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