Dear Filip, Thank you for your comment. Historically, metadata related to client authentication methods have been defined for each endpoint such as token endpoint, introspection endpoint and revocation endpoint. When defining the CIBA specification, we discussed whether to define a new metadata for client authentication methods for the backchannel authentication endpoint. The final decision is "not define but reuse metadata defined for token endpoint". See Issue 102 "CIBA: Metadata for client auth at backchannel endpoint" <https://bitbucket.org/openid/mobile/issues/102> of MODRNA WG for details. This is the reason the CIBA specification explicitly says as follows:
*The token_endpoint_auth_method indicates the registered authentication method for the client to use when making direct requests to the OP, including requests to both the token endpoint and the backchannel authentication endpoint.* What I'm asking is whether to (1) allow authorization server implementations to auto-detect the client authentication method used by a device authorization request at runtime based on request parameters such as (a) client_id & client_secret (client_secret_post), (b) client_assertion & client_assertion_type (client_secret_jwt or private_key_jwt), (c) Authorization header (client_secret_basic) or (d) a client certificate (tls_client_auth or self_signed_tls_client_auth), or (2) use the pre-configured client authentication method only and reject/ignore other client authentication methods. For the latter case, one more point is whether to (1) define a new metadata that represents the client authentication method at the device authorization endpoint or (2) reuse the existing metadata defined for the token endpoint. Best Regards, Takahiko Kawasaki 2019年6月4日(火) 14:33 Filip Skokan <panva...@gmail.com>: > Hello Takahiko, > > Such language already exists in second to last paragraph of section 3.1. > Like with CIBA the client’s regular token endpoint auth method is used at > the device authorization endpoint. > > > The client authentication requirements of Section 3.2.1 of [RFC6749] > > <https://tools.ietf.org/html/rfc6749#section-3.2.1> > apply to requests on this endpoint, which means that confidential > clients (those that have established client credentials) authenticate > in the same manner as when making requests to the token endpoint, and > public clients provide the "client_id" parameter to identify > themselves. > > > Odesláno z iPhonu > > 4. 6. 2019 v 4:10, Takahiko Kawasaki <t...@authlete.com>: > > Hello, > > Do you have any plan to define a rule as to which client authentication > method should be used at the device authorization endpoint (which is > defined in OAuth 2.0 Device Authorization Grant > <https://datatracker..ietf.org/doc/draft-ietf-oauth-device-flow/?include_text=1> > )? > > Section 4 of CIBA > <https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0.html>, > which has incorporated some ideas/rules/parameters from Device Flow, says > as follows. > > > *The token_endpoint_auth_method indicates the registered authentication > method for the client to use when making direct requests to the OP, > including requests to both the token endpoint and the backchannel > authentication endpoint.* > > This means that a backchannel authentication endpoint in CIBA (which > corresponds to a device authorization endpoint in Device Flow) performs > client authentication using the client authentication method specified by > the token_endpoint_auth_method metadata of the client. > > I'd like to know if you have any plan to explicitly add a description like > above into the specification of OAuth 2.0 Device Authorization Grant. > > Best Regards, > Takahiko Kawasaki > Authlete, Inc. > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
