OAuth 2.0 Device Authorization Grant
Note: This ballot was opened for revision 10 and is now closed.
(Eric Rescorla) Yes
(Ignas Bagdonas) No Objection
(Deborah Brungard) No Objection
(Ben Campbell) No Objection
Comment (2018-08-01 for -11)
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.
(Alissa Cooper) No Objection
Comment (2018-07-31 for -11)
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.
(Spencer Dawkins) No Objection
Benjamin Kaduk (was Discuss) No Objection
Comment (2018-10-27 for -13)
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.
(Suresh Krishnan) No Objection
Warren Kumari No Objection
Comment (2018-07-28 for -11)
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
(Mirja Kühlewind) (was Discuss) No Objection
Comment (2018-10-18 for -12)
Thanks for addressing my discuss comments (quickly - sorry for the delay!)
(Terry Manderson) No Objection
(Alexey Melnikov) No Objection
Comment (2018-07-29 for -11)
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.
(Adam Roach) (was Discuss) No Objection
Comment (2018-10-19 for -13)
Thanks to the authors for addressing my comments and my DISCUSS.