Re: [OAUTH-WG] Adam Roach's No Objection on draft-ietf-oauth-native-apps-11: (with COMMENT)
Adam Roach <adam@nostrum.com> Tue, 23 May 2017 17:27 UTC
Return-Path: <adam@nostrum.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 C97A4129C3E; Tue, 23 May 2017 10:27:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.88
X-Spam-Level:
X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
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 n1W3leItfRxB; Tue, 23 May 2017 10:27:21 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 D9D96129C37; Tue, 23 May 2017 10:27:21 -0700 (PDT)
Received: from Orochi.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v4NHREZ5022728 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 23 May 2017 12:27:16 -0500 (CDT) (envelope-from adam@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Orochi.local
To: William Denniss <wdenniss@google.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>
References: <149548482877.9096.13896958451655712801.idtracker@ietfa.amsl.com> <CAAP42hAcc5qGCxMC-Qj=G5BKQ9kRv9N6_pdtjH8mxUCcFCD_8g@mail.gmail.com>
From: Adam Roach <adam@nostrum.com>
Message-ID: <fabf4337-c4e8-7da8-d212-9e16bf4cf7e0@nostrum.com>
Date: Tue, 23 May 2017 12:27:09 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: <CAAP42hAcc5qGCxMC-Qj=G5BKQ9kRv9N6_pdtjH8mxUCcFCD_8g@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------E2F5C0BD007C926365915E05"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/C9BOdGC0JhywfYrP_dKsaupJs7M>
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: Tue, 23 May 2017 17:27:24 -0000
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
- [OAUTH-WG] Adam Roach's No Objection on draft-iet… Adam Roach
- Re: [OAUTH-WG] Adam Roach's No Objection on draft… William Denniss
- Re: [OAUTH-WG] Adam Roach's No Objection on draft… Alexey Melnikov
- Re: [OAUTH-WG] Adam Roach's No Objection on draft… Alexey Melnikov
- Re: [OAUTH-WG] Adam Roach's No Objection on draft… Adam Roach
- Re: [OAUTH-WG] Adam Roach's No Objection on draft… Adam Roach
- Re: [OAUTH-WG] Adam Roach's No Objection on draft… William Denniss
- Re: [OAUTH-WG] Adam Roach's No Objection on draft… William Denniss
- Re: [OAUTH-WG] Adam Roach's No Objection on draft… Adam Roach
- Re: [OAUTH-WG] Adam Roach's No Objection on draft… William Denniss
- [OAUTH-WG] IESG Comments addressed John Bradley