I can tell you I definitely read it. I actually read it multiple times. But I don't know what to tell you. The problem you've identified exists, but that doesn't necessarily mean it is a problem. In a way it is a bit like, You create a bank account at a bank and you give them all your money. They then decide to never give it back.
While banks are regulated in most countries and things like GitHub are not, in essence this interaction is based on trust. Of course solutions like WebAuthn via FIDO2 used as a first party authentication can solve this, and arguably this is the remit of the entire web3.0 domain. I don't think anyone would suggest this isn't a problem, just that it isn't that big of a problem. I think realistically, in order for this problem to have a closed form solution, it would need to start with a suggestion on how to solve it, rather than a bunch of us agreeing that it is. Because right now there doesn't seem to be any fundamental solution available for this. And honestly, the bigger problem is the digital assets at risk at the third parties is not due to impersonation, but just general negligence. GitHub isn't trying to malicious log into my StackOverflow account, and Google isn't trying to log into my bank. That's because these organizations have supposedly bound themselves to not grant this ability to their internal engineers to abuse. And they are spending tons of resources attempting to stop external attackers. That being said, it's hard to know if this problem hasn't already transgressed in the wild. While it is certainly possible, it seems internal users are more likely to act maliciously on behalf of the user via their owned data in their own company, rather than attempt to impersonate their users at third party sites. - Warren On Wed, Aug 9, 2023 at 10:06 PM mfulz <mf...@olznet.de> wrote: > Anyone read this topic or could tell if there is a better place to adress > this? > > Sent from Nine <http://www.9folders.com/> > ------------------------------ > *Von:* mfulz > *Gesendet:* Sonntag, 16. Juli 2023 03:38 > *An:* oauth@ietf.org > *Betreff:* [OAUTH-WG] OAuth Trust model > > > > Hi Together, > > I was thinking about some (at least I see it in that way) problem in the > whole oauth/openid design: > > The problem is the following: > > The user has no control about what providers are accepted by the clients > (websites, etc.) and this opens access to these providers without any way > to protect against that. > > Example: > > I've created an account with email/password login at stackoverflow > > I've created an account with the same email at github > > -> logged out from stackoverflow > > -> logged in via github oauth -> working and connected to the email/pw > account from stackoverflow > > > Stackoverflow has the possibility to remove the github login now, but the > main problem is, that I would be out of control, that some of these oauth > providers > > (please don't go into the discussion WHY they or anyone should do it) > could access my accounts, when such site would allow them as provider. > > > In my opionion it would be good to avoid such issues, by including > something in the standard, that the user MUST allow the connection on both > sides on the client > > and on the provider. > > > Yes for sso without any existing account that's some kind of an issue, but > still it could be added some verification process like sending confirmation > link > > That the user is accepting the oauth provider on the Client side. > > Then the oauth provider would also need access to my emails to access my > account. > > > Not sure if I'm wrong here but I think my description is correct. > > > BR, > > Matthias > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
