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
