EOSC Portal - A gateway to information and resources in EOSC

Press [ esc ] or close+

Introduction

The EOSC Portal Onboarding Process is the process that an EOSC Provider must follow to register the Provider and its Resources in the EOSC Portal Registry. The ESOC Registry provides EOSC System Users with a list of live/ready-to-use descriptions of EOSC Resources offered by the EOSC System. Every entry of the EOSC Registry must comply with and be described and updated following the EOSC Portal Interoperability Framework. The EOSC Portal Interoperability Framework includes, among others the EOSC Profiles, the EOSC Rules of Participation (RoP) and the EOSC Portal Application Programming Interface (APIs) methods for the automatic provisioning and synchronisation of information between Providers’ systems and the EOSC Portal. The EPOP is fundamental is achieving trust in the EOSC by checking compliance to the EOSC RoP and the EOSC Profiles.

 

Prior Efforts

The 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 and the EOSC launch in 2018. This First version of the EOSC Portal onboarded many 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 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. 

From 2019 to 2021 EOSC Enhance was responsible to further develop, optimise and coordinate the onboarding function and related interfaces of the EOSC Portal. In this framework, EOSC Enhance was responsible to unify and specify, develop and operate a single onboarding process for all EOSC Providers. 

 

EOSC Portal Onboarding Process v3.00

EOSC Enhance D2.2 – EOSC Processes development and consensus, unified and specified the EOSC Portal Onboarding Process (EPOP) v3.00 and provided the basic information for the EPOP operations. The EPOP operations were overlooked by EOSC Enhance in collaboration with EOSC-hub initially and currently with ESOC Future, which staff the process while the tooling comes from EOSC Enhance. The EPOP is implemented by the EOSC Providers Component of the EOSC Portal developed by eInfraCentral and upgraded in EOSC Enhance. 

EPOP v3.00 was 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. EPOP v3.00 reflected 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. 

EPOP v3.00 specified only the onboarding of Providers and their Resources; and was organised in 3 distinct Phases implemented in 10 Stages. EPOP v3.00 defined also the EOSC Portal Onboarding Team (EPOT) roles and responsibilities and the messaging for informing Providers and the EPOT on next (or pending) steps on the EPOP.

The EPOP is supported by the EPOT Backend interface. The EPOT utilises an additional software platform to keep track of the applications’ onboarding progress. The ticketing system is based on the Jira suite modified accordingly to cope with the requirements of the process. The tooling is presented in D2.2 – EOSC Processes development and consensus.

 

EOSC Portal Onboarding Process v4.00

After v3.00 was adopted and implemented successfully at the EOSC Portal, EOSC Enhance received several Requests for Changes (RfCs) for the EOSC Portal Onboarding Process. Among those are:

  • Several requirements reviewed and approved via the EOSC Portal Change Management Process and listed in Table 5‑1.
  • The Ordering Capability (additional onboarding Phase).
  • The updates on the Quality Assurance and Feedback Processes (see next Chapter).
  • The onboarding of trusted Multi-Provider Regional and Thematic Portals (MPRTP) (additional distinct EPOP to cover cases where the Requestor is not the owner of the Resources but rather an aggregator, broker or of other similar roles).

 

Table 1: EOSC Portal Onboarding Process Requests for Change

Jira ID

EOSC Portal Onboarding Process Requests for Change (RfC)

Subject

EOSCENR-212

Activate Provider (incl. dashboard) even without a Resource onboarded

Single Provider

EOSCENR-213

Adjust Onboarding process for approving Provider and Resources

Single & Multi-Provider

EOSCENR-214

Add for each Resource the admin role at the Provider Component

Single Provider

EOSCENR-206

Prerequisite of minimum maturity level for listing Resources on the Portal

Single Provider

EOSCENR-210

New event for coexistence of Resources in user projects

Single Provider

EOSCENR-184

Fix silent failure of records which pass PC validation and fail UC validation

Single Provider

EOSCENR-202

Provide textbox for comments during Resource Update

Single Provider

EOSCENR-187

In the timeline view show also, who changed the records

Single Provider

EOSCENR-151

Automatically message Providers who have not updated their Profiles in the last x months

Single Provider

EOSCENR-152

Send automatic daily digest of EPOT and PP activity to EPOT mailing list

Single Provider

EOSCENR-115

Prospective providers can access a section with the full guidelines for the onboarding of National Catalogues & Registries

Multi-Provider

EOSCENR-116

National, Regional or Thematic Aggregators can onboard their resources in automated way

Multi-Provider

EOSCENR-174

Allow the option to onboard Providers via the API

Single & Multi-Provider

Based on the aforementioned requirements, 2 distinct EOSC Portal Onboarding Processes are defined in EPOP v4.00: a) for Single Providers like in v3.00 and b) for Aggregators and in particular for MPRTPs.

V4.00 EOSC Portal Onboarding Process for Single Providers

The current form includes 5 distinct Phases implemented in various Stages. As soon as each phase is concluded (approved or rejected), the user is notified to proceed accordingly. The following sections provide further details of the actions that take place in each of the workflow Stages.

 

Phases for the EOSC Portal Onboarding Process for Single Providers 

  • Phase 1: An Authorised Representative of a Provider (ARP) registers into the EOSC Portal.
  • Phase 2: The Authorised and Authenticated Representative of a Provider (AARP) onboards the Provider (organisation).
  • Phase 3: The AARP onboards the Resources offered by the Provider.
  • Phase 4: The AARP onboards the Options/Offerings of a Resource offered by the Provider.
  • Phase 5: The AARP and the EPOT maintain the quality of the Profiles.

Diagram</p>
<p>Description automatically generated

 

 

Stages of the Onboarding Process for Single Providers

  • Stage 1: The Representative of the Provider (RP) visits the EOSC Portal.
  • Stage 2: The RP registers with the EOSC Portal using an existing identity from a supported Social or Academic AAI mechanism.
  • Stage 3: The Authenticated Representative of the Provider (ARP) logs into the EOSC Portal.
  • Stage 4: The ARP asserts he/she is an Authorized Representative of a Provider.
  • Stage 5: The Authenticated and Authorized Representative of a Provider (AARP) apply to onboard the Provider.
  • Stage 6: The EOSC Portal Onboarding Team (EPOT) reviews the newly onboarded Provider.
  • Stage 7: The AARP gets access to the Portal Dashboard.
  • Stage 8: The AARP selects the method to onboard Resources.
  • Stage 9a: The AARP applies to onboard a Resource via the Web Interface or Stage 9b: The AARP applies to onboard a Resource via the API.
  • Stage 10: The EPOT reviews the newly onboarded Resources.
  • Stage 11: The AARP can review the Resource at the Portal Dashboard and can apply to onboard other Resources via the API or Web Interface.
  • Stage 12: The AARP applies to onboard Resource Options/Offerings.
  • Stage 13: The EOSC Portal Onboarding or Ordering Team reviews the onboarded Resource Options/Offerings.
  • Stage 14: The EPOT creates a Review and Feedback Report
  • Stage 15: Upon Request of Providers the EPOT can provide best practices, feedback, and consultation to Providers.​
  • Stage 16: Profiles on the EOSC Portal are updated by Providers and periodically audited by the EPOT.

 

 

Flow Diagram of the Onboarding Process for Single Providers 

 

 

 

Detailed Description of the Onboarding Process Stages for Single Providers

No.

Stage

Description-Actions

Phase 1: Provider Representative Onboarding

Α1

The Representative of the Provider visits the Portal

A Representative of the Provider (RP) [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 authorized to act on behalf of the Provider at this stage.

[2] https://providers.eosc-portal.eu/becomeAProvider

[3] https://providers.eosc-portal.eu/provider/add

Text</p>
<p>Description automatically generated

 

 

A2

The Representative of the Provider registers with the Portal using an existing identity from a supported Social or Academic AAI mechanism

The RP uses the Authentication and Authorization Infrastructure (AAI) mechanisms supported by the Portal [4] to register with the Portal. 

In case any difficulties arise during the Authentication, the Representative may communicate issues [5] and depending on the issue, the AAI Team may organise a 1-to-1 call to offer guidance.

[4] Currently supported AAI mechanisms: eduTeams, EGI CheckIn, OpenAIRE, EUDAT, B2ACCESS, Aria, Dariah, IGTF, OpenMINTED, ORCID, etc. and AAI mechanisms of many Academic and Research Institutions worldwide. If a Provider representative cannot authenticate via one of the provided Academic AAI proxies, the representative can authenticate via a Google identity account.

[5] https://www.eosc-portal.eu/helpdesk or use the feedback ribbon.

Graphical user interface, application</p>
<p>Description automatically generated

A3

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.

 

Graphical user interface, application</p>
<p>Description automatically generated

 

Text</p>
<p>Description automatically generated

A4

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] https://eosc-portal.eu/privacy-policy-summary

