After a normal Solid-OIDC login, a Solid application registers a W3C WebAuthn (passkey) credential — bound to the application's own origin — with the user's OpenID Provider (OP). Thereafter the application re-authenticates without an interactive redirect: it fetches a single-use challenge from the OP, produces a WebAuthn assertion in the application's own page, and exchanges the assertion at the OP's token endpoint using OAuth 2.0 Token Exchange ([[RFC8693]]) for ordinary Solid-OIDC, DPoP-bound tokens ([[RFC9449]]). Because the credential is origin-bound and the user agent refuses to release it to any other origin, one assertion attests both the user (possession of the authenticator) and the client application (its origin, signed unspoofably into clientDataJSON). Resource Servers (Pods) are unchanged: they consume the issued DPoP-bound token exactly as any other, trusting the OP via the existing solid:oidcIssuer link.

This document is an unofficial editor's draft. It has no standing whatsoever: it is not a work item of the W3C Solid Community Group and is not endorsed by that group, by W3C, or by anyone else. It is published to solicit review before any proposal for adoption.

This specification is implementation-first: its normative requirements are those enforced by the reference implementations — the OpenID Provider component [[CSS-WEBAUTHN]] and the client / wire-format library [[REAUTH-IMPL]] — with a small number of clearly marked additions. records, requirement by requirement, which parts are implemented and which are proposed.

Drafting disclosure: this draft was prepared with AI assistance (Claude Fable 5, Anthropic), working from the jointly-authored design corpus ([[SOLID-WEBAUTHN-ARCH]], its ADR log, and the reference implementations), and is awaiting review by its human editor. Errors introduced in drafting are the tooling's, not the cited sources'.

Introduction

This section is non-normative.

Solid-OIDC [[SOLID-OIDC]] authenticates a user to a Solid application through an interactive, redirect-based OpenID Connect flow. Once the resulting tokens expire, the application must re-authenticate — and a full top-level redirect to the OP is disruptive: it unloads the application, loses in-memory state, and trains users to type credentials into whatever page appears. This specification defines a redirect-free re-authentication mechanism built on W3C WebAuthn Level 3 [[WEBAUTHN-3]]: a fast, phishing-resistant challenge–response handled entirely between the application and the OP, surfaced to the user as at most a passkey prompt.

Two facts fix the architecture and are assumed throughout (rationale and threat analysis in [[SOLID-WEBAUTHN-ARCH]] §3.3):

F1 — the application is the Relying Party.

A WebAuthn assertion's RP ID is bound by the user agent to an origin the Relying Party controls. A different-origin OP cannot be the RP for an app-bound credential. The ceremony therefore runs in the application, and the OP verifies a relayed assertion. This is why the OP cannot host the ceremony as its own login page — doing so would make the OP the RP and destroy the client-attestation guarantee.

F2 — a WebAuthn key cannot sign HTTP requests.

The authenticator signs only a server challenge it wraps in authenticatorData and clientDataJSON, with a user gesture each time. WebAuthn is a challenge–response login primitive — which is exactly how it is used here, and why per-request request-signing is out of scope.

This document is the normative wire specification. The non-normative companion — overview, rationale, C4 diagrams, and the full STRIDE / LINDDUN / attack-tree threat analysis — is the architecture document [[SOLID-WEBAUTHN-ARCH]]. Where the two disagree, this document governs.

This specification defines three conformance classes — Application, OpenID Provider, and Resource Server — enumerated in . Requirements phrased against a class bind every implementation of that class.

Conformance classes

This specification defines three conformance classes. The terms are used in the sense of [[SOLID-OIDC]].

Application (the WebAuthn Relying Party)

A Solid-OIDC client running in a user agent at an HTTPS origin, identified by a Client ID Document URI. It is the WebAuthn Relying Party: it runs the registration and assertion ceremonies via navigator.credentials and relays the results to the OpenID Provider. Conformance requirements: , , , (the client-side requirements, including req-client-downgrade).

OpenID Provider (the verifier, key store, and grant)

A Solid-OIDC OP that additionally stores registered passkey public keys, issues challenges, verifies relayed assertions, and mints tokens via the re-authentication grant. Conformance requirements: , , , , , , , .

Resource Server (explicitly unmodified — a non-target)

