The IDP has to support additional infrastructure to support FedCM

[bvandersloot-mozilla]

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

[bvandersloot-mozilla]

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.

[bvandersloot-mozilla]

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.