Hi Filip, Yes, this was exactly what I was thinking about. Good to know I'm working in the right direction. I must say that the spec reads really well and is fairly straightforward to implement.
Best regards, Emond Papegaaij Topicus KeyHub On Mon, Mar 11, 2019 at 6:29 PM Filip Skokan <panva...@gmail.com> wrote: > > Hi Emond, > > the way i approached implementation of device flow into an OIDC server was to > allow all already registered and handled parameters excluding the ones [1] > that really don't make sense for the flow at the device authorization > endpoint. > > What can be validated at the device authorization endpoint time is, > everything else runs as part of the regular authorization pipeline for which > i also construct the request based on the params saved together with the > device code backend model. Everything else that depends on the actual device > where authnz happens is processed as part of the web request following the > user code submission. When errors occur that cannot be resolved with user > interaction the error is assigned to the device code and returned to the > device with the next poll. I did not exclude prompt:none, as the pipeline > processing starts after the submission it's possible that no prompt will > occur there, but i can see how it may be weird. Yes the result at the token > endpoint will include an id token if the scope included `openid` as one would > expect, just like it will include a refresh token if `offline_access` is > present. `resource` specifically is available as per the resource indicator > spec at device authorization as well as token endpoints. > > I guess this is very similar to what you're thinking. > > I don't think we need to (and can for that matter) enumerate all possible > OAuth2.0 extensions in the specification. > > [1] web_message_uri, web_message_target, response_type, response_mode, state, > redirect_uri > > S pozdravem, > Filip Skokan > > > On Mon, 11 Mar 2019 at 15:02, Emond Papegaaij <emond.papega...@gmail.com> > wrote: >> >> 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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