Graphical user interface, application, Teams</p>
<p>Description automatically generated

 

 

 

Phase 2: Provider (Organisation) Onboarding

A5

The Authenticated and Authorized Representative of a Provider applies to onboard the Provider

Now 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. 

If any difficulties arise during the application, the AARP may communicate issues [8]. Depending on the issue, the EOSC Portal Onboarding Team (EPOT) may organize a 1-to-1 call to offer guidance. 

Upon successful submission: a) the AARP and the EPOT are notified, and b) an onboarding ticket is opened.

The EPOT reviews the ticket from the Provider and updates it with any additional information deemed necessary.

[7] The Profile is available to download and preview in various formats at https://eosc-portal.eu/providers-documentation/eosc-provider-portal-provider-profile

[8] at onboarding@eosc-portal.eu or using the feedback ribbon.

Graphical user interface, text, application, email</p>
<p>Description automatically generated

A6

The Portal Onboarding Team reviews the newly onboarded Provider

The EPOT reviews the Provider description by checking 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 recommendations (if any) for improvement. 

If the Provider Profile description does not comply with the minimum requirements, 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 description. The ticket is updated, and the recommendations are 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.

The Provider may be rejected at this step as not within the allowed range of organizations expected to act as Providers. Otherwise, the AARP is notified of the approval. Approval or rejection notifications are sent automatically by the Portal. The EPOT updates the status of the onboarding ticket.

A screenshot of a computer</p>
<p>Description automatically generated

A7

The Authenticated and Authorized Representative of the Provider gets access to the Portal Dashboard

Once the Provider is approved, the Provider is visible publicly, can use the Providers' Dashboard [9] and can be added as a (co) Provider on Resources, etc.

Providers are required to maintain and update their descriptions at least once per year via the Dashboard.

[9] https://providers.eosc-portal.eu/dashboard/

 

Graphical user interface, application</p>
<p>Description automatically generated

 

 

 

Phase 3: Resource Onboarding

A8

The Authenticated and Authorized Representative of the Provider selects the method to onboard the Resources

The AARP logins (if not already logged in) to the Portal and may proceed with the onboarding of Resources. 

The AARP is offered two options to onboard Resources: a) via a web interface for each Resource individually or b) via the Portal Application Programming Interface (API).

If the web interface is selected, then Stage A9a follows; otherwise, Stage A9b.

 

Graphical user interface, application</p>
<p>Description automatically generated

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

A9a

The Authenticated and Authorized 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 [10].

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 [11], and depending on the issue, the EPOT may organise a 1-to-1 call to offer guidance.

Otherwise, if the Profile is completed and passes all checks, it can be submitted.

When the Profile is submitted, the AARP is queried if additional Resources will be onboarded. If yes, then step A9a is repeated; otherwise, the process moves to step A10.

[10] The Profile is available to download and preview in various formats at https://eosc-portal.eu/providers-documentation/eosc-provider-portal-resource-profile

[11] at onboarding@eosc-portal.eu or using the feedback ribbon.

Graphical user interface, application</p>
<p>Description automatically generated

A9b

The Authenticated and Authorized 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. 

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 is available [12]. 

In case any difficulties arise during the employment of the API, the AARP may communicate issues [13]. Depending on the issue, the EPOT may organize a 1-to-1 call to offer guidance.

[12] https://providers.eosc-portal.eu/openapi

[13] onboarding@eosc-portal.eu or using the feedback ribbon.

 

Graphical user interface, text, application</p>
<p>Description automatically generated

 

Text</p>
<p>Description automatically generated

A10

The Portal Onboarding Team reviews the newly onboarded Resources 

For each Resource to be onboarded, the EPOT examines whether the Resource has been already onboarded by any other Providers and if this the case, tries to resolve the issue.

The EPOT examines the quality of the metadata, if they follow the general recommendations and guidance of the Resource Profile, spelling, accuracy, composition and URLs.

