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

William Denniss <> Wed, 01 March 2017 02:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E24AA129473 for <>; Tue, 28 Feb 2017 18:48:19 -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 XTKCKr0I7zq4 for <>; Tue, 28 Feb 2017 18:48:18 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CC0ED129434 for <>; Tue, 28 Feb 2017 18:48:17 -0800 (PST)
Received: by with SMTP id s186so49821701qkb.1 for <>; Tue, 28 Feb 2017 18:48:17 -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=SprW0Nt3Eg4AfeZPCIQd3f9c7Xj2NSUr818TKyVRgfY=; b=LvyJqwDHtDuxkuru9ewlaMdwTHeFEzHqetkKNbcp0eCyKj1mhyXfd5wVPeLSOdoVWy dfN8CT0BkNsUw2p1LvLMp28F/mYnpw0K4M7PowQ0IVSXhCdIPL3dbwykNyJqm4wix36l sDw/O5oz5kcC0K6mH8nPC9ve2yxGAnD8zNMhDojNn8Wzk57eH/vPdrHlXlclNbLDw6VG kLWSm3ciGswfb/ej0R/49uf6sQQYnEsFVSDnUYZUYOmg28xtYtxBtB/SL7Ir6MUUk3O4 Am23AftVLCiX4zXWg8qy+klvRAAxPnFdTkxew3pjFAldq+QCAD+6v25+rHkB2R5mOixK XbEw==
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=SprW0Nt3Eg4AfeZPCIQd3f9c7Xj2NSUr818TKyVRgfY=; b=c5lRhG/Srq78Nvg7QF2ErgqbBB0jMtXPlIXVxqZXSKU0e1nDFcXn3SFY+0/P8Jili7 0nPZSNIxq1yhqDS8a+Yj4ZDxM2SCCrZ/8yF0aVIyrSk9FLJ3PYmq6U3LGVfgRZmsORus MMS84yoH5fyJt8oYqQAZy20BaocmaRMucK//aMZLQ4tM/wzaCZ5IB4dazRzqQBi983ml xJFwMObkLR9ra640mqcgmq0ZS0ifWZ3niGqajVrMXr4zkMDX9SJx8Da6kUzBXcLtCJEG 4WmNPMc2PtADnNYeSpCIooh7nUEjdvs7ZEKmxRdlSJPfQmNCUPkmD1Mf6kvlJRA6JN2a W3xA==
X-Gm-Message-State: AMke39kXJvASzzgZK+fBDhs3/IZbzbOelHS1V3ENSS8Eqfjw6TSt+0WI+CZ+uHViwBpxWdjDkpLbZ+dDMQAIFfSG
X-Received: by with SMTP id s4mr6766149qkd.101.1488336496591; Tue, 28 Feb 2017 18:48:16 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Tue, 28 Feb 2017 18:47:56 -0800 (PST)
In-Reply-To: <>
References: <> <> <>
From: William Denniss <>
Date: Tue, 28 Feb 2017 18:47:56 -0800
Message-ID: <>
To: "Manger, James" <>
Content-Type: multipart/alternative; boundary="94eb2c057a702fe0c20549a258e3"
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 02:48:20 -0000

On Tue, Feb 28, 2017 at 6:06 PM, Manger, James <James.H.Manger@team.telstra.
com> wrote:

> >>>
> >> 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 the device is always used with a pre-installed companion mobile app: no
> benefit.
> If the device has ample screen size for "To register, visit <uri> and
> enter <code>": no benefit.
> If the device can use NFC/BLE/QR-code/… to transmit a URI: benefit; can
> get verification_uri and user_code to a mobile browser without anything
> else (on the device or on the mobile).
> Scenario: a device with no screen, just a few LEDs; the instructions say
> "to activate, tap the device with your mobile (after enabling NFC or
> bluetooth)".
> User taps with mobile; browser launches; AS shows picture of device and
> asks user to confirm LEDs are flashing red/green/red/green… (on form with
> CSRF-protection); user click Yes; next device polling token request
> succeeds.
> This scenario is harder without a standard way to combine verification_uri
> and user_code into a single URI.

I don't see how this would be interoperable, how would the AS know about
the specifics of the device such as the color of the LEDs?  If you're
already relying on implementation specifics, like negotiating with the
client about the color of the LED, then you could also negotiate that the
code can be appended in any way that you both agree.  This is why I
suggested such advanced pairing would be out-of-scope.

I think a more plausible interop scenario would be that the URI and the
code are displayed as normal, but there's a step-up convenience option,
like QR code or NFC that combines the two. For users with a QR reader or
NFC they could use it, others could do it the old way.

> 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.
> My guess is that "transmitting both pieces of info" requires
> special-purpose code that understands those 2 pieces. Whereas browsing to a
> transmitted URI is generic.
> >  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.
> It is still the browser model; it's just how the URI and code get to the
> browser.
>  >> 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.
> I didn't mean to imply the AS had to *finish* the flow immediately when
> uri?code was accessed. An AS can still display anti-phishing measures
> requiring explicit user clicks to continue. The AS could still display a
> picture of the device.
> I do concede that requiring a code to be manually entered is a specific
> phishing defence so any alternative should probably be specified separately

I know for sure that Google's AS will not implement this MUST. We've talked
about it in the past (including the unfinished pre-filled scenario you
outlined) and it was rejected due to increased phishing risk. I don't know
how others who've implemented early versions of this spec will act, but I
think introducing this MUST after so many years will harm interop.

I'm not necessarily saying that nobody should accept pre-filled codes
though, only that it was the direction my team went.

A MAY might be an option. E.g. the authorization server MAY accept the
authorization URI with an appended user code (appended in a standard way).
But that the client MUST still display the code in case the AS ignores the
param and requires it to be manually entered, and for verification purposes.

For servers who accept the pre-fill, I think the UX advice would be that
the user is still prompted to confirm the code visually.  Since the device
needs to display the code in all cases, even if only for confirmation
purposes, then that actually still works fine for an AS that decides to
require manual input.

That compromise could potentially work.

> > 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 …
> I guess I read that as a suggestion for server-side code. But the user
> needs a hint at the client-side as they enter the code.
> This is a minor detail. A web form could, for instance, say "case and
> punctuation are ignored" below the code input field.

It wasn't meant to imply a server-side action, only that it's an
authorization server responsibility (which could be handled client side).
The text could be clarified if it's ambiguous.