Reusing the FedCM accounts schema imposes 1 account : 1 email — issuers vouching for multiple emails are silently rejected (duplicate id)

[dickhardt]

The verified-email-autocomplete flow reuses FedCM's accounts_endpoint and accounts schema. In FedCM's data model each entry is an account with id as its primary key and email as an attribute — a strict 1:1 between entries and emails.

An EVP issuer is authoritative for email addresses, not accounts. A single signed-in account will often be vouched for on multiple delegated emails (e.g. dick@blame.ca and home@blame.ca on one account). The natural response is one entry per email — which duplicates the account id:

{
  "accounts": [
    { "id": "usr_abc123", "email": "dick@blame.ca", "name": "Dick Hardt" },
    { "id": "usr_abc123", "email": "home@blame.ca", "name": "Dick Hardt" }
  ]
}

Chromium rejects this entire response as malformed (AccountsResponseInvalidReason::kAccountsShareSameId in IdpNetworkRequestManager::ParseAccounts, content/browser/webid/idp_network_request_manager.cc). EmailVerificationRequest::CheckIfVerifiable then reports not-verifiable and the flow stops silently — no DevTools issue, no console message. This cost us a long debugging session: the accounts fetch returns 200 with the correct email present, autofill simply never offers verification. Notably the EVP code never uses id — it matches accounts by email (case-insensitive); the uniqueness constraint is inherited FedCM plumbing.

The same ParseAccounts validation applies to the accounts-push / lightweight path, so pushing accounts via the Login Status API does not avoid this.

Workaround: mint synthetic per-email ids ("id": "usr_abc123:dick@blame.ca").

Suggestions (any subset would help):

1. Spec the semantics of id for EVP explicitly — e.g. "an opaque identifier unique per (account, email) pair", making the workaround the documented behavior; or drop the uniqueness requirement for EVP since matching is by email.
2. Consider whether EVP should use a leaner accounts schema (just email, optionally name) rather than inheriting FedCM account semantics wholesale.
3. Surface a DevTools issue when an accounts response is rejected during an EVP flow (kAccountsShareSameId, missing required fields, etc.) — today the failure is indistinguishable from "user not signed in".

[samuelgoto]

Surface a DevTools issue when an accounts response is rejected during an EVP flow (kAccountsShareSameId, missing required fields, etc.) — today the failure is indistinguishable from "user not signed in".

This option is somewhat simple to implement, and we can take that AI, but before I think harder about the other two, would it be sufficient?