Framework and roles

The iSHARE Trust Framework aims to provide generic building blocks for service provision, widely applicable in most sectors. This requires that the Framework can be applied to a wide variety of use cases in practice. This chapter explains the framework, its roles, and its relations, step by step.

Important (and as under technical overview)

APIs manage access to the services of an organisation, services that can be consumed by other parties. Services accessible through APIs can let those (machines or humans) that access the service do anything between reading simple data, receiving complex instructions, to adding information to a database.

If a truck's system sends a time and location to another party's Estimated Time of Arrival, for example, this service might respond with an optimal route to take and an Estimated Time of Arrival.

Within iSHARE, the terms 'service consumption' and 'service provision' are used to specify how parties interact with each other (with, in this example, the truck's owner, the Service Consumer, and the other party, the Service Provider).

Note that while the word data exchange is not literally in these terms, API service provision and consumption ALWAYS entail data exchange.

The iSHARE Framework consists of six roles that, depending on the situation, interact with each other based on the Trust Framework agreements. A party can fulfil multiple roles at the same time. Each role has a certain function in the framework and bears certain responsibilities, as described below:

Any party fulfilling a role in the iSHARE Trust Framework must be iSHARE adhering or iSHARE certified:

  • Parties fulfilling adhering roles, depicted in purple, provide and consume services under the iSHARE Trust Framework. These parties adhere to the iSHARE terms of use.

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 the iSHARE network. 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 their own systems, or are only an Entitled Party for services at a single Service Provider.

  • Parties fulfilling certified roles, depicted in grey, facilitate functions that Adhering Parties can rely upon when providing or consuming services. To become certified, these parties must not only prove adherence to the iSHARE terms of use but also meet several role-specific criteria.

Adhering roles

In any use case, the three adhering roles appear: a Service Consumer always consumes a Service Provider's service based on the Entitled Party's entitlements.

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. This legal entity is in need of the result of a service; for example, a trucking company that needs to know its optimal route and the Estimated Time of Arrival.

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

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. This legal entity provides the result of a service that Service Consumer(s) need; for example, the party that uses a truck's time and location to calculate and communicate the truck's optimal route and Estimated Time of Arrival.

Entitled Party

The Entitled Party is the legal person 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) with which it has a legal agreement.

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)

The Entitled Party, Service Consumer and Service Provider 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 (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.

For example, our trucking company could have been delegated the right to request Estimated Time of Arrival- and optimal route information by an Entitled Party that had originally planned to transport its goods itself, but instead hired the trucking company to do so. It therefore delegated its own right to request the Estimated Time of Arrival and optimal route information to the trucking company.

Certified roles

For the controlled provision and consumption of services, Adhering Parties (and specifically, the humans and machines representing them) must be identified, authenticated, and authorised. The tooling necessary for these processes can be implemented by Adhering Parties. Such tooling is expensive, however, and must be constantly updated to keep in line with the latest security standards. To make sure no such tooling needs to be implemented by Adhering Parties before they start providing or consuming services, the iSHARE Trust Framework recognises several certified roles fulfilled by legal entities that offer outsourced identification, authentication, and authorisation tooling to Adhering Parties.

As detailed under functional requirements per role, to become an iSHARE Certified Party, a legal entity must (first) be admitted as a participant by the Scheme Owner/Participant Registry (in the relevant role).

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 credentials (i.e. a password or electronic keycard) to humans;

  • Based on this identification information, it identifies and authenticates humans for Service Providers.

  • Holds 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 check, based on this information, whether a human representing a legal entity is authorised to take delivery of a service;

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

As a result, Service Providers can outsource the identification and authentication of humans, as well as tasks concerning the management of authorisation and delegation information of humans, to an Identity Provider instead of implementing their own tooling.

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 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 Trust Framework.

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.

Authorisation Registry

The Authorisation Registry role is fulfilled by a legal entity that provides solutions for Adhering Parties for the storage of delegation and authorisation information. An Authorisation Registry:

  • Can holds 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.

  • Can check, based on this information, whether a machine representing a legal entity 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 authorisation and delegation information to an Authorisation Registry instead of implementing their own tooling.

Participant Registry (previously called Satellite)

The Participant Registry ensures smooth membership management. All participants within the Data Space/iSHARE network will be explicitly linked to the Participant Registry responsible for their admission. The Participant Registry plays a fundamental role in any iSHARE use case. Every participant of the iSHARE Trust Framework can check with the Participant Registry whether other parties participate in iSHARE.

iSHARE compatible software

Next to iSHARE adherence and certification, the concept of iSHARE compatibility exists. This concept is reserved for software that technically adheres to the iSHARE Trust Framework (i.e. is iSHARE compatible), and can be sold to parties fulfilling adhering and certified roles. Note that parties using iSHARE-compatible software within an iSHARE context must adhere to or be certified, whereas a party that delivers iSHARE-compatible software does not need to be so.

Role of the Scheme Owner

The Scheme Owner role is fulfilled by the legal entity that keeps the Framework, and its network of participants, operating properly. How exactly is it found under the detailed Operational descriptions?

The Scheme Owner is responsible for admission of the Participant Registries and the overall maintenance of the iSHARE Trust Framework.

Please refer to the detailed descriptions for details on how the Scheme Owner facilitates and federates trust in the iSHARE Trust Framework.

Role of the Data Space Governance Body

The Data Space Governance Body role is fulfilled by the entity that is responsible for the data space, including the defining, evolving & maintaining and governing of participant life-cycle processes. This role can be fulfilled by a legal entity or by a non-legal entity (a group of parties with a certain governance). For reference, the definition of data spaces can be based on the iSHARE Data Space Template, and this body is responsible for defining, evolving and governing the building blocks therein.

The Data Space Governance Body can also be the Participant Registry for their data space. Please note that the Data Space Governance Body does not have an active role in any use cases within the iSHARE network.

NOTE: Legal entities can have both roles simultaneously, or a **Data Space Governance Body**could use (contract) a legal entity to fulfil the role of Participant Registry.

Framework and roles in use cases

All of iSHARE's use cases can be depicted in the iSHARE Trust Framework. Their complexity is dependent on:

  • The interaction model (Machine to Manon-legalHuman to Machine), i.e. whether the Service Consumer is represented by a machine or a human.

  • Whether delegation takes place, i.e. whether the Service Consumer-role is fulfilled by another entity than the Entitled Party-role. How delegations work exactly is explained here.

  • Whether parties fulfilling adhering roles use their own tooling for identification, authentication, and authorisation or outsource these processes and the information necessary for these processes to certified roles instead.

Hypothetically, and dependent on the above, a use case could include all of the following relations between roles:

NOTE: The only relation mandatory in all use cases is the relation between the Entitled Party and the Service Provider, which establishes the entitlements of the Entitled Party. In the depiction of use cases, all legal relations are shown before the actual interaction is plotted in the framework.

Last updated