Page Comparison

This most important part of the Functional descriptions explains the following in detail:

• The iSHARE framework, including the Scheme Owner 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. 

iSHARE framework

The iSHARE framework was explained under use cases. It 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. To fulfil a other role in the framework, a party must fulfil specific admittance criteria, as explained.

What was not explained under use cases was how the iSHARE and the Scheme Owner-role provide a trust framework. The Scheme Owner-role is fulfilled by the legal entity that governs the iSHARE Scheme and its participant network. It is this Scheme Owner that decides whether a party is admitted to the iSHARE network. To be admitted, this party must sign an agreement with the Scheme Owner. The fact that every legal entity fulfilling a role in the iSHARE Scheme agrees to the scheme rules - as proven by its agreement with the Scheme Owner - creates trust between parties in the iSHARE network. This is why the following depiction of the iSHARE framework, showing the mandatory relation between the Scheme Owner and every other role, can be called the trust framework:

Image Modified

In order to know whether a party is an iSHARE participant before sharing data with it, the Scheme Owner can be asked about this party's adherence/certification (as detailed in secondary use case 5a). This and the trust framework as a whole are not reflected in the primary use cases because every relation or interaction within iSHARE is build upon the trust framework. The framework used to depict use cases was already presented as follows:

Image Modified

It was stated that all of iSHARE's use cases can be depicted in the above framework. 

...

• 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 Conumer's behalf;
• Identity info: information about a Human Service Consumer's identity (only applicable in H2M use cases).

...