idp-sp-storage API

[sunetzacharias]

Proposal Summary: idp-sp-storage API

The problem we met to solve is how browsers can help prevent hidden tracking without breaking federation protocols for Research and Education federations. Our hope is that this scenario could be more broadly implemented for other federated use cases.

The RP, the browser, the IdP, and the user all need to own a piece of the consent that suggests the user is aware of and accepts that an authentication flow is about to happen. If this is done by interrupting the actual protocol flow, certain scenarios (e.g., when the IdP must know who the RP is before responding with a response that will allow the user to progress) will fail.

The group did not focus on third-party cookies specifically; the focus was on how to enable browser-level consent without breaking the protocol, regardless of the primitives being used. This means that this proposal might solve not only for third-party cookies but also for future issues with link decoration (aka, navigation-based tracking) and redirects (aka, bounce tracking).

Research & Education have tools and services, particularly federation operators that provide governance to the federation system, that we considered leveraging as part of the way to move from a consent model that focuses solely on gaining the user’s consent for a transaction to a classification model that allows the browser to differentiate between a federated authentication flow and a tracking flow. Consent can still be included, but by classifying the action correctly, the user experience should be much simpler.

The scenario in this proposal assumes that the metadata provided by the Relying Party to the browser will allow the browser to both classify the flow and provide a common UX for further IdP discovery (aka, resolve the NASCAR problem).

For more background see [20230309 Background for proposals]

We propose a javascript API for authorizing a set of mappings between an SP and an IdP in the browser. The data that defines the SP and IdP in the API calls defined below (e.g. n.c.allowed.put) is either the ORIGIN of the SP/IdP or a signed data structure which includes one or more of the URLs which the IdP has configured as the authorized location(s) to which the authentication response may be returned for a specific SP. Note that current authentication protocols have a limited list of permitted URLs that may be used by an SP; the SP must assert URLs from that list.

The data that defines the IdP is, similarly, either the ORIGIN or a signed data structure which includes the URL the SP will use (via the appropriate protocol binding) to make its request, and a URL for UX information that is in the same ORIGIN as the IdP. The .well-known/ location cannot be used for this purpose as many IdPs for different organizations may be hosted at the same ORIGIN. By requiring this URL to be at the same ORIGIN as the authentication endpoint the SP cannot insert misleading data. In the absence of an SP-asserted UX endpoint the .well-known location could be used. In the absence of a .well-known endpoint the URL could be presented to the user.

By using a signed data structure, instead of simply specifying the ORIGIN, the caller can include additional information used to drive the UX–such as the human-friendly and/or localized name of the IdP/SP. The signed data structure is submitted, along with a proof of membership of the public key, in a recognized transparency log allowing the browser to validate the origin of the data.

Calls to the API will trigger browser-provided UX at certain stages to ensure that the user is aware that a mapping exists between the SP and the IdP. The browser will use this mapping – including the SP and IdP endpoints used in identity protocol flows – to allow interaction between these endpoints which would otherwise not be permitted. (That is: future bounce tracking and other cross domain exchanges that appear to be tracking data.)

Privacy threat model

There are 3 actors involved in the standard federated identity exchange:

1. The Identity Provider (IdP). The IdP has information about associated users and can upon request create an assertion (aka claim-set). Each claim-set is created specifically for transfer to a single service provider (cf below) in response to an authentication request.
2. The Service Provider (SP). The SP represents a service that wants to authenticate users and get access to attributes (claims) about the authenticated user.
3. The user-agent that mediates the protocol flow between the IdP and SP.

The following is a brief description of a typical authentication flow using the most common protocol bindings for SAML. OIDC is quite similar.

