IdP requires knowlege of RP to allow a session

[hlflanagan]

In some cases, an IdP needs to know who the RP is in order to actually allow a session. Below are two screenshots of a SAML use case where a user is trying to log into the Feide IdP from two different RPs.

RP does not have a relationship with the IdP:

RP does have a relationship with the IdP:

To replicate where the RP does not have a relationship with the IdP:

1. Go to https://edusign.sunet.se/ and click on "Access through your institution"
2. Type in "Oslo" and select "Feide"

To replicate where the RP does have a relationship with the IdP:

1. Go to https://iopscience.iop.org/article/10.35848/1882-0786/abdcd7 and click on "Access through your institution"
2. Type in "Oslo" and select "Feide"

[David-Chadwick]

We are addressing a similar use case using OpenID4VCs. In this scenario, a user with VCs in their wallet from any OP(i.e. VC issuer) should be able to sent their VCs to any RP anywhere in the world. If all three are part of the same trust federation then this is easy to engineer as the wallet can determine that the RP is trusted, but when they are not, GAIN is devising a solution in which the federations can interwork via the OpenID Federation specification so that the entities can still determine if the others are trusted or not. But what if the RP and OP do not share either a federation or GAIN. Then our wallet pops up a message to the user "Warning this RP cannot be trusted. Do you want to continue". This is analogous to a browser finding a faulty TLS PKC and informing the user of such, allowing the user to either cease communicating with the web site, or to proceed regardless. In this way the VC eco-system should be able avoid the situation that occurs today in FIM systems as described in this issue.

[npm1]

We've been thinking about adding a parameter to the client_metadata_endpoint to allow the IDP to disallow FedCM on the relevant RP. We had thought that a disallowed RP would not see anything FedCM related, but it could be possible to show some error message if there is a need for that.

[timcappalli]

Just to further clarify (and recap the discussion at IIW), many large, multi-tenant IdPs require some kind of context in order to establish a session (aka drop an IdP cookie). Typically this is a client_id or some other parameter.

Depending on the platform, a "naked" request will either be rejected, or a default client_id will be assumed (such as the primary application of that provider or an account management portal).

We should consider having some kind of scoped cookie that an IdP can drop that is only valid for FedCM to list accounts/sessions. We should also consider having some kind of client_id that the browser can use when trying to establish a session with the IdP. It could be as simple as the hostname of the browser's primary website or something more concrete like a URN.

[npm1]

At first glance this looked a bit different from the IIW discussion. Note that it is not acceptable for the IDP to have both the first party cookies as well as some identifier of the RP before any user interaction since this would enable cross-site tracking.

I don't follow your scoped cookie idea. Can you elaborate when it would be set and when it could be read, and how it would be keyed? Re client id, it is already part of the FedCM flow.

[bvandersloot-mozilla]

One alternative that I support is requiring user consent to the IDP before sending the AccountList request. This would free up the ability to send a referer and credentials to the IDP at that point.

[cbiesinger]

Even with user consent, I would prefer not to send the RP to the accounts list endpoint; that is a tracking vector that has no good purpose IMO since we could handle this with special handling in the clientmd endpoint that is not credentialed.

It would also prevent potential future work on caching the accounts list.