Subject: [OAUTH-WG] Client authentication in the Device Authorization Request

From: Brian Campbell <[email-masked]>
Date: Mon, 11 Mar 2019 10:03:31 -0600

Another omission[1] (maybe, I believe it is anyway) to the Device Flow is
that client authentication isn't defined for the device authorization
request to device authorization endpoint.

I suspect that it's largely an oversight because public clients are really
the conical use-case for the device flow and no authentication is needed or
possible in that case. There are, however, likely to be cases where a
client with credentials will do the device flow and it would be good for
the AS to be able to properly authenticate such clients before setting up
and saving the state for the transaction. Having normal client
authentication at device authorization endpoint also brings better
consistency to client identification/authentication for requests made
directly from client to AS.

[1] error responses from the device authorization endpoint should probably
also be defined
https://mailarchive.ietf.org/arch/msg/oauth/DMTUR1msdNQPiLh0xVXe39933k4

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._

---

From: Brian Campbell <[email-masked]>
Date: Mon, 11 Mar 2019 10:07:20 -0600

I do realize it's very late in the process for this document but believe
these omissions can be addressed in the document with only minor
changes/additions and that it'd be better late than not at all.

---

From: Filip Skokan <[email-masked]>
Date: Mon, 11 Mar 2019 17:14:27 +0100

If we're about to add client authentication for the
device_authorization_endpoint, i'd say we should also register for
device_authorization_endpoint_auth_method,
device_authorization_endpoint_auth_signing_alg client metadata. Maybe
define the default value to be "none" / not provided to be in line with the
late draft implementations. Wdyt?

S pozdravem,
*Filip Skokan*

On Mon, 11 Mar 2019 at 17:08, Brian Campbell <bcampbell=
[email-masked]> wrote:

> changes/additions and that it'd be better late than not at all..
>
> On Mon, Mar 11, 2019 at 10:03 AM Brian Campbell <
> [email-masked]> wrote:
>
>> I suspect that it's largely an oversight because public clients are
>> really the conical use-case for the device flow and no authentication is
>> needed or possible in that case. There are, however, likely to be cases
>> where a client with credentials will do the device flow and it would be
>> good for the AS to be able to properly authenticate such clients before
>> setting up and saving the state for the transaction. Having normal client
>> [1] error responses from the device authorization endpoint should
>> probably also be defined
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited..
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*_______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Filip Skokan <[email-masked]>
Date: Mon, 11 Mar 2019 17:21:14 +0100

Strike that, it should maybe just use the registered auth method for the
token endpoint?

If there's auth we should also make it clear that client_id should not be
omitted from the request body and it must be the same as the one provided
with client authentication.

S pozdravem,
*Filip Skokan*

On Mon, 11 Mar 2019 at 17:14, Filip Skokan <[email-masked]> wrote:

>>> Another omission[1] (maybe, I believe it is anyway) to the Device Flow
>>> is that client authentication isn't defined for the device authorization

---

From: Brian Campbell <[email-masked]>
Date: Mon, 11 Mar 2019 10:31:11 -0600

> Strike that, it should maybe just use the registered auth method for the

Yeah, that's what I'd think would be the way to go.

> with client authentication.
Fair point.

>>> review, use, distribution or disclosure by others is strictly
>>> prohibited...  If you have received this communication in error, please
>>> notify the sender immediately by e-mail and delete the message and any file
>>> attachments from your computer. Thank you.*
>>> _______________________________________________
>>> OAuth mailing list
>>> [email-masked]
>> _______________________________________________
> OAuth mailing list
> [email-masked]

---

From: George Fletcher <[email-masked]>
Date: Mon, 11 Mar 2019 13:27:57 -0400

+1

to using the same client authn method as for the /token endpoint

On 3/11/19 12:31 PM, Brian Campbell wrote:
>
>
> On Mon, Mar 11, 2019 at 10:22 AM Filip Skokan <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Strike that, it should maybe just use the registered auth method
>     for the token endpoint?
>
>
>     If there's auth we should also make it clear that client_id should
>     not be omitted from the request body and it must be the same as
>     the one provided with client authentication.
>
>
> Fair point.
>
>
>     S pozdravem,
>     *Filip Skokan*
>
>
>     On Mon, 11 Mar 2019 at 17:14, Filip Skokan <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>         device_authorization_endpoint, i'd say we should also register
>         for device_authorization_endpoint_auth_method,
>         device_authorization_endpoint_auth_signing_alg client
>         metadata. Maybe define the default value to be "none" / not
>         provided to be in line with the late draft implementations. Wdyt?
>
>         S pozdravem,
>         *Filip Skokan*
>
>
>         On Mon, 11 Mar 2019 at 17:08, Brian Campbell
>         <bcampbell=[email-masked]
>         <mailto:[email-masked]>> wrote:
>
>             I do realize it's very late in the process for this
>             document but believe these omissions can be addressed in
>             the document with only minor changes/additions and that
>             it'd be better late than not at all..
>
>             On Mon, Mar 11, 2019 at 10:03 AM Brian Campbell
>             <[email-masked]
>             <mailto:[email-masked]>> wrote:
>
>                 Another omission[1] (maybe, I believe it is anyway) to
>                 the Device Flow is that client authentication isn't
>                 defined for the device authorization request to device
>                 authorization endpoint.
>
>                 I suspect that it's largely an oversight because
>                 public clients are really the conical use-case for the
>                 device flow and no authentication is needed or
>                 possible in that case. There are, however, likely to
>                 be cases where a client with credentials will do the
>                 device flow and it would be good for the AS to be able
>                 to properly authenticate such clients before setting
>                 up and saving the state for the transaction. Having
>                 normal client authentication at device authorization
>                 endpoint also brings better consistency to client
>                 identification/authentication for requests made
>                 [1] error responses from the device authorization
>                 endpoint should probably also be defined
>             /CONFIDENTIALITY NOTICE: This email may contain
>             confidential and privileged material for the sole use of
>             the intended recipient(s). Any review, use, distribution
>             or disclosure by others is strictly prohibited...  If you
>             have received this communication in error, please notify
>             the sender immediately by e-mail and delete the message
>             and any file attachments from your computer. Thank
>             you./_______________________________________________
>             OAuth mailing list
>             [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>
> /CONFIDENTIALITY NOTICE: This email may contain confidential and 
> prohibited..  If you have received this communication in error, please 
> notify the sender immediately by e-mail and delete the message and any 
> file attachments from your computer. Thank you./
>

-- 
Identity Standards Architect
Verizon Media                     Work: [email-masked]
Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544           Photos: http://georgefletcher.photography

---

From: Phil Hunt <[email-masked]>
Date: Mon, 11 Mar 2019 10:30:08 -0700

+1 to using same authentication requirements as for token endpoint. 

Phil

> On Mar 11, 2019, at 10:27 AM, George Fletcher <gffletch=[email-masked]> wrote:
> 
> +1
> 
>>> Strike that, it should maybe just use the registered auth method for the token endpoint?
>> 
>>> If there's auth we should also make it clear that client_id should not be omitted from the request body and it must be the same as the one provided with client authentication.
>>> 
>> 
>> Fair point. 
>> 
>> 
>>  
>>> S pozdravem,
>>> Filip Skokan
>>> 
>>> 
>>>> If we're about to add client authentication for the device_authorization_endpoint, i'd say we should also register for device_authorization_endpoint_auth_method, device_authorization_endpoint_auth_signing_alg client metadata. Maybe define the default value to be "none" / not provided to be in line with the late draft implementations. Wdyt?
>>>> 
>>>> S pozdravem,
>>>> Filip Skokan
>>>> 
>>>> 
>>>>> On Mon, 11 Mar 2019 at 17:08, Brian Campbell <bcampbell=[email-masked]> wrote:
>>>>> I do realize it's very late in the process for this document but believe these omissions can be addressed in the document with only minor changes/additions and that it'd be better late than not at all.. 
>>>>> 
>>>>>> On Mon, Mar 11, 2019 at 10:03 AM Brian Campbell <[email-masked]> wrote:
>>>>>> Another omission[1] (maybe, I believe it is anyway) to the Device Flow is that client authentication isn't defined for the device authorization request to device authorization                                         endpoint. 
>>>>>> 
>>>>>> I suspect that it's largely an oversight because public clients are really the conical use-case for the device flow and no authentication is needed or possible in that case. There are, however, likely to be cases where a client with credentials will do the device flow and it would be good for the AS to be able to properly authenticate such clients before setting up and saving the state for the transaction. Having normal client authentication at device authorization endpoint also brings better consistency to client identification/authentication for requests made directly from client to AS.  
>>>>>> 
>>>>>> 
>>>>>> [1] error responses from the device authorization endpoint should probably also be defined https://mailarchive.ietf.org/arch/msg/oauth/DMTUR1msdNQPiLh0xVXe39933k4 
>>>>>> 
>>>>> 
>>>>> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited...  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._______________________________________________
>>>>> OAuth mailing list
>>>>> [email-masked]
>> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you. 
>> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=T9FBaSmKjH9DP1tZy7yS2PWNPsktsU0izt30MhOcMpw&s=A-TWytTVW596UG0zc6oz1rozU_auZJ0bIPSGqtXnTGA&e=

---

From: William Denniss <[email-masked]>
Date: Mon, 11 Mar 2019 12:18:21 -0700

Thank you Brian for raising this.

Yes, the expectation I believe is to follow the same approach as the token
endpoint. As the spec is primarily for public clients, that's what we
documented explicitly but it's worth calling out.

Would the following text suffice in order to "inherit" the client
authentication requirements of the token endpoint do you think?

    "The client authentication requirements of Section 3.2.1 of RFC6749
apply to requests on this endpoint."

Then there's the matter of the REQUIRED "client_id" parameter. Perhaps we
could say "REQUIRED, unless the client authenticates per Section 2.3 of
RFC6749"

On Mon, Mar 11, 2019 at 10:30 AM Phil Hunt <[email-masked]> wrote:

> On Mar 11, 2019, at 10:27 AM, George Fletcher <
> gffletch=[email-masked]> wrote:
>
> +1
>
>>>> I do realize it's very late in the process for this document but
>>>> believe these omissions can be addressed in the document with only minor
>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_oauth_DMTUR1msdNQPiLh0xVXe39933k4&d=DwMDaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=T9FBaSmKjH9DP1tZy7yS2PWNPsktsU0izt30MhOcMpw&s=0mpCioWFgFIBMvwRTGb0v6ZawCSwMK9a2YH4G_yoRoo&e=>
>>>>>
>>>>>
>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth&d=DwMDaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=T9FBaSmKjH9DP1tZy7yS2PWNPsktsU0izt30MhOcMpw&s=A-TWytTVW596UG0zc6oz1rozU_auZJ0bIPSGqtXnTGA&e=>
>>>>
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth&d=DwMDaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=T9FBaSmKjH9DP1tZy7yS2PWNPsktsU0izt30MhOcMpw&s=A-TWytTVW596UG0zc6oz1rozU_auZJ0bIPSGqtXnTGA&e=>
>>
>
> your computer. Thank you.*
>
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth&d=DwMDaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=T9FBaSmKjH9DP1tZy7yS2PWNPsktsU0izt30MhOcMpw&s=A-TWytTVW596UG0zc6oz1rozU_auZJ0bIPSGqtXnTGA&e=>
>
>
> --
> Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch <https://urldefense.proofpoint.com/v2/url?u=http-3A__twitter.com_gffletch&d=DwMDaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=T9FBaSmKjH9DP1tZy7yS2PWNPsktsU0izt30MhOcMpw&s=fm9UvoaRS-A1-2CXwQEgOZ7fWb-PGvleny8Ccwq-SRs&e=>
> Office: +1-703-265-2544           Photos: http://georgefletcher.photography <https://urldefense.proofpoint.com/v2/url?u=http-3A__georgefletcher.photography&d=DwMDaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=T9FBaSmKjH9DP1tZy7yS2PWNPsktsU0izt30MhOcMpw&s=pHcwrS-xhaUz37RAgViALdKPBAFeoFc7nLxxs2NywdQ&e=>
>

---

From: Brian Campbell <[email-masked]>
Date: Mon, 11 Mar 2019 14:21:16 -0600

And thank you, William, for being responsive about it.

> apply to requests on this endpoint."

I think so, yes.

Although given the primary focus being for public clients, it might be
helpful to have a little qualifying text here catering to that most common
case. I guess I'm just looking to try and avoid folks mistakenly
interpreting that to mean that client authentication is always required and
so somehow public clients can't do this flow. Something like the following
(wording could maybe be improved but hopefully conveys the idea):

'The client authentication requirements of Section 3.2.1 of RFC6749 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.'

> could say "REQUIRED, unless the client authenticates per Section 2.3 of

I kinda prefer the text you have already in section 3.4:

  " client_id
      REQUIRED, if the client is not authenticating with the
      authorization server as described in Section 3.2.1. of [RFC6749]."

>>> If there's auth we should also make it clear that client_id should not
>>> be omitted from the request body and it must be the same as the one
>>> provided with client authentication.
>>>
>>>
>> Fair point.
>>
>>
>>
>>
>>> S pozdravem,
>>> *Filip Skokan*
>>>
>>>
>>>>>> Another omission[1] (maybe, I believe it is anyway) to the Device
>>>>>> Flow is that client authentication isn't defined for the device
>>>>>> authorization request to device authorization endpoint.
>>>>>>

---

From: William Denniss <[email-masked]>
Date: Mon, 11 Mar 2019 13:42:53 -0700

On Mon, Mar 11, 2019 at 1:21 PM Brian Campbell <bcampbell=
[email-masked]> wrote:

>> Yes, the expectation I believe is to follow the same approach as the
>> token endpoint. As the spec is primarily for public clients, that's what we

The context helps, thanks for the suggested text, I used it and it's staged
locally now.

>       authorization server as described in Section 3.2.1. of [RFC6749]."
hah yeah I prefer that construction too, forgot I'd already given it that
treatment elsewhere.

Also staged locally.

Thanks again for reporting this!

>>> Office: +1-703-265-2544           Photos: http://georgefletcher.photography <https://urldefense.proofpoint..com/v2/url?u=http-3A__georgefletcher.photography&d=DwMDaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=T9FBaSmKjH9DP1tZy7yS2PWNPsktsU0izt30MhOcMpw&s=pHcwrS-xhaUz37RAgViALdKPBAFeoFc7nLxxs2NywdQ&e=>
>>>

---

From: Brian Campbell <[email-masked]>
Date: Mon, 11 Mar 2019 14:57:16 -0600

All sounds good to me. Thanks again for picking this one up quickly.

On Mon, Mar 11, 2019 at 2:43 PM William Denniss <wdenniss=
[email-masked]> wrote:

> The context helps, thanks for the suggested text, I used it and it's
> staged locally now.
>
>
>>
>>
>>> Then there's the matter of the REQUIRED "client_id" parameter. Perhaps
>>> we could say "REQUIRED, unless the client authenticates per Section 2.3 of
>>> RFC6749"
>>>
>>