FIM4R Position Paper on the desired evolution of EOSC AAI

(David Kelsey)

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

• 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