Allow IDP registration

[tplooker]

TL;DR there is a significant amount of context at the start of this issue before we get to the proposal, here is a google doc version for an alternative form.

Background

The origins of many federated identity technologies have deep ties to providing an open ecosystem of IDPs to give End Users ample choice in how they choose to “login”. Efforts like OpenID v1 and v2, SIOP, Mozilla Persona, CHAPI, and others, strongly embodied these principles and much of this has remained in future revisions of standards such as OpenID Connect core. However, due to numerous complex issues, much of the industry today, primarily around the “social login” market has consolidated leaving a few IDPs as the dominant market players. To counteract this, FedCM in this work on establishing new browser mechanisms for supporting federated identity has an opportunity to make a meaningful impact and help re-chart the course for the future of federated identity on the web.

In the landscape of today, the choices around federated providers an End-User has available to them when going to “login” on the web is most often a small curated list of IDPs pre-determined by the Relying Party.

One of the main market forces that influences the options an End-User is presented with is often referred to as the NASCAR problem (https://github.com/fedidcg/FedCM/blob/main/explorations/related_problems.md#the-nascar-flag-problem). In order for a relying party to keep the UX on their login page from being overwhelming, they must pick a small number of IDPs to support (usually 2-3). How this decision is made by a relying party can be complex, but one major driving factor that applies to many is the existing user-base a particular IDP offers. Often the larger the user base, the more likely the relying party is in its desire to support it. This is because the relying party wants to offer as few login options as possible that services the largest possible user-base for them. This factor makes it difficult for new competition in the IDP side of the federated identity landscape, especially for entities that don’t have large pre-existing user-bases.

Who an IDP is, is often also important to factor in. As federated login technologies have developed, companies who built successful social networks, ISPs and commonly used search engines had the large user bases that made them attractive as IDPs to many Relying Parties. These IDPs have been very open about their interests in performing the IDP role, where the access it gives them to information about End User behavior, often supports their primary business models. In this context, concerns about user tracking are very real.

End Users looking to opt out of the limited federated identity login options available today are required to significantly compromise convenience because they are forced to manage a new set of credentials directly with the relying party, creating friction and usability challenges.

This equation in many cases has led to End Users using federated login options, trading off concerns such as the fear of being tracked by a particular IDP, for the convenience it offers. As a result, Relying Parties seeking large user bases continue to converge on the dominant IDPs and End User choice is further diminished. We end where we are today, in a self-reinforcing loop dominated by extremely limited choice at logon.

What we need to support instead is a federated login model that re-introduces the End-User into the mediation process so they can have more of a say on which provider they use and where.

Proposal

Currently the proposed FedCM API is focused around a browser mediated approach that assumes the relying party specifies a set of IDPs it supports login from. This model is largely a continuation of that described above and in many respects is just a browser mediated version of what we see most commonly on the web today.

Many Relying Parties will want to continue in a model where they specify the IDPs they support.

The challenge is for when this is not the case, to provide a viable way to achieve more End-User choice, greater inclusiveness, increased competition, and reduce vendor lock-in around the IDP options available.

In this proposed additional model, instead of the Relying Party specifying the IDPs it supports in the federation request, it communicates the capabilities it supports such as signature schemes, assertion formats and response modes.

End-Users can then register providers they wish to use with the browser, which are then available as options to present to the End-User when they go to login. This is enabled through the following two step process

1) Registration Step - The End User navigates to the IDP they want to use, prior to attempting a login with an RP and registers it for use in the browser.

2) Login Step - Later when the End User goes to login with a particular RP that supports this open IDP model, instead of the End User being presented with a pre-set list of IDPs determined by the RP, they are presented with a list of IDPs they have registered to use that support the capabilities required by the relying party.

Note - To prevent a scenario where a relying party is supporting this login model but no IDPs have been previously registered in the browser, the relying party could provide IDP hints.

Conclusions

Considering the cited basis for FedCM is to “preserve and elevate identity federation” please strongly consider adopting this in your work. Choosing this path would have a meaningful positive impact on federated identity on the web by improving the choices End-Users have to login on with. Ignoring this issue risks the continued consolidation of options available for End-Users and therefore undermining its value as a means of login.

Acknowledged Challenges

