Add "filter" mode to FedCM enabling dynamic OP discovery based on criteria

[yaron-zehavi]

This proposal suggests using OIDC-Fed trust anchor's trust_marked_entities_listing_endpoint
https://openid.bitbucket.io/connect/openid-federation-1_0.html#name-trust-marked-entities-listi

To retrieve OPs matching RP's criteria such as (OIDC-IDA) trust_frameworks, for example - a BankID, an aml compliant ID or government certified ID.

See proposal doc here
https://docs.google.com/document/d/1pycQaYBgr3O-0En3fugrU6kEctSNWjLVAbUh_1_cXMc/edit?usp=sharing

[samuelgoto]

Ha, that's an interesting idea!

See proposal doc here
https://docs.google.com/document/d/1pycQaYBgr3O-0En3fugrU6kEctSNWjLVAbUh_1_cXMc/edit?usp=sharing

Request access!

[samuelgoto]

Request access!

I skimmed through this and I think it is a pretty compelling idea.

But I couldn't stop but thinking: isn't this already accomplishable without requiring any changes to the browser?

By that I mean, can't you call FedCM in the following way:

// Fetches the publicly available data about the federation:
const list = await fetch("https://example.ia.com/openid_provider/eidas/substantial");
// Parses it
const federation = await list.json();

const credential = await navigator.credentials.get({
  identity: {
    // maps each entity in the federation to a provider
    providers: federation.map((provider) => {
        return {
           configURL: `${provider}/.well-known/web-identity`,
           clientId: window.location.origin,
           nonce: nonce,
           // ...
        }
    })
  }
});  

FedCM only makes requests to IdP that you are logged in to (through the Login Status API), so even if you pass 5 thousand IdPs here, we would only make requests to the ones that you are logged into (which, hopefully, is a manageable size).

WDYT?

[yaron-zehavi]

Thanks for your interest, prompt response and kind words :-)

Fetching a list of IDPs from specific trust anchors / intermediate authorities is of course possible, but I think the intended vision equates Trust Anchors (TAs) to that of CAs managed in Trust Stores (Input from Giuseppe Di Marco co-author of OIDC-FED). Therefore TAs better be pre-configured (curated), while allowing explicit overriding. This also keeps RPs burden light when they don't need to know TAs/IAs (there may be multiple IAs providing same trust marks such as 27 national EU eIDAS IAs).

Regarding Logged in state, high-assurance IDPs (e.g: eIDAS, banks) are required by EU PSD2 regulation to logout users after short idle times (5 minutes). So unlike "social IDPs" they are not allowed to keep users logged-in and therefore Login Status is a concept contradicting regulatory frameworks. See: https://www.commerzbank.com/portal/en/fi/de/system-1/zahlungsdiensterichtlinie_2.html

But perhaps instead of logged-in state, FedCM could get guidance which IDPs are related to the user-agent.
This can be accomplished for example by IDPs setting a long-lived cookie following a standard name once they've been logged into.

Filtered eligible IDPs would be shown by FedCM if previously used by user-agent.
We'd need to support end-users who MAY access an eligible IDP but haven't yet done so this user-agent, so a cookie is not present. Perhaps "Show more" button + text search to display eligible IDPs that were not previously shown

[philsmart]

I agree with the last point. In research and education federations, many logins are initiated from the RP before the end-user has authenticated to their IdP and, therefore, before the login status has been set.

[dwaite]

I agree with the last point. In research and education federations, many logins are initiated from the RP before the end-user has authenticated to their IdP and, therefore, before the login status has been set.

In education at least, this is thousands of individual IDPs. I suspect when we get to trust frameworks with a large and dynamically changing membership, the unauthenticated "IDP picker" UX will still be best served by web content that can do things like provide hierarchal navigation and location-based suggestions.

[yaron-zehavi]

@dwaite what do you think about the proposal that IDPs shall set a long-lived (not HttpOnly) cookie in a standard name once a user has been logged into that IDP, to be detected by FedCM as a guidance for further filtering the "IDP picker" UX?

[dwaite]

Fetching a list of IDPs from specific trust anchors / intermediate authorities is of course possible, but I think the intended vision equates Trust Anchors (TAs) to that of CAs managed in Trust Stores (Input from Giuseppe Di Marco co-author of OIDC-FED). Therefore TAs better be pre-configured (curated), while allowing explicit overriding. This also keeps RPs burden light when they don't need to know TAs/IAs (there may be multiple IAs providing same trust marks such as 27 national EU eIDAS IAs).

