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

[Brian Campbell <[e-mail]>]

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.






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/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.*
>>
>
>
> _______________________________________________
> 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._