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
