ClientIdScheme

This value indicates that the Client Identifier is a DID defined in DID-Core. The request MUST be signed with a private key associated with the DID. A public key to verify the signature MUST be obtained from the verificationMethod property of a DID Document. Since DID Document may include multiple public keys, a particular public key used to sign the request in question MUST be identified by the kid in the JOSE Header. To obtain the DID Document, the Wallet MUST use DID Resolution defined by the DID method used by the Verifier. All Verifier metadata other than the public key MUST be obtained from the client_metadata or the client_metadata_uri parameter.

This value indicates that the Client Identifier is an Entity Identifier defined in OpenID Connect Federation. Processing rules given in OpenID.Federation MUST be followed. Automatic Registration as defined in OpenID.Federation MUST be used. The Authorization Request MAY also contain a trust_chain parameter. The Wallet MUST obtain Verifier metadata only from the Entity Statement(s). The client_metadata or client_metadata_uri parameter MUST NOT be present in the Authorization Request when this Client Identifier scheme is used.

Any not natively supported client id scheme, so it can still be parsed

This value represents the RFC6749 default behavior, i.e., the Client Identifier needs to be known to the Wallet in advance of the Authorization Request. The Verifier metadata is obtained using RFC7591 or through out-of-band mechanisms.

This value indicates that the Verifier's Redirect URI (or Response URI when Response Mode direct_post is used) is also the value of the Client Identifier. The Authorization Request MUST NOT be signed. The Verifier MAY omit the redirect_uri Authorization Request parameter (or response_uri when Response Mode direct_post is used). All Verifier metadata parameters MUST be passed using the client_metadata parameter.

This Client Identifier Scheme allows the Verifier to authenticate using a JWT that is bound to a certain public key. When the Client Identifier Scheme is verifier_attestation, the Client Identifier MUST equal the sub claim value in the Verifier attestation JWT. The request MUST be signed with the private key corresponding to the public key in the cnf claim in the Verifier attestation JWT. This serves as proof of possession of this key. The Verifier attestation JWT MUST be added to the jwt JOSE Header of the request object. The Wallet MUST validate the signature on the Verifier attestation JWT. The iss claim value of the Verifier Attestation JWT MUST identify a party the Wallet trusts for issuing Verifier Attestation JWTs. If the Wallet cannot establish trust, it MUST refuse the request. If the issuer of the Verifier Attestation JWT adds a redirect_uris claim to the attestation, the Wallet MUST ensure the redirect_uri request parameter value exactly matches one of the redirect_uris claim entries. All Verifier metadata other than the public key MUST be obtained from the client_metadata parameter.

When the Client Identifier Scheme is x509_san_dns, the Client Identifier MUST be a DNS name and match a dNSName Subject Alternative Name (SAN) RFC5280 entry in the leaf certificate passed with the request. The request MUST be signed with the private key corresponding to the public key in the leaf X.509 certificate of the certificate chain added to the request in the x5c JOSE header RFC7515 of the signed request object.

When the Client Identifier Scheme is x509_san_uri, the Client Identifier MUST be a URI and match a uniformResourceIdentifier Subject Alternative Name (SAN) RFC5280 entry in the leaf certificate passed with the request. The request MUST be signed with the private key corresponding to the public key in the leaf X.509 certificate of the certificate chain added to the request in the x5c JOSE header RFC7515 of the signed request object. The Wallet MUST validate the signature and the trust chain of the X.509 certificate. All Verifier metadata other than the public key MUST be obtained from the client_metadata parameter. If the Wallet can establish trust in the Client Identifier authenticated through the certificate, e.g. because the Client Identifier is contained in a list of trusted Client Identifiers, it may allow the client to freely choose the redirect_uri value. If not, the redirect_uri value MUST match the Client Identifier.