On Wed, May 30, 2018 at 3:48 PM, Brian Campbell <bcampb...@pingidentity.com> 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=40google....@dmarc.ietf.org> wrote: > > > Hi Andrew, > > > > On Wed, May 30, 2018 at 3:18 PM, Andrew Sciberras < > > andrewsciber...@pingidentity.com> 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 <wdenn...@google.com> > >> wrote: > >> > >>> Hi Andrew, > >>> > >>> On Wed, May 30, 2018 at 2:35 PM, Andrew Sciberras < > andrewsciber...@pingidentity.com> 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 >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
