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. > > 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
