A meeting of the Federated Identity Management for Research (FIM4R) community. This FIM4R is co-hosted with the TIIME Workshop in Vienna.
Registration: https://tiimeworkshop.eu/registration/ (be sure to select FIM4R!)
Location: MGC Messe Vienna, Austria Leopold-Böhm-Straße 8, 1030 Wien
For questions, email contact@fim4r.org
How can the FIM4R Community be helping other Research Communities to get started in FIM? Brainstorming session
Should align with AEGIS, though they appear to take very mature things which may be beyond us at the moment
Notes Vienna 2020
Refer to FIM4R v2 paper
Our interpretation is not that end users/researchers will not all be authenticating through a single “entrypoint” (e.g. Login with EOSC)
Users will remain affiliated with their Research Community
Service Catalogue may contain AAI services/software that can be used by Research Communities
One of these could be the ResearcherID service, which eases integration of Federated Identity for Research Communities (this could be part of the AAI offerings perhaps)
Others may be full AARC Compliant proxy implementations/platforms that follow guidelines approved by AEGIS
Aim not to reinvent the wheel, there are existing tools
Multiple AAIs interacting
Some Research Communities will pick AAI services from the Catalogue
Others will run their own
THEY MUST INTEROPERATE
Policy aspect of trust between AAIs
E.g. security coverage
Balance between the concept of “no barriers to entry for services and users” and trust. Peer review may be appropriate
Many players are not legal entities
GDPR
Propagation of assurance (RAF) should be supported and usable by Research Communities with different assurance requirements
We should prioritise “low friction” for researchers e.g.
Single-sign-on
Limit # AUPs, consent etc
Data policies (legal measures from 2018 were unhelpful)
Must be adequate operational support
We should make the language here EOSC agnostic, we may well be misunderstanding terms like Service Catalogue and Platform
Many Research Communities already run production AAIs, they should not be obliged to adopt EOSC AAI services
However, they may need to adopt common guidelines for Interoperability
Research Communities will want to pick up new Services and integrate them behind their AAIs
Research Communities should be able to offer their services in EOSC
Services will be clustered behind proxies (e.g. NRENs collate services from their constituents). EOSC has capability to allow integration of e.g. university resources,
Our document should specify what FIM4R Research Communities want out of EOSC
What do we do about smaller RCs that are not represented?
We do need to say who we are, and state the wide variation in Research Communities and how they may want to use EOSC
ORCID could be of value
Next Steps
Good draft document edited by a few (if you’re in the EOSC AAI already perhaps not active participation, but certainly should express what they know or are questioning)
Send to FIM4R for comment and endorsement by Research Communities
End of March public version of EOSC AAI Architecture (AARC BPA 2019)
Can send this already to EOSC AAI people so they can incorporate ideas
Qs from EOSC AAI
Single login point?
Big vs small collaborations (missing the forest of small communities)
Multiple solutions are being deployed by different infrastructures, each infrastructure needs to be interoperable. Do we want a “single solution” i.e. “login with EOSC”? (answer is no) We need to be careful to understand what is meant by “portal” or “single entrypoint”. Portal (or Service Catalogue) used by infrastructure to procure services. In AAI, trust will come from communities, bridging between services and users. There are already some AAI platforms available in the service catalogue. There are now some EOSC AAI people who are not FIM4R veterans so it is valuable for us to say something.
Key points from the room:
GDPR compliance (much work ongoing in various projects)
Should take some key points from FIM4R and clarify that it is still valid
Some notion of whether communities are providers (i.e. making services available to other communities) or consumers of services (i.e. buying from the EOSC Service Catalogue)
Should take a look at AARC BPA 2019 and identify gaps
Does FIM4R need to take a more “commodity” viewpoint?
It is a dynamic situation, we expect this process to continue (getting opportunities to supply input)
Some effort on outreach would be valuable
Expectation on specialised services to make life a little easier than doing it yourself
Perhaps ResearcherID as a service in EOSC that can be used by Research Communities and AAI Services
Discovery service, Seamless-Access etc should be considered (bear in mind that it is not designed to preserve community branding)
TODO
Unconference Session(s)
“The European Open Science Cloud (EOSC) enters a next phase of integration and consolidation with the establishment of a common service portal listing underpinning services that enable distributed resources in the areas of computation, data, open access, and above-the-net collaboration services. More than ever before, composition of services within the EOSC ecosystem will create mutual dependencies between service providers – in terms of not only quality management, provisioning, accounting and settlement, but specifically also in managing the integrity, resilience, availability, and trust in the composition of services and their use. Trust management is enabled by establishing and maintaining essential capabilities providing the appropriate level of integrity, resilience, availability, and confidentiality of the involved services and data.
The existing e-Infrastructures that are anticipated to be part of the EOSC each provide their own capabilities in terms of trust and identity management, integrity protection and risk management, as well as capabilities to support business continuity and disaster recovery in case of security incidents. Many of these activities are anchored in existing, cross-infrastructure, coordination groups such as the WISE (Wise Information Security for E-infrastructures) community (wise-community.org), the Interoperable Global Trust Federation IGTF (igtf.net), the Special Interest Group on Information Security Management SIG-ISM (wiki.geant.org/display/SIGISM), and the AARC Engagement Group for Infrastructures AEGIS (aarc-community.org). Jointly, the e-Infrastructures also support and further the work of the research-community centric Federated Identity Management for Research FIM4R group (fim4r.org). There are also specific trust, collaboration management, and security services that are jointly managed by multiple e-Infrastructures for the benefit of (but in many cases not exclusively) the European research and collaboration community as a whole. These include for instance the glue between the EOSC AAI suite of services that each implement the AARC Blueprint Architecture (eduTEAMS, EGI CheckIn, Indigo IAM, and B2ACCESS) and components such as the RCauth.eu credential translation bridge service. But also a Security Policy Group addressing joint risk assessment, and trust and security training activities, for the core and edge services alike, that consider the interdependency of services in the EOSC ecosystem.”
Key points for FIM4R:
We do not see a Single AAI as a solution, many Communities will bring their own AAIs and many underlying infrastructures also have established AAIs. We do not believe that EOSC should offer only one AAI service in its catalogue, as mentioned in FIM4R v2: “The diversity of the research communities should be reflected in the AAI offerings; we do not see a single solution as a sustainable future.”
All AAIs in EOSC should be aware of and addressing FIM4R Recommendations, particularly those targeted to “Research community proxies” and “Research e-Infrastructures”
Interoperability between AAIs is critical, including
A common syntax for expressing authorisation information between such AAIs
Propagation of assurance information between proxies
Possible locations?
What do we need to meet about?
Next Steps
TO DO at TIIME