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

[Warren Parad]



Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress .


On Wed, Feb 24, 2021 at 10:09 AM Hannes Tschofenig <
hannes.tschofe...@arm.com> wrote:

> Hi Phil,
>
>
>
> I am moving this to the OAuth group to avoid confusing the IETF list any
> further.
>
>
>
> See my feedback below.
>
>
>
> *From:* ietf  *On Behalf Of * Phillip Hallam-Baker
> *Sent:* Wednesday, February 24, 2021 6:47 AM
> *To:* Kathleen Moriarty 
> *Cc:* i...@ietf.org; oauth@ietf.org
> *Subject:* Re: Diversity and Inclusiveness in the IETF
>
>
>
> 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.
>
>
>
> [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.
>
>
>
> 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.
>
>
>
> [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.
>
>
>
> The Internet is for everyone. The Internet is for end users.
>
>
>
> [Hannes] Those are great words but they mean nothing in this context. You
> know that.
>
>
>
>
>
> I am really not that interested in who makes the ingredients except 

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

[Hannes Tschofenig]

Hi Phil,

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

See my feedback below.

From: ietf  On Behalf Of Phillip Hallam-Baker
Sent: Wednesday, February 24, 2021 6:47 AM
To: Kathleen Moriarty 
Cc: i...@ietf.org; oauth@ietf.org
Subject: Re: Diversity and Inclusiveness in the IETF

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.

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

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.

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

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

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


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 

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

[Jim Manico]

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  
> wrote:
> 
> 
> 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'.
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Larry Masinter]

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

 

 

From: ietf  On Behalf Of Phillip Hallam-Baker
Sent: Tuesday, February 23, 2021 9:47 PM
To: Kathleen Moriarty 
Cc: i...@ietf.org; oauth@ietf.org
Subject: Re: Diversity and Inclusiveness in the IETF

 

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

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Phillip Hallam-Baker]

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

>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Eric Rescorla]

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

>
> On Tue, Feb 23, 2021 at 4:57 PM Mark Nottingham  wrote:
>
>>
>>
>> > On 24 Feb 2021, at 2:20 am, Kathleen Moriarty <
>> kathleen.moriarty.i...@gmail.com> 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;
>
>
> 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,
>>
>>
>> --
>> Mark Nottingham   https://www.mnot.net/
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Rifaat Shekh-Yusef]

On Tue, Feb 23, 2021 at 4:57 PM Mark Nottingham  wrote:

>
>
> > On 24 Feb 2021, at 2:20 am, Kathleen Moriarty <
> kathleen.moriarty.i...@gmail.com> 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;


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,
>
>
> --
> Mark Nottingham   https://www.mnot.net/
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Mark Nottingham]

> On 24 Feb 2021, at 2:20 am, Kathleen Moriarty 
>  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/

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Kathleen Moriarty]

On Tue, Feb 23, 2021 at 9:30 AM Roman Danyliw  wrote:

> Hi!
>
>
>
> *From:* ietf  *On Behalf Of * Bron Gondwana
> *Sent:* Tuesday, February 23, 2021 7:47 AM
> *To:* Rifaat Shekh-Yusef 
> *Cc:* i...@ietf.org; oauth@ietf.org
> *Subject:* Re: Diversity and Inclusiveness in the IETF
>
>
>
> 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.
>
>
>
> [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


>
> Regards,
>
> Roman
>
>
>


-- 

Best regards,
Kathleen
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Roman Danyliw]

Hi!

From: ietf  On Behalf Of Bron Gondwana
Sent: Tuesday, February 23, 2021 7:47 AM
To: Rifaat Shekh-Yusef 
Cc: i...@ietf.org; oauth@ietf.org
Subject: Re: Diversity and Inclusiveness in the IETF

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.

[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

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Hannes Tschofenig]

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 
Sent: Tuesday, February 23, 2021 12:51 PM
To: Hannes Tschofenig ; i...@ietf.org
Cc: oauth@ietf.org
Subject: Re: Diversity and Inclusiveness in the IETF

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:  
Fecking OAUTH as they say.  I came out of this saying "they can't even agree 
about what they don't agree on".   says it was even worse in the 
past.  What a fustercluck.  Don't expect anything workwhile out of this group 
unfortunately.   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.

On Tue, Feb 23, 2021, at 22:00, Hannes Tschofenig wrote:

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 

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

[Bron Gondwana]

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.

--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  br...@fastmailteam.com

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Rifaat Shekh-Yusef]

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 
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:
>
> *Thursday 19th: (Aug 2018)*
>
> *9:30am* OAUTH
> :
> Fecking OAUTH as they say.  I came out of this saying "they can't even
> agree about what they don't agree on".   says it was even
> worse in the past.  What a fustercluck.  Don't expect anything workwhile
> out of this group unfortunately.   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.
>
> On Tue, Feb 23, 2021, at 22:00, Hannes Tschofenig wrote:
>
> 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  *On Behalf Of * Bron Gondwana
> *Sent:* Tuesday, February 23, 2021 5:20 AM
> *To:* i...@ietf.org
> *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 

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

[Bron Gondwana]

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 
> :  
> Fecking OAUTH as they say.  I came out of this saying "they can't even agree 
> about what they don't agree on".   says it was even worse in 
> the past.  What a fustercluck.  Don't expect anything workwhile out of this 
> group unfortunately.   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.

On Tue, Feb 23, 2021, at 22:00, Hannes Tschofenig wrote:
> 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  *On Behalf Of * Bron Gondwana
> *Sent:* Tuesday, February 23, 2021 5:20 AM
> *To:* i...@ietf.org
> *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 

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

[Hannes Tschofenig]

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  On Behalf Of Bron Gondwana
Sent: Tuesday, February 23, 2021 5:20 AM
To: i...@ietf.org
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: fg...@si6networks.com
PGP Fingerprint:  31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492






--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  br...@fastmailteam.com


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.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth