Re: [OAUTH-WG] Device profile draft

[David Recordon <[e-mail]>]

On Thu, Jul 15, 2010 at 1:05 PM, George Fletcher <[e-mail]> 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.



> 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.
>
>
> http://github.com/daveman692/OAuth-2.0/raw/master/draft-recordon-oauth-v2-device-00.txt
>
>  Thanks!
>
>  --David
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]://www.ietf.org/mailman/listinfo/oauth
>
>