Pre-configured where? There can be an unlimited number of large and small, independent, overlapping federations. Multiple trust anchors also exists to allow for them to represent entity participation in independent federations.

I would not expect a user agent to maintain a cache of the membership of a federation unless it was part of that trust framework and such data was core to its operation.

I've seen applications still apply allow/deny lists based on their own local policy - for example, a commercial service which will only allow educational users from institutions that are paying customers.

The equation is changed when discussing (out of scope) identity credentials. The relationships are more unilateral, with less expectation of credentials with services are assurances around attributes being provided as part of a financial arrangement. There may be an additional specialized user agent (a wallet) specifically for certain kinds of credentials and may exist under the same trust framework, rather than a browser adding additional generalized functionality for IDP websites. These both greatly increase the likelihood that broad trust mark requirements will be sufficient in a (verifier) request.

[dwaite]

@dwaite what do you think about the proposal that IDPs shall set a long-lived (not HttpOnly) cookie in a standard name once a user has been logged into that IDP, to be detected by FedCM as a guidance for further filtering the "IDP picker" UX?

Hopefully we are at a stage where any requirements solved by such a cookie could be input into the Login Status API

[yaron-zehavi]

@dwaite what do you think about the proposal that IDPs shall set a long-lived (not HttpOnly) cookie in a standard name once a user has been logged into that IDP, to be detected by FedCM as a guidance for further filtering the "IDP picker" UX?

Hopefully we are at a stage where any requirements solved by such a cookie could be input into the Login Status API

Do I understand correctly that IDP will be responsible to set it's Login Status value per user-agent? If so the cookie is not needed, it's sole purpose was to indicate past-visited IDPs to the user-agent. I would then suggest FedCM offers to users also IDPs in Logged-Out state

[yaron-zehavi]

Fetching a list of IDPs from specific trust anchors / intermediate authorities is of course possible, but I think the intended vision equates Trust Anchors (TAs) to that of CAs managed in Trust Stores (Input from Giuseppe Di Marco co-author of OIDC-FED). Therefore TAs better be pre-configured (curated), while allowing explicit overriding. This also keeps RPs burden light when they don't need to know TAs/IAs (there may be multiple IAs providing same trust marks such as 27 national EU eIDAS IAs).

Pre-configured where? There can be an unlimited number of large and small, independent, overlapping federations. Multiple trust anchors also exists to allow for them to represent entity participation in independent federations.

I would not expect a user agent to maintain a cache of the membership of a federation unless it was part of that trust framework and such data was core to its operation.

I've seen applications still apply allow/deny lists based on their own local policy - for example, a commercial service which will only allow educational users from institutions that are paying customers.

The equation is changed when discussing (out of scope) identity credentials. The relationships are more unilateral, with less expectation of credentials with services are assurances around attributes being provided as part of a financial arrangement. There may be an additional specialized user agent (a wallet) specifically for certain kinds of credentials and may exist under the same trust framework, rather than a browser adding additional generalized functionality for IDP websites. These both greatly increase the likelihood that broad trust mark requirements will be sufficient in a (verifier) request.

I'm indeed coming from broader use identity credentials, in the vision of the GAIN initiative where a relying party doesn't need knowledge of specific IDPs and can dynamically locate them and establish trust. Perhaps FedCM could support general purpose trust anchors (pre-curated) as well as overriding with case-specific trust anchors for closed-use federations as you mentioned.
I'm thinking more in the direction of retailers that can benefit from assured identity but don't want to onboard with 30+ assured identity providers across the globe, and don't want to limit this capability by assuming where their customers reside and which specific trust framework can provide identity assurance. Hence FedCM can serve to dynamically establish the trust with eligible IDPs.

[yaron-zehavi]

