Thank you! That is exactly what I needed. I was focused on the password attributes.

Sorry, I should have included that.Yes, targeting macOS, arbitrarily new (no existing users; I'm on 10.15.4). I'm trying to use Swift, though if some option which would help isn't available, I'm fine with Obj-C. Currently using URLSession, though I'm open to switching if something else would be better. The remote API is based entirely around HTTP PUT requests.iPadOS compatibility might be an eventual goal, but that's waaaay off past the horizon. For now, I'm trying to understand the right way to flag that the user doesn't want credentials saved for a given server. Safari's behavior seems like a good place to start, and I started by asking here because I'm not sure if it's a weird thing Safari does, or if it's using some flag on the keychain items of which I am unaware.If this code ever winds up being used for real, the server it talks to uses Active Directory accounts for authentication. In organizations (like mine) which have ignored the last 30+ years of security research showing regular password changes hurt security, the users may need to update the saved password frequently. The same credentials would also be used to log in to a lot of internal web applications, file servers, and so on, so making it visible in Keychain Access is the cleanest way I could think of to let the user update all instances of the password at once.

Figured it out, and yes, I was missing something obvious. You apparently have to also have the keys kSecUseDataProtectionKeychain or kSecAttrSynchronizable set to true in your query dictionary for kSecAttrAccessGroup filters to work. It's right there in the documentation, and I evidently missed it.Still not sure what's going on with kSecAttrIsInvisible, but I don't actually need that working.

Sorry, forgot to include my version. I'm on macOS 10.15.4, targeting macOS 10.15.My application has the Keychain Group "com.example.myApp" specified in its Signing & Capabilities section, and "$(AppIdentifierPrefix)com.example.myApp" in its entitlements file.Weirdly enough, I do see the nine additional items which keep showing up in my query in Keychain Access under login > Keys. When I search for kSecAttrIsInvisible: true, I get only the nine keys I see in Keychain Access. When I search for kSecAttrIsInvisible: false, I get ... the nine keys I see in Keychain Access.I just feel like there must be something critical I'm misunderstanding about how these queries are meant to work.

Just learned something irritating about the on-disk format of SSH keys (possibly other keys, not sure). The leading zeros are actually ommitted not just from OpenSSL's output, but from the file on disk as well. The base64 above decodes to hex starting with this:30 81 db 02 01 01 04 41 5a 69 4d 15 75 c8 03The private key starts at 5a 69 4d 15. No leading zeros in the bytes from the base64. Easy enough to prepend zeros as needed:var tempPrivateKeyBytes:[UInt8] = privateKeyBytes while tempPrivateKeyBytes.count < 66 { tempPrivateKeyBytes.insert(0x00, at: 0) } self.ecdsaPrivateKey = try! P521.Signing.PrivateKey(rawRepresentation: Data(tempPrivateKeyBytes))