FWIW We simplified to just a URL in OpenID 2
People just did not know what to do and were confused. Conversion dropped at RPs so they took it out. I agree that the browser work may change the dynamics if: - the user can opt in at their provider to have the functionality - the functionality is only displayed to the user at the app web page if the user has functionality and has opted in - the user understands the functionality when displayed and only has to click a button to start login - the user can have a choice of which one to select This solves the earlier problems of: - the user being confused at the web app about what to do, and - the user having to know what value to enter - the user having choice Unfortunately the browser work so far has been focused presenting an experience that mimics the Google Experience, which does not map to other providers My other concern is this lowering the security of the web as account protection is hard and my Mastodon server is not up to the task While people are rightfully concerned about the control of the large platforms, the account protection offered is unequaled anywhere else On Wed, Jan 22, 2025 at 5:20 AM Sam Goto <g...@google.com> wrote: > 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
