Subject: [OAUTH-WG] Ben Campbell's No Objection on draft-ietf-oauth-device-flow-11: (with COMMENT)

From: Ben Campbell <[email-masked]>
Date: Wed, 01 Aug 2018 14:36:09 -0700

Ben Campbell has entered the following ballot position for
draft-ietf-oauth-device-flow-11: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Major Comment:

I support Mirja's DISCUSS. (Otherwise, this would be a DISCUSS), but I have a
slightly different spin on it. The device polls the server while waiting on the
user to take action. Users are notoriously slow about that sort of thing. They
might plug in a device then walk away for hours, days, or forever.  Now,
consider that we are talking about IoT devices, so there may be millions of
them. If they are fate shared in some way (imagine shipping day for a new
popular product, or a software update that forces reauthorization, or a server
coming back online after getting whacked the last time around), there could be
millions of them trying this at the roughly the same time.

Given all that, I think the draft really needs to give more detailed guidance
on what sort of refresh rates, maximum attempts, expirations, back off
patterns, etc might be reasonable from both network congestion and server
overload perspectives.

Other Substantive Comments:

§3.1: What sort of events are expected to trigger the flow? In particular, I
wonder if there should be guidance to make it unlikely to start the process by
accident. For example, if the authorization process is kicked off by a device
simply being plugged into power, a user might plug it in then walk away before
realizing they had more to do. (See my major comment).

§3.3: What sort of bad thing could happen if the device_code is communicated to
a user? Do implementers need to worry about people  guessing device-codes?

§3.3, last paragraph: The "NOT RECOMMENDED" seems overly strong, given that the
next section describes a perfectly good way to do exactly that. Maybe something
like "NOT RECOMMENDED unless the device uses a non-textual mechanism for
conveying the URL and code, such as that described in ..." would make sense?

§5.4: Are devices expected to know the operating environment in advance of
deployment?

Editorial Comments:

§1, 3rd paragraph: The first sentence is hard to parse due the list of long,
complex phrases. Please consider breaking into simpler sentences.

§2: There are lower case instances of normative keywords.  Please consider
using the updated boilerplate from RFC8174.

---

From: William Denniss <[email-masked]>
Date: Thu, 2 Aug 2018 14:56:45 -0700

Hi Ben,

Thank you for your feedback. Version 12 has been posted which addresses
some of your points. Replies inline:

Version 12 adds defaults for the interval, documents slow_down behavior,
and now requires that an expiry time is given (previously this was
optional).

Regarding maximum attempts, as that is a function of interval and the
expiry the AS can decide this (and also has the slow_down mechanism if they
need).

> realizing they had more to do. (See my major comment).

Added the text:

Due to the polling nature of this protocol, to avoid unneeded
requests on the token endpoint, the client SHOULD only commence a
device authorization request when prompted by the user, and not
automatically such as when the app starts.

> a user?

Nothing bad. This text was revised in 12 to clarify that this
recommendation is for usability.

> Do implementers need to worry about people  guessing device-codes?
>

Yes. Guessing the device_code would enable another device to obtain the
authorization grant once issued. We will add a security section in the next
version (13).

> conveying the URL and code, such as that described in ..." would make

The next section uses `verification_uri_complete` which is separate to
`verification_uri`, this NOT RECOMMENDED refers to the latter only. Also
the text immediately following the block you quoted reads "The next section
documents user interaction with "verification_uri_complete", which is
designed to carry this information." Even devices that use the non-textual
mechanism may also display the vanilla `verification_uri` and user_code as
a fallback, as Figure 3 shows, and so this NOT RECOMMENDED still applies to
the `verification_uri` that they display.

Figure 3 was updated to indicate that the user either scans the QR code
*or* follows the fallback options.

> §5.4: Are devices expected to know the operating environment in advance of

These apps typically are aware of the operating environments in which they
are deployed, e.g. a TV app deployed to a branded "TV streaming stick".

> complex phrases. Please consider breaking into simpler sentences.

Added this to the -13 revision plan.

> using the updated boilerplate from RFC8174.

Done.

Best,
William

---

From: Ben Campbell <[email-masked]>
Date: Fri, 3 Aug 2018 15:38:56 -0500

Hi, thanks for the response. Comments inline. I removed sections that seem resolved.

Ben.

> On Aug 2, 2018, at 4:56 PM, William Denniss <wdenniss=[email-masked]> wrote:
> 

[…]

> Version 12 adds defaults for the interval, documents slow_down behavior, and now requires that an expiry time is given (previously this was optional).
> 
> Regarding maximum attempts, as that is a function of interval and the expiry the AS can decide this (and also has the slow_down mechanism if they need).

That all helps. But I think it would be useful to have some guidance about how one should choose these values, or what things people should think about. Do you think the defaults are good for most cases? Are there situations that would warrant faster or slower polling? I’m not asking for anything complex or normative. (Also, keep in mind this is a non-blocking comment. If people don’t think the additional work is worthwhile, then so be it.)

> Other Substantive Comments:

[…]
> The next section uses `verification_uri_complete` which is separate to `verification_uri`, this NOT RECOMMENDED refers to the latter only. Also the text immediately following the block you quoted reads "The next section documents user interaction with "verification_uri_complete", which is designed to carry this information." Even devices that use the non-textual mechanism may also display the vanilla `verification_uri` and user_code as a fallback, as Figure 3 shows, and so this NOT RECOMMENDED still applies to the `verification_uri` that they display.
> 
> Figure 3 was updated to indicate that the user either scans the QR code *or* follows the fallback options.
> 
> 

Okay.

[…]