Describe Client Authentication with Automatic Registration

[selfissued]

Fixes #147

[jogu]

Initially I thought this was sufficient, but Tim's comment ( #147 (comment) ) has caused me to re-consider.

https://github.com/openid/rp-metadata-choices doesn't define multi-values-capable entries for revocation_endpoint_auth_methods_supported or introspection_endpoint_auth_methods_supported. I think we need to either:

1. Define these, or:
2. Make clear that the token endpoint auth methods is used for all endpoints

[selfissued]

@jogu, does openid/rp-metadata-choices#7 do the trick so that you can approve this PR?

[panva]

https://github.com/openid/rp-metadata-choices doesn't define multi-valued-capable client metadata for "this is how i can authenticate at the introspection/revocation/par endpoint" because these would have no single-valued counterpart since clients do in-fact use the same client authentication method for all authenticated endpoints and refer back to the original authenticated endpoint - the token endpoint, ergo token_endpoint_auth_method (single-valued) and token_endpoint_auth_methods_supported (multi-valued from rp-metadata-choices).

The inclusion of revocation_endpoint_auth_methods_supported and introspection_endpoint_auth_methods_supported in AS Metadata (RFC8414) remains a mystery to me but I do recall a distant conversation with @b---c that we shall not be registering any more of those endpoint-specific AS metadata for new endpoints. PAR, CIBA, Device Authorization Grant in fact all state the client authenticates in the same manner as for the token endpoint.

I think we need to either:

1. Define these, or:
2. Make clear that the token endpoint auth methods is used for all endpoints

2. is right, we do not have a general client data model that supports the client having different auth methods at different endpoints. We do not need one. And I would even go as far as to say the concern of a client out of the blue using different auth methods for different endpoints is largely theoretical, not practical.

[rohe]

It would be interesting to know if the OIDC test suite allows a client to use different client authentication methods at different endpoints. The OIDC standard allows it and therefor the test suite should be able to support it.

[bc-pi]

The inclusion of revocation_endpoint_auth_methods_supported and introspection_endpoint_auth_methods_supported in AS Metadata (RFC8414) remains a mystery to me

Same but it shouldn't be a mystery that it was a mistake.

but I do recall a distant conversation with @b---c that we shall not be registering any more of those endpoint-specific AS metadata for new endpoints. PAR, CIBA, Device Authorization Grant in fact all state the client authenticates in the same manner as for the token endpoint.

I recall this conversation similarly.

I think we need to either:

1. Define these, or:

Absolutely not.

2. Make clear that the token endpoint auth methods is used for all endpoints

2. is right, we do not have a general client data model that supports the client having different auth methods at different endpoints. We do not need one. And I would even go as far as to say the concern of a client out of the blue using different auth methods for different endpoints is largely theoretical, not practical.

Agree that 2 is right.

[selfissued]

I will update the PR to apply choice 2 above.

[jogu]

It would be interesting to know if the OIDC test suite allows a client to use different client authentication methods at different endpoints. The OIDC standard allows it and therefor the test suite should be able to support it.

The test suite doesn't allow for it, and I don't believe the OIDC standard allows it at the endpoints that are in scope for / tested by the test suite. (I'm not sure I understand how the question is relevant to the issue described in #147.)

[selfissued]

@jogu, in light of openid/rp-metadata-choices#8 and the clarification to use token_endpoint_auth_methods_supported for all AS endpoints, can you please re-review and consider approving? Thanks.