If the Resource description does not comply with the minimum requirements of the Portal and the rules and criteria based on the current RoP and the typology of the Resource Profile, the AARP may be asked to take action (e.g. amend the description and resubmit, etc.) or join an information/training session. In this, often 1-to-1 call, the AARP will have the chance to ask questions and get personalized consultation on the best way to onboard the Resources. 

To facilitate the amendment, the EPOT provides recommendations taking into account potential Provider's peculiarities, reviews the Provider’s website, its catalogue and provided URLs and proposes alternatives for the description of the Resource’s metadata, and provides best practice examples from other Providers. 

The Resource may also be rejected if the Provider fails to update the Resource accordingly. The Provider receives a notification of the definitive Resource Onboarding rejection and possibly Provider suspension. 

The EPOT may also perform small corrections on the Resource descriptions and ask for the Provider's consent before publishing.

Graphical user interface, application</p>
<p>Description automatically generated

A11

The Authenticated and Authorized Representative of a Provider can review the Resource at the Portal Dashboard and can apply to onboard other Resources via the API or web interface

Once the Resource is approved, it is visible publicly, and the AARP can use the Providers' Dashboard to maintain and review the descriptions at least once per year by either using the pencil button or clicking on the name of the Resource. 

The Dashboard also offers statistics for Resources, and a reach set of additional functionalities that are constantly being enriched such as active Resources, pending to be approved Resources, messages, information/statistics regarding ordering etc.

On the Dashboard the AARP can now proceed to onboard other Resources via the web interface or the API.

 

Graphical user interface, application</p>
<p>Description automatically generatedGraphical user interface, text, application, email</p>
<p>Description automatically generated

Phase 4: Option/Offering Onboarding

A12

The Authenticated and Authorized Representative of a Provider applies to onboard Resource Options/Offerings

The AARP may apply for onboarding a Resource Option/Offering by completing the Option/Offering Profile currently at the EOSC Portal User Component. This is available to orderable resources only.

Currently the SOMBO Order Management System is integrated and used to handle the orders. The registered Providers may select to use their own Order Management System for integration or use SOMBO to receive information about submitted orders.

Orders for resources are placed in the EOSC Portal User Component, which then need to be passed on to Providers' systems for handling, and to SOMBO for user support.

Table</p>
<p>Description automatically generated

 

 

 

 

 

 

 

 

 

 

A13

The Portal Onboarding Team reviews the onboarded Resource Options/Offerings

All newly onboarded Resource Option/Offering and their representation in EOSC Portal User Component are reviewed by the EPOT. 

Graphical user interface, text, application, chat or text message</p>
<p>Description automatically generated

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Phase 5: Maintenance and Quality Assurance

A14

The Portal Onboarding Team creates a Review and Feedback Report

After the first Onboarding round and then periodically a Review and Feedback Report that assesses the Provider and Resources descriptions is produced by the EPOT.

The Review and Feedback Report is based on 106 attributes assessed in a quantity and quality-based manner and provides general recommendations to improve their Profiles.

 

 

 

 

 

 

A15

Upon Request of Providers the EOSC Portal Onboarding Team can provide best practices, feedback, and consultation to Providers

Upon request by any Provider the EPOT may provide practices for the Providers to enhance and improve their Profiles. Feedback can be provided with an additional Report.​

Graphical user interface, text, application</p>
<p>Description automatically generated

Graphical user interface, text, application</p>
<p>Description automatically generated

 

 

A16

Profiles on the EOSC Portal are updated by Providers and periodically audited by the EOSC Onboarding Team

Periodically the EPOT audits the catalogue records, and Providers may be requested to update their Profiles within an agreed and stated timeframe; otherwise, the Provider and/or Resource may be suspended until updated. 

Also due to a updates in Profile specifications or functionality (new RoP, new Profiles, new features, etc.) Providers are requested to review their Provider and Resource descriptions to ensure they still meet the new rules and criteria and all required information.

Possible changes are highlighted to the Providers. Providers must update their services within an agreed and stated timeframe; otherwise, the service may be suspended until updated. 

In case the Provider is suspended: the Provider cannot submit new resources, existing Resources are suspended while in this state but reactivated if the Provider is re-approved, the Provider can edit records for the Provider and already onboarded Resources, but they are not published. Where a Provider is a Provider Organisation for a Resource from another Resource organisation, they are greyed out. 

 

 

Graphical user interface, application</p>
<p>Description automatically generated

 

v4.00 EOSC Portal Onboarding Process for Aggregators/Multi-Provider Portals

