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