OpenID4VCI: client identification and authentication at the token endpoint

[Takahiko Kawasaki]

From Section 6.1. Token Request of the draft 11 of “OpenID for Verifiable Credential Issuance”.

Requirements around how the Wallet identifies and, if applicable, authenticates itself with the Authorization Server in the Token Request depends on the Grant Type.

For the Authorization Code Grant Type, the requirement as described in Sections 4.1.3 and 3.2.1 of [RFC6749] MUST be followed.

For the Pre-Authorized Code Grant Type, authentication of the client is OPTIONAL, as described in Section 3.2.1 of OAuth 2.0 [RFC6749] and consequently, the "client_id" is only needed when a form of Client Authentication that relies on the parameter is used.

The description in the above paragraphs about wallet (client) identification and authentication at the token endpoint is inappropriate.

Wallet (client) identification and authentication should depend on “client type” (RFC 6749 Section 2.1) and “client authentication method” (“token_endpoint_auth_method” client metadata), not on “grant type”.

When the client type of the wallet (client) making a token request is “public” (RFC 6749 Section 2.1), the client_id request parameter is only needed.

On the other hand, when the client type of the wallet (client) making a token request is “confidential” (RFC 6749 Section 2.1), necessary parameters for client identification and authentication vary depending on the client authentication method.

client authentication method	identification	necessary parameters
client_secret_basic	The client ID encoded in the Authorization HTTP header	The Authorization HTTP header
client_secret_post	The client_id request parameter	The client_id request parameter and the client_secret request parameter
client_secret_jwt	The iss claim and the sub claim in the client assertion	The client_assertion request parameter and the client_assertion_type request parameter
private_key_jwt	The iss claim and the sub claim in the client assertion	The client_assertion request parameter and the client_assertion_type request parameter
tls_client_auth	The client_id request parameter	The client_id request parameter and an X.509 certificate of the client
self_signed_tls_client_auth	The client_id request parameter	The client_id request parameter and an X.509 certificate (self-signed) of the client

The paragraphs in Section 6.1 should be rephrased.

‌

cf. “OAuth 2.0 Client Authentication”

[Brian Campbell]

Generally agree with Taka but do want to note that OAuth does allow for client identification/authentication to be omitted in extension grants. That admittedly might be somewhat ambiguous or open to different interpretations but that was my reading and it has been codified in RFCs 7521, 7522 & 7523 for SAML and JWT assertion grants. And allowing for unidentified clients in pre-authorized code grant seems to similarly make sense. The text you quote could maybe be improved or clarified but I think keeping pre-authorized code grant able to omit client identification is needed.

‌

[Kristina Yasuda]

I would suggest the following:

Requirements around how the Wallet identifies and, if applicable, authenticates itself with the Authorization Server in the Token Request depends on the Grant Type.

Update this sentence to say “depends on client type (RFC 6749 Section 2.1) and client authentication method (“token_endpoint_auth_method” client metadata)“.

For the Authorization Code Grant Type, the requirement as described in Sections 4.1.3 and 3.2.1 of [RFC6749] MUST be followed.

For the Pre-Authorized Code Grant Type, authentication of the client is OPTIONAL, as described in Section 3.2.1 of OAuth 2.0 [RFC6749] and consequently, the "client_id" is only needed when a form of Client Authentication that relies on the parameter is used.

keep this text.

[Kristina Yasuda]

SIOP call

For the Pre-Authorized Code Grant Type, authentication of the client is OPTIONAL, as described in Section 3.2.1 of OAuth 2.0 [RFC6749] and consequently, the "client_id" is only needed when a form of Client Authentication that relies on the parameter is used.

try paraphrase that client authn not necessary at the token endpoint….

[Kristina Yasuda]

look at JWT authorization grant and token exchange

[Brian Campbell]

FWIW I just filed an issue for OAuth 2.1 https://github.com/oauth-wg/oauth-v2-1/issues/143 related to and mentioning this.

‌

‌

[Michael Jones]

Kristina to create a PR

[Kristina Yasuda]

PR #534

[Kristina Yasuda]

PR merged