Subject: Re: [OAUTH-WG] Diversity and Inclusiveness in the IETF

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 23 Feb 2021 11:00:04 +0000

Hi Bron,

I have to respond to your statements about the OAuth working group below.

While we do not pay attention to keeping the charter page up-to-date, we have been able to advance our documents, produce many implementations, and got those deployed all over the Internet.

The bar for acceptance of new work varies among working group in the IETF. Some working groups develop technology that got widely deployed and hence randomly changing specs isn't such a great idea because you have to consider the deployment situation as well. This is a situation many IETF working groups face. Reaching (widespread) deployment is great on one hand and a pain on the other.

There are other groups, which are early in their lifecycle. In those groups you do not need to worry about deployments, backwards compatibility or even any source code.

In general, Rifaat and I are always open for anyone in the IETF (and outside) to reach out to us, if they want to bring new work forward to the group. Sometimes proposed work fits into the group and sometimes it does not. The work on JOSE, for example, was put into a separate working group even though it was initially developed for use with JSON Web Tokens.

I don't recall having chatted with you or with someone from the JMAP community on the use of OAuth. Sorry if my memory does not serve me well today.  Typically, applications just use OAuth and therefore there is no need to reach out to the OAuth working group.

Ciao
Hannes

From: ietf <[email-masked]> On Behalf Of Bron Gondwana
Sent: Tuesday, February 23, 2021 5:20 AM
To: [email-masked]
Subject: Re: Diversity and Inclusiveness in the IETF

Thanks Fernando,

I would add to this document something about inertia, backwards compatibility and existing dysfunction.

Many ideas are shut down because they aren't in the right place, or don't fit comfortably into the existing corpus of IETF documents.

When we brought JMAP to the IETF it was after a long process of socialisation, and still there was significant work in the first couple of meetings just to convince people that "this is worth doing, the existing work the IETF has done in this neighborhood is not sufficient".

JMAP also had an authentication scheme in it originally.  It was a good authentication scheme, but applications don't do authentication schemes, that's the bailiwick of OAUTH, where ideas go to die (in my experience, that working group has been dysfunctional for my entire time at IETF - exhibit 'A' being the "Milestones" section of the about page, which lists 6 items all due in 2017)

So we just removed all mention of authentication method and handwaved "the connection will be authenticated", because we wanted to publish something during the decade with years starting '201'.

... all that to say.  One of the biggest barriers to entry in the IETF is stumbling across an area in which no work is able to progress due to entrenched issues within that area.

And I'm not arguing for "no barriers to entry", because there needs to be a sanity check that we're actually producing high quality specifications, and that our specifications are compatible with each other so the entirety of the IETF's work product is a coherent whole.  But it's hard to get started if you don't already have the connections to have your work sponsored by somebody who already knows their way around the IETF's idiosyncrasies.  I'm doing some of that sponsoring myself now for the people from tc39 who are trying to get the IETF to look at defining an extended datetime format.

Cheers,

Bron.

On Tue, Feb 23, 2021, at 11:07, Fernando Gont wrote:
Folks,

We have submitted a new I-D, entitled "Diversity and Inclusiveness in
the IETF".

The I-D is available at:
https://www.ietf.org/archive/id/draft-gont-diversity-analysis-00.txt

We expect that our document be discussed in the gendispatch wg
(https://datatracker.ietf.org/wg/gendispatch/about/). But given the
breadth of the topic and possible views, we'll be glad to discuss it
where necessary/applicable/desired.

As explicitly noted in our I-D, we're probably only scratching the
surface here -- but we believe that our document is probably a good
start to discuss many aspects of diversity that deserve discussion.

Thanks!

Regards,
--
Fernando Gont
SI6 Networks
e-mail: [email-masked]<mailto:[email-masked]>
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  [email-masked]<mailto:[email-masked]>

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: "Bron Gondwana" <[email-masked]>
Date: Tue, 23 Feb 2021 22:50:49 +1100

Without wishing to litigate the entire issue here (happy to remove the wider IETF list and just talk on the OAuth group), we never brought any work to the OAuth group because everybody who we spoke to warned us that nothing would get done.

There's a term "missing stair" https://en.wikipedia.org/wiki/Missing_stair which describes this phenomenon, where "everybody knows" something, but new participants are forced to discover it through either having someone tell them quietly, or just notice it for themselves.

...

Just as an anecdote, the last time I bothered to attend an OAuth meeting in person I had this to say about it on our internal slack channel when asked:"they can't agree about what they don't agree on".

The topic that had taken basically the entire meeting and had been totally unproductive - was a particular key in a JSON Web Token going to clash with a reserved word in either javascript itself or one of the other environments in which this token had to be evaluated.  There were people saying "this won't work, just rename the key" and others saying "I like this name and insist upon us keeping it".  No progress was made that day.

In fact, here's the extract of my report on the OAuth meeting at IETF102 (a detailed long email with pictures of poutine, icecream, and a report on every session I attended).  Names extracted to protect the others involved, but other text left exactly as it was, complete with typoes:

> *Thursday 19th: (Aug 2018)*
> 
> *9:30am* OAUTH <https://datatracker.ietf.org/meeting/102/materials/agenda-102-oauth-03>:  Fecking OAUTH as they say.  I came out of this saying "they can't even agree about what they don't agree on".  <Name redacted> says it was even worse in the past.  What a fustercluck.  Don't expect anything workwhile out of this group unfortunately.  <Other name redacted> and I were just looking at each other like WTF the entire time.

Maybe it's become heaps better since then.  But I wouldn't want to have been a new participant trying to get anything done in that session.

...

The authentication flow as originally put into JMAP (before it came to the IETF) can be seen in the initial draft here if you're interested:

https://www.ietf.org/archive/id/draft-jenkins-jmap-00.txt

But we decided in the interests of expediency to just drop it rather than trying to progress that work anywhere at the IETF.

Regards,

Bron.

> The bar for acceptance of new work varies among working group in the IETF. Some working groups develop technology that got widely deployed and hence randomly changing specs isn’t such a great idea because you have to consider the deployment situation as well. This is a situation many IETF working groups face. Reaching (widespread) deployment is great on one hand and a pain on the other.

> I don’t recall having chatted with you or with someone from the JMAP community on the use of OAuth. Sorry if my memory does not serve me well today.  Typically, applications just use OAuth and therefore there is no need to reach out to the OAuth working group.

> *From:* ietf <[email-masked]> *On Behalf Of * Bron Gondwana
> *Sent:* Tuesday, February 23, 2021 5:20 AM
> *To:* [email-masked]
> *Subject:* Re: Diversity and Inclusiveness in the IETF

>> e-mail: [email-masked]

>   [email-masked]

  [email-masked]

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Tue, 23 Feb 2021 07:40:43 -0500

So you have never reached out to us to try to bring any work to the WG, and
based on attending one meeting and hearing from a few people, you formed a
strong opinion and declared that "nothing would get done"? that seems odd.

For your information, last year we published 4 RFCs, and we already have 3
documents with the IESG and more to come.

If you have anything you want to bring to the OAuth WG, Hannes and I would
be happy to discuss this with you or anyone that wants to bring work to the
OAuth WG.

Regards,
 Rifaat

On Tue, Feb 23, 2021 at 6:52 AM Bron Gondwana <[email-masked]>
wrote:

> Without wishing to litigate the entire issue here (happy to remove the
> wider IETF list and just talk on the OAuth group), we never brought any
> work to the OAuth group because everybody who we spoke to warned us that
> nothing would get done.
>
> There's a term "missing stair" https://en.wikipedia.org/wiki/Missing_stair
> which describes this phenomenon, where "everybody knows" something, but new
> participants are forced to discover it through either having someone tell
> them quietly, or just notice it for themselves.
>
> ...
>
> Just as an anecdote, the last time I bothered to attend an OAuth meeting
> in person I had this to say about it on our internal slack channel when
> asked:"they can't agree about what they don't agree on".
>
> The topic that had taken basically the entire meeting and had been totally
> unproductive - was a particular key in a JSON Web Token going to clash with
> a reserved word in either javascript itself or one of the other
> environments in which this token had to be evaluated.  There were people
> saying "this won't work, just rename the key" and others saying "I like
> this name and insist upon us keeping it".  No progress was made that day.
>
> In fact, here's the extract of my report on the OAuth meeting at IETF102
> (a detailed long email with pictures of poutine, icecream, and a report on
> every session I attended).  Names extracted to protect the others involved,
> but other text left exactly as it was, complete with typoes:
>
> *9:30am* OAUTH
> <https://datatracker.ietf.org/meeting/102/materials/agenda-102-oauth-03>:
> Fecking OAUTH as they say.  I came out of this saying "they can't even
> agree about what they don't agree on".  <Name redacted> says it was even
> worse in the past.  What a fustercluck.  Don't expect anything workwhile
> out of this group unfortunately.  <Other name redacted> and I were just
> looking at each other like WTF the entire time.
>
>
> Maybe it's become heaps better since then.  But I wouldn't want to have
> been a new participant trying to get anything done in that session.
>
> ...
>
> The authentication flow as originally put into JMAP (before it came to the
> IETF) can be seen in the initial draft here if you're interested:
>
> But we decided in the interests of expediency to just drop it rather than
> trying to progress that work anywhere at the IETF.
>
> Regards,
>
> Bron.
>
> While we do not pay attention to keeping the charter page up-to-date, we
> have been able to advance our documents, produce many implementations, and
> got those deployed all over the Internet.
>
>
>
> The bar for acceptance of new work varies among working group in the IETF.
> Some working groups develop technology that got widely deployed and hence
> randomly changing specs isn’t such a great idea because you have to
> consider the deployment situation as well. This is a situation many IETF
> working groups face. Reaching (widespread) deployment is great on one hand
> and a pain on the other.
>
>
>
> There are other groups, which are early in their lifecycle. In those
> groups you do not need to worry about deployments, backwards compatibility
> or even any source code.
>
>
>
> In general, Rifaat and I are always open for anyone in the IETF (and
> outside) to reach out to us, if they want to bring new work forward to the
> group. Sometimes proposed work fits into the group and sometimes it does
> not. The work on JOSE, for example, was put into a separate working group
> even though it was initially developed for use with JSON Web Tokens.
>
>
>
> I don’t recall having chatted with you or with someone from the JMAP
> community on the use of OAuth. Sorry if my memory does not serve me well
> today.  Typically, applications just use OAuth and therefore there is no
> need to reach out to the OAuth working group.
>
>
>
> Ciao
>
> Hannes
>
>
>
> Many ideas are shut down because they aren't in the right place, or don't
> fit comfortably into the existing corpus of IETF documents.
>
>
>
> When we brought JMAP to the IETF it was after a long process of
> socialisation, and still there was significant work in the first couple of
> meetings just to convince people that "this is worth doing, the existing
> work the IETF has done in this neighborhood is not sufficient".
>
>
>
> JMAP also had an authentication scheme in it originally.  It was a good
> authentication scheme, but applications don't do authentication schemes,
> that's the bailiwick of OAUTH, where ideas go to die (in my experience,
> that working group has been dysfunctional for my entire time at IETF -
> exhibit 'A' being the "Milestones" section of the about page, which lists 6
> items all due in 2017)
>
>
>
> So we just removed all mention of authentication method and handwaved "the
> connection will be authenticated", because we wanted to publish something
> during the decade with years starting '201'.
>
>
>
> ... all that to say.  One of the biggest barriers to entry in the IETF is
> stumbling across an area in which no work is able to progress due to
> entrenched issues within that area.
>
>
>
> And I'm not arguing for "no barriers to entry", because there needs to be
> a sanity check that we're actually producing high quality specifications,
> and that our specifications are compatible with each other so the entirety
> of the IETF's work product is a coherent whole.  But it's hard to get
> started if you don't already have the connections to have your work
> sponsored by somebody who already knows their way around the IETF's
> idiosyncrasies.  I'm doing some of that sponsoring myself now for the
> people from tc39 who are trying to get the IETF to look at defining an
> extended datetime format.
>
>
>
> Cheers,
>
>
>
> Bron.
>
>
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
>
>
> --

