Re: [OAUTH-WG] Device Code expiration and syntax

[William Denniss <[e-mail]>]

Thanks for your review Mike, the PR
<https://github.com/WilliamDenniss/draft-ietf-oauth-device-flow/pull/3> has
been updated to address your comment.

On Sun, Mar 12, 2017 at 12:28 PM, Mike Jones <[e-mail]>
wrote:

> Thanks for doing this, William.  I added one comment to the pull request.
> After addressing it, I support this new version being published.
>
>
>
>                                                        -- Mike
>
>
>
> *From:* William Denniss [mailto:[e-mail]]
> *Sent:* Saturday, March 11, 2017 6:59 PM
> *To:* Mike Jones <[e-mail]>
> *Cc:* Justin Richer <[e-mail]>; <[e-mail]> <[e-mail]>
>
> *Subject:* Re: [OAUTH-WG] Device Code expiration and syntax
>
>
>
> Sure thing. Changes are staged here: https://github.com/Willi
> amDenniss/draft-ietf-oauth-device-flow/pull/3/files
>
>
>
> Includes the normative change suggested by Justin. PTAL.
>
>
>
> On Sat, Mar 11, 2017 at 1:46 PM, Mike Jones <[e-mail]>
> wrote:
>
> The pre-Chicago submission deadline is Monday afternoon (see
> http://ietf.org/meeting/important-dates.html#ietf98).  Would you have
> time to check proposed edits into GitHub for the editors to review before
> that, William?
>
>
>
>                                                        -- Mike
>
>
>
> *From:* OAuth [mailto:[e-mail]] *On Behalf Of *William
> Denniss
> *Sent:* Saturday, March 11, 2017 12:54 PM
> *To:* Justin Richer <[e-mail]>
> *Cc:* <[e-mail]> <[e-mail]>
> *Subject:* Re: [OAUTH-WG] Device Code expiration and syntax
>
>
>
>
>
> On Sat, Mar 11, 2017 at 12:40 PM, Justin Richer <[e-mail]> wrote:
>
>
>
> On Mar 11, 2017, at 2:54 PM, William Denniss <[e-mail]> wrote:
>
>
>
> On Sat, Mar 11, 2017 at 11:10 AM, Justin Richer <[e-mail]> wrote:
>
> We’re implementing support for the device code draft and had a question on
> what the “expiration” of the code refers to. Obviously, once the code has
> expired it can no longer be used. But when should the expiration count
> from? Say I have a code that’s good for 60 seconds, do I start the timer as
> soon as I issue the code to the client? Do I reset the timer when the user
> approves the client, to another 60 seconds? Or does that 60 seconds count
> for the entire transaction?
>
> My read on it is the latter-- one timeout for the entire lifetime of the
> code regardless of its current state, with no resets. But I didn’t find
> good guidance in the document itself.
>
>
>
> It's the expiry of the user_code and device_code pair, at which point the
> device will need to start-over with a new device authorization request.
> The device wouldn't *have* to start a timer, as they will get an error
> during polling:
>
>
>
>    expired_token
>
>       The "device_code" has expired.  The client will need to make a new
>
>       Device Authorization Request.
>
>
>
> We should add some guidelines around expiry behavior.
>
>
>
> OK, so it really is one expiration for the whole thing. The device doesn’t
> need to care (and I’ll bet you right now that, just like with access
> tokens, the overwhelmingly vast majority of devices won’t care about
> expires_in), but the authorization server certainly does, and we wanted to
> know the right place to set the timers.
>
>
>
>
>
> You're probably right that most ignore expires_in, and I think that's
> fine. As long as the client handles errors correctly, it'll work out OK.
>
>
>
> Agree that we should add some documentation. One piece of advice for the
> AS would be not to make it too short, else users won't be able to complete
> the flow in time.
>
>
>
> We use a 30 minute expiry.
>
>
>
>
>
> Secondly, I had a question about the “response_type” parameter to the
> device endpoint. This parameter is required and it has a single, required
> value, with no registry or other possibility of extension. What’s the
> point? If it’s for “parallelism”, I’ll note that this is *not* the
> authorization endpoint (as the user is not present) and such constraints
> need not apply here.
>
>
>
> Good points here. At a guess, it bled in from the OAuth spec. If it's not
> needed, we should remove it.
>
>
>
>
>
> I’d vote for removal, I don’t see the point.
>
>
>
>  — Justin
>
>
>
>
>
>
>