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:[email protected]] On Behalf Of William Denniss
Sent: Saturday, March 11, 2017 12:54 PM
To: Justin Richer <[email protected]>
Cc: <[email protected]> <[email protected]>
Subject: Re: [OAUTH-WG] Device Code expiration and syntax
On Sat, Mar 11, 2017 at 12:40 PM, Justin Richer
<[email protected]<mailto:[email protected]>> wrote:
On Mar 11, 2017, at 2:54 PM, William Denniss
<[email protected]<mailto:[email protected]>> wrote:
On Sat, Mar 11, 2017 at 11:10 AM, Justin Richer
<[email protected]<mailto:[email protected]>> 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
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
