Passkeys.is

Due to the Webauthn specification, Passkeys are created against a particular website (e.g., A.xyz) as its “Relying Party ID”. This Passkey will only be able to be prompted during the visit from a browser to this domain. If this domain is no longer available, the Passkey will remain within the device of the user, but it will no longer be able to be prompted by any other website (e.g., B.xyz). Additionally, since only A.xyz was ever able to get the related public key of said Passkey as part of its creation, if the public key of the Passkey was not stored elsewhere, this public key is lost forever, and signatures can not be verified against it.

This architecture poses a critical flaw into applications that do not use the Passkey in the intended Webauthn workflow, such as decentralized applications that only use the Passkey as an authentication mechanism for a smart wallet within the context of web3 (e.g., EIP 4337). However, as a work around, as long as the source code of A.xyz is available, the user can run it locally and trick a device where the Passkey is stored into loading A.xyz in its device instead of via the actual DNS call the domain resolved. This can be easily done in computer devices by updating the local /etc/hosts and using an SSL proxy with a self-signed certificate (e.g., via mkcert), but might pose a harder challenge in a mobile device.

Although part of the Passkey information is provided as part of the "signing" or "attestation" process of the Webauthn workflow, the actual public key is NOT included in the response. The attestation includes a signature over the clientDataJSON and the authenticatorData, the latter including some information about the actual device used during the verification process. However, the public key data is only available during the registration part of the Webauthn workflow (i.e., the navigator.credentials.create call) and is not available to that particular Passkey anymore, not even during the navigator.credentials.get call.

To access a Passkey public key, you need to await for the response payload, and call the method response.getPublicKey(). Within TypeScript, you can cast the response of the credential as AuthenticatorAttestationResponse to have visibility of the getPublicKey method.

As a requirement to work with Passkeys in the Apple ecosystem, iCloud for Keychain needs to be enabled. As a result, Passkeys generated in an iOS device will be synced using Apple’s encrypted HSM setup that protects all user’s iCloud accounts. This means that other iOS devices sharing the same Apple ID will automatically sync this Passkey. In case of 10 failed Apple ID attempts to recover an iCloud account, as detailed by Apple’s Terms of Service, the account will be locked, and no further information, included Passkeys connected to this account, can be recovered.

Passkeys can be backed up to a different Apple ID account using iOS’s Airdrop feature. Both users (sender and recipient) need to be in each other contacts’s list. After sending the Passkey, it will be available on the recipient’s phone via its traditional biometrics workflow. Although an iOS device can send a Passkey to a macOS device (e.g., macbook Air, macbook Pro), the latter can not make use of the Passkey, nor it is available via Keychain or Safari to log in to the website the Passkey was created in.

The property authenticatorSelection and its children authenticatorAttachment can determine a preference for a particular authenticator. If selected cross-platform, then the webauthn authentication catalog will only show support for roaming authenticators (e.g., Yubikey). At the same time, if selected platform, it will request only biometrics-supported authentication. By default (i.e., if the property is missing), no preference is given and thus, both options can be selected.

There are a couple of edge-cases where a platform authenticator can be toggled on and off (e.g., a keyboard with a fingerprint reader with FIDO2 support) and platform is preferred. If the only authenticator is this device, then the workflow will continue w/o even prompting signature using the previously loaded key before the authenticator was disconnected.