Privacy unfriendly account chooser

[dickhardt]

The current FedCM proposal dictates that the user's name, email, and picture are presented to the user for selection.

While this model has been popularized by Google's offerings, it signals to the user that all of the information presented in the UX will be shared with the RP. even if the RP does not want or need that information.

I understand the account chooser model has worked well for Google as an IdP as many users have multiple Google accounts, each of which has a picture, email, and name -- which helps the user identify which Google account to select -- but pretty much all other IdPs don't have the multiple account issue -- and a UX that indicates to the user which IdP they are choosing, without signaling that their email, picture, and name will be share would be much more privacy friendly, and enable RPs and IdPs that do not need / want to share those user attributes to participate in FedCM. @samuelgoto I know this feedback is a late in the discussion. Thoughts?

[dickhardt]

The Accounts List API (7.10 is also very privacy unfriendly. https://fedidcg.github.io/FedCM/#idp-api-accounts-endpoint as the user's name and email are required parameters.

Additionally, the API is optionally asking for the IdP to share ALL the clients that the IdP has approved. If the user only uses one browser, then the browser would already know this -- and if they user has not, then the IdP is sharing information that they user is unlikely to know is being shared with the browser.

This brings up a philosophical discussion => the stance appears to be that the browser is 100% trust worthy and ONLY acts in the user's best interest.

[bvandersloot-mozilla]

Even while trusting the browser 100% there are issues with the account chooser and privacy: #230 #231.

I'm happy to have the philosophical discussion about the role of browsers on a separate issue specifically dedicated to threat modelling :)

[samuelgoto]

The current FedCM proposal dictates that the user's name, email, and picture are presented to the user for selection.

Yeah, I agree with you here: name/email and picture shouldn't be required.

and a UX that indicates to the user which IdP they are choosing, without signaling that their email, picture, and name will be share would be much more privacy friendly, and enable RPs and IdPs that do not need / want to share those user attributes to participate in FedCM

Yeah, that seems right to me, but largely depends on how to construct that UX. An account chooser seemed to us like a good starting point because it was a UX that we knew how to construct and explain to the user.

No disagreement on the privacy goals of sharing as little information as possible, but I'd be curious to get proposals on how to construct the UX (e.g. what does it look like? an IDP-chooser instead of an account-chooser?).

and if they user has not, then the IdP is sharing information that they user is unlikely to know is being shared with the browser.

In our privacy and security threat model, the browser (and the vertical stack below it, e.g. the operating system and the physical machine) is taken as a user agent that is trusted by the user.

[samuelgoto]

a UX that indicates to the user which IdP they are choosing, without signaling that their email, picture, and name will be share would be much more privacy friendly, and

Yeah, I'm totally convinced that that's the right thing to do.

Let's discuss how to accomplish this.

I'm thinking that there would be some sort of browser UX that says something like the following:

"Sign in to rp.example with idp.example? This allows rp.example to view your name. Allow?"

enable RPs and IdPs that do not need / want to share those user attributes to participate in FedCM

Second, how would an RP tell the FedCM UX "hey, I just need the user's name". Could that be done with an extra parameter like scope that you use in hello.coop with an enumeration of desirable claims?

e.g.

await navigator.credentials.get({
      federated: {
        claims: ["name"], // yo, just need your name
        // well-known enumeration of typical claims
        // claims: ["name", "nickname", "given_name", "family_name", "email", "phone", "picture"], 
        providers: [{
          url: "https://idp.example",
          clientId: "123"
        }]
      }
});

Here is an example using the OIDC individual claims request structure:

await navigator.credentials.get({
      federated: {
        claims: {
          name: {essential: true}, // required
          email: null, // optional
          emailVerified: null, // optional
          picture: {essential: true}, // required
        },
        providers: [{
          url: "https://idp.example",
          clientId: "123"
        }]
      }
});

This could potentially lead the a UX like the following:

Would that work?

[dickhardt]

wrt. "Sign in to ... " language => the user may already have an account, or this could be a registration. If there is an existing cookie for the IdP, the IdP can let the browser know if the user has previously registered. This allows the browser to present the option to sign in which is much simpler and cleaner and avoids claims management by the browser.

On that same point, different apps choose different language on what is happening. "Sign in", "Sign up", "Log in" etc. -- and of course there is localization.

wrt. claims such as email and phone, Hellō let's users select from what they have already verified, as well as verify a new email or phone all in the consent page. The UX above has the browser disinter-mediating the experience, which in my opinion gives the user less choice -- it also does not look like there is a selector to select a specific email or phone.

[npm1]

Is this roughly the same as #243?

[dickhardt]

No -- this issue is about what is being presented to the user on sign in -- implying that their name, email, picture will be shared

[npm1]

Sounds like we'd want to rename the fields in https://fedidcg.github.io/FedCM/#idp-api-accounts-endpoint then? Or perhaps provide more flexibility in terms of which fields may be provided and displayed to the user.

[martinthomson]

So there is a bunch of information that might be shared. I see a few issues here:

1. The IdP is willing to share a set of auxiliary information, but the user wants to remove some subset of those items. Historically, this is something that the IdP decides based on its understanding of user intent and RP needs. The deceptive piece here is that while browser mediation we can provide the appearance of user control over this interaction, once the IdP and RP share an understanding of user identity, they can use another medium to exchange any information they choose. Presenting the user with some means of control is - in the presence of a malicious IdP and RP - a lie.

2. The IdP simply does not have some of the information provided. It might be that we need placeholders for those cases where there is no account name or picture.

3. The IdP does not offer multiple accounts. I don't see this as a problem. If we can display a list, that list can be size 1.

I think that the first of these speaks most to @dickhardt's comments regarding the sort of information might be exchanged between IdP and RP. This becomes more about authorization than it does about a simple login flow. That is, what opportunities does an IdP have for interacting with users when it comes to making decisions about what an RP can learn.

Generally, IdPs rely heavily on an initial interaction flow that is rendered on their site for establishing an understanding of what information might be shared. Here, with the browser intermediating (I don't think it's disinter-mediating), the expectations a user might gain about information exchange might be very limited: userid (which might be email, or not), name, and picture. This might mean that an IdP has to provide very sparse information initially, then find other ways to authorize access to more information.