Support accounts push (Login Status API) as an alternative to web-identity discovery

[dickhardt]

The current verification flow requires issuers to support pull-based account discovery: the browser fetches /.well-known/web-identity from the issuer's eTLD+1 apex, follows its accounts_endpoint to learn which emails the signed-in user can be vouched for, and only then proceeds to issuance.

FedCM is growing a push alternative — the Login Status API accepts an accounts list (navigator.login.setStatus("logged-in", { accounts: [...] }), currently behind FedCmLightweightMode, disabled by default), and in Chromium the pushed accounts already substitute for the accounts fetch inside IdpNetworkRequestManager::SendAccountsRequest. However, the email verification flow (content/browser/webid/delegation/email_verification_request.cc) is currently push-blind: it hard-requires the web-identity fetch to succeed, an accounts_endpoint to be present, and same-origin with the issuer, all before the accounts request where the push substitution lives. So today push can only ever skip the final fetch — it cannot replace discovery.

Proposal: define accounts push as a first-class alternative to web-identity discovery for email verification. An issuer that pushes its vouched emails at login time (and logged-out on logout, which we already send) should not need to serve /.well-known/web-identity at all — the _email-verification DNS TXT record plus /.well-known/email-verification on the issuer origin already establish who the issuer is and where issuance happens.

Why this matters in practice — deploying the eTLD+1 web-identity file is the operationally hardest part of being an issuer:

• The issuer's apex is often not owned by the identity infrastructure. Our production apex (hello.coop) is a redirect-only distribution to www, and serving one static file there ended up spanning three repositories' infrastructure. The wallet service itself runs on wallet.hello.coop and can trivially push at login.
• The flow only works today because Chromium follows redirects on the well-known fetch (follow_redirects=true) — an implementation detail rather than a spec guarantee.
• The accounts endpoint must be served with first-party cookies, Sec-Fetch-Dest: webidentity, and correct login-status keying — several failure modes that are all invisible to the issuer when they go wrong. Push moves the account list to a moment when the issuer knows the user is present and authenticated.

Push would also improve autofill latency (no discovery/accounts round-trips at form-interaction time) and avoid stale-cache issues with the well-known files.

Note for whenever push lands: pushed accounts currently run through the same ParseAccounts validation as pulled ones, including the requirement that account ids be unique within the list — issuers vouching for multiple emails from one account need per-email ids there too (filed separately).

I understand push support is already on the implementation roadmap — filing this so the spec captures it as a supported issuer deployment model, not just an optimization.

[samuelgoto]

Yeah, the accounts push is already largely implemented, but we never had any issuer/provider that requested it. I'm checking to see if there is anything else left to be done, but I think it is just a matter of releasing it.