On Mon, May 13, 2024 at 12:49 PM Sam Goto <g...@google.com> wrote: > > > On Sat, May 11, 2024 at 3:22 PM Dick Hardt <dick.ha...@gmail.com> wrote: > >> >> >> On Wed, May 8, 2024 at 4:07 PM Sam Goto <goto=40google....@dmarc.ietf.org> >> wrote: >> >>> That's easier to answer: the browser needs name/email/picture to >>> construct an account chooser >>> <https://docs.google.com/presentation/d/1iURrPakaHgBfQ6mAefKijjxToiTTgBSPz1rtaV0od98/edit#slide=id.p>, >>> which is the UX that tested best with users by a far margin. >>> >> >> >> I bring up again the issue I filed >> https://github.com/fedidcg/FedCM/issues/242 >> > > Yeah, that's a known issue. We actively are working on a subset of this > problem here: > > https://github.com/fedidcg/FedCM/issues/559 >
I brought this up in response to the *browser needs name/email/picture *to construct ... I don't think the browser needs these >> Registration and login are conflated in OIDC. showing the >> name/email/picture implies those will be shared. That is commonly what >> happens when using Google -- but other IdP's might have those attributes, >> and it may not be what an RP needs, breaking the Law of Identity about >> minimal disclosure. >> >> The FedCM architecture works well to solve the 3P cookie deprecation for >> fancy Google login flow -- but standardizing that as how all login works >> normalizes that email, name, and picture will always be shared -- not a >> goal I think many of us are aligned on. >> > > Yeah, no disagreement from my side that that's a non-goal, and not part of > the end state. Purely sequencing strategy based on practicalities, from > where I stand. > > As I said, I think the following will go a long way in making > email/picture optional/unnecessary. > > https://github.com/fedidcg/FedCM/issues/559 > This seems in conflict with the Account Chooser that Google presents, which users now understand as a way for them to select which Google account they want to use. As a Google user, I find this experience with the Google IdP to work well. It would be confusing to me as a user if my name, picture, and email were not shown when selecting which Google account. The "popup" like UX is nice on sites where I can use my Google account and provides a more seamless experience without a redirect, but I don't know of any other IdP that has deployed a similar UX. The challenge is that the "account chooser" is not how other IdPs interact with the user. For example with Hellō we let users have high fidelity on which name, email, picture they release with each RP, as studies[1] have shown that users will often pick a different combination of name / email / picture across sites that are crisply not aligned along personas captured in an account. In sharp contrast to the wallet UX / API that was demoed at IIW recently, I find the browser is dictating too much of the UX in FedCM. It enables an experience similar to what Google offers websites today where login is enabled without a redirect -- but other IdPs don't provide that experience -- which leads to the observation that this work is primarily motivated to enable Google to continue offering its experience with the demise of 3P cookies. Enabling a web app to discover which IdPs a user has, if the user has used the IdP with the site, and if the IdP can provide the desired identity data and then to allow the user to pick the IdP they want to use, and then let the IdP own the UX (similar to the wallet UX demoed) /Dick [1] just kidding, I don't know of any official studies -- just my learning from Sxipper, a form fill product I had, where we learned that people don't really have precise personas they choose between for apps.
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
