Re: [OAUTH-WG] OAuth 2.0 Device Flow: IETF98 Follow-up

Justin Richer <> Sat, 29 April 2017 13:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BF587129438 for <>; Sat, 29 Apr 2017 06:12:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.3
X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id C4vBjGn-mBu8 for <>; Sat, 29 Apr 2017 06:12:55 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DBF80127136 for <>; Sat, 29 Apr 2017 06:12:26 -0700 (PDT)
X-AuditID: 1209190f-6afff70000006010-bf-59049139027c
Received: from ( []) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id B8.5B.24592.93194095; Sat, 29 Apr 2017 09:12:25 -0400 (EDT)
Received: from ( []) by (8.13.8/8.9.2) with ESMTP id v3TDCO7Q024273; Sat, 29 Apr 2017 09:12:24 -0400
Received: from [] ( []) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by (8.13.8/8.12.4) with ESMTP id v3TDCL0N031845 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 29 Apr 2017 09:12:23 -0400
To: John Bradley <>, William Denniss <>
Cc: "" <>
References: <> <>
From: Justin Richer <>
Message-ID: <>
Date: Sat, 29 Apr 2017 09:12:10 -0400
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.0.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------5C7FE7964D71EAF9D5E6EDC7"
Content-Language: en-US
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCKsWRmVeSWpSXmKPExsUixG6nrms5kSXS4PRaBYuTb1+xWay++5fN YtOcZnYHZo8Fm0o9liz5yeRx+/ZGlgDmKC6blNSczLLUIn27BK6MRe9/sRZsS61Y+KyJsYHx sHsXIyeHhICJxKz+7cxdjFwcQgJtTBJfr29mhXA2Mkpc2LqRCaRKSOA2k0T/f28QW1jAXuLy nC4WEFtEwFvi3fe/jCA2s4CqxJcF75kgmlsYJTbMXs4MkmADSkxf0wKU4ODgFbCS+HyrBiTM AhS+1zKLDcQWFYiReNmzFaycV0BQ4uTMJ2DzOQXsJLo+3mKHmB8m8edCLwuELS5x68l8pgmM ArOQtMxCUjYLSRmEbSYxb/NDZghbXqJ562wgmwPIVpNY1qqELLyAkX0Vo2xKbpVubmJmTnFq sm5xcmJeXmqRrolebmaJXmpK6SZGUGRwSvLvYJzT4H2IUYCDUYmHt8ODOVKINbGsuDL3EKMk B5OSKG8VB0ukEF9SfkplRmJxRnxRaU5q8SFGCQ5mJRHev+1AOd6UxMqq1KJ8mJQ0B4uSOK+4 RmOEkEB6YklqdmpqQWoRTFaGg0NJgtdsAlCjYFFqempFWmZOCUKaiYMTZDgP0HAOkBre4oLE 3OLMdIj8KUZFKXHeyH6ghABIIqM0D64XlLgS3h42fcUoDvSKMG8mSDsPMOnBdb8CGswENLhe DWxwSSJCSqqBcae+Y6yPnMvDxaGT7mx9f8VCSnXCL4Gq3LsyHzb8Ociz/ZrO9advFny1irGf w1r2/FGnbV5BxqeW0z6Mq49LcMy8Puuh5aqrZ0N+tGdty76bMnUJf+bdfZv9Kx7cDDhc8GHr tIAJy79Z7l0r/YDBa8OToh2lj8KS91tr+yxOPX3vq6qUa9vjr7uVWIozEg21mIuKEwEX0/Ai NwMAAA==
Archived-At: <>
Subject: Re: [OAUTH-WG] OAuth 2.0 Device Flow: IETF98 Follow-up
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 29 Apr 2017 13:12:58 -0000

+1, documentation is better. Though we also need to keep in mind that 
this was the justification for the password flow in 6749, which has been 
abused all over the place (and continues to this day). Still, it would 
be arguably worse without that so I'm good with keeping the parameter in 
there as long as we're careful.

Namely: So long as the user code is *also* delivered separately to the 
user, we would have interoperability between the two. What I don't think 
we want is some systems that *require* the URI parameter on the approval 
URL and other implementations that *forbid* it. That case could end up 
with something like: I've got a set-top system that's incapable of 
displaying a separate user code because it always assumes it's baked 
into the URL, and then I try to put it on a server that requires the 
code be entered separately.

The resulting spec needs to be clear that the box MUST be able to 
display both the URL and the code separately, in case the URL does not 
include the code. In fact, maybe we'd even want to introduce a new 
parameter from the endpoint for the pre-composed URL:

       REQUIRED.  The end-user verification code.

       REQUIRED.  The end-user verification URI on the authorization
       server.  The URI should be short and easy to remember as end-
       users will be asked to manually type it into their user-agent.

       OPTIONAL.  The end-user verification URI with the end-user
       verification code already included. See discussion in [blah]
       for its use.

  -- Justin

On 4/28/2017 6:38 PM, John Bradley wrote:
> I would like to keep the optional parameter.   It is useful enough 
> that if we don’t have it people will add it on there own as a custom 
> parameter.
> Better to document any issues.
> John B.
>> On Apr 28, 2017, at 5:39 PM, William Denniss < 
>> <>> wrote:
>> Thanks all who joined us in Chicago in person and remotely last month 
>> for the discussion on the device flow. [recording here 
>> <>, 
>> presentation starts at about 7min in].
>> The most contentious topic was addition of the user_code URI param 
>> extension (introduced in version 05, documented in Section 3.3 
>> <>).
>> I'd like to close out that discussion with a decision soon so we can 
>> advance to a WG last call on the draft.
>> To summarise my thoughts on the param:
>>  1. It can be can be used to improve usability – QR codes and NFC can
>>     be used with this feature to create a more delightful user
>>     authorization experience.
>>  2. It may increase the potential phishing risk (which we can
>>     document), as the user has less typing. This risk assessment is
>>     likely not one-size-fits-all, it may vary widely due to different
>>     the different potential applications of this standard.
>>  3. The way it's worded makes it completely optional, leaving it up
>>     to the discretion of the authorization server on whether to offer
>>     the optimisation, allowing them to secure it as best they see it.
>>  4. I do believe it is possible to design a secure user experiance
>>     that includes this optimization.
>> I think on the balance, it's worthwhile feature to include, and one 
>> that benefits interop. The authorization server has complete control 
>> over whether to enable this feature – as Justin pointed out in the 
>> meeting, it degrades really nicely – and should they enable it, they 
>> have control over the user experiance and can add whatever phishing 
>> mitigations their use-case warrants.  Rarely is there a 
>> one-size-fits-all risk profile, use-cases of this flow range widely 
>> from mass-market TV apps to internal-only device bootstrapping by 
>> employees, so I don't think we should be overly prescriptive.
>> Mitigating phishing is already something that is in the domain of the 
>> authorization server with OAuth generally, and I know that this is an 
>> extremely important consideration when designing user authorization 
>> flows. This spec will be no exception to that, with or without this 
>> optimization.
>> That's my opinion. I'm keen to continue the discussion from Chicago 
>> and reach rough consensus so we can progress forward.
>> Best,
>> William
> _______________________________________________
> OAuth mailing list