Requirements EOSCENR-115 and EOSCENR-116 asked for the capability to onboard “National Catalogues and Registries” and “National, Regional or Thematic Aggregators” in an automated way” to the EOSC Portal.

The requirements were analysed and led to a pilot implementation to onboard to the EOSC Portal  Regional or Thematic Portals with multiple providers and their resources and to synchronize the metadata between the EOSC Portal and the MPRTPs.

The first pilot was implemented with the NI4OS project. The implementation of the NI4OS pilot revealed several technical and policy-related aspects for the onboarding of Aggregators/Multi-Provider Portals to the EOSC Portal that need to be further examined and resolved.

These aspects include the deduplication of records, the bidirectional synchronization of records, the administration rights for the Providers and Resources registered at both Portals, the need of a framework or customised agreement for each of the Portals to be integrated into EOSC Portal, etc.

One of the major updates of the EOSC Portal Interoperability Framework made for addressing some of the aforementioned issues, is the introduction of a new Profile for the EOSC Portal Multi-Provider Catalogue and the relevant updates of EOSC Portal Provider and Resource Profiles (introduction of a new attribute “Catalogue” to link to the MPRTP)

Bidirectional synchronisation should be allowed in the future. In this case, the prevailing metadata to overwrite the other will be the one lastly updated (based on timestamp) and therefore the Authorized representative(s) of a Provider must be aware that any change introduced to metadata in one Portal will be communicated to the other one as well.

This is a requirement that will be handed over to EOSC Future.

Furthermore, the onboarding of an MPRTP should have as a prerequisite to sign an agreement with the EOSC Portal to abide by the EOSC Rules of Participation, EOSC Portal Onboarding Process and\or any other assumptions to allow for representing and managing the resources of its providers in the EOSC portal. This is also handed over to EOSC Future.

Τhe Onboarding Process v4.00 for the MPRTP  is very similar to the Onboarding Process of the Single Provider and includes 5 Phases and 19 distinct Stages.

An updated version of the EPOP for an MPRTP v4.00 must be developed once all previously mentioned issues are fully resolved.

The 5 Phases of the MPRTP EPOP v4.00 are:

  • Phase 1: An Authorised Representative of MPRTP registers into the EOSC Portal.
  • Phase 2: The Authorised and Authenticated Representative of an MPRTP (AARM) onboards the Providers registered at the MPRTP.
  • Phase 3: The AARM onboards the Resources registered at the MPRTP.
  • Phase 4: The AARM onboards the Options/Offerings of Resources offered by the Providers registered at the MPRTP.
  • Phase 5: The AARM and the EPOT maintain the quality of the Profiles.

The 19 Stages of the MPRTP EPOP v4.00 are:

  • Stage 1: The Representative of the MPRTP (RM) visits the EOSC Portal.
  • Stage 2: The RM registers with the EOSC Portal using an existing identity from a supported Social or Academic AAI mechanism.
  • Stage 3: The Authenticated Representative of the MPRTP (ARM) logs into the EOSC Portal.
  • Stage 4: The ARM asserts he/she is an Authorized Representative of an MPRTP.
  • Stage 5: The Authenticated and Authorized Representative of an MPRTP (AARM) apply to onboard the MPRTP.
  • Stage 6: The EOSC Portal Onboarding Team (EPOT) reviews the newly onboarded MPRTP.
  • Stage 7: The AARM gets access to the Portal Dashboard.
  • Stage 8: The AARM logs into the API Token Portal.
  • Stage 9: The AARM selects to Get the Value of the Access Token.
  • Stage 10: The AARM selects to Create a Refresh Token.
  • Stage 11: The AARM selects to Manage all Access/Refresh Tokens.
  • Stage 12: The AARM onboards the MPRTP Providers into the EOSC Portal using the Token acquired.
  • Stage 13: The AARM onboards the Resources of the MPRTP Providers on the EOSC Portal with the token acquired.
  • Stage 14: The EPOT reviews the onboarded MPRTP Providers and Resources.
  • Stage 15: The AARM or the MPRTP Provider Managers may onboard Options/Offerings of the Resources of the MPRTP Providers.
  • Stage 16: The EOSC Portal Onboarding or Ordering Team reviews the Resource Options/Offerings of the MPRTP Providers’ Resources.
  • Stage 17: The EPOT creates a Review and Feedback Report.
  • Stage 18: Upon Request of MPRTPs the EPOT can provide best practices, feedback, and consultation to MPRTPs.​
  • Stage 19: Profiles on the EOSC Portal are updated by MPRTPs and periodically audited by the EPOT.

