Occurred since Chrome 126: FedCM Accounts API does not show the user in the FedCM dialog if the email is blank.

[solatsuta]

Overview

The FedCM Accounts API behaves differently in Chrome 125 and earlier than in Chrome 126 and later when the email address is blank.

In Chrome 126 and later, user selection is no longer possible in the dialog.
I have not been able to find an issue regarding this change, so I am submitting an issue.
If you know of any discussion of the specification change, please let me know.

Thanks for reading this far.
This issue is made in translation. Sorry if the language is strange.

Details

The Accounts API responds with the following JSON

{
  "accounts": [{
    "id": "1234",
    "name": "John Doe",
    "email": "",
    "approved_clients": ["123", "456", "789"],
  }
}

For Chrome 125, the FedCM dialog will ask if you want to log in as "John Doe" and the FedCM assertion process will run.
For Chrome 126 and later, the FedCM dialog does not display user information.

We have confirmed that Chrome 126 or later behaves the same as Chrome 125 by including a value such as "dummy@test" in the email field.

Question

• Is this behavior a specification or a bug?

• If it is a spec, how should IdPs who do not know the user's email address deal with it future Chrome?

[wanderview]

I recommend filing a bug at crbug.com in the "Chromium > Blink > Identity > FedCM" component.

[npm1]

Do you have a username or something? Perhaps put that while we make the email optional, see w3c-fedid/FedCM#317

[samuelgoto]

Is this behavior a specification or a bug?

Ugh, this does seem to be a backwards incompatible change that we made that is causing this. Here is the CL that introduced the requirement that email addresses are present, which, as you noted, got into Chrome 126 and above.

https://chromium-review.googlesource.com/c/chromium/src/+/5529788

It is technically neither (a) incompatible with the spec nor (b) a bug, since email is a required field and this CL is just enforcing that the string is non-empty.

If it is a spec, how should IdPs who do not know the user's email address deal with it future Chrome?

That's a good question.

Can you help us understand a bit more about your deployment. A few questions:

(a) Do all of your users not have email or just some?
(b) Do you support multiple accounts? Or can the browser assume that you'll have just one entry returned in the accounts endpoint?
(c) If you support multiple accounts, how do your users differentiate between them (a profile picture? a username?)?
(d) when the RP isn't in the approved_clients array, the browser says "do you want to share name, email and profile picture". If the email is unavailable, maybe we should remove the "email" from this list?

[solatsuta]

@npm1
Users without email addresses are given unique nicknames.

Currently, we work around the problem of accounts not showing up in FedCM by displaying the nickname in the "email" field.

[solatsuta]

@samuelgoto
Thanks for the link Cl.
I understood the change from Chrome 126.

(a) Only some users do not have an email address.
If a user refuses to register his/her email address, we ensure uniqueness only with cookies. In essence, if the cookie is deleted, the user will never be able to sign in again.

(b) No, multiple accounts are not supported.
the response to the accounts endpoint will always have a single entry.

(c)The condition does not occur because the response to b is no.

(d) We believe that there are a certain number of IdPs that support a function that allows users to reject the acquisition of personal information through GDRP or other means.
We would like you to consider a UX that also takes into account the case where a user does not have an e-mail address. We agree with removing "email" in the case in question as one idea.

[npm1]

Followup questions:

1. when the user has a nickname/username, do you share that with the RP or not? What about when the user has an email?
2. how common is it for the user to have an account tied to the cookie and being used for federation? It does not seem optimal to use such an ephemeral account in FedCM so I'm curious.
3. Even though you do not support being logged in to multiple accounts, a user may still have multiple accounts. Do you consider it useful for the UI to show some way to let the user know the precise account being used (eg by showing the nickname) even if that is not shared with the RP?

[solatsuta]

@npm1
OK. I will answer.

Ans. 1

Nicknames may be shared in RP. However, we do not share email addresses.
In my case, the email address is one of the elements used when a user logs into IdP.
It will not be used by the RP, so we will not share it.

Ans. 2

This happens a lot in my case. For example, this is the case where the RP is offering a game.
It is up to the user to decide whether or not to continue with the game play.
For example, an IdP can provide a unique account by registering the user through the tutorial.

If the RP cannot manage the data until the user finishes the tutorial without tying the data to something, the IdP will provide the user tied to a cookie as an ephemeral account.

The user may interrupt and resume the tutorial as long as the cookie is not deleted.
If the user does not continue playing, the data tied to the cookie will be deleted when the cookie expires, as it is dependent on the cookie.

This is beneficial to the user in terms of personal information management, since the user can play the game without unwillingly registering any personal or other information. We want to respect the user's willingness to register, so we offer ephemeral accounts that rely on cookies.

Ans. 3

Yes.
It is very important to specify which IdP the user is trying to log into and which account he/she is trying to log in to.
It is also important for IT literacy that users themselves choose to log in of their own volition as a way to avoid malicious sites.

I think it is an important element of IdP for users to be able to identify themselves by nicknames, icons, etc.

[samuelgoto]

Ok, I think we heard two different things in this thread. Let me try to reconcile them.

First, we heard:

[...] when the email address is blank [...] user selection is no longer possible in the dialog.
Only some users do not have an email address.
Users without email addresses are given unique nicknames.
Currently, we work around the problem of accounts not showing up in FedCM by displaying the nickname in the "email" field.

The problem is that we currently have email as a required fields in the accounts endpoint. The fix here, I think, is simple:

1. Make email optional in the in the IdentityProviderAccount dictionary that we get back from the accounts endpoint and
2. Introduce username to the IdentitityProviderAccount dictionary, as an optional string

This would allow you to pass us email or username, and we could use one or the other in the account chooser.

Here is an example of an accounts response without an email address:

{
  "accounts": [{
    "id": "1234",
    "name": "John Doe",
    "username": "johndown1982",
    "approved_clients": ["123", "456", "789"],
  }]
}

Would that work?

Second, we heard:

when the RP isn't in the approved_clients array, the browser says "do you want to share name, email and profile picture". If the email is unavailable, maybe we should remove the "email" from this list?

We would like you to consider a UX that also takes into account the case where a user does not have an e-mail address. We agree with removing "email" in the case in question as one idea.
Nicknames may be shared in RP. However, we do not share email addresses.
It will not be used by the RP, so we will not share it.

The problem here is that, indeed, FedCM currently assumes that what will be shared will be name, email and picture, which is a known problem. We are generally addressing this problem with the Fields API, so the proposal here would be to:

3. Introduce username to the Fields API, such that RPs can request for username but NOT for email, such that the browser doesn't say that the email is going to be shared.

Here is an example of how the RP would call the FedCM API:

const credential = await navigator.credentials.get({
  identity: {
    providers: [{
      configURL: ...,
      // controls what permission is asked of the user
      fields: ["name", "username", "picture"], // in case the RP wants the username
      fields: ["name", "picture"],  // in case the RP doesn't need the username
    }]
  }
});

Would that address this issue?

[solatsuta]

This would allow you to pass us email or username, and we could use one or the other in the account chooser.

We think it is good, no problem.

The problem here is that, indeed, FedCM currently assumes that what will be shared will be name, email and picture, which is a known problem. We are generally addressing this problem with the w3c-fedid/custom-requests#4, so the proposal here would be to:

A few questions remain regarding this one.
RP should not be asking for email when logging in.
It is necessary for the user to choose which account he/she logs in with, and depending on the IdP, the email may not be unique.
What is important is that users themselves can choose which account to log in without making a mistake.

So I would prefer the following response

account endpoint response

• Make email optional.
• Add unique_name to the response. it's required value.
  • unique_name should be an arbitrary String defined by the IdP.
    • For example, unique_name can be defined by the IdP as information that uniquely identifies the user, such as email or nickname.

{
 "accounts": [{
   "id": "1234",
   "name": "John Doe",
   "unique_name": "john_doe@idp.example",        // For example, if an IdP has id + email as uniq
   "unique_name": "John Doejohn_doe_123456789",  // For example, if an IdP has id + name as uniq
   "unique_name": "Jack",                        // For example, if an IdP has id + nickname as uniq
   "picture": "https://idp.example/profile/123",
   "approved_clients": ["123", "456", "789"],
   "login_hints": ["john_doe"],
   "domain_hints": ["idp.example"],
  }]
}

account endpoint request

• FieldsAPI can be specified as options. For example, email.
  • This allows RP who need email to retrieve email, and RP who only need id and unique_name do not need to exchange unnecessary information.

const credential = await navigator.credentials.get({
  identity: {
    providers: [{
      configURL: ...,
      // Optionally specify additional information to be obtained
      fields: ["email"], // in case the RP wants the email
    }]
  }
});

The above will solve the problem in my use case where an email cannot be retrieved in an RP request.
Please consider this.

[samuelgoto]

Ok, I think we are getting there!

Add unique_name to the response. it's required value.
unique_name should be an arbitrary String defined by the IdP.

One of the challenges with taking an arbitrary string is abuse: a spammer can abuse the API to include something like "Get 5% off" and create an intrusion for users.

I was hoping we'd be able to prevent some of this abuse if we could enumerate the types of valid strings (e.g. we can regex email, phone numbers and usernames). An IdP would be able to choose which one to pass to be displayed to the user to disambiguate accounts.

For example:

{
 "accounts": [{
   "id": "1234",
   "name": "John Doe",
   "email": "john_doe@idp.example",        // For example, if an IdP has id + email as uniq, has to match emails
   "phone_number": "(630) 023-3243",   // For example, if an IdP has id + phone as uniq, has to be numeric
   "username": "John Doejohn_doe_123456789",  // For example, if an IdP has id + name as uniq, can't contain spaces
   "username": "Jack",                        // For example, if an IdP has id + nickname as uniq, can't contain spaces
   "picture": "https://idp.example/profile/123",
   "approved_clients": ["123", "456", "789"],
   "login_hints": ["john_doe"],
   "domain_hints": ["idp.example"],
  }]
}

Would that work?

Or do you have any other type of way to clarify to the user accounts other than email, username, phone_number?

FieldsAPI can be specified as options. For example, email.

Yeah, I think this would work.

[solatsuta]

An IdP would be able to choose which one to pass to be displayed to the user to disambiguate accounts.

It will work!

I believe the problem can be solved by doing what is in the example.
If the interface of the account API call on the RP side remains the same, I think this is a very good approach.

If only a modification to the accounts API response interface on the IdP side, or to the IdP such as /.well-known/web-identity or fedcm config json would complete the response, then issue problem is solved.
Thanks for your consideration.

[samuelgoto]

If the interface of the account API call on the RP side remains the same, I think this is a very good approach.

Yeah, that's one of the benefits of this approach: we could make the accounts endpoint response backwards compatible.

[solatsuta]

I believe this issue completes the identification of the problem and the rubbing of the direction of the response.
Since w3c-fedid/FedCM#639 has also been raised, I think we can close this issue.

[solatsuta]

Let's discuss in the future at w3c-fedid/FedCM#639.
privacysandbox/privacy-sandbox-dev-support#379 will be Closed !!