If you'd like to put up a web page at the http://oauth.net/grant_type/device/1.0 URI that Google is using, feel free to create it and send me a PR. I think it could be useful for developers if there is a minimal page there that talks about the device flow.
<https://github.com/aaronpk/oauth.net> <https://github.com/aaronpk/oauth.net> <https://github.com/aaronpk/oauth.net> <https://github.com/aaronpk/oauth.net>https://github.com/aaronpk/oauth.net ---- Aaron Parecki aaronparecki.com @aaronpk <http://twitter.com/aaronpk> On Fri, Jul 8, 2016 at 6:56 PM, Brian Campbell <[email protected]> wrote: > I hate to be pedantic but... well, here goes. > > Grant types other than those defined in RFC 6749 are supposed to be URIs > (see section 4.5 on Extension Grants > <https://tools.ietf.org/html/rfc6749#section-4.5>). There's no registry > for grant_type values so name collisions are avoided via the use of URIs. > > An IETF document like the Device Flow should probably use a stable IETF > URI rather than something under oauth.net, which it has no real > relationship with or control of. RFC 6755 > <https://tools.ietf.org/html/rfc6755> exists specifically for the purpose > of obtaining/registering such URIs and even has an example registration > request <https://tools.ietf.org/html/rfc6755#section-2.1> for a grant > type URI. > > > > On Fri, Jul 8, 2016 at 5:37 PM, William Denniss <[email protected]> > wrote: > >> I agree that the token request section was not well defined, using the >> OAuth 2.0 definition in this case isn't correct as there are unique aspects >> of the Device Flow grant_type that need to be specified >> >> I've posted an update that fleshes out the token request polling & >> response. https://tools.ietf.org/html/draft-ietf-oauth-device-flow-02 >> Section 3.2 referenced in the above email is now numbered 3.4 >> <https://tools.ietf.org/html/draft-ietf-oauth-device-flow-02#section-3.4> >> . >> >> I specified a grant_type value of "device_code" as it matches the >> convention for other OAuth grant types. Google's implementation >> <https://developers.google.com/identity/protocols/OAuth2ForDevices#obtainingatoken> >> currently uses a URI instead: http://oauth.net/grant_type/device/1.0. >> >> >> On Fri, Apr 15, 2016 at 3:42 PM, Aaron Parecki <[email protected]> wrote: >> >>> Hi Alex and Oli, >>> >>> I also believe you are correct. I posted a similar question a while ago >>> here: >>> >>> https://www.ietf.org/mail-archive/web/oauth/current/msg15139.html >>> >>> I had a couple other notes you may be interested in: >>> >>> https://www.ietf.org/mail-archive/web/oauth/current/msg15138.html >>> >>> My implementation of a server that implements the device flow is here, >>> although it actually acts as a proxy for existing OAuth services: >>> >>> https://github.com/aaronpk/TVAuthServer >>> >>> Cheers! >>> >>> ---- >>> Aaron Parecki >>> aaronparecki.com >>> @aaronpk <http://twitter.com/aaronpk> >>> >>> >>> On Fri, Apr 15, 2016 at 8:24 PM, Oli Dagenais <[email protected]> >>> wrote: >>> >>>> Hi Alex, >>>> >>>> >>>> >>>> I’m also working on an implementation based on the draft specification. >>>> I came to the same conclusion about linking to Section 4.1.3 of RFC6749. >>>> >>>> >>>> >>>> As for your second question, I also came to the same conclusion, which >>>> was confirmed by looking at the source code to the Active Directory >>>> Authentication Library (ADAL) for .NET (Azure Active Directory is my >>>> project’s first target). ADAL also sets the grant_type parameter to >>>> “device_code” (contrast this with the value originally in section 4.1.3). >>>> >>>> >>>> >>>> I am hoping to also test my implementation against other major server >>>> implementations (Google and Facebook come to mind) in the next few weeks >>>> and will report my findings to this mailing list. >>>> >>>> >>>> >>>> Cheers, >>>> >>>> - Oli >>>> >>>> >>>> >>>> -- >>>> >>>> Let me help you be awesome at what you do, using >>>> >>>> Microsoft Developer Tools >>>> >>>> +1 613-212-5551 >>>> >>>> >>>> >>>> *From:* OAuth [mailto:[email protected]] *On Behalf Of *Alex >>>> Bilbie >>>> *Sent:* Friday, April 15, 2016 13:32 >>>> *To:* [email protected] >>>> *Subject:* [OAUTH-WG] Device flow clarifications >>>> >>>> >>>> >>>> N.B: I sent the following email to >>>> [email protected] on 12th April but didn't >>>> receive a reply so am reposting here: >>>> >>>> >>>> >>>> --- >>>> >>>> >>>> >>>> Hello, >>>> >>>> >>>> >>>> I've been working on an implementation of the OAuth 2.0 Device Flow (as >>>> described at >>>> https://tools.ietf.org/html/draft-ietf-oauth-device-flow-01 >>>> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-ietf-oauth-device-flow-01&data=01%7c01%7colivida%40microsoft.com%7c1cf0164e15984b96d6ad08d36553de5e%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Aw6hIdrAeX5%2feexlbPdZZiOYNdD6ETBP2bwnVpAuBIY%3d> >>>> ). >>>> >>>> >>>> >>>> Please could the following points please be clarified: >>>> >>>> >>>> >>>> Section 3.2: "The client requests an access token by making an HTTP >>>> "POST" request to the token endpoint as described in Section 4.1.1 of >>>> [RFC6749]" >>>> >>>> >>>> >>>> Should this actually say Section 4.1.3 of RFC6749 which is the Access >>>> Token Request section for the authorisation code grant? >>>> >>>> >>>> >>>> Assuming the above is true, should the `code` parameter POSTed to the >>>> authorisation server be the value of the `device_code` parameter returned >>>> to the client in the initiating request? >>>> >>>> >>>> >>>> Many thanks, >>>> >>>> >>>> >>>> Alex Bilbie >>>> >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >> >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth >> >> >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
