- edited description
CIBA: Metadata for client auth at backchannel endpoint
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.
Comments (11)
-
reporter -
reporter 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? -
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
andclient_auth_signing_alg_values_supported
, I would not have had suggested the new metadata. -
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.
-
- changed milestone to CIBA Implementer's Draft
-
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.
-
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 hasrevocation_endpoint_auth_methods_supported
andintrospection_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, thetoken_endpoint_auth_method
is the authentication method registered for its client_id regardless of the endpoint being called. -
-
assigned issue to
-
assigned issue to
-
reporter I agree with your suggestion Brian.
-
to address this, pull request #32 has basically the changes previously proposed
-
- changed status to resolved
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.
- Log in to comment