FWIW, I do agree that it is unlikely that a standard (any standard) will change anything, but I do think that the rise of bluesky/mastodon in conjunction with the browser being more involved (as Aaron pointed out, this specifically https://github.com/w3c-fedid/idp-registration/issues/2 but this too https://github.com/w3c-fedid/idp-registration/issues/15) adds at least a couple missing parts that weren't available a few years ago when it was last tried, and may be enough to make this viable.
I'm @sgo.to and really feel represented by my domain name on the web, and I hope this pattern gets further developed. On Tue, Jan 21, 2025, 2:49 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 >
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
