Is client_id optional in the requests using wallet attestation?

[Sakurann]

IETF client attestation draft is not clear, but also it is probably out of scope of that draft..

[babisRoutis]

My understanding is the following:

• Client attestation JWT (signed by the provider) must have wallet's client_id to the sub claim.
• Client attestation JWT PoP (signed by the wallet) must have wallet's client_id to the iss claim
• Authorization server has to enforce the above rules, and extract the client_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

[babisRoutis]

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

[jogu]

@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:

1. That document does not require client_id to be passed
2. The client_id is already present in the signed jwt (very similar to private_key_jwt)

then client_id is not required when using client attestations to authenticate the client.

[babisRoutis]

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 😄

[jogu]

@Sakurann can we close this given the above responses and that you've opened oauth-wg/draft-ietf-oauth-attestation-based-client-auth#81 now?