I am absolutely not trying to convince anyone that I have done anything new or done anything more than see an emerging trope and see the opportunity it presents.
It is likely that one of the reasons earlier schemes failed is that we presented a large number of different approaches to the end-user at the same time and they just got confused by what was being offered. This time it is different because there is already a parade that has gained 20 million people in the space of ten weeks. That means that we have one approach that has been picked for us. All we have to do is acknowledge the situation, pick up the ball and carry it to where we want to go. Most of the standards work is already done for OAUTH. The one part where ATprotocol is not fully aligned is in the resolution of a DNS Handle to an authentication provider. They introduce a DID which contains a Direct Trust Fingerprint which has definite advantages, it allowed me to change my handle from @hallam.blsky.social to @phill.hallambaker.com. BUT that goes through this PLC mechanism that introduces a centralization point and I want to eliminate that for a start. If it wasn't obvious, I am not an OAuth expert, I have been on the sidelines but I only implemented the protocol a few weeks ago and I am not familiar with it as an insider. I can see immense value in what BlueSky have done but they are only solving their problems for themselves, I am looking at DNS handles as a much broader instrument that allows me to address multiple security and protocol concerns. I am making proposals related to DNS handles here and in SETTLE. I also have this large cryptographic infrastructure that supports a personal PKI that I am planning to combine with DNS handles to achieve end-to-end secure communication across messaging, mail and filedrop and I want to pitch the MOQ folk on getting onboard with using DNS handles to allow person to person voice and video communication via MOQ. So don't be upset if you think all the work is done because even if OAUTH is clearly 95% ready, that is only one part of the broader picture. On Tue, Jan 21, 2025 at 5:47 PM Dick Hardt <dick.ha...@gmail.com> wrote: > I’m not saying it won’t happen — I’m saying a standard is unlikely what is > holding it back. > > On Tue, Jan 21, 2025 at 10:33 PM Phillip Hallam-Baker < > ph...@hallambaker.com> wrote: > >> Exactly the same happened with social media in general. We had >> interactive forums and blogs in 1994. Users couldn't quite work out what >> they were about. >> >> Ten years later, Facebook launched with a set of what were well worn >> features by then and took off. >> >> Timing matters a great deal. At the same time OpenID launched, a friend >> was trying to get a password management service off the ground. It crashed >> and burned; the users simply hadn't got to a sufficient level of pain yet. >> Today there are a dozen successful providers in that space. >> >> Another point to consider is that there is a very large government entity >> that is very upset about the 'centralization' of the Web. A government >> entity that is more than willing to pick fights with BigTech and the means >> to enforce its legal decisions. This would be a very opportune moment for >> certain companies to consider whether they would like to modify their >> technical approach, so they are not unnecessarily inserting themselves into >> unrelated business transactions or if they wish to press ahead and become >> that which is between the irresistible force and the immovable object. >> >> >> >> >> On Tue, Jan 21, 2025 at 4:45 PM Dick Hardt <dick.ha...@gmail.com> wrote: >> >>> Sounds alot like what OpenID was (not OpenID Connect) >>> >>> The user entered an identifier into the box and then was logged in. This >>> was when blogging was taking off, and we all thought people had some >>> identifier on the internet they would enter. Many of those were just a >>> domain name. >>> >>> According to Built With, OpenID[1] had more adoption in the top 1M sites >>> (42k) than Google Identity Platform[2] does today (35k). >>> >>> If you look at the OpenID graph, you see it spikes up, and then drops >>> off rapidly. Consensus was that people did not know what to do. >>> >>> Perhaps the world is different now -- but I don't think so. It was not a >>> lack of standards back then, and a standard is unlikely to change anything >>> now. >>> >>> /Dick >>> >>> >>> >>> [1] https://trends.builtwith.com/docinfo/OpenID >>> [2] https://trends.builtwith.com/widgets/Google-Identity-Platform >>> >>> On Tue, Jan 21, 2025 at 9:03 PM Phillip Hallam-Baker < >>> ph...@hallambaker.com> wrote: >>> >>>> The differences in the new approach as I see it are >>>> >>>> 1) The user identifier is '@' followed by their DNS address and that is >>>> the ONLY syntax used to present that identifier. No URIs, URLs, QR codes, >>>> etc. the only thing a user is required to remember and type in at a site >>>> where they want to claim their identity is their DNS handle. >>>> >>>> I am experimenting with calling the system @nywhere because this means >>>> I can prompt the user with the @ sign as the field label with 'nywhere' as >>>> text replaced as soon as they start to type. Which I think provides a >>>> really nice contextual grounding for the user. I am willing to change this >>>> but not to use https// or similar. URLs were never intended to be user >>>> facing labels. >>>> >>>> 2) The user can change their handle and preserve their account. In the >>>> ATprotocol scheme, the DNS handle is resolved to a DID which is a >>>> fingerprint of a public key that can be used as a root of trust for making >>>> claims related to the handle. >>>> >>>> Now, I have reservations about this part of the BlueSky spec and the >>>> fact that it is bound to a public key doesn't really mean anything unless >>>> the private key is held by the end user. It is a part of the spec that I >>>> want to align with end-to-end secure communications tech that put the >>>> private key under user control. But in the meantime, it DOES provide the >>>> ability to change handles and that is really important as it allows users >>>> to move from an 'at-will' handle controlled by another to a personal >>>> registration. >>>> >>>> 3) The entire system is loosely coupled. Relying sites are not required >>>> to establish any prior relationship with the authentication provider. This >>>> is obviously something a lot of folk are going to object to but the only >>>> way that an authentication system can become ubiquitous is if it is >>>> permissionless. >>>> >>>> I talked to folk about connecting my Internet Drafts comment forum up >>>> to the IETF datatracker and was told this was likely to require contracts >>>> and agreements and such. The emerging infrastructure allows me to >>>> authenticate the user regardless of who is providing their authentication >>>> without needing any prior agreement, app key or anything. >>>> >>>> >>>> >>>> >>>> On Tue, Jan 21, 2025 at 3:13 PM Warren Parad <wpa...@rhosys.ch> wrote: >>>> >>>>> I'm not really following. Maybe let's start at the end and work >>>>> ourselves backwards. As an Identity Provider today, we generate JWTs for >>>>> our users that applications can use. Users log in to applications via our >>>>> Authorization Server and get application specific JWTs. Based on your >>>>> suggestion how does the result JWT different from the one that we are >>>>> generating for the user+application today? >>>>> >>>>> On Tue, Jan 21, 2025 at 9:02 PM Phillip Hallam-Baker < >>>>> ph...@hallambaker.com> wrote: >>>>> >>>>>> On Tue, Jan 21, 2025 at 2:43 PM Warren Parad <wpa...@rhosys.ch> >>>>>> wrote: >>>>>> >>>>>>> The only thing lacking is a base of authentication service providers >>>>>>>> that are willing to give users control. >>>>>>> >>>>>>> >>>>>>> As someone who works for one of those "authentication service >>>>>>> providers", what exactly would we need to support that we don't already? >>>>>>> >>>>>> >>>>>> I am writing a draft. The short answer is almost nothing. But not >>>>>> nothing. >>>>>> >>>>>> The longer answer is that we need to have: >>>>>> >>>>>> 1) A detailed explanation that puts ALL the information needed to >>>>>> implement against the profile in one place. I am working on an Internet >>>>>> draft to do exactly that. >>>>>> >>>>>> 2) A discussion of how to best present the scheme as something whose >>>>>> primary purpose is as an authentication provider rather than an account >>>>>> with one social media property that can also be used elsewhere. >>>>>> >>>>>> 3) A discussion of how to use the DNS handles to enable end-to-end >>>>>> secure messaging. If Bob is reading a comment by Alice under @ >>>>>> alice.example.com, that is the handle he is likely to want to use to >>>>>> message her. >>>>>> >>>>>> 4) A discussion about what else we might want a DNS handle provider >>>>>> to support. I have a prototype running that extends to supporting the IoT >>>>>> requirements raised in SETTLE. >>>>>> >>>>>> Right now, we have 'a' way to do this which is not necessarily the >>>>>> best way or the way that allows us to grow in all the ways we might want >>>>>> in >>>>>> the future. >>>>>> >>>>>> I have a history of being able to market protocols and get them into >>>>>> widespread use. I haven't always been successful but have more successes >>>>>> than failures and I think I know what it takes to make DNS Handles widely >>>>>> used, which businesses I need to approach, etc. etc. >>>>>> >>>>>> The reason I am raising this here now, is that before I go round to >>>>>> the DNS registrars (and their affiliates) and the VPN providers and such >>>>>> to >>>>>> say this is the thing to do, I want to make sure we have everything >>>>>> straight at a technical level so we are all on the same page. >>>>>> >>>>>> >>>>>>
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
