On Mon, May 13, 2024 at 5:15 PM Sam Goto <g...@google.com> wrote: > > > On Mon, May 13, 2024 at 4:50 PM Dick Hardt <dick.ha...@gmail.com> wrote: > >> >> >> On Mon, May 13, 2024 at 4:33 PM David Waite <da...@alkaline-solutions.com> >> wrote: >> >>> <snip> >>> >>> > On May 13, 2024, at 4:10 PM, Dick Hardt <dick.ha...@gmail.com> wrote: >>> >>> > 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. >>> >>> The name, picture, and email are used for the picker displayed by the >>> browser, based on IDP data for individual accounts. I do not believe these >>> values are released to the RP (by the API) - the result of a successful >>> interaction with the IDP for a selected user account is a credential object >>> holding an IDP-provided string token. That token can contain or reference >>> RP-specific attributes, such as pseudonyms. >>> >> >> Did you look at the referenced issue? >> While the name/picture/email may not be released to the RP, it may not be >> clear to the user what will be released, particularly one that is not >> familiar with the Google Account Chooser. >> > > After the account chooser, IdPs can choose to use the Continuation API ( > https://github.com/fedidcg/FedCM/issues/555), which allows them to open a > pop-up window to tell the user - using their own words in html/css/js -, > what's going to be shared with the RP. > > Would that help? >
For Hellō, the popup would be a confusing UX as Hellō is an IdP aggregator, and a full redirect is a better experience on desktop as it is not just a release page as the user may select other IdPs / Issuers to gather additional data. I still think that we will get into an IdP permissioning model of some kind if the browsers are going to want to block link decorating redirects. A number of federation protocol features depend on 3P cookies -- and this is the most straightforward way to allow 3P cookies where they are needed, and pave a path to start blocking decorated redirects. IMHO browsers should manage permissions, not provide application level UX, which I consider login / registration to be.
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
