Functional requirements per role

Owned by Gerard van der Hoeven
Last updated: Oct 30, 2023 by Vinith Bhandari
5 min read

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:


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


Adhering roles

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

Service Consumer

The Service Consumer-role is fulfilled by a legal entity that consumes a service, such as data, as provided by a Service Provider. 

A Service Consumer can be represented by a machine (its system) or a human, fittingly called the Machine Service Consumer and the Human Service Consumer.

The functional requirements applicable to Service Consumers are as follows:

  • iSHARE adherence is REQUIRED. 

Service Provider

The Service Provider-role is fulfilled by a legal entity that provides a service, such as data, for consumption by a Service Consumer.

The functional requirements applicable to Service Providers are as follows:

Entitled Party

The Entitled Party-role is fulfilled by a legal entity that has one or more rights to a service provided by a Service Provider, for example to data. These rights, or entitlements, are established in a legal relation between the Entitled Party and the Service Provider.

The Entitled Party- and Service Consumer-roles can be fulfilled by the same entity - i.e. a legal entity that consumes a service based on its own entitlements to this service - but this is not necessary. Legal entities that are entitled to a service can delegate other entities to consume this service on its behalf: the legal entity consuming the service, then, does so on the basis of another entity's entitlements. In such use cases, as always, the Service Consumer consumes a Service Provider's service on the basis of the Entitled Party's entitlements, but the Service Consumer-role is fulfilled by another entity than the Entitled Party-role.

The functional requirements applicable to Entitled Parties are as follows:

  • iSHARE adherence is REQUIRED.
    • Note: as it is the responsibility of the Service Provider to determine the Entitled Party, the Service Provider can choose to provide services where the Entitled Party is not admitted to iSHARE. In this event, the responsibilities of the Entitled Party are shifted to the Service Provider in question. This is particularly useful for Service Providers who have existing (smaller) customers, who do not have own systems, or are only an Entitled Party for services at a single Service Provider.


Certified roles

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

Identity Provider

The Identity Provider-role is fulfilled by a legal entity 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, on the basis of this information, determine whether the human representing a legal entity is authorised to take delivery of a service;
  • Can confirm the identity, authentication and authorisation information to the Service Provider. 

As a result, Service Providers can outsource identification and authentication to an Identity Provider instead of implementing their own tooling. 

The functional requirements applicable to Identity Providers are as follows:

  • The Identity Provider MUST have a clear agreement with the authorising entity concerning the process of allowing the registering, updating or removing of an authorisation;
  • The Identity Provider MUST prevent that a revoked authorisation is 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;
  • The Identity Provider 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 Provider MUST be in accordance with the Level of Assurance for which the Identity Provider has been certified;
  • iSHARE certification is REQUIRED;
  • All user interfaces available in an iSHARE context MUST comply with the iSHARE's user interface requirements.

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 relation with each Identity Provider individually, an Identity Broker is introduced. The Identity Broker-role is fulfilled by a legal entity 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.

As a result, 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 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;
  • iSHARE certification is REQUIRED;
  • All user interfaces available in an iSHARE context MUST comply with the iSHARE's user interface requirements.

Authorization Registry

The Authorization Registry-role is fulfilled by a legal entity who provides solutions for Adhering Parties for the storage of delegation information. An Authorization 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, on the basis of this information, whether a legal entity is authorised to take delivery of a service;
  • Can confirm whether this is the case to the Service Provider. 

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

The functional requirements applicable to Authorization Registries are as follows:

  • The Authorization Registry MUST have a clear agreement with the delegating entity concerning the process of allowing the registering, updating or removing of a delegation;
  • The Authorization Registry MUST prevent that a revoked delegation is processed as a valid delegation;
  • The Authorization Registry MUST conform to the service levels for Certified Parties as described here;
  • The Authorization 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 Authorization Registry MUST be in accordance with the Level of Assurance for which the Authorization Registry has been certified;
  • iSHARE certification is REQUIRED.