<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. 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. 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. -DW _______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