A Solid-OIDC Resource Server (Pod). This specification imposes no requirements on it: it consumes the issued DPoP-bound Solid-OIDC access token exactly as it consumes any other, trusting the OP via the existing solid:oidcIssuer link [[SOLID-OIDC]]. That zero-change property is a design goal; a Resource Server that is entirely unaware of WebAuthn is conforming.

Terminology

This document uses the wire structures and ceremonies of [[WEBAUTHN-3]]: clientDataJSON, authenticatorData, the UP (User Presence) and UV (User Verification) flags, the signature counter (signCount), the COSE credential public key, and the JSON serialization of ceremony results (PublicKeyCredential.toJSON() → RegistrationResponseJSON / AuthenticationResponseJSON).

origin

A web origin tuple — scheme, host, and port — as observed by the user agent and serialized into clientDataJSON.origin. It is set by the user agent and cannot be forged by script. An origin is not a client_id, and the two MUST NOT be compared as strings ().

client_id

A Solid-OIDC Client ID Document URI (an HTTPS URI), e.g. https://app.example/clientid.jsonld [[SOLID-OIDC]]. It identifies the Application.

allowed-origin set

The set of origins from which an assertion is accepted for a given client_id, derived per .

assertion bundle

The versioned envelope around a WebAuthn assertion, carried as the [[RFC8693]] subject_token ().

canonical base64url

The unpadded base64url encoding of [[RFC4648]] §5 (as used throughout [[WEBAUTHN-3]]), with the additional property that the string is the unique encoding of its byte content: its length modulo 4 is never 1, and any unused low-order bits of the final character are zero — equivalently, decoding then re-encoding the string yields the identical string. See .

per-client RP ID

The WebAuthn RP ID an OP expects for a given client_id: the lowercased host of the Client ID Document URI, with no port ().

The per-client RP ID and origin model

Each Application is its own WebAuthn Relying Party.

The OpenID Provider MUST derive the expected WebAuthn RP ID per request from the authenticated client_id: the lowercased host of the Client ID Document URI, with no port. It MUST do so consistently at registration (), at assertion-options (), and at verification (). It MUST NOT substitute a single deployment-wide RP ID when a host is derivable from the client_id (always the case for a valid http(s) URI). A deployment-wide RP ID MAY be configured as a fallback used only when no host is derivable.

The OpenID Provider MUST compute the allowed-origin set for a client_id as exactly the single normalised origin of the client_id URI. Normalisation lowercases the scheme and host, elides the default port for the scheme, and discards any path, query, or fragment. Origins declared inside the Client ID Document are out of scope for this version and MUST NOT be added to the allowed-origin set (they require a proof-of-control mechanism deferred to a future profile; see ).

The OpenID Provider MUST verify, at registration and at every assertion, that clientDataJSON.origin (after the same normalisation) is a member of the allowed-origin set for the authenticated client_id. It MUST NOT compare clientDataJSON.origin to the client_id as a string. This check is the phishing-resistance gate.

Because the verifier asserts rpIdHash == SHA-256(expected RP ID) and the expected RP ID is derived from the authenticated client_id, the triple ⟨signed rpIdHash, the registered credential's client_id, the authenticated client_id⟩ is a checked invariant: an assertion whose rpIdHash is for a host other than the authenticated client's fails verification. This is what lets one OP serve multiple applications without the origin check being the sole per-app discriminator ([[SOLID-WEBAUTHN-ARCH]] §8.2).

Registration

Registration binds a passkey to a ⟨Application, device⟩ pair and stores its public key at the OpenID Provider. It runs over two authenticated endpoints, reached after a normal Solid-OIDC login; in the reference implementation [[CSS-WEBAUTHN]] they are POST /.account/account/<id>/webauthn/register-options and POST /.account/account/<id>/webauthn/register. The endpoint paths are not normative; their behaviour is.

The assertion-options endpoint

The OpenID Provider MUST expose an assertion-options endpoint that returns WebAuthn PublicKeyCredentialRequestOptions (JSON serialization) for the redirect-free re-authentication ceremony. In the reference implementations the conventional location is POST <issuer>/.oidc/webauthn/assertion-options; the path is not normative and MAY be deployment-configured, but the conventional default aids interoperability with clients that discover nothing.

