Subject: Re: [OAUTH-WG] Device flow clarifications

From: William Denniss <[email-masked]>
Date: Fri, 8 Jul 2016 16:37:38 -0700

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-masked]> 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-masked]>
> 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-masked]] *On Behalf Of *Alex Bilbie
>> *Sent:* Friday, April 15, 2016 13:32
>> *To:* [email-masked]
>> *Subject:* [OAUTH-WG] Device flow clarifications
>>
>>
>>
>> N.B: I sent the following email to
>> [email-masked] 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-masked]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>

---

From: Brian Campbell <[email-masked]>
Date: Fri, 8 Jul 2016 19:56:59 -0600

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-masked]> wrote:

>>> 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.
>>>
>>>
>>>

---

From: Aaron Parecki <[email-masked]>
Date: Sat, 9 Jul 2016 10:22:33 -0700

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

On Fri, Jul 8, 2016 at 6:56 PM, Brian Campbell <[email-masked]>
wrote:

> 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.
>
>
>
>>>> described at
>>>> https://tools.ietf.org/html/draft-ietf-oauth-device-flow-01

---

From: William Denniss <[email-masked]>
Date: Sat, 9 Jul 2016 11:11:21 -0700

On Sat, Jul 9, 2016 at 10:22 AM, Aaron Parecki <[email-masked]> wrote:

> 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.
>

Good idea, thanks!  https://github.com/aaronpk/oauth.net/pull/125

> On Fri, Jul 8, 2016 at 6:56 PM, Brian Campbell <[email-masked]
> > wrote:
>
>> <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.
>>
>>
>>
>>>>> 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.
>>>>>
>>>>>
>>>>>
>>>>> I've been working on an implementation of the OAuth 2.0 Device Flow
>>>>> (as described at

---

From: William Denniss <[email-masked]>
Date: Sat, 9 Jul 2016 11:28:40 -0700

> I hate to be pedantic but... well, here goes.

Thanks for your review, it's important to get this right :-)

> for grant_type values so name collisions are avoided via the use of URIs.

Glad you pointed this out.  I had assumed there was a registry for
base-level strings, and only non-standard extensions would need a URI, but
you're right.

> relationship with or control of.
>

I agree, it was never my proposal to use that, I was just pointing out that
our current implementation does. My plan would be to release a new version
of our endpoint once the spec is near-final, to conform to the standard.

> RFC 6755 <https://tools.ietf.org/html/rfc6755> exists specifically for
> the purpose of obtaining/registering such URIs and even has an example

That example is useful. So what do people think about standardizing on:

*urn:ietf:params:oauth:grant-type:device_code*

---

From: Brian Campbell <[email-masked]>
Date: Sat, 9 Jul 2016 13:49:52 -0600

> Thanks for your review, it's important to get this right :-)

Well, I haven't actually reviewed the draft yet. But I will. I just noticed
the email thread. 6755 was my first RFC so I'm kind of partial to it
getting used :)

> base-level strings, and only non-standard extensions would need a URI, but

That probably would have been a better way for 6749 to have set things up
but that's water under the bridge at this point.

> I agree, it was never my proposal to use that, I was just pointing out
> that our current implementation does.
>

I figured. I was just looking to head-off the potential suggesting coming
from elsewhere.

> My plan would be to release a new version of our endpoint once the spec is
> near-final, to conform to the standard.
>

Excellent.

> *urn:ietf:params:oauth:grant-type:device_code*

Works for me.