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
