Client metadata ?

[babisRoutis]

If I am not mistaken, the specifications defines some extensions to Authorization Server Metadata, but related client metadata are not defined.

Can you please consider extensions for the Client metadata as well?

1. For the signing algorithm(s) supported for signing Client Attestation JWT
2. For the signing algorithm(s) supported for signing Client Attestation PoP JWT
3. Whether client requires challenge_endpoint

There is token_endpoint_auth_signing_alg but I think that this is for other authentication methods

[c2bo]

I don't really see how client metadata helps given the current scope of the draft (which is purely the client <-> AS/RS part). Client metadata would be more relevant for the issuance of client attestations, wouldn't it? Everything we need for AS <-> client should be covered by AS metadata imho.

Would you be up for a quick call on this @babisRoutis, so we can better understand your perspective?

[babisRoutis]

Hi @c2bo

Of course, we can have a quick call

Until then, I will try to better describe the intention of my request.

The AS metadata have two attribute to describe the client authentication method supported by the AS:

• token_endpoint_auth_methods_supported,
• token_endpoint_auth_signing_alg_values_supported

ABCA defines the value attest_jwt_client_auth for the token_endpoint_auth_methods_supported, but it cannot use token_endpoint_auth_signing_alg_values_supported because ABCA has to advertise algs for both the Client Att. JWT and its PoP.
I guess that this is the reason, why ABCA defined :

• client_attestation_signing_alg_values_supported and
• client_attestation_pop_signing_alg_values_supported

Now, Client Metadata already may contain

• token_endpoint_auth_method (as defined in RFC7591)
• token_endpoint_auth_signing_alg (as defined in OIDC Dynamic Client Registration)

I was wondering whether we could add in a similar way to the client metadata two attributes for the alg supported by the client for the client attestation and its PoP.

I am not interested for the Dynamic Registration use case per se.
Rather I think that a wallet acting as a OAUTH2 Client has to figure out whether it can interoperate with the AS. This involves checking the AS metadata against the Client Metadata. Borrowing 😄 a line from FAPI to justify my request

The metadata defined by [RFC7591], and registered extensions to it, also imply a general data model for clients that is useful for authorization server implementations even when the dynamic client registration protocol isn't in play

Finally, It is not uncommon when a specification defines extensions to AS metadata to define extensions to Client Metadata (or even to Protected Resource Metadata). Some examples: DPoP, JAR, JARM, OpenId4VCI