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]>]

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) 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.
>>>
>>>
>>> It doesn’t seem that any of these options are appropriate to convey that
>>> a user has refused to grant access to the device.
>>>
>>>
>>> The Google implementation appears to be using the access_denied error
>>> code from section 4.1.2.1 of RFC6749. While this would seem to be the most
>>> suitable error code, the document does not explicitly indicate it as a
>>> permitted response.
>>>
>>
>> Actually, this is indicated explicitly I believe:
>>
>> If the user has approved the grant, the token endpoint responds with a
>> success response defined in Section 5.1 of [RFC6749]; *otherwise it
>> responds with an error, as defined in Section 5.2 of [RFC6749].*
>>
> In addition to the error codes defined in Section 5.2 of [RFC6749], the
>> following error codes are specific for the device flow:
>>
>>
>>>
>>> I believe that clarifying the response error code in the condition where
>>> a user has refused access to the client would be beneficial, remove
>>> ambiguity, and promote greater consistency across implementations.
>>>
>>>
>>> Regards
>>>
>>> Andrew Sciberras
>>>
>>>
>>> On Wed, May 30, 2018 at 8:20 AM, The IESG <[e-mail]>
>>> wrote:
>>>
>>>>
>>>> The IESG has received a request from the Web Authorization Protocol WG
>>>> (oauth) to consider the following document: - 'OAuth 2.0 Device Flow for
>>>> Browserless and Input Constrained Devices'
>>>>   <draft-ietf-oauth-device-flow-09.txt> as Proposed Standard
>>>>
>>>> The IESG plans to make a decision in the next few weeks, and solicits
>>>> final
>>>> comments on this action. Please send substantive comments to the
>>>> [e-mail] mailing lists by 2018-06-12. Exceptionally, comments may
>>>> be
>>>> sent to [e-mail] instead. In either case, please retain the
>>>> beginning of
>>>> the Subject line to allow automated sorting.
>>>>
>>>> Abstract
>>>>
>>>>
>>>>    This OAuth 2.0 authorization flow for browserless and input
>>>>    constrained devices, often referred to as the device flow, enables
>>>>    OAuth clients to request user authorization from devices that have an
>>>>    Internet connection, but don't have an easy input method (such as a
>>>>    smart TV, media console, picture frame, or printer), or lack a
>>>>    suitable browser for a more traditional OAuth flow.  This
>>>>    authorization flow instructs the user to perform the authorization
>>>>    request on a secondary device, such as a smartphone.  There is no
>>>>    requirement for communication between the constrained device and the
>>>>    user's secondary device.
>>>>
>>>>
>>>>
>>>>
>>>> The file can be obtained via
>>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/
>>>>
>>>> IESG discussion can be tracked via
>>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/ballot/
>>>>
>>>>
>>>> No IPR declarations have been submitted directly on this I-D.
>>>>
>>>>
>>>> The document contains these normative downward references.
>>>> See RFC 3967 for additional information:
>>>>     rfc6819: OAuth 2.0 Threat Model and Security Considerations
>>>> (Informational - IETF stream)
>>>>     draft-recordon-oauth-v2-device: OAuth 2.0 Device Profile
>>>>  (None - )
>>>>     rfc6755: An IETF URN Sub-Namespace for OAuth (Informational - IETF
>>>> stream)
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> [e-mail]
>>>> 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.*
>>>
>>
>>
>
> *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.*
>