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 <wdenn...@google.com> 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 <aa...@parecki.com> 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 <oliv...@microsoft.com> >> 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:oauth-boun...@ietf.org] *On Behalf Of *Alex Bilbie >>> *Sent:* Friday, April 15, 2016 13:32 >>> *To:* oauth@ietf.org >>> *Subject:* [OAUTH-WG] Device flow clarifications >>> >>> >>> >>> N.B: I sent the following email to >>> draft-ietf-oauth-device-f...@tools.ietf.org 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 >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >> >> _______________________________________________ >> 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 > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
