Re: [OAUTH-WG] We appear to still be litigating OAuth, oops

Tim Bray <> Wed, 24 February 2021 16:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 92CFF3A17C5 for <>; Wed, 24 Feb 2021 08:34:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.888
X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id g8UShxx2Naaa for <>; Wed, 24 Feb 2021 08:34:49 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::12b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 308513A17C3 for <>; Wed, 24 Feb 2021 08:34:49 -0800 (PST)
Received: by with SMTP id w36so3975363lfu.4 for <>; Wed, 24 Feb 2021 08:34:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AZuMFp7PsGgU7KkA0fIqaQ/CsSu3p23VCP2gJAZFRV8=; b=ey00CWCe7C+TdIld48gKy5Wi+Kv3Q5i4bLuPYaIoxi4r7etFyYNq0DG21HqDNDugP3 nxGXctN/+9fjkRa78EttR3qurpu6uEVQJwvdFdpjCoEnJGy9NmlypZw0n9znl0pLtCO3 RejQYzJ+OHwf3N2upKddpG8jIRtGjKZzgi+c5nKIJQCxVSA2dHN36eHbpr2Jl/64aOvj EL2eXILG3o5lnjiPHHDFzdb0wwaUO+GqvkakxB8HHE3m3jLZlkQGFcFjW31Kk91tIdLy PCt1noGmO9FhjFVBYCaaqrOr9kCDYATw0GX7xJc6WJfz4IsuaqHowC4Ax1Dq1axXgKz9 nhIg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AZuMFp7PsGgU7KkA0fIqaQ/CsSu3p23VCP2gJAZFRV8=; b=ac/q9z6F7BpShEaWk++Xvzi1HDnbbA0fY60WJkvwffAoBVadt1wrDz1ZMcblF1x/n7 xEG9ASaUgl7aOWmDNg5wYGNa2ec6MCX7KHbZFVZA6p+WRXJy7ZyS+lYlIWQSYHbNXkb8 BnlnRj7dbS5WiUCcJrKB11YZgWYaZZC1c69Y7R5T3l52U/jDrRxK+mZmTczpPxGDGdzh OlicWks3is/qtNxKiSeQk/ir6PaJj/7ch0GqvdgwDMSMTm9vgKluaUDLs/yMNTMVURH8 bwIKIBHsQqcCLTickOg2S86cw2t/4sVkV3XlIiXK21O1IIvkhGbUWiT494UtOn8HqX9X GSFw==
X-Gm-Message-State: AOAM5322ErZMEBsxtqFf1jtu8uiR8vRbAfjXKUWhWqJckATwAMSlmsQk QWnjATXSgej5utFyW9bu27b2hR+A6sIXB+v1ap+JZQ==
X-Google-Smtp-Source: ABdhPJykG4yl+AuzSDikiy6cYw8mV7qzwuaTxuYfA6TEhIAYYd19gUVtPLtIdbcdEfi+mrSbPYYphmS4ai8vgxxKx7I=
X-Received: by 2002:ac2:41ce:: with SMTP id d14mr16953743lfi.451.1614184487277; Wed, 24 Feb 2021 08:34:47 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Tim Bray <>
Date: Wed, 24 Feb 2021 08:34:35 -0800
Message-ID: <>
Subject: Re: [OAUTH-WG] We appear to still be litigating OAuth, oops
To: Justin Richer <>
Cc: Bron Gondwana <>, Phillip Hallam-Baker <>, Warren Parad <>, "" <>, IETF-Discussion Discussion <>
Content-Type: multipart/alternative; boundary="000000000000f769cf05bc179c3f"
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 24 Feb 2021 16:34:54 -0000

 The OAuth work has successfully built a perfectly reasonable syntax and
protocol for exchanging identity and attribute assertions, and that's
fine.  What it hasn't done is opened up the world of Identity Provision,
but that's not a technical problem.

OAuth flowed out of OpenID back in the day. The core idea of OpenID,
beginning with the attractive but wrong notion that URIs are a good way for
people to identify themselves, was that service providers should be
prepared to trust arbitrary identity providers.  At the moment, nobody has
figured out an automated way for services to figure out which  identity
providers they want to trust. The counter-argument is that service
providers should just trust people to pick appropriate identity providers,
and it has never in my experience succeeded in convincing a single lawyer
or business-policy type.

