Verification Offer

Context

Purpose of this document is to enhance current User Authentication capabilities with hybrid approaches like classical OIDC, SIOPv2, and VP Exchange. The aim is to re-use existing protocols and patterns.

Generic communication pattern

OpenID4VCI uses Credential Offer, where Issuer initiates Cross- or Same-device request for a credential. This allows the Holder Wallet to stay in control of proceeding or not, whitelisting Issuers and to do background validations & configuration through /.well-known discovery. The main benefit of the offer is to allow the Issuer to introduce itself, and to allow Wallet to initiate the underlying sequence. Wallets have the possibility to use client_metadata in the initial Authorisation Request and to have full control on how the Authorisation Request should be built.

OpenID4VP could use the same pattern, Verification Offer, where the Verifier initiates Cross- or Same-device request for a verification, with equal benefits.

Verification Offer

The new Verification Offer must contain the verifier's client_id. Verification Offer should contain information of the possible authentication schemes, including classical OIDC, ID Token and VP Exchange, and it should also contain the required scopes and possibly optional scopes. Optionally, the VP Token section could contain supported VC types, this could also be defined in the /.well-known configuration.

Wallet must be able to respond through the initial Authorisation Request's client_metadata if they support the possible authentication schemes or not, for example not all End-Users might want to use classical OIDC, which then informs the Authorisation Server to go with a credential which could be used in-place of it.

Well-known metadata

The Verifier should expose ./well-known/openid-verifier. If Issuer is acting as a Verifier, it will also contain the configuration next to /.well-known/openid-credential-issue. Depending on the used Client Identifier Scheme, the ./well-known configuration may be located through client_id. Verifier may also deliver the metadata in Verification Offer, through client_metadata or through client_metadata_uri property.

If Verifier is not an Authorisation Server, then the Verifier must expose authorization_server in the configuration (just like in the Issuer's case).

Flow

1. Verifier starts by creating Verification Offer, specific to their need.
2. Holder Wallet receives Verification Offer (redirect or QR Code)
3. Holder Wallet reads /.well-known configuration and optionally AS configuration
4. Holder Wallet optionally requests a consent from End-User, and possible scope extensions
5. Holder Wallet sends /authorize request into designated AS, with client_metadata describing Wallet capabilities.
6. AS redirects back, either classic OIDC redirection, Authorisation Request with response_type=id_token or response_type=vp_token, where both also contains the response_mode=direct_post
7. Holder Wallet will create the direct post response accordingly, or follow redirect for classical OIDC.
8. After one to many authentications are completed, the AS should return to the initial response_type. In case of code, it will return redirect into RP with code.

To allow device specific redirections, the Verifier should always use Signed Request Object as request or request_uri, which can also be achieved with JAR.

Verifying the verifier

Verifier may own credentials in any public place, for example in /.well-known/verifiable-credentials/xyz-jwt or in public Credential Registry, the credentials should be referenced in the verifier's /.well-known/openid-verifier configuration.

Each Verifiable Credential should be issued for the client_id, which are automatically proven through TLS if the client_id equals to prefix of /.well-known endpoint. In other cases, the Verification Offer should be signed as JWT with keys located through Client Identifier Scheme.

Benefits

• Verifier can work with 3-legged models.
• ID Token, VP Token and/or classical OIDC can be used for the authentication
• Builds on top of existing protocol and patterns
• SIOP can be used as 2FA in normal OIDC
• Enables Decentralised Access Management through VCs which holds proofs of access

Known issues

openid-credential-offer:// is very specific for VCI, while Verification Offer would introduce another endpoint (openid-verification-offer://). On End-User devices, the End-User may bind the two endpoints to different applications, which may incur support tickets and general confusion, thus it would be better to unify these two endpoints into a single one openid-offer://.