Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

1. Introduction

This document defines a mechanism for generating and verifying identity assertion tokens using Navigator Credentials. These tokens are client-generated cryptographic signatures that bind a user identity to an authentication assertion, leveraging WebAuthn-compatible authenticators.

Tokens are signed using one of the following public-key signature algorithms:

  • Ed25519 (preferred), or
  • RS256 (RSA PKCS#1 v1.5 with SHA-256).

2. Token Format

Tokens are transmitted using POST request to server defined on query parameters redirect.

2.1 Body fields

FieldDescription
signatureCryptographic signature.
idUnique user identifier with server (e.g., id@server.com).
keyIdentifier of the public key used to verify the signature.
authenticatorDataBase64url-encoded data returned by the authenticator, includes flags, counters, etc.
clientDataJSONBase64url-encoded JSON describing the context (challenge, origin, type).

3. Token Generation (Client-Side)

  1. The client obtains credentials via the WebAuthn API.
  2. The authenticator signs a challenge with the user’s private key.
  3. The client builds a token URL with the resulting signature and metadata.
  4. The token is shared with the relying party (e.g., via HTTP redirect or fetch).

4. Token Verification (Server-Side)

To verify the received token, the server MUST:

  1. Parse the fields from the body request.
  2. Reconstruct the signed payload:
    • message = authenticatorData || SHA-256(clientDataJSON)
  3. Retrieve the public key:
    • Use the key and id parameters to fetch the correct key.
    • Validate the authenticity of the server and key material.
  4. Verify the signature using the appropriate algorithm (Ed25519 or RS256).
  5. Validate authenticatorData:
    • Check presence/verification flags.
    • Validate the relying party ID hash.
  6. Parse and validate clientDataJSON:
    • Ensure challenge matches what was sent.
    • Confirm origin matches expected domain.
  7. Create server-side token with expiration.

5. Security Considerations

Token relay on WebAuthn with extras.

  • User ID modification: server MUST get public key from query server using query user ID; if no key corresponds to the user, the connection is invalidated.
  • Replay attack: while WebAuthn have no timestamp or nonce field, it have a challenge one which MUST be used.

NEVER use WebAuthn signature as server-side token. You SHOULD use JWT after verifications. challenge generated by the server MUST have a window shorter than 2 minutes.