Primary use cases
This most important part of the Functional descriptions explains the following in detail:
The iSHARE Trust Framework functional description, including the Participant Registry and what roles can hold what types of information;
The two primary use cases: Machine to Machine, Human to Machine with authorisation info and identity info held at the Service Provider, and Human to Machine with identity info held at an Identity Provider;
The possible variations to the two primary use cases, depending on where identity information, authorisation information and/or delegation information is held.
The possible use of Verifiable Credentials and its impact on execution flow and prerequisites.
iSHARE Trust Framework functional description
The iSHARE Trust framework was first explained under use cases. It consists of six roles that, depending on the situation, interact with each other based on the agreements. Each role has a certain function in the Framework and bears certain responsibilities. To fulfil any other role in the Framework, a party must fulfil specific admittance criteria, as explained.
The Scheme Owner role is fulfilled by the legal entity (Stichting iSHARE Foundation) that governs the iSHARE Trust Framework. The Scheme Owner admits the Participant Registry following the admission process of the framework. For a participant to be admitted to a data space, the Participant MUST sign the data space agreement (which includes iSHARE accession agreements) and be onboarded by the Participant Registry of the data space. The fact that every legal entity onboarded and fulfilling role(s) defined in the iSHARE Trust Framework, agrees to the rules - as proven by its accession to the framework - creates trust between parties in the data space/iSHARE network.
In order to know whether a party is an iSHARE participant before sharing data with it, the Participant Registry can be queried about this party's adherence/certification (as detailed in secondary use case 5a). This is not reflected in the primary use cases because every relation or interaction within iSHARE is built upon the Framework. The Framework use cases are presented as follows:
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, and 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.
Zooming in on the latter, four types of information are recognised that are needed to facilitate identification, authentication and authorisation:
Entitlement info: information indicating what Entitled Parties are entitled to what (parts of) services;
Delegation info: information indicating which (parts of) an Entitled Party's rights (as registered at the Service Provider or the Authorisation Registry (AR)) are delegated to a Service Consumer;
Authorisation info: information indicating which Human Service Consumers are authorised to act on a Service Consumer's behalf;
Identity info: information about a Human Service Consumer's identity (only applicable in H2M use cases).
All complexity can be brought back to two primary use cases, with 21 variations.
Two primary use cases
Machine-to-Machine service provision; Primary use case 1 caters to all Machine-to-Machine cases.
Human to Machine service provision with identity info held at the Identity Provider. Primary use case 2 caters to all Human to Machine cases where identity information is held at an Identity Provider. The Service Provider has outsourced identification and authentication, and therefore needs to consult the Identity Provider.
Derived use cases
The primary use cases allow a variety of derived use cases. Derived use cases are variations of the primary use cases in which delegation- and authorisation information required by the Service Provider is held by (i.e. outsourced to) and retrieved from different parties. In technical terms, we call the party holding information a Policy Information Point (PIP). This PIP, as in XACML 3.0, acts as the source of the information. However, an Authorisation Registry also acts as Policy Decision Point (PDP) as it evaluates the policies to determine authorisations for subject to a resource. Technically, the Authorisation Registry therefore acts as Policy Information Point (PIP) and Policy Decision Point (PDP) in all use cases. There are different use case variations for different ARs for delegation- and/or authorisation information, as presented in the use case tables below. Note that entitlement info is always held by the Service Provider, which is (consequently) not depicted in the tables below.
The Service Provider requests (from the ARs and PIPs, if any) and evaluates the information required to decide whether or not to grant a Service Consumer access to a service. After making its decision based on the received information, it grants this access (or not) to the Service Consumer. Technically, the Service Provider therefore acts as Policy Enforcement Point (PEP) and Policy Decision Point (PDP) in all use cases.
Authorisation Registry discovery logic
The Service Provider or Service Consumer discovers the Authorisation Registry for the specific capability in the following order. The first condition that applies, determines the location of the Authorisation Registry.
The Entitled Party has registered an Authorisation Registry for the specific capability in its /capabilities endpoint;
The Entitled Party has registered the Authorisation Registry for the specific capability in the Participant Registry;
The Entitled Party has registered an Authorisation Registry for a specific data space in the Participant Registry;
The Entitled Party's has set a default Authorisation Registry in the Participant Registry.
Else the Entitled Party and Service Provider have shared an Authorisation Registry bilaterally by other means (e.g., Service Provider has a profile/configuration for each Entitled Party to gather such information).
Primary use case 1 (and derived use cases)*: M2M service provision
Use case initiated by the Machine Service Consumer
*Use case 1 and its variations can also be initiated by a Human Service Consumer through an app. In such a case, the Machine Service Consumer acts as a proxy between the Human Service Consumer and the Service Provider's machine as described here.
**Primary use case 1 assumes that authorisation information is always present in a valid token used by the Machine Service Consumer. Therefore, primary use case 1 has no derived use cases where authorisation information is retrieved from other parties.
Note that interaction sequences are not described in the table above. In derived use cases 1b and 1c, several interaction sequences are possible depending on who requests delegation evidence from the AR. If the Entitled Party is also delegation evidence provider (AR)
The Service Provider can request delegation evidence after a service request from the Service Consumer;
The Machine Service Consumer can request delegation evidence and include it in its service request to the Service Provider;
The Entitled Party can push delegation evidence to the Machine Service Consumer, so it can include it in its service request to the Service Provider.
If the Authorisation Registry is the PIP/PDP providing delegation evidence:
The Service Provider must discover which Authorisation Registry was appointed by the Entitled party and then can request delegation evidence after a service request from the Service Consumer;
The Machine Service Consumer can request delegation evidence and include it in its service request to the Service Provider.
Use case 1 only has one interaction pattern, as there is no AR. Derived use case 1a also has one interaction pattern, as the Service Provider is the Delegation evidence PIP/PDP and therefore already has the delegation info it needs.
Primary use case 2 (and derived use cases): H2M service provision with identity info held at the IDP
Use case initiated by the Human Service Consumer.
Delegation evidence PIP/PDP
No delegation
Service Provider
Entitled Party
Authorisation Reg
Auth info PIP
Identity Provider
2
2a
2b
2c
Note again that interaction sequences are not described in the tables above. A Human Service Consumer cannot include delegation (or authorisation) info in its service request to the Service Provider. In use case 2 (and derived use cases), therefore, the Service Provider will always request delegation- and/or authorisation info from the respective PIP(s) after a service request from the Human Service Consumer.
Several interaction sequences are still theoretically possible depending on who requests a login from the Identity Provider. During the Functional working groups, however, it appeared that in practice, a Human Service Consumer will never request login from an Identity Provider before requesting a service from the Service Provider. Until proven otherwise, therefore, the only interaction sequence in scope for use cases 2 (and derived use cases) is the one in which the Service Provider (also) requests login from the Identity Provider after a service request from the Human Service Consumer.
In use case 2 (and derived use cases), an Identity Broker can be introduced to broker the relation between the Service Provider and the Identity Provider(s) and/or the Service Provider and the Authorisation Registry(s). This is optional and useful in situations with several Identity Providers and/or Authorisation Registries. Use case 2 is detailed both without an Identity Broker and with one.
Rest of this section
Please note that all use cases that contain a hyperlink (in their respective tables) are detailed on their own page, as follows:
Roles;
Depiction of legal relations, prerequisite registration and use case interaction;
Description of prerequisites and use case interaction;
Sequence diagram.
For both use case 2 (and derived use cases), an interface is required. Requirements for this interface are summarised here.
Last updated