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

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.
>
>
> 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 <iesg-secretary@ietf.org> 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
>> ietf@ietf.org mailing lists by 2018-06-12. Exceptionally, comments may be
>> sent to iesg@ietf.org 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
>> OAuth@ietf.org
>> 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.*
>