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

From: Justin Richer <[email-masked]>
Date: Sat, 11 Mar 2017 14:10:04 -0500

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.

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.

 — Justin

---

From: William Denniss <[email-masked]>
Date: Sat, 11 Mar 2017 11:54:14 -0800

On Sat, Mar 11, 2017 at 11:10 AM, Justin Richer <[email-masked]> 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.

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.

---

From: Justin Richer <[email-masked]>
Date: Sat, 11 Mar 2017 15:40:57 -0500

> On Mar 11, 2017, at 2:54 PM, William Denniss <[email-masked]> wrote:
> 
> On Sat, Mar 11, 2017 at 11:10 AM, Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
> 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

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.

> 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

---

From: William Denniss <[email-masked]>
Date: Sat, 11 Mar 2017 12:54:17 -0800

On Sat, Mar 11, 2017 at 12:40 PM, Justin Richer <[email-masked]> 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
> 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.

---

From: Mike Jones <[email-masked]>
Date: Sat, 11 Mar 2017 21:46:12 +0000

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-masked]] On Behalf Of William Denniss
Sent: Saturday, March 11, 2017 12:54 PM
To: Justin Richer <[email-masked]>
Cc: <[email-masked]> <[email-masked]>
Subject: Re: [OAUTH-WG] Device Code expiration and syntax

On Sat, Mar 11, 2017 at 12:40 PM, Justin Richer <[email-masked]<mailto:[email-masked]>> wrote:

On Mar 11, 2017, at 2:54 PM, William Denniss <[email-masked]<mailto:[email-masked]>> wrote:

On Sat, Mar 11, 2017 at 11:10 AM, Justin Richer <[email-masked]<mailto:[email-masked]>> 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?

   expired_token

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.

 — Justin

---

From: William Denniss <[email-masked]>
Date: Sat, 11 Mar 2017 18:59:21 -0800

Sure thing. Changes are staged here:
https://github.com/WilliamDenniss/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 <[email-masked]>
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:[email-masked]] *On Behalf Of *William
> Denniss
> *Sent:* Saturday, March 11, 2017 12:54 PM
> *To:* Justin Richer <[email-masked]>
> *Cc:* <[email-masked]> <[email-masked]>
> *Subject:* Re: [OAUTH-WG] Device Code expiration and syntax
>
>
>
>
>
> 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.
>
>
>

---

From: Mike Jones <[email-masked]>
Date: Sun, 12 Mar 2017 19:28:52 +0000

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:[email-masked]]
Sent: Saturday, March 11, 2017 6:59 PM
To: Mike Jones <[email-masked]>
Cc: Justin Richer <[email-masked]>; <[email-masked]> <[email-masked]>
Subject: Re: [OAUTH-WG] Device Code expiration and syntax

Sure thing. Changes are staged here: https://github.com/WilliamDenniss/draft-ietf-oauth-device-flow/pull/3/files

On Sat, Mar 11, 2017 at 1:46 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> 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:[email-masked]<mailto:[email-masked]>] On Behalf Of William Denniss
Sent: Saturday, March 11, 2017 12:54 PM
To: Justin Richer <[email-masked]<mailto:[email-masked]>>
Cc: <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>>
Subject: Re: [OAUTH-WG] Device Code expiration and syntax

   expired_token

 — Justin

---

From: William Denniss <[email-masked]>
Date: Sun, 12 Mar 2017 14:42:30 -0700

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 <[email-masked]>
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:[email-masked]]
> *Sent:* Saturday, March 11, 2017 6:59 PM
> *To:* Mike Jones <[email-masked]>
> *Cc:* Justin Richer <[email-masked]>; <[email-masked]> <[email-masked]>
>
> Sure thing. Changes are staged here: https://github.com/Willi
> amDenniss/draft-ietf-oauth-device-flow/pull/3/files
>
>
>

---

From: Brian Campbell <[email-masked]>
Date: Mon, 13 Mar 2017 05:47:39 -0600

>> I’d vote for removal, I don’t see the point.
+1 on removal of the “response_type” parameter from the Device
Authorization Request

---

From: John Bradley <[email-masked]>
Date: Wed, 15 Mar 2017 20:15:20 -0300

I think response mode is only needed if you are overloading a existing authorization endpoint.

URI are cheep so I don’t see the value.

> On Mar 13, 2017, at 8:47 AM, Brian Campbell <[email-masked]> wrote:
> 
> 
> 
> On Sat, Mar 11, 2017 at 1:54 PM, William Denniss <[email-masked] <mailto:[email-masked]>> wrote:
> 
> On Sat, Mar 11, 2017 at 12:40 PM, Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> 
> +1 on removal of the “response_type” parameter from the Device Authorization Request
>  
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: William Denniss <[email-masked]>
Date: Wed, 15 Mar 2017 16:18:31 -0700

Yes, I think this bled over from the original spec.

Google's Device endpoint doesn't use a response_type param.

It's removed in -05.

---

From: Justin Richer <[email-masked]>
Date: Thu, 16 Mar 2017 10:05:49 -0400

Funny thing, I went to remove it from our implementation, and we were 
already ignoring it completely.

Also, our implementation was just pushed to the master branch and will 
be in the next release: 
https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server/

  -- Justin

On 3/15/2017 7:18 PM, William Denniss wrote:
> On Wed, Mar 15, 2017 at 4:15 PM, John Bradley <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>>     On Mar 13, 2017, at 8:47 AM, Brian Campbell
>>     <[email-masked] <mailto:[email-masked]>>
>>     wrote:
>>
>>
>>
>>     On Sat, Mar 11, 2017 at 1:54 PM, William Denniss
>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>
>>         On Sat, Mar 11, 2017 at 12:40 PM, Justin Richer
>>         <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>
>>>
>>>                 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.
>>>
>>
>>     [email-masked] <mailto:[email-masked]>
>>     <https://www.ietf.org/mailman/listinfo/oauth>
>
>
>
>