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. 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. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