---

From: "Bron Gondwana" <[email-masked]>
Date: Tue, 23 Feb 2021 23:46:34 +1100

On Tue, Feb 23, 2021, at 23:40, Rifaat Shekh-Yusef wrote:
> So you have never reached out to us to try to bring any work to the WG, and based on attending one meeting and hearing from a few people, you formed a strong opinion and declared that "nothing would get done"? that seems odd.

Based on a few meetings, and having heard from many people.

> For your information, last year we published 4 RFCs, and we already have 3 documents with the IESG and more to come.

That's good to hear.

> If you have anything you want to bring to the OAuth WG, Hannes and I would be happy to discuss this with you or anyone that wants to bring work to the OAuth WG.

Thanks.  I don't mean to pick on OAuth specifically, but I also would recommend that you ask around and see whether my view of the culture of the OAuth working group is widely shared within the IETF or whether I've managed to find myself inside a small echo chamber that has a poor opinion of the welcoming-ness of the working group.

Either way, the fact that the participants of the JMAP working group (including myself) who were all new to the IETF at the time were warned that OAuth is not a place where you can reasonably expect to get your work advanced is an indictment of SOMETHING, and that's worth having a think about in terms of making the IETF a welcoming place.

Regards,

Bron.

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 23 Feb 2021 12:46:48 +0000

Hi Bron,

Let me also tell you a personal story. I was in the army in Austria and a commander of a small group. Everyone on the base knew about a pub in the city that was extremely dangerous and, according to stories, you would most likely get stabbed there. I was wondering about that place and went there. Guess what: I was there alone with the waitress. Everyone was too afraid to go there.

Maybe there is a lesson here. Just give it a try*.

Getting back to the OAuth group: Groups typically go through cycles. At the beginning when participants do not know each other the discussions are often rough. When there is not much content (typically during a requirements gathering phase) everyone has an opinion to share. As time goes on, the situation improves and everyone gets to know each other better, hangs around after the official WG meetings and meets at non-IETF events. That’s where it gets more civilized. We went through those stages as well.

Groups that work on exciting technologies also attract “rock stars” (as I call them). We had those in the OAuth group as well. It caused a lot of stress for the entire group but also for us chairs. When you have several people who do not accept a proposal different than their own then it gets tricky. Unfortunately, chairs don’t have much to say in the IETF either.

I believe it helped us to get together in workshops (we organized a series of OAuth workshops), met at industry events (the Internet Identity Workshop, etc.) and scheduled regular “virtual office hours”. Of course, we still have disagreements and it would be a lie to say that all our meetings have been productive. Productivity has, however, been increased. The meetings were certainly passionate. On the other hand, I have been in working group meetings where there was no passion, no discussion and no productivity. Not great either.

I don’t know whether it is already too late for your document (which is dated 2016) to consider the use of OAuth but Rifaat and I are happy to put you on the spot in one of our future virtual office hours or virtual interim meetings.

Ciao
Hannes

PS: This is not a general life advice. There are many things you better skip...

From: Bron Gondwana <[email-masked]>
Sent: Tuesday, February 23, 2021 12:51 PM
To: Hannes Tschofenig <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: Diversity and Inclusiveness in the IETF

...

Thursday 19th: (Aug 2018)

9:30am OAUTH<https://datatracker.ietf.org/meeting/102/materials/agenda-102-oauth-03>:  Fecking OAUTH as they say.  I came out of this saying "they can't even agree about what they don't agree on".  <Name redacted> says it was even worse in the past.  What a fustercluck.  Don't expect anything workwhile out of this group unfortunately.  <Other name redacted> and I were just looking at each other like WTF the entire time.

...

Regards,

Bron.

Hi Bron,

Ciao

Hannes

From: ietf <[email-masked]<mailto:[email-masked]>> On Behalf Of Bron Gondwana
Sent: Tuesday, February 23, 2021 5:20 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: Diversity and Inclusiveness in the IETF

Thanks Fernando,

Cheers,

Bron.

Folks,

the IETF".

The I-D is available at:

Thanks!

Regards,

--

Fernando Gont

SI6 Networks

--

---

From: "Bron Gondwana" <[email-masked]>
Date: Wed, 24 Feb 2021 00:01:43 +1100

(bringing this back to just the OAuth list)

> I don’t know whether it is already too late for your document (which is dated 2016) to consider the use of OAuth but Rifaat and I are happy to put you on the spot in one of our future virtual offic…

It's never "too late" - we could add a "how to Authenticate JMAP using OAuth" document easily enough.

That specific document which I mentioned went through many revisions and a split to eventually become RFC8620 and RFC8621.  The core JMAP spec says this about Authentication:

