demo · v143

Privacy leak explorer

A walkthrough of the actual leak v143 closes. Pick an IdP configuration shape, watch the per-request data the IdP can see, and watch v143's enforcement either pass the request (privacy-respecting) or block it (privacy-leaking).

The risk: if the IdP both serves client_metadata_endpoint AND knows the RP's URL via the federation flow, a creative IdP can build a cross-site user map without the user's knowledge. v143 makes any IdP that needs client_metadata_endpoint declare its accounts_endpoint and login_url directly — so the browser knows the full graph and can sanitise it.

Pick an IdP configuration

User
browser
IdP
idp.example
RP
app.example

What happens per step

How v143 enforces this

  1. Chrome reads https://idp/.well-known/web-identity.
  2. If the file references a client_metadata_endpoint but does not spell out accounts_endpoint and login_url, Chrome rejects the IdP.
  3. If the endpoints are present but inconsistent with the per-RP config, Chrome rejects the IdP.
  4. If they're absent and there's no client_metadata_endpoint, no enforcement needed — the legacy single-endpoint indirection is fine.
// /.well-known/web-identity — v143 compliant when client_metadata is used:
{
  "accounts_endpoint": "https://idp.example/accounts",
  "login_url": "https://idp.example/login",
  "provider_urls": ["https://idp.example/fedcm.json"]
}

see also