The following discussion is very much under development - your comments on this approach are welcomed by aarc-na3@lists.geant.org. This communication is a reflection earlier sent to the REFEDS list.
What we have seen in studies from AARC (and FIM4R) is that basically all research communities have established SP-IdP proxies. In that proxy service they augment the authenticator and attributes that come from the 'conventional R&E IdPs' with elements that are essential for that infrastructure: a persistent non-reassigned identifier, assurance level, maybe add community membership roles and groups, maybe add reputation. In that, the RIs shield themselves from the heterogeneity of the global R&E federation space, and they make it easier for themselves since they can now 'hide' all their services behind just a single proxy. Once that proxy is in a federation, or in eduGAIN, the entire community is a happy one. One IdP (internally) to rule them all. And they will usually throw in an IdP-of-last-resort for their own community as a bonus ...
However, such a proxy in itself poses a few policy challenges: first of all the services 'internal' to the community see only a single IdP, and they will have to trust that single one. Relying parties and data centres that service multiple research communities will have to trust several of these proxies (think of an EUDAT or EGI). Basically, each proxy creates a silo, and you need ways to merge these silos again for multi-tenant resource providers.
Conversely, the SP-IdP proxy hides all of the research services behind a single SP, so the home orgs and R&E federation will see a single entity, even if the service behind that is provided by 300+ different administrative domains and service providers. So what did you just let in to your federation space? ...
The nucleus of this idea is to see if we can come up with a policy framework that allows us to determine the 'quality' of such SP-IdP proxies. For example, a SP-IdP-proxy for EGI, proxying in all the HTC compute and mass storage services in EGI, would be able to express to the R&E federation space that is has an internally-consistent policy set, that it can make assured collective statements about all its 'upstream' services and resource providers, and that it can and will abide by DPCoCo, R&S, and (probably) even Sirtfi. But how does that compare to other infrastructures? How can you compare the SP-IdP-proxy for EGI with the one from ELIXIR? Or from B2ACCESS from EUDAT? &c?
For that, one of the options is to evolve the SCI framework. You'll know a bit about SCI, since it inspired the Sirtfi work. There are more elements in there. See e.g.
https://www.igtf.net/sci/
for the areas on traceability, participant responsibilities, community membership documentation requirements, legal, or data protection. It's a framework, so it does not in itself set standards, but does set the framework by which you can see whether a peer infrastructure has a policy or process in pace addresing a topic of concern. Yet SCI was primarily written to compare Distributed IT Infrastructures, and does not deal too much with the IdP and identity side. For the first SCI version that was out of scope.
But for a framework for SP-IdP-proxies, you could evolve SCI to include (by reference or inheritance) those elements from good sources (maybe the GEANT federation template? Some great IdP policy frameworks out there?) and then make a scheme - comparable to Sirtfi but scoped to IdP-SP-proxies - that will allow us to compare their merits, potentially assign entity categories for meeting or exceeding some baseline requirements in a few areas, and generally allowing a scalable way to negotiate and filter on policies. That would probably help both on the R&E federation side ("do I want this worm hole in my federation? Yes, it meets the baseline criteria, and it's trustworthy!"), and on the SP side (they get into more federations, IdPs are more willing to release attributes to them, they can convince their registrar to assert CoCo and R&S), and on the back-end e-Infra services ("yes, I want assertions from this proxy, since I know it meets my resource provider trust requirements").