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

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=
40google.com@dmarc.ietf.org> wrote:

>
>
> 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.*
>
>

-- 
_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._