federation.map((provider) => {
        return {
           configURL: `${provider}/.well-known/web-identity`,
           clientId: window.location.origin,
           nonce: nonce,
           // ...

I accept your proposal @samuelgoto and modified my document accordingly.
https://docs.google.com/document/d/1pycQaYBgr3O-0En3fugrU6kEctSNWjLVAbUh_1_cXMc/edit

Therefore I'm asking FedCM to:

• Present OPs previously used on user-agent (Login Status API returns Logged-In or Logged-Out)
• Presumably using accounts_endpoint of Logged-Out OPs will not work, so they can be shown as “Sign in using {{OP}}��
• Offer a way to choose eligible OPs not yet known to user-agent (Login Status API returns “Unknown”)

[samuelgoto]

FedCM could support general purpose trust anchors (pre-curated)

I'm still stuck on two questions:

1. isn't this best done in userland than in browserland? that is, isn't this already possible without any modification? and
2. who needs this? which specific and real RPs and IdPs are blocked on this specific problem to be solved? do you, @yaron-zehavi , control enough of the RPs and IdPs such that, if we made this change, we would actually manage to enable this ecosystem?

Maybe you could coordinate with @hlflanagan and join one of the FedID CG calls someday to walk us through your production deployment, the problem you are trying to solve and your proposal?

[yaron-zehavi]

FedCM could support general purpose trust anchors (pre-curated)

I'm still stuck on two questions:

1. isn't this best done in userland than in browserland? that is, isn't this already possible without any modification? and
2. who needs this? which specific and real RPs and IdPs are blocked on this specific problem to be solved? do you, @yaron-zehavi , control enough of the RPs and IdPs such that, if we made this change, we would actually manage to enable this ecosystem?

Maybe you could coordinate with @hlflanagan and join one of the FedID CG calls someday to walk us through your production deployment, the problem you are trying to solve and your proposal?

1. I changed my proposal adopting your suggestion that RP invokes OIDC-Fed on its own to discover eligible OPs prior to using FedCM. So that's no longer an ask from browserland. The required modification from FedCM is to support presenting also logged-out OPs (perhaps by default not, but can be overridden by a new request parameter)
2. This is needed to facilitate discovery of eligible OPs, by RPs operating at internet scale across many geographies having identity assurance requirements but not wanting to manage cumbersome overloaded login selector UIs. Imagine a telco provider operating across Europe or global hospitality platforms. OIDC-Fed allows them to discover eligible OPs and establish trust. FedCM can enable presenting users with valid login choices, filtered to those they normally use. Supporting OPs Logged-Out status enables showing strict-security OPs who log-out idle users (e.g government eID and banks), and not removing them because they're not in Logged-In state.

I'm from a group of banks, so represent ~12 IDPs. While not controlling any RPs, we're engaged in discussion with several large retailers and this requirement could be a great enabler for them. Happy to join FedID CG calls, I'll reach out

[samuelgoto]

The required modification from FedCM is to support presenting also logged-out OPs (perhaps by default not, but can be overridden by a new request parameter)

I think that's a duplicate request of #575. Would this suffice?

I'm from a group of banks, so represent ~12 IDPs. While not controlling any RPs, we're engaged in discussion with several large retailers and this requirement could be a great enabler for them.

Can you help me understand if this is actually blocking you? That is, isn't there an intermediate step that you could take (showing only for logged-in users) to get the ball rolling, so that we can have a stronger signal of evidence of demand from you?

There are only so many things that we can pick up to do, so we hold a high bar in gathering evidence of developer demand (e.g. we avoid working on hypothetical problems that doesn't materialize into concrete usage by users and developers), which we typically test by requiring deployments (e.g. a prototype behind a flag?) that shows us precisely what's missing.

Happy to join FedID CG calls, I'll reach out.

That's great to hear. Yeah, please do reach out to @hlflanagan and try to come so that we could get a sense of whether this is actually blocking you.

[yaron-zehavi]

The required modification from FedCM is to support presenting also logged-out OPs (perhaps by default not, but can be overridden by a new request parameter)

I think that's a duplicate request of #575. Would this suffice?

It's a bit more related to #442 which proposes an RP provided flag determining affordance for not logged-in users

I'm from a group of banks, so represent ~12 IDPs. While not controlling any RPs, we're engaged in discussion with several large retailers and this requirement could be a great enabler for them.

Can you help me understand if this is actually blocking you? That is, isn't there an intermediate step that you could take (showing only for logged-in users) to get the ball rolling, so that we can have a stronger signal of evidence of demand from you?

IDPs could keep user-agents in permanent logged-in status, which would prevent them being omitted. But it's not RP controlled and semantically incorrect so might cause issues down the line.

There are only so many things that we can pick up to do, so we hold a high bar in gathering evidence of developer demand (e.g. we avoid working on hypothetical problems that doesn't materialize into concrete usage by users and developers), which we typically test by requiring deployments (e.g. a prototype behind a flag?) that shows us precisely what's missing.

Happy to join FedID CG calls, I'll reach out.

That's great to hear. Yeah, please do reach out to @hlflanagan and try to come so that we could get a sense of whether this is actually blocking you.

[yaron-zehavi]

I think the workaround for providers requiring short lived user sessions is retaining browser's Logged-in state despite session's expiration. This causes FedCM to include the provider and when accounts_endpoint returns HTTP 401 the user is offered to login.

Perhaps we can close this issue, depending on how stable is the browser's Logged-in. e.g: what can cause it to change outside of provider's control?