Summary: Has 3 DISCUSSes. Has enough positions to pass once DISCUSS positions are resolved.
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.
Please specify more clearly the (default) polling behavior to ensure that the polling does neither overload the network, nor the server, or is never terminated. Ideally provide default values and an upper bound for the polling frequency, as well as a timer to terminate polling if no reply is received (and no expiration time is given). See further details below. 1) Sec 3.3: "until the user completes the interaction, the code expires, or another error occurs." What if not expiration time is given (as this optional) and no reply is ever received? 2) Sec 3.5: "the client should stop polling and react accordingly, for example, by displaying an error to the user." Maybe: "the client MUST stop polling and SHOULD react accordingly, for example, by displaying an error to the user." 3) sec 3.5 "If no interval was provided, the client MUST use a reasonable default polling interval." Can you please provide a default number for a "reasonable" polling interval! And in best case an upper bound! 4) sec 3.5: "...increasing the time between polls if a "slow_down" error is received. " Maybe use a separate normative sentence instead: "The client SHOUD increase the time between polls if a "slow_down" error is received." Or MUST? If so how much? Can you given further (default) guidance. 5) sec 3.5: "Clients MAY then choose to start a new device authorization session." Maybe make it clear that polling is stopped "Clients MUST stop polling but MAY then choose to start a new device authorization session." 6) sec 3.5: "then the device MAY wait until notified on that channel that the user has completed the action before initiating the token request." Why not SHOULD (or MUST) here?
Thanks to the authors for addressing my comments and half of my DISCUSS. This final issue appears to remain unaddressed: §3.1: > The client constructs the request with the following parameters, > encoded with the "application/x-www-form-urlencoded" content type: This document needs a normative citation for this media type. My suggestion would be to cite REC-html5-20141028 section 188.8.131.52, as this appears to be the most recent stable description of how to encode this media type. I'd love to hear rationale behind other citations being more appropriate, since I'm not entirely happy with the one I suggest above (given that it's been superseded by HTML 5.2); but every other plausible citation I can find is even less palatable (with HTML 5.2 itself having the drawback of not actually defining how to encode the media type, instead pointing to an unstable, unversioned document).
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.
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.
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
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.