+1. Many of our customers ask if we’ll being adding Passkeys support to our Password Manager, so we’ve now added a request for this functionality to be made available via Feedback Assistant. We all want to see and play our part in a Password-less future. By Apple empowering third-party Password Manager apps to securely generate, store, and autofill Passkeys via native APIs, they reduce friction and hugely increase potential Passkey adoption from users who are already happy with their existing Password Manager app, without forcing them to have to use the in-built system provided password manager. This will also negate the need for a fragmented user experience of having to manage passwords and passkeys from separate apps. As a side point, 1Password will be rolling out their own solution for Passkeys in early 2023, so it looks like password managers being able to manage a user’s Passkeys might soon become a user expectation.

Ah, OK that makes sense as I've been using the simulator solely. If any other issues pop up I'll be sure to add them to Feedback Assistant. Thanks for your help!

Thanks for your reply. That's super helpful to know. I'll check over our implementation and report back here (in case it will help other devs). I hope it's just an issue with our response as opposed to Google doing some strict or custom validation based on weakly identifying iCloud Keychain + Passkey Provider platform (i.e iOS). Would be interesting to hear if any other third-party passkey provider devs are successfully creating passkeys for Google accounts, or if they've run into a similar issue as mine?

Hey Incogn1to, as a fellow third-party passkey provider, I wonder if you can help. We're debugging an issue with passkey compatibility for Google Accounts: https://developer.apple.com/forums/thread/737161 It's most likely an issue with our specific implementation, but for peace of mind I wanted to ask if you're able to provide passkeys for Google accounts? Google is the only service we're unable to provide passkeys for, so if you're able to then at least I know the issue is on my end. Thanks!

It’s not mandatory to use iCloud Keychain for sync. It‘s up to each third-party passkey provider to decide how they will securely create (based on WebAuthn Authenticator Model spec), persist, and optionally sync passkeys. Apple have intentionally left the implementation details up to the passkey provider, to allow for flexibility.

For posterity, @Incogn1to had already run into this issue and rightly pointed out here that the WebAuthn spec requires that the attestationObject‘s dictionary keys be sorted in a specific order. It turns out that Google seem to be the only RP that’s validating this. I missed that requirement, but I can confirm that using an ordered dictionary has resolved the issue. Thanks again @Incogn1to and @garrett-davidson!

Hey @letsbondiway1986 , The UX flow would be pretty much the same as creating a passkey with iCloud Keychain, but for a third-party provider/passkey manager some additions to that flow might be: Presenting a screen to unlock the password/passkeys database via biometrics (Face/Touch ID). Presenting a screen to allow the user to select which vault to save the passkey to (if your app supports vaults). You can implement the passkeys creation and auth flows using the newly added extensions on ASCredentialProviderViewController: https://developer.apple.com/documentation/authenticationservices/ascredentialproviderviewcontroller

I’m still seeing this bug even in iOS 17.1.2 and it’s preventing me from shipping a feature that relies on Widget button interactions, because the host app is easily being launched unintentionally. If you haven’t already done so, please report this bug by filing feedback at https://feedbackassistant.apple.com and hopefully Apple will fix this for us 🙏