Strike that, it should maybe just use the registered auth method for the token endpoint?
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. S pozdravem, *Filip Skokan* On Mon, 11 Mar 2019 at 17:14, Filip Skokan <[email protected]> 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= > [email protected]> 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 < >> [email protected]> 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth >> >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
