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 again for your comments, and sorry for the delay. I believe they
are all addressed now in version 14
<https://tools.ietf.org/html/draft-ietf-oauth-device-flow-14>.

Detailed replies below:

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

> 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.
>
>
Added some text to address the requirement for user action:

  Due to the polling nature of this protocol, care is needed to avoid
  overloading the capacity of the token endpoint. 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 or when the previous authorization session
  expires or fails.


 And further down, added text on network timeouts:

  Clients on encountering a connection timeout MUST unilaterally reduce
  their polling frequency before retrying. The use of an exponential
  backoff algorithm to achieve this, such as by doubling the polling
  interval on each such connection timeout is RECOMMENDED.



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

Good point. Added text that there should be a user action (see above).

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

Users discovering their own codes falls under client impersonation (clients
being impersonated can also just request new device_codes). Added a section
directly discussing device_codes in Section 5.6 Non-confidential Clients.

The section titled "Device Code Brute Forcing" covers the guessing problem,
Section 5.2.


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

This section was reworded, it currently has a NOT RECOMMENDED for including
the user_code specifically in the `verification_uri`, and mentions that
there is a designed way to do this as well.


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

Generally yes.


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

That's done.


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

Boilerplate is now RFC8174.

Best,
William