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

[Warren Parad <[e-mail]>]

👏

Warren Parad

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


On Wed, Feb 24, 2021 at 10:09 AM Hannes Tschofenig <
[e-mail]> 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 <[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.
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>