OpenID4VCI: client identification and authentication at the token endpoint
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.
Comments (9)
-
-
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.
-
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….
-
look at JWT authorization grant and token exchange
-
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.
-
- changed status to open
-
Kristina to create a PR
-
-
- changed status to resolved
PR merged
- Log in to comment
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.