Passkey-fused credentials: definition, protocols and use cases

In the previous post I described issuance and presentation protocols for a kind of third-party credential that is made available at once to all the browser instances controlled by a user, which I refer to as the user's sync fabric, instead of being issued to one instance and then replicated to other instances upon request by relying parties. The credential comprises a passkey and a certificate, uses the public key of the passkey as the public key in the certificate, and uses an AES key stored in the user.id parameter of the passkey to encrypt the certificate.

Then in this LinkedIn post I referred to the third-party credential as being the result of "fusing" a passkey with a public key certificate.

Here I'm going to formally define the term passkey-fused credential (PFC) to refer to that kind of third-party credential, restate the issuance and presentation protocols of the previous post with reference to that definition, and provide four examples of use cases where PFCs can be used.

Definition

A passkey-fused credential is a distributed data structure comprising:

  • A discoverable passkey with a 64-byte user.id parameter comprising the concatenation of:
    • A random high-entropy 32-byte string that we shall call the "retrieval token".
    • A random high-entropy 32-byte symmetric key that we shall call, for conciseness, the AES key.
  • A user record in a noSQL database used by the issuer's backend, comprising:
    • The retrieval token.
    • A set of attributes verified by the issuer as pertaining to the user. (This is only used during issuance.)
    • A public key certificate signed by the issuer and encrypted under the AES key, comprising:
      • A subset selected by the user from the set of attributes verified by the issuer as pertaining to the user, and
      • The public key of the passkey.

Caveat. The PFC must be created in a browser that supports interception of a credential presentation request by a service worker. Chrome, Edge and Brave do, Firefox and Safari do not.

Issuance

  1. The issuer generates the random retrieval token and creates the user record with the retrieval token and the set of verified attributes.
  2. The issuer conveys the retrieval token to the user through some channel that authenticates the recipient as the user to whom the verified attributes pertain.
  3. The user sends a request authenticated by the retrieval token to the credential issuance endpoint of the issuer through a browser instance in the user's sync fabric.
  4. The issuer frontend generates the random AES key and calls navigator.credentials.create() with:
    • The domain name of the issuer as the value of the rp.id parameter.
    • "required" as the value of the authenticatorSelection.residentKey parameter.
    • The concatenation of the retrieval token and the AES key as the value of the user.id parameter.
  5. The issuer frontend extracts the public key of the passkey from the response to the call to navigator.credentials.create().
  6. The issuer frontend uses the retrieval token to retrieve the set of verified attributes form the issuer backend and asks the user to select the subset of attributes to be included in the public key certificate.
  7. The issuer frontend sends the retrieval token, the selected attributes, the public key of the passkey, and the AES key to the issuer backend.
  8. The issuer backend verifies that the selected attributes are in the user record, creates a certificate binding the selected attributes to the public key of the passkey, signs the certificate, and encrypts the certificate with the AES key.
  9. The issuer backend adds the encrypted certificate to the user record.

After issuance, the user's sync fabric is equipped with a PFC that can be presented to relying parties accessed from any of the browser instances in the fabric as shown below.

Presentation

  1. The RP sends a POST request with a challenge and a callback URL to the credential presentation endpoint of the issuer on a browser instance in the user's sync fabric.
  2. If the request is not intercepted by a service worker, the issuer handles it as follows:
    1. The issuer frontend asks the user for consent to present the PFC to the RP, with the option of creating a service worker and storing the encrypted certificate in localStorage to facilitate subsequent presentations.
    2. The frontend obtains a signature on the challenge and the callback URL received from the RP by calling navigator.credentials.get() with:
      • The domain name of the issuer as the value of the rpId parameter.
      • A concatenation of the challenge and the callback URL received from the RP as the value of the challenge parameter.
      • An empty array as the value of the allowCredentials parameter, causing the authenticator to look for a credential created with the domain name of the issuer as the value of the rp.id parameter.
    3. In addition to the signature, the frontend obtains the retrieval token and the AES key from the value of the userHandle property of the response to navigator.credentials.get(), which is identical to the value of the user.id parameter of the call to navigator.credentials.create() for discoverable credentials.
    4. The frontend uses the retrieval token to download the encrypted certificate from user record.
    5. The frontend creates a service worker and stores the encrypted certificate in localStorage, if the option to do so was not declined above.
    6. The frontend uses the AES key to decrypt the certificate and sends the signature and the certificate to the RP.
    7. The RP verifies the signature on the challenge and the callback URL using the public key in the certificate, which is the public key of the passkey, and the signature in the certificate using the public key of the issuer, which might be obtained from a PKI or a VICAL.
  3. If the request is intercepted by a service worker, in which case there will be an encrypted certificate in localStorage, it is handled as follows:
    1. The service worker creates a consent page, which asks the user for consent to present the PFC to the RP.
    2. JavaScript code in the consent page calls navigator.credentials.get() and obtains the signature on the challenge received from the RP and the callback URL, the retrieval token, the AES key, and the encrypted certificate as the issuer frontend does in steps 2b-d.
    3. JavaScript code in the consent page decrypts the certificate and sends the signature and the certificate to the RP as the frontend does in step 2f.
    4. The RP verifies the signature on the challenge and the callback URL, and the signature in the certificate, as in step 2f.

Use cases

  1. Remote identity proofing, using a government-issued PFC

    A PFC resulting from the fusion of a passkey and a JSON certificate with attributes from a digital driver's license could be used for bank account opening with KYC compliance, citizen access to online benefit portals, or account recovery.

  2. Federated identity, using a PFC issued by the identity provider

    A PFC resulting from the fusion of a passkey and a JSON certificate with profile attributes could be used for registering to websites.

  3. Registration at a website, using a subset of the attributes in a government-issued PFC

    A PFC resulting from the fusion of a passkey and a selective disclosure JSON certificate with attributes from a digital driver's license could be used for registration at a website with attributes requested by the site and consented to by the user.

  4. Login to a website, using a PFC issued by the website with attributes from the user profile

    A PFC resulting from the fusion of a passkey and a JSON certificate with attributes from the user's profile at the site would provide returning user authentication without having to obtain the attributes from the database of the website.

Leave a Reply

Your email address will not be published. Required fields are marked *