WebAuthn serialization (Web IDL/JSON)

Use cases

• Authenticators - Using libwebauthn to communicate with an authenticator
• Request validation - Using libwebauthn to validate WebAuthn requests (origin checking) only, then passing the validated JSON request to a WebAuthn IDL-compatible password manager
• Client processing - Using libwebauthn to perform WebAuthn client responsibilities (eg. client extension processing) before routing the request to another CTAP2-compatible virtual device (eg. password manager)

Changes

• 1. Deserialization: Allow WebAuthn operations to be created form WebAuthn JSON, eg. MakeCredentialRequest::parseJson.
  • This should be optional, and it should still be possible to create requests manually.
  • The origin of the request should be exposed, allowing the client to perform origin checking.
  • The parser should separate known extensions from unknown extensions:
    • Known extensions should continue to be mapped to CTAP2 extension input structures;
    • Unknown extensions should be returned as a JSON dictionary, containing the original payload for optional (external) further processing.
• 2. Serialization: Serialize responses back to WebAuthn JSON

TODOs

• Challenge min length validation
• Allow arbitrary size PRF inputs
• Update examples to use JSON requests

Context

• https://github.com/linux-credentials/linux-webauthn-platform-api/issues/26

Start by locating MakeCredentialRequest and the related WebAuthn and CTAP2 request/response types. Review the linked platform API issue and determine how optional JSON deserialization, origin exposure, extension handling, and response serialization should fit together. Done means WebAuthn JSON requests and responses are supported while manual request construction remains available.