This endpoint:

• MUST accept POST (issuing a single-use challenge is a state-changing, non-cacheable operation). It MUST reject other methods with HTTP 405 (Allow: POST). An OP MAY additionally expose the challenge as a safe GET read where its challenge issuance is genuinely side-effect-free.
• is unauthenticated and cross-origin (the Application's origin differs from the OP's). It is therefore a discoverable-credential ceremony: the request body is empty and the returned allowCredentials MUST be empty. The authenticator selects a resident passkey, and the verifier resolves the ⟨WebID, client_id⟩ from the presented credentialId at the token exchange ().
• MUST return a fresh, single-use challenge, recorded as outstanding per . Two calls MUST return distinct challenges.
• MUST set userVerification = "required".
• SHOULD set rpId to the host of the request's Origin header; this value is advisory (the user agent uses it to select the credential), because the verifier re-derives and enforces the per-client RP ID at the token exchange (req-rpid-per-client).

Because this challenge is issued before any client or WebID is authenticated, it is issued unbound; single-use consumption () together with the per-client RP ID, origin, and credential checks at verification are the controls on this path.

CORS. On the registration endpoints (), where the target client_id is known from the authenticated request, cross-origin responses MUST carry CORS headers restricted to that client's allowed-origin set; an OpenID Provider MUST NOT use Access-Control-Allow-Origin: * there. On the assertion-options endpoint no client is identified (the request is unauthenticated and bodyless), so a per-client restriction is not computable: an OP SHOULD restrict Access-Control-Allow-Origin to a configured allowlist or to the union of the allowed-origin sets of clients holding at least one registered credential, and MAY otherwise reflect the request's Origin. Responses from the assertion-options endpoint MUST NOT require or include credentials (cookies or HTTP authentication; Access-Control-Allow-Credentials MUST NOT be true where the allowed origin is reflected).

The challenge is deliberately not a secret: possession of a challenge grants nothing — every security check happens at the token exchange (), and the challenge is single-use (). CORS restriction on the assertion-options endpoint is abuse hygiene (it complements rate limiting), not a security boundary.

The assertion bundle

The re-authentication grant carries the WebAuthn assertion as the [[RFC8693]] subject_token. Its subject_token_type is the URI

urn:solid:token-type:webauthn-assertion

defined by this specification (; [[RFC8693]] §3 permits any URI as a token-type identifier, so no IANA registration is required for this version).

The subject_token value MUST be the unpadded base64url encoding ([[RFC4648]] §5) of the UTF-8 JSON serialization of the assertion bundle, a versioned envelope with exactly these members:

version

A JSON number. This version of the specification defines version 1. An OpenID Provider MUST reject a bundle whose version it does not support ().

credential

The WebAuthn AuthenticationResponseJSON produced by PublicKeyCredential.toJSON() [[WEBAUTHN-3]]: id, rawId, type ("public-key"), and a response object carrying base64url clientDataJSON, authenticatorData, and signature, with an optional userHandle.

Reusing the W3C WebAuthn JSON serialization means user agents and WebAuthn libraries produce and consume the inner credential directly; no bespoke encoding is introduced.

{
  "version": 1,
  "credential": {
    "id": "PfYagP...JOSjA",
    "rawId": "PfYagP...JOSjA",
    "type": "public-key",
    "response": {
      "clientDataJSON": "eyJ0eXBlIjoid2ViYXV0aG4uZ2V0Iiwi...",
      "authenticatorData": "SZYN5YgOjGh0NBcPZHZgW4_krrmihjLHmVzzuoMdl2MdAAAAAA",
      "signature": "MEUCIQ...Dq8Q",
      "userHandle": "b3BhcXVlLXJhbmRvbS1oYW5kbGU"
    }
  }
}

The token exchange profile

Re-authentication is an OAuth 2.0 Token Exchange [[RFC8693]] at the OP's token endpoint (located via OpenID Connect discovery), with:

• grant_type = urn:ietf:params:oauth:grant-type:token-exchange ([[RFC8693]] §2.1);
• subject_token = the encoded assertion bundle ();
• subject_token_type = urn:solid:token-type:webauthn-assertion;
• client_id = the Application's Client ID Document URI, sent as a body parameter (the Application is a public client, token_endpoint_auth_method: none, per [[SOLID-OIDC]]); and
• a DPoP proof [[RFC9449]] in the DPoP header of the request ([[RFC9449]] §5).