1. The user expresses an interest to authenticate at a service provider. This typically involves a user gesture such as clicking a button marked “Login”.
2. The SP creates a user flow, the purpose of which is to determine which IdP the user wants to use. This flow creates information at the user-agent about which IdP the user believes themselves to be associated with. Minimally this information is a public identifier of the IdP (eg a URI). NB that this is not the same thing as account information which typically involves information about the user and not only information about the IdP. In point of fact the information created in this step is equivalent to information about an affiliation between the user agent and the IdP.
3. The SP creates an authentication request and directs the user-agent to send the authentication requests as a URI parameter in a GET request to the IdP. The authentication request is sometimes encrypted to the IdP and may contain sensitive information about the authentication that is taking place. For instance when the user is involved in a financial transaction the authentication request may contain summary information for display by the IdP about the nature of the transaction. The information in the authentication request (if encrypted) must be protected from the user-agent and other AITM.
4. The IdP presents UX to the user prompting them to authenticate. After successful authentication the IdP creates a set of claims encrypted with the SP public key. The user-agent is directed to POST the encoded and encrypted claims to the SP. In this step the set of claims may contain information about the user which the user may not themselves have access to. By encrypting the set of claims to the SP the claims are protected against the user-agent and AITM.
5. The SP unpacks the claims and decrypts them with its private key. At this state the SP has access to the claims the IdP sent. These claims are not necessarily equivalent to account information in the traditional sense. In many cases the only claim provided is detailed information about the affiliation of the user and some organizations (eg that they are students at a certain university) but no further information may be provided. The information in the claims are not necessarily available to the user-agent at this stage either since they are POSTed to the ORIGIN.

In summary:

• User information is never made available to the user-agent unless by the SP after a successful authentication response has been received by the IDP
• The only information needed to start the flow is the users choice of IdP which does not involve any user information beyond the belief (by the user) that they have an association with the IdP
• Authenticated information about the user is controlled by the IdP and created specifically for a particular transaction with a particular SP
• The user-agent is never privy to any information exchanged between the SP and the IdP.
• Both the authentication request and response may contain sensitive information which must not be shared with the user-agent.

API calls n.c.allowed.isEmpty(<sp>) -> Boolean

Returns true if there are no objects associated with . This is called the unconfigured state for the .

n.c.allowed.put(<sp>, <idp>, [<ttl>]) -> Promise<IdP>

The browser prompts the user to allow the - mapping to be authorized. If the user agrees, the mapping between and is stored. Optionally this mapping expires after time-to-live . If the user authorizes the mapping the Promise resolves with the choice, allowing the calling page to invoke the login flow for the chosen . Alternatively, if the user denies the mapping the Promise resolves as an error which can be handled in an exception flow by the caller.

n.c.allowed.invoke(<sp>) -> Promise<IdP>

The invoke method displays a UX allowing the user to select one among the ones already associated with (from a previous n.c.allowed.put call). When the user has chosen, the Promise resolves with the object. The user should be given the choice to not invoke any of the existing objects and have the UX behave as if it is in the unconfigured state for . This is signaled by resolving the Promise as an error which can be handled in an exception flow by the caller.

n.c.allowed.get(<sp>) -> Promise<[IdP]>

The get method returns a list of the objects associated with the object. This API call will throw an exception through the Promise if called outside of a Chrome [fenced frame] (or equivalent code-execution sandbox in other browser engines). This allows an SP-supplied (not browser-provided) UX (in a sandbox) to be presented, which is not visible to the SP, but allows cross-origin resources, etc.

n.c.allowed.deleteAll(<sp>)

Delete all for this .

n.c.allowed.delete(<sp>, <idp>)

Delete this particular - pair.

What is the Expected RP (or IDP Library) Developer Experience?

An RP would either call a SAML or OIDC discovery service that calls the API or would call the API directly on the SP page.

What is the Expected IDP Developer Experience?

This proposal does not impact any of the current identity protocols.

What is the Expected User Experience?

Code executing on the page will call n.c.allowed.put(<sp>,<idp>) which would cause the user to be prompted to allow the <idp> to be authorized for use by the page associated with <sp>. The <idp> and <sp> are expected to be objects representing “metadata” for the two entities. The UX is expected to be similar to current credit card autofill behaviour. When the calling page wants to use the mapping it calls n.c.allowed.invoke(<sp>) which prompts the user to select among the existing stored <idp>-objects associated with the <sp>object.

