How to indicate certain credential configurations need oauth client attestation?

[awoie]

Perhaps this issue should be filed in a different repository.

Two questions:

• Should we define a mechanism that some of the credential configurations require oauth client attestation while others may not?
• Would it make sense to define a token endpoint auth method for oauth client attestation to indicate oauth client auth is supported, e.g., by including it in the token_endpoint_auth_methods_supported metadata?

[paulbastian]

The latter already exists, but I think there is no possible way to communicate so for a particular credential configuration.

[awoie]

Is it a possibility that some configurations might need an attestation, others don't?

[paulbastian]

The same applies to PKCE, Dpop and so on?

[procivisAG]

Hello

We'd like to revive this discussion getting hopefully some clarification on this issue as it seems still unclear to us:

In particluar, we'd like to know the intention when using the Pre-Authorized Code Grant Type without a client_id:

• The client_id is then optional as per section 6.1:

  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 parameter is only needed when a form of Client Authentication that relies on this parameter is used.

• And just above that:

  Requirements around how the Wallet identifies and, if applicable, authenticates itself with the Authorization Server in the Token Request depend on the Client type defined in Section 2.1 of [RFC6749] and the Client authentication method indicated in the token_endpoint_auth_method Client metadata (as defined in [RFC7591]). The requirements specified in Sections 4.1.3 and 3.2.1 of [RFC6749] MUST be followed.

So if an authorization server wants to offer credentials using the Pre-Authorized Code Grant Type but also require client / wallet attestation (which the server will then check against some trust list), how should it communicate the need for attestation to that anonymous client? And conversely how does the wallet obtain the information that client attestation is required?

Section 12.1.1 seems quite unhelpful in that regard:

How to obtain Client Metadata is out of scope of this specification.

Also, why must that information be taken from the client metadata? Would it not be much easier if the need for client attestation was simply stated in the OAuth 2.0 Authorization Server metadata using the token_endpoint_auth_methods_supported property? Is there a specific reasone why the OAuth 2.0 Authorization Server metadata was not used?

---

In general, standardizing how / if a client_id id is obtained would be very helpful. I.e. either mandating dynamic client registration or make it an explicit requirement to have them assigned by the trust infrastructure (or preferably some lighter process).