In yesterday's discussion, "authentication" was used interchangeably for "Reader Auth" and "Verifier Auth" while covering at least four distinct concerns. If we don't identify and name these separately, we risk designing a single mechanism that over-solves some use cases, under-solves others, and makes it hard to evaluate proposals against the requirement they actually target.
The four concerns
1. Verifier Identification (Verifier ID)
A set of metadata, signed by a party the credential manager trusts, that can be rendered to the user at request time (by the platform in the selector or the credential manager, or both). Elements like:
- RP Organization legal name
- RP Doing-business-as name
- RP Machine readable organizational identifier (GLUE ID)
- Verifier Organization legal name (if different than RP)
- Verifier Doing-business-as name (if different than RP)
- Verifier Machine readable organizational identifier (GLUE ID) (if different than RP)
- Privacy policy
- Terms of use
- Logo
- maybe more...
This is about informed user consent. It does not require the credential manager to cryptographically verify that the party presenting this metadata is entitled to it beyond trusting the signer of the metadata itself. Many, maybe most, use cases need only this.
This is what FIDO Alliance is working to define, in a WebPKI-like manner (think OV). Roles like Verifier Registrar, Delegated Verifier Registrar, and Verifier Services are supported in this architecture.
2. Verifier Authentication
Some credential managers (and issuers via the CM) need to authenticate the requestor before authorizing the request. This is proof-of-possession of a key bound to an identity, verified against a trust framework. It is a stronger requirement than Identification and may carry a different trust anchor, revocation, and key management implications.
3. Verifier Authorization
A distinct class of use cases performs authorization decisions based on an identifier, carried either in the request itself or derived from the verifier / reader auth identity. Examples: is this verifier registered, is it entitled to request this credential type or these claims, does policy permit this transaction. Authorization consumes the outputs of (1) or (2) but is a separate function with its own policy sources (trust lists, registration certificates, entitlement attestations).
4. Request Integrity / Protocol Security
Nearly all scenarios need signed requests to secure the protocol exchange itself:
- Binding keys for encrypted responses to the request
- Signing over expected origins for cross-device flows
- Replay and tamper protection of request parameters
Critically, this is not specifically Verifier ID, Verifier/Reader Authentication, or Authorization. A signed request protects the exchange even when the signer's identity is unverified or irrelevant. Conflating request signing with "verifier authentication" or "reader authentication" is where much of the terminology confusion originates.
Why this matters for the harmonized protocol
Some of this topic is out of scope for the protocol spec itself. But it has a heavy impact across the ecosystem, including other layers of the stack where the protocol is carried/used. As we ideate, every proposal should state which of the four it addresses or relates to. "Verifier auth" as a catch-all makes it impossible to compare proposals or detect gaps.
Different requirements, different mechanisms.
A solution optimized for Authentication (e.g., mandatory X.509 chains to a trust anchor) imposes unnecessary cost on the majority of flows that only need Identification. A solution optimized for Identification provides false assurance if deployed where Authentication is the actual requirement.
Different trust anchors and lifecycles.
The signer of display metadata, the CA attesting verifier identity, and the registrar issuing entitlements can all be different parties with different revocation and rotation properties. Should they be?
Different failure modes and UX.
Failed Identification means degraded consent UI. Failed Authentication means request rejection. Failed Authorization means policy denial. Failed request integrity means a protocol-level security break. These should not share one error surface or one requirement label.
In yesterday's discussion, "authentication" was used interchangeably for "Reader Auth" and "Verifier Auth" while covering at least four distinct concerns. If we don't identify and name these separately, we risk designing a single mechanism that over-solves some use cases, under-solves others, and makes it hard to evaluate proposals against the requirement they actually target.
The four concerns
1. Verifier Identification (Verifier ID)
A set of metadata, signed by a party the credential manager trusts, that can be rendered to the user at request time (by the platform in the selector or the credential manager, or both). Elements like:
This is about informed user consent. It does not require the credential manager to cryptographically verify that the party presenting this metadata is entitled to it beyond trusting the signer of the metadata itself. Many, maybe most, use cases need only this.
This is what FIDO Alliance is working to define, in a WebPKI-like manner (think OV). Roles like Verifier Registrar, Delegated Verifier Registrar, and Verifier Services are supported in this architecture.
2. Verifier Authentication
Some credential managers (and issuers via the CM) need to authenticate the requestor before authorizing the request. This is proof-of-possession of a key bound to an identity, verified against a trust framework. It is a stronger requirement than Identification and may carry a different trust anchor, revocation, and key management implications.
3. Verifier Authorization
A distinct class of use cases performs authorization decisions based on an identifier, carried either in the request itself or derived from the verifier / reader auth identity. Examples: is this verifier registered, is it entitled to request this credential type or these claims, does policy permit this transaction. Authorization consumes the outputs of (1) or (2) but is a separate function with its own policy sources (trust lists, registration certificates, entitlement attestations).
4. Request Integrity / Protocol Security
Nearly all scenarios need signed requests to secure the protocol exchange itself:
Critically, this is not specifically Verifier ID, Verifier/Reader Authentication, or Authorization. A signed request protects the exchange even when the signer's identity is unverified or irrelevant. Conflating request signing with "verifier authentication" or "reader authentication" is where much of the terminology confusion originates.
Why this matters for the harmonized protocol
Some of this topic is out of scope for the protocol spec itself. But it has a heavy impact across the ecosystem, including other layers of the stack where the protocol is carried/used. As we ideate, every proposal should state which of the four it addresses or relates to. "Verifier auth" as a catch-all makes it impossible to compare proposals or detect gaps.
Different requirements, different mechanisms.
A solution optimized for Authentication (e.g., mandatory X.509 chains to a trust anchor) imposes unnecessary cost on the majority of flows that only need Identification. A solution optimized for Identification provides false assurance if deployed where Authentication is the actual requirement.
Different trust anchors and lifecycles.
The signer of display metadata, the CA attesting verifier identity, and the registrar issuing entitlements can all be different parties with different revocation and rotation properties. Should they be?
Different failure modes and UX.
Failed Identification means degraded consent UI. Failed Authentication means request rejection. Failed Authorization means policy denial. Failed request integrity means a protocol-level security break. These should not share one error surface or one requirement label.