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

In reading the draft (again) I noticed a couple of things that, while maybe
not substantive, seemed like they were worth raising here in last call:

1:
In Section 3.5
<https://tools.ietf.org/html/draft-ietf-oauth-device-flow-09#section-3.5> a
new 'expired_token' error code is defined for when the 'device_code' has
expired and the client will need to start the flow over. Shortly after the
new error code definition there is text in that section that says 'If the
verification codes have expired, the server SHOULD respond with the
standard OAuth error "invalid_grant".  Clients MAY then choose to start a
new device authorization session.'

This reads to me like: here's a new error for expired device code but this
other code SHOULD be used for expired device code. Am I confused or
otherwise missing something?

I kinda suspect that the intent is that expired_token can be returned for
codes that are known to be expired while invalid_grant is more of a catch
all for codes that may have expired long enough ago that they have been
purged from server memory/persistence or are otherwise unknown. That's my
guess anyway. But the current text seems somewhat contradictory, which I
think could be clarified/fixed.

2:
In section 5
<https://tools.ietf.org/html/draft-ietf-oauth-device-flow-09#section-5.5>
about security considerations for Non-confidential Clients there's a
pointer to recommendations from Section 8.9 of [RFC8252]
<https://tools.ietf.org/html/rfc8252#section-8.9>, which is about using the
"state" parameter in the authorization request to protect against cross-app
request forgery.  That doesn't seem right or relevant to the device flow,
does it? Was it intended to point to section 8.5 in RFC8252
<https://tools.ietf.org/html/rfc8252#section-8.5>? Or something else?

On Tue, May 29, 2018 at 4:20 PM, 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._