Framework and roles
Last updated
Last updated
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 the wide variety of use cases possible 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 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, to 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'-service, for example, this service might respond with an 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 entails data exchange.
The iSHARE Framework consists of six roles that, depending on the situation, interact with each other based on the Trust Framework agreements. 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 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.
In any use case, the three adhering roles appear: a Service Consumer always consumes a Service Provider's service on the basis of the Entitled Party's entitlements.
| Adhering role: | Role description: |
|---|---|
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 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 a time and location to calculate and communicate the truck's optimal route and Estimated Time of Arrival. |
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 (for example, the trucking company's entitlement to request Estimated Time of Arrival- and optimal route information) - 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. Our trucking company, for example, 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 Estimated Time of Arrival- and optimal route information to the trucking company. |
For the controlled provision and consumption of services, Adhering Parties (and specifically, the humans and machines representing them) must be identified, authenticated, and authorized. 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 check 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.
| Certified role: | Role description: |
|---|---|
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:
As a result, Service Providers can outsource 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 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 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 who provides solutions for Adhering Parties for the storage of delegation- and authorisation information. An Authorisation Registry:
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. |
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/Satellite (in the relevant role).
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 be adhering or certified, whereas a party that delivers iSHARE compatible software does not need to be so.
The Scheme Owner role is fulfilled by the legal entity that keeps the Framework, and its network of participants, operating properly. How exactly is found under the detailed Operational descriptions.
The Scheme Owner is responsible for admission of the Satellites and the overall maintenance of the iSHARE Trust Framework, including the Participants' Registry.
Please refer to the detailed descriptions for details on how the Scheme Owner facilitates and federates trust in the iSHARE Trust Framework
A central role in the basic iSHARE Framework is the Satellite. The Satellite role is fulfilled by the legal entity that is responsible for the operational processes and keeps the data space functioning properly. How exactly is found under the detailed Operational descriptions.
The Satellite plays a fundamental role in any iSHARE use case. Every participant of the iSHARE Trust Framework must have a relation with the Satellite, and can check with the Satellite whether other parties participate in iSHARE. These are prerequisites, however, which is why the Satellite does not play a direct role (and is not depicted) in any of the use cases. All participants within the Data Space/iSHARE network will be explicitly linked to the Satellite responsible for their admission.
The Satellite can delegate responsibilities for onboarding, etc to Satellite administrators.
The Satellite Administrator is responsible for onboarding participants when delegated by the Satellite. The Satellite Administrator validates and checks for compliance - whether a party can be admitted to the Data space/iSHARE network (and whether this is as an Adhering- or Certified Party). When a party is admitted, Satellite Administrator will register the new participant with the Satellite participants' registry and will continue to act as point of contact on behalf of the Satellite for its participants.
Please note that Satellite Administrator does not have an active role in any use cases within the iSHARE network.
All of iSHARE's use cases can be depicted in the iSHARE Trust Framework. Their complexity is dependent on:
The interaction model (Machine to Machine or Human 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 that 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.
