demo · v148

Login Element Gallery

A walk through the proposed declarative <login> element. Three planning-stage use cases from the FedIDCG explainer are wired to the showcase FedCM backend, so each control can request a real assertion token or run the same endpoint trace.

Heads up Origin trial. No browser parses <login> yet, so these controls stand in for the proposed activation surface while calling the real FedCM-shaped backend endpoints.

recipe 1 — same-origin "Sign in with Google"

The classic case from the explainer: a relying party that wants to swap its JavaScript-driven button for a declarative element. The browser handles the FedCM call.

Markup

<login
  provider="https://accounts.google.com/.well-known/web-identity"
  client-id="example-client.apps.googleusercontent.com">
  Sign in with Google
</login>

Activated control

No beforeinstallprompt-style dance. No JS handler. The element itself talks to FedCM.

recipe 2 — marketplace cross-origin invitation

A directory site (think: an SSO comparison page) wants to surface a login affordance for someone else's site. Today this is impossible without redirect. The relying-party attribute lets the browser propose the cross-origin login, and the IDP confirms via the agentic FedCM extension.

app garden
categoriestrendingnew
Cloud Notebook notebook.example
Mailbox Pro mailbox.example
Drafts Studio drafts.example 
<login
  provider="https://idp.example/.well-known/web-identity"
  client-id="aggregator-client"
  relying-party="https://notebook.example">
  Sign in
</login>

recipe 3 — IDP-initiated invitation

From the fedidcg/idp-initiated explainer. The IDP (not the RP) hosts the surface inviting the user to take their session somewhere new — e.g. "use your work account to sign in to this new procurement tool".

work identity
profileapps

Invitations from your admin:

Procurement Suite invited by it@work.example

// Interaction log — activate a login control above.

the code (planning-stage)

// Same-origin (recipe 1) — declarative form
<login provider="https://idp.example/.well-known/web-identity"
       client-id="...">Sign in</login>

// What the UA dispatches when activated:
navigator.credentials.get({
  identity: {
    providers: [{
      configURL: "https://idp.example/.well-known/web-identity",
      clientId: "..."
    }]
  }
});

// Cross-origin (recipe 2) — relying-party attribute opts the user in
<login provider="..." client-id="..." relying-party="https://other.example">
  Sign in
</login>

see also

implementation reference

Need the exact API surface, compatibility boundaries, errors, lifecycle, and source links? Read the matching gendn reference ↗