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

William Denniss <wdenniss@google.com> Sat, 03 June 2017 02:26 UTC

Return-Path: <wdenniss@google.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87461129B91 for <oauth@ietfa.amsl.com>; Fri, 2 Jun 2017 19:26:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GNhXVCGzF12F for <oauth@ietfa.amsl.com>; Fri, 2 Jun 2017 19:26:06 -0700 (PDT)
Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (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 1222C1294A2 for <oauth@ietf.org>; Fri, 2 Jun 2017 19:26:06 -0700 (PDT)
Received: by mail-it0-x234.google.com with SMTP id m47so7312843iti.1 for <oauth@ietf.org>; Fri, 02 Jun 2017 19:26:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; 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; d=1e100.net; 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 10.107.25.203 with SMTP id 194mr10724104ioz.182.1496456765123; Fri, 02 Jun 2017 19:26:05 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.79.35.37 with HTTP; Fri, 2 Jun 2017 19:25:44 -0700 (PDT)
In-Reply-To: <fabf4337-c4e8-7da8-d212-9e16bf4cf7e0@nostrum.com>
References: <149548482877.9096.13896958451655712801.idtracker@ietfa.amsl.com> <CAAP42hAcc5qGCxMC-Qj=G5BKQ9kRv9N6_pdtjH8mxUCcFCD_8g@mail.gmail.com> <fabf4337-c4e8-7da8-d212-9e16bf4cf7e0@nostrum.com>
From: William Denniss <wdenniss@google.com>
Date: Fri, 2 Jun 2017 19:25:44 -0700
Message-ID: <CAAP42hBB_VWZA5rb3KVP+Adh2wvJ-DeRHwZ6B_hZdwQO-xtMkw@mail.gmail.com>
To: Adam Roach <adam@nostrum.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-oauth-native-apps@ietf.org, Hannes Tschofenig <Hannes.Tschofenig@gmx.net>, oauth-chairs@ietf.org, "oauth@ietf.org" <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="001a113fe2dae8b2fb055104fda8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/ACblV9nZC3zLAyMhPY0o4cyFeT8>
Subject: Re: [OAUTH-WG] Adam Roach's No Objection on draft-ietf-oauth-native-apps-11: (with COMMENT)
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: Sat, 03 Jun 2017 02:26:09 -0000

On Tue, May 23, 2017 at 10:27 AM, Adam Roach <adam@nostrum.com>; 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
<https://github.com/WilliamDenniss/draft-ietf-oauth-native-apps/pull/9/files>;,
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
web-view.