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

[William Denniss <[e-mail]>]

On Sat, Oct 27, 2018 at 4:11 PM Benjamin Kaduk <[e-mail]> wrote:

> 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.
>

Thank you again for your review.

The UI requirements not being a matter for interoperability is indeed why
there is no normative text for that, and we're following the approach taken
by other IETF OAuth specifications which also leave this up to the
implementors. I understand your concerns here, but I hope that the current
non-normative guidance is enough.



>
> 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.
>
>
>