Hi Ben, Thank you for your feedback. Version 12 has been posted which addresses some of your points. Replies inline:
On Wed, Aug 1, 2018 at 2:36 PM, Ben Campbell <[email protected]> wrote: > > ---------------------------------------------------------------------- > 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. > Version 12 adds defaults for the interval, documents slow_down behavior, and now requires that an expiry time is given (previously this was optional). Regarding maximum attempts, as that is a function of interval and the expiry the AS can decide this (and also has the slow_down mechanism if they need). 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). > Added the text: Due to the polling nature of this protocol, 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. > §3.3: What sort of bad thing could happen if the device_code is > communicated to > a user? Nothing bad. This text was revised in 12 to clarify that this recommendation is for usability. > Do implementers need to worry about people guessing device-codes? > Yes. Guessing the device_code would enable another device to obtain the authorization grant once issued. We will add a security section in the next version (13). > > §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? > The next section uses `verification_uri_complete` which is separate to `verification_uri`, this NOT RECOMMENDED refers to the latter only. Also the text immediately following the block you quoted reads "The next section documents user interaction with "verification_uri_complete", which is designed to carry this information." Even devices that use the non-textual mechanism may also display the vanilla `verification_uri` and user_code as a fallback, as Figure 3 shows, and so this NOT RECOMMENDED still applies to the `verification_uri` that they display. Figure 3 was updated to indicate that the user either scans the QR code *or* follows the fallback options. > §5.4: Are devices expected to know the operating environment in advance of > deployment? > These apps typically are aware of the operating environments in which they are deployed, e.g. a TV app deployed to a branded "TV streaming stick". > 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. > Added this to the -13 revision plan. > §2: There are lower case instances of normative keywords. Please consider > using the updated boilerplate from RFC8174. > Done. Best, William
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
