Multi-IdP API: The RP needs a way to know which IdP the user selected

[samuelgoto]

I'm posting this on behalf of an IdP that is currently experimenting with the Multi-IdP API and has given us this feedback

In the Multi-IdP API proposal, the RP needs to know which IdP was selected from the list of providers, so that it can interpret the token that it gets in the IdentityCredential.

[samuelgoto]

One of the proposals that @npm1 is exploring is exposing the configURL that was used when the user made the choice in the resulting IdentityCredential.

[obfuscoder]

Or the configURL provided by the IdP during IdP registration (see w3c-fedid/idp-registration#2) when client used "any" as IdP configURL?

[samuelgoto]

Or the configURL provided by the IdP during IdP registration (see https://github.com/fedidcg/FedCM/issues/240) when client used "any" as IdP configURL?

Yep.

[obfuscoder]

I read somewhere else that this is already available in Canary for testing?

[cbiesinger]

Yes! @npm1 added a configURL property to the returned IdentityCredential in version 126.0.6436.0 (requires the multi IDP flag to be enabled)

[samuelgoto]

Yes! @npm1 added a configURL property to the returned IdentityCredential in version 126.0.6436.0 (requires the multi IDP flag to be enabled)

This cl here.

As @cbiesinger, you should be able to use the configURL in the returning IdentityCredential to figure out which IdP that was used that resulted into the promise.

I think @npm1 was intending it to be used somewhat like the following:

const credential = await navigator.credentials.get({
  identity: {
    providers: [{
      configURL: "https://idp1.example",
      // ... other stuff ...
    }, {
      configURL: "https://idp2.example",
      // ... other stuff ...
    }, ]
  }
});

const {token, configURL} = credential;

// decode the token differently depending on which configURL was used

I'm going to mark this as fixed, since there is a different issue tracking putting this into the spec, etc here:

#2

Let me know if you give this a try and it doesn't work for you @obfuscoder .

[cbiesinger]

We should probably keep this open until we actually added this to the spec

[aaronpk]

Just wanted to chime in and say this is working for me.