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 https://github.com/fedidcg/FedCM/issues/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.