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

[Hannes Tschofenig <[e-mail]>]

Hi Phil,

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

See my feedback below.

From: ietf <[e-mail]> On Behalf Of Phillip Hallam-Baker
Sent: Wednesday, February 24, 2021 6:47 AM
To: Kathleen Moriarty <[e-mail]>
Cc: [e-mail]; [e-mail]
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 because they are not even customers, they are the product.

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


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

[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

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.