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

On Mon, Mar 11, 2019 at 1:21 PM Brian Campbell <bcampbell=
40pingidentity.com@dmarc.ietf.org> wrote:

> And thank you, William, for being responsive about it.
>
>
> On Mon, Mar 11, 2019 at 1:18 PM William Denniss <wdenniss=
> 40google.com@dmarc.ietf.org> wrote:
>
>> 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."
>>
>
> 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.'
>
>

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"
>>
>
> 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]."
>
>
hah yeah I prefer that construction too, forgot I'd already given it that
treatment elsewhere.

Also staged locally.

Thanks again for reporting this!

>
>
>>
>> On Mon, Mar 11, 2019 at 10:30 AM Phil Hunt <phil.hunt@oracle.com> wrote:
>>
>>> +1 to using same authentication requirements as for token endpoint.
>>>
>>> Phil
>>>
>>> On Mar 11, 2019, at 10:27 AM, George Fletcher <
>>> gffletch=40aol.com@dmarc.ietf.org> wrote:
>>>
>>> +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 <panva.ip@gmail.com>
>>> wrote:
>>>
>>>> Strike that, it should maybe just use the registered auth method for
>>>> the token endpoint?
>>>>
>>>
>>> Yeah, that's what I'd think would be the way to go.
>>>
>>>
>>>>
>>>> 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 <panva.ip@gmail.com> wrote:
>>>>
>>>>> 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=
>>>>> 40pingidentity.com@dmarc.ietf.org> 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 <
>>>>>> bcampbell@pingidentity.com> 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
>>>>>>> <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=>
>>>>>>>
>>>>>>>
>>>>>> *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
>>>>>> OAuth@ietf.org
>>>>>> https://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=>
>>>>>>
>>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://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=>
>>>>
>>>
>>> *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 listOAuth@ietf.orghttps://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=>
>>>
>>>
>>> --
>>> Identity Standards Architect
>>> Verizon Media                     Work: george.fletcher@oath.com
>>> 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=>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>>
>>> 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=
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>
> *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.*