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

[William Denniss <[e-mail]>]

Mirja,

Thanks for your feedback. Version 12 has been posted which incorporates
much of your feedback. Replies inline:

On Tue, Jul 24, 2018 at 11:50 AM, Mirja Kühlewind <[e-mail]>
wrote:
>
> ----------------------------------------------------------------------
> 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?
>

The expiration time is now required.


>
> 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."
>
>
Added, thanks!


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

We set a default of 5 seconds.


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

We now document that every slow_down message should increase the interval
by 5 seconds.


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

This was revised, thank you!


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

This is a non-normative discussion of a potential optimization, perhaps we
should drop the normative keyword completely?

The reason MAY was chosen is that the client would be free to follow the
rest of this document which allows for polling.

Best,
William