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

Rifaat Shekh-Yusef <> Mon, 08 May 2017 13:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A82EF129467 for <>; Mon, 8 May 2017 06:02:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fVt-P96T2qJj for <>; Mon, 8 May 2017 06:02:23 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400c:c08::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EAC3B129465 for <>; Mon, 8 May 2017 06:02:22 -0700 (PDT)
Received: by with SMTP id e55so40261646uaa.2 for <>; Mon, 08 May 2017 06:02:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=SXnegd+RCc48ZHH6jHdpDSUPoHc+XPUlMgTCMA5fSaI=; b=WVpnP/JDPID8xOMui4m31+HjflOPJf3jEVsY/PZYwxGPr2DkQHYgH9/LlOr1kmNeJy yfumkds+q/mDohMym9j4FadA3gBzD7yiUkWBqAsCDjWtrUPl8sSg/l5jhLOzT3jQijj4 +vzlvgyUaMvNMc6mAy4e7LrE+8+zyflkFjo63bO2VeKwmXzcyzd5CyAVJ/9sVFOhmtaO /cENVo9IJQu9Js7YzCWag7QT0hRvUIHihWn+3RiuJtabN33asVyLOtoq1f9GkOws5ZYa kTLIfeQOsX+xNT8YPCiEtX6RSIobxCTPumeMP/B/I9TLey9SMpQA7sQoMOfgRbPeUrZc 4qIA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=SXnegd+RCc48ZHH6jHdpDSUPoHc+XPUlMgTCMA5fSaI=; b=uIxAakf5MZLYRdedZQr5w0e0V/KJeoQC3nKb+F+FvdOnI+UyzC2YURmxuoXWvyX2DB EHxNp8RFz28rETXQ1YILBJMGI2+B+pLolVqUZlitHEKrSUUhVEiZ2PjBCijI+mVuSxlM yrd4P1txKYCPFOS4hOZaMUbnNazloMfkdrLqya5i9SAbvxB4irs4v2Z7t3T6lIibpLV3 gOPTK6mqyhN+kb1Rz/ePBJuh96ea3uWkJPrkRy7uu3iEYewTwXJ3Eg4W+Rw6bipRC8uB 0jjlCvvIvGpkUkKe65ESqd+UjuRIFvl1pRQSY+ejAGZV5udqWQiLCJaXSqXyJkG7+ucX L0MQ==
X-Gm-Message-State: AN3rC/6vklWoP4558y4RMILbKjlKWKdf+MQytYgCBz/S87SiN/OFF6uZ F+p5MQobVY460dErk1sOx9L21cwFmC1P
X-Received: by with SMTP id g63mr15397719uag.52.1494248541749; Mon, 08 May 2017 06:02:21 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 8 May 2017 06:02:21 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <>
From: Rifaat Shekh-Yusef <>
Date: Mon, 08 May 2017 09:02:21 -0400
Message-ID: <>
To: Simon Moffatt <>
Cc: Torsten Lodderstedt <>, Justin Richer <>, "" <>
Content-Type: multipart/related; boundary="94eb2c122e648c1039054f02d9ca"
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: Mon, 08 May 2017 13:02:30 -0000


Hannes and I discussed the Device Flow draft. Based on the mailing list
feedback, we see that there is a good support for keeping the "user_code"
parameter in, but there is a need to document the security implication of
this feature. If anyone is against keeping this feature, please speak up


Can you please update the document based on the feedback you received so
We would like to start a WGLC after we get the new version of the draft.

We also have few comments on v05 of the draft:

Section 3.3, second paragraph:

   The document should explicitly state that this step must be done over an
   HTTPS channel.

   Also, the paragraph is talking about an "end-user" performing the
   procedure. This could be done by an administrator that has a long list
   of devices, e.g. IoT devices, that support this mechanism. So, maybe the
   document should clearly state that too.


Section 3.3, 3rd paragraph, second line:
   Remove the "a" before "the browser"

Section 5.2, 1st paragraph, second line:
   Remove the word "they" after "attacker"

 Rifaat & Hannes

On Tue, May 2, 2017 at 4:56 AM, Simon Moffatt <>

> +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 <>:
> +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 listOAuth@ietf.org
> _______________________________________________
> OAuth mailing list
> _______________________________________________
> OAuth mailing listOAuth@ietf.org
> --
> [image: ForgeRock] <> *Simon Moffatt*
> Product Management  |  ForgeRock
> *tel* +44 (0) 7903 347 240 <+44%207903%20347240>  |  *e*
> <>
> *skype* simon.moffatt  |  *web*  |  *twitter*
> @simonmoffatt
> [image: ForgeRock Live 2017] <>
> _______________________________________________
> OAuth mailing list