The following pseudocode outlines the different API calls in use by the SP in the process of connecting the user to their IdP. The embedded STOP signals where the proposed new flow terminates and moves to existing protocol behavior.

1. SP wants to invoke SSO protocol a. SP knows the IdP it wants to use, so it calls n.c.allowed.put(<sp>, <idp>, [<ttl>]) to request consent for establishing that linkage and permission to invoke SSO. i. On error, go to b, otherwise proceed with SSO protocol. STOP b. SP does not know the IdP to use. i. SP calls n.c.allowed.isEmpty(<sp>) to check for existing relationships to reuse.
   1. If true, go to ii
   2. If false, SP may call n.c.allowed.invoke(<sp>) to attempt browser-mediated reuse of an IdP choice. a. If error, go to ii, otherwise proceed with SSO protocol. STOP ii. SP invokes a protocol and community appropriate Discovery Service (either embedded or external) using existing discovery protocol.
      1. Discovery service pattern out of scope of this document, go to 2.
2. DS returns IdP choice to SP’s discovery endpoint a. SP now knows the IdP it wants to use, so it calls n.c.allowed.put(<sp>, <idp>, [<ttl>])to request consent for establishing that linkage and permission to invoke SSO i. On error (either IdP refuses or user rejects registering the IdP chosen) repeat discovery of a suitable IdP. Otherwise proceed with SSO protocol. STOP

Regarding discovery, this narrative assumes discovery may be embedded within SP or shared, but is not formally part of the browser apart from the “invoke” option to select from an existing set of relationships (not select new ones). This would obviate the need for a shared discovery service to ever retain state/choices since that would be managed by the browser alone and reused via n.c.allowed.invoke.

In a typical case, a user would be forced through discovery once, pick their IdP and establish the connection for some TTL, then reuse it via the ç method until it expires; discovery would be bypassed entirely by the SP for that TTL period. Multiple IdPs works fine, allowing that additional trips through discovery and the n.c.allowed.put call (to obtain consent) would occur. The user would have to select “none of the above” after n.c.allowed.invokeis called to make that happen.

Open questions

• What UI “sprinkles” are meaningful to add to the UX when/if there is out of band knowledge about the trust status of the and/or .
• Represent some version of the “context” label in the API to enable groups of SPs to enable a mechanism for buckets of ’s to share their mapping.
• Would a user be able to map an unlimited number of IdP / SP connections?
• How does the browser know when to ask for user’s consent?
• Would this process mean that the user can potentially approve of a connection with a malicious SP, one that’s not trusted by their IdP? In what way does this system preserve the existing trust infrastructure?

Out of scope

Consuming federation trust elements (e.g. metadata or public keys) is explicitly out of scope for this proposal however it is possible to combine this proposal with additional signals based on out-of-band import of metadata.

Flows

1. Brand new computer / session, never used SP or IdP
2. Coming back to the SP and reuse a used IdP
3. Going to a brand new IdP

An account management module for editing and removing - for federated accounts

[philsmart]

Hello! It is not clear to me what the difference is between n.c.allowed.get and n.c.allowed.invoke. More specifically, what I would use get for.

Also, the sequence diagram for this shows a flow that involves some kind of embedded discovery service (and I assume is limited to an embedded type). That is not clearly reflected in the test. For example, if the SP is in an unconfigured state, a first step could be to initiate discovery before the put API is called?

[philsmart]

Allowing for IdP-Initiated SSO. It might be useful to have a similar call to n.c.allowed.isEmpty but taking an IdP and SP combination. Just as a way for the IdP to know if it needs to call put again i.e. put is probably redudant if the IdP and SP already have a relationship in the browser.

[leifj]

Thinking about this after our workshop I suspect we may need some trust component in this case aswell to make the UX work reasonably well.