8.2 <https://tools.ietf.org/html/rfc8620#section-8.2>.  Authentication Scheme

   A number of HTTP authentication schemes have been standardised (see
   <https://www.iana.org/assignments/http-authschemes/>).  Servers
   should take care to assess the security characteristics of different
   schemes in relation to their needs when deciding what to implement.

   Use of the Basic authentication scheme is NOT RECOMMENDED.  Services
   that choose to use it are strongly recommended to require generation
   of a unique "app password" via some external mechanism for each
   client they wish to connect.  This allows connections from different
   devices to be differentiated by the server and access to be
   individually revoked.

What it doesn't have is something like what existed in the first draft, which allowed out-of-band authentication in many ways, and *probably did require security review - but security review from people who wanted it to succeed rather than from people who wanted it to go away because it wasn't OAuth*.  At the time, that didn't sound like something achievable.  We were told that any authentication proposal would have to get past the OAuth working group, who would shoot it down or stagnate it for years.  Maybe that was wrong, but it was the impression we got from multiple people in multiple conversations, both in our working group and in the hallway track.

The original authentication protocol started with a username and a service, and got back a session token plus list of authentication methods that were allowed, or even a "we already authenticated you out of band - go right ahead".

The methods included password or password plus second factor, but also allowed for things like "here's a URL, go sign in there and when you're finished your session will be valid" or "a popup has been shown in your existing sessions on other clients, confirm this code and click OK".

The important thing was that there was no requirement that there be any web context built into the client - it could happily just sit there waiting for a push event down the push channel to tell it that the session had been authorised, or poll to see if it was allowed access yet.  The authentication could be entirely out of band after the initial handshake.

It's a quite different model than OAuth2.  It's probably closer to GNAP, which is why I've been watching that with interest, though not with enough time to engage closely.

Cheers,

Bron.

---

From: Warren Parad <[email-masked]>
Date: Tue, 23 Feb 2021 14:13:59 +0100

Hey Bron,

(caveat: I only skimmed the other conversation)

I'm trying to figure out how best to digest your message. I feel like I'm
missing context in your message, is there something about JMAP required
authentication that you're asking to be considered in OAuth. Help me figure
out what I'm missing.

- Warren

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress.io/>.

On Tue, Feb 23, 2021 at 2:03 PM Bron Gondwana <[email-masked]>
wrote:

> I don’t know whether it is already too late for your document (which is
> dated 2016) to consider the use of OAuth but Rifaat and I are happy to put
> you on the spot in one of our future virtual office hours or virtual
> interim meetings.
>
>
> That specific document which I mentioned went through many revisions and a
> split to eventually become RFC8620 and RFC8621.  The core JMAP spec says
> this about Authentication:
>
> What it doesn't have is something like what existed in the first draft,
> which allowed out-of-band authentication in many ways, and *probably did
> require security review - but security review from people who wanted it to
> succeed rather than from people who wanted it to go away because it wasn't
> OAuth*.  At the time, that didn't sound like something achievable.  We
> were told that any authentication proposal would have to get past the OAuth
> working group, who would shoot it down or stagnate it for years.  Maybe
> that was wrong, but it was the impression we got from multiple people in
> multiple conversations, both in our working group and in the hallway track.
>
> The original authentication protocol started with a username and a
> service, and got back a session token plus list of authentication methods
> that were allowed, or even a "we already authenticated you out of band - go
> right ahead".
>
> The methods included password or password plus second factor, but also
> allowed for things like "here's a URL, go sign in there and when you're
> finished your session will be valid" or "a popup has been shown in your
> existing sessions on other clients, confirm this code and click OK".
>
> The important thing was that there was no requirement that there be any
> web context built into the client - it could happily just sit there waiting
> for a push event down the push channel to tell it that the session had been
> authorised, or poll to see if it was allowed access yet.  The
> authentication could be entirely out of band after the initial handshake.
>
> It's a quite different model than OAuth2.  It's probably closer to GNAP,
> which is why I've been watching that with interest, though not with enough
> time to engage closely.
>
> Cheers,
>
> Bron.
>
> --
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: "Bron Gondwana" <[email-masked]>
Date: Wed, 24 Feb 2021 00:25:08 +1100

On Wed, Feb 24, 2021, at 00:13, Warren Parad wrote:
> I'm trying to figure out how best to digest your message. I feel like I'm missing context in your message, is there something about JMAP required authentication that you're asking to be considered in OAuth. Help me figure out what I'm missing.

We were told at the time "if you're doing an authentication protocol over HTTP, it's going have to go to OAuth group".

---

From: Warren Parad <[email-masked]>
Date: Tue, 23 Feb 2021 14:35:35 +0100

I admit I haven't been present that long in this group, however it might
help to start at the beginning. So far I see rfc8620
<https://tools.ietf.org/html/rfc8620> already exists, is there a draft or
something else you want to discuss?

Are you hoping to introduce a new authentication protocol?

Any additional information would be appreciated.

Warren Parad

Founder, CTO

On Tue, Feb 23, 2021 at 2:25 PM Bron Gondwana <[email-masked]>
wrote:

> We were told at the time "if you're doing an authentication protocol over
> HTTP, it's going have to go to OAuth group".
>
> --

---

From: Roman Danyliw <[email-masked]>
Date: Tue, 23 Feb 2021 14:29:40 +0000

Hi!

From: ietf <[email-masked]> On Behalf Of Bron Gondwana
Sent: Tuesday, February 23, 2021 7:47 AM
To: Rifaat Shekh-Yusef <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: Diversity and Inclusiveness in the IETF

That's good to hear.

[Roman] In addition to regular cadence of proposed standard publications noted above, I would additionally note that all of these documents came with a model behavior of multiple implementations by WGLC - typically 3+.  The WG has not only managed to steadily complete its work items in the IETF but also interest an implementor community to ensure this work is used.

Regards,
Roman

---

From: Brian Campbell <[email-masked]>
Date: Tue, 23 Feb 2021 08:09:14 -0700

Just to add a little context - this is an offshoot of a discussion that's
happening over on the ietf@ list:
https://mailarchive.ietf.org/arch/msg/ietf/pTFOZjhuZfj45pnUNOr7Pt-YnGc/

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 23 Feb 2021 10:20:51 -0500

On Tue, Feb 23, 2021 at 9:30 AM Roman Danyliw <[email-masked]> wrote:

> *Sent:* Tuesday, February 23, 2021 7:47 AM
> *To:* Rifaat Shekh-Yusef <[email-masked]>
> *Cc:* [email-masked]; [email-masked]
> So you have never reached out to us to try to bring any work to the WG,
> and based on attending one meeting and hearing from a few people, you
> formed a strong opinion and declared that "nothing would get done"? that
> seems odd.
>
>
>
> [Roman] In addition to regular cadence of proposed standard publications
> noted above, I would additionally note that all of these documents came
> with a model behavior of multiple implementations by WGLC – typically 3+.
> The WG has not only managed to steadily complete its work items in the IETF
> but also interest an implementor community to ensure this work is used.
>

And way back when I was AD, OAuth was by far the most productive working
group I managed.  They put out what felt like about 3 documents a meeting
for full publication.  I was the AD for 3 years, ending in 2017 when EKR
became an AD.

There was a bit of management as a result of the number of experts and
varying use cases for their environments, but even with that, OAuth was
very productive.  Since your document was 2016, I was likely the AD.  Yes,
the meetings had challenges at times, but we worked through it and things
got done.

Best regards,
Kathleen

-- 

Best regards,
Kathleen

---

From: Phil Hunt <[email-masked]>
Date: Tue, 23 Feb 2021 12:02:08 -0800

Bron,

I notice that JMAP is a protocol built on top of HTTP.  Like JMAP, when the SCIM WG was developing SCIM (RFC7643/7644) we had a lot of participants wanting to define authentication within SCIM too.  This in part came from the popular use of the LDAP “bind” feature as a general purpose authentication database.  “Bind” was never intended to be used this way, it just happened.  In the HTTP world, we recognized we were building on top of HTTP with an already diverse set of authentication schemes.

The trade-off is that you ignore all of the schemes built on top of HTTP (RFC7230) *and* you loose any natural agility in the spec as HTTP and authentication techniques evolve over time.  One limitation of IETF specs is that “versioning” specs is difficult. They are intended to reflect long-term stabilized practices after a period of agile-like ID spec iteration.  

The downside to saying “any HTTP mechanism” is usable is that it does create point-in-time interop challenges as parties have to agree on authentication schemes. However, this is less of an implementation problem as one might think. Most platforms (e.g. Spring, Quarkus) offer all of the popular mechanisms. The challenge therefor becomes one of deployment and configuration rather than implementation.

As an example, as OAuth evolves, the libraries pick up the changes and dependent systems like SCIM pick it up transparently. This speaks to some of the “existing applications” concerns that Hannes mentioned.

So yes, you could narrowly define authentication in JMAP but it’s lifespan will become severely limited as authentication requirements and risks evolve over time.  Case in point. the OAuth WG has had to maintain a sustained evolution of specs and best practices. Why bog JMAP down with such a huge domain as authentication?

Hope this helps.

Phil Hunt
@independentid
[email-masked]

> On Feb 23, 2021, at 7:09 AM, Brian Campbell <bcampbell=[email-masked]> wrote:
> 
> Just to add a little context - this is an offshoot of a discussion that's happening over on the ietf@ list: https://mailarchive.ietf.org/arch/msg/ietf/pTFOZjhuZfj45pnUNOr7Pt-YnGc/ <https://mailarchive.ietf.org/arch/msg/ietf/pTFOZjhuZfj45pnUNOr7Pt-YnGc/>
> On Tue, Feb 23, 2021 at 6:36 AM Warren Parad <wparad=[email-masked] <mailto:[email-masked]>> wrote:
> I admit I haven't been present that long in this group, however it might help to start at the beginning. So far I see rfc8620 <https://tools.ietf.org/html/rfc8620> already exists, is there a draft or something else you want to discuss?
> 
> Secure your user data with IAM authorization as a service. Implement Authress <https://authress.io/>.
> 
> 
> On Tue, Feb 23, 2021 at 2:25 PM Bron Gondwana <[email-masked] <mailto:[email-masked]>> wrote:
>   [email-masked] <mailto:[email-masked]>
> 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> 
> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._______________________________________________
> OAuth mailing list
> [email-masked]

---

From: "Bron Gondwana" <[email-masked]>
Date: Wed, 24 Feb 2021 08:54:36 +1100

Yeah - the discussion has wandered into the weeds (and I'm largely responsible for this) about whether the way JMAP was proposing doing Authentication was the right way, rather than the meta topic which started this which was "my impression on joining the IETF was that OAuth working group was toxic and unwelcoming to new work, and taking anything there was a sure-fire way to make sure nothing got progressed".

And my experience of being a tourist in the OAuth face-to-face meetings was consistent with that impression.  There was an awfully large amount of talking and an awfully small amount of listening going on - with the IETF102 Thursday meeting being particularly bad (I had a clash for Tuesday's meeting, so I don't know how that one went).

Maybe it's a completely different place now - but one of two things must be true:

a) the OAuth group is insular and unwelcoming; or
b) there's a false impression of the OAuth group that's been circulating for years, at least within the applications area which is where I spend most of my time.

Back on the specifics...

I do want to quote this: *"The challenge therefor becomes one of deployment and configuration rather than implementation."* because that's part of the impression that I got of OAuth. I come from a world where deployment and configuration are major hurdles, and in fact OAuth interoperability is a major mess because it's such a flexible toolkit.  Just this week I've run into issues where Yahoo's SMTP "XOAUTH2" is behaving differently from Google's and we had delivery issues for authenticated sending.

If every client and every server needs to implement "*all the popular mechanisms*" then that's not such a big deal when you're shipping the client code for your own server as part of a website, but it's a big deal if you're trying to create a general client and don't want to have to hard-code the specific magic for each server provider.

So the reason to encode the authentication mechanism into JMAP was precisely to reduce the number of possibilities.

Bron.

On Wed, Feb 24, 2021, at 07:02, Phil Hunt wrote:
>> Just to add a little context - this is an offshoot of a discussion that's happening over on the ietf@ list: https://mailarchive.ietf.org/arch/msg/ietf/pTFOZjhuZfj45pnUNOr7Pt-YnGc/
>> 
>> On Tue, Feb 23, 2021 at 6:36 AM Warren Parad <wparad=[email-masked]> wrote:
>>> *Warren Parad*
>>> On Tue, Feb 23, 2021 at 2:25 PM Bron Gondwana <[email-masked]> wrote:
>>>> __
>> *CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.*_______________________________________________
>> OAuth mailing list
>> [email-masked]

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 24 Feb 2021 08:57:06 +1100

> On 24 Feb 2021, at 2:20 am, Kathleen Moriarty <[email-masked]> wrote:
[...]
> And way back when I was AD, OAuth was by far the most productive working group I managed.  They put out what felt like about 3 documents a meeting for full publication.  I was the AD for 3 years, ending in 2017 when EKR became an AD.
> 
> There was a bit of management as a result of the number of experts and varying use cases for their environments, but even with that, OAuth was very productive.  Since your document was 2016, I was likely the AD.  Yes, the meetings had challenges at times, but we worked through it and things got done.

Measuring productivity through the number of documents published is not a good habit for us to get into; it gives incentive to all of the wrong kinds of behaviours. Having some success metrics for our work has come up in the IAB a few times, but we haven't made much progress.  

Cheers,

--
Mark Nottingham   https://www.mnot.net/

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Tue, 23 Feb 2021 17:11:03 -0500

On Tue, Feb 23, 2021 at 4:57 PM Mark Nottingham <[email-masked]> wrote:

> Measuring productivity through the number of documents published is not a
> good habit for us to get into;

The number of documents published was in response to a comment that
"nothing would get done" at the OAuth WG. Which is clearly not true.

> it gives incentive to all of the wrong kinds of behaviours.

Can you elaborate on these wrong behaviours?

Regards,
 Rifaat

> Having some success metrics for our work has come up in the IAB a few
> times, but we haven't made much progress.
>
> Cheers,
>
>
> --

---

From: Evert Pot <[email-masked]>
Date: Tue, 23 Feb 2021 17:36:24 -0500

> If every client and every server needs to implement "/all the popular 
> mechanisms/" then that's not such a big deal when you're shipping the 
> client code for your own server as part of a website, but it's a big 
> deal if you're trying to create a general client and don't want to 
> have to hard-code the specific magic for each server provider.
>
> So the reason to encode the authentication mechanism into JMAP was 
> precisely to reduce the number of possibilities.

I want to echo this as a something I also feel OAuth2 has failed at 
(thusfar). We used to be able to point our user-agent at an endpoint, 
get a WWW-Authenticate & 401, and the agent would be able to figure out 
how to log the user in. I can't point my browser to an OAuth2 protected 
endpoint and discover what an API offers.

With OAuth2 we need a ton of out-of-band information. I think this is 
partially contributing to people not building generic HTTP clients, but 
SDKs for each service. To some extent I think it's breaking the web.

I hope a future version of OAuth prioritizes server-driven oauth2 
configuration.

Evert

P.S.: I do appreciate all the work that has gone in OAuth2, and this 
specific criticism is not intended as an overall sentiment.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 23 Feb 2021 14:39:24 -0800

Replying to Rifaat's e-mail but not replying to him specifically.

Hi folks,

I don't think the question of whether OAuth is a good or bad WG group is
really a productive one in general, and it's especially hard for me to see
how it's going to let us make progress on questions of DEI. This seems like
precisely the kind of thing that's going to lead to a bunch of hard
feelings without making progress. I think we can all agree that the IETF
culture isn't perfect and that there are cases where we make it hard for
new people to get involved, so maybe we could focus instead on those
aspects of our culture.

I would suggest that if people have problems with the way the OAuth WG is
being run they ought to take it up with the AD (Roman Danyliw), or, failing
that, on the IETF list.

-Ekr

On Tue, Feb 23, 2021 at 2:12 PM Rifaat Shekh-Yusef <[email-masked]>
wrote:

