Re: [OAUTH-WG] FW: draft-ietf-oauth-device-flow: url with code

William Denniss <> Wed, 01 March 2017 00:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B80DE1297A7 for <>; Tue, 28 Feb 2017 16:40:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 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, URIBL_BLOCKED=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 ZGftkpVkL9i3 for <>; Tue, 28 Feb 2017 16:40:12 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3486F1293EB for <>; Tue, 28 Feb 2017 16:40:12 -0800 (PST)
Received: by with SMTP id n186so45031834qkb.3 for <>; Tue, 28 Feb 2017 16:40:12 -0800 (PST)
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=SC9FWkjsTqufscfWbi4iNX21ZF38Y6VVSVm48Ep75FM=; b=X3JMk6eZpv7IKTLtzgwmRqUipPtc2hvEclASFFdaVhGG6RY6Bxkp9xnYVh6jMJOWUz yRYaREBS/jqEr9glPE9XB/xiH9ImPf2TB1+fQV6mVrRn3S8eD+JNnzwBVzig3cb9A+Lj 1itJCZrkBj+7RQ+KnqoJPSiI9EausvkRypmx5pO7fSiRL2JONGOuKNTrUrSXSz1JkLni r+0aBz2XwxmAEwOVTcbKffdMkH42WRwb8V5LipJDqv7XD2T5opn5ia3Ah8luoCLSNFcg gFnZuqBTshNuTKQptHoZOKl2B6BlXYWJMY9xeJUkalBWPQoDoohCL89HwF+DGpD02aEd z6qg==
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=SC9FWkjsTqufscfWbi4iNX21ZF38Y6VVSVm48Ep75FM=; b=LuQ7nf5JwT6LOqHNHNJvARCEm/1ITRWlWTgyIlh575XvXqAoVYa8HBb9C2W9TQ+J6u 9n60+U0EERH4vbJ5D0aC9q7SviW8cTouufzYKA1r9uisQ0GjmEHXHHwBijpMvb3jXRu9 Er5dTfg74tnYVPGvLjs8BCuI6ifBrtDHy6o9n3IFnA0oWEa0+3Tyv7tlSOBQa+L1DMla IgLMpDLRVXIdI4p0yHmkL7zbKOhuxLYEvZljaab2mltcbV2vIDDXx23ya7aQduUIStTb +cr4h62am3zWdzfXUURyJVwka9pxbnhf0ZEgompJ58Mzz1v9AXE9nnCY2vbsjNqc7pGr G7YA==
X-Gm-Message-State: AMke39mhDz/rxHBBIR3ops4fftQ29WGvnjESQT2p7GLLVZ2oCwFemotTlPO4yJxtElVikFQN+t/EYAPzGHVJJ2YZ
X-Received: by with SMTP id l9mr6866150qtf.198.1488328810996; Tue, 28 Feb 2017 16:40:10 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Tue, 28 Feb 2017 16:39:50 -0800 (PST)
In-Reply-To: <>
References: <>
From: William Denniss <>
Date: Tue, 28 Feb 2017 16:39:50 -0800
Message-ID: <>
To: "Manger, James" <>
Content-Type: multipart/alternative; boundary="001a1140868a1713190549a08e77"
Archived-At: <>
Cc: "" <>, "" <>
Subject: Re: [OAUTH-WG] FW: draft-ietf-oauth-device-flow: url with code
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 01 Mar 2017 00:40:15 -0000

Thanks for your review James!

On Tue, Feb 28, 2017 at 4:23 PM, Manger, James <> wrote:

> Resending; not sure that OAuth email list is working at the moment.
> *From:* Manger, James
> *Sent:* Tuesday, 28 February 2017 9:53 AM
> *To:*
> *Subject:* draft-ietf-oauth-device-flow: url with code
> How about combining the verification_uri and user_code?
> The Device Flow provides a verification_uri and user_code, both of which
> have to be copied to a web browser on, say, a mobile phone. The main model
> in this draft is that the user copies the uri, then the resulting web page
> prompts for the code.

Correct. And note that there is a high probability that the user will make
errors, one reason why it's better for them to get the URI input first
(which may get browser auto-complete), before asking for the code.

> The draft also mentions other possibilities such as Bluetooth to do the
> “copying”. Transmitting a URI via Bluetooth, or NFC, or QR code, is quite
> common. In such cases it would be nicer to transmit the user_code as part
> of the URI.

I don't really see the benefit.

If you're doing some kind of out-of-band transmission (which is mentioned
as out of scope of the spec) there's no reason you can't simply transmit
both pieces of information.  We've done that before, and this is what we
do.  Having the data separate did not really alter the implementation of
this, and combining it wouldn't measurably make it simpler (but it would
make the spec more complex).

Also if the AS really wanted to, there's nothing to stop it including
whatever parameters it wanted in the verification URI today (which could
include the user code).

So I'd prefer to keep 1 protocol, designed for the browser model (which is
the only thing in-scope in the spec), that can potentially work with a wide
range of cases.

> Perhaps both modes could be supported by saying the user_code can be
> included as a query parameter on the verification_uri when it is more
> convenient for a device to transmit a single URI. Authorization Servers
> MUST accept this. The choice is to use user_code as the complete query
> string (eg or specify a “code”
> parameter name (eg

-1. I know for sure Google's AS will not comply with that MUST. As it is
there are some phishing concerns around this flow (documented in the spec),
and this change unfortunately makes the matter worse by allowing for
single-click phishing.

For example, we use the text today: "Enter the code displayed on your
device". And we display a picture picture of the device to help guide the
user as to the expected usage of this flow (this by itself isn't everything
– but they are important hints).

> Recommending case-insensitive punctuation-ignoring alphabetic codes is
> good, but how does a user know this is the case for a particular code?
> Perhaps the advice needs to be to use a “fancy” input field with javascript
> to convert to uppercase as the user types and handle punctuation?

I believe that's covered:

   The server should ignore any characters like punctuation that are not
   in the user-code character set.  Provided that the character set
   doesn't include characters of different case, the comparison should
   be case insensitive.

> [§6.1] The example user code “WDJB-MJHT” doesn’t have “24^8 bits of
> entropy”, but “log2(24 ^ 8) = 36.7 bits of entropy”.

Good point.


> --
> James Manger
> On Mon, Feb 27, 2017 at 9:46 AM, <> wrote:
>         Title           : OAuth 2.0 Device Flow for Browserless and Input
> Constrained Devices
>         Filename        : draft-ietf-oauth-device-flow-04.txt
> Abstract:
>    This OAuth 2.0 authorization flow for browserless and input
>    constrained devices, often referred to as the device flow, enables
>    OAuth clients to request user authorization from devices that have an
>    Internet connection, but don't have an easy input method (such as a
>    smart TV, media console, picture frame, or printer), or lack a
>    suitable browser for a more traditional OAuth flow.  This
>    authorization flow instructs the user to perform the authorization
>    request on a secondary device, such as a smartphone.  There is no
>    requirement for communication between the constrained device and the
>    user's secondary device.