Skip to main content

PassKey ID Token binding

· 3 min read

Aim of this document is discuss simple, good-enough solutions for complex problems.

Proposal 1: PassKey-ID Token binding​

Demo:

What's the problem we're trying to solve?​

Digital signatures and key management infrastructure are complicated and hard to use.

Note: passkeys do have their own limitations.

The opportunity​

  • Build a good-enough digital signing infrastructure by leveraging the PassKey infrastructure
  • Enable secure authorization

How?​

Use OIDC to bind ID tokens to passkeys (jwk thumbprints) by setting the jwk thumbprint as nonce in the authorization request.

Descriptions​

In the OIDC protocol, RPs can create digitally signed authorisation request and can define their own nonce. After a successful authentication, the authorisation server returns a digitally signed ID Token that contains the RP-defined nonce. If nonce is a hash of the public key (e.g., JWK thumbprint), the ID token is cryptographically bound to the public key. The private key controller can use the ID token as identity attestation that can be included in digital signatures; a simplified alternative to x509 certificates.

Below we're introducing two binding flows.

Option A: A simple ID Token binding

Assumptions

  • Authorization server supports nonces
  • Authorization server supports signed ID tokens

Flow

  • RP asks the user to register her passkey
  • The RP computes the jwk thumbprint
  • RP creates an authorisation request and sets the nonce value to the jwk thumbprint
  • Traditional OIDC flow is initiated by the RP
  • At the end of the flow, the RP receives a signed ID token with jwk thumbprint in it

RP can offer services where the user can use their passkey to create identity-bound authorisations or digital signatures.

Note: it is easy to extend the flow to include a proof that the user actually controls the public key at the time of authorisation creation by including both public key and the proof in the nonce; e.g., nonce: v1_encoded-jwk_jws

For the authorisation server to verify the proof, additional proof verification needs to be implemented.

Alternatively the RP could include the public key in their configuration and ask the user

Security considerations​

  • The model requires that both RP and AS are trusted.
  • RP is liable to include the correct public key digest in the authorisation request.
  • The authorisation server MUST prevent the reply attack

Signing with passkeys​

Demo: N/A

Digital signing infrastructure is complex (overcomplicated).

Passkeys, on the other hand, are easy to use and are supported by major platforms. Passkeys hide the complexity of key management and are a good candidate to create "chatgpt moment" in digital identity.

Passkeys are primarily designed for authentication.

userinfo endpoint with signature profiles​

Demo: N/A