-
As I understand, passkeys are compatible with WebAuthn. However, the iOS APIs look somewhat different than the browser WebAuthn APIs.
I'm mostly confused on how the PublicKeyCredentialCreationOptions (traditionally generated server side) from WebAuthn maps to iOS APIs. Specifically:
-
How to specify in ASAuthorizationPlatformPublicKeyCredentialProvider#createCredentialRegistrationRequest which cryptographic algorithms the Relying Party supports (pubKeyCredParams)? Or is there a specific one that the server needs to support to be compatible with passkeys, as it can't be provided?
-
The userID for ASAuthorizationPlatformPublicKeyCredentialProvider#createCredentialRegistrationRequest looks like an username in "Supporting passkeys" documentation ("anne_johnson"). Is this error in the documentation? In WebAuthn, the user ID for PublicKeyCredentialCreationOptions is described as "The user handle of the user account entity. A user handle is an opaque byte sequence with a maximum size of 64 bytes, and is not meant to be displayed to the user.". Specifically it states that "The user handle MUST NOT contain personally identifying information about the user, such as a username or e-mail address.".
Is the userID in createCredentialRegistrationRequest equivalent to WebAuthn PublicKeyCredentialCreationOptions.user.id, or something different? If it is equivalent, then I think the supporting passkeys documentation should not suggest using username there, as it's clearly in violation of WebAuth standard. If it's not equivalent, what then is the equivalent of that in the iOS APIs?
-
-
Is there any documentation on the QR based authentication flow? So this would be a case where I want to use a Windows computer to sign in to a website using a passkey from my iOS device.
I saw it demoed in several videos, but haven't found any documentation to accompany it.
-
How does one generate the QR code (in the demo it was browser which seemed to have built-in support for that, but let's say it would be needed in a native application running on a game console or Smart TV)?
-
Are there any protections against phishing in this flow? Would it be possible for me to send a picture of the QR code to someone remotely and have them scan it and use their passkey to sign in?
-
-
If passkeys can be shared via AirDrop/iMessages, how can they be secure from phishing? If someone asks me to share my passkey with them and I comply, how is it different and more phishing resistant compared to someone asking for my password and me complying? I've seen several posts go around this question saying that for passkeys to be adopted, they need to have the same versatility than passwords. I accept that, but if passkeys can be shared with anyone having iOS device, they can't eliminitate phishing related problems.
Great questions! Trying to address all of them:
- In general there's a 1:1 mapping for supported options between WebAuthn and the ASAuthorization APIs. There are some WebAuthn features that aren't supported in each of the passkey and security key APIs, so those options aren't present.
- Passkeys only support ES256, aka
ASCOSEEllipticCurveIdentifierP256, aka-7. There's no option exposed for this since it's not configurable. - Thanks for calling this out! We'll get the documentation updated 🙂. The
userIDparameter is indeed the user handle.
- The QR code flow will be publicly formalized in an upcoming version of the CTAP2 spec. It uses the "hybrid" transport (formerly known as "caBLE"). There is a detailed explanation of how it works in the Meet passkeys WWDC video, which also answers both below questions.
- It is indeed a feature of the browser or platform, not the RP. Part of the reason for standardization is so that other platforms, such as game consoles and smart TVs, can implement it. It should not be possible for an RP to implement the protocol itself, by design, as part of the phishing resistance.
- Absolutely yes, it was very much designed with phishing protections in mind. A picture of a QR code will not work without physical proximity to the user. The session video mentions this exact scenario.
- In iOS 16 and Safari16/macOS Ventura, passkeys can be shared only via AirDrop, not iMessage. The nature of AirDrop alone makes phishing infeasible, as it would require an attacker physically close to the user, who is able to convince them to share the credential itself, rather than attempting to sign in somewhere with it. There are also additional mitigations in place, such AirDrop for passkeys only being allowed for mutual contacts (i.e. both the sender and receiver have each other's Apple ID in their Contacts).