On Wed, Feb 24, 2021 at 7:21 AM Justin Richer <> wrote:

> I agree that the NxM problem is the purview of the whole IETF, but it’s
> something that we’re particularly interested in over in GNAP. As the editor
> of OAuth’s dynamic registration extension and the GNAP core protocol, I
> hope I can add to this conversation.
> From a technical standpoint, OAuth’s dynamic client registration lets
> arbitrary clients talk to an AS, but the trust isn’t there in practice. On
> top of that I think this problem is exacerbated by a fundamental protocol
> design element of OAuth: the client_id that’s required. That field means
> there’s an assumption that a relationship was set up between the pieces of
> software, implied to be trusted by admins at the AS. Sure you can get that
> client_id under special circumstances, but there’s still a special weight
> handed to that and the dynamic stuff feels like you’re giving up control as
> an AS. In GNAP, the relationship is inverted, and it’s designed as
> “dynamic-first”, with pre-registered clients being an optimization on top
> of that.
> Does this solve the NxM problem? No, because companies are still going to
> decide that they only talk to keys or identifiers that they know ahead of
> time. But the protocol puts the dynamic case forward as baseline and fits
> in much better with the likes of JMAP than OAuth ever could:
> - {The Bat} creates a key pair.
> - {User} enters their email address into {Bat}, {Bat} does discovery
> (maybe that’s a JMAP thing? Webfinger?) and finds the JMAP server and the
> GNAP endpoint for authentication as an option.
> - {Bat} talks to the GNAP AS at {ISP} and presents the key it just made
> up. {ISP} has never seen this key, but knows how to talk GNAP and get the
> user to authorize {Bat} to access email.
> - {User} does this using GNAP and gets back an access token that’s tied to
> the key {Bat} made back at the beginning. That token is tied (at the {ISP})
> to the user’s account.
> Yes, you can do all of this today with OAuth (and people have done so),
> but OAuth’s basic model of “go do discovery and registration first and THEN
> talk to me” is a trust impediment more than it is a technical impediment.
> The “negotiation” part of the GNAP name comes from the philosophy of “start
> talking first and figure out what you need as you go”. Instead of jumping
> through hoops to get something you can trust, you just start in and then
> decide how much you trust it. A corporate rollout could use its own key
> distribution mechanism and static registration to limit which client
> instances talk back to the company server, regardless of which accounts
> would authorize access on top of that. An internet-facing service is going
> to be more likely to take a TLS approach, of “I’ll talk to you in a secure
> fashion without caring who you are right now”.
> We really are trying to make GNAP a consistent protocol at its core and
> learn from problems with OAuth in the wild, all while letting GNAP address
> a wider variety of use cases. I agree that GNAP could be clearer about
> specific use cases, and we’re working on the spec still so any help here is
> appreciated.
>  — Justin
> On Feb 24, 2021, at 7:15 AM, Bron Gondwana <> wrote:
> On Wed, Feb 24, 2021, at 23:09, Warren Parad wrote:
> (I tend to trend lightly in the pronoun area, mostly because I'm shocked
> that openid included gender but not pronouns)
> I hadn't heard that to be called the NxM problem, so that definitely
> cleared up the potential confusion (at least for me).
> I think GNAPs lack of clarity is a non sequitur for the handling or not of
> the multitrust arbitrary-client with arbitrary-service, however it's lack
> of clarity for me prevents me from knowing whether GNAP actually seeks to
> solve this problem. So from an OAuth WG perspective we can still ask:
> *Is this or should this problem be left to GNAP to solve, or is an OAuth
> WG responsibility?*
> Honestly I think the problem space is the whole ietf's responsibility.
> Protocols that allow an end user to safely transfer data between two
> parties that don't have a pre-existing trust relationship are a key part of
> enabling user freedom and user choice.
> Bron.
> *Warren Parad*
> Founder, CTO
> Secure your user data with IAM authorization as a service. Implement
> Authress <>.
> On Wed, Feb 24, 2021 at 12:39 PM Bron Gondwana <>
> wrote:
> On Wed, Feb 24, 2021, at 22:04, Warren Parad wrote:
> I would prefer Bron to answer that question, as they are the one who
> started this email thread.
> You can also use he when talking about me, or she for that matter - I do
> enough group fitness classes where it's roughly assumed that the entire
> class is female, and I have an ambiguous enough name that I'm used to it.
> Most people use "he" most of the time.
> However let's look at GNAP, I've honestly been struggling to understand at
> least one fully documented case that GNAP supports. It seems in every
> document the only thing that is clear is GNAP wants to allow "everything",
> doesn't actually talk about an example.
> That's my biggest fear for GNAP - it too will try to be everything to
> everybody and wind up being nothing to nobody because the super flexible
> "everything protocol" is the same as no protocol at all, since you have to
> special-case everybody you talk to anyway.
> By NxM, I assume we mean that the end user or client is free to select
> whichever AS they want, in a way which the RS can verify the AS credential
> and the user identity, without the RS having to (and really without the
> ability to limit) which AS are allowed.
> Let's get down to use cases then, rather than talking in abstracts.
> I'm an end user with a copy of {The Bat email client} and I want to
> connect it to {Gmail} + {Yahoo} + {My ISP}.  It supports {POP3}, a widely
> popular open standard.  I want to be able to authenticate to each of those
> services without saving my plaintext passwords on my hard disk where the
> next {Windows ME} virus will exfiltrate them to {Noextraditionistan} and
> all my {Dogecoin} will then be exfiltrated from my {Paybuddy} account,
> leaving me destitute.
> But, {The Bat} doesn't have a trusted client cert from my isp, because who
> does - so there's no good protocol for me - it's either plaintext auth, or
> it's some architecture astronaut multi-party nonsense that's massively over
> specified and doesn't work half the time.  So I write a plain text password
> on a post-it note which is lying in the dust under my monitor because the
> glue has gone bad, and I hope I never accidentally click "remember me" when
> I type it in.
> That's been the reality of the end user experience for very many years.
> NxM means that you can authenticate an arbitrary client against an
> arbitrary server so long as they are both speaking a known public protocol,
> without needing to build a trust relationship between the client vendor and
> the server vendor first.
> Any "trust relationship" is made through a user both who trusts the client
> and trusts the server, and it's not transitive over to other users of the
> same client and the same server.  The client author doesn't need to get a
> signed "I trust you" from every single server, and the server author
> doesn't have to go identify every single client.
> That's what NxM means to a user, the ability to use arbitrary clients with
> arbitrary servers so long as they both implement a documented protocol.
> Interoperability.
> OAuth has not given interoperability in the NxM sense outside some simple
> web use cases.  They're nice and all, but they don't tend to be useful with
> open protocols - OAuth gets used for accessing proprietary API endpoints
> after getting an access key for a single provider.  At least you get Nx1 or
> 1xM out of it depending who's the N and who's the M, and maybe some of your
> code can rhyme so you're not doing everything from scratch each time.
> This is the sorry story of real open protocols.  The floor for true
> interoperability is still username + password over cleartext, over
> hopefully a TLS tunnel that's providing some level of protection.  Most so
> than a few years ago when Fastmail wrote our "starttls considered
> harmful"[1] objection to the IETF's habit at the time of putting a
> "STARTTLS" upgrade into an initially plaintext protocol, where an active
> intercepter could just strip the "I support STARTTLS" indicator from the
> protocol and convince the client to send the credentials in the clear.
> We're a little better mostly these days, but it's still a tirefire, and in
> my heart I do hold the OAuth working group's squatting on this area of the
> landscape while failing to address this burning need partially
> responsible.  The result (as Phillip pointed out upthread) has been a
> consolidation towards a few big players - because NxM becomes tractable
> when you reduce the N and M to small enough numbers.
> Bron.
> [1]
> --
>   Bron Gondwana, CEO, Fastmail Pty Ltd
> --
>   Bron Gondwana, CEO, Fastmail Pty Ltd
> _______________________________________________
> OAuth mailing list