Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-device-flow-09.txt> (OAuth 2.0 Device Flow for Browserless and Input Constrained Devices) to Proposed Standard

[William Denniss <[e-mail]>]

On Wed, May 30, 2018 at 3:48 PM, Brian Campbell <[e-mail]>
wrote:

> I realize this is somewhat pedantic but I don't think referencing 4.1.2.1
> works given how RFC 6749 set things up. Rather I believe that the device
> flow needs to define and register "access_denied" as a valid token endpoint
> response error code (it's not a token endpoint response error per RFC 6749
> sec 5.2 nor has it been registered https://www.iana.org/assignmen
> ts/oauth-parameters/oauth-parameters.xhtml#extensions-error
> <https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#extensions-error>
> ).  Also
> invalid_grant is a a token endpoint response error from RFC 6749 sec 5.2 so
> that reference is needed and appropriate. RFC 6749 Sec 4.1.2.1
> <https://tools.ietf.org/html/rfc6749#section-4.1.2> defines errors
> returned
> from the authorization endpoint. But the device flow errors are from the
> token endpoint.
>
>
Yes, that's true. It's still the token endpoint, so 5.2 does in fact apply,
it's just we're mixing in authorization-style actions which were not
previously considered/used for that endpoint.

Do you have any proposed text to resolve this?


>
> On Wed, May 30, 2018 at 4:27 PM, William Denniss <
> wdenniss=[e-mail]> wrote:
>
> > Hi Andrew,
> >
> > On Wed, May 30, 2018 at 3:18 PM, Andrew Sciberras <
> > [e-mail]> wrote:
> >
> >> Hi William
> >>
> >> You are right that the document explicitly indicates which error codes
> >> may be returned. However I think it's ambiguous as to which error within
> >> Section 5.2 of RFC6749 would apply in the scenario of a user not
> granting
> >> access.
> >>
> >> I think that this ambiguity is highlighted further by the Google
> >> implementation (https://developers.google.com
> >> /identity/protocols/OAuth2ForDevices#step-6-handle-
> >> responses-to-polling-requests
> >> <https://developers..google.com/identity/protocols/OAuth2For
> Devices#step-6-handle-responses-to-polling-requests>)
> >> not adhering to the explicit statement of the document and electing to
> use
> >> a (more appropriate) error code that exists outside of section 5.2.
> >>
> >>
> >
> > Oh, I see what you mean now. Yes, given this is an authorization request,
> > not a token request, the errors from Section 4.1.2.1
> > <https://tools.ietf.org/html/rfc6749#section-4.1.2> are more relevant.
> >
> > I believe it was the authors intention to reference that set of errors,
> so
> > I will plan to update the doc to reference 4..1.2.1 instead.  Good catch!
> > Thank you.
> >
> >
> >>
> >> On Thu, May 31, 2018 at 8:06 AM, William Denniss <[e-mail]>
> >> wrote:
> >>
> >>> Hi Andrew,
> >>>
> >>> On Wed, May 30, 2018 at 2:35 PM, Andrew Sciberras <
> [e-mail]> wrote:
> >>>
> >>> Hello
> >>>>
> >>>>
> >>>> Do we feel that the document should be more specific in addressing how
> >>>> the authorization service should respond to a device access token
> request
> >>>> when the user has refused to grant access to the device?
> >>>>
> >>>>
> >>>> The document currently indicates in section 3.5 that a success
> response
> >>>> defined in section 5.1 of RFC6749, an error as defined in section 5.2
> of
> >>>> RFC6749 (this includes invalid_request, invalid_client, invalid_grant,
> >>>> unauthorized_client, unsupported_grant_type, and invalid_scope), or a
> new
> >>>> device flow error code (authorization_pending, slow_down, and
> >>>> expired_token) may be returned in a response to a device token request
>