Primary use cases
Last updated
Last updated
This most important part of the Functional descriptions explains the following in detail:
The iSHARE Trust Framework functional description, including the Satellite and and what role can hold what types of information;
The three primary use cases: Machine to Machine, Human to Machine with authorization 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 three primary use cases, depending on where identity information, authorization information and/or delegation information is held.
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 Trust Framework 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 that governs the iSHARE Trust Framework and its participant network. To be admitted, one must first be admitted to the data space/network by a Satellite and must then sign an accession agreement with the Satellite. The fact that every legal entity fulfilling a role in the iSHARE Trust Framework agrees to the rules - as proven by its agreement with the Satellite - 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 Satellite can be asked 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 build 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 authorization 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 authorization:
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 Authorization Registry) are delegated to a Service Consumer;
Authorization info: information indicating which Human Service Consumers are authorized 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 three primary use cases, with 21 variations.
Machine to Machine service provision; Primary use case 1 caters to all Machine to Machine cases.
Human to Machine service provision with authorization and identity info held at the Service Provider; Primary use case 2 caters to all Human to Machine cases where the Service Provider resides over both identity information and authorization information. He has not outsourced identification, authentication and authorization, and therefore does not need to consult certified parties
Human to Machine service provision with identity info held at the Identity Provider. Primary use case 3 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.
The primary use cases all know a variety of derived use cases. Derived use cases are variations of the primary use cases in which delegation- and authorization 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. There are different use case variations for different PIPs for delegation- and/or authorization 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 PIP(s)) 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.
Use case initiated by the Machine Service Consumer
| Delegation info PIP | |||
No delegation | Service Provider | Entitled Party | Authorization Reg | |
Derived use cases** | 1a |
*Use case 1 and its variations can also be initiated by a Human Service Consumer through an app. In such 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 authorization 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 authorization 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 info from the PIP. If the Entitled Party is the delegation info PIP:
The Service Provider can request delegation info after a service request from the Service Consumer;
The Machine Service Consumer can request delegation info and include it in its service request to the Service Provider;
The Entitled Party can push delegation info to the Machine Service Consumer, so it can include it in its service request to the Service Provider_._
If the Authorization Registry is the delegation info PIP:
The Service Provider can request delegation info after a service request from the Service Consumer;
The Machine Service Consumer can request delegation info and include it in its service request to the Service Provider.
Use case 1 only has one interaction pattern as there is no delegation info PIP. Derived use case 1a also has one interaction pattern as the Service Provider is the Delegation info PIP and therefore already has the delegation info it needs.
Use case initiated by the Human Service Consumer
| Delegation info PIP | |||
No delegation | Service Provider | Entitled Party | Authorization Reg | |
Auth info PIP | 2a | 2c | 2c |
Use case initiated by the Human Service Consumer
| Delegation info PIP | ||||
No delegation | Service Provider | Entitled Party | Authorization Reg | ||
Auth info PIP | Identity Provider | 3a | 3b | 3c |
Note again that interaction sequences are not described in the tables above. A Human Service Consumer cannot include delegation (or authorization) info in its service request to the Service Provider. In use cases 2 and 3 (and derived use cases), therefore, the Service Provider will always request delegation- and/or authorization 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 3 (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 3 (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 Authorization Registry(s). This is optional and useful in situations with several Identity Providers and/or Authorization Registries. Use case 3 is detailed both without an Identity Broker and with one.
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 3 (and derived use cases), an interface is required. Requirements to this interface are summarised here.
