On Thu, Jul 15, 2010 at 1:05 PM, George Fletcher <gffle...@aol.com> 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 > oa...@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
