Introduction
Following the publication of the Commission Staff Working Document (March 2018) on the Implementation of the EOSC, a joint effort by the European Commission, the Member States and four projects (EOSCPilot, eInfraCentral, OpenAIRE-Advance, EOSC-Hub) led to the development of the First Version of the EOSC Portal for the EOSC launch in November 2018.
This First version of the EOSC Portal onboarded a large number of Resources offered to European researchers from a large number of EOSC Providers. The onboarding of those Resources to the EOSC Portal was achieved by two parallel efforts: eInfraCentral (catalogue) and EOSC-Hub (marketplace) that onboarded together more than 94 Resource Providers that gave access to more than 250 services, 4M datasets, 150K applications and software, 35M publications and 3M other research products, organized in more than 300 entries.
EOSC Enhance is now responsible to further develop, optimise and coordinate the onboarding function and related interfaces of the EOSC Portal. In this framework, EOSC Enhance is responsible, in close collaboration with EOSC-Hub and OpenAIRE, to a) unify and specify, b) develop (product development axis) and c) operate (service operation axis) a single onboarding process for all EOSC Resource Providers. This document unifies and specifies the EOSC Portal Onboarding Process (OP) and provides additional supporting information for the process implementation and validation.
The SW development for the onboarding process is the responsibility of EOSC Enhance WP3. The EOSC Onboarding Operations is overlooked by WP2 at this link and is operated currently in collaboration with EOSC-hub and OpenAIRE, which staffs the process while the tooling comes from EOSC Enhance and is supported by the EOSC Providers Section of the EOSC Portal developed by eInfraCentral and upgraded in EOSC Enhance.
The EOSC Portal OP is built on the foundations of eInfraCentral, EOSC-Hub, EOSCPilot, OpenAIRE-Advance and CatRIS, as well as the results produced by the EOSC Working Groups (e.g. RoP) and the experience gained by the organisations participating in the onboarding so far that have produced a detailed set of rules and specific criteria. The EOSC Portal OP reflects the need for sufficient and appropriate inclusiveness, transparency and openness such that it can be followed by all interested parties with small differentiations, irrespective of their maturity.
The OP at its current form specifies only the onboarding of Resource Providers and their Resources; Additional onboarding steps will be defined in the future (e.g., Options/Instantiations, etc). Furthermore, the OP will be extended to cover cases where the Provider onboarded is not the owner of the Resources but rather an aggregator, broker or may take similar roles. It is expected that the long-term evolution of this process will introduce automation in selected steps to allow scalability and avoid bottlenecks in the onboarding process. Last but not least, the onboarding process might have some variations depending on the type of resource onboarded (e.g. service or data, etc).
The EOSC Portal OP has cross-references and is dependent on the EOSC Profiles, the EOSC Rules of Participation (RoP) and the EOSC Portal Application Programming Interface (API) methods for the automatic provisioning and synchronisation of information between Providers’ systems and the EOSC Portal. All those documents constitute the EOSC Portal Registry Interoperability Framework. The framework specifications as a whole constitute an important pillar to realise the EOSC vision and framework. It is an evolving specification, which will incorporate new features from the EOSC ecosystem as they emerge.
Phases of the EOSC Portal Onboarding Process
A general overview of the EOSC Portal OP is depicted in the following Figure. The current form includes 3 distinct Phases implemented in 10 distinct Stages.
The 3 Phases of the Onboarding Process are:
- An Authorised Representative of a Provider registers him/herself into the EOSC Portal.
- The Authorised and Authenticated Representative of a Provider onboards (and updates) the Provider.
- The Authorised and Authenticated Representative of a Provider onboards (and updates) the Resources offered by the Provider.
As soon as each phase is concluded (approved or rejected), the user is notified to proceed accordingly. If the three-phase onboarding process is successful, then the Provider is registered to the EOSC Portal and their Resources become publicly accessible.
Stages of the EOSC Portal Onboarding Process
The 10 Stages of the Onboarding Process are:
- The ARP registers with the EOSC Portal
- The AARP logins to the EOSC Portal
- Τhe AARP asserts Authorisation for the Provider
- The AARP applies to onboard the Provider
- The EPOT reviews the Provider Profile
- The AARP selects the method to onboard Resources
- The AARP applies to onboard Resources
- The EPOT reviews the Resource Profiles
- The AARP applies to onboard other Resources
- The EPQT creates a Report
The Flow Diagram of the EOSC Portal Onboarding Process is depicted in the following Figure.
The following sections provide further details of the actions that take place in each of the workflow Stages.
| Stage | Title | Actions | |
|---|---|---|---|
| 0 | The Representative of the Provider visits the Portal | A Representative of the Provider [1] visits the “For Providers” Section of the EOSC Portal [2] and clicks on "Become a provider! Apply now" [3] to start the process of applying to become a Provider [1] Αassumed to be authorised to act on behalf of the Provider at this stage. |
|
| 1 | The Representative of the Provider registers with the Portal using an existing identity from a supported Social or Academic AAI mechanism | The Representative of the Provider uses the Authentication and Authorization Infrastructure (AAI) mechanisms supported by the Portal [4] to register with the Portal. [4] Currently supported AAI mechanims: [4] Currently supported AAI mechanisms: eduTeams, EGI CheckIn, OpenAIRE, EUDAT B2ACCESS, Aria, Dariah, IGTF, OpenMINTED, ORCID, Social and AAI mechanisms of many Academic and Research Institutions worldwide. If a Representative of a Provider cannot authenticate via one of the provided Academic AAI proxies, the representative can authenticate via a Google social identity account. [5] https://www.eosc-portal.eu/helpdesk |
|
| 2 | The Authenticated Representative of the Provider logs into the Portal | The Authenticated Representative of the Provider (ARP) logins via the AAI of the Portal. Once logged in, the menu allows access to the "Add New Provider" functionality. |
|
| 3 | The Authenticated Representative of the Provider asserts he/she is an Authorized Representative of a Provider | By clicking on "Add New Provider" the ARP is asked a) to agree to the EOSC Portal Privacy Policy [6] and b) to assert the Authorisation of Representation of the Provider Organisation. Once a and b are accepted and the latter asserted, the Authenticated and Authorized Representative of the Provider (AARP) can apply to onboard the Provider. [6] The EOSC Portal Privacy Policy applies to the collection of the data, public vs. internal, etc. |
|
4 | The Authenticated and Authorized Representative of a Provider applies to onboard the Provider | Upon successful completion of step 3, the AARP may apply for the onboarding of the Provider by completing the Provider Profile [7]. Automated mechanisms are used to the greatest extent possible to ensure that all required information is included and that the information is of the correct type, size, etc. In case any difficulties arise during the application, the AARP may communicate issues [8] and depend on the issue the EOSC Portal Onboarding Team (EPOT) may organise a 1-to-1 call to offer guidance. The EPOT reviews the ticket from the Provider and updates it with any additional information deemed necessary. [7] The Profile in pdf and in excel formats is available to download and preview. |
|
| 5 | The Portal Onboarding Team reviews the newly onboarded Provider | The Provider application is reviewed by the Onboarding Team. The EPOT checks the minimum requirements of the Portal and the rules and criteria based on the current RoP and the typology of the Provider Profile (mandatory fields, lengths, types, etc.) and provides comments and recommendations for improvements on the Validation Tool. If the Provider description does not comply with the minimum requirements, or the rules and criteria or the typology of the Provider Profile, the AARP is contacted by email to act on the recommendations and resubmit the Provider Profile. The ticket is updated and the Validation Tool with the recommendations is attached. At this stage, the AARP can benefit from the tutorial materials available on the Portal. In the case of specific needs or issues, personalized consultation may be offered. If the Provider updates via the Portal the Provider description, it is reassessed following the same steps. At this step, the Provider may be rejected also as not within the allowed range of organisations expected to act as Provider, otherwise, the AARP is notified of the approval and invited into step 6. Approval or rejection notifications are sent automatically by the Portal. The onboarding team updates the status in the onboarding ticket. Provider authorisations to the Portal without the onboarding of a Resource are valid for 1 year. After the Onboarding of one or more Resources, the authorisation of the Provider to the Portal is extended to a year. Providers are required to maintain and update the Resource descriptions at least once per year. |
|
| 6 | The Authenticated and Authorized Representative of the Provider selects the method to onboard the Re-sources | The AARP logins (if not already logged in) to the Portal and may proceed with the onboarding of Resources. Note) The first resource of the Provider must be entered using the web interface, see step 7a. |
|
| 7a | The authorized and authenticated Representative of a Provider applies to onboard a Resource via the web interface | The AARP may apply for the onboarding of a Resource by completing the Resource Profile [9]. Automated mechanisms are used to the greatest extent possible to ensure that all required information is included and that the information is of the correct type, size, etc. Otherwise, if the form is completed and passes all checks it can be submitted. When the form is submitted the AARP is queried if additional Resources will be onboarded. If yes, then step 6 is repeated otherwise the process moves to step 8. [9] The Profile in pdf and in excel formats is available to download and preview. |
|
| 7b | The authorized and authenticated Representative of a Provider applies to onboard a Resource via the API | The AARP may apply for the onboarding of Resources by using the Portal Open API. In brief, the Provider needs to use the AAI of the Portal to retrieve a new API token. Then, the Provider prepares the Resource description, according to the Resource Profile by calling the API’s POST/Resource/validate method. Upon successful validation, the Provider calls the POST/Resource method to add the new Resources in the catalogue. Upon success, the Provider receives a new set of Resource IDs and the new Resources are onboarded in the Portal. A detailed description of the Portal Open API [11] is available. In case any difficulties arise during the employment of the API, the AARP may communicate issues [12] and depend on the issue the onboarding team may organise a 1-to-1 call to offer guidance. |
|
| 8 | The Portal Onboarding Team reviews the newly onboarded Resources | All newly onboarded Resources are reviewed by the EPOT. |
|
| 9 | The authorized and authenticated Representative of a Provider applies to onboard other Resources via the API or web interface | The AARP can now onboard new Resources from the Provider Dashboard. |
|
| 10 | The Portal Quality Team creates a Completeness Report | When all Resources of a Provider are listed, the Provider may select to receive a Completeness Level Report that can be used to show compliance to the Portal Interoperability Framework and proceed with further improvements on the Provider and Resource descriptions. |
|
EOSC Portal Rules and Criteria for Onboarding
The rules and criteria used to validate which Resources should be onboarded to the EOSC Portal are based on:
- The high level Rules of Participation coming from EOSC Governance
- The practical implementation of these rules as set out by the EOSC Portal team in collaboration with other EOSC community landscape actors
- The practical and technical requirements of the EOSC Portal and the portfolio and catalogue platforms it hosts.
These rules and criteria are still under development with the contribution of EOSC-Enhance, EOSC-hub, OpenAIRE, CatRIS project, but also at a larger scale by the EOSC Governance and EOSC WGs. The EOSC Executive Board may define broader rules and criteria in the future. The process will be updated accordingly.
- The Provider must accept the EOSC Portal Agreement (to be covered in EOS-Provider Agreement).
- The Resources must be actual Resources, according to the Definitions section and IT Service Management definitions (e.g. FitSM: Way to provide value to customers through bringing about results that they want to achieve Note: In the context of the FitSM standard series, when referring to services, usually IT services are meant):
- A Service, i.e. an ongoing activity offered ‘live’ to customers;
- A Data Source, i.e. a Service Resource whose specific purpose is to offer deposition, preservation, curation, discovery, access, and usage statistics functionalities to collections of Research Product Resources from a thematic or cross-discipline perspective;
- A Research Product, i.e. digital or physical result of a research process (e.g. publications, research data, research software, other products) and is made accessible via an EOSC Data Source.
- The Resource must be coherent. It must be available and offer value on its own. It may not be only a feature of a larger service.
- The Resources must meet at least one of the following:
- Must be targeted to the research community
- Must be provided by the research community
- Comes from an EOSC related H2020 funded project
- Is part of a procurement framework targeting researchers.
- The Resources must be available in Europe and in a European language. See https://europa.eu/european-union/about-eu/eu-languages_en
- The Resources must be described according to the latest DTs and the mandatory fields must be filled, including required linked information. URLs must be Fully Qualified Domain Names (FQDN).
- Key information of Resources must be in English
- The DT must be in English
- The basic information in the UI for the Resource must be available in English
- Privacy statements, terms of use and SLA/SLS must be available in English (other documentation may be in native language only).
- The Resource helpdesk must be able to answer queries in English.
EOSC Portal Onboarding Operations Roles and Responsibilities
This chapter describes in detail the roles and responsibilities of the EOSC Portal Onboarding Team.
The EOSC Onboarding Operations is overlooked by EOSC Enhance WP2 and is operated in collaboration with EOSC-hub and OpenAIRE which staffs the process while the tooling comes from EOSC Enhance and is supported by the EOSC Providers Section of the EOSC Portal developed by eInfraCentral and upgraded in EOSC Enhance by UOA.
| Stage | Responsibility | Individuals | Operating hours | Response time | Comments | |
|---|---|---|---|---|---|---|
| 0 | UOA: | |||||
| 1 | GEANT: | |||||
| 2 | UOA: | |||||
| 3 | EGI: UOA: | |||||
| 4 | JNP: EGI: UOA: | |||||
| 5 | JNP: EGI: | |||||
| 6 | UOA: | |||||
| 7a | JNP: EGI: UOA: | |||||
| 7b | JNP: EGI: UOA: | |||||
| 8 | JNP: EGI: UOA: | |||||
| 9 | JNP: | |||||
| 10 | JNP: EGI: UOA: | |||||
| 11 | JNP: EGI: UOA: | |||||
| 12 | JNP: EGI: | |||||
| 13 | JNP: EGI: |
EOSC Portal Onboarding Process Communication Exchange
Stage 4. The Authenticated and Authorized Representative of a Provider applies to onboard the Provider | |||||||
Action 4.1: Mail to AARP to Acknowledge Reception of Provider Application | |||||||
From: noreply@eosc-portal.eu To: [User email] Subject: [EOSC Portal] Your application for registering [Provider Name] as a new EOSC Provider to the EOSC Portal has been received and is under review | |||||||
| |||||||
Action 4.2: Mail to the EPOT to approve or reject the Provider application |
From: noreply@[...].eu To: onboarding@[...].eu Subject: [EOSC Portal] A new application for registering [Provider Name] ([Provider ID]) as a new EOSC Provider to the EOSC Portal has been received and should be reviewed |
Dear EOSC Portal Onboarding Team, A new application by [user name] – [user email] has been received for registering [Provider Name] ([Provider ID]) as a new EOSC Provider in the EOSC Portal. You can review the application here [link to application page] and approve or reject it. |
Stage 5. The EPOT reviews the newly onboarded Provider | ||||||||||
Action 5.1: Mail to the AARP to acknowledge approval of Provider application | ||||||||||
From: noreply@[...].eu To: [User email] CC: onboarding@[...].eu Subject: [EOSC Portal] Your application for registering [Provider Name] as a new EOSC Provider to the EOSC Portal has been approved | ||||||||||
| ||||||||||
Action 5.2: Mail to the AARP to acknowledge rejection of Provider application | ||||||||||
From: noreply@[...].eu To: [User email] CC: onboarding@[...].eu Subject: [EOSC Portal] Your application for registering [EOSC Provider Name] as a new EOSC Provider to the EOSC Portal has been rejected | ||||||||||
| ||||||||||
Action 5.3: Mail to the EPOT after approval of Provider application. | ||||||||||
From: noreply@[...].eu To: onboarding@[...].eu Subject: [EOSC Portal] The application of [Provider Name] ([Provider ID]) for registering as a new EOSC Provider has been approved | ||||||||||
Dear EOSC Portal Onboarding Team, The application by [user name] – [user email] for registering [Provider Name] ([Provider ID]) has been approved. You can view the application status here [link to the application page]. | ||||||||||
Action 5.4: Mail to the EPOT after rejection of Provider application | ||||||||||
From: noreply@[...].eu To: onboarding@[...].eu Subject: [EOSC Portal] The application of [Provider Name] ([Provider ID]) for registering as a new EOSC Provider has been rejected | ||||||||||
Dear EOSC Portal Onboarding Team, The application by [user name] – [user email] for registering [EOSC Provider Name] ([EOSC Provider ID]) has been rejected. You can view the application status here [link to the application page]. Please contact xxx@xxx.xx to be informed about the rejection evidence. | ||||||||||
Stage 7a. The AARP applies for onboarding a Resource | ||||||||||
Action 7a.1: Mail to AARP to Acknowledge Reception of Resource Application | ||||||||||
From: noreply@[...].eu To: [User email] CC: onboarding@[...].eu Subject: [EOSC Portal] Your application for registering [Resource Name] as a new Resource to the EOSC Portal has been received and is under review | ||||||||||
| ||||||||||
Action 7a.2: Mail to the EPOT to approve or reject the Resource application. | ||||||||||
From: noreply@[...].eu To: onboarding@[...].eu Subject: [EOSC Portal] A new application for registering [Resource ID] as a new Resource to the EOSC Portal has been received and should be reviewed | ||||||||||
Dear EOSC Portal Onboarding Team, A new application by [user name] – [user email] has been received for registering [Resource Name] - [Resource ID], as a new Resource of [Provider Name] ([Provider ID]). You can review the application here [link to application page] and approve or reject it. | ||||||||||
Stage 8. The EPOT reviews the newly onboarded Resources | ||||||||||
Action 8.1: Mail to the AARP to acknowledge approval of Resource application | ||||||||||
From: noreply@[...].eu To: [User email] CC: onboarding@[...].eu Subject: [EOSC Portal] Your application for registering [Resource Name] as a new Resource to the EOSC Portal has been approved | ||||||||||
| ||||||||||
Action 8.2: Mail to the Authorized Representative of the Provider to acknowledge rejection of Resource application | ||||||||||
From: noreply@[...].eu To: [User email] CC: onboarding@[...].eu Subject: [EOSC Portal] Your application for registering [Resource Name] as a new Resource to the EOSC Portal has been rejected | ||||||||||
| ||||||||||
Action 8.3: Mail to the EPOT after approval of Resource application | ||||||||||
From: noreply@[...].eu To: onboarding@[...].eu Subject: [EOSC Portal] The application of [Resource Name] ([Resource ID]) for registering as a new Resource has been approved | ||||||||||
Dear EOSC Portal Onboarding Team, The application by [user name] – [user email] for registering [Resource Name] ([Resource ID]) of [Provider Name] ([Provider ID]) has been approved. You can view the application status here [link to the application page]. | ||||||||||
Action 8.4: Mail to the EOSC Portal Onboarding Team after rejection of Resource application | ||||||||||
From: noreply@[...].eu To: onboarding@[...].eu Subject: [EOSC Portal] The application of [Resource Name] ([Resource ID]) for registering as a EOSC Resource has been rejected | ||||||||||
Dear EOSC Portal Onboarding Team, The application by [user name] – [user email] for registering [Resource Name] ([Resource ID]) of [Provider Name] ([Provider ID]) has been rejected. You can view the application status here [link to the application page]. | ||||||||||