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? > > >> >> I imagine that use of the current API would have single entries for Hellō >> accounts (if there happen to be multiple of them), and challenge for a site >> like Hellō would be letting the user understand that the account selected >> in the picker to initiate IDP interaction is not indicative of the >> information being released to the RP. However, I think this is a general UX >> issue for all IDPs using the federated credential API, unless they actually >> plan to always release exactly the display attributes to the RP. >> > > So far, I have no motivation to support the FedCM API. The experience in a > browser redirect works fine. > > >> >> The /accounts endpoint I admit is the part of the current proposal I >> understand the least. It seems like it mandates that the IDP know disparate >> accounts which have some linkage across machines, such as different members >> of a household. >> >> > 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. >> >> I imagine the difference is that the system UX can delegate to native >> applications in the passkeys and credentials case, and (on Android) can run >> such applications in sandbox modes where they cannot save or report >> metadata upstream over the network unless they are selected. FedCM is going >> to need to delegate to web properties, and it can’t be expected that all >> browsers will do heavy lifting to implement a particular sandboxing model >> to protect from IDPs that might try to get a pipe into every website a user >> visits that wants authentication. Likewise, platforms without Android’s >> sandboxing model for applications likely will need a different approach for >> credential wallets, and may require user consent for wallets to have access >> to tracking information. >> > > I thought the UX and API presented were from the browser, not the system. > > FWIW I find the passkey UX choices to be suboptimal. We only support > WebAuthN on mobile platforms on Hellō for that reason, and use it primarily > for convenience rather than security. > > Early in these discussions, we talked about the IdP prompting the user if > it can be an IdP, and then getting access to additional functionality. > Having a good UX around the permissioning would be a good area for the > browser to iterate on the UX. > > > >
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