As it stands the IdP and SP are represented essentially by their respective ORIGIN but in order to support human-friendly naming, branding elements and - equally importantly - multiple protocol endpoints per IdP/SP it is probably necessary to authenticate the binding between ORIGIN and any additional data needed to produce good UX.

This is exactly what SAML and OIDC metadata does today but trusting the caller to provide this data opens the way for a rogue SP to provide false endpoints thereby tricking a user into a flow that leads to tracking. The solution could be to introduce some form of trust anchor (eg the federation operator) that can authenticate data associated with the SP and IdP.

[leifj]

it may be possible to support a simple version of the api which only takes ORIGIN (sp and idp) as input without introducing external trust but at the expense of the UX only being able to display the ORIGIN. In the mockups above the name of the University would be replaced by its URL.

[sunetzacharias]

added judielaine's flowchart diagram that was also agreed by the participants at the meeting

[meshna]

Adding steps in authentication process is the opposite of seamless. It's not user-friendly; it's frustrating. There are already so many steps that users have to go through (multiple results in WAYF, IdP's MFA, questions at SP's side, popups asking for rating, updates, etc.). This was meant to be seamless access.

If we ask a user to take action then it needs to make sense to them, and in such situation the user is not making an informed choice, they're just feeding the browser so it lets them pass. It's not even a choice. 99,99% of all users will have no clue what's going on, they can't possibly know whether the SP is to be trusted or not or whether their choice was the right one (before they actually authenticate). And if they do make the wrong choice in haste, then what?

There's already an existing trust infrastructure that has been established for this purpose and we should utilize that.

This could perhaps be a fallback for when the existing trust infrastructure isn't in place, for bilateral connections. It still won't be user friendly but at least it would be needed.

[timcappalli]

It would be very helpful if you could add an intro section that talks about both the user journey and problem statement before diving into a proposed solution. For example, "A university student wants to access a research paper from research.org. Their university is part of a federation that provides access to research.org... blah blah". Ideally the problem statement would highlight the issues you're facing today and the issues you think you'll be facing tomorrow (3PCD, link decoration, etc).

[windhamg]

Hello! It is not clear to me what the difference is between n.c.allowed.get and n.c.allowed.invoke. More specifically, what I would use get for.

@philsmart The idea here is that n.c.allowed.get would return the list of IdP objects associated with the SP, so that a chooser UI element (a la seamlessaccess) can be presented. When an IdP is selected from that chooser, n.c.allowed.invoke is called, which presents a browser-generated permission modal ("do you want to sign-in with XYZ IdP?") and returns a Promise that resolves to either the selected IdP object (if the user clicks "allow"), or an Error (if the user clicks "deny").

[meshna]

user-flows-saml-meshna.pdf

Attaching a quickly put together user flow with some descriptions; if a different format is needed and/or I could upload it somewhere for easy collaboration, please let me know where.

[sunetzacharias]

user-flows-saml-meshna.pdf

Attaching a quickly put together user flow with some descriptions; if a different format is needed and/or I could upload it somewhere for easy collaboration, please let me know where.

For clarity: This describes an old flow of how a implementor of the SeamlessAccess discovery and persistence service has its set up. It is not related to the context of the proposal #4.

[meshna]

user-flows-saml-meshna.pdf Attaching a quickly put together user flow with some descriptions; if a different format is needed and/or I could upload it somewhere for easy collaboration, please let me know where.

For clarity: This describes an old flow of how a implementor of the SeamlessAccess discovery and persistence service has its set up. It is not related to the context of the proposal #4.

Yes, this was a response to timcappalli's comment above.

[sunetzacharias]

Updated the proposal today with information about the "Threat model". Last monday updated the text with various information and updated diagrams. Interested parties should read through the entire text as a lot has been attempted to be clarified.

[judielaine]

Here are a few issues with the current FedCM and solutions this model offers.

Many IdPs may be hosted by a cloud provider at an Origin

Azure and Cirrus are examples. Current model cannot distinguish between all the different IdPs at the origin.

