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

Simon Moffatt <simon.moffatt@forgerock.com> Tue, 02 May 2017 09:01 UTC

Return-Path: <simon.moffatt@forgerock.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B49811314DB for <oauth@ietfa.amsl.com>; Tue, 2 May 2017 02:01:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9fSeyiEVPb4E for <oauth@ietfa.amsl.com>; Tue, 2 May 2017 02:01:18 -0700 (PDT)
Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DCE812EC92 for <oauth@ietf.org>; Tue, 2 May 2017 01:56:49 -0700 (PDT)
Received: by mail-wm0-x229.google.com with SMTP id r190so11601670wme.1 for <oauth@ietf.org>; Tue, 02 May 2017 01:56:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; 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; d=1e100.net; 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 10.28.147.3 with SMTP id v3mr1285636wmd.45.1493715407385; Tue, 02 May 2017 01:56:47 -0700 (PDT)
Received: from [192.168.43.12] ([148.252.128.147]) by smtp.gmail.com with ESMTPSA id n99sm22174586wrb.62.2017.05.02.01.56.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 May 2017 01:56:45 -0700 (PDT)
To: Torsten Lodderstedt <torsten@lodderstedt.net>, Justin Richer <jricher@mit.edu>
References: <CAAP42hDugtAz-7MaeVcNsS+Oza1GVKRyGm4vfR6Vj1DFF1-nag@mail.gmail.com> <77856AF4-9B2E-4478-9509-1459037C24E4@ve7jtb.com> <22d06952-94ab-e6a9-d2b2-f96f8252bf5e@mit.edu> <4107AB98-25D8-4542-B932-CD6F921D0D1D@lodderstedt.net>
Cc: "oauth@ietf.org" <oauth@ietf.org>
From: Simon Moffatt <simon.moffatt@forgerock.com>
Message-ID: <5529a18f-0ebe-eeae-2de1-c4066cf986b3@forgerock.com>
Date: Tue, 2 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: <4107AB98-25D8-4542-B932-CD6F921D0D1D@lodderstedt.net>
Content-Type: multipart/alternative; boundary="------------30D8DE1442EB7F0C3CE2CD8D"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/yN2quxJSl27cgByDbuaqXIP6rGI>
Subject: Re: [OAUTH-WG] OAuth 2.0 Device Flow: IETF98 Follow-up
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=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.

SM


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 <jricher@mit.edu 
> <mailto:jricher@mit.edu>>:
>
>> +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 <wdenniss@google.com 
>>>> <mailto:wdenniss@google.com>> wrote:
>>>>
>>>> Thanks all who joined us in Chicago in person and remotely last 
>>>> month for the discussion on the device flow. [recording here 
>>>> <https://play.conf.meetecho.com/Playout/?session=IETF98-OAUTH-20170327-1710>;, 
>>>> 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 
>>>> <https://tools.ietf.org/html/draft-ietf-oauth-device-flow-05#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@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>> https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

-- 
ForgeRock <http://www.forgerock.com/> 	*Simon Moffatt*
Product Management  |  ForgeRock
*tel* +44 (0) 7903 347 240  | *e* Simon.Moffatt@Forgerock.com 
<mailto:simon.moffatt@forgerock.com>
*skype* simon.moffatt  | *web* www.forgerock.com 
<http://www.forgerock.com/>  | *twitter* @simonmoffatt


ForgeRock Live 2017 <https://summits.forgerock.com/>