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 is also the value of the Client Identifier. In this case, the Authorization Request MUST NOT be signed, the Verifier MAY omit the redirect_uri Authorization Request parameter, and all Verifier metadata parameters MUST be passed using the client_metadata or client_metadata_uri parameter.

This scheme allows the Verifier to authenticate using a JWT that is bound to a certain public key. When the 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 or the client_metadata_uri 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 name 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.