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

John Bradley <ve7jtb@ve7jtb.com> Fri, 28 April 2017 22:40 UTC

Return-Path: <ve7jtb@ve7jtb.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 8745A129B62 for <oauth@ietfa.amsl.com>; Fri, 28 Apr 2017 15:40:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.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 QsvrH6bu7ikx for <oauth@ietfa.amsl.com>; Fri, 28 Apr 2017 15:40:48 -0700 (PDT)
Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (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 382FD129AAC for <oauth@ietf.org>; Fri, 28 Apr 2017 15:38:19 -0700 (PDT)
Received: by mail-qt0-x22c.google.com with SMTP id c45so61153087qtb.1 for <oauth@ietf.org>; Fri, 28 Apr 2017 15:38:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=i+xXLHXvlGIawjK8domAKrUOqObEAzANjnu1sW/DrQE=; b=J7446tsOrtutsQTsBT8GvG+p2Jf3DCaaejEIAD465Ui8C9c1ZlRr2nAtuQ8ZswudD2 rGiRT0taXk35P+Rl4k/5gK8eA+6EuDVhztVkh6F3nl1cr1FHRQ9Ky09YaXHJFPIY1eMf cnhaJPM0d2xCXg4KazfmXsG2SV29HbWiY4G/P1t2H8YTjGkaUkX1+NTEMwbhBV+zJKbR ZgE2/h+wyZvdLvBkLg4Y/tKDJp0B5BTukM0LmgJWdMu8EiPtuR/087rFXBYLCQowg81B tzI7gKAtMaO2VseDFaqQgbmvan0ocj9qyXztMR1mHiwQTFV34th9vIkXVC8kMW5b5ABd I1rQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=i+xXLHXvlGIawjK8domAKrUOqObEAzANjnu1sW/DrQE=; b=HS5ZQ0J1bfJZR0ksHCjJEOvCjZXI2nhh06T7LxTBf7k+eDTIXeHAbp6fCKeFdK10Gx 4WYwAr4gb9gzTrjC6OVza+a9qk9lnkcxrzIZ8TRbkt/1aH/3DuPNAqjSNNd7mvD29Qo2 Pk06daAMNc0OkGn76QFnLrNsXBPVmu9L3oFe5bEFGeq7Epwqz0PSQ/5ZlA85vnj88Jz4 sj4/VrnQ5os8fVFUxr7lAJ5cft3yJ0BIJvR4HHtUoe1DlAqLDMU0tXRgzQoGmdLBbhDe M5SpKtkDRglwVdvFgZAW44uNa5gP22YWDMscK10cLbx15kE81QXF6rT9eYq5Bq4z/DIx hxEA==
X-Gm-Message-State: AN3rC/4vmDGCwF4pyQwi+ir1UdahfXb/Tk/g5ebCJTu8HspVdKevyXqj tZ/Wx4md8OhM83uJ
X-Received: by 10.200.42.199 with SMTP id c7mr13310401qta.102.1493419098087; Fri, 28 Apr 2017 15:38:18 -0700 (PDT)
Received: from [192.168.8.100] ([181.201.77.247]) by smtp.gmail.com with ESMTPSA id v64sm5390538qkg.38.2017.04.28.15.38.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Apr 2017 15:38:17 -0700 (PDT)
From: John Bradley <ve7jtb@ve7jtb.com>
Message-Id: <77856AF4-9B2E-4478-9509-1459037C24E4@ve7jtb.com>
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Fri, 28 Apr 2017 19:38:14 -0300
In-Reply-To: <CAAP42hDugtAz-7MaeVcNsS+Oza1GVKRyGm4vfR6Vj1DFF1-nag@mail.gmail.com>
Cc: "oauth@ietf.org" <oauth@ietf.org>, Hannes Tschofenig <hannes.tschofenig@gmx.net>, Michael Jones <Michael.Jones@microsoft.com>
To: William Denniss <wdenniss@google.com>
References: <CAAP42hDugtAz-7MaeVcNsS+Oza1GVKRyGm4vfR6Vj1DFF1-nag@mail.gmail.com>
X-Mailer: Apple Mail (2.3273)
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a11404eb0db1159054e41bac8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/4LCoP_4X6LTS8to5ehef55FStjs>
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: Fri, 28 Apr 2017 22:40:50 -0000

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