15th FIM4R Workshop

Europe/Berlin
Description

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

Actions:

  • Share ResearchID concept with group for feedback
  • Unconference sessions
    • data collection for impact assessment (Peter)
    • position paper for EOSC AAI (Dave)
  • Blog post with Iris (TomD)
  • Decide next meeting (?)
There are minutes attached to this event. Show them.
    • 1
      Welcome and Objectives Setting
      Speakers: Hannah Short (CERN), Peter Gietz (DAASI International)
    • 2
    • 3
      WLCG & CERN Update
      Speaker: Hannah Short (CERN)
    • 4
      LifeScience AAI and GA4GH
      Speaker: Pavel Brousek (CESNET/Masaryk University)
    • 5
      PaNOSC and FENIX
      Speaker: Christos Kanellopoulos
    • 10:30
      Break
    • 6
      DARIAH AAI 2.0 to 3.0
      Speaker: Peter Gietz (DAASI International)
    • 7
      Data driven FIM Impact Assessment
      Speaker: Chris Whalen
    • 12:25
      Lunch
    • 8
      AARC Community and AEGIS Update
      Speakers: Christos Kanellopoulos, David Groep (Nikhef National institute for subatomic physics (NL)), David Groep (NIKHEF (NL)), David Groep (NIKHEF (NL))
    • 9
      GN4 Project: Enabling Communities
      Speaker: Mr Maarten Kremers (SURFnet)
    • 10
      OIDC-agent
      Speaker: Uros Stevanovic (Karlsruhe Institute of Technology)
    • 14:45
      Break
    • 11
      Kickstarting FIM

      How can the FIM4R Community be helping other Research Communities to get started in FIM? Brainstorming session

      • Write blog posts to share use cases
        • Iris with IAM (Hannah to speak with TomD)
      • Should we provide a Knowledge-base platform for people to ask questions? Concern about sustainable funding
      • Convince community
        • Gather data to inform others 
      • ResearcherID Idea
        • Somehow provide our requirements and help it to be realistic (Hannah to share a link to the doc)

      Should align with AEGIS, though they appear to take very mature things which may be beyond us at the moment

    • 12
      FIM4R Position Paper for EOSC AAI

       

      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

    • 13
      Next Steps

      Possible locations?

      • TIIME and TechEx have problem that we don't reach new Communities
      • We need to change the level of discussion if we are inviting many new communities
      • Standalone?
        • CERN happy to host (could be November or December)
          • Need to avoid Thanksgiving and SuperComputing
      • PEARC (July)
        • Can send a few individuals (TomB, it's too late to book a side meeting)
      • Go to the big 5 ESFRIs (?) 
        • They are not all active yet
      • RDA, could hold meeting before or after
        • March 20 = Melbourne
        • Nov 30 = Costa Rica 
        • Apr 21 = Edinburgh
      • TechEx (October)
        • More non-Research Community people, need to tailor the agenda to that 

      What do we need to meet about?

      • We are no longer saying "we are the market" in the same was as v2
      • Aim to influence Framework Europe
      • Aim to collect data
      • Maybe we need to be putting FIM requirements into Research Agreements (Marcus)

      Next Steps

      • 1 or 2 pages for EOSC AAI (do this week)
      • From this write a longer document, could even be a v3

      TO DO at TIIME

      • SPs happy to pool data (PeterG)
      • EOSC AAI position paper (DaveK)