Excellent work on Passkeys. For context, I’m soon to release a Password Manager app that is built specifically for Apple devices only (iOS, iPadOS, macOS). A user’s vault items are encrypted on their own device and synced end-to-end encrypted via their own private iCloud database. As you’d expect, the app requires the user to enter their master password to unlock their vaults, and allows them to optionally enable Touch or Face ID for a passwordless unlock experience. In this scenario where there is no third-party server involved, and auth takes place on-device only, is there any meaningful way an app like this can or should take advantage of Passkeys? The only thing I can think of so far would be to allow the user to use a Passkey instead of a master password to unlock their vault. But aside from the convenience factor for the user in terms of UX, I’m not entirely sure I understand if there would be any major security advantage in doing so, over the app’s existing auth/unlock flow?

Are “Notification Service Extensions” officially supported on macOS? I’m developing an app for both iOS and macOS (not Catalyst). I’ve successfully setup a separate notification service extension for both the iOS and macOS targets. The iOS extension is modifying the CKSubscription push notification as expected. However the macOS notification service extension is not being launched at all no matter what I seem to try, matching deployment targets etc. I’m also asking because although Apple docs report that support for UNNotificationServiceExtension was added in macOS 10.14, the article at https://developer.apple.com/documentation/usernotifications/modifying_content_in_newly_delivered_notifications makes no mention of macOS, only iOS.

Firstly massive thank you to the Passkeys team at Apple for opening up the APIs to allow third-party password manager apps to save and autofill Passkeys in iOS 17! I wasn't expecting this so soon. Incredible work. I have successfully implemented the new methods on ASCredentialProviderViewController, up to the point where our app's extension is now being presented when a user is prompted to "Create a passkey?". However two things are not entirely clear to me from this point on: When the user chooses our app to create a password by tapping "Continue", the prepareInterfaceToProvideCredential(for credentialRequest: ASCredentialRequest) method is called. Should I be handling passkey creation within this method? Really at this point I was expecting prepareInterface(forPasskeyRegistration: to be called instead. Are new passkeys automatically generated and returned by AuthenticationServices during this flow, or is it down to the developer to generate a new passkey here? I ask because the documentation for prepareInterface(forPasskeyRegistration: seems to imply the former, stating: "This method will present your extension's UI for user authentication before creating the passkey." Thanks again.

I suspect this is an issue with Google’s passkey implementation, but it might not be, and if there is a solution I suspect this post will be useful for all other third-party passkey providers encountering the same issue. I have implemented Passkeys in our password manger using the new APIs introduced in iOS17. Passkey attestation and assertion works as expected with every service we’ve tested that supports Passkeys (I.e Webauthn.io, GitHub, etc). However the only service that doesn‘t work is Google. I can create a passkey for Google using iCloud Keychain just fine, but for some reason, although my app successfully creates the passkey, Google is rejecting it. I suspect this is a security measure on Google’s side, but it will be a UX nightmare for users of third-party passkey managers on iOS 17, as they won’t be able to create or sign in with a passkey for Google (which will probably be the number 1 use-case for using passkeys). When using iCloud Keychain to create a passkey, unlike other services, I noticed that Google actually recognises that I’ve used iCloud Keychain to create the Passkey, and labels the Passkey with “iCloud Keychain”. Is Apple sending some additional identifying info in their attestation statement that I’m not sending? If not, how is Google able to identify the passkey provider (in this case “iCloud Keychain”) by name? Could it be that Google has somehow whitelisted iCloud Keychain for Passkey creation, while disallowing third-party providers? Assuming it is the latter, unfortunately there is no way to reach out to Google about this. I suspect Apple would need to advocate on the behalf of third-party providers running on apple platforms, that they be allowed to provide passkeys for Google sign in. Its a shame to hit this type of road block so close to the iOS 17 release candidate.

Rapidly tapping on a Button in an interactive widget bypasses the button's AppIntent action, and launches the host app instead. I've filed a radar for this, but is there any known workaround for this behaviour? Doesn't seem to happen when using Apple's first party app widgets.