Some more evidence for this is most of our customers. We provide something a bit different from Hello, but the ask is the same. The branding experience for the widget must be fully controlled by the app developers, this is the only way they'll support it. We have our own unified managed login experience but most customers have designed a custom experience to host inside their app.
Unless FedCM supports a purely API based flow, there is no way this is going to get off the ground. Here, the authors of FedCM are so worried about not allowing tracking, but while a problem, is not one that users actually care about. They care about delivering their ticket at the top of their backlog. That ticket doesn't say "make sure IDPs can't track our users", it says "the login button must be blue". In the future, no doubt there will be adoption in the long tail innovators that don't care, but if we want actual usage by the early and late majority, by actual companies and therefore provide value to actual users, the UI must be fully controllable app side. So a full browser API for handling user input and events for handling responses. - Warren On Tue, May 14, 2024, 02:35 Dick Hardt <dick.ha...@gmail.com> wrote: > > > 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 >
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
