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

Warren Parad <> Wed, 24 February 2021 12:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 793583A14C1 for <>; Wed, 24 Feb 2021 04:09:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.088
X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-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 cYM9xHoLkNSg for <>; Wed, 24 Feb 2021 04:09:26 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::d2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 31C993A14BB for <>; Wed, 24 Feb 2021 04:09:26 -0800 (PST)
Received: by with SMTP id y202so1758042iof.1 for <>; Wed, 24 Feb 2021 04:09:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GbAQR5VKohjmNQNdWyyof8g+21qbDiT3BsoJpZNFPoE=; b=F1AaizDukA7drvYMMgfwmgO2DN5/8f2QEjUFVqWXNYoBBbtZC8gfwOrA8Ila2FvXw3 KGCaZFXZTCKYyBpBocsBbZiNTBm3qcjxvhJzqvLL4zUWxD5gBY5MwHo46RutMSCpnCqg nVjsug/yKFx1zQt0vGsyerzSNJPeSLuDl9nZNKspAFO/P5/VOJkWVVJsACjEhxB/qjlm K+NRiGj/lofK3Ynnq9xBOPaBWywijryKY82GvJW1At3Fu4OjSkrclYNqs8F8FzVLQGTJ ESugoDIMSkcfGv0XwMpW+V2vx+LpS8t/YtSxXCk0Qeq+O2X6FCkRQvcgvF9gYAlaJap2 zFYw==
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=GbAQR5VKohjmNQNdWyyof8g+21qbDiT3BsoJpZNFPoE=; b=jqKbjYM8AvmSLblsr6CacSxFkloU30QpNEcKPEG8IKjI3RBflyCqePqM/V8qlyCmu9 1DNZum9gvwqgoEbTPLKvkTBxMaYlQTBZf/FyMTMUtvidoXjEoO2jwaS7xvkVDwgH10jL wv45Umo3si2empy8MXIczQCovb4L23eXN/K8aJKt5RsGgFzqDSHML4ZrnY82YNhepxP5 AZFyj2srcU9MQqrVAyjSFvfz3csjYu2hA8o/cc44A2K9suuKPZM2IgnM+/MOT0byAH/C Ub/+PyTfkjn/ts06/sbSMcOwNRNFhj1hHddtHfgX5Y6LfGK4OylXdNpwbF27cG3ojwAr MeVQ==
X-Gm-Message-State: AOAM531CSC1LEtg+w3z3P8nZklclGpyqTDOd//4T789+ZPLiEjfnUFbn M9lZK24NkIB0aB0WnnwrAH0Elr5LuDIt/8Hqze0G
X-Google-Smtp-Source: ABdhPJyuzIg4fVLDRlZHCSHKIxVAtJtdmyt7hMqw+z2cbsfvvzDjV6DaDnWqkFOMxgPxCcFlv0TWWFciaZzCL2MntXo=
X-Received: by 2002:a05:6602:130a:: with SMTP id h10mr21944927iov.48.1614168565398; Wed, 24 Feb 2021 04:09:25 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <> <>
In-Reply-To: <>
From: Warren Parad <>
Date: Wed, 24 Feb 2021 13:09:14 +0100
Message-ID: <>
Subject: Re: [OAUTH-WG] We appear to still be litigating OAuth, oops
To: Bron Gondwana <>
Cc: Carsten Bormann <>, Phillip Hallam-Baker <>, "" <>,
Content-Type: multipart/alternative; boundary="000000000000f2d76505bc13e74a"
Archived-At: <>
X-Mailman-Approved-At: Wed, 24 Feb 2021 08:40:45 -0800
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 12:09:29 -0000

(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

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 <>

> 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