+1 to using same authentication requirements as for token endpoint. Phil
> On Mar 11, 2019, at 10:27 AM, George Fletcher > <gffletch=40aol....@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...@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...@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....@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 >>>>>> <bcampb...@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 >>>>>> >>>>> >>>>> 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 >>> _______________________________________________ >>> 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. >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > -- > Identity Standards Architect > Verizon Media Work: george.fletc...@oath.com > Mobile: +1-703-462-3494 Twitter: http://twitter.com/gffletch > Office: +1-703-265-2544 Photos: http://georgefletcher.photography > _______________________________________________ > 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
