Yes, that's how I implemented it as well. I return 'invalid_request' when the client_id is missing entirely.
Do you have any thoughts how this specification should work in combination with other specs, such as OIDC? For example, the OIDC Authentication Request specifies several additional parameters, some of which may be applicable for the device flow as well. Can the device flow be used to obtain an ID token? How should parameters like 'max_age', 'id_token_hint' and 'claims' be processed? My plan was to construct a pseudo-authentication/authorization request using the parameters specified at the device authorization endpoint and apply these parameters during the user interaction. Some parameters, such as 'prompt=3Dnone', do not make much sense though. I think it may be a good idea to describe how this spec is supposed to interoperate with other specifications, especially those that extend the Authorization Endpoint. This definition can never be complete, as new specs will be defined after this one, but it can at least try to describe the general rules that apply. PS. Other specifications also define additional parameters that may be useful, such as: 'resource' from Resource Indicators for OAuth 2.0 and 'include_granted_scopes' from OAuth 2.0 Incremental Authorization. Best regards, Emond Papegaaij Topicus KeyHub On Fri, Mar 8, 2019 at 10:24 PM Brian Campbell <bcampb...@pingidentity.com> wrote: > > While probably not terribly important from an interoperability perspective, I > agree that does seem like an omission. > > I took a quick look at our implementation and bad requests to the device > authorization endpoint will indeed return what is a standard OAuth 2.0 error > response normally from the token endpoint with invalid_client or > invalid_scope error codes. And a little bit of poking at Google's device > authorization endpoint suggests it behaves similarly. I suspect it's pretty > typical. > > > > On Fri, Mar 8, 2019 at 5:28 AM Emond Papegaaij <emond.papega...@gmail.com> > wrote: >> >> Dear all, >> >> I'm working on an implementation of the OAuth 2.0 Device Flow for Browserless >> and Input Constrained Devices and noticed a possible omission in the spec. >> Section 3.2 describes the Device Authorization Response, but only the success >> response is specified, not the error response. I would have expected a >> standard OAuth 2.0 error response, probably with the following error codes: >> invalid_request, invalid_client and invalid_scope. >> >> Best regards, >> Emond Papegaaij >> Topicus KeyHub >> >> >> _______________________________________________ >> 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
