Passkey questions

  1. 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?

  2. 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?

  3. 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.

Up vote post of mikko-nylen Down vote post of mikko-nylen
1.5k views
Posted by
mikko-nylen
Reply
Add a Comment

Accepted Reply

Great questions! Trying to address all of them:

  1. 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 userID parameter is indeed the user handle.
  1. 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.
  1. 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).
Posted by
garrett-davidson
Up vote reply of garrett-davidson Down vote reply of garrett-davidson
Post marked as solved

  • Hi Garret,

    I was curious about the rationale behind only supporting the one ES256 algorithm. We have a stack that’s standardized on a different algorithm and it would be helpful to us not to have to add another signature type.

    —
    VortexByte
Add a Comment

Replies

Great questions! Trying to address all of them:

  1. 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 userID parameter is indeed the user handle.
  1. 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.
  1. 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).
Posted by
garrett-davidson
Up vote reply of garrett-davidson Down vote reply of garrett-davidson
Post marked as solved

  • Hi Garret,

    I was curious about the rationale behind only supporting the one ES256 algorithm. We have a stack that’s standardized on a different algorithm and it would be helpful to us not to have to add another signature type.

    —
    VortexByte
Add a Comment

Thanks for the great answers! Glad that it was just a documentation issue for user ID and good to know which algorithms to support, although I guess most library implementations support all the major ones anyway.

And sure, didn’t even consider that passkey sharing is only over AirDrop and hence you need to be physically close for the sharing to work. I guess the proximity requirement is also why the QR code is not possible to be implemented by RP (as that would require Bluetooth I’d imagine), and instead it has to be built by the platform.

Even if passkeys could be shared without the proximity requirement (which I'm happy they don't), it occurred to me just after posting that another phishing protection built-into the WebAuthn standard (and thus passkey) over passwords is that you can't just send a scam link over email or sms that looks like yourservice.com and ask the users to sign in, as the platform authenticator wouldn't recognize the domain and provide an option for signing in there.

Posted by
mikko-nylen
Up vote reply of mikko-nylen Down vote reply of mikko-nylen
Add a Comment