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