>> > And way back when I was AD, OAuth was by far the most productive
>> working group I managed.  They put out what felt like about 3 documents a
>> meeting for full publication.  I was the AD for 3 years, ending in 2017
>> when EKR became an AD.
>> >

---

From: Warren Parad <[email-masked]>
Date: Wed, 24 Feb 2021 00:14:23 +0100

Okay, now I'm lost, what's the point of this discussion? Is there something
we are actively trying to achieve?

The email subject is *JMAP's experience with proposing an Authentication
model*, sometimes sharing experiences is helpful, but I still lack the goal
we are attempting to accomplish by doing that. Are we hoping to change
something in particular, if so, what exactly is that? Is it the culture of
the group, how the OAuth specs are written, the goal of the WG, or
something else?

Warren Parad

Founder, CTO

On Tue, Feb 23, 2021 at 11:36 PM Evert Pot <[email-masked]> wrote:

>
> If every client and every server needs to implement "*all the popular
> mechanisms*" then that's not such a big deal when you're shipping the
> client code for your own server as part of a website, but it's a big deal
> if you're trying to create a general client and don't want to have to
> hard-code the specific magic for each server provider.
>
> (thusfar). We used to be able to point our user-agent at an endpoint, get a
> WWW-Authenticate & 401, and the agent would be able to figure out how to
> log the user in. I can't point my browser to an OAuth2 protected endpoint
> and discover what an API offers.
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 24 Feb 2021 00:47:03 -0500

I am worried by the advice 'use OAUTH' but for a very different reason.

OAUTH and SAML are both attempts to provide a secure authentication scheme
that works within the very particular and very peculiar environment of Web
browsers. They are schemes that necessarily involve techniques that are
rightly regarded as alchemy if not outright witchcraft.

That is fine, that is more than fine if you are developing an
authentication scheme for use within Web browsers (or if you are developing
whatever SAML and OAUTH are these days, neither was originally billed as
authentication). But it is completely inappropriate to ever suggest let
alone demand that anyone use a technology whose primary design constraint
is to work around the voodoo of Javascript, URIs, HTTP cookies etc. etc. in
an application where none of those legacy issues apply.

One of the big problems of IETF is that a lot of people don't think about
how to get their scheme deployed and when they do, their plan is to tie it
to some other group as a boat anchor. Back when we were doing DKIM and SPF
we had to tell certain DNS folk that the fact that almost no DNS Registrars
offered customers the ability to specify new RRTypes was their problem and
was going to remain their problem no matter how loudly they tried to
complain that it should become our problem.

In the case of OAUTH, there is another problem in that OAUTH really isn't a
very open protocol from the standpoint of the user. I can use my Google or
my Facebook or my Twitter accounts to log in via OAUTH at a large number of
sites. But if I want to use any other OAUTH provider I am completely out of
luck. Or at least I will be until this becomes one of the multifaceted
complaints in the anti-trust hearings coming soon to a capitol hill near
you. And yes, that is a consequence of how the protocol has been deployed,
but that probably not going to get people very far on capitol hill.

The Internet is for everyone. The Internet is for end users.

I am really not that interested in who makes the ingredients except to the
extent that it determines what sort of cake emerges. One of the unexpected
side effects of Web 2.0 has been that it has greatly centralized power in
the hands of a tiny number of individuals. Individuals who are at best
accountable to shareholders, but in the case of some of them, a separate
share class ensures that they are accountable to nobody. In neither case
are the people with power accountable to end users because they are not
even customers, they are the product.

What I am interested in is the extent to which Internet technologies are
Technologies of Freedom. The question we need to ask ourselves is 'does
this technology increase end user autonomy or increase their reliance on
third parties'.

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 24 Feb 2021 17:01:22 +1100

Just to +1 and add my bit: in my mind one of the fundamental flaws of the Web is that it is basically a platform construction toolkit, without any of the checks or balances we put into *real* internet platforms to assure that there isn't one chokepoint with all of the power. As a result, it's tilted heavily towards winner-take-all economists through accrual of network effects and data advantages.

We should not follow this pattern in IETF specifications, whether or not they're associated with the Web. OAUTH-as-deployed might be one good example, but WEBRTC is equally problematic in this regard. WEBTRANS smells like it's primarily going to benefit big platforms who want to control the entire end user experience (and have the resources to exploit it), and let's not even get started about WPACK.

Yes, federation is hard. Yes, standards are slow and not as able to respond. Yes, the commercial incentives for silo'd platforms to invest aren't present. However, there's a *huge* push by competition authorities and regulators to find remedies for the concentrations of power in these few hands, and in many minds interoperability standards -- enforced by legal instruments -- are a primary means of getting there. This is potentially game-changing, in terms of the work that's possible to ship here.

I wrote a bit more about this recently:
  https://www.mnot.net/blog/2021/02/18/no-news

Cheers,

> On 24 Feb 2021, at 4:47 pm, Phillip Hallam-Baker <[email-masked]> wrote:
> 
> OAUTH and SAML are both attempts to provide a secure authentication scheme that works within the very particular and very peculiar environment of Web browsers. They are schemes that necessarily involve techniques that are rightly regarded as alchemy if not outright witchcraft.
> 
> That is fine, that is more than fine if you are developing an authentication scheme for use within Web browsers (or if you are developing whatever SAML and OAUTH are these days, neither was originally billed as authentication). But it is completely inappropriate to ever suggest let alone demand that anyone use a technology whose primary design constraint is to work around the voodoo of Javascript, URIs, HTTP cookies etc. etc. in an application where none of those legacy issues apply.
> 
> One of the big problems of IETF is that a lot of people don't think about how to get their scheme deployed and when they do, their plan is to tie it to some other group as a boat anchor. Back when we were doing DKIM and SPF we had to tell certain DNS folk that the fact that almost no DNS Registrars offered customers the ability to specify new RRTypes was their problem and was going to remain their problem no matter how loudly they tried to complain that it should become our problem. 
> 
> In the case of OAUTH, there is another problem in that OAUTH really isn't a very open protocol from the standpoint of the user. I can use my Google or my Facebook or my Twitter accounts to log in via OAUTH at a large number of sites. But if I want to use any other OAUTH provider I am completely out of luck. Or at least I will be until this becomes one of the multifaceted complaints in the anti-trust hearings coming soon to a capitol hill near you. And yes, that is a consequence of how the protocol has been deployed, but that probably not going to get people very far on capitol hill.
> 
> 
> I am really not that interested in who makes the ingredients except to the extent that it determines what sort of cake emerges. One of the unexpected side effects of Web 2.0 has been that it has greatly centralized power in the hands of a tiny number of individuals. Individuals who are at best accountable to shareholders, but in the case of some of them, a separate share class ensures that they are accountable to nobody. In neither case are the people with power accountable to end users because they are not even customers, they are the product.
> 
> What I am interested in is the extent to which Internet technologies are Technologies of Freedom. The question we need to ask ourselves is 'does this technology increase end user autonomy or increase their reliance on third parties'.

---

From: Larry Masinter <[email-masked]>
Date: Tue, 23 Feb 2021 22:07:56 -0800

Cogent argument that brings to focus on the  Subject:  topic what seemed like a “side” conversation about friendliness of the OAUTH wg. 

From: ietf <[email-masked]> On Behalf Of Phillip Hallam-Baker
Sent: Tuesday, February 23, 2021 9:47 PM
To: Kathleen Moriarty <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: Diversity and Inclusiveness in the IETF

---

From: Jim Manico <[email-masked]>
Date: Wed, 24 Feb 2021 01:26:32 -0500

I think it’s important to point out that OAuth is not an authentication protocol. It’s for delegation. OAuth is one of the most mis-used protocols on the modern web. If you really want to support end users, a good place to start is to make it clear to developers what OAuth is really for so secure solutions are built as opposed to the dumpster fire that OAuth solutions have become today.

Regards,
--
Jim Manico
@Manicode
Secure Coding Education

> On Feb 24, 2021, at 12:48 AM, Phillip Hallam-Baker <[email-masked]> wrote:
> 
>

---

From: "Bron Gondwana" <[email-masked]>
Date: Wed, 24 Feb 2021 18:06:52 +1100

> I think it’s important to point out that OAuth is not an authentication protocol. It’s for delegation. OAuth is one of the most mis-used protocols on the modern web. If you really want to support e…

https://en.wikipedia.org/wiki/The_purpose_of_a_system_is_what_it_does

Which suggests that if the OAuth solutions deployed today are dumpster fires, then ... well, that's what OAuth 2 does.

My biggest problem with OAuth as an outsider is that it doesn't solve the NxM problem.  You can't build a client which can OAuth against any arbitrary OAuth service that provides a standard protocol, because you need to get an API key for your particular application from each service provider.  This just doesn't scale, which is a large part of Phillip's complaint as well.

Of course, I came into the IETF having already read https://web.archive.org/web/20120731155632/http://hueniverse.com/2012/07/oauth-2-0-and-the-road-to-hell/ - which was one of the things which made me wary of the IETF in the first place, and keen to not let everything I touched get over-complicated.

Bron.

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 24 Feb 2021 09:09:11 +0000

Hi Phil,

I am moving this to the OAuth group to avoid confusing the IETF list any further.

See my feedback below.

Sent: Wednesday, February 24, 2021 6:47 AM

[Hannes] OAuth and SAML were initially developed for the Web because the web is an important deployment use case. Both protocols had a very different history and also different use cases. OAuth is for delegated access and SAML was developed as a WebSSO solution. OAuth and SAML were later extended to other environments too. In case of OAuth you can find some of this info in our documents, such as the OAuth 2.0 for native apps.

That is fine, that is more than fine if you are developing an authentication scheme for use within Web browsers (or if you are developing whatever SAML and OAUTH are these days, neither was originally billed as authentication).

[Hannes] OAuth is not an authentication scheme, particularly when referring to users. It is explicitly the intention to keep the user authentication part outside OAuth, which allows us to use the most modern user authentication technology available without having to touch OAuth.

But it is completely inappropriate to ever suggest let alone demand that anyone use a technology whose primary design constraint is to work around the voodoo of Javascript, URIs, HTTP cookies etc. etc. in an application where none of those legacy issues apply.

[Hannes] It is difficult to comment on this because I don’t know the context. Maybe OAuth was a fine choice and maybe it wasn’t. I don’t know. We all agree that OAuth is not going to be the answer to every question.

One of the big problems of IETF is that a lot of people don't think about how to get their scheme deployed and when they do, their plan is to tie it to some other group as a boat anchor.

[Hannes] In general, standing on the shoulders of giants is not a bad approach. Changes are that there is a potential for re-use. OAuth also wasn’t produced in a vacuum either. We use JSON as an encoding for the access tokens with the JWT when the work in the JOSE group was started. We also had to work with the nuances of HTTP. We made use of TLS.

Back when we were doing DKIM and SPF we had to tell certain DNS folk that the fact that almost no DNS Registrars offered customers the ability to specify new RRTypes was their problem and was going to remain their problem no matter how loudly they tried to complain that it should become our problem.

[Hannes] I cannot comment on DKIM and SPK because I was not involved in that work.

[Hannes] OAuth 2.0 is a specification. It has a couple of flows. A product and a service adds more to OAuth, i.e. OAuth is just a building block in a larger ecosystem. That ecosystem will contain the actual application and also the user authentication component (among other things). Companies make their own decision about how they want to use OAuth in their product. A fitness company may decide to allow its users to share their heart rate data with others (assuming consent of the user). It may also decide not to do it. It is a business decision. OAuth allows you to do it securely with the consent of the user. Neither the OAuth spec nor the IETF can tell companies who they should work with.

[Hannes] Those are great words but they mean nothing in this context. You know that.

[Hannes] I believe the IETF is good at producing building blocks, has little experience in complete systems and no experience with building actual products. You are complaining about the products. You are blaming the wrong people.

[Hannes] OAuth is flexible. You could use in your own personal data store and people have done that. Then, you are controlling everything. You can also setup a company to offer that service to others because there will be some users who do not want to run everything themselves.

I understand that some of the developments on the Internet are concerning and I share your concerns. If you believe OAuth is a reason for this development then I have to disagree with you.

Ciao
Hannes

---

From: Warren Parad <[email-masked]>
Date: Wed, 24 Feb 2021 11:22:31 +0100

Should we solve the NxM problem, and if so, how do you propose we do that?

Warren Parad

Founder, CTO

On Wed, Feb 24, 2021 at 8:08 AM Bron Gondwana <[email-masked]>
wrote:

> I think it’s important to point out that OAuth is not an authentication
> protocol. It’s for delegation. OAuth is one of the most mis-used protocols
> on the modern web. If you really want to support end users, a good place to
> start is to make it clear to developers what OAuth is really for so secure
> solutions are built as opposed to the dumpster fire that OAuth solutions
> have become today.
>
>
> Which suggests that if the OAuth solutions deployed today are dumpster
> fires, then ... well, that's what OAuth 2 does.
>
> My biggest problem with OAuth as an outsider is that it doesn't solve the
> NxM problem.  You can't build a client which can OAuth against any
> arbitrary OAuth service that provides a standard protocol, because you need
> to get an API key for your particular application from each service
> provider.  This just doesn't scale, which is a large part of Phillip's
> complaint as well.
>
> Of course, I came into the IETF having already read
> https://web.archive.org/web/20120731155632/http://hueniverse.com/2012/07/oauth-2-0-and-the-road-to-hell/
> - which was one of the things which made me wary of the IETF in the first
> place, and keen to not let everything I touched get over-complicated.
>
> Bron.
>
> --

---

From: Warren Parad <[email-masked]>
Date: Wed, 24 Feb 2021 11:22:49 +0100

👏

Warren Parad

Founder, CTO

On Wed, Feb 24, 2021 at 10:09 AM Hannes Tschofenig <
[email-masked]> wrote:

> *From:* ietf <[email-masked]> *On Behalf Of * Phillip Hallam-Baker
> *Sent:* Wednesday, February 24, 2021 6:47 AM
> *To:* Kathleen Moriarty <[email-masked]>
> [Hannes] OAuth and SAML were initially developed for the Web because the
> web is an important deployment use case. Both protocols had a very
> different history and also different use cases. OAuth is for delegated
> access and SAML was developed as a WebSSO solution. OAuth and SAML were
> later extended to other environments too. In case of OAuth you can find
> some of this info in our documents, such as the OAuth 2.0 for native apps.
>
>
>
> authentication).
> [Hannes] OAuth is not an authentication scheme, particularly when
> referring to users. It is explicitly the intention to keep the user
> authentication part outside OAuth, which allows us to use the most modern
> user authentication technology available without having to touch OAuth.
>
>
>
> But it is completely inappropriate to ever suggest let alone demand that
> anyone use a technology whose primary design constraint is to work around
> the voodoo of Javascript, URIs, HTTP cookies etc. etc. in an application
> where none of those legacy issues apply.
>
>
>
> [Hannes] It is difficult to comment on this because I don’t know the
> context. Maybe OAuth was a fine choice and maybe it wasn’t. I don’t know.
> We all agree that OAuth is not going to be the answer to every question.
>
>
>
> to some other group as a boat anchor.
>
>
>
> [Hannes] In general, standing on the shoulders of giants is not a bad
> approach. Changes are that there is a potential for re-use. OAuth also
> wasn’t produced in a vacuum either. We use JSON as an encoding for the
> access tokens with the JWT when the work in the JOSE group was started. We
> also had to work with the nuances of HTTP. We made use of TLS.
>
>
>
> Back when we were doing DKIM and SPF we had to tell certain DNS folk that
> the fact that almost no DNS Registrars offered customers the ability to
> specify new RRTypes was their problem and was going to remain their problem
> no matter how loudly they tried to complain that it should become our
> problem.
>
>
>
> In the case of OAUTH, there is another problem in that OAUTH really isn't
> a very open protocol from the standpoint of the user. I can use my Google
> or my Facebook or my Twitter accounts to log in via OAUTH at a large number
> of sites. But if I want to use any other OAUTH provider I am completely out
> of luck. Or at least I will be until this becomes one of the multifaceted
> [Hannes] OAuth 2.0 is a specification. It has a couple of flows. A product
> and a service adds more to OAuth, i.e. OAuth is just a building block in a
> larger ecosystem. That ecosystem will contain the actual application and
> also the user authentication component (among other things). Companies make
> their own decision about how they want to use OAuth in their product. A
> fitness company may decide to allow its users to share their heart rate
> data with others (assuming consent of the user). It may also decide not to
> do it. It is a business decision. OAuth allows you to do it securely with
> the consent of the user. Neither the OAuth spec nor the IETF can tell
> companies who they should work with.
>
>
>
> [Hannes] I believe the IETF is good at producing building blocks, has
> little experience in complete systems and no experience with building
> actual products. You are complaining about the products. You are blaming
> the wrong people.
>
>
>
>
>
> [Hannes] OAuth is flexible. You could use in your own personal data store
> and people have done that. Then, you are controlling everything. You can
> also setup a company to offer that service to others because there will be
> some users who do not want to run everything themselves.
>
>
>
>
>
> I understand that some of the developments on the Internet are concerning
> and I share your concerns. If you believe OAuth is a reason for this
> development then I have to disagree with you.
>
>
>
> Ciao
>
> Hannes
>
>

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 24 Feb 2021 11:36:13 +0100

> Should we solve the NxM problem, and if so, how do you propose we do that?

Let GNAP do that.

Grüße, Carsten

---

From: Warren Parad <[email-masked]>
Date: Wed, 24 Feb 2021 12:04:40 +0100

I would prefer Bron to answer that question, as they are the one who
started this email thread.

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.

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.

Would you agree with that statement?

Warren Parad

Founder, CTO

---

From: "Bron Gondwana" <[email-masked]>
Date: Wed, 24 Feb 2021 22:39:11 +1100

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] https://www.fastmail.help/hc/en-us/articles/360058753834-SSL-TLS-and-STARTTLS

---

From: Warren Parad <[email-masked]>
Date: Wed, 24 Feb 2021 13:09:14 +0100

(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?*

Warren Parad

Founder, CTO

On Wed, Feb 24, 2021 at 12:39 PM Bron Gondwana <[email-masked]>
wrote:

> 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.
>
> 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.
>
> 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.
>
> 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]
> https://www.fastmail.help/hc/en-us/articles/360058753834-SSL-TLS-and-STARTTLS
>
> --

---

From: "Bron Gondwana" <[email-masked]>
Date: Wed, 24 Feb 2021 23:15:15 +1100

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.

> On Wed, Feb 24, 2021 at 12:39 PM Bron Gondwana <[email-masked]> wrote:
>> __

---

From: Neil Madden <[email-masked]>
Date: Wed, 24 Feb 2021 12:20:56 +0000

On 24 Feb 2021, at 11:39, Bron Gondwana <[email-masked]> wrote:
>> […]

Does the following meet your needs?

You type your email address into {The Bat} to begin configuration. {The Bat} does discovery [1][2] to locate the OAuth/OIDC server for {My ISP}. The discovery document reveals that {My ISP} supports open dynamic client registration [3][4] so {The Bat} registers and gets issued with a client id and client secret. {The Bat} then does a normal OAuth flow to get an access token to access your emails from {My ISP}. If you later stop using {The Bat} you can go to your page on {My ISP} and revoke its access because it has a unique client id.

[1]: https://openid.net/specs/openid-connect-discovery-1_0.html <https://openid.net/specs/openid-connect-discovery-1_0.html>
[2]: https://tools.ietf.org/html/rfc8414 <https://tools.ietf.org/html/rfc8414> 
[3]: https://openid.net/specs/openid-connect-registration-1_0.html <https://openid.net/specs/openid-connect-registration-1_0.html>
[4]: https://tools.ietf.org/html/rfc7591 <https://tools.ietf.org/html/rfc7591> 

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

That’s fine for your use-case, but that isn’t everybody’s use-case. Other use-cases (such as Open Banking) involve regulatory or policy frameworks in which open dynamic client registration is not appropriate. JMAP could have an RFC describing the use of OAuth with JMAP that mandates open dynamic client registration and discovery.

— Neil

-- 
ForgeRock values your Privacy <https://www.forgerock.com/your-privacy>

---

From: Aaron Parecki <[email-masked]>
Date: Wed, 24 Feb 2021 05:44:53 -0800

> You type your email address into {The Bat} to begin configuration. {The
Bat} does discovery [1][2] to locate the OAuth/OIDC server for {My ISP}.
The discovery document reveals that {My ISP} supports open dynamic client
registration [3][4] so {The Bat} registers and gets issued with a client id
and client secret. {The Bat} then does a normal OAuth flow to get an access
token to access your emails from {My ISP}. If you later stop using {The
Bat} you can go to your page on {My ISP} and revoke its access because it
has a unique client id.

Like Neil says, the building blocks are all already there. The fact that
companies choose not to use them is not because the technology isn't there,
it's because it's a business problem.

I'd be thrilled if the NxM problem were solved in practice, but
unfortunately that doesn't seem to be what's happened in the market. The
technical solution has been there a long time, so there's something else
going on.

When I've brought up this topic in the past, most of the responses I've
gotten from the "big players" are along the lines of "lol we're not going
to let someone's software talk to us unless we have a legal arrangement
with the developer". The fact that dynamic client registration is barely
used is more because these service operators want the software developers
to agree to their terms of service before being able to access APIs.

This is all to say that I agree it'd be nice to solve this problem, but in
the end, the IETF can't tell companies what to do with their products and
services.

Aaron

On Wed, Feb 24, 2021 at 4:21 AM Neil Madden <[email-masked]>
wrote:

> You type your email address into {The Bat} to begin configuration. {The
> Bat} does discovery [1][2] to locate the OAuth/OIDC server for {My ISP}.
> The discovery document reveals that {My ISP} supports open dynamic client
> registration [3][4] so {The Bat} registers and gets issued with a client id
> and client secret. {The Bat} then does a normal OAuth flow to get an access
> token to access your emails from {My ISP}. If you later stop using {The
> Bat} you can go to your page on {My ISP} and revoke its access because it
> has a unique client id.
>
> [1]: https://openid.net/specs/openid-connect-discovery-1_0.html
> [2]: https://tools.ietf.org/html/rfc8414
> [3]: https://openid.net/specs/openid-connect-registration-1_0.html
> [4]: https://tools.ietf.org/html/rfc7591
>
>
> That’s fine for your use-case, but that isn’t everybody’s use-case. Other
> use-cases (such as Open Banking) involve regulatory or policy frameworks in
> which open dynamic client registration is not appropriate. JMAP could have
> an RFC describing the use of OAuth with JMAP that mandates open dynamic
> client registration and discovery.
>
>
> — Neil
>
>
-- 
---
Aaron Parecki
https://aaronparecki.com

---

From: Jim Willeke <[email-masked]>
Date: Wed, 24 Feb 2021 09:59:21 -0500

But in reality, Just "because the technology" is there there leaves out the
practicality of creating a secure implementation. Sure, you could write it
off as "a business problem" but many of the developers are small and not
unusually single person operations that do not have the resources to create
a specific team, or even a specific person, to work through all the
specifications that are involved.

I do believe, in general, specific implementations should not be within
the specifications but a "Best Practices" or "Common Implementations"
document to coincide with the specifications might be in order.

Just spend some time on https://stackexchange.com/filters/4229/oauth and
you will see the issue and struggles.

--
-jim
Jim Willeke

On Wed, Feb 24, 2021 at 8:46 AM Aaron Parecki <[email-masked]> wrote:

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

---

From: Justin Richer <[email-masked]>
Date: Wed, 24 Feb 2021 10:18:22 -0500

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 <[email-masked]> wrote:
> 
> 
> 
>> Is this or should this problem be left to GNAP to solve, or is an OAuth WG responsibility?
> 
>> On Wed, Feb 24, 2021 at 12:39 PM Bron Gondwana <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> [1] https://www.fastmail.help/hc/en-us/articles/360058753834-SSL-TLS-and-STARTTLS <https://www.fastmail.help/hc/en-us/articles/360058753834-SSL-TLS-and-STARTTLS>
>> 
>> --

---

From: Aaron Parecki <[email-masked]>
Date: Wed, 24 Feb 2021 07:21:33 -0800

> Sure, you could write it off as "a business problem" but

I did not mean to suggest that I was *writing it off* as a business
problem.

It *is* a very real problem, and I would very much like to see a solution,
however based on my experience it is not something that technology will
solve. This is demonstrated by the fact that there are all the pieces in
place already yet many organizations refuse to adopt them, and it’s
definitely not for a lack of understanding.

Aaron

On Wed, Feb 24, 2021 at 7:01 AM Jim Willeke <[email-masked]> wrote:

> But in reality, Just "because the technology" is there there leaves out
> the practicality of creating a secure implementation. Sure, you could write
> it off as "a business problem" but many of the developers are small and not
>> > You type your email address into {The Bat} to begin configuration.
>> {The Bat} does discovery [1][2] to locate the OAuth/OIDC server for {My
>> ISP}. The discovery document reveals that {My ISP} supports open dynamic
>> client registration [3][4] so {The Bat} registers and gets issued with a
>> client id and client secret. {The Bat} then does a normal OAuth flow to get
>> an access token to access your emails from {My ISP}. If you later stop
>> using {The Bat} you can go to your page on {My ISP} and revoke its access
>> because it has a unique client id.
>>
>> This is all to say that I agree it'd be nice to solve this problem, but
>> in the end, the IETF can't tell companies what to do with their products
>> and services.
>>
>> Aaron
>>
>>
>>
>>
>>> That’s fine for your use-case, but that isn’t everybody’s use-case.
>>> Other use-cases (such as Open Banking) involve regulatory or policy
>>> frameworks in which open dynamic client registration is not appropriate.
>>> JMAP could have an RFC describing the use of OAuth with JMAP that mandates
>>> open dynamic client registration and discovery.
>>>
>>>
>>> — Neil
>>>
>>>
-- 
---
Aaron Parecki
https://aaronparecki.com

---

From: Jim Willeke <[email-masked]>
Date: Wed, 24 Feb 2021 10:34:08 -0500

I didn't mean to imply "you" were writing it off and you are probably right
technology may not be able to solve it, I was just looking for ways we
might help?

--
-jim
Jim Willeke

---

From: Tim Bray <[email-masked]>
Date: Wed, 24 Feb 2021 08:34:35 -0800

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 <[email-masked]> 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:
>
> - {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
>
> 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

---

From: Warren Parad <[email-masked]>
Date: Wed, 24 Feb 2021 17:48:29 +0100

I'll add just one more thing here, even if the protocol exists, the
clarity, and was supported, I'm not sure that it would even be that widely
used. Thinking about this from the user perspective, I just can't imagine
how many would really choose to even need or want to set up these other
mechanisms. There is a very small community dedicated to web3.0 which
supports browser extensions to log in to various tools via crypto
blockchains.

There's still only a handful, and identity providers, who are actually in
this WG, can attest to supporting N+ number of AS and WebAuthN, and
username/password, and likely anything else users want. As one of them, we
add anything and everything that application developers want to support. So
it isn't the lack of paradigms, RFCs, or general neglect (/lack of desire)
to implement these. The blocking factor is the symbiotic evolution of user
desires, platform capabilities, and AS features. So as all AS don't support
all features, and as it seems the capabilities are there, even if they were
supported by user facing applications, there is still further that the
community as a whole needs to go to adopt the mindset of wanting to bring
custom unverified AS to the table.

Warren Parad

Founder, CTO

On Wed, Feb 24, 2021 at 5:34 PM Tim Bray <[email-masked]> wrote:

>> - {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.
>>
>> 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:
>>
>> 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
>> 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

---

From: Michael Richardson <[email-masked]>
Date: Wed, 24 Feb 2021 12:05:14 -0500

Justin Richer <[email-masked]> wrote:
    > arbitrary clients talk to an AS, but the trust isn’t there in
    > practice.

As an example of a fail even in a closed ecosystem: neither Google nor
Facebook nor LinkedIn nor .. permit one to login to them with themselves.
Even if we believe that there are business reasons why they wouldn't delegate
to another, the fact is that they don't delegate to themselves.

What's the use case?  I'll give you two:
  1) parent/child
  2) boss/secretary (*)

My kid is subject to Google Classroom.  A great idea, rather poorly implemented.
The parent interface is basically non-existent.  The advice, from *GOOGLE*
(and my school board) is, in order to find out what your child is
doing... have them share their password with you, the parent.  I read this,
and went WTF?  Doesn't that go against all of the authentication security
precepts that Google and others have been telling us?

(*) - yes there are limited abilities to do this within gmail.  But, it
      does not extend throughout the ecosystem.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: "Bron Gondwana" <[email-masked]>
Date: Thu, 25 Feb 2021 09:30:33 +1100

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

Yep, this is the big point - OAuth is designed to require the the third leg of trust that creates the NxM problem.

If that dotted line between client and server requires a pre-existing trust relationship rather than the trust being entirely mediated by the user choosing to connect client A with server B, then you have the NxM problem.  This is the "you can only have your John Deere tractor serviced by an approved John Deere service centre" problem.  You can only use this client with servers who have pre-approved it.  Or fall back to the "cash of the internet" - plain text passwords.

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

Excellent.  This is precisely what I've been waiting for for these very many years as a viable replacement for storing a password locally on disk.  Just having the server able to distinguish between different client instances for the same user is a big start, because you can de-authorise one without having to lock out every connection - even if the user is still entering their password during the setup phase each time.

This is what Fastmail already do with our own app, creating a long-lived access token and storing that on the device rather than storing the password itself - and you can log out any one client from your security settings page.  What's missing is a standard way to do that with any IMAP client.  The initial JMAP authentication proposal was a very simple case of pretty much this, build into to the protocol so everyone would do it.

Making it easy to connect up arbitrary clients with per-client tokens the default, and easy rather than almost impossible to do in practice is where the big difference comes in.

Bron.

---

From: Seán Kelleher <[email-masked]>
Date: Thu, 25 Feb 2021 08:22:20 +0000

Just to clarify, I assume in this discourse that the "server" in this
client and server relationship refers to an AS/RS pair in OAuth
terminology? Based on this, one big sticking point for me on the
applicability of NxM, or even 1xM, is that all of the "M" RSs need to
publish the same interface for any meaningful implementation in the first
place.

It probably makes more sense with email clients, since as Bron said, there
is the common standard of POP. If we assume that all the email services
that we want to connect to publish the same POP interface, and would accept
tokens in the same way, then the way the authZ is handled is indeed the
point of divergence that needs to be resolved.

However, we're talking about NxM in the general case here. I feel like
using the likes of discovery and dynamic registration, etc. that's already
supported by OAuth, the "N" part of this equation is surmountable. But each
of the "M" servers also need to export the same interface, otherwise a
client is going to have to write custom code to deal with talking to the
service after the authZ step anyway, reintroducing the "problem" part of
the NxM problem.

As such, I would actually suggest constraining this discussion to just the
POP NxM problem rather than NxM in general because, for me at least, the
authZ part of the general case is the most "solved" part of the problem,
and the outstanding work lies more in consolidating the "M" RS interfaces.

On Wed, 24 Feb 2021 at 22:32, Bron Gondwana <[email-masked]> wrote:

> Yep, this is the big point - OAuth is designed to require the the third
> leg of trust that creates the NxM problem.
>
>
>
> If that dotted line between client and server requires a pre-existing
> trust relationship rather than the trust being entirely mediated by the
> user choosing to connect client A with server B, then you have the NxM
> problem.  This is the "you can only have your John Deere tractor serviced
> by an approved John Deere service centre" problem.  You can only use this
> client with servers who have pre-approved it.  Or fall back to the "cash of
> the internet" - plain text passwords.
>
> Excellent.  This is precisely what I've been waiting for for these very
> many years as a viable replacement for storing a password locally on disk.
> Just having the server able to distinguish between different client
> instances for the same user is a big start, because you can de-authorise
> one without having to lock out every connection - even if the user is still
> entering their password during the setup phase each time.
>
> This is what Fastmail already do with our own app, creating a long-lived
> access token and storing that on the device rather than storing the
> password itself - and you can log out any one client from your security
> settings page.  What's missing is a standard way to do that with any IMAP
> client.  The initial JMAP authentication proposal was a very simple case of
> pretty much this, build into to the protocol so everyone would do it.
>
> Making it easy to connect up arbitrary clients with per-client tokens the
> default, and easy rather than almost impossible to do in practice is where
> the big difference comes in.
>
> Bron.
>
> --

---

From: Seán Kelleher <[email-masked]>
Date: Thu, 25 Feb 2021 08:41:05 +0000

> leg of trust that creates the NxM problem.

I believe the snippet of Justin's that you quoted actually shows you how
you can forgo the trust element using dynamic client registration. It still
allows a "server" to identify requests and impose security policies via the
client ID, but without requiring the client author to manually register the
client in advance of using it (e.g. in the case where the client author
doesn't even know what servers the client is going to be connecting to).
You still need the client ID, but anyone can get one whenever they need it.

I'm also feeling a bit of confusion arising from a conflation of terms
between the regular client/server model and the terminology used in OAuth.
To be clear, in OAuth, the level of trust between the client and authZ
server only really depends on policy; as mentioned, dynamic client
registration can be used if you don't need any trust between the client and
AS.

---

From: ST GERMAIN <[email-masked]>
Date: Thu, 25 Feb 2021 12:30:21 +0000

My apologies, I’m just a near homeless guy who can’t access any funds do to one reason or another who in addition ate pizza from a dumpster just recently. Peace. MSBRA

Get Outlook for iOS<https://aka.ms/o0ukef>
________________________________
From: OAuth <[email-masked]> on behalf of Bron Gondwana <[email-masked]>
Sent: Wednesday, February 24, 2021 3:30:33 PM
To: Justin Richer <[email-masked]>
Cc: Phillip Hallam-Baker <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [OAUTH-WG] We appear to still be litigating OAuth, oops

Bron.

---

From: Evert Pot <[email-masked]>
Date: Thu, 25 Feb 2021 14:49:42 -0500

On 2021-02-25 3:22 a.m., Seán Kelleher wrote:

> publish the same interface for any meaningful implementation in the 
> first place.
>
> It probably makes more sense with email clients, since as Bron said, 
> there is the common standard of POP. If we assume that all the email 
> services that we want to connect to publish the same POP interface, 
> and would accept tokens in the same way, then the way the authZ is 
> handled is indeed the point of divergence that needs to be resolved.

The usefulness of this goes beyond standardized protocols / multiple 
implementors of an API. Some examples of what's possible with Basic 
auth, and not with OAuth2:

 1. I can point my browser to a Basic Auth-protected endpoint. I get a
    pop-up and it will let me log in.
 2. Basic auth is supported in tools like Curl.
 3. It makes generic clients more viable for things like APIs. SDKs for
    specific APIs can be helpful, but HTTP is the universal interface. I
    should be able to use a generic HTTP client and point it to a
    generic HTTP destination and for this to work.
 4. Similarly for the cases where there is a common standard
    server-side, implementors should not have to decide on an
    authentication system. If Auth is baked into the HTTP layer and
    widely supported, POP can be agnostic about how Auth is performed.
    This allows independent upgrading/decoupling of 'POP' and 'Auth'.
    Imagine if we had to update *every client* if a new TLS version is
    released? That's what OAuth2 is like now.

Evert

---

From: Evert Pot <[email-masked]>
Date: Thu, 25 Feb 2021 14:59:47 -0500

On 2021-02-25 3:41 a.m., Seán Kelleher wrote:
>
>     Yep, this is the big point - OAuth is designed to require the the
>     third leg of trust that creates the NxM problem.
>
>
> I believe the snippet of Justin's that you quoted actually shows you 
> how you can forgo the trust element using dynamic client registration. 
> It still allows a "server" to identify requests and impose security 
> policies via the client ID, but without requiring the client author to 
> manually register the client in advance of using it (e.g. in the case 
> where the client author doesn't even know what servers the client is 
> going to be connecting to). You still need the client ID, but anyone 
> can get one whenever they need it.

Apologies if this a dumb question, but how would you discover the 
dynamic client registration endpoint after getting a 401 unauthorized?

I couldn't really find anything in RFC7591 about this.

---

From: Justin Richer <[email-masked]>
Date: Fri, 26 Feb 2021 08:16:16 -0500

> On Feb 25, 2021, at 2:59 PM, Evert Pot <[email-masked]> wrote:
>> I believe the snippet of Justin's that you quoted actually shows you how you can forgo the trust element using dynamic client registration. It still allows a "server" to identify requests and impose security policies via the client ID, but without requiring the client author to manually register the client in advance of using it (e.g. in the case where the client author doesn't even know what servers the client is going to be connecting to). You still need the client ID, but anyone can get one whenever they need it.
> Apologies if this a dumb question, but how would you discover the dynamic client registration endpoint after getting a 401 unauthorized?
> 
We deliberately left that level of discovery out of the registration spec (7591) because, as it turns out, RS-first discovery is a lot harder than it looks on the surface. There are some tricky privacy considerations around divulging an AS to an unknown party, and while not a dead-stop there you’ve got a lot of use cases where it hurts more than it helps.

In the end, we decided not to solve those aspects together and leave discovery for another spec. I think the call made sense at the time. Now, obviously, this assumption goes halfway out the window when you start doing the registration programmatically, and so discovery on a static relationship vs. discovery on a dynamic relationship are pretty different. 

We’re taking a different approach in GNAP, based on work that was done in User Manage Access (UMA):

https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-04.html#name-requesting-resources-with-i <https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-04.html#name-requesting-resources-with-i>

Caveat, there are still a lot of open questions about the details of this, the focus in GNAP has been on the core delegation protocol so far, but it’s on our radar and we welcome the input.

And then there’s the considerations about hooking up more RS’s in real time, or even having the user/client SPECIFY the AS for the RS to talk to. So ultimately it’s an NxMxP problem, with client, AS, and RS in each slot varying differently depending on the API in question. In most OAuth use cases, the AS and RS have a pre-existing relationship that the client doesn’t know or care about. The client’s just trying to “call this API” and so it gets configured with all the bits it needs to ahead of time when it gets registered. But with a common API, like POP or IMAP, the client just needs to know how to get to the next step to keep going. 

This is one thing I’ve found security engineers simply Do Not Get more often than not: client developers don’t care about your security protocol. Your security is what gets in the way of them doing what they want to do, which is use the API and build an awesome thing. The simpler-to-follow we can make the security process, the better it will be for everyone.

 — Justin

---

From: Justin Richer <[email-masked]>
Date: Fri, 26 Feb 2021 11:08:46 -0500

Right, it’s possible to patch OAuth to do this, but the whole “registration equals trust” mindset is baked into OAuth at a really core level. That’s one of the main reasons there’s been hesitance at deploying dynamic registration. It’s an extension that changes your trust model’s assumptions, and does so in a way that is challenging for a lot of large scale providers.

That’s why I personally think it’s really important that we get away from that registration model in GNAP, so we don’t repeat that same problem in the same way. Some people will still deploy GNAP with static registration, but this model becomes more exceptional than baseline. The philosophy of what’s considered an extension vs. default is important.

 — Justin

> On Feb 25, 2021, at 3:41 AM, Seán Kelleher <[email-masked]> wrote:
> 
> I'm also feeling a bit of confusion arising from a conflation of terms between the regular client/server model and the terminology used in OAuth. To be clear, in OAuth, the level of trust between the client and authZ server only really depends on policy; as mentioned, dynamic client registration can be used if you don't need any trust between the client and AS.
> 
> On Thu, 25 Feb 2021 at 08:22, Seán Kelleher <[email-masked] <mailto:[email-masked]>> wrote:
> Just to clarify, I assume in this discourse that the "server" in this client and server relationship refers to an AS/RS pair in OAuth terminology? Based on this, one big sticking point for me on the applicability of NxM, or even 1xM, is that all of the "M" RSs need to publish the same interface for any meaningful implementation in the first place.
> 
> It probably makes more sense with email clients, since as Bron said, there is the common standard of POP. If we assume that all the email services that we want to connect to publish the same POP interface, and would accept tokens in the same way, then the way the authZ is handled is indeed the point of divergence that needs to be resolved.
> 
> However, we're talking about NxM in the general case here. I feel like using the likes of discovery and dynamic registration, etc. that's already supported by OAuth, the "N" part of this equation is surmountable. But each of the "M" servers also need to export the same interface, otherwise a client is going to have to write custom code to deal with talking to the service after the authZ step anyway, reintroducing the "problem" part of the NxM problem.
> 
> As such, I would actually suggest constraining this discussion to just the POP NxM problem rather than NxM in general because, for me at least, the authZ part of the general case is the most "solved" part of the problem, and the outstanding work lies more in consolidating the "M" RS interfaces.
> 
> On Wed, 24 Feb 2021 at 22:32, Bron Gondwana <[email-masked] <mailto:[email-masked]>> wrote:

---

From: Warren Parad <[email-masked]>
Date: Fri, 26 Feb 2021 17:22:19 +0100

A) I don't think it is helpful to talk about what other WGs are doing, or
how GNAP attempts to fix or not fix these problems.
B) Sharing statements like this:

> Right, it’s possible to patch OAuth to do this, but the whole
> “registration equals trust” mindset is baked into OAuth at a really core
> level. That’s one of the main reasons there’s been hesitance at deploying
> dynamic registration

Don't help everyone come to the same conclusion, Who is "we" here, it begs
the question "is there a mindset baked into OAuth", I think to work
effectively we need to be talking about how to best to tackle challenges
everyone and anyone brings up and not fallback on arbitrary statements. It
would be one thing to point to a document which outlines the exact issues
with dynamic registration and then we could potentially have a valuable
conversation about "are those reasons still relevant or do we need to
revisit."

Right now it seems there is "Someone in the past decided this was a bad
idea, so we can't do it", rather than actually having the conversation
about it.

Just based on the conversation, it seems like the obvious right thing to do
is provide dynamic registration in OAuth. Will client developers do the
wrong thing, sure. Might it be challenging to support in a simple way,
maybe. But having the addition to OAuth to solve the problem is better than
nothing, and further it starts to change the mindset that dynamic
registration is and should be provided when appropriate.

Warren Parad

Founder, CTO

On Fri, Feb 26, 2021 at 5:11 PM Justin Richer <[email-masked]> wrote:

> Right, it’s possible to patch OAuth to do this, but the whole
> “registration equals trust” mindset is baked into OAuth at a really core
> level. That’s one of the main reasons there’s been hesitance at deploying
> dynamic registration. It’s an extension that changes your trust model’s
> assumptions, and does so in a way that is challenging for a lot of large
> scale providers.
>
> That’s why I personally think it’s really important that we get away from
> that registration model in GNAP, so we don’t repeat that same problem in
> the same way. Some people will still deploy GNAP with static registration,
> but this model becomes more exceptional than baseline. The philosophy of
> what’s considered an extension vs. default is important.
>
>  — Justin
>
>> services that we want to connect to publish the same POP interface, and
>> would accept tokens in the same way, then the way the authZ is handled is
>> indeed the point of divergence that needs to be resolved.
>>
>> As such, I would actually suggest constraining this discussion to just
>> the POP NxM problem rather than NxM in general because, for me at least,
>> the authZ part of the general case is the most "solved" part of the
>> problem, and the outstanding work lies more in consolidating the "M" RS
>> interfaces.
>>
>>> 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:
>>>
>>> Making it easy to connect up arbitrary clients with per-client tokens
>>> the default, and easy rather than almost impossible to do in practice is
>>> where the big difference comes in.
>>>
>>> Bron.
>>>
>>> --

---

From: Tim Bray <[email-masked]>
Date: Fri, 26 Feb 2021 08:31:55 -0800

> assumptions, and does so in a way that is challenging for a lot of large

Justin is correct but being extremely diplomatic. “There’s been hesitance”,
as he puts it, translates in practice to some lawyer or VP saying “You want
to accept auth assertions for business transactions from unknown parties?
I have no interest in jail time, so forget it.”

---

From: Aaron Parecki <[email-masked]>
Date: Fri, 26 Feb 2021 08:32:51 -0800

Dynamic client registration does exist in OAuth:
https://tools.ietf.org/html/rfc7591

The point is that basically nobody uses it because they don't want to allow
arbitrary client registration at their ASs. That's likely due to a
combination of pre-registration being the default model in OAuth for so
long (the Dynamic Client Registration draft was published several years
after OAuth 2.0), as well as how large corporations have decided to run
their ASs where they want to have (what feels like) more control over the
things talking to their servers.

On Fri, Feb 26, 2021 at 8:22 AM Warren Parad <wparad=
[email-masked]> wrote:

> Just based on the conversation, it seems like the obvious right thing to
> do is provide dynamic registration in OAuth. Will client developers do the
>>>> This is what Fastmail already do with our own app, creating a
>>>> long-lived access token and storing that on the device rather than storing
>>>> the password itself - and you can log out any one client from your security

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 26 Feb 2021 11:40:43 -0500

I spend rather too much time doing disinformation analysis these days. But
one of the issues that keeps coming up is what Sartre called a 'bad faith'
argument which is an unfortunate term in that people end up doing it
without being aware of it, no malice involved.

What Sartre was describing was an argument in which there are two separate
frames of reference used. The first frame is used to establish that X
applies, then once that is achieved the first frame is discarded and X is
interpreted in the second frame.

To take an example:

Frame 1: Tony Blair implemented many polices that are described in a paper
by Milton Friedman when the latter was shilling for a position in the
Democratic administration of Harry Truman: Blair is a 'neoliberal'.

Frame 2: Neoliberal Milton Friedman shilled for and was successful in
getting a consulting role in the Pinochet regime. Therefore neoliberals
support Pinochet. Therefore Blair supports Pinochet. Therefore Blair
supports the mass murder of 30,000 people.

I am seeing similar in the OAUTH discussion:

Frame 1: X must use OAUTH it is simple!

Frame 2: You have to understand how to apply OAUTH correctly. The
Turbo-encabulator mode is very powerful let me stroke my beard while you
come to that understanding.

And yes, folk are going to get upset about having their arguments presented
in this fashion but I really don't know how else to get through to them the
reasons why the people on the receiving end of those arguments are getting
upset.

There is a real problem in trying to get across unwelcome information. The
ground problem for many of us with OAUTH is that we simply cannot
understand it. And we rather suspect the problem isn't on our side. I have
come to find that not being able to understand things that exceed a certain
complexity is actually a profound advantage in architecture. The real value
of formal methods turns out to be they force people to reduce the problem
to something simple enough to write proofs about.

This is one of the reasons I would like to see the IETF move towards a W3C
style plenary in which WGs are required to provide short introductions to
what they do. No, not status reports: an elevator pitch. Because if nobody
in the group can describe what is going on with clarity, well perhaps they
don't know themselves.

it is really difficult to know what to do in these circumstances. I tell
people my criteria for adopting a technology early on. If they meet my
criteria, I will attempt to make use of their work product. But I feel
absolutely no obligation to do so if they don't.

---

From: Christian Huitema <[email-masked]>
Date: Fri, 26 Feb 2021 12:11:27 -0800

On 2/26/2021 8:31 AM, Tim Bray wrote:

> On Fri, Feb 26, 2021 at 8:10 AM Justin Richer <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     “registration equals trust” mindset is baked into OAuth at a
>     really core level. That’s one of the main reasons there’s been
>     hesitance at deploying dynamic registration. It’s an extension
>     that changes your trust model’s assumptions, and does so in a way
>     that is challenging for a lot of large scale providers.
>
>
> Justin is correct but being extremely diplomatic. “There’s been 
> hesitance”, as he puts it, translates in practice to some lawyer or VP 
> saying “You want to accept auth assertions for business transactions 
> from unknown parties?  I have no interest in jail time, so forget it.”

Tim's point is very important. It shows a tension between "blindly 
accepting authentication claims from unknown parties", which would 
indeed lead to adversarial business consequences, and "only accepting 
authentication claims from parties that have been marked as trusted by 
my organization", which in theory looks safe but in practice drives 
concentration. If the trust decision is delegated to each site, we have 
the recipe for a network effect, in which only a very small set of big 
organizations can provide authentication for everybody, and collect the 
corresponding data and statistics.

This is both a very hard problem and an urgent problem. An IETF working 
group works on a hard issue and produces an incomplete solution. Big 
companies can fill the gaps by providing their own value. The result is 
further concentration of the Internet.

Such problems are very hard, but they are not impossible to solve. Look 
for example at PKI and its supporting infrastructure like the CAB Forum. 
It is not perfect, but at least it had the property of allowing web 
sites to use HTTPS without routing all authentication transactions 
through third parties. Wouldn't it be nice if we had a federation system 
on top of OAUTH? I suppose that is difficult. Not a reason to not try...

-- Christian Huitema

---

From: David Waite <[email-masked]>
Date: Fri, 26 Feb 2021 14:36:02 -0700

> On Feb 26, 2021, at 9:32 AM, Aaron Parecki <[email-masked]> wrote:

> The point is that basically nobody uses it because they don't want to allow arbitrary client registration at their ASs. That's likely due to a combination of pre-registration being the default model in OAuth for so long (the Dynamic Client Registration draft was published several years after OAuth 2.0), as well as how large corporations have decided to run their ASs where they want to have (what feels like) more control over the things talking to their servers.

Do you disagree that this gives them control over which things talk to their servers?

FWIW my personal mental model here is pretty simple:

With users, there are services you provide anonymously and services you provide only to registered/authenticated/trusted parties for various reasons. Once you are delegating user access, you still have many of the same reasons to provide access to anonymous or registered/authenticated/trusted delegates.

Dynamic registration arriving later and requiring additional complexity has unfortunately encouraged registration in use cases where anonymous clients might have been acceptable, but shifting the timelines or complexity balance would not  have changed business needs for authentication and trust of delegates. Omitting registration would have caused businesses to use other protocols that met their needs.

If AS’s are only getting what feels like proper control for their business needs, we should attempt to give them the actual control they require.

-DW

---

From: Aaron Parecki <[email-masked]>
Date: Fri, 26 Feb 2021 13:49:30 -0800

> Do you disagree that this gives them control over which things talk to
their servers?

Yes -- with a public client, I can impersonate a "real" app and it's
basically non-detectable by the AS. For a theoretical example, if I wanted
to use the Instagram API but they restrict which apps can upload photos to
only their own mobile apps, I can find the client ID of their own app, then
do an OAuth flow using their own client ID, and without a client secret it
looks the same as their own client. I'm unlikely to be able to get
arbitrary users to authorize my app because of limits and checks on the
redirect URI, but I can certainly do it myself for my own account. This is
the sort of false sense of security provided by the client registration
step I'm talking about.

I'd love to solve the app identity problem too, but that's only possible
with cooperation from the mobile OSs.

Aaron

On Fri, Feb 26, 2021 at 1:36 PM David Waite <[email-masked]>
wrote:

> > The point is that basically nobody uses it because they don't want to
> allow arbitrary client registration at their ASs. That's likely due to a
> With users, there are services you provide anonymously and services you
> provide only to registered/authenticated/trusted parties for various
> reasons. Once you are delegating user access, you still have many of the
> same reasons to provide access to anonymous or
> registered/authenticated/trusted delegates.
>
> Dynamic registration arriving later and requiring additional complexity
> has unfortunately encouraged registration in use cases where anonymous
> clients might have been acceptable, but shifting the timelines or
> complexity balance would not  have changed business needs for
> authentication and trust of delegates. Omitting registration would have
> caused businesses to use other protocols that met their needs.
>
> If AS’s are only getting what feels like proper control for their business
> needs, we should attempt to give them the actual control they require.
>
> -DW

---

From: Jeff Craig <[email-masked]>
Date: Fri, 26 Feb 2021 15:58:58 -0600

> the sort of false sense of security provided by the client registration

The fact that you're unlikely to be able to get arbitrary users authorized
as the client is precisely the attack vector that registration is meant to
avoid. The fact that any reasonably sophisticated AS is going to use
additional signals (Referer headers, etc) to limit the scope of the Public
Client to make hijacking harder, which is only possible with registration,
is another line of defense. OAuth doesn't need to protect *your* data from
you, it needs to protect other people's data from you, and registration
offers more opportunities to collect signals that can be used to protect
users.

None of it's perfect, and I agree that there are problems in the
app-identification space that need some additional work, but the
registration friction does serve a purpose in a lot of cases.

>> If AS’s are only getting what feels like proper control for their
>> business needs, we should attempt to give them the actual control they
>> require.
>>
>> -DW
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 27 Feb 2021 11:15:51 -0500

On Fri, Feb 26, 2021 at 11:32 AM Tim Bray <[email-masked]> wrote:

> saying “You want to accept auth assertions for business transactions from
> unknown parties?  I have no interest in jail time, so forget it.”
>

Getting back to the general case rather than litigating one particular
protocol. I have on many occasions found that the response to raising an
issue in the IETF is to be told that the solution is I should go and
'educate them' to understand that their concern doesn't matter.

---

From: "Bron Gondwana" <[email-masked]>
Date: Mon, 01 Mar 2021 15:35:23 +1100

> As such, I would actually suggest constraining this discussion to just the POP NxM problem rather than NxM in general because, for me at least, the authZ part of the general case is the most "solve…

Sorry for the delay in responding - real life got in they way of this general discussion.

Yes, the common standard of POP - or indeed any common standard.  A fine example of common standards is the move towards many devices being charged by USB-C these days.  Previously, there was this:

https://en.wikipedia.org/wiki/Common_external_power_supply

Why?  So you that you don't need a new charger for each new device.

The whole point of being a standards org is to try to guide each "M" towards exporting the same interface when providing the same (or similar enough) underlying service, so that the network effects of interoperability are realised.

So yes, constrain to POP (and IMAP, and SMTP submission, and file storage, and calendars, and ... everything where there's enough similarity that clients should be able to portably interoperate with multiple services).

Right now the problem with POP/IMAP/etc is that the interoperable authentication choice is "username+password".  There's nothing better than that because there's no Micro-USB-like thing that has sufficient technical and political clout behind it that everyone implements it.

Bron.