On Fri, May 10, 2024 at 2:41 AM Neil Madden <neil.e.mad...@gmail.com> wrote:
> 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. > Neil, just checking, but is it clear to you that the UA doesn't make an imposition on what's passed back to the RP (e.g. ID tokens vs access tokens)? An IdP can return whatever it wants back to RP in the id assertion endpoint <https://fedidcg.github.io/FedCM/#idp-api-id-assertion-endpoint> as a string <https://fedidcg.github.io/FedCM/#dom-identitycredential-token> (e.g. a Base64 encoded JWT, an access token, a binary blob, a JPEG image, an mp3 file, etc), which doesn't get introspected by the UA. The only data that does get instrospected by the UA is the result of the accounts endpoint <https://fedidcg.github.io/FedCM/#idp-api-accounts-endpoint>, which is used to construct an account chooser. I was assuming we were having a discussion around the accounts endpoint, not the id assertion endpoint. > > 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. > > Yeah, I'm in agreement with that. I think the "MUST use email" emphasis on Neil's original point is the key one to me: I am convinced that it MUST NOT, i.e. FedCM must be able to operate in the absence of email addresses. > 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
