Functional requirements per role

This part of the iSHARE Trust Framework is considered normative and is therefore compliant with RFC 2119.

This chapter summarises the responsibilities and functional requirements per role:

• Adhering roles:

  • Service Consumer;

  • Service Provider;

  • Entitled Party.

• Certified roles:

  • Identity Provider;

  • Identity Broker;

  • Authorisation Registry;

  • Participant Registry.

One requirement to any legal entity fulfilling a role is that they MUST provide a unique identifier.

Existing JWT-based flows remain supported; roles MAY use either mechanism where stated.

---

Adhering roles

Please refer to the detailed Operation descriptions for what criteria need to be met to be onboarded as iSHARE compliant participant.

Service Consumer

The Service Consumer role is fulfilled by a participant who consumes a service, such as data, as provided by a Service Provider. A Service Consumer can be represented by:

1. Machine Service Consumer (MSC): uses the organisation’s certificate (eSeal/X.509) to onboard;

2. Human Service Consumer (HSC): onboarded via an iSHARE-certified Identity Provider/Broker (no own certificate)

The functional requirements applicable to Service Consumers are as follows:

• iSHARE adherence is REQUIRED;

• For technical requirements, refer to Service Consumer getting started in the developer portal.

Service Provider

The Service Provider role is fulfilled by a participant who provides a service, such as data, for consumption by a Service Consumer.

The functional requirements applicable to Service Providers are as follows:

• iSHARE adherence is REQUIRED;

• All user interfaces provided in an iSHARE context MUST comply with the iSHARE's user interface requirements;

• Service Provider MUST discover the Authorisation Registry (AR) internally for the requested capability before requesting delegation evidence.

  • either because the Service Provider and Entitled parties have shared an AR internally;

  • or from the EP’s /capabilities ; if absent, through the Participant Registry, as described in Authorisation Registry discovery logic;

  • When an Identity Provider provides an authorisation link, the Service Provider MAY use the link and MUST verify the Authorisation Registry through the Participant Registry afterwards.

• For technical requirements, refer to Service Provider getting started in the developer portal.

Entitled Party

The Entitled Party is the participant that holds one or more legitimate rights regarding access to, use of, or control over data and/or data services provided by a Service Provider (role).

This may include:

• The right to access or consume a data service (e.g. retrieve or send data)

• The right to exercise legal or contractual control over the data itself (e.g. data ownership, stewardship, or regulatory responsibility)

