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

Simon Moffatt <> Tue, 02 May 2017 09:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B49811314DB for <>; Tue, 2 May 2017 02:01:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9fSeyiEVPb4E for <>; Tue, 2 May 2017 02:01:18 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6DCE812EC92 for <>; Tue, 2 May 2017 01:56:49 -0700 (PDT)
Received: by with SMTP id r190so11601670wme.1 for <>; Tue, 02 May 2017 01:56:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=NgRsRVnl3xvaV354bgtmOz2EJFhiGJ4mGTEIv7KXPqc=; b=GPflGE+en+QqoDgk61K/aBgpbQGr8F3f6wjG+PKxF67c5g5owml2IAekR5Seib99e1 n0D2hsUC85Vqp13DQXgvXTylBZmIHKGjNEKw53ppj5vVjznWMo1fS/dZ5WZUGiYzxlme eT961S0crLiFbBIUPd6/FFvoLiIwwCyKHO8xY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=NgRsRVnl3xvaV354bgtmOz2EJFhiGJ4mGTEIv7KXPqc=; b=qyUtk1o+LU5mqlHlv5u9l4lElKHzBzDRNlKe59raHbAviphj2MajWVYucJkWZYBLGa o2MEQ9zwekGW0qbGePpaxfJaonk3SLzh5zsBfAPXuP6RW5v6JwzF1Zjo91UvnDs83X36 aTDapWI1R0ACs/M1mD98dqhZBGNkwbgU1fCabsYMz0S5+s/16Z1qJgQqZv9MmJTobbjN drqMkKNDtSPcWTssfAzDVP9wL1AceTjBoAmbzF2hr4dBFMMSJOvevVuGgvCIfxxLY2lX ugOH2zCE13yQfK1LofVCgD4B8wCizlBVJiDucxduxf8+kPeU8y/7hkhkUCpM9mX//ZvP QPMA==
X-Gm-Message-State: AN3rC/5adhLIcEFbFzkWipA+KMdW0iLJ3r7cGGtTqnCNcUqOMhkFZPUE 2VvrnofvDU5yotes56ibLfmEKcjnOy68wSsc8HHBKINa7/YlM6KYGMEdGBfo9PxMeyoNrvg2eyT qC5HYaLqgNwKZ6X0lllcSbIx8C2ggFBwPc8nXTWpto1/swnAZK0w=
X-Received: by with SMTP id v3mr1285636wmd.45.1493715407385; Tue, 02 May 2017 01:56:47 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id n99sm22174586wrb.62.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 May 2017 01:56:45 -0700 (PDT)
To: Torsten Lodderstedt <>, Justin Richer <>
References: <> <> <> <>
Cc: "" <>
From: Simon Moffatt <>
Message-ID: <>
Date: Tue, 02 May 2017 09:56:38 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------30D8DE1442EB7F0C3CE2CD8D"
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: Tue, 02 May 2017 09:01:22 -0000

+1 for separate. The real world implementations we've seen tend to not 
need the URL at all.  Eg end user out of band is in a web application on 
the their laptop/tablet and that app has a "pair device" area, where 
they just enter the necessary code - so they don't even need to see/use 
a URL from the device.

Having the code augmented in to the URL too opens up the ability for 
that code to be logged on intermediary network devices.


On 02/05/17 06:32, Torsten Lodderstedt wrote:
> +1 to keep the optional parameter along with clear wording regarding 
> security risk and interoperability
> Am 29.04.2017 um 15:12 schrieb Justin Richer < 
> <>>:
>> +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:
>>     user_code
>>        REQUIRED.  The end-user verification code.
>>     verification_uri
>>        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.
>>     composite_verification_uri
>>        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
>> _______________________________________________
>> OAuth mailing list
>> <>
> _______________________________________________
> OAuth mailing list

ForgeRock <> 	*Simon Moffatt*
Product Management  |  ForgeRock
*tel* +44 (0) 7903 347 240  | *e* 
*skype* simon.moffatt  | *web* 
<>  | *twitter* @simonmoffatt

ForgeRock Live 2017 <>