Subject: [OAUTH-WG] Device profile draft

From: David Recordon <[email-masked]>
Date: Thu, 15 Jul 2010 12:47:02 -0700

I've broken the device profile out of draft 06 so that it now lives in a
separate document as an extension and have updated it to fit into the draft
10 structure. It defines a new "device endpoint" for the initial setup
request where the client gets the two codes and URL. It then uses the
existing token endpoint for polling for an access token.

Jim is currently working on an implementation of it and we're generally
looking for feedback from implementors. The current polling mechanism hasn't
been tested in production deployments so it's possible that it may change in
future drafts. My goal is for this to become a working group draft.

http://github.com/daveman692/OAuth-2.0/raw/master/draft-recordon-oauth-v2-device-00.txt

Thanks!

--David

---

From: George Fletcher <[email-masked]>
Date: Thu, 15 Jul 2010 16:05:26 -0400

Looks good.

Are there any restrictions on the device_code such that it has to be 
under a certain size? Seems like it would be good to protect against 
random polling attacks (I presume this is what the Google research 
refers to). If there are no size restrictions then the device_code could 
be an encrypted blob with things like the client IP which make 
verification that it's the right client a little stronger.

Also, for devices like a digital photo frame or refrigerator, it seems 
like client_secrets would be appropriate. Is there a particular reason 
while they are excluded rather than just optional?

Thanks,
George

On 7/15/10 3:47 PM, David Recordon wrote:
> I've broken the device profile out of draft 06 so that it now lives in 
> a separate document as an extension and have updated it to fit into 
> the draft 10 structure. It defines a new "device endpoint" for the 
> initial setup request where the client gets the two codes and URL. It 
> then uses the existing token endpoint for polling for an access token.
>
> Jim is currently working on an implementation of it and we're 
> generally looking for feedback from implementors. The current polling 
> mechanism hasn't been tested in production deployments so it's 
> possible that it may change in future drafts. My goal is for this to 
> become a working group draft.
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: David Recordon <[email-masked]>
Date: Thu, 15 Jul 2010 13:12:27 -0700

On Thu, Jul 15, 2010 at 1:05 PM, George Fletcher <[email-masked]> wrote:

>  Looks good.
>
> Are there any restrictions on the device_code such that it has to be under
> a certain size? Seems like it would be good to protect against random
> polling attacks (I presume this is what the Google research refers to). If
> there are no size restrictions then the device_code could be an encrypted
> blob with things like the client IP which make verification that it's the
> right client a little stronger.
>

No, there aren't currently any restrictions around the device_code. Just
needs to be something which the authorization server issues and the device
can hold onto for a few minutes.

The Google research is on the length of the user code since you want those
to be short and easy to type.

Also, for devices like a digital photo frame or refrigerator, it seems like
> client_secrets would be appropriate. Is there a particular reason while they
> are excluded rather than just optional?
>

Like with desktop apps, it's hard to guarantee that a device can keep
secrets. I should definitely discuss this in the security considerations.
There are basically two thoughts in terms of how to solve it:
1) Devices which have TPM can use it to sign requests and
thus securely authenticate themselves to authorization servers.
2) An authorization server can issue a second client secret which is only
for the device profile. If it is compromised then the client secret used by
the application's web servers would still be secure.

> [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>

---

From: "Zeltsan, Zachary (Zachary)" <[email-masked]>
Date: Thu, 15 Jul 2010 15:36:19 -0500

Section 1.5:

"The client makes the following request at an arbitrary but reasonable

interval which MUST NOT exceed the minimum interval rate provided by
  the authorization server (if present via the "interval" parameter)."

My understanding is that the intervals between the client's subsequent requests must not be less than the value provided by the "interval" parameter (if it is present). If that is correct than the intervals between the subsequent requests MUST exceed (or be equal to) the value of the "interval" parameter.

Section 1.4:

"interval

         OPTIONAL.  The minimum amount of time in seconds that the

         client SHOULD wait between polling requests to the token
         endpoint"

The definition uses the SHOULD requirement, while in section 1.5 the MUST requirement is used. Should not the requirement be the same in both places?

Zachary

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of David Recordon
Sent: Thursday, July 15, 2010 3:47 PM
To: OAuth WG
Cc: Jim Brusstar
Subject: [OAUTH-WG] Device profile draft

I've broken the device profile out of draft 06 so that it now lives in a separate document as an extension and have updated it to fit into the draft 10 structure. It defines a new "device endpoint" for the initial setup request where the client gets the two codes and URL. It then uses the existing token endpoint for polling for an access token.

Jim is currently working on an implementation of it and we're generally looking for feedback from implementors. The current polling mechanism hasn't been tested in production deployments so it's possible that it may change in future drafts. My goal is for this to become a working group draft.

Thanks!

--David

---

From: David Recordon <[email-masked]>
Date: Thu, 15 Jul 2010 14:11:16 -0700

On Thu, Jul 15, 2010 at 1:36 PM, Zeltsan, Zachary (Zachary) <
[email-masked]> wrote:

>  Section 1.5:
>
> “The client makes the following request at an arbitrary but reasonable
>
>   the authorization server (if present via the "interval" parameter).”
>
>
>
> My understanding is that the intervals between the client’s subsequent
> requests must not be less than the value provided by the “interval”
> parameter (if it is present). If that is correct than the intervals between
> the subsequent requests MUST exceed (or be equal to) the value of the
> “interval” parameter.
>
Thanks! Reworded to "The client makes the following request at an arbitrary
but reasonable interval which MUST NOT be less than the minimum interval
rate provided by the authorization server"

Section 1.4:
> “interval
>          endpoint”
> The definition uses the SHOULD requirement, while in section 1.5 the MUST
> requirement is used. Should not the requirement be the same in both places?
>
Changed this should to a must.

>
>
> Zachary
>
>
>  ------------------------------
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *David Recordon
> *Sent:* Thursday, July 15, 2010 3:47 PM
> *To:* OAuth WG
> *Cc:* Jim Brusstar
> *Subject:* [OAUTH-WG] Device profile draft
>
>
>

---

From: Michael D Adams <[email-masked]>
Date: Thu, 15 Jul 2010 14:31:53 -0700

On Thu, Jul 15, 2010 at 2:11 PM, David Recordon <[email-masked]> wrote:
> On Thu, Jul 15, 2010 at 1:36 PM, Zeltsan, Zachary (Zachary)

It still sounds confusing to me.  Part of the problem is that we're
talking both about an interval (a length of time) and a frequency
(requests per unit of time).

How about:

The client makes the next request after an arbitrary but reasonable
length of time, which MUST be longer than or equal to the minimum
length of time provided by the authorization server in the "interval"
parameter if present.

I changed "following" to "next" because the former makes it sound like
the next paragraph will have details about the request.

I changed "at an arbitrary" to "after an arbitrary" since we're
talking here about lengths of time.

I replaced "interval" with "length of time" to make it clear we're
talking about the length of time and not the corresponding frequency.

Mike
--mdawaffe

---

From: David Recordon <[email-masked]>
Date: Thu, 15 Jul 2010 14:41:35 -0700

Even better, thanks!