This proposal provides a method by which more sophisticated integrations can supply the full URLs for the endpoints currently at .well-known . Note that while an identifier could be provided for the origin .well-known, the scale of some of the cloud provides may make loading that file prohibitively slow.

Many SPs may be hosted by a cloud provider

Office 365 and Liblynx (a platform for journals) are examples. Current model cannot provide the IdP sufficient information to distinguish between options.

This proposal provides a method by which more sophisticated integrations can supply the full URLs for the endpoints IdPs pre-provision as acceptable locations to return Authentication responses.

Roadmap for more trust

Assuming that browsers will allow protocol exchanges to continue, the provisioning of all the metadata allows a browser to restrict front channel cross domain authentication exchanges to the same pre-specified endpoints that the protocols use. Admittedly, this will require additional user interactions when protocol endpoints change.

The endpoints provided by the SP for the IdP and or the SP itself can also be signed by a trust credentialing partner, allowing browsers to signal to endusers that the endpoints are certified by an trusted party.

[samuelgoto]

Azure and Cirrus are examples. Current model cannot distinguish between all the different IdPs at the origin.

Can you give us real world examples? Can you copy/paste an Azure / Cirrus URL that represents a real world IdP? And can't some of this be solved with DNS CNAMES?

[samuelgoto]

Here are a few issues with the current FedCM and solutions this model offers.

From what I understand, one of the most fundamental problems with the current FedCM design at the moment is that the Multi-IdP API wouldn't be able to handle the scale of O(1K) IdPs (which is common in this space) that the user can choose from (we currently assume in the design O(< 10) IdPs).

Is it fair to articulate this as one of the problems we face?

[samuelgoto]

Here are a few issues with the current FedCM and solutions this model offers.

The other issue that I heard from Gary was along the lines of "IdP sessions are typically short-lived (say, a few hours, e.g. at the University Of Arizona it was around 8 hours)", which is an assumption that we don't take into consideration in the current design.

[philsmart]

FedCM calls all IdPs to find accounts. Typical federation flow would be just to choose the IdP without making any calls to find account/session.

[wanpengli]

Here are a few issues with the current FedCM and solutions this model offers.

From what I understand, one of the most fundamental problems with the current FedCM design at the moment is that the Multi-IdP API wouldn't be able to handle the scale of O(1K) IdPs (which is common in this space) that the user can choose from (we currently assume in the design O(< 10) IdPs).

Is it fair to articulate this as one of the problems we face?

Most website only support a few number of IdPs, I did conduct some empirical study several years ago. The 'craziest RP' supported 9 RPs then. This applied for OAuth and OpenID Connect RPs.

[samuelgoto]

Another note I got from the demo you walked us through:

The SAML tracer breaks when we use FedCM, because the extension doesn't have visibility over the browser mediated UI.

[windhamg]

Azure and Cirrus are examples. Current model cannot distinguish between all the different IdPs at the origin.

Can you give us real world examples? Can you copy/paste an Azure / Cirrus URL that represents a real world IdP? And can't some of this be solved with DNS CNAMES?

Here are some examples:

1. Multiple institutions have registered their Google IdPs in various national federations' metadata that are part of the eduGAIN aggregate metadata:
   • Institut des Arts de Diffusion (BELNET Federation):

     <md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://accounts.google.com/o/saml2/idp?idpid=C02lghgox"/>
     <md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://accounts.google.com/o/saml2/idp?idpid=C02lghgox"/>

   • Luxembourg School of Business (eduID Luxembourg):

     <md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://accounts.google.com/o/saml2/idp?idpid=C02ws9ruj"/>
     <md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://accounts.google.com/o/saml2/idp?idpid=C02ws9ruj"/>

   • University of Technology and Applied Sciences (OMREN)

     <md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://accounts.google.com/o/saml2/idp?idpid=C02afc2g7"/>
     <md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://accounts.google.com/o/saml2/idp?idpid=C02afc2g7"/>
     <md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign" Location="https://accounts.google.com/o/saml2/idp?idpid=C02afc2g7"/>

2. University of Northern Colorado has 2 separate Azure AD tenants (one for staff, the other for students) behind a Cirrus Proxy:
   • Azure AD tenant 1:

     <SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://login.microsoftonline.com/b4dce27c-d088-4454-9965-2b59a23ea171/saml2"/>
     <SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://login.microsoftonline.com/b4dce27c-d088-4454-9965-2b59a23ea171/saml2"/>

   • Azure AD tenant 2:

     <SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://login.microsoftonline.com/48e07fd6-ad72-497f-b298-b5c57de6db2d/saml2"/>
     <SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://login.microsoftonline.com/48e07fd6-ad72-497f-b298-b5c57de6db2d/saml2"/>

3. The Danish federation has all of their member IdPs (72 listed in the eduGAIN metadata aggregate) behind a single domain; so all of their SSO endpoints start with https://birk.wayf.dk/.

[skoranda]

Here are a few issues with the current FedCM and solutions this model offers.

From what I understand, one of the most fundamental problems with the current FedCM design at the moment is that the Multi-IdP API wouldn't be able to handle the scale of O(1K) IdPs (which is common in this space) that the user can choose from (we currently assume in the design O(< 10) IdPs). Is it fair to articulate this as one of the problems we face?

Most website only support a few number of IdPs, I did conduct some empirical study several years ago. The 'craziest RP' supported 9 RPs then. This applied for OAuth and OpenID Connect RPs.

CILogon is a RP that brokers access from the eduGAIN federation to a large number of scientific resources. It supports more than 4000 IdP. See https://cilogon.org/

That is only one example. Many RPs in the higher education and research space federate with thousands of IdPs. It's how the community facilitates scholarly and research collaboration.

[meshna]

Correct.

Elsevier SP federates with 3200+ IdPs and that's not the only publisher doing that; this is a normal use case.

Kind regards, Meshna

From: Scott Koranda @.> Sent: Wednesday, March 22, 2023 17:04 To: fedidcg/proposals @.> Cc: Koren, Meshna (ELS-AMS) @.>; Comment @.> Subject: Re: [fedidcg/proposals] idp-sp-storage API (Issue #4)

External email: use caution

Here are a few issues with the current FedCM and solutions this model offers.

From what I understand, one of the most fundamental problems with the current FedCM design at the moment is that the Multi-IdP API wouldn't be able to handle the scale of O(1K) IdPs (which is common in this space) that the user can choose from (we currently assume in the design O(< 10) IdPs). Is it fair to articulate this as one of the problems we face?

Most website only support a few number of IdPs, I did conduct some empirical study several years ago. The 'craziest RP' supported 9 RPs then. This applied for OAuth and OpenID Connect RPs.

CILogon is a RP that brokers access from the eduGAIN federation to a large number of scientific resources. It supports more than 4000 IdP. See https://cilogon.org/https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcilogon.org%2F&data=05%7C01%7Cm.koren%40elsevier.com%7Cf2b1b3ed5f81435628dd08db2aef0bf5%7C9274ee3f94254109a27f9fb15c10675d%7C0%7C0%7C638150978418604233%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=XcOIWOQdq05LitgIJXm3VeNGVboaYnIKJhSBeyar2gU%3D&reserved=0

That is only one example. Many RPs in the higher education and research space federate with thousands of IdPs. It's how the community facilitates scholarly and research collaboration.

- Reply to this email directly, view it on GitHubhttps://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ffedidcg%2Fproposals%2Fissues%2F4%23issuecomment-1479849732&data=05%7C01%7Cm.koren%40elsevier.com%7Cf2b1b3ed5f81435628dd08db2aef0bf5%7C9274ee3f94254109a27f9fb15c10675d%7C0%7C0%7C638150978418604233%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ktO3z7Gljws1nvlYsgxVpbGXPCxHsiAJ3e7fjAhmlOU%3D&reserved=0, or unsubscribehttps://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAFOCGTRCFP4V5M6TVW5KHP3W5MPG5ANCNFSM6AAAAAAVMVWX3Q&data=05%7C01%7Cm.koren%40elsevier.com%7Cf2b1b3ed5f81435628dd08db2aef0bf5%7C9274ee3f94254109a27f9fb15c10675d%7C0%7C0%7C638150978418604233%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=cuG9LkZGecBT5U50TUH6RtCBbDsjBeOfKQ2DVJjbZcQ%3D&reserved=0. You are receiving this because you commented.Message ID: @.**@.>>

---

Elsevier B.V. Registered Office: Radarweg 29, 1043 NX Amsterdam, The Netherlands, Registration No. 33158992, Registered in The Netherlands.

[judielaine]

Most website only support a few number of IdPs, I did conduct some empirical study several years ago. The 'craziest RP' supported 9 RPs then. This applied for OAuth and OpenID Connect RPs.

I'm going through a list of publishers. In the past 40 minutes i identified the following sites with more than ten IdPs. Adding -- one normally needs to search for their institution, you may not be able to determine the precise number of IdPs but can explore search terms to determine "more than ten".

https://5minuteconsult.com see https://5minuteconsult.com/SignInShibboleth.aspx, pick from five federations https://akjournals.com/ see https://akjournals.com/login https://acpjournals.org see https://www.acpjournals.org/action/ssostart?redirectUri=%2F https://alexanderstreet.com/ see https://search.alexanderstreet.com/wayf?destination= https://anatomy.tv see https://www.anatomy.tv/login?lastpageurl=titles

https://academic.oup.com/ see https://oup2-ds.sams-sigma.com/?entityID=https%3A%2F%2Foup-sp.sams-sigma.com%2Fshibboleth&return=https%3A%2F%2Foup-sp.sams-sigma.com%2FShibboleth.sso%2FLogin%3FSAMLDS%3D1%26target%3Dss%253Amem%253Afd4b4a0c1b2d0e230c53001b312510d6d644de32ff591de54a561602d1bd794d https://access.torrossa.com see https://access.torrossa.com/shibboleth-ds/index.html?entityID=https%3A%2F%2Fwww.torrossa.com%2Fshibboleth&return=https%3A%2F%2Faccess.torrossa.com%2FShibboleth.sso%2FLogin%3FSAMLDS%3D1%26target%3Dss%253Amem%253Aa28767884b281870eba40e75d8f1fde661614e20f8e49c16823d93259d5e078b https://acta.chadwyck.co.uk see https://www.proquest.com/legacyredirect/actasanctorum https://advantage.marketline.com see https://advantage.marketline.com/HomePage/Index?returnUrl=Home https://advisor.lww.com see https://wayfinder.openathens.net/?return=https%3A%2F%2Fconnect.openathens.net%2Fsaml%2F2%2Fauth%3Fr%3Dhttps%253A%252F%252Fconnect.openathens.net%252Foidc%252Fauth%253Fresponse_type%253Dcode%2526client_id%253Dwolterskluwer.com.oidc-app-v1.0c519265-f12d-4407-915b-7c35a86d9c18%2526scope%253Dopenid%2526redirect_uri%253Dhttps%25253A%25252F%25252Flns-sso.lww.com%25252Fopenid_connect_login%2526nonce%253D357e3387b0746%2526state%253Dafaa38974fba%2526pfidpadapterid%253DLippincottAdapter%26d%3Dwolterskluwer.com%26c%3D092c9afe-6fb4-4d4e-bf47-dadfa3d358f7%26as%3Dpublished%26aid%3D0c519265-f12d-4407-915b-7c35a86d9c18&oaDomain=wolterskluwer.com&oaAppId=0c519265-f12d-4407-915b-7c35a86d9c18&entityID=https%3A%2F%2Fadvisor.lww.com%2Foa%2Fmetadata

[wanpengli]

Most website only support a few number of IdPs, I did conduct some empirical study several years ago. The 'craziest RP' supported 9 RPs then. This applied for OAuth and OpenID Connect RPs.

I'm going through a list of publishers. In the past 40 minutes i identified the following sites with more than ten IdPs. Adding -- one normally needs to search for their institution, you may not be able to determine the precise number of IdPs but can explore search terms to determine "more than ten".

https://5minuteconsult.com see https://5minuteconsult.com/SignInShibboleth.aspx, pick from five federations https://akjournals.com/ see https://akjournals.com/login https://acpjournals.org see https://www.acpjournals.org/action/ssostart?redirectUri=%2F https://alexanderstreet.com/ see https://search.alexanderstreet.com/wayf?destination= https://anatomy.tv see https://www.anatomy.tv/login?lastpageurl=titles

https://academic.oup.com/ see https://oup2-ds.sams-sigma.com/?entityID=https%3A%2F%2Foup-sp.sams-sigma.com%2Fshibboleth&return=https%3A%2F%2Foup-sp.sams-sigma.com%2FShibboleth.sso%2FLogin%3FSAMLDS%3D1%26target%3Dss%253Amem%253Afd4b4a0c1b2d0e230c53001b312510d6d644de32ff591de54a561602d1bd794d https://access.torrossa.com see https://access.torrossa.com/shibboleth-ds/index.html?entityID=https%3A%2F%2Fwww.torrossa.com%2Fshibboleth&return=https%3A%2F%2Faccess.torrossa.com%2FShibboleth.sso%2FLogin%3FSAMLDS%3D1%26target%3Dss%253Amem%253Aa28767884b281870eba40e75d8f1fde661614e20f8e49c16823d93259d5e078b https://acta.chadwyck.co.uk see https://www.proquest.com/legacyredirect/actasanctorum https://advantage.marketline.com see https://advantage.marketline.com/HomePage/Index?returnUrl=Home https://advisor.lww.com see https://wayfinder.openathens.net/?return=https%3A%2F%2Fconnect.openathens.net%2Fsaml%2F2%2Fauth%3Fr%3Dhttps%253A%252F%252Fconnect.openathens.net%252Foidc%252Fauth%253Fresponse_type%253Dcode%2526client_id%253Dwolterskluwer.com.oidc-app-v1.0c519265-f12d-4407-915b-7c35a86d9c18%2526scope%253Dopenid%2526redirect_uri%253Dhttps%25253A%25252F%25252Flns-sso.lww.com%25252Fopenid_connect_login%2526nonce%253D357e3387b0746%2526state%253Dafaa38974fba%2526pfidpadapterid%253DLippincottAdapter%26d%3Dwolterskluwer.com%26c%3D092c9afe-6fb4-4d4e-bf47-dadfa3d358f7%26as%3Dpublished%26aid%3D0c519265-f12d-4407-915b-7c35a86d9c18&oaDomain=wolterskluwer.com&oaAppId=0c519265-f12d-4407-915b-7c35a86d9c18&entityID=https%3A%2F%2Fadvisor.lww.com%2Foa%2Fmetadata

The currently FeDCM API is allowing the RP developer to identify the IdP manually. This works fine with OAuth and OpenIDConnect. SAML needs some special IdP discovery process( see here https://techdocs.broadcom.com/us/en/symantec-security-software/identity-security/siteminder/12-8/configuring/partnership-federation/saml-2-0-only-configurable-features/idp-discovery-profile-saml-2-0.html). If FeDCM need to be compatible with SAML. The IdP discovery procedure of SAML needs to be considered.

[judielaine]

@wanpengli Yes! This proposal is in alignment with SAML discovery profiles.The actual specification for SAML Discovery is http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-idp-discovery.html However, with recent user experience and privacy research in the RA21 project -- https://ra21.org/ -- spun off the Seamless Access project -- https://seamlessaccess.org/ . Participants from Seamless Access helped draft this specification.

[nckroy]

This is now markdown at: https://github.com/fedidcg/proposals/blob/idp-sp-storage-API-Issue-4/idp-sp-storage-api.md