The iSHARE Trust Framework aims to provide a generic building block blocks for service provision, widely applicable in the logistics sectormost sectors. This requires a framework that the Framework 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.
...
| Info | ||
|---|---|---|
| ||
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 Framework consists of six roles that, depending on the situation, interact with each other based on the iSHARE scheme Trust Framework agreements. Each role has a certain function in the scheme framework and bears certain responsibilities, as described below:
Any party fulfilling a role in the iSHARE framework 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.
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.
...
For the controlled provision and consumption of services, Adhering Parties (and specifically, the humans and machines representing them) must be identified, authenticated, and authorisedauthorized. 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 , 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 Scheme 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).
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 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.
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 schemeFramework, and its network of participants, operating properly. How exactly is found under the detailed Operational descriptions.
The Scheme Owner plays 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 Functional descriptions for details on how the Scheme Owner facilitates and federates trust in the iSHARE Trust Framework
Role of the Satellite
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 to the iSHARE Scheme of the iSHARE Trust Framework must have a relation with the Scheme OwnerSatellite, and can check at with the Scheme Owner Satellite whether other parties participate in iSHARE. These are prerequisites, however, which is why the Scheme Owner Satellite 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 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.
Role of the Satellite Administrator
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, its Scheme Satellite Administrator will register the new participant with the iSHARE Scheme Ownerthe Satellite participants' registry and will continue to act as point of contact on behalf of iSHARE the Satellite for its participants.All participants within iSHARE wil be explicitly linked to the Scheme Adminstrator responsible for their admission.
Please note that Scheme Satellite Administrator does not have a an active role during data sharing in any use cases within the iSHARE network. 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 frameworkTrust Framework. Their complexity is dependent on:
...
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.