Entitled Party, Service Consumer and Service Provider roles can be fulfilled by the same participant (for example, a trucking company's entitlement to request Estimated Time of Arrival and optimal route information), but this is not necessary.

The Entitled Party can also delegate its rights to another Service Consumer. In the latter case, this other Service Consumer (or its machines and humans) may consume services on the Entitled Party’s behalf, but it is not necessary.

The functional requirements applicable to Entitled Parties are as follows:

• Entitled Party MUST make available to the Service Provider which Authorisation Registry holds delegation evidence by either direct communication, or publishing it per capability in its /capabilities endpoint or by registering it in the Participant Registry, as described in Authorisation Registry discovery logic.

• Entitled Party MAY use different Authorisation Registries for different capabilities or data spaces.

• If the Entitled Party operates its own Authorisation Registry, it MUST meet the Authorisation Registry functional requirements, with the exception that it only provides delegation evidences for itself and not for someone else. In this setup the Entitled Party is an adhering party (not a certified Authorisation Registry).

• If the Entitled Party also acts as a Service Provider, it MUST meet the Service Provider functional requirements for its own services.

• iSHARE adherence is REQUIRED;

  • Note: As the Service Provider determines the Entitled Party, the Service Provider may provide services where the Entitled Party is not iSHARE-adherent. In that case, the Service Provider proxies on the Entitled Party’s behalf under a binding legal agreement, MUST be able to evidence that agreement, and assumes the Entitled Party’s responsibilities and liabilities towards other iSHARE participants for the proxied scope.

• For technical requirements, refer to Entitled Party getting started in the developer portal.

---

Certified roles

Please refer to the detailed Operation descriptions for what criteria that need to be met to be admitted to the iSHARE network.

Identity Provider

The Identity Provider role is fulfilled by a participant whose tooling identifies and authenticates humans (and specifically, Human Service Consumers representing Service Consumers). An Identity Provider:

• Provides identifiers for humans;

• Issues and manages credentials (i.e. a password or electronic keycard) for humans;

• Receive authentication requests from Service Providers;

• Provides an online interface to authenticate humans based on their credentials.

• Can hold information on authorisations of humans representing a Service Consumer; i.e. information indicating which humans are authorised to act on a Service Consumer's behalf;

• Can, after successful identification and authentication, based on this information, determine whether the human representing a participant is authorised to take delivery of a service;

• Can confirm the identity, authentication and authorisation information to the Service Provider, by providing an organizationIdentifier attribute, compliant to ETSI EN 319 412-1 section 5.1.4.

As a result, Service Consumers are able to re-use their existing identities to authenticate themselves to different service providers whilst allowing Service Providers to optimise their software and processes while being able to serve larger number of consumers

The functional requirements applicable to Identity Providers are as follows:

• The Identity Provider MUST have a clear agreement with the Authorisation Registry concerning the process of allowing the registration, updating or removal of an authorisation;

• The Identity Provider MUST prevent a revoked authorisation from being processed as a valid authorisation;

• The Identity Provider MUST ensure that the identification and authentication process conforms to the Level of Assurance requested by the Service Provider.

• The Identity Provider MUST conform to the service levels for Certified Parties as described here as minimum or as extended by respective data space;

• The Identity Provider MUST NOT claim accordance with a Level of Assurance for which it has not been certified;

• The processes of the Identity Provider MUST be in accordance with the Level of Assurance for which the Identity Provider has been certified;

• The Identity Provider MUST be listed in a Participant Registry as a participant in the role of Identity Provider (certified role) with level of assurance and compliance status;

• All user interfaces available in an iSHARE context MUST comply with the iSHARE's user interface requirements;

• For technical requirements, refer to Identity Provider getting started in the developer portal.

---

Identity Broker

Different humans might hold identifiers at different Identity Providers. Also, Service Providers might need to connect to several Identity Providers. To make sure Service Providers do not need a relationship with each Identity Provider individually, an Identity Broker is introduced. The Identity Broker role is fulfilled by a participant that provides Service Providers access to different Identity Providers, and that offers humans the option to choose with which Identity Provider to identify and authenticate themselves throughout the iSHARE Scheme.

An Identity Broker is an OPTIONAL intermediary that lets a Service Provider access multiple Identity Providers through one integration and lets humans choose an Identity Provider. iSHARE already enables direct Service Provider to Identity Provider connections; a broker is used only for consolidation and value-adds. For example, if Service Providers choose to outsource identification and authentication to more than one Identity Provider, they can connect to an Identity Broker instead of to several Identity Providers.

The functional requirements applicable to Identity Brokers are as follows:

• The Identity Broker MUST provide users with an interface to select their Identity Provider.

• The Identity Broker MUST conform to the service levels for Certified Parties as described here;

• The Identity Broker MUST NOT claim accordance with a Level of Assurance for which it has not been certified by the Scheme Owner;

• The processes of the Identity Broker MUST be in accordance with the Level of Assurance for which the Identity Broker has been certified;

• The Identity Broker MUST be listed in a Participant Registry as a participant in the role of Identity Broker (certified role) with level of assurance and compliance status;

• All user interfaces available in an iSHARE context MUST comply with the iSHARE's user interface requirements;

• For technical requirements, refer to Identity Broker getting started in the developer portal.

---

Authorisation Registry

The Authorisation Registry role is fulfilled by a participant who provides delegation evidence as proof of delegations on behalf of entitled parties to other parties. An Authorisation Registry:

• Can hold information on delegations to Service Consumers; i.e. information indicating what parts of the rights of an Entitled Party are delegated to a Service Consumer;

• Has a process in place allowing for the registration, update and revocation of delegations;

• Can check, based on this information, whether a participant is authorised to take delivery of a service;

• Can confirm whether this is the case with the Service Provider.

As a result, Adhering Parties can outsource tasks concerning the management of delegation information to an Authorisation Registry instead of implementing their own tooling.

The functional requirements applicable to Authorisation Registries are as follows:

• The Authorisation Registry MUST have a clear agreement with the delegating entity concerning the process of allowing the registering, updating or removing of a delegation;

• The Authorisation Registry MUST prevent that a revoked delegation is processed as a valid delegation;

• The Authorisation Registry MUST conform to the service levels for Certified Parties as described here;

• The Authorisation Registry MUST NOT claim accordance with a Level of Assurance for which it has not been certified by the Scheme Owner;

• The Authorisation Registry MAY support receiving and processing delegation creation requests in line with iSHARE specifications;

• The processes of the Authorisation Registry MUST be in accordance with the Level of Assurance for which the Authorisation Registry has been certified;

• The Authorisation Registry MUST be listed in a Participant Registry as a participant in role of Authorisation Registry (certified role) with level of assurance and compliance status;

• For technical requirements, refer to Authorisation Registry getting started in the developer portal.

---

Participant Registry

The Participant Registry role is fulfilled by a participant who validates and onboards the participants into the data space. The Data Space Governance Body defines the requirements and governs the process of onboarding participants into the data space. A Participant Registry:

• Can hold information on all participants in the data space; i.e. information indicating their level of assurance, services offered and roles performed in the data space.

• Has processes and criteria in place allowing for the onboarding or registration, update and review of participants;

• Can confirm whether a participant is a member of the data space.

• Can register and maintain claims for participants that are registered by other Participant Registries, provided that such claims are within the scope of the data space it governs and that mandatory validation requirements are fulfilled before claim submission.

The functional requirements applicable to Participant Registries are as follows:

• The Participant Registry MUST have a clear process and criteria agreed with the data space (governance body) concerning the onboarding, registering, updating or reviewing of a participant;

• The Participant Registry MUST conform to the service levels for Certified Parties as described here;

• The Participant Registry MUST NOT claim accordance with a Level of Assurance for which it has not been certified by the Scheme Owner;

• The processes of the Participant Registry MUST be in accordance with the Level of Assurance for which the Participant Registry has been certified;

• The Participant Registry MUST enable Service Providers to discover the Authorisation Registry through the Participant Registry when it is not declared in the Entitled Party’s /capabilities , following Authorisation Registry discovery logic.

• The Participant Registry MUST be listed in a Participant Registry as a participant in the role of Participant Registry (certified role) with level of assurance and compliance status.

• The Participant Registry MAY register and maintain claims (e.g., data space memberships, roles, or credentials) for participants that are registered by other Participant Registries. Such actions MUST follow the defined operational and governance processes, ensuring proper validation, authenticity, and traceability of claims.

• The Participant Registry, on behalf of the scheme owner, can also onboard participants to be compliant with the iSHARE framework, but not in a data space;

• For technical requirements, refer to Participant Registry getting started in the developer portal.