The IDP has to support additional infrastructure to support FedCM

Specifically, the items in Identity Provider HTTP API. It would be nice to eliminate this requirement.

One way forward would be to expand upon the IDP Sign in status API and have a top level IDP window get opened. I discussed something like this in fedidcg/proposals#3 but it could be adapted here. I'll add a comment with a general shape of the proposal.

How this could work:

We need to allow the FedCM n.c.get API to open a window. Let's add to the IdentityProviderConfig a new optional item IdentityProviderNavigationConfig navigation_config; and make the configURL not required. But the IdentityProviderConfig must have one of them.

This new config would be defined as

enum IdentityProviderDisplayFeatures {
  required boolean popup;
  long width;
  long height;
  long left;
  long top;
}

dictionary IdentityProviderNavigationConfig {
  IdentityProviderDisplayFeatures displayFeatures;
  required USVString loginURL;
  IdentityProviderBranding branding;
  USVString
};

If a IdentityProviderNavigationConfig is provided, then the browser should not try to access any IDP APIs. Instead, it should display the IDP using branding in any UI and provide a window.open(navigation_config["loginURL"], "_blank", foo) call where foo is a serialization of navigation_config["displayFeatures"] with noopener. Then the opener sits and waits for the opened window to call an augmented IDP sign in status API's recordSignIn.

The IDP sign in status API is augmented to be the following:

[Exposed=Window,SecureContext]
interface IdentityProvider
 {
  static Promise<Record<string,LoginStatusRequest>> pendingFederatedLoginRequest();
  static undefined recordSignIn(IdentityProviderSignInResult? credentialInformation);
  static undefined recordSignOut();
};

dictionary IdentityProviderSignInResult {
  required string relying_party_origin;
  required string token;
// Any other information required to construct an IdentityCredential
}

dictionary LoginStatusRequest {
  required string relying_party_origin;
  required IdentityProviderConfig caller_idp_config;
}

This also requires a per-origin map for IDP pending login requests. It should be added to when the window.open is called above, be read when pendingFederatedLoginRequest is called, and have values modified when recordSignIn is called. It should key on the IDP origin (taken from the loginURL or the IDP sign in status API's caller origin) and have a value of Sequence.

When recordSignIn is called with a defined and non-null argument, the corresponding pairs (with key equal to relying_party_origin) should be removed from the IDP's entry's value in the new per-origin map. Then the caller to navigator.credentials.get() that caused that pair to be included in the IDP's entry's value should resolve with a credential constructed from the argument to recordSignIn. That credential can also be Stored automatically, conditioned on a new boolean field in IdentityProviderSignInResult, if IdentityCredentials are storable.

If we decide that IdentityCredentials are storable, we should also extend IdentityProviderNavigationConfig to allow the caller to specify the target of the window.open call to be either "_blank" or "_top". This enables redirect-navigation! And then a resulting stored credential can be collected with mediation=silent when redirected back to the RP. This is probably worth it IMO.

I'm eliding a lot of detail here. And it will depend on the resolution of #436 and #438 and #439. However, I think this sketches how we can skirt around the IDP API requirement via an opener and using the IDP Sign in Status API as a communication channel.

I do use branding but somehow my UI looks like this (red arrow), why?

passed to navigator.credentials.get

{
      identity: {
        providers: [{
          configURL: "https://idp.local/fedcm/manifest.json",
          clientId: "123",
          nonce: `${Math.random()}`,
        }],
        context: 'signup',
        mode: 'active'
      },
      mediation: 'required',
};

config response send back

{
        id_assertion_endpoint: 'https://idp.local/fedcm/assert',
        accounts_endpoint: 'https://idp.local/fedcm/account',
        login_url: 'https://idp.local/signin',
        client_metadata_endpoint: 'https://idp.local/fedcm/client_metadata',
        branding: {
            background_color: 'blue',
            color: 'white',
            icons: [{
                url: 'https://idp.local/rubber-duck.png',
                size: 512,
            }],
            name: 'Duck idp'
       }
}

The loading dialog in the screenshot is shown before we get a response from the config URL, so we can't use the data from the config file to customize it.

Thank you, I also want to add, that the same dialog is shown for a split second (like 0.5 sec) in the video demo of the sandbox, before it is covered with the "login in" window from the idp

I catch that by accident, if i had noticed I would not have asked the question, my apologies

Thank you

video

This is another older issue I'd like to know if we can resolve (and therefore perhaps close #439 )

Unless someone is prepared to champion this issue, we plan to close it in two weeks.

If you believe it should remain open, please comment here and tag it for discussion at a future Federated Identity WG/CG meeting so we can determine next steps.

No one has volunteered to champion this issue or requested further discussion, so we’re closing it for now.

If there is renewed interest or new information that warrants reconsideration, please feel free to open a new issue or bring the topic to a future Federated Identity WG/CG meeting.

@hlflanagan

@hlflanagan — Perhaps "not-planned" (which leaves whatever led to the issue being opened basically unresolved) would be a better closure than "completed" (which suggests that whatever led to the issue being opened is no longer the case), for this and nearby issues?

Navigation Menu

Repository navigation

The IDP has to support additional infrastructure to support FedCM #441

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

The IDP has to support additional infrastructure to support FedCM #441

Description

Activity

bvandersloot-mozilla commented on Feb 16, 2023

bvandersloot-mozilla commented on Feb 16, 2023

jacobbogers commented on Jul 29, 2025

cbiesinger commented on Jul 30, 2025

jacobbogers commented on Jul 31, 2025

hlflanagan commented on Feb 6, 2026

hlflanagan commented on Sep 24, 2026

hlflanagan commented on Oct 7, 2026

TallTed commented on Oct 14, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions