On Wed, May 30, 2018 at 3:48 PM, Brian Campbell <bcampbell@xxxxxxxxxxxxxxxx> 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 ). 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.com@xxxxxxxxtf.org > wrote:
> Hi Andrew,
>
> On Wed, May 30, 2018 at 3:18 PM, Andrew Sciberras <
> andrewsciberras@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- >> <https://developers..google.co
>> responses-to-polling-requests
m/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 <wdenniss@xxxxxxxxxx>
>> wrote:
>>
>>> Hi Andrew,
>>>
>>> On Wed, May 30, 2018 at 2:35 PM, Andrew Sciberras <andrewsciberras@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
