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

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