[OAUTH-WG] Benjamin Kaduk's No Objection on draft-ietf-oauth-device-flow-13: (with COMMENT)

[Benjamin Kaduk <[e-mail]>]

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.