Subject: [OAUTH-WG] Mirja Kühlewind's Discuss on draft-ietf-oauth-device-flow-11: (with DISCUSS)

From: Mirja Kühlewind <[email-masked]>
Date: Tue, 24 Jul 2018 11:50:55 -0700

Mirja Kühlewind has entered the following ballot position for
draft-ietf-oauth-device-flow-11: Discuss

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/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Please specify more clearly the (default) polling behavior to ensure that the
polling does neither overload the network, nor the server, or is never
terminated. Ideally provide default values and an upper bound for the polling
frequency, as well as a timer to terminate polling if no reply is received (and
no expiration time is given). See further details below.

1) Sec 3.3: "until the user completes the interaction, the code expires, or
another
   error occurs."
What if not expiration time is given (as this optional) and no reply is ever
received?

2) Sec 3.5: "the client should stop polling and react accordingly, for
   example, by displaying an error to the user."
Maybe:
"the client MUST stop polling and SHOULD react accordingly, for
   example, by displaying an error to the user."

3) sec 3.5 "If no interval was provided, the client
   MUST use a reasonable default polling interval."
Can you please provide a default number for a "reasonable" polling interval!
And in best case an upper bound!

4) sec 3.5: "...increasing the time between polls if a
   "slow_down" error is received. "
Maybe use a separate normative sentence instead:
"The client SHOUD increase the time between polls if a
   "slow_down" error is received."
Or MUST? If so how much? Can you given further (default) guidance.

5) sec 3.5: "Clients MAY then choose to
   start a new device authorization session."
Maybe make it clear that polling is stopped
"Clients MUST stop polling but MAY then choose to
   start a new device authorization session."

6) sec 3.5: "then the
   device MAY wait until notified on that channel that the user has
   completed the action before initiating the token request."
Why not SHOULD (or MUST) here?