• What happens to an end user when their registrations are wiped?
• What happens if an end user has forgotten what IDP they use where?
• Can a significant enough portion of relying parties trust login assertions from an IDP for which they don’t have a pre-existing trust relationship?
• How are the capabilities supported by the RP communicated to the browser

Prior Art

CHAPI Mozilla Persona Account Chooser OpenID

Raised with @dmitrizagidulin

[samuelgoto]

I strongly support this overall vision for FedCM, making it so that IDPs interoperate (e.g. don't require pre-registration).

We've been thinking along those lines too and calling it affectionally BYOIDP ("bring your own IDP"), as an analogy to how signing-up with email works (i.e. it is not like there is a list of email providers that the websites works with, right?).

As you may have guessed, we are deliberately not choosing to start there, because we have a responsibility to preserve the current deployment of federation, but we are in agreement of where it should/could go.

I don't think that the solution is as simple as you are making it seem (from a design of incentives perspective first, but also from a UX perspective second), but I think you got the problem and the broad strokes of how to go about it right.

Any chance you could come over some time at the FedID CG to present your work / proposal?

[tplooker]

We've been thinking along those lines too and calling it affectionally BYOIDP ("bring your own IDP"), as an analogy to how signing-up with email works (i.e. it is not like there is a list of email providers that the websites works with, right?).

Yes very much aligned with this framing.

I don't think that the solution is as simple as you are making it seem (from a design of incentives perspective first, but also from a UX perspective second), but I think you got the problem and the broad strokes of how to go about it right.

Yes there are a bunch of additional incentives and UX complexities to consider here, some we have already discussed a bit but im sure there are others.

Any chance you could come over some time at the FedID CG to present your work / proposal?

Yes we would be more than happy to.

[samuelgoto]

Wonderful! @hlflanagan any chance you can help us coordinate a presentation by @tplooker sometime in the upcoming meetings that intersects with his availability?

[gffletch]

This model is very similar to the approach of decentralized identity. Rather than inventing something new, I highly recommend to look at making the browser be a viable "wallet" for the user and then just use decentralized identity protocols. Note that the OpenID Foundation is working in this space as well with the SIOPv2 spec and it's associated specs.

https://openid.net/specs/openid-connect-self-issued-v2-1_0.html https://openid.net/specs/openid-connect-4-verifiable-presentations-1_0.html

[tplooker]

@gffletch my mental model here is that the browser is a mediator able to facilitate an End-User using an IDP of their choosing (within the constraints of the RP of course). That IDP could be a "wallet" taking a variety of different forms such as a server/web application or native application. So the "browser" itself isn't the wallet. I also agree with the reference to prior art, SIOP in particular needs a solution to mediation beyond the limitations of a custom URL scheme such as "openid://"

[samuelgoto]

There were a series of sessions that happened at IIW between Kristina (SIOP) / Tobias (this proposal) / Dimitri (CHAPI) / Wayne (Sign-in with ethereum) and I (FedCM) on topics adjacent to this issue, and I feel like we left with a good amount of synergy and a reasonable sense of where to start from.

This is my personal recollection of what we discussed as a group at IIW, but others feel free to chime in and correct me where I'm wrong.

Overall, I left with the sentiment that we had a good amount of appreciation for each other's work.

As far as FedCM goes, SIOP aligns really well with FedCM because it addresses two key problems: (a) the portability problem and (b) keeping issuers blind to verifiers (through a self-issued and trusted OP).

FedCM aligns well with SIOP and CHAPI because both seem to need a neutral / reliable wallet-selector: SIOP has to name IDP on desktop browsers (e.g. if a user doesn't have a phone to scan a QR code) and iOS (e.g. without an openid:// disambiguator), and CHAPI requires everybody to trust auth.io and doesn't quite work in the absence of third party cookies.

The overall idea that we floated around at IIW (largely based on @tplooker 's original architecture) was to expose a browser API to allow:

(a) the registration of IDPs (Self-Issued OPs or not) and (b) the ability of RPs to ask for an idtoken un-opinionated about where it is being issued from

It wasn't perfectly clear / obvious, but the intuition in the group was that the browser should just keep pushing things down to the OS level (which would obviously require further cooperation from OSes).

For (a) something along the lines of following would write into browser storage the IDP's registration:

navigator.credentials.registerProvider("https://my-idp.example");

This call registers with the Browser the IDP at "https://my-idp.example", which can have all sorts of configuration under a .well-known configuration. In the configuration, there would be some sort of callback that the IDP registers to be called when the IDP is chosen later.

We discussed a few UX options, and the most obvious one was to follow @tplooker 's original proposal to prompt at this point (this also matches what CHAPI does, so that's encouraging). We discussed a few more options and generally agreed that this needs more experimentation to determine what would work best.

For (b), FedCM could expose an extra option to allow, not only named IDPs, but also allowing the user to bring their own. Something along the lines of:

const credential = await navigator.credentials.get({
  federated: {
    providers: [{
      // allows the account chooser to load named IDPs
      url: 'https://named-idp.example',   
      clientId: '********'
    }],
    // The RP accepts IDPs that called registerIDP() before.
    registered: true, 
    // the RP accepts SIOPs
    selfIssued: true,
  }
})

And, when invoked in this fashion, the account chooser would bring accounts from "named" IDPs as well as "registered" IDPs.

If a "registered" IDP is called, then the callback previously registered is called.

We also discussed how this could be used to pass VCs/mDLs over SIOP, which didn't seem to conflict/disagree with this architectural choice. One of the challenges that Wayne brought up that I don't think we talked about enough was to have the ability to register not just IDPs but also types. Something along the lines of:

navigator.credentials.registerProvider("https://my-idp.example", [
  "UniversityDegree", "DriversLicense", "COVIDVaccine", ...
]);

Such that the RP could then use a querying language to filter out SIOPs that contain them.

We also discussed briefly that we'd like the resulting idtoken to be directed, so it is likely that the callback needs to take at least the RP's name so that the SIOP server can direct it.

There is a lot of handwaving here, but this is more or less what I remember from the discussion. There were a series of diagrams that we drew in the whiteboard, and in case any of you still have them on your phones, sharing them would be appreciated.

[Sakurann]

Pictures of the whiteboard we drew:

[quartzjer]

This all looks and sounds pretty fantastic, wish I had been there!

We also discussed briefly that we'd like the resulting idtoken to be directed, so it is likely that the callback needs to take at least the RP's name so that the SIOP server can direct it.

Not just directed, but a nonce would be essential for the resulting token to be bound and prevent replay as well. Signed requests will also be an important trust mechanism, so the RP initiation interface might be fairly rich.

[dlongley]

Instead of taking this approach:

navigator.credentials.registerProvider("https://my-idp.example", [
  "UniversityDegree", "DriversLicense", "COVIDVaccine", ...
]);

I'd recommend that any sort of filters be provided / be updateable either through some .well-known config or manifest.json. Providers should not require the user to visit their site and call registerProvider again to make changes / improvements to what it is supported. Browsers should pull down config updates from time to time -- and needn't do it on demand (in the middle of a particular user request) if that would be a privacy concern.

Keeping the registration API surface light (i.e., base URL as the only param) also enables better future proofing for adding new feature expression via configs / manifest.json over time.

I will note that adding filters for specific Verifiable Credential types may have challenges, given the unbounded set size. Certainly being able to specify that a provider supports VCs at all or the ability to produce Verifiable Presentations (or perhaps provides other types of credentials / supports other features / protocols) could be of value. So there are some additional considerations around what is to be filtered and at what "levels" or granularity.

[samuelgoto]

I'd recommend that any sort of filters be provided / be updateable either through some .well-known config or manifest.json.

Ah, that would work too!

So, something along the lines of:

navigator.credentials.registerProvider("https://my-idp.example");

Which, as a convention, points towards something like:

https://my-idp.example/.well-known/tbd.json

Which could contain:

{
  "typesOfCredentialsICanProvide": [
    "UniversityDegree", "DriversLicense", "COVIDVaccine", 
  ]
}

Did I understand that right?

[dlongley]

@samuelgoto,

Did I understand that right?

Yes! Thanks.

[bvandersloot-mozilla]

I think a simple version of the bring-your-own IDP is interesting, where a user can use an arbitrary identity with a site. This would be akin to a wildcard in the provider list that searches through the users' preregistrations. This could be useful for RPs that need no guarantee of identity elements, just a unique identifier– especially if they don't want to deal with handling username-password management.

[samuelgoto]

Just to report back on this thread with an update, we started looking into this problem and building some prototypes to see where that takes us: Firefox seems initially supportive and it shows up in multiple places, e.g. https://github.com/fedidcg/FedCM/issues/374.

You can follow the prototype process and some early ideas on API design here: https://bugs.chromium.org/p/chromium/issues/detail?id=1406698.

[michielbdejong]

@samuelgoto It was great to discuss this in person last week at TPAC! I would love to help prototype the BYOIDP idea, I see it would have the following advantages:

• solve the NASCAR problem
• make it feasible to have thousands of acceptable IDPs, especially for instance in Research and Education
• support things like https://indieauth.com/ and "Log in with your WebID" (as used in https://solidproject.org) without requiring the user to type in the domain name of their IDP

[thhck]

Hello,

@janschill and I are Solid developers, and we believe this proposal would be a great feature for FedCM to integrate well with the Solid ecosystem.

We're considering working on a Proof of Concept to explore potential solutions and understand the practical challenges.

You can follow the prototype process and some early ideas on API design here: https://bugs.chromium.org/p/chromium/issues/detail?id=1406698.

@samuelgoto it seems that there has been no update since Feb 15. What is the status of the prototype?

Is anyone else currently working on it?

Otherwise, we are looking forward to the possibility of contributing to this effort, and we'd appreciate any guidance or feedback you could provide to help us get started.

[samuelgoto]

We're considering working on a Proof of Concept to explore potential solutions and understand the practical challenges.

I'd love to participate in this. Is there a call that I can join or maybe a document that I can read to learn more about what you have in mind?

@samuelgoto it seems that there has been no update since Feb 15. What is the status of the prototype?

We have a basic prototype working in chrome canaries that anyone can try.

We are currently blocked on getting feedback from developers if the current proposal meets needs and is a useful API.

Any chance you'd be willing to give this a go and let us know if it works the way you'd expect it to work?

Is anyone else currently working on it?

Not at the moment. Like I said, we feel blocked by meaningful developer's interest.

Otherwise, we are looking forward to the possibility of contributing to this effort, and we'd appreciate any guidance or feedback you could provide to help us get started.

I think one first concrete step we could take is getting a better sense of:

(a) what problem you currently have that you feel like this feature would help? (b) what alternatives you considered? (c) how many users/developers would benefit from this feature?

At the moment, we feel like this would be a great addition to FedCM, but we are really worried about implementing and shipping something that doesn't get enough use (and then, paying a maintenance price). We are willing to take risks, but that's currently what's holding us back moving forward, so the more data points you can give us about market demand the easier we can make this happen.

[thhck]

I'd love to participate in this. Is there a call that I can join or maybe a document that I can read to learn more about what you have in mind?

We want to improve user experience within the SoLiD ecosystem. Given the multitude of IdPs, it can be challenging for users often to recall their specific IdP. If browsers could display a list of previously used IdPs, it would significantly enhance the user experience and usability. We would love to dive deeper in this topic during a call. We also started working on a PoC.

We have a basic prototype working in chrome canaries that anyone can try.

We are currently blocked on getting feedback from developers if the current proposal meets needs and is a useful API.

Any chance you'd be willing to give this a go and let us know if it works the way you'd expect it to work?

We downloaded the latest version of chrome canary on MacOS activated the required flags ( including fedcm-idp-registration ) but we were not able to make it work. We didn't found the api call to register an IdP, and calling the following didn't gave us any result:

navigator.credentials.get({
  identity: {
    providers: [{
      registered: true 
    }]
  }
});

Is there any resources on how to make it work ?

(a) what problem you currently have that you feel this feature would help?

• To interact with an IdP, RPs must provide a text input where users can enter their IdP URL.
  • Users have to manually enter the IdP URL and need to remember it, ensuring they make no typos.
  • If a user has multiple IdPs, they must remember all the corresponding URLs.

(b) what alternatives you considered?

• We've thought about a browser extension, but it's not ideal because it needs to be installed on each browser.
• Field autocomplete was considered, but it doesn't offer an experience as seamless as the one FedCM provides.

(c) how many users/developers would benefit from this feature?

• It's difficult for us to estimate these numbers. Undoubtedly, this feature would be a significant improvement for the Solid ecosystem. However, I believe it would also be highly beneficial for larger and more mature decentralized communities ( I'm thinking of the Fediverse).

[npm1]

I'm not super familiar with the flag but I think the prototype is not usable yet. You can call IdentityProvider.register('configUrl') in an IDP context but it does nothing as far as I can tell.

[samuelgoto]

We want to improve user experience within the SoLiD ecosystem. Given the multitude of IdPs, it can be challenging for users often to recall their specific IdP. If browsers could display a list of previously used IdPs, it would significantly enhance the user experience and usability.

Can you expand on this a bit more (just intuition is fine, we don't need super hard data at this point)? How many IdPs are operating today within the Solid ecosystem? How many users a typical IdP have? How many solid RPs exist, and how often are they used?

We also started working on a PoC.

This is really neat, and typically a strong signal that browser vendors take to make an assessment of demand: are developers going out of their way to try to make this work.

Is there an open source implementation of Solid that we could use to build some of these prototypes?

We downloaded the latest version of chrome canary on MacOS activated the required flags ( including fedcm-idp-registration ) but we were not able to make it work. We didn't found the api call to register an IdP, and calling the following didn't gave us any result:

Ah, I think I'm still missing merging one more CL. Let me get that merged and report back to you here.

However, I believe it would also be highly beneficial for larger and more mature decentralized communities ( I'm thinking of the Fediverse).

Yeah, I share that intuition. But we really need to make sure that we are developing something that will be ultimately useful for users and developers, because the cost of development and maintenance is extremely high.

I think we'd be happy to move forward trying to complete prototypes and seeing where that takes us, but we are ultimately going to need a good set of developers who are excited about this before moving too far. Fair?

[samuelgoto]

@thhck I just merged a CL in chromium that implements some of the missing parts that you ran into. Can you try to use it in Chrome Canaries in a couple of days once it picks it up?

[janschill]

@samuelgoto I work with @thhck on this. I just tested this in Google Chrome Canary and it works.

I ran the demo IdP from @asr-enid with two IdPs, registered, logged into idp-1.localhost and in a Chrome console ran:

IdentityProvider.register('http://idp-1.localhost:8080/fedcm.json');

navigator.credentials.get({
  identity: {
    providers: [{
      nonce: "not-a-nonce",
      configURL: "http://idp-2.localhost:8080/fedcm.json",
      clientId: "yourClientID",
      registered: true
    }]
  }
});

The browser then successfully prompted me with "Sign in to idp-1.localhost with idp-1.localhost".

Thanks for getting this out.

[achimschloss]

I ran the demo IdP from @asr-enid with two IdPs, registered, logged into idp-1.localhost and in a Chrome console ran:

Great to see that this is useful beyond our own usage!

[samuelgoto]

@samuelgoto I work with @thhck on this. I just tested this in Google Chrome Canary and it works.

Can you try this again? The code snippet you sent feels off to me: you want to skip the configURL when using registered: true.

For example:

IdentityProvider.register('http://idp-1.localhost:8080/fedcm.json');

navigator.credentials.get({
  identity: {
    providers: [{
      nonce: "not-a-nonce",
      // comment out the following line, so that the browser can load accounts 
      // from registered IdPs rather than by configURL
      // configURL: "http://idp-2.localhost:8080/fedcm.json",
      clientId: "yourClientID",
      registered: true
    }]
  }
});

[janschill]

@samuelgoto yeah, that was also my understanding. I get this error though.

I am on Google Chrome Canary: Version 121.0.6153.0 (Official Build) canary (x86_64)

The FedCM prompt shows only after the last get call where I also provide the configURL, please note that it doesn't matter what the passed value is, it just seems that configURL is not an optional parameter in your implementation.

[samuelgoto]

@samuelgoto yeah, that was also my understanding. I get this error though.

Could you make sure you have the following flag enabled in your chrome canary instance?

chrome://flags/#fedcm-idp-registration

[janschill]

Yes, chrome://flags/#fedcm-idp-registration was enabled during my testing.

[samuelgoto]

The FedCM prompt shows only after the last get call where I also provide the configURL, please note that it doesn't matter what the passed value is, it just seems that configURL is not an optional parameter in your implementation.

Ah, I think there is a bug in the code. So, if you pass an empty string for configURL (this will validate that it won't be fetching from a passed configURL -- but it needs to be present, because there is a bug) it works?

For example:

navigator.credentials.get({
  identity: {
    providers: [{
      registered: true,
      configURL: "", // NOTE(goto): left deliberately empty because of a bug
      clientId: "yourClientID",
      nonce: "123",
    }]
  }
});

If so, yeah, that seems like a bug on my part.

I managed to reproduce it locally and I put together a CL to fix it.

[samuelgoto]

Ok, so it seems like you are more or less happy with the API surface.

Now, let's discuss the permission UX model.

I'm thinking we'd prompt the user to get some acknowledgement on IdentityProvider.register() because otherwise any random website that you have visited in the past could be calling IdentityProvider.register() to show up in the account chooser UI.

Something along the lines of Would you like to use {origin} as an Identity Provider?.

Does that make sense to you?

[samuelgoto]

On a related note, you probably got something wrong here in this screenshot: this is what we call the "mismatch UI".

You want to call in the IdP:

navigator.login.setStatus("logged-in");
IdentityProvider.register('http://idp-1.localhost:8080/fedcm.json');

And then in the RP:

navigator.credentials.get({
  identity: {
    providers: [{
      registered: true,
      configURL: "", // NOTE(goto): left deliberately empty because of a bug
      clientId: "yourClientID",
      nonce: "123",
    }]
  }
});

And you want to make sure that your accounts_endpoint is returning accounts, so that the browser can show an account chooser with the accounts that you are logged into in your IdP, as opposed to the error you you are seeing (which occurs when you have called navigator.login.setStatus("logged-in") AND you return no accounts in the accounts_endpoint).

[philsmart]

From the FedID CG call. @samuelgoto confirmed the plan would include a) a way to unregister an IdP (IdentityProvider.unregister), and b) The user can see the list of registered IdPs. All sensible, just recording for my understanding.

[philsmart]

Just wondering if there would be a way to use any registered IdP, but from a known set of trusted IdPs (trusted by the RP)?

[samuelgoto]

I managed to reproduce it locally and I put together a CL to fix it.

I merged this CL recently, so this specific bug should be fixed in canaries at the moment. Please take another and let me know if this is behaving how you'd expect.

[samuelgoto]

Now, let's discuss the permission UX model. I'm thinking we'd prompt the user to get some acknowledgement on IdentityProvider.register() because otherwise any random website that you have visited in the past could be calling IdentityProvider.register() to show up in the account chooser UI. Something along the lines of Would you like to use {origin} as an Identity Provider?. Does that make sense to you?

I continue to make forward progress on this problem. Here is one formulation I'm starting to play with:

WDYT?

[samuelgoto]

Just wondering if there would be a way to use any registered IdP, but from a known set of trusted IdPs (trusted by the RP)?

Ah yeah, that occurred to me to @philsmart ! I was thinking maybe the RP can specify a public key, that must have been used to allow the IdP to register itself against it.

Something along the lines of:

await IdentityProvider.register({
  configURL: "...",
  federation: "https://federation-provider.org",
  proof: "...", // proves that it can be part of the specific "foobar" federation
});

Which then the RP can request the browser for only things that match that public key:

await navigator.credentials.get({
  identity: {
    providers: [{
     federation: "https://federation-provider.org"
    }]
  }
});

WDYT?

I'm sure that we are going to find better mechanisms, but does this give you a sense that this is a solvable problem given enough energy?

[philsmart]

Hi @samuelgoto, GitHub did not notify me of this update, sorry about that. I'll have a think.

[philsmart]

Hi @samuelgoto, thanks for thinking about this use case (a known set of trusted IdPs) and suggesting a way forward. These are my thoughts:

• The filtering of IdPs suggested here might be similar to Trust Information inside SAML metadata (yet to be standardised). That is, filtering IdP selection by federation, by entity category, by assurance certification, or by 'some' category of information. This is certainly a useful feature.
• Also, there maybe some analogue with OID4VP's Support for federation trust schemes (OpenID for Verifiable Presentations - draft 20)
• The proof seems tricky:
  • I am not sure what kind of proof could be self-asserted by the Identity Provider that would prove federation membership. Some kind of attestation.
  • Something signed by the IdP which the browser would need to verify by accessing trusted public keys of IdPs from the federation they assert membership of. Or something similar: but in each case I think the browser would need to look something up, or hold something (keys) to do this?
• Smaller observations:
  • How would they re-register with different federations if they change
  • The IdP could be removed from a federation: the proof would need to be evaluated on each FedCM invocation.

[cbiesinger]

Hi Phil, I have another question for you -- do you envision that an IDP would register itself in response to a user interaction (e.g. click "Register" or something), or do you expect that they would register themselves automatically upon login?

[philsmart]

In the simple case, upon login would be less disruptive to current user flows. I guess the IdP would be in control of when that API was called?

[cbiesinger]

Yes, the IDP would be in control of that, but we were wondering whether we need to/should allow calling the API without a user gesture

[philsmart]

Ah, I see. So yes, I think the possibility of triggering that consent box without a user gesture makes sense. This would provide a more seamless experience in an IdP-initiated login flow.

I guess it (registration in general) does mean you would be excluding possible IdPs when trying to access an SP (from that SP) if you have not yet visited the IdP and registered it in some way.

[philsmart]

Looking through the RP call. It is possible (or even likely) that the RP would need to present a different client_id to each registered IdP. I am not sure how that is represented/signalled.

[achimschloss]

You can specify a nonce and client_id per IDP if I'm not mistaken

[philsmart]

Hi @asr-enid, I was thinking specifically about the registered set of IdPs. My understanding was the following:

providers: [{
      registered: true,
      configURL: "", // NOTE(goto): left deliberately empty because of a bug
      clientId: "yourClientID",
      nonce: "123",
    }]

Would potentially show accounts from any 'registered' IdP (like a wildcard). If so, you would not know which client_id and nonce to use for each registered IdP. I've probably missed something.

It is also feasible to use the same client_id of course (esp. in a multi-lateral federation context).

[achimschloss]

Would potentially show accounts from any 'registered' IdP (like a wildcard). If so, you would not know which client_id and nonce to use for each registered IdP. However, I've probably missed something. It is also feasible to use the same client_id of course (esp. in a multi-lateral federation context).

Gotcha - good question. Depends on how the federation (or the lack of any RP/IDP relation) comes into play

[cbiesinger]

I don't think it's realistically possible to provide a different clientID per-IDP when the set of possible IDPs is unknown to the RP? Or do you have a proposal for how to do this / what you would like to see?

[philsmart]

No, you're right. If it (IdP) wants to just respond to any RP with 'some kind' of token, it does not need the client_id. And it always has the origin if it wanted to make some kind of trust descision.

Otherwise, I can not easily see how to do this without privacy issues i.e. allowing the RP to list the registered IdPs before calling 'get'. Alternatively, FedCM would need to return the user-chosen IdP to the RP—to form a more specific request—before it queries the assertions endpoint: which is fundamentally different from how it works now.

[julianfoad]

Four "Acknowledged Challenges" are listed at the end of the initial proposal in this issue. Could someone annotate those with links to any discussions or solutions, to show progress?

[julianfoad]

I blogged about this issue: FedCM: Sign-In-With-Big-Tech-Only or Sign-In-With-Whom-I-Prefer? with this image:

Feel free to boost/repost the blog and share/improve the image. I hope this is of some use.

[elf-pavlik]

I would like to understand better how the token / credential / assertion is supposed to work.

https://fedidcg.github.io/FedCM/#dom-identityprovidertoken-token

The content of the token is opaque to the user agent and can contain anything that the IDP would like to pass to the RP to facilitate the login. For this reason the RP is expected to be the party responsible for validating the token passed along from the IDP using the appropriate token validation algorithms defined. One example of how this might be done is defined in OIDC Connect Core § IDTokenValidation.

While the set of possible tokens can be left open, at least a few most common ones should be defined—for example OIDC Id Token or its VC equivalent.

I would also like to know if someone has been considering the feature of having the token issued by IdP be optional sender constrained (bound) to the RP. In Solid-OIDC we currently have a requirement of the OIDC Id Token to be bound to the RP, at this moment we rely on DPoP. I would like to hear if a requirement to have possibility of sender constraining the issued token came up already. To clarify, in Solid-OIDC, the RP pushes sender-constrained Id Token to different UMA AS since users have Resource Servers independent from the RP.

[npm1]

For the first question about token types, would the scopes addition (see https://github.com/fedidcg/FedCM/issues/477) suffice? For the second question, is it correct that the system currently relies on two fetches based on https://www.rfc-editor.org/rfc/rfc9449.html#name-concept? If so, are both credentialed/require the IDP cookies?