Some content taken from Trust Coordination Paper by DavidG.
Attendees TIIME 2020: Dave Kelsey, Hannah Short, Peter Moinar, Wolfgang Pempe, Marcus Hardt, Uros Stevanovic, Mischa Sallé, David Hübner, David Groep, Mikkel Halel, Ian Collier, Tom Dack, Niels van Dijk, Gabriel Guckenbiehl, Christos Kanellopoulos, Benn Oshrin, Slavek Licehammer, Tom Barton, Gerben Venekamp, Ian Neilson, Marco Leonardi, Andreas Matheus, Valentina Faccin
A detailed description of FIM4R Recommendations for Research Community and Infrastructure AAIs can be found in the FIM4R version 2 white paper. This short position paper highlights the FIM4R Community’s vision for an EOSC AAI offering that adequately supports Research Communities.
The level of maturity varies significantly between Research Communities, with some already operating production AAIs and others more likely to seek an AAI service offered through EOSC. All these AAIs must interoperate within EOSC and provide researchers with an intuitive, “low-friction” user experience. Many researchers are accustomed to existing authentication flows, through web interfaces branded by their own Research Community - FIM4R does not believe that Researchers should change this flow to authenticate via “Login with EOSC” or equivalent. Rather, EOSC services should be transparently integrated behind Research Community proxies.
Some Research Communities may also wish to offer services to other Research Communities through EOSC; such a process should be made as intuitive as possible without users visibly leaving the environment of their own Research Community.
Any EOSC AAI service offerings should leverage existing products and services (i.e. not reinvent the wheel), and be made available in a modular way such that individual components can be plugged in to existing AAIs if relevant (e.g. Research ID Connect). As stated in FIM4Rv2, “The diversity of the research communities should be reflected in the AAI offerings; we do not see a single solution as a sustainable future.” AAI services, solutions and products offered by EOSC should be available for Research Communities to select on demand, Research Communities should not be expected to adopt a specific tool and undergo a costly migration to a new system to benefit from EOSC. At the same time, Research Communities must be prepared to adopt interoperability guidelines. Such guidelines should be agreed and adopted following consensus between multiple Research Communities and Infrastructures operating production AAIs. We see the AEGIS community as an appropriate body for creating such guidelines.
We anticipate the EOSC AAI landscape to comprise multiple AAIs protecting clusters of services. Establishing trust between AAIs (and with the services behind them) is essential; certain best practices in Operational Security (e.g. Sirtfi) and the ability to support Federation Frameworks (such as the REFEDS Assurance Framework) should be mandated.
Researcher experience must be prioritised, such as; minimising the number of required authentications (Single-sign-on), limiting the number of AUPs and consent workflows to which a user is exposed, ensuring sufficient attribute release between proxies for valid authentication. A scalable solution should be found to legalise the flow of personal data required for authentication. Experience with Federated Identity in FIM4R Research Communities indicates the need for a strong Operational Support platform that is able to resolve user authentication issues - EOSC must take this into account.
Notes Vienna 2020
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:
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: