If someone uses the auth code flow, how would the account chooser display anything?
On Fri, May 10, 2024, 18:53 Neil Madden <neil.e.mad...@gmail.com> wrote: > > > On 10 May 2024, at 17:07, Sam Goto <g...@google.com> wrote: > > 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. > > > Yes, that's correct. The accounts endpoint mandates that the IDP expose > PII to the UA that otherwise needn't be. If you use the auth code flow, > other than what the user provides to authenticate (under their control), no > identity information at all is exposed to the user agent. > > (I appreciate such PII _often_ will be exposed by the IDP UI anyway, but > it is a significant change to make it mandatory). > > >> > 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. > > > Great. > > > >> 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 >
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
