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