Re: [OAUTH-WG] Adam Roach's No Objection on draft-ietf-oauth-native-apps-11: (with COMMENT)

William Denniss <> Sat, 03 June 2017 02:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 87461129B91 for <>; Fri, 2 Jun 2017 19:26:08 -0700 (PDT)
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 GNhXVCGzF12F for <>; Fri, 2 Jun 2017 19:26:06 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c0b::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1222C1294A2 for <>; Fri, 2 Jun 2017 19:26:06 -0700 (PDT)
Received: by with SMTP id m47so7312843iti.1 for <>; Fri, 02 Jun 2017 19:26:05 -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=R5MFLE8bL5SLXrwD8Mn/AlwFiI/lEaa5LFMrs3pt96c=; b=ogeiwB8snmyKsnnMxGLm35+elZAU7AQwZs1TKIt7FiN946+UbAVmCUjPgs4Ef58Dru L0FReWEsHKP76embnMJO3Q4KhxTshKa0MuuDxk8DLZLLtt78SzsD1WYD6R8MUNTi5fAZ cVS34ZoYfOdGEYWhi59Axfochqer9Qx2Zx8VkmNa6J9t7hJjhu4crEn++aOFeB9pLfXZ GX5CJoiO1Tktz+bGJR4Ka3rFPJ65C4PsF/LKzKiGHnTOdyp42/hVLeJcRftgaOFXo6r/ 77+AF6qd5XS+Zcbo80hjRDtDAG/axgwWhFV6iQbzRV2VDdFpe3swwccnWLxKd5xjkYXf qLAA==
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=R5MFLE8bL5SLXrwD8Mn/AlwFiI/lEaa5LFMrs3pt96c=; b=r1g7rO16DboIprqIOy5ayv6Wv/0uS3Fc4Cx/sXaFU5l6uj2UOZRf/2JyQFLwNrzyYx D8Rza1s5r081gzW2DAujV7j0cdqmaU3WMahwjpMyNhSTAhjQg1ErwpBL+3H7aQLtRtoM 4HkZqEdS4Ujh4eKCZ3PGh8VT7x+ZNOh2eu0DjFKRXUkEyUQPxNkIThug+drceyiheSYi p6l/zr78YjT6flhQU4XCIxhmPdQLROtalOc6cWuV7a+LJMeHhtmTm3yzOPMcIMMhKzcx +7DR5oO/9uzeHypSDJpUz7bPLNFnayq2x5SupjOkCyy1WvR4ZW2F21xCUj6MM0y04BrG jy4w==
X-Gm-Message-State: AODbwcCJuKfH5yxdvFS1FqW73KepEGhALIKAMpcuVPWqwymPWVySfMw4 +WzhwxvYCNV79jvUyaUW/LjQ6et34Yix
X-Received: by with SMTP id 194mr10724104ioz.182.1496456765123; Fri, 02 Jun 2017 19:26:05 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 2 Jun 2017 19:25:44 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
From: William Denniss <>
Date: Fri, 02 Jun 2017 19:25:44 -0700
Message-ID: <>
To: Adam Roach <>
Cc: The IESG <>,, Hannes Tschofenig <>,, "" <>
Content-Type: multipart/alternative; boundary="001a113fe2dae8b2fb055104fda8"
Archived-At: <>
Subject: Re: [OAUTH-WG] Adam Roach's No Objection on draft-ietf-oauth-native-apps-11: (with COMMENT)
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: Sat, 03 Jun 2017 02:26:09 -0000

On Tue, May 23, 2017 at 10:27 AM, Adam Roach <> wrote:

> William --
> Thanks for your quick responses! I have only one follow-up (beyond my
> response to the thread that Alexey started):
> On 5/22/17 17:14, William Denniss wrote:
> My understanding of the Web Authentication Broker is that it is
> effectively a special-case browser designed for authentication. There is a
> single cookie-jar which is retained and used with all apps that use the Web
> Authentication Broker in "SSO mode". So logins are shared, and the
> advantages of Section 4 apply.  It's a separate cookie-jar from the main
> browser, which would imply a minimum of two sign-ins on the device (so not
> quite "single" at a device level), but I'm not sure if this is enough to
> disqualify it.
> My goal here is to simply document the current state of the art of the
> platforms, and I felt that the Web Authentication Broker qualified as an
> external user agent per the BCP.  The user interface is arguably quite nice
> too, which mitigates some of the downsides of using a special
> authentication "browser" with a separate cookie jar.
> Some of this comes down to user experience and some of it comes down to
> user choice. I'm going to speak using first-person pronouns here, but
> please be aware that I'm speaking from the point of view of a significant
> body of users.
> For the user experience side of things: users of Firefox and Chrome will
> commonly take advantage of cross-machine, cross-platform password
> synchronization built into those browsers, and the recommendation you're
> giving in this document defeats those pretty soundly. Thinking all the way
> through the user experience you're promoting, here's what this would look
> like to me:
>    1. Native app has a button I can use to [link an account, authenticate
>    myself, etc]
>    2. I click that button, and the Web Authentication Broker opens
>    3. I manually open Firefox, go to options->security, and click on
>    "saved logins"
>    4. I type in the name of the authenticating website, click on "Show
>    Passwords," and enter my master password
>    5. I copy and paste the (long, randomly-generated) password for the
>    authenticating website into the Web Authentication Broker
> That's... pretty friction-laden, especially when you consider that opening
> the authentication flow in my native browser would take maybe one or two
> clicks instead. The situation for Chrome users is approximately as bad.
> The other part of this recommendation (and I think this is a bigger issue)
> is that I, as a user, have made a pretty conscious decision about the
> browser I want to use for these kinds of things, based in part on the way I
> know various browsers handle things like analytics and privacy, and based
> in part on the speed with which browser security exploits are patched. I'm
> going to presume that the Web Authentication Broker acts in every way that
> I care about like either Edge or Explorer (probably Edge), which is likely
> to fall outside the envelope of what I'm okay with in a browser. I don't
> mean this as a major knock on Edge; I just have certain preferences in this
> area, and it's a choice that I feel I should be allowed to make and have
> respected when possible.
> This section is written in a way that reads very much like "use the Web
> Authentication Broker when possible, and fall back on the user's explicitly
> selected and preferred browser only as a last resort." This circumvents the
> user agency I describe above, which gives me more than a little cause for
> concern.
> For these two reasons, I would like to see the recommendation in this
> section pretty much reversed: calling to to the browser registered with the
> operating system should be preferred so as to respect user agency, followed
> by a note that using the Microsoft Web Authentication Browser in SSO Mode
> qualifies as using an External Browser as described in this document,
> although it has the three drawbacks of:
>    1. Not integrating with cookie storage for the user's preferred
>    browser.
>    2. Not integrating with password management for the user's preferred
>    browser.
>    3. Bypassing user choice regarding various browser attributes, such as
>    privacy and security properties.
> /a

In my staged copy
I have followed your advice and reversed the recommendation ordering, and
mentioned the caveats that the user's personalisations are not present in
the broker. The lack of password manager support is a very good point. It's
definitely been one of the advantages we've seen by moving to browsers from