OAuth 2.0 Device Authorization Grant
draft-ietf-oauth-device-flow-15

Props on the ASCII art QR code :-)

I believe the acknowledgement section should be in the body of the document, not as an appendix.


Also, please see the OpsDir review at: https://mailarchive.ietf.org/arch/msg/ops-dir/W8nzC89juHe32K3VXLQyVcPC_og

Thanks to the authors for addressing my comments and my DISCUSS.

This is generally a fine document and it was easy to follow.

I am agreeing with Benjamin's DISCUSS about amount of entropy in codes.

In addition, the last para in Section 6.1 reads:

   The server should ignore any characters like punctuation that are not
   in the user-code character set.  Provided that the character set
   doesn't include characters of different case, the comparison should
   be case insensitive.

This makes me uncomfortable, because you are talking of case-insensitivity,
without fully specifying what it is. I assume that your advice only
applies to user-code character sets which only use subset of ASCII?
Because if you mean to extend your advice to full Unicode, you need more text
and references here. Can you please clarify.

I support Mirja's DISCUSS point #3 which was also raised by the Gen-ART reviewer. The Gen-ART review also included a number of other useful comments. Please address them.

Perhaps this is implicit, but I found it a little odd that there is no mention of whether the device codes and user codes are expected to be unique to individual devices.

Section 3.3:

"It is NOT RECOMMENDED for authorization servers to include the user
   code in the verification URI ("verification_uri"), as this increases
   the length and complexity of the URI that the user must type."

I don't fully understand the justification for the normative requirement here. The user ultimately ends up typing in both strings, right? Is it so much more complex to type them both into a browser bar contiguously than to type the uri into the browser bar and the code into some form field on the page such that the normative requirement is warranted?

Section 3.3.1:

Wouldn't there be textual instructions about how to use the QR code also included here? If the point is to illustrate the UI it seems like those should be included too.

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.

Thank you for addressing my Discuss points.  I would still prefer to see a
normative requirement for explicit user approval (as opposed to  just the
descriptive statement that the chance to approve/deny should be offered),
but I can understand the sentiment that such a requirement  on  the UI is
not a matter for interoperability and could not be reliably enforced anyway.

Original COMMENT  section preserved below.

Please use the RFC 8174 boilerplate instead of the RFC 2119 one.

Section 3.2

The example expires in 30 minutes?  That seems longer than needed; wouldn't
5 minutes do?

Section 3.3

I agree with directorate reviewer that the MUST NOT requirement for
displaying the device_code should justify that requirement by discussing
the consequences of exposure.

Section 3.5

   authorization_pending
      The authorization request is still pending as the end-user hasn't
      yet completed the user interaction steps (Section 3.3).  The
      client should repeat the Access Token Request to the token
      endpoint.

I feel like we want to mention the 'interval' here or some other discussion
of an inter-request delay.

Also, please clarify "reasonable default polling interval", per multiple
directorate reviews.

Section 5.2

Please clarify the entities involved in "the backchannel flow" that can be
MITM'd.

Section 5.6

The "short-range" part of a "short-range wireless signal" partially depends
on how big the receiver's antenna is.  So perhaps we should be careful
about indicating that this has more security value than it does.

Section 6.1

I'm not sure I understand the usage of "case-insensitive", here -- how
would the user have an expectation of case-insensitivity?  Perhaps it is
better to just say "majuscule" or "upper case" or whatever.

Thanks for addressing my discuss comments (quickly - sorry for the delay!)