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 Brian,

On Wed, May 30, 2018 at 12:56 PM, Brian Campbell <[e-mail]
> wrote:

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

I agree that the way it's documented "expired_token" would be for when you
know it's expired, whereas "invalid_grant" is a more generic catch all. I
think this section needs to be revisited to clear up this ambiguity. Before
proposing a solution, I want to investigate a little what the existing
implementations are doing around this case.


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?
>
>
Good catch.

That text was introduced in 04, https://tools.ietf.org/html/
draft-ietf-oauth-device-flow-04#section-5.4 and Section 8.9 of the 07 draft
version of native apps at the time was "Client Authentication
<https://tools.ietf.org/html/draft-ietf-oauth-native-apps-07#section-8.9>",
which is now Section 8.5 of RFC8252.  I will update this draft to point to
Section 8.5, per the original intent.


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