On 9 May 2024, at 21:58, Watson Ladd <watsonbl...@gmail.com> wrote: > > On Thu, May 9, 2024 at 7:24 AM Neil Madden <neil.e.mad...@gmail.com> wrote: >> >> On 9 May 2024, at 00:06, Sam Goto <g...@google.com> wrote: >> >> [...] >>> >>> >>> I guess, flipping this around, we might ask what is the legitimate purpose >>> for which browsers need to access the user’s name, email address (both >>> requires) and other identifying information? I’d have thought an identifier >>> (possibly randomised) and some user-supplied account nickname would be >>> sufficient. >> >> >> That's easier to answer: the browser needs name/email/picture to construct >> an account chooser, which is the UX that tested best with users by a far >> margin. >> >> Static/unpersonalized permission prompts - example in Safari, example in >> Chrome - perform extremely poorly (in comparison to account choosers), >> although have other benefits too (namely ergonomics and extensibility), so >> Chrome (and others) expose that too in the form of the Storage Access API. >> >> >> >> Yeah, that's what I suspected. Did you do research that specifically called >> out email addresses as a must-have? > > I'm sort of mystified here by the objection. > > What exactly is the alternative where the user agent doesn't have > access to all of the data passing through it?
With auth code flow the data doesn't pass through the user agent at all. With encrypted ID tokens it does, but is not accessible to the UA. > In particular user > emails are everywhere in the User Agent. It's in the autofill > settings, the webmail interface, every signup form filled out etc, > etc. Many OAuth flows are not OIDC. There's no guarantee that the AS even has access to any identity information beyond a username. > > To be absolutely clear today the information generally appears in big > bold text to confirm the user wants to pass it to the RP, and those > letters are made to appear on screen through a process the User Agent > is very involved in. It also got typed in by the user (or autofilled > by the user agent) when signing into the IdPs. Usually there are UI > ways to confirm what account you are signed into that depend on > similar APIs. And everything the user does is done through the User > Agent. Is there some exotic setup that I'm ignoring here? > > I'm just very confused as to why this is a problem. There's a lot of background assumptions there -- do we want to bake those into the web for all eternity? Yes, email addresses are passed around like candy on the web currently, but I don't think that is a good thing. As for how this could be an issue, imagine you are giving a presentation/demo at work and you go to login to a website (not uncommon) and up pops a box asking if you want to login with your xyz.example account (pornhub, grindr, whatever) -- revealing some sensitive or embarassing information about you, such as your sexual orientation. The idea that it is a perfectly neutral and acceptable thing for the browser to make background requests *prior to* consent that pull in personal info from all kinds of sources is deeply suspect IMO. -- Neil _______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
