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

[William Denniss <[e-mail]>]

Hi Ben,

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

On Wed, Aug 1, 2018 at 2:36 PM, Ben Campbell <[e-mail]> wrote:

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

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


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

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.


> §3.3: What sort of bad thing could happen if the device_code is
> communicated to
> 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).


>
> §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?
>

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
> deployment?
>

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


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

Added this to the -13 revision plan.



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

Done.

Best,
William