CIBA: Metadata for client auth at backchannel endpoint

[Dave Tonge]

From Takahiko Kawasaki

I'd like to suggest two OpenID Provider Metadata regarding client authentication method at the backchannel authentication endpoint.

backchannel_authentication_endpoint_auth_methods_supported - Client authentication methods supported at the backchannel authentication endpoint.

backchannel_authentication_endpoint_auth_signing_alg_values_supported - Supported signature algorithms of JWT used for client authentication at the backchannel authentication endpoint. For example, for private_key_jwt.

[Dave Tonge]

I think the idea was that token_endpoint_auth_methods_supported should be sufficient. Is there a use case for allowing a different set of auth methods for the token endpoint and the backchannel authentication endpoint?

[Takahiko Kawasaki]

The reason I suggested the metadata was not for real use cases but for consistency with RFC 8414 (OAuth 2.0 Authorization Server Metadata). RFC 8414 includes the following metadata.

Token Endpoint

• token_endpoint_auth_methods_supported
• token_endpoint_auth_signing_alg_values_supported

Introspection Endpoint

• introspection_endpoint_auth_methods_supported
• introspection_endpoint_auth_signing_alg_values_supported

Revocation Endpoint

• revocation_endpoint_auth_methods_supported
• revocation_endpoint_auth_signing_alg_values_supported

From an implementer's viewpoint, I felt the following would be natural.

Backchannel Authentication Endpoint

• backchannel_authentication_endpoint_auth_methods_supported
• backchannel_authentication_endpoint_auth_signing_alg_values_supported

If there existed generic-purpose metadata like client_auth_methods_supported and client_auth_signing_alg_values_supported, I would not have had suggested the new metadata.

[Takahiko Kawasaki]

But, if the specification explicitly states something like "The same client authentication method should be used at the backchannel authentication endpoint as at the token endpoint", the proposed new metadata won't be necessary.

[Takahiko Kawasaki]

If the token delivery mode is "push", the client does not access the token endpoint. In this case, it may sound strange to require "the client authentication method at the backchannel authentication endpoint should be the same as that at the token endpoint." But others may feel differently.

[Brian Campbell]

There's some historical weirdness to how client authentication has come to be represented (and named) in metadata. Client registration metadata has only a token_endpoint_auth_method, which despite the name has become the de facto place in the client data model to say how the client will authenticate to the AS when making any direct client -> AS call. The parameter name is a bit unfortunate but I believe it makes sense to have a single (backchannel) authentication method per client. RFC 8414 took a different direction and has revocation_endpoint_auth_methods_supported and introspection_endpoint_auth_methods_supported etc., which I believe was a mistake. I don't see a clear use case for needing or allowing a different set of auth methods for the different endpoints. And having a bunch of _supported parameters for different endpoints seems likely to clutter up the metadata document with a bunch of redundant info.

I'd propose that some text be added into CIBA core that says that, for the backchannel authentication endpoint, the AS supports the same client authentication methods as indicated with token_endpoint_auth_methods_supported. And state that, for a client, the token_endpoint_auth_method is the authentication method registered for its client_id regardless of the endpoint being called.

[Dave Tonge]

I agree with your suggestion Brian.

[Brian Campbell]

to address this, pull request #32 has basically the changes previously proposed

[Brian Campbell]

merged pull request #32 with text added into CIBA’s metadata section that says that, for the backchannel authentication endpoint, the AS supports the same client authentication methods as indicated with token_endpoint_auth_methods_supported. And that, for a client, the token_endpoint_auth_method is the authentication method registered for its client_id regardless of the endpoint being called.