The following table provides further details of the actions that take place in the workflow Stages 8-13.

 

 

No.

Stage

Description-Actions

B8

The AARM logs into the API Token Portal

A AARM [1] visits the Providers API Token Portal by entering the following URL in a browser: https://aai.eosc-portal.eu/providers-api and clicks on “Authorise”.

[1] it is assumed that the Representative of the MPRTP (to be confirmed via an agreement to be established):

  • There is a common onboarding process/method applied to both portals ('trusted') complying to the EOSC Portal Interoperability Framework, including the EOSC Portal Profiles, code lists, taxonomies and controlled values, Onboarding Process and RoP.
  • Providers registered at the MPRTP have agreed on the Terms of Use and Privacy Policy of EOSC Portal
  • Providers will update their Resources only at the MPRTP and not the EOSC Portal (unidirectional synchronization).
  • Resources and Providers in the EOSC Registry are linked to the original hosting catalogue.
  • There is a unique ID for Providers which must be common in both portals.

 

Graphical user interface, application</p>
<p>Description automatically generated

 

Graphical user interface, text, application, email</p>
<p>Description automatically generated

 

 

B9

The AARM selects to Get the Value of the Access Token

After successful authentication, the AARM is redirected to the Providers API token portal. Then she/he will be able to perform the following actions in the “My Access Token” tab [2]:

  • Get the value of the Access Token (Go to step B5a)
  • Create a Refresh Token (Go to step B5b).
  • Manage all Access/Refresh Tokens obtained by the EOSC Portal AAI.

The Representative of the MPRTP can Get the value of the Access Token and use it directly in an API call:

Click on the “Copy” button under the “Access Token” label and then add it to your HTTP request.

[2] New Access Tokens expire in 1 hour, but the Token Portal also allows for obtaining Refresh Tokens which are valid for approximately 13 months. A Refresh Token is a special kind of token used to obtain a renewed Access Token. Fresh Access Tokens can be requested using a Refresh Token until that token expires or gets revoked.

Example: Make a request from Terminal

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

B10

The AARM selects to Create a Refresh Token

The AARM can Create a Refresh Token by clicking on the “Create Refresh Token” button. Then 2 new fields will appear with the following actions:

  • Get the value of the Refresh Token.
  • Request the token endpoint to generate an Access Token using the Refresh Token.

The Representative of the MPRTP shall then click on the “Copy” button under the “To generate access tokens from this refresh token use the following curl command” label and paste the command in the terminal.

 

Graphical user interface, text, application, email</p>
<p>Description automatically generated

 

 

 

 

 

 

 

 

 

 

 

 

 

B11

The AARM selects to Manage all Access/Refresh Tokens

The AARM can Manage all Access/Refresh Tokens that have been obtained by the EOSC Portal AAI by following the link: https://aai.eosc-portal.eu/oidc/manage/user/services.

In the “My Refresh Tokens” tab the Representative of the MPRTP can see all active Refresh Tokens that have been created by this portal.

The Representative of the MPRTP can copy the value of the refresh Token or “deactivate” the Token by clicking on the “Revoke” button. This action is irreversible.

Graphical user interface, application</p>
<p>Description automatically generated

 

B12

The AARM registers the MPRTP Providers into the EOSC Portal using the Token acquired

Upon successful completion of step B4, the Representative of the MPRTP registers the MPRTP Provider(s) via the API using the token acquired:

curl \

--header "Authorization: Bearer $token" \

--header "Content-Type: Application/json" \

--data "$escapedJson" \

https://sandbox.providers.eosc-portal.eu/api/provider

A FLAG is created in which the Provider(s) submitted the first resource as Resource Organisation.

B13

The AARM registers the Resources of the MPRTP Providers on the EOSC Portal with the token acquired

Following the successful completion of step B7, the Representative of the regional/thematic portal may onboard subsequent Resources, as per step B7 above.

Subsequent resources are automatically approved, but there is a flag that these are transferred from another catalogue. This is a filterable characteristic for EPOT (filter catalogue transfers, filter by specific catalogue). EPOT will audit these records periodically.