demo · v141

Phone Identifier

Some identity providers — large in markets like India, Brazil, Indonesia — identify users by phone number, not email. Before Chrome 141, FedCM's account chooser had no slot for that. The new tel field gets phone numbers into the picker so phone-first IdPs (Truecaller, Snapchat, WhatsApp Login) can adopt FedCM at all.

Heads up Requires Chrome 141+. The browser UI for the account chooser is OS-owned — this page renders an HTML mockup of what an IdP's accounts response would yield. The "real call" snippet below is the JSON shape Chrome consumes from the IdP's accounts endpoint.
checking support…

Toggle which alternative fields the IdP returns and watch the chooser refit:

Use your account to continue

the IdP accounts response

// GET https://idp.example/fedcm/accounts response
{
  "accounts": [
    {
      "id": "acc_2014_a",
      "tel": "+91 98765 43210",        // ← new in 141
      "username": "@anika",            // ← new in 141
      "email": "anika@example.com",
      "name": "Anika Roy",
      "picture": "https://idp.example/p/anika.png"
    },
    /* … */
  ]
}

// Site calls FedCM exactly as before — no API change for sites
const cred = await navigator.credentials.get({
  identity: { providers: [{ configURL: "https://idp.example/fedcm.json", clientId: "…" }] },
});

why this angle

The W3C FedCM issue thread #435 specifically called out phone-first IdPs: they had been unable to adopt FedCM because the chooser would render rows missing the only identifier the user recognised. That's an accessibility-and-recognition problem disguised as an API gap — users can't pick an account they don't recognise. The Chrome 141 change is small (two new optional fields on the accounts response) but unblocks a whole class of providers.

see also