Benjamin Kaduk has entered the following ballot position for draft-ietf-oauth-device-flow-13: 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: ---------------------------------------------------------------------- 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. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
