Framework and roles
iSHARE aims to provide a generic building block for service provision, widely applicable in the logistics sector. This requires a framework that can be applied to the wide variety of use cases possible in practice. This chapter explains the iSHARE 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 iSHARE scheme agreements. Each role has a certain function in the scheme and bears certain responsibilities, as described below:
Any party fulfilling a role in the iSHARE framework must be iSHARE adhering or iSHARE certified:
- Parties fulfilling adhering roles, depicted in purple, provide and consume services under iSHARE. 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 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.
- 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 iSHARE 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. |
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 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 under iSHARE (and therefore, to improve iSHARE's scalability), iSHARE 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 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. |
| 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 (in the relevant role).
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 Scheme (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.
Role of the Scheme Owner
A central role, not part of the basic iSHARE framework, is that of the Scheme Owner. The Scheme Owner role is fulfilled by the legal entity that keeps the scheme, and its network of participants, operating properly. How exactly is found under the detailed Operational descriptions.
The Scheme Owner plays a fundamental role in any iSHARE use case. Every participant to the iSHARE Scheme must have a relation with the Scheme Owner, and can check at the Scheme Owner whether other parties participate in iSHARE. These are prerequisites, however, which is why the Scheme Owner does not play a direct role (and is not depicted) in any of the use cases.
The Scheme Owner is responsible for admission of the Scheme Administrators and the overall maintenance of the iSHARE scheme, including the iSHARE Scheme participants' registry (iSHARE Registry).
Please refer to the detailed Functional descriptions for details on how the Scheme Owner facilitates and federates trust in the iSHARE Scheme.
Role of the Scheme Administrator
The Scheme Administrator acts as an iSHARE satellite in a federated trust scheme. It is this Scheme Administrator that decides whether a party is admitted to the iSHARE network (and whether this is as an Adhering- or Certified Party). When a party is admitted, its Scheme Administrator will register the new participant with the iSHARE Registry and will continue to act as point of contact on behalf of iSHARE for its participants.
All participants within iSHARE wil be explicitly linked to the Scheme Adminstrator responsible for their admission.
Please note that Scheme Administrator does not have a active role during data sharing use cases within iSHARE.
Please also note that the legal entity fulfilling the role of Scheme Owner may also act as in the role of Scheme Administrator.
Framework and roles in use cases
All of iSHARE's use cases can be depicted in the iSHARE 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 iSHARE's use cases, all legal relations are shown before the actual interaction is plotted in the framework.