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

William Denniss <wdenniss@google.com> Fri, 28 April 2017 20:42 UTC

Return-Path: <wdenniss@google.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 73B181293FB for <oauth@ietfa.amsl.com>; Fri, 28 Apr 2017 13:42:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Status: No, score=-2.701 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, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id KVrKaoB7tylX for <oauth@ietfa.amsl.com>; Fri, 28 Apr 2017 13:42:04 -0700 (PDT)
Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (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 ABC91129BBF for <oauth@ietf.org>; Fri, 28 Apr 2017 13:39:42 -0700 (PDT)
Received: by mail-it0-x233.google.com with SMTP id 70so49347586ita.0 for <oauth@ietf.org>; Fri, 28 Apr 2017 13:39:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=PY4B2rToOhiczJwUvSC08tz6mafqQs2pV7avs58djng=; b=L8HqNCRcb6xUxszJndQO2ZnmRAJ6II8CCqfA9yG1mgPSTgRRoyZ8cl0TNh0Tdq7eGQ k07AL232cFO2AevKOQXMtomR2hurBVY9d8tLPV2fJWEBzmThE30R6c+RknwbbO8gsff9 FPwvZ/TpEn+LoHn7JrObymillrioJyiTOYn40cZV+s2KIPQ4AOTmXIez70UDZmHIwXz1 BxHTvJxahCfAeEdQITnGx+Hl6vQ7nszEJ6LWvZ4phGGGGljnkkj2xb52TdwqEXqC5WfR dNx9SH4ypXJUPb0QnyCnVPuawse0TqTBLWYvGVaW321cS4U2aCl9qn9LzznyaVjdeW6Y 4ZiA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=PY4B2rToOhiczJwUvSC08tz6mafqQs2pV7avs58djng=; b=HXcIx5lDepsmremH+xV7YYbrpXyaix6cSGGud0NYv4KGp2QEcTrGD14XI7QGr+1r6H hUvU2q6WCv5ZtbYr+uScJMh/NQVYyJwNMOIHntxmkKrE6cmP7rohDWypH4JzEAwkNSTp N9Y1VxSXggnZG3gn41MgImZ2M8WDxZZwRksfeaV218sspRt6d467QI+DUzU8DstuXpnw 2u3vneKK5FFOHweG2oPvWOeUzDTOj6j1/6xRdHBIjwPoj2kR2/YcZEW/WImFgqyZHyja 3yPLkUjv4KTqVXicBtWkpMi0KgUcdPbeVCnYoLXu2Z+1SeUklokt+ngega/ByepAVjUd GRKA==
X-Gm-Message-State: AN3rC/502lzr2RT/52eH8wMauyCXu9eHvy46c9IWp+lHmuGtK5jRoUJl XEGr/uqbqKdqf0kOKeLGHqPAXJ1Tfb+4tBk=
X-Received: by with SMTP id e5mr12290553ith.101.1493411981497; Fri, 28 Apr 2017 13:39:41 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 28 Apr 2017 13:39:20 -0700 (PDT)
From: William Denniss <wdenniss@google.com>
Date: Fri, 28 Apr 2017 13:39:20 -0700
Message-ID: <CAAP42hDugtAz-7MaeVcNsS+Oza1GVKRyGm4vfR6Vj1DFF1-nag@mail.gmail.com>
To: "oauth@ietf.org" <oauth@ietf.org>, John Bradley <ve7jtb@ve7jtb.com>, Hannes Tschofenig <hannes.tschofenig@gmx.net>, Mike Jones <Michael.Jones@microsoft.com>
Content-Type: multipart/alternative; boundary="94eb2c11c82ea98b52054e40126b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/DmCnMJR-bWqh2za1egH_OQl3m5Q>
Subject: [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 20:42:08 -0000

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