The grant MUST require a valid DPoP proof: an OpenID Provider MUST reject an exchange request with no DPoP proof or an invalid one (invalid_dpop_proof / use_dpop_nonce, [[RFC9449]] §12.2; ). This profile issues only sender-constrained tokens; there is no Bearer variant.

The authenticated client_id — established by dereferencing the Client ID Document per [[SOLID-OIDC]] — is the input to all per-client checks in .

OpenID Provider verification requirements

The OpenID Provider MUST verify the relayed assertion in the following order. DPoP-proof validation ([[RFC9449]] §4.3), including any nonce demand, precedes the sequence below — a request failing DPoP MUST NOT consume the challenge (so a use_dpop_nonce retry is possible, req-client-nonce). The challenge MUST then be consumed before any cryptographic check, so that a presented assertion is never replayable even when a later step fails:

1. Decode. Decode the subject_token into an assertion bundle, enforcing the fail-closed structural and canonicality rules of and . A malformed or unsupported-version bundle is invalid_request.
2. Embedding. Reject the assertion unless clientDataJSON.crossOrigin is false or absent and no topOrigin is present, so an assertion produced inside a cross-origin iframe is never accepted.
3. Single-use challenge. Atomically consume the challenge named in clientDataJSON.challenge (); reject if it is unknown, expired, or already consumed.
4. Resolve the credential and WebID. Look up the stored credential record by ⟨authenticated client_id, credentialId⟩ and read its WebID — the OP does not know the user up front; the assertion proves who they are. Reject if no record exists, or if the record is bound to a different client_id.
5. Cryptographic verification per [[WEBAUTHN-3]] §7.2 against the stored COSE credential public key, asserting: the expected challenge; clientDataJSON.origin ∈ the allowed-origin set (req-origin-check); rpIdHash == SHA-256(per-client RP ID) (req-rpid-per-client); User Verification present — the OP MUST reject an assertion whose UV flag is unset; a valid signature over authenticatorData ‖ SHA-256(clientDataJSON); and a signature counter strictly greater than the stored counter where the authenticator reports a non-zero one.
6. Advance state. On success, persist the new signCount so a later replay at the same count is rejected. Where the authenticator reports a non-zero counter that did not advance, the OP SHOULD record a clone-suspicion anomaly. A signCount of 0 throughout is the normal synced-passkey case and is not an anomaly.

On success the OP mints the token per . The OP MUST trust no part of the bundle that is not covered by the WebAuthn signature; the embedding pre-check (step 2) operates on the unverified parse only as a defence-in-depth fast path, since the same bytes are re-authenticated by the signature in step 5.

The challenge lifecycle

A challenge issued by an OpenID Provider MUST be short-lived and single-use. The OP MUST maintain a consumed-challenge record so that the first consumption of a challenge succeeds and every subsequent attempt fails. Consumption MUST be an atomic check-and-consume at the OP deployment boundary: a single-node OP MAY use an in-memory store; a clustered or multi-process OP MUST use a store shared across instances so replays cannot race between instances.

Where the issuing endpoint authenticates the ⟨WebID, client_id⟩ context — the registration ceremony () — the OP MUST bind the challenge to that context at issue and verify the binding on consume, so a challenge minted for one account/application cannot be redeemed for another. The assertion-options challenge () is necessarily issued unbound (no context is authenticated at issue); single-use consumption plus the per-client checks at verification are the controls on that path.

A self-contained signed challenge removes session affinity but not the replay record: a signed challenge alone is replayable until expiry. The consumed-challenge record is required either way ([[SOLID-WEBAUTHN-ARCH]] §8.3).

Credential lifecycle and revocation

An OpenID Provider MUST allow the account owner to list and delete registered credential records over an authenticated account route (in the reference implementation, GET/POST /.account/account/<id>/webauthn/credentials). The listing MUST return non-secret metadata only and MUST NOT return the stored COSE public key. Deleting a credential MUST cause subsequent assertions for that credentialId to fail.

Revocation does not retroactively invalidate already-issued access tokens; the short token lifetime of this flow bounds the post-revocation gap. An OP SHOULD keep this flow's access-token lifetime short, and MAY additionally support OAuth token revocation [[RFC7009]] for immediacy. Recovery from a lost authenticator is the normal Solid-OIDC login followed by re-registration: the passkey is a re-authentication accelerator, never the sole factor.

Resource Server trust

This specification adds no requirement to the Resource Server. The RS↔OP trust relationship is the existing Solid-OIDC solid:oidcIssuer link: the RS accepts the issued DPoP-bound access token because its issuer is authoritative for the WebID — the WebID Profile document contains a matching ?webid solid:oidcIssuer ?iss statement ([[SOLID-OIDC]] §6.1) — exactly as for a token obtained by the interactive flow. A Resource Server MUST NOT need any WebAuthn awareness.

Error responses

Failures map to OAuth token-endpoint errors [[RFC6749]] [[RFC8693]] [[RFC9449]]. To deny an enumeration oracle, every assertion-validation failure — unknown credential, origin not allowed, bad signature, signCount regression, UV absent, embedded context, per-client RP-ID mismatch, client-binding mismatch, and challenge unknown/expired/replayed — MUST be returned as a single coarse wire error: invalid_grant with one generic description. The precise reason MUST NOT be exposed on the wire; it MAY be recorded in an audit log ().

Only request-shape errors that are not assertion validation keep a distinct code:

Relationship to RFC 8693 §2.2.2. RFC 8693 directs that when a subject_token is "invalid for any reason" the error MUST be invalid_request. This profile deliberately distinguishes a token that is malformed as a request artefact (invalid_request — re-encode and resend) from an assertion that is well-formed but fails validation as a grant (invalid_grant — re-run the ceremony with a fresh challenge), matching RFC 6749 §5.2's invalid_grant semantics and giving clients an actionable recovery signal while keeping the validation-failure reason coarse. This divergence is flagged for Community Group review (); the reference implementations implement the table above.

The registration, assertion-options, and token endpoints SHOULD be rate-limited; an over-limit request SHOULD be answered with HTTP 429.

Security considerations

This section maps the threat model to the normative requirements that mitigate each threat; the full STRIDE / LINDDUN / attack-tree treatment is in [[SOLID-WEBAUTHN-ARCH]] §9, which this section references rather than restates. The five headline threats below are the reference implementation's threat model ([[REAUTH-IMPL]] DESIGN.md §4); three further considerations follow.

Privacy considerations

This section is non-normative except where it restates requirements defined above.

• No new cross-application correlator. A passkey is scoped per ⟨user, application-origin⟩; the mechanism introduces no identifier that links a user across applications beyond the WebID the user already presents. The OP learns ⟨WebID, client_id⟩ per re-authentication — exactly what it already learns in the interactive Solid-OIDC flow.
• Non-derivable user handle. The WebAuthn user handle is a random per-account value (req-user-handle). A deterministic handle such as SHA-256(WebID) would let any party holding an assertion offline-confirm a WebID guess — an offline-confirmable cross-application correlator — and is prohibited. The userHandle relayed inside the assertion bundle therefore reveals nothing about the WebID to intermediaries.
• Log minimisation. Audit logs record hash-truncated identifiers rather than full WebIDs, credential ids, or challenges; the coarse wire error keeps precise failure reasons off the wire (req-coarse-error).
• No secrets in the bundle. The assertion bundle contains no long-lived secret: signatures, identifiers, and public data only. Its interception (already prevented by TLS) would not enable replay, because the embedded challenge is single-use.
• Attestation. Attestation conveyance of none is acceptable (), so the OP does not learn — and is not encouraged to demand — the authenticator's make and model, avoiding a device-fingerprinting vector.
• Non-repudiation. Authentication events are attributable by design; this is the intended behaviour of an authentication protocol, not an incidental leak.

Registrations

This section records the identifiers this specification defines, in the style of the IANA OAuth registries. No IANA registration is made for this version: the identifiers live under urn:solid:, and [[RFC8693]] §3 permits any URI as a token-type identifier ("Other URIs MAY be used to indicate other token types"). If the mechanism generalises beyond Solid, a future profile MAY register an urn:ietf:params:oauth:token-type:webauthn-assertion in the IANA "OAuth URI" registry via a thin IETF Internet-Draft ().