đź‘Ź 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 < [email protected]> 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 <[email protected]> *On Behalf Of * Phillip Hallam-Baker > *Sent:* Wednesday, February 24, 2021 6:47 AM > *To:* Kathleen Moriarty <[email protected]> > *Cc:* [email protected]; [email protected] > *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 > [email protected] > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
