I think you are still describing exactly what OAuth does, also FedCM helps a lot there, and I hate to say it but if this is the argument:
Users are far less likely to remember a password for a site they visited > last 24 months ago than the password for their DNS handle they use > everywhere. There are many accounts I end up doing password recovery on > every single day. Right no, I can't open the garage door from my app > because the clueless dweebs wrote it decided to forget my password because > of some security superstition they acquired somewhere. Same goes for this: > A big attraction for this approach for me as someone starting a social > media site is that I don't need to muck about with accounts *AT ALL*. Not > my problem if the user forgets their password, I don't need their email for > recovery either. All the customer support overhead is taken off my site. Users will still forget their password, and now are less likely to be able to recover it due to the fact you can't help them. I'm not against the idea, but this argument doesn't provide any points in favor of it. Realistically, no amount of standard is going to fix people doing the wrong thing here. They already have the tools to do the right thing, arguably the problem isn't lack of standards it is lack of examples applying that standard in their use case. So I'm not sure how much anyone here can help them, more than we are already doing (A fair number of the WG give quite in-depth conference talks to as many people as possible to raise awareness). Is this just about routing VPN traffic? What does user identity have to do with VPN traffic routing, I'm not making the connection here. If we assume some magic standard existed and said exactly the right thing, I'm not sure what would make your VPN provider help provide authentication here. That is, why would the business that provides the VPN also decide to provide Authentication and user identities. OR said differently, a standard is not going to cause a business to do the right thing. It will only assist them in doing the thing they always wanted to do. From your hypothetical, I would see the value if we already saw VPN providers attempting to do this poorly, is that what we are seeing? VPN providers who are also providing auth, and are using OAuth but somehow are getting it wrong? (I'm genuinely curious here, I don't know very much about VPN providers). Which is why I think it makes sense to talk about concrete existing scenarios that are being built today, and either: - Are being built so well we want to standardize their approach - Are being built so poorly we want to create a standard so they have something to help them do it less wrong I'm getting a sense that this falls into a third category: - Wouldn't it be nice if the world worked differently, but no one has any incentive to make it happen I'm happy to be wrong, but I'm not seeing it yet. On Tue, Jan 21, 2025 at 8:05 PM Phillip Hallam-Baker <ph...@hallambaker.com> wrote: > On Tue, Jan 21, 2025 at 1:31 PM Dick Hardt <dick.ha...@gmail.com> wrote: > >> From a privacy perspective, using a correlatable identifier across all >> sites simplifies tracking to the detriment of the user's privacy. >> >> The other concern with this approach is control of the identifier is >> control of your identity. How does my mom get back control? >> >> We have similar issues with email, which is by default how people login >> to most sites and do an email loop to prove control of their identifier if >> they (or the attacker) does not have the password. >> > > I had similar concerns at first. Then I started to think 'what if a lot of > our problems are due to the lack of clarity in what an identifier is doing > for us'. > > There are so many ways of linking users in the current setup that the > handle isn't really much of a worry. Facebook has figured out some of the > accounts I use for telemetry analysis belong to me. Likely because I log in > from the same IP address. If we are going to worry about unlinkability, we > have to take that as our goal and provide a complete solution. > > > So let's imagine I care about privacy and unlinkability and my > authentication provider is also my VPN provider. With the right browser > support, I can tell the Web client, 'start private browsing for golf.com' > and it goes and tells my authentication provider to spin up a separate > handle for me to use, just for that site. And it can direct the traffic > through a different VPN exit. > > A big attraction for this approach for me as someone starting a social > media site is that I don't need to muck about with accounts *AT ALL*. Not > my problem if the user forgets their password, I don't need their email for > recovery either. All the customer support overhead is taken off my site. > > Users are far less likely to remember a password for a site they visited > last 24 months ago than the password for their DNS handle they use > everywhere. There are many accounts I end up doing password recovery on > every single day. Right no, I can't open the garage door from my app > because the clueless dweebs wrote it decided to forget my password because > of some security superstition they acquired somewhere. > > > > _______________________________________________ > 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
