You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
RPs may not be aware of the challenges with supporting 3rd party passkey providers based on issues at the platform level.
It's important that RPs are aware of this, as their deployments will cause problems for their users who will raise those issues with the RP or the 3rd party provider, when in fact the issue may lie partly with the platform provider.
Details
iOS & macOS
Main issue
Currently native applications on iOS/macOS that support passkeys will fail to work with 3rd party pluggable providers due to a bug in iOS/macOS, this bug is fixed in iOS 17.2 (and most likely macOS 14.2) which is yet to be released.
RPs will not receive the clientDataJSON from the OS, it will be empty/nil, until the user has updated to iOS 17.2/macOS 14.2 (yet to be released).
While this applies to iOS and macOS, it is assumed most RPs will be concerned with the issue on iOS.
Additional issues
Below are additional issues with Apple support for pluggable providers, the bugs are listed here verbatim from the Apple bug reporting tool. It is not known if/when these issues will be resolved.
WebAuthn property "excludeCredentials" is not catered for in the passkey provider APIs (FB12855407)
It would be helpful to receive the "excludeCredentials" array from the RP so that the 3rd party passkey provider knows this is a potential duplicate key registration. Having duplicate keys created within a passkey provider is problematic as the user may end up deleting one from the authenticator and another via the RP settings screen, if 2 keys are registered with the same authenticator. If the OS knows that the authenticator already has a credential, it does not need to provide the entire list of "excludeCredentials", it can filter to include only credential IDs that it knows are owned by the provider.
The credProps extension is not supported on iOS (FB12817012)
If the RP requests the credProps extension to know if a resident key was created by the authenticator, iOS does not provide the credProps information, macOS does. You can test this with the following test website: https://inabajunmr.github.io/webauthn-viewer/ Create a passkey on macOS and notice the getClientExtensionResults section where the credProps extension information is provided. Do the same on iOS and notice it is missing. Expected behaviour is that credProps/rk extension is provided when the RP requests the extension.
Android
Native apps must use the Credential Manager API and not the legacy FIDO2 API, in order for 3rd party providers to work, there is a guide for this:
Summary
RPs may not be aware of the challenges with supporting 3rd party passkey providers based on issues at the platform level.
It's important that RPs are aware of this, as their deployments will cause problems for their users who will raise those issues with the RP or the 3rd party provider, when in fact the issue may lie partly with the platform provider.
Details
iOS & macOS
Main issue
Currently native applications on iOS/macOS that support passkeys will fail to work with 3rd party pluggable providers due to a bug in iOS/macOS, this bug is fixed in iOS 17.2 (and most likely macOS 14.2)
which is yet to be released.RPs will not receive the clientDataJSON from the OS, it will be empty/nil, until the user has updated to iOS 17.2/macOS 14.2
(yet to be released).While this applies to iOS and macOS, it is assumed most RPs will be concerned with the issue on iOS.
Additional issues
Below are additional issues with Apple support for pluggable providers, the bugs are listed here verbatim from the Apple bug reporting tool. It is not known if/when these issues will be resolved.
WebAuthn property "excludeCredentials" is not catered for in the passkey provider APIs (FB12855407)
It would be helpful to receive the "excludeCredentials" array from the RP so that the 3rd party passkey provider knows this is a potential duplicate key registration. Having duplicate keys created within a passkey provider is problematic as the user may end up deleting one from the authenticator and another via the RP settings screen, if 2 keys are registered with the same authenticator. If the OS knows that the authenticator already has a credential, it does not need to provide the entire list of "excludeCredentials", it can filter to include only credential IDs that it knows are owned by the provider.
The credProps extension is not supported on iOS (FB12817012)
If the RP requests the credProps extension to know if a resident key was created by the authenticator, iOS does not provide the credProps information, macOS does. You can test this with the following test website: https://inabajunmr.github.io/webauthn-viewer/ Create a passkey on macOS and notice the getClientExtensionResults section where the credProps extension information is provided. Do the same on iOS and notice it is missing. Expected behaviour is that credProps/rk extension is provided when the RP requests the extension.
Android
Native apps must use the Credential Manager API and not the legacy FIDO2 API, in order for 3rd party providers to work, there is a guide for this:
https://developer.android.com/training/sign-in/fido2-migration
Early adopters of passkeys will most likely be using the legacy Android FIDO2 API.
Proposed Content Type
Best Practice
Proposed Content Title
Considerations for pluggable passkey provider support
Related Articles
The text was updated successfully, but these errors were encountered: