Re: [OAUTH-WG] Client Authentication Method at Device Authorization Endpoint

[Takahiko Kawasaki <[e-mail]>]

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 <[e-mail]>:

> 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 <[e-mail]>:
>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>