Closed Sakurann closed 1 week ago
My understanding is the following:
client_id
to the sub
claim.client_id
to the iss
claimclient_id
Thus, requests against the token and/or PAR endpoint don't need the client_id
parameter.
In addition, the same seems true, for the request to the authorization endpoint that follows after PAR.
In conclusion, I have the impression that client_id
is not needed in the above cases.
Should authorization server reject a with a client_id different that the one extracted from the attestation? Perhaps, server could just ignore the parameter and keep the attestation, yet I feel that this is not in the scope of the VCI
An update:
I missed the case where PAR is placed using a signed object.
It seems that client_id
should be present, according to https://www.rfc-editor.org/rfc/rfc9126.html#name-the-request-request-paramet that I think has its origin to https://www.rfc-editor.org/rfc/rfc9101.html#name-authorization-request
PS: I find this very puzzling. It would have been easier - from the wallet perspective - to just always send the client_id
parameter
@babisRoutis :
I missed the case where PAR is placed using a signed object.
It seems that
client_id
should be present, according to https://www.rfc-editor.org/rfc/rfc9126.html#name-the-request-request-paramet that I think has its origin to https://www.rfc-editor.org/rfc/rfc9101.html#name-authorization-request
I believe that client_id
supplied at the PAR endpoint when using a signed request object is only required when using a client authentication method that requires client_id to be passed in the request body - see this text in https://www.rfc-editor.org/rfc/rfc9126.html#name-the-request-request-paramet :
Request parameters required by a given client authentication method are included in the application/x-www-form-urlencoded request directly and are the only parameters other than request in the form body (e.g., mutual TLS client authentication [RFC8705] uses the client_id HTTP request parameter, while JWT assertion-based client authentication [RFC7523] uses client_assertion and client_assertion_type)
PS: I find this very puzzling. It would have been easier - from the wallet perspective - to just always send the client_id parameter
As per https://www.rfc-editor.org/rfc/rfc6749#section-3.2.1 the wallet 'MAY' always send client_id, even if it is not required.
The logic is basically that there is no need for the client to send client_id if it's (say) using private_key_jwt (where the client id is already in the assertion) or client_secret_basic (where the client id is in the HTTP Authorization header).
@Sakurann :
IETF client attestation draft is not clear, but also it is probably out of scope of that draft..
That draft is an OAuth client authentication method, so as per the above it is in that document's scope to say whether client_id is required or not.
I would say that as:
then client_id is not required when using client attestations to authenticate the client.
As per https://www.rfc-editor.org/rfc/rfc6749#section-3.2.1 the wallet 'MAY' always send client_id, even if it is not required.
The logic is basically that there is no need for the client to send client_id if it's (say) using private_key_jwt (where the client id is already in the assertion) or client_secret_basic (where the client id is in the HTTP Authorization header).
Hi @jogu thanks for your reply, and especially for the above hint :smile:
@Sakurann can we close this given the above responses and that you've opened https://github.com/oauth-wg/draft-ietf-oauth-attestation-based-client-auth/issues/81 now?
IETF client attestation draft is not clear, but also it is probably out of scope of that draft..