# iSHARE Trust Framework

{% hint style="info" %}
This is iSHARE Framework version: 3.0.
{% endhint %}

This document provides a full overview of the current state of the iSHARE Trust Framework.

iSHARE is a collaborative effort to improve conditions for data-sharing for organisations. The functional scope of the iSHARE Trust Framework focuses on topics of identification, authentication and authorisation to business data attributes.

<figure><img src="/files/Js35miKn2QpqgnNU3Ckj" alt=""><figcaption></figcaption></figure>


# Introduction

iSHARE is a collaborative effort to improve conditions for data-sharing for organisations aiming to collaborate in a data space. The functional scope of the iSHARE Trust Framework focuses on topics of identification, authentication and authorisation.

## Reader's guide <a href="#introduction-readersguide" id="introduction-readersguide"></a>

* iSHARE's introductory section describes the Framework's starting points: its goals, the guiding principles and the governance of the Trust Framework.
* The '[releases](/releases)' section describes the release notes, planning of future releases and version history of the iSHARE Trust Framework.
* The '[main aspects of the iSHARE Trust Framework](/main-aspects-of-the-ishare-trust-framework)' section summarises the most important functionality of the Framework, roles, and the technical, operational and legal provisions enabling it;
* The '[use cases](/use-cases)' section showcases the key functionalities in four use cases.
* The '[detailed descriptions](/detailed-descriptions)' section explains the in-depth Functional, Technical, Legal and Operational agreements that, together, improve data-sharing;
* The Trust Framework concludes with the '[glossary and legal notices](/glossary-and-legal-notices)' section.

Within the iSHARE Trust Framework documentation, the following notational conventions apply:

* The keywords 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in IETF [RFC 2119](http://www.ietf.org/rfc/rfc2119.txt) whenever this note is at the top of the chapter:
  * *This part of the iSHARE Trust Framework is considered normative and is therefore compliant with RFC 2119.*


# Goals and scope of the iSHARE Trust Framework

The iSHARE Trust Framework is a collaborative effort to improve the exchange of data between organisations in and across data spaces. The Framework results in a set of agreements which improve circumstances for data exchange.

The ambition of iSHARE is to lower barriers for sharing data, to empower new forms of collaboration between organisations and to help scale up existing initiatives that aim to improve conditions for data exchange. The underlying assumption is that if data can flow in a controlled and smart way, it will lead to a more efficient use of infrastructure, less carbon emissions and more competitiveness.

The Trust Framework's scope focuses on three main topics that are crucial in any data exchange context:

1. [Identification;](/glossary-and-legal-notices/glossary#glossary-identificationidentification)
2. [Authentication](/glossary-and-legal-notices/glossary#glossary-authenticationauthentication);
3. [Authorisation](/glossary-and-legal-notices/glossary#glossary-authorisationauthorization).

iSHARE focuses on these three aspects as they are considered indispensable in any communication between parties, also in the context of exchanging logistical data. Within the Trust Framework, agreements are made on the above three topics to work towards a more uniform, straightforward and controlled way of exchanging data on a bigger scale than is possible right now\*.

* Uniform: one uniform way of working across all types of modalities, small and large organisations, public and private organisations, suppliers and receivers of data or their software partners, etc. iSHARE aims to create new possibilities for efficiency improvements, time gains and cost savings.
* Straightforward: Easy to connect with new, existing and third-party business partners throughout the sector, more certainty on the trustworthiness of parties you exchange data with, a building block which is easy to implement by your software partners or your IT department and an addition that empowers your existing solutions.
* Controlled: The basic principle within iSHARE is that the owner of the data stays in control at all times; the owner decides with whom what data is exchanged and on what terms.

These three aims can only be reached when a variety of perspectives are considered during the establishment of the Framework. To this end, a variety of organisations are involved in defining the agreements for iSHARE.

{% hint style="info" %}

* The scope of the iSHARE Trust Framework does not include the specification of possible business models for sharing data and/or payments related to data exchange.
* The iSHARE Trust Framework can in some way be compared with the institution of the passport: the Trust Framework will be usable by anyone who owns a digital identity compatible with the framework. This will greatly simplify authentication and authorisation processes, also between different organisations (however, even though organisations can have valid certificates, it does not rule out possible malicious intentions).
  {% endhint %}


# Guiding principles

To achieve the goals of the iSHARE Trust Framework, it is paramount to stay close to a set of guiding principles. As time progresses, new principles can be defined, existing principles can be adapted or dropped if deemed necessary. The guiding principles were defined using the format as suggested\* by [TOGAF 9.2 architectural principles](https://pubs.opengroup.org/architecture/togaf9-doc/arch/).

The following principles define the Trust Framework and must be kept in mind at all times during further development (see details of guiding principles below):

<table><thead><tr><th width="135">Principle #</th><th>Principle name</th></tr></thead><tbody><tr><td><strong>1</strong></td><td>Generic building block to enable data exchange</td></tr><tr><td><strong>2</strong></td><td>Limited scope: identification, authentication, and authorisation</td></tr><tr><td><strong>3</strong></td><td>Leverage existing (international) building blocks</td></tr><tr><td><strong>4</strong></td><td>Agnostic towards nature and content of data</td></tr><tr><td><strong>5</strong></td><td>Benefits outweigh investment for all types of participants</td></tr><tr><td><strong>6</strong></td><td>International orientation</td></tr></tbody></table>

## Guiding principles details

<table data-header-hidden><thead><tr><th width="198"></th><th>Generic building block to enable data exchange</th></tr></thead><tbody><tr><td><strong>Principle 1</strong></td><td><strong>Generic building block to enable data exchange</strong></td></tr><tr><td><strong>Statement</strong></td><td>iSHARE provides a generic identification, authentication and authorisation Trust Framework to be used as an enabler for data exchange.</td></tr><tr><td><strong>Rationale</strong></td><td>In every exchange of data, identification, authentication, and authorisation are fundamental factors. iSHARE aims to simplify processes of identification, authentication and authorisation as a generic solution to facilitate data exchange.</td></tr><tr><td><strong>Implications</strong></td><td><ul><li>The Framework will allow for extension or adaptability so it can be used in situation/sector-specific cases.</li><li>The Framework will not cater to a specific sector or market; it is applicable in several cases.</li><li>The Framework will not be a point solution.</li></ul></td></tr></tbody></table>

<table data-header-hidden><thead><tr><th width="200"></th><th></th></tr></thead><tbody><tr><td><strong>Principle 2</strong></td><td><strong>Limited scope: identification, authentication, and authorisation</strong></td></tr><tr><td><strong>Statement</strong></td><td>The iSHARE Trust Framework's scope is limited to topics of identification, authentication and authorisation in the context of data exchange</td></tr><tr><td><strong>Rationale</strong></td><td>iSHARE aims to improve the circumstances for data exchange and provides a focus on the topic of identification, authentication and authorisation. Identification, authentication and authorisation are a fundamental part of any data exchange, but are not solved in a scalable or standardised way at the moment.</td></tr><tr><td><strong>Implications</strong></td><td><ul><li>Without this principle, there is a risk of 'scope creep': related topics could take away the focus from the intended topics</li></ul></td></tr></tbody></table>

<table data-header-hidden><thead><tr><th width="201"></th><th></th></tr></thead><tbody><tr><td><strong>Principle 3</strong></td><td><strong>Leverage existing (international) building blocks</strong></td></tr><tr><td><strong>Statement</strong></td><td>Where possible, the iSHARE Trust Framework should be realised using existing and proven standards, technology or initiatives</td></tr><tr><td><strong>Rationale</strong></td><td>By reusing building blocks already available and in use, the impact on organisations to participate in the iSHARE network and the time to adopt the iSHARE Trust Framework are lowered. Standards, technology and initiatives preferably have a broad (international) usage base and are backed by a professional organisation charged with maintenance of the standards, technology or initiatives.</td></tr><tr><td><strong>Implications</strong></td><td><ul><li>The Framework will build on or use existing (international) standards, technology or initiatives where possible;</li><li>The Framework will aim to use open standards, technology or initiatives;</li><li>The Framework may use proprietary standards, technology or initiatives;</li><li>If existing and/or proven standards, technology, or initiatives do not provide what is needed, alternative solutions will be sought.</li></ul></td></tr></tbody></table>

<table data-header-hidden><thead><tr><th width="202"></th><th></th></tr></thead><tbody><tr><td><strong>Principle 4</strong></td><td><strong>Agnostic towards nature and content of data</strong></td></tr><tr><td><strong>Statement</strong></td><td>The iSHARE Trust Framework does not concern itself with the contents or nature of data</td></tr><tr><td><strong>Rationale</strong></td><td>Given the generic nature of the iSHARE Trust Framework and the aim to be applicable throughout any sector, it needs to function with any type of possible data and/or any relevant data exchange interaction model. To this end, the contents of data are only considered where they concern the facilities needed within iSHARE to adequately exchange various types of data (e.g. requirements for security, encryption, etc.). It is up to the participating organisations to ensure that iSHARE adequately fulfils the requirements of the process of identification, authentication and authorisation in the context of data exchange.</td></tr><tr><td><strong>Implications</strong></td><td><ul><li>The Framework will not specify the (allowed) content of data exchanges done within a data space( iSHARE context);</li><li>The Framework does not specify content-specific data standards.</li><li>The Framework should not have limitations connected to types of data or standards used.</li></ul></td></tr></tbody></table>

<table><thead><tr><th width="203"></th><th></th></tr></thead><tbody><tr><td><strong>Principle 5</strong></td><td><strong>Benefits outweigh investment for all types of participants</strong></td></tr><tr><td><strong>Statement</strong></td><td>The iSHARE Trust Framework needs to be attractive to use and implement for all types of participants/roles in the data space.</td></tr><tr><td><strong>Rationale</strong></td><td>The iSHARE Trust Framework knows different roles with different responsibilities. When a potential participant considers taking a (or multiple) role(s) in the data space, the framework should aim to have the lowest possible threshold to participate for the potential participant. Depending on what the character of the potential participant is (e.g smaller size or larger size organisations) and which role the participant wants to take, this could mean that the impact of implementation needs to be small or that the implementation is kept relatively simple.</td></tr><tr><td><strong>Implications</strong></td><td><ul><li>The framework aims to keep thresholds to participate in the data space (e.g. in terms of implementation impact or onboarding/certification effort) as low as possible for all possible roles.</li><li>The framework strives for the lowest possible impact for participants when changes occur in the future. Changes to used standards will take place within the framework and its specifications, though there needs to be a focus on how change is dealt with in an efficient way.</li></ul></td></tr></tbody></table>

<table data-header-hidden><thead><tr><th width="204"></th><th></th></tr></thead><tbody><tr><td><strong>Principle 6</strong></td><td><strong>International orientation</strong></td></tr><tr><td><strong>Statement</strong></td><td>The iSHARE Framework needs to look over geographic and sector boundaries to foster international involvement and cooperation</td></tr><tr><td><strong>Rationale</strong></td><td>Every sector is by definition an international sector. The iSHARE Trust Framework needs to facilitate, to the extent that it is practical and possible, international involvement.</td></tr><tr><td><strong>Implications</strong></td><td><ul><li>The Framework needs its participants to provide knowledge and experience on how it can stay (and become) attractive in the international context.</li></ul></td></tr></tbody></table>

\*Format used for defining guiding principles, based on the TOGAF standard:

<table data-header-hidden><thead><tr><th width="203"></th><th></th></tr></thead><tbody><tr><td><strong>Principle name</strong></td><td>Should both represent the essence of the rule as well as be easy to remember. Specific technology platforms should not be mentioned in the name or statement of a principle. Avoid ambiguous words in the Name and in the Statement, such as 'support', 'open', 'consider', and, for lack of a better term, the word 'avoid' itself, be careful with 'manage(ment)', and look for unnecessary adjectives and adverbs (fluff).</td></tr><tr><td><strong>Statement</strong></td><td>Should succinctly and unambiguously communicate the fundamental rule. For the most part, the principles statements for managing information are similar from one organisation to the next. The principles statement must be unambiguous.</td></tr><tr><td><strong>Rationale</strong></td><td>Should highlight the business benefits of adhering to the principle, using business terminology. Point to the similarity of information and technology principles to the principles governing business operations. Also, describe the relationship to other principles and the intentions regarding a balanced interpretation. Describe situations where one principle would be given precedence or carry more weight than another for making a decision.</td></tr><tr><td><strong>Implications</strong></td><td>Should highlight the requirements, both for the business and IT, for carrying out the principle, in terms of resources, costs, and activities/tasks. It will often be apparent that current systems, standards, or practices would be incongruent with the principle upon adoption. The impact on the business and the consequences of adopting a principle should be clearly stated. The reader should readily discern the answer to: 'How does this affect me?' It is important not to oversimplify, trivialise, or judge the merit of the impact. Some of the implications will be identified as potential impacts only, and may be speculative rather than fully analysed.</td></tr></tbody></table>


# Governance

The iSHARE Trust Framework describes the Governance as follows. The Scheme Owner is the main body involved in the maintenance of the iSHARE Trust Framework. The governance consists of the following bodies. See below for detailed descriptions:

* The iSHARE Foundation, which is the Scheme Owner
* The Executive Board
* The Supervisory Board
* The Council of Participants
* The Change Advisory Board
* The Council of Sponsors

The governance is organised such that the iSHARE network can operate and grow in a sustainable way. At the same time, it provides the appropriate checks and balances that will allow Participants to provide input, supervise ongoing activities and collaboratively influence the growth and development of the iSHARE Trust Framework. Rules about the foundation’s organisation and its governance framework are captured in the statutes of the iSHARE Foundation. The iSHARE Foundation is listed in the Commercial Register (Handelsregister) in the Netherlands, maintained by the Chamber of Commerce (Kamer van Koophandel) under registration number 73058289.

<figure><img src="https://ishare.eu/wp-content/uploads/2021/11/iSHARE.Governance.png" alt=""><figcaption></figcaption></figure>

The above figure describes the governance in the Trust Framework. L/O - Legal/Operational. F/T - Functional/Technical.

### Scheme Owner <a href="#governance-schemeowner" id="governance-schemeowner"></a>

The iSHARE Foundation is the Scheme Owner of the iSHARE Trust Framework and is responsible for all activities related to the iSHARE Trust Framework. The iSHARE Scheme Owner consists of:

* An **Executive Board** formed by (an) independent representative(s) of the iSHARE community. Executive board members are selected and chosen by the Supervisory Board. The Executive Board is the highest organ of the Scheme Owner. Executive board members are accountable to the Supervisory Board for the functioning of the iSHARE Foundation and the iSHARE Trust Framework.
* An **operational branch** responsible for day-to-day management activities. These activities include (amongst others) the following responsibilities:
  * Management of the iSHARE Trust framework (specifications + brand management and marketing);
  * Development and maintenance of tools;
  * Maintenance of the Participant Registry (old term: Satellite);
  * Addition of new data spaces.

### Sponsor(s) <a href="#governance-sponsor-s" id="governance-sponsor-s"></a>

The iSHARE Foundation can receive funding from government and semi-public organisations that wish to support the realisation of the goals of the Foundation. Upon request of such an organisation, the Supervisory Board can decide to grant the organisation the status of Sponsor of the iSHARE Foundation. The organisation maintains the status of Sponsor for the duration that it provides funding to the iSHARE Foundation.

### Supervisory Board <a href="#governance-supervisoryboard" id="governance-supervisoryboard"></a>

* The Supervisory Board is appointed by the Council of Participants and consists of three members
  * One member of the Supervisory Board may be appointed by the Sponsor(s), rather than the Council of Participants, if there are Sponsor(s) present.
* The Supervisory Board supervises the correct functioning of the iSHARE Foundation's Executive Board and elects/dismisses the members of the Executive Board.

The Supervisory Board transferred Scheme Owner activities to the iSHARE Foundation.

### Council of Participants <a href="#governance-councilofparticipants" id="governance-councilofparticipants"></a>

* The Council of Participants consists of all Parties (or representations of these parties) that have a contract with the Scheme Owner/ individual data space and are willing to participate in the Council of Participants' activities.
* The Council of Participants advises the iSHARE Foundation and appoints members of the Supervisory Board.

### Change Advisory Board <a href="#governance-changeadvisoryboard" id="governance-changeadvisoryboard"></a>

* The Change Advisory Board consists of subject matter experts (legal/ operational/ functional/ technical) delegated by the Participants and Data Space Governance Bodies.
* The Change Advisory Board advises the Scheme Owner on changes to the specifications of the iSHARE Trust Framework.


# Releases

This chapter describes the release notes, planning of future releases and version history of the iSHARE Trust Framework.

* [Release notes](/releases/release-notes)
* [Release planning](/releases/release-planning)
* [Version history](/releases/version-history)


# Release notes

The release notes show the release history and the main differences between releases.

<table><thead><tr><th width="225.333251953125">Release 3.0</th><th></th></tr></thead><tbody><tr><td>Purpose</td><td>Improve support and separation of responsibilities between components, increase flexibility in delegation and tokens, enhance discoverability and client portability across data spaces, and prepare for broader adoption of emerging standards such as Verifiable Credentials.</td></tr><tr><td>Release date</td><td>21 November 2025</td></tr><tr><td>Change log</td><td><p><strong>Functional</strong></p><ul><li>Participants can now assign different Authorisation Registries per Service Provider or capability.</li><li>Delegation evidence supports conditions, that may be evaluated by the Authorisation Registry or by the Service Provider at the time of service consumption.</li><li>Participants can expose a Data Space Description for improved discovery.</li><li>Improved client portability across multiple data spaces by introducing the "claims" concept.</li><li>Clarified participant adherence indicators under a revamped section: Criteria for Participation (instead of Levels of Assurance).</li><li>Introduces Verifiable Credentials (W3C standard) as an additional, interoperable means for participants to authenticate, authorise, and interact across data spaces.</li></ul><p><strong>Technical</strong></p><ul><li>/parties and /capabilities endpoints are updated to declare multiple ARs.</li><li>Delegation evidence now supports conditions, which may reference attributes such as validFrom, validUntil, or certifications.</li><li>Party-related endpoints have been redesigned with a new parties-and-claims structure to improve portability across data spaces.</li><li>Verifiable Credentials support added, including standardised credential formats and presentation flows for identity and authorisation.</li></ul><p><strong>Operational</strong></p><ul><li>With introduction of Verifiable Credentials the roles and responsibilities are updated in the iSHARE Role model.</li><li>Updated and clarified onboarding process for participants.</li><li>Capability and Participant Registry metadata now support advanced configuration of AR per service provider.</li><li>Optional specifications can now be published via dataspace descriptions, enabling discovery while keeping core interoperability unchanged.</li><li>Improved documentation for multi-service AR setup and delegation path discovery models, including fallback logic and resolution priorities.</li><li>Documented rules on what fields can be locally overwritten (limited to SLA).</li></ul><p><strong>Legal</strong></p><ul><li>The assessment framework has been improved for all certified roles, making it role specific.</li></ul></td></tr></tbody></table>

<table><thead><tr><th width="225">Release 2.2</th><th></th></tr></thead><tbody><tr><td>Purpose</td><td><ul><li>Improve interoperability among global data ecosystems</li></ul></td></tr><tr><td>Release date</td><td>13 June 2025</td></tr><tr><td>Change log</td><td><p>All included RFCs are available <a href="https://gitlab.com/groups/ishare-foundation/cab/-/issues/?label_name%5B%5D=Release%202.2">here</a>.</p><p><strong>Functional</strong></p><ul><li>Improved iSHARE licenses and released a dedicated licenses portal on https://licenses.ishare.eu..</li></ul><p><strong>Technical</strong></p><ul><li>Added create and update specifications for managing parties at Participant Registry</li></ul><p><strong>Legal</strong></p><ul><li>Updates to license agreements</li></ul></td></tr></tbody></table>

| Version 2.1.1 |                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            |
| ------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Purpose       | <ul><li>Update links to OpenAPI specifications</li><li>Update relevant endpoints to support new party identifcation model.</li></ul>                                                                                                                                                                                                                                                                                                                                                                                                                                                                       |
| Release date  | 5 January 2026                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                             |
| Change log    | <ul><li>Party-related identifiers have been standardised by replacing partyId with id and alsoKnownAs across relevant endpoints, examples, and schemas to improve consistency and readability.</li><li>The Dataspace endpoint now supports defaultParticipantIdentifierName and defaultParticipantIdentifierPrefix, allowing data spaces to explicitly declare their default participant identifier (defaulting to ishare:did when not specified).</li><li>The User Info and id\_token endpoint now includes clearer examples and the required organisationIdentifier (ETSI/X.509 OID 2.5.4.97).</li></ul> |

<table><thead><tr><th width="225">Release 2.1</th><th></th></tr></thead><tbody><tr><td>Purpose</td><td><ul><li>Introduction of iSHARE-ID to enhance interoperability.</li><li>Update of terminology.</li><li>Introduction of standardised delegation creation requests.</li><li>Respecification of the /capabilities endpoint.</li><li>Decommissioning of PKIOverheid certificates.</li><li>Alternative onboarding for service consumers without PKI certificates.</li></ul></td></tr><tr><td>Release date</td><td>7 March 2025</td></tr><tr><td>Change log</td><td><p>All included RFCs are available <a href="https://gitlab.com/groups/ishare-foundation/cab/-/issues/?label_name%5B%5D=Release%202.1">here</a>.</p><p><strong>Functional</strong></p><ul><li>Supporting multiple identifiers and the Introduction of iSHARE-ID</li><li>Updated terminology (Data Space Governance Body and Participant Registry)</li><li>Standardised delegation requests</li></ul><p><strong>Technical</strong></p><ul><li>Multiple party identifiers and iSHARE DID Method</li><li>Respecification of /capabilities endpoint</li><li>Onboarding service consumers without PKI certificates</li></ul><p><strong>Operational</strong></p><ul><li>Updated onboarding processes</li><li>Decommissioning PKIOverheid certificates</li><li>Addition of Brand Guidelines to UI Guidelines</li></ul><p><strong>Legal</strong></p><ul><li>Updates to legal agreements</li></ul></td></tr></tbody></table>

<table><thead><tr><th width="225">Release 2.0.1</th><th></th></tr></thead><tbody><tr><td>Purpose</td><td><ul><li>Release of new framework website</li></ul></td></tr><tr><td>Release date</td><td>3 July 2024</td></tr><tr><td>Change log</td><td><ul><li>Minor typos only</li><li>All content has been copied to the new framework website</li></ul></td></tr></tbody></table>

<table><thead><tr><th width="225">Release 2.0</th><th></th></tr></thead><tbody><tr><td>Purpose</td><td><ul><li>Updated Roles</li><li>Updated Governance structure</li><li>Distinction and clarity in roles and governance</li><li>Updates in operational and functional processes</li></ul></td></tr><tr><td>Release Date</td><td>30 October 2023</td></tr><tr><td>Change log</td><td><p><strong>Introduction</strong></p><ul><li>The scheme is now known as the iSHARE Trust Framework</li><li>Updated goals, scope, guiding principles and governance.</li><li>Federation of Trust Framework</li></ul><p><strong>Functional</strong></p><ul><li>Added new role: Satellite</li><li>The scheme administrator is now the Satellite administrator</li><li>Minor fixes in key functionality</li></ul><p><strong>Technical</strong></p><ul><li>Updated Satellite role</li><li>Review of technical standards and minor fixes</li></ul><p><strong>Legal</strong></p><ul><li>Updated Satellite role</li><li>Updated Accession agreement and Terms of Use</li></ul><p><strong>Operational</strong></p><ul><li>New role - Satellite</li><li>Updated the operational processes of admission, withdrawal and incident management processes</li><li>Updated the service levels.</li></ul></td></tr></tbody></table>

<table><thead><tr><th width="225">Release 1.11</th><th></th></tr></thead><tbody><tr><td>Purpose</td><td><ul><li>Updated legal documents</li><li>Added new role: Scheme Administrator</li><li>Updated Governance structure</li><li>Small technical improvements</li></ul></td></tr><tr><td>Release date</td><td>16 November 2020</td></tr><tr><td>Change log</td><td><p><strong>Functional</strong></p><ul><li><p>Added new role: Scheme Administrator</p><ul><li>Participant admission process</li><li>Governance</li><li>Scheme trust model</li></ul></li><li>Human authorisation for IDPs is now optional and no longer mandatory</li></ul><p><strong>Technical</strong></p><ul><li>Human authorisation for IDPs is now optional and no longer mandatory. The associated CTT tests are no longer a requirement for certification.</li><li><p>Scheme administrators added and new attributes added to:</p><ul><li>Track which SA is responsible for the participant</li><li>Express the level of adherence of the participant.</li></ul></li></ul><p><strong>Operational</strong></p><ul><li><p>Updated the admission process for the Scheme Administrator:</p><ul><li>Admission of Scheme Administrator</li><li>Withdrawal of Scheme Administrator</li></ul></li><li><p>Updated the admission process for Parties:</p><ul><li>Admission through the Scheme Administrator</li><li>Reassignment of Scheme Administrator</li></ul></li><li>The governance structure changed to reflect the transition from the project phase</li><li>Added process of determining yearly participation fees.</li></ul><p><strong>Legal</strong></p><p>Updates:</p><ul><li>Updated the Terms of Use to reflect the fact that Adhering Parties and Certified Parties are subject to an annual fee, added article 11 “Participation Fee” and updated the links to the Annexes.</li><li>Updated the Accession Agreement for Certified Parties to reflect the fact that Certified Parties are subject to an annual fee.</li><li>Updated the Accession Agreement for Adhering Parties to reflect the fact that Adhering Parties are subject to an annual fee.</li><li>Renewed the standard NDA to reflect the relation between the iSHARE foundation, Scheme Owner and Adoption.</li></ul></td></tr></tbody></table>

<table><thead><tr><th width="225">Release 1.10</th><th></th></tr></thead><tbody><tr><td>Purpose</td><td><ul><li>Updated the process for verifying eIDAS certificates</li><li>Update the admission process for Certified Parties</li><li>Added levels of assurance for Certified Parties</li><li>Added support for the use case where the Entitled Party is not an iSHARE Adhering Party, but is a customer of an iSHARE Service Provider</li><li>Small technical improvements</li></ul></td></tr><tr><td>Release date</td><td>24 June 2019</td></tr><tr><td>Change log</td><td><p><strong>Functional</strong></p><ul><li>Updated the functional requirements for Certified Parties (references to eHerkenning have been removed and replaced by relevant requirements)</li></ul><p><strong>Technical</strong></p><ul><li>Updated the process for verifying eIDAS certificates (now uses the same process as PKI-Overheid certificates)</li><li>Added level of assurance to the Party Info endpoint at the Scheme Owner (for Certified Parties)</li><li>Clarified the use of acr_values in the H2M flow to request a minimal level of assurance</li><li>Clarified the headers used for JWE in the H2M flow</li></ul><p><strong>Operational</strong></p><ul><li><p>Updated the admission process for Certified Parties, including the following changes:</p><ul><li>Admission to eHerkenning is no longer required</li><li>Added the concept of Levels of Assurance for Certified Parties</li><li>Added the Assessment Framework for Certified Parties to determine the Level of Assurance of a Certified Party</li></ul></li></ul><p><strong>Legal</strong></p><ul><li>Updated the terms of use to reflect the use case where the Entitled Party is not an iSHARE Adhering Party, but is a customer of an iSHARE Service Provider</li></ul></td></tr></tbody></table>

<table><thead><tr><th width="225">Release 1.9</th><th></th></tr></thead><tbody><tr><td>Purpose</td><td>Enable Human to Machine (H2M) authorisations</td></tr><tr><td>Release date</td><td>5 April 2019</td></tr><tr><td>Change log</td><td><p><strong>Functional:</strong></p><ul><li>Updated primary Human to Machine use cases to reflect changes from RFC 010, which added the authorisation flow to these cases</li></ul><p><strong>Technical:</strong></p><ul><li>Added technical specifications on the generic authorisation flow for Human to Machine (H2M) interactions as facilitated by Identity Providers in the iSHARE Scheme, to reflect changes from RFC 010</li><li>Modified technical specifications for the capabilities endpoint of all iSHARE Parties</li></ul><p><strong>Operational</strong></p><ul><li>No changes</li></ul><p><strong>Legal</strong></p><ul><li>Updated governance framework to reflect that Stichting iSHARE Foundation has been created</li></ul><p><strong>Miscellaneous</strong></p><ul><li>Rearranged pages and sections to improve readability</li><li>Material has been moved from the Scheme to the Developer Portal to improve the readability and usability of both</li></ul></td></tr></tbody></table>

<table><thead><tr><th width="225">Release 1.8</th><th></th></tr></thead><tbody><tr><td>Purpose</td><td>Enable Human to Machine (H2M) interactions and finalise contracts for signing between iSHARE Foundation and iSHARE Participants.</td></tr><tr><td>Release date</td><td>31 October 2018</td></tr><tr><td>Change log</td><td><p><strong>Functional:</strong></p><p>-</p><p><strong>Technical:</strong></p><ul><li>Added technical specifications on the generic authentication flow for Human to Machine (H2M) interactions as facilitated by Identity Providers in the iSHARE Scheme.</li></ul><p><strong>Operational</strong></p><p><strong>-</strong></p><p><strong>Legal</strong></p><ul><li>Minor modifications to Terms of Use and the Accession Agreements for Adhering Paries and Certified Parties</li><li>Moved GDPR Factsheet and templates for Data Exchange Agreement and Data Processor Agreements to the appendix of the scheme, since they serve merely as an inspiration for participants who want to make additional bilateral arrangements with others they are sharing data with.</li></ul><p><strong>Miscellaneous</strong></p><ul><li>The governance framework is updated</li><li>Rearranged pages and sections to improve readability</li></ul></td></tr></tbody></table>

<table><thead><tr><th width="225">Release 1.7</th><th></th></tr></thead><tbody><tr><td>Purpose</td><td>Create a better overview of all API specs in a singular space, to make it easier for developers to implement iSHARE and to improve the readability of the iSHARE Scheme</td></tr><tr><td>Release date</td><td>28 June 2018</td></tr><tr><td>Change log</td><td><p><strong>Functional:</strong></p><p>-</p><p><strong>Technical:</strong></p><ul><li>The API technical specifications have been moved to a dedicated developer portal.</li><li>Adjusted specification for JSON Web Token (JWT) to facilitate certificate validation under eIDAS.</li></ul><p><strong>Operational</strong></p><ul><li>The service levels are now structured per participant type (Adhering Party/ Certified Party/ Scheme Owner) to give participants a better overview of their applicable service levels.</li></ul><p><strong>Legal</strong></p><p>-</p><p><strong>Miscellaneous</strong></p><ul><li>Rearranged pages and sections to improve readability</li><li>The governance framework is updated</li><li>The project history is updated</li></ul></td></tr></tbody></table>

<table><thead><tr><th width="225">Release 1.6</th><th></th></tr></thead><tbody><tr><td>Purpose</td><td>Lowering barriers for parties to start using iSHARE</td></tr><tr><td>Release date</td><td>11 May 2018</td></tr><tr><td>Change log</td><td><p><strong>Functional:</strong></p><p>-</p><p><strong>Technical:</strong></p><ul><li>For authentication purposes, the use of digital certificates within iSHARE will be limited initially to certificates issued under PKIOverheid.</li></ul><p><strong>Operational</strong></p><ul><li>The admission process for Certified Parties and Adhering Parties is merged into one generic process. Role-specific requirements may apply.</li><li>The order of admission steps is changed to enable new iSHARE entrants to start testing before a contract is signed.</li></ul><p><strong>Legal</strong></p><p>-</p><p><strong>Miscellaneous</strong></p><ul><li>Rearranged pages and sections to improve readability</li><li>The governance framework is updated</li></ul></td></tr></tbody></table>

<table><thead><tr><th width="225">Release 1.5</th><th></th></tr></thead><tbody><tr><td>Purpose</td><td>First public version of the iSHARE Scheme that can be used by launching customers</td></tr><tr><td>Release date</td><td>14 December 2017</td></tr><tr><td>Change log</td><td><ul><li><p>Updated specifications for all content of the iSHARE Scheme:</p><ul><li>Functional</li><li>Technical</li><li>Operational</li><li>Legal</li></ul></li><li>Significantly updated and rearranged sections for readability, including a <a href="/pages/irtl6qzup7otVUs4FZ8G">main scheme aspects</a>- and illustrative <a href="/pages/wjQ0540J0716RQDhpmCC">use cases</a> chapter with new depictions; Integrated (technical) specifications, generic and per iSHARE role.</li></ul></td></tr></tbody></table>


# Release planning

The release planning provides detailed information about changes that are planned for future releases of the Framework. See the [Change Management](/detailed-descriptions/operational/operational-processes/change-management) section for details about the change management process of the iSHARE Trust Framework.

### **Planned releases** <a href="#releaseplanning-plannedreleases" id="releaseplanning-plannedreleases"></a>

Version 3.0 is now live. Further updates and harmonisation of terms are underway. [More details on upcoming changes](https://gitlab.com/ishare-foundation/cab/rfc/-/boards).

The RFCs for this release have been discussed in the CAB meetings.

### **Suggestions** <a href="#releaseplanning-suggestions" id="releaseplanning-suggestions"></a>

If you have any other suggestions to improve the iSHARE Trust Framework, please let us know. The Request For Change procedures can be submitted and processed [here](https://gitlab.com/ishare-foundation/cab/rfc).

Additionally, if you would like to participate in the CAB, please [contact the iSHARE Foundation](https://ishare.eu/contact/).


# Version history

* [iSHARE v2.2](https://framework.ishare.eu/version-2.2/), 13 June 2025
* [iSHARE v2.1.1](https://framework.ishare.eu/version-2.1.1/), 5 January 2026
* [iSHARE v2.1](https://framework.ishare.eu/version-2.1/), 7 March 2024
* [iSHARE v2.0.1](https://gitlab.com/ishare-foundation/cab/ishare-trust-framework/-/blob/main/.gitbook/assets/iSHARE-Framework-2.0.1.pdf), 3 July 2024
* [iSHARE v2.0](https://gitlab.com/ishare-foundation/cab/ishare-trust-framework/-/blob/main/.gitbook/assets/iSHARE%20Framework%20v2.0.pdf), 30 October 2023
* [iSHARE v1.11](https://gitlab.com/ishare-foundation/cab/ishare-trust-framework/-/blob/main/.gitbook/assets/2775482429.pdf), 16 November 2020
* [iSHARE v1.10](https://gitlab.com/ishare-foundation/cab/ishare-trust-framework/-/blob/main/.gitbook/assets/722173953.pdf), 24 June 2019
* [iSHARE v1.9](https://gitlab.com/ishare-foundation/cab/ishare-trust-framework/-/blob/main/.gitbook/assets/628392034.pdf), 5 April 2019
* [iSHARE v1.8](https://gitlab.com/ishare-foundation/cab/ishare-trust-framework/-/blob/main/.gitbook/assets/332660850.pdf), 31 October 2018
* [iSHARE v1.7](https://gitlab.com/ishare-foundation/cab/ishare-trust-framework/-/blob/main/.gitbook/assets/109182985.pdf), 28 June 2018
* [iSHARE v1.6](https://gitlab.com/ishare-foundation/cab/ishare-trust-framework/-/blob/main/.gitbook/assets/70229595.pdf), 11 May 2018
* [iSHARE v1.5](https://gitlab.com/ishare-foundation/cab/ishare-trust-framework/-/blob/main/.gitbook/assets/70229563.pdf), 14 December 2017
* [iSHARE v1.2](https://gitlab.com/ishare-foundation/cab/ishare-trust-framework/-/blob/main/.gitbook/assets/70227913.pdf), 25 October 2017
* [iSHARE v1.0](https://gitlab.com/ishare-foundation/cab/ishare-trust-framework/-/blob/main/.gitbook/assets/70226334.pdf), 23 June 2017
* [iSHARE v0.5](https://gitlab.com/ishare-foundation/cab/ishare-trust-framework/-/blob/main/.gitbook/assets/70223171.pdf), 24 March 2017
* [iSHARE v0.3](https://gitlab.com/ishare-foundation/cab/ishare-trust-framework/-/blob/main/.gitbook/assets/70228182.pdf), 27 February 2017
* [iSHARE v0.2](https://gitlab.com/ishare-foundation/cab/ishare-trust-framework/-/blob/main/.gitbook/assets/70223244.pdf), 13 February 2017
* [iSHARE v0.1](https://gitlab.com/ishare-foundation/cab/ishare-trust-framework/-/blob/main/.gitbook/assets/70223607.pdf) (start document)


# Main aspects of the iSHARE Trust Framework

The iSHARE Trust Framework is a combination of Functional, Technical, Operational and Legal agreements to which participating parties adhere. This chapter provides a bird's bird's-eye view of the main aspects of iSHARE specifications and an introduction to more in-depth details of the Trust Framework.

This section describes the Trust Framework's:

* [Key functionality](/main-aspects-of-the-ishare-trust-framework/key-functionality)
  * [Support Machine-to-Machine (M2M) interaction](/main-aspects-of-the-ishare-trust-framework/key-functionality/support-machine-to-machine-m2m-interaction)
  * [Support Human to Machine (H2M) interaction](/main-aspects-of-the-ishare-trust-framework/key-functionality/support-human-to-machine-h2m-interaction)
  * [Facilitate portable identity(s) for parties and humans](/main-aspects-of-the-ishare-trust-framework/key-functionality/facilitate-portable-identity-s-for-parties-and-humans)
  * [Facilitate flexible authorisations, applicable in any context](/main-aspects-of-the-ishare-trust-framework/key-functionality/facilitate-flexible-authorizations-applicable-in-any-context)
  * [Enable data exchange based on delegations - even between unknown parties](/main-aspects-of-the-ishare-trust-framework/key-functionality/enable-data-exchange-based-on-delegations-even-between-unknown-parties)
  * [Enable control over own data through management of consent](/main-aspects-of-the-ishare-trust-framework/key-functionality/enable-control-over-own-data-through-management-of-consent)
  * [Provide a Trust Framework](/main-aspects-of-the-ishare-trust-framework/key-functionality/provide-a-trust-framework)
  * [Support Verifiable Credentials](/main-aspects-of-the-ishare-trust-framework/key-functionality/support-verifiable-credentials)
* [Technical overview](/main-aspects-of-the-ishare-trust-framework/technical-overview)
* [Framework and roles](/main-aspects-of-the-ishare-trust-framework/framework-and-roles)
* [Legal provisions](/main-aspects-of-the-ishare-trust-framework/legal-provisions)
* [Operational provisions](/main-aspects-of-the-ishare-trust-framework/operational-provisions)


# Key functionality

The iSHARE Trust Framework aims to support the following key functionalities:

* [Support Machine-to-Machine (M2M) interaction](/main-aspects-of-the-ishare-trust-framework/key-functionality/support-machine-to-machine-m2m-interaction)
* [Support Human to Machine (H2M) interaction](/main-aspects-of-the-ishare-trust-framework/key-functionality/support-human-to-machine-h2m-interaction)
* [Facilitate portable identity(s) for parties and humans](/main-aspects-of-the-ishare-trust-framework/key-functionality/facilitate-portable-identity-s-for-parties-and-humans)
* [Facilitate flexible authorisations, applicable in any context](/main-aspects-of-the-ishare-trust-framework/key-functionality/facilitate-flexible-authorizations-applicable-in-any-context)
* [Enable data exchange based on delegations - even between unknown parties](/main-aspects-of-the-ishare-trust-framework/key-functionality/enable-data-exchange-based-on-delegations-even-between-unknown-parties)
* [Enable control over own data through management of consent](/main-aspects-of-the-ishare-trust-framework/key-functionality/enable-control-over-own-data-through-management-of-consent)
* [Provide a Trust Framework](/main-aspects-of-the-ishare-trust-framework/key-functionality/provide-a-trust-framework)
* [Support Verifiable Credentials](/main-aspects-of-the-ishare-trust-framework/key-functionality/support-verifiable-credentials)

In line with iSHARE' Trust Framework's [guiding principles](/introduction/guiding-principles), these key functionalities might be realised by (re)using existing standards or initiatives.


# Support Machine-to-Machine (M2M) interaction

The iSHARE Trust Framework aims to support multiple interaction models, of which Machine-to-Machine (M2M) is one. M2M interaction can be characterised as communication between machines, without interference by a human. In contemporary data communication, there is a heavy reliance on M2M interaction.

Example:

* Every day, the ERP system (machine) of party A requests a status update from the ERP system (machine) of party B. Party B's ERP system automatically responds with the requested status update. No humans are needed to interfere.

This example is detailed under [use cases](/use-cases).

The opposite of the M2M interaction model is the [Human to Machine interaction model](/main-aspects-of-the-ishare-trust-framework/key-functionality/support-human-to-machine-h2m-interaction).


# Support Human to Machine (H2M) interaction

The iSHARE Trust Framework aims to support multiple interaction models, of which Human to Machine (H2M) is one. H2M interaction can be characterised as communication between a human and (a) machine(s). A user interface is necessary to enable H2M communication.

Example:

* Human X, working for Party A, requests a status update from the ERP system (machine) of Party B. It does so via a user interface.

This example is detailed under [use cases](/use-cases).

The opposite of the H2M interaction model is the Machine-to-Machine[ interaction model](/main-aspects-of-the-ishare-trust-framework/key-functionality/support-machine-to-machine-m2m-interaction).


# Facilitate portable identity(s) for parties and humans

The iSHARE Trust Framework aims to facilitate (but not impose) the use of one or more so-called 'federated identity(s)'. A federated identity is an identity that is spread out and recognised, i.e. portable, across multiple, independent systems.

Within the iSHARE Trust Framework, the use of federated identities would reduce costs by eliminating the need for proprietary or newly issued identity solutions. In order for an identity to become part of iSHARE's federation, the legal entity providing the identity must be certified under the iSHARE Trust Framework.

Example:

* Human X, working for Party A, has a personal keycard issued by iSHARE-certified Identity Provider Y. The card, and thus the identity of Human X, can be used to identify and authenticate Human X at party B.

This example is detailed under [use cases](/use-cases).


# Facilitate flexible authorisations, applicable in any context

The iSHARE Trust Framework aims to enable parties to grant other parties or persons access to (parts of) their data or services. Parties within the iSHARE Trust Framework have greatly varying backgrounds, however. Private and public, large and small, different value chains, different geographies, different modalities, etc. For that reason, there needs to be a flexible way of expressing authorisations.

Two examples can illustrate different levels of required flexibility:

1. Some parties or contexts require management of authorisations on a very detailed level, e.g. Party A's ERP system (machine) is ONLY allowed to request status updates concerning line X of bill of lading Y;
2. Some contexts require less detailed authorisations, e.g. Party A's ERP system (machine) is allowed to request ANY information about ANY (part of a) bill of lading.

Both examples are explained under use cases: [fine-grained](/use-cases/use-case-m2m-interaction-with-fine-grained-authorization), [coarse-grained](/use-cases/use-case-h2m-interaction-with-coarse-grained-authorization).

The iSHARE Trust Framework envisions a world in which (access) authorisations are flexible in three ways:

* Flexible authorisation scope: iSHARE aims to provide a way to add a layer of authorisation to any resource or any selection or combination of resources. The authorisation scope refers to the objects or resources of a specific party to which authorisations need to be assigned. The scope can include many or all resources (e.g. all data), or only some resources (e.g. specific data fields or services). Either way, the scope is always governed by a formal agreement and implemented by technical means.
* Granular authorisations: iSHARE aims to provide a granular way to use authorisations for resources. The authorisation granularity refers to the characteristics of both the requested resources and the rules (policies, conditions) that apply. Authorisations to resources can be coarse-grained (e.g. someone has access to all data in a certain data scope) or fine-grained (e.g. someone has access to only data with a low sensitivity level). The rules (policies, conditions) that control the authorisations can be fine-grained as well, meaning that many different types of rules can apply, such as time of day, location, organisation, role, and competence level.
* Flexible authorisation source: iSHARE aims to provide flexibility in where authorisation rules are stored and can be retrieved. The authorisation source refers to the location of the rules (policies, conditions) and the attributes (e.g. subject attributes, object attributes) that govern the authorisations. These can be located near the data, at a dedicated source, or a combination thereof. In the current version of the iSHARE Trust Framework, the flexibility in authorisation source is described as 'Policy Information Point' or PIP in the [detailed functional descriptions](/detailed-descriptions/functional).


# Enable data exchange based on delegations - even between unknown parties

One of the barriers to exchanging data is often that parties do not know each other sufficiently, and therefore are not able to share data. Often, this can only be done after some form of contract has been established.

Within the iSHARE network, it is the explicit aim to make it possible to exchange data for parties that are unknown to each other based on delegations. A delegation within iSHARE functions as evidence that a party is directly or indirectly operating in the name of a known party. Based on the delegation a certain (unknown) party has given, a party can decide if this party may receive certain data or not.

Example:

* Party A hires Trucking Company B to deliver Container X to Party C. Trucking Company B's ERP system asks Party C's ERP system at what time it should deliver the container. Party C's ERP system does not know Trucking Company B, but can check the delegation to Trucking Company B that Party A has registered at Authorisation Registry D. Because this delegation is in order, Party C's ERP system shares a time slot with Trucking Company B's ERP.

This example is detailed under [use cases](/use-cases).


# Enable control over own data through management of consent

As described under key functionalities '[facilitate flexible authorisations](/main-aspects-of-the-ishare-trust-framework/key-functionality/facilitate-flexible-authorizations-applicable-in-any-context)' and '[enable data exchange based on delegations](/main-aspects-of-the-ishare-trust-framework/key-functionality/enable-data-exchange-based-on-delegations-even-between-unknown-parties)', the iSHARE Trust Framework aims to enable parties to grant other parties or persons access to (parts of) their data or services. At least as important is the aim to allow parties to modify or withdraw these access rights to their data or services, whenever they wish. This is called management of consent, and enables full control over own data at any moment in time.

Example:

* In the example described under key functionality '[enable data exchange based on delegations](/main-aspects-of-the-ishare-trust-framework/key-functionality/enable-data-exchange-based-on-delegations-even-between-unknown-parties)', Party A hires Trucking Company B to deliver Container X to Party C. Trucking Company B's ERP system asks Party C's ERP system at what time it should deliver the container. Party C's ERP system does not know Trucking Company B, but can check the delegation to Trucking Company B that Party A has registered at Authorisation Registry D. Because this delegation is in order, Party C's ERP system shares a time slot with Trucking Company B's ERP.
  * Now imagine that moments before Trucking Company B's ERP system asks Party C's ERP system for a time slot, Party C revokes Party A's access to requesting a time slot. Consequently, Trucking Company B's request for a time slot gets an access forbidden message; Trucking Company B's request is NOT accepted because Party A, and therewith delegated Trucking Company B, is no longer authorised to ask for a time slot.

Party C, as showcased, remains in full control over its own data and services at any moment in time. This example is detailed under [use cases](/use-cases).


# Provide a Trust Framework

Within the iSHARE network, it is the explicit aim to define trust based on a synthesis between technological and legal aspects. In practical terms, the aim is to let iSHARE participants interact within the network through a party that they know and trust (their Participant Registry) and sign one contract, based on which they have a contract with all participants within the data space/iSHARE network. In other words, participants within the data space/iSHARE network do not need to sign separate contracts with each other to share data with each other (although they are free to define additional contracts that do not conflict with the iSHARE Trust Framework).

An important tool within the Trust Framework is licenses, which define the conditions under which data can be exchanged or services can be consumed. For functional details on licenses, see the [Licenses page](/detailed-descriptions/functional/licenses).

The Trust Framework is depicted under [Primary use cases](/detailed-descriptions/functional/primary-use-cases) and needs an appropriate technological underpinning so that parties can authenticate each other in a reliable way.


# Support Verifiable Credentials

The iSHARE Framework supports Verifiable Credentials (VCs) to enhance trust, interoperability, and portability within and across data spaces.

This capability aligns iSHARE with global standards defined by the [W3C Verifiable Credentials Data Model 2.0](https://www.w3.org/TR/vc-data-model-2.0/), enabling participants to exchange digitally verifiable and privacy-preserving claims in a secure, standardised manner.

Integrating VCs as a global standard enhances decentralised identity and trust, already a foundation in iSHARE, to ensure digital credentials can be verified cryptographically without depending on a central authority.

### Benefits

* **Interoperable trust:** Credentials issued once can be used across multiple ecosystems as they are all based on the common standard.
* **Decentralised verification:** As has always been the case with iSHARE with VCs as well, no central authority is required for validation.
* **Privacy:** Using VCs could potentially be more privacy-preserving, as no real-time checks are necessary. Also, it supports the sharing of only relevant attributes via the means of Verifiable Presentations
* **Hybrid compatibility:** Works alongside current API-based mechanisms

### Example Scenario

A Service Consumer wants to access a dataset from a Service Provider in a mobility data space.

1. The Participant Registry issues the Service Consumer a **Participant Credential** confirming it is an iSHARE-adhering organisation.
2. The Authorisation Registry, on behalf of an Entitled Party, issues the Service Consumer a **Data Rights Credential** that states it can read specific transport data.
3. The Service Consumer stores both credentials in its wallet.
4. When requesting data, the Service Consumer presents these Verifiable Credentials to the Service Provider.
5. The Service Provider verifies the credentials and grants access if the rights are valid.

This entire process remains secure and verifiable, ensuring that both sides trust each other without prior arrangements or manual validation in line with iSHARE's principles.


# Technical overview

The iSHARE Trust Framework can be characterised as an API (Application Programming Interface) architecture for identification, authentication and authorisation based on a modified version of the widely used OAuth and OpenID Connect standards. The APIs specified for every role enable standardised interaction between computer systems.

{% hint style="info" %}
**Important**

APIs manage access to the 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, receiving complex instructions, to adding information to a database.

If a truck's systems send 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 entail data exchange.
{% endhint %}

The API architecture of the iSHARE Trust Framework also builds upon the following components:

* **PKI and digital certificates;** For the authentication of parties and machines, iSHARE uses PKI and digital certificates.
* **HTTP over TLS (HTTPS);** iSHARE uses the commonly used HTTP protocol for its communications, including TLS to encrypt the communications.
* **RESTful architectural style;** iSHARE uses the RESTful architectural style to structure APIs and HTTP calls.
* **JSON/JWT;** Data exchanged in the iSHARE context is structured using the JSON standard. Where non-repudiation is required, JWTs are used;
* **XACML.** Delegations are structured according to a JSON port of the XACML standard.
* **Verifiable Credentials (VCs)** support aligning with the W3C standard, enabling participants to issue, present, and verify participant/data rights credentials in a verifiable manner, adhering to a participant's privacy. This includes support of relevant industry standards such as the [Eclipse Decentralised Claims Protocol (DCP)](https://eclipse-dataspace-dcp.github.io/decentralized-claims-protocol/v1.0/) and [OpenID for Verifiable Credential Issuance (OpenID4VCI)](https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html) to ensure secure and standardised credential exchange.

The combination of the above standards and protocols leads to a certain dynamic between the [roles in the Trust Framework](/main-aspects-of-the-ishare-trust-framework/framework-and-roles). In essence, Service Consumers acquire a token which allows them to access certain services from certain Service Providers. The roles specified in the Framework are loosely based on the OAuth standard.

For a full explanation and description of all APIs, standards and protocols, please refer to the [Developer Portal](https://dev.ishare.eu/).


# Framework and roles

The iSHARE Trust Framework aims to provide generic building blocks for service provision, widely applicable in most sectors. This requires that the Framework can be applied to a wide variety of use cases in practice. This chapter explains the framework, its roles, and its relations, step by step.

{% hint style="info" %}
**Important (and as under technical overview)**

APIs manage access to the 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, 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, for example, this service might respond with 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 entail data exchange.
{% endhint %}

The iSHARE Framework consists of six roles that, depending on the situation, interact with each other based on the Trust Framework agreements. A party can fulfil multiple roles at the same time. Each role has a certain function in the framework and bears certain responsibilities, as described below:

<figure><img src="/files/qivpr3H7mEx7ZGrS4khX" alt=""><figcaption></figcaption></figure>

Any party fulfilling a role in the iSHARE 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.

{% hint style="info" %}
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 their own systems, or are only an Entitled Party for services at a single Service Provider.
{% endhint %}

* 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 <a href="#frameworkandroles-adheringroles" id="frameworkandroles-adheringroles"></a>

In any use case, the three adhering roles appear: a Service Consumer always consumes a Service Provider's service based on the Entitled Party's entitlements.

#### **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 the 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 time and location to calculate and communicate the truck's optimal route and Estimated Time of Arrival.

#### **Entitled Party**

The Entitled Party is the legal person that holds one or more legitimate rights regarding access to, use of, or control over data and/or data services provided by a [Service Provider (role)](https://framework.ishare.eu/glossary-and-legal-notices/glossary#glossary-serviceprovider-role-serviceprovider-role) with which it has a legal agreement.

This may include:

* The right to access or consume a data service (e.g. retrieve or send data)
* The right to exercise legal or contractual control over the data itself (e.g. data ownership, stewardship, or regulatory responsibility)

The Entitled Party, Service Consumer and Service Provider 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, a trucking company's entitlement to request Estimated Time of Arrival and optimal route information), but this is not necessary.

The Entitled Party can also delegate its rights to another Service Consumer. In the latter case, this other Service Consumer (or its machines and humans) may consume services on the Entitled Party’s behalf, but it is not necessary.

For example, our trucking company 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 the Estimated Time of Arrival and optimal route information to the trucking company.

### Certified roles <a href="#frameworkandroles-certifiedroles" id="frameworkandroles-certifiedroles"></a>

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 line 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, the iSHARE Trust Framework recognises several certified roles fulfilled by legal entities that offer outsourced identification, authentication, and authorisation tooling to Adhering Parties.

As detailed under [functional requirements per role](/detailed-descriptions/functional/functional-requirements-per-role), to become an iSHARE Certified Party, a legal entity must (first) be admitted as a participant by the Scheme Owner/Participant Registry (in the relevant role).

#### **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:

* Provides identifiers for humans;
* Issues credentials (i.e. a password or electronic keycard) to humans;
* Based on this identification information, it identifies and authenticates humans for Service Providers.
* Holds information on authorisations of humans representing a Service Consumer; i.e. information indicating which humans are authorised to act on a Service Consumer's behalf.
* Can check, based on this information, whether a human representing a legal entity is authorised to take delivery of a service;
* Can confirm whether this is the case with the Service Provider.

As a result, Service Providers can outsource the 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 relationship 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 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 that provides solutions for Adhering Parties for the storage of delegation and authorisation information. An Authorisation Registry:

* Can holds information on delegations to Service Consumers; i.e. information indicating what parts of the rights of an Entitled Party are delegated to a Service Consumer.
* Can check, based on this information, whether a machine representing a legal entity is authorised to take delivery of a service;
* Can confirm whether this is the case with the Service Provider.

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.

#### **Participant Registry (**[**previously called Satellite**](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/1)**)**

The Participant Registry ensures smooth membership management. All participants within the Data Space/iSHARE network will be explicitly linked to the Participant Registry responsible for their admission.\
\
The Participant Registry plays a fundamental role in any iSHARE use case. Every participant of the iSHARE Trust Framework can check with the Participant Registry whether other parties participate in iSHARE.

### iSHARE compatible software <a href="#frameworkandroles-isharecompatiblesoftware" id="frameworkandroles-isharecompatiblesoftware"></a>

Next to iSHARE adherence and certification, the concept of iSHARE compatibility exists. This concept is reserved for software that technically adheres to the 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 adhere to or be certified, whereas a party that delivers iSHARE-compatible software does not need to be so.

### Role of the Scheme Owner <a href="#frameworkandroles-roleoftheschemeowner" id="frameworkandroles-roleoftheschemeowner"></a>

The Scheme Owner role is fulfilled by the legal entity that keeps the Framework, and its network of participants, operating properly. How exactly is it found under the [detailed Operational descriptions](/detailed-descriptions/operational)?

The Scheme Owner is responsible for admission of the Participant Registries and the overall maintenance of the iSHARE Trust Framework.

Please refer to the [detailed](/detailed-descriptions/functional)[ descriptions ](/detailed-descriptions/functional)for details on how the Scheme Owner facilitates and federates trust in the iSHARE Trust Framework.

### Role of the Data Space Governance Body <a href="#frameworkandroles-roleofthesatellite" id="frameworkandroles-roleofthesatellite"></a>

The Data Space Governance Body role is fulfilled by the entity that is responsible for the data space, including the defining, evolving & maintaining and governing of participant life-cycle processes. This role can be fulfilled by a legal entity or by a non-legal entity (a group of parties with a certain governance). For reference, the definition of data spaces can be based on the [iSHARE Data Space Template](https://template.ishare.eu/), and this body is responsible for defining, evolving and governing the building blocks therein.

The Data Space Governance Body can also be the **Participant Registry** for their data space. Please note that the Data Space Governance Body does not have an active role in any use cases within the iSHARE network.

{% hint style="info" %}
NOTE: Legal entities can have both roles simultaneously, or a \*\*`Data Space Governance Body`\*\*could use (contract) a legal entity to fulfil the role of **`Participant Registry.`**
{% endhint %}

### Framework and roles in use cases <a href="#frameworkandroles-frameworkandrolesinusecases" id="frameworkandroles-frameworkandrolesinusecases"></a>

All of iSHARE's use cases can be depicted in the iSHARE Trust Framework. Their complexity is dependent on:

* The interaction model (Machine to Manon-legalHuman 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](/detailed-descriptions/functional/delegation-paths).
* 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:

<figure><img src="/files/qivpr3H7mEx7ZGrS4khX" alt=""><figcaption></figcaption></figure>

{% hint style="info" %}
NOTE: 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 use cases](/use-cases), all legal relations are shown before the actual interaction is plotted in the framework.
{% endhint %}


# Legal provisions

The legal underpinning of the iSHARE Trust Framework consists of a contract between all iSHARE participants and the iSHARE Scheme Owner (the so-called Accession Agreement). This contract can be signed with the Participant Registry instead. Based on this one contract with the Scheme Owner or Participant Registry, all participants are bound to the common iSHARE terms of use and can appeal to each other to abide by these rules (in legal terms, this is called perfection (Dutch: *derdenwerking*)).

Two main documents make up iSHARE's legal provisions:

1. **The Accession Agreement:** The main contract between the participant and the iSHARE Scheme Owner/Participant Registry. This contract refers to the terms of use, including all iSHARE specifications, to which all participants must abide. After signing the Accession Agreement, a party becomes a participant of the iSHARE network either as an Adhering Party or a Certified Party. There are two separate Accession Agreements: one for Adhering Parties and one for Certified Parties.
2. **The Terms of Use** The Terms of Use further define the rights and obligations of every iSHARE Participant and the Scheme Owner/Participant Registry. The Terms of Use apply to any party that has signed the Accession Agreement. The Terms of Use also state that participants fully abide by the iSHARE specifications.

**Data space agreements** - The data space can choose to embed the Accession Agreement and Terms of Use in its data space-specific agreements. The data spaces can also have additional agreements for their members.

For the details of the Accession Agreements, the full version of the Terms of Use and the information available on legal context, please refer to the [detailed Legal descriptions](/detailed-descriptions/legal).

### Licenses <a href="#legalprovisions-licenses" id="legalprovisions-licenses"></a>

Within the iSHARE network, it is possible to explicitly provide instructions on how a service may be consumed or under which conditions data is exchanged. These instructions or conditions are called licenses. Licenses are a crucial part of the iSHARE Trust Framework because they provide its participants the possibility to clearly state what is and what is not allowed.

Since all participants are bound to the same contract and underlying Trust Framework rules, participants are legally obliged to comply with the license conditions and can appeal to each other to follow the provided licenses. Licenses apply beyond the transaction and are included in [delegation evidence](https://framework.ishare.eu/detailed-descriptions/technical/structure-of-delegation-evidence), allowing for machine-readable and combined usage rules.

Please refer to the iSHARE Terms of Use for a detailed legal explanation.


# Operational provisions

The iSHARE Trust Framework is constantly improved in collaboration with its stakeholders. Keeping the Trust Framework and the network operating properly is facilitated by the iSHARE Scheme Owner.

The main responsibilities of the Scheme Owner include:

* Management of the iSHARE Trust Framework (specifications);
* Management of the iSHARE network (participants);
* Management of the iSHARE brand.

To fulfil its responsibilities, the Scheme Owner facilitates the correct operation of the iSHARE Trust Framework and network through administering several aspects:

* [Operational processes](/detailed-descriptions/operational/operational-processes)
* [Service levels](/detailed-descriptions/operational/service-levels)
* [Communication](/detailed-descriptions/operational/communication)

The Scheme Owner is part of a wider governance framework, which can be found in the [introduction of the Framework](/introduction/governance).


# Use cases

This chapter builds on the [iSHARE Trust Framework](/main-aspects-of-the-ishare-trust-framework/framework-and-roles) to showcase the [key functionalities](/main-aspects-of-the-ishare-trust-framework/key-functionality) in four use cases and their Verifiable Credentials (VC) variant.

Both versions describe the same business goals; they differ only in the technical evidence used for authentication and authorisation:

* **\[Classic]:** JWT artefacts and registry lookups
* **\[VC variant]**: Verifiable Credentials (VCs) and Verifiable Presentations (VPs) ([Refer to Glossary](/glossary-and-legal-notices/glossary))

{% hint style="info" %}
Many implementers run the classic flow today. The VC pages let you adopt RFC040 gradually and compare flows 1:1. Use whichever matches your deployment.
{% endhint %}

1. **Use case:** [**M2M interaction (with fine-grained authorisation)**](/use-cases/use-case-m2m-interaction-with-fine-grained-authorization) showcases:
   * [Support Machine-to-Machine (M2M) interaction](/main-aspects-of-the-ishare-trust-framework/key-functionality/support-machine-to-machine-m2m-interaction);
   * [Facilitate flexible authorisations, applicable in any context](/main-aspects-of-the-ishare-trust-framework/key-functionality/facilitate-flexible-authorizations-applicable-in-any-context).
2. **Use case:** [**H2M interaction (with coarse-grained authorisation)**](/use-cases/use-case-h2m-interaction-with-coarse-grained-authorization) showcases:
   * [Support Human to Machine (H2M) interaction](/main-aspects-of-the-ishare-trust-framework/key-functionality/support-human-to-machine-h2m-interaction);
   * [Facilitate flexible authorisations, applicable in any context](/main-aspects-of-the-ishare-trust-framework/key-functionality/facilitate-flexible-authorizations-applicable-in-any-context).
3. **Use case:** [**portable identity**](/use-cases/use-case-portable-identity) showcases:
   * [Facilitate portable identity(s) for parties and humans](/main-aspects-of-the-ishare-trust-framework/key-functionality/facilitate-portable-identity-s-for-parties-and-humans).
4. **Use case:** [**delegation (and management of consent)** ](/use-cases/use-case-delegation-and-management-of-consent)showcases:
   * [Enable data exchange based on delegations - even between unknown parties](/main-aspects-of-the-ishare-trust-framework/key-functionality/enable-data-exchange-based-on-delegations-even-between-unknown-parties);
   * [Enable control over own data through management of consent](/main-aspects-of-the-ishare-trust-framework/key-functionality/enable-control-over-own-data-through-management-of-consent).

### **Structure**

Each use case includes:

* A description and depiction of the roles and relations;
* A description of the prerequisites, and a depiction of prerequisite registration;
* A description and depiction of the use case;
* A sequence diagram;
* A reference to what needs to be technically implemented for this use case.

The depicted use cases are only a selection of the iSHARE Trust Framework's use case scope. For the full scope, please refer to the [detailed Functional descriptions](/detailed-descriptions/functional).


# Use case: M2M interaction (with fine-grained authorisation)

This use case showcases iSHARE Trust Framework's key functionality, '[support Machine to Machine (M2M) interaction](/main-aspects-of-the-ishare-trust-framework/key-functionality/support-machine-to-machine-m2m-interaction)'.

The example described in the linked chapter is as follows:

* Every day, the ERP system (machine) of Party A requests a status update from the ERP system (machine) of Party B. Party B's ERP system automatically responds with the requested status update. No humans are needed to interfere.

To showcase the key functionality '[facilitate flexible authorisations](/main-aspects-of-the-ishare-trust-framework/key-functionality/facilitate-flexible-authorizations-applicable-in-any-context)', Party A's ERP system (machine) is ONLY allowed to request status updates concerning line X of bill of lading Y. This can be considered a fine-grained authorisation.

The following explains this example in detail, utilising the iSHARE Trust Framework.

### Roles and Relations <a href="#usecase-m2minteraction-withfine-grainedauthorization-rolesandrelations" id="usecase-m2minteraction-withfine-grainedauthorization-rolesandrelations"></a>

The following roles are fulfilled in this use case:

* Party A requests a status update, so it is the participant fulfilling the **Service Consumer role**.
* Party B responds with the status update, so it is the participant fulfilling the **Service Provider role**.
* No delegation takes place, so Party A also fulfils the **Entitled Party role**.
* As this is an M2M use case, a **Machine Service Consumer** represents Party A.

The only **legal relation** is the mandatory relation between the Entitled Party (Party A) and the Service Provider (Party B), which establishes the entitlements of the Entitled Party (Party A). As depicted:

<figure><img src="/files/XjxLPw2HWCXGOpI3Ewe1" alt=""><figcaption></figcaption></figure>

### Prerequisites <a href="#usecase-m2minteraction-withfine-grainedauthorization-prerequisites" id="usecase-m2minteraction-withfine-grainedauthorization-prerequisites"></a>

It is a prerequisite of this use case that:

* **\[Classical JWT]:**
  * The Service Provider (Party B) has and manages its own entitlement information indicating what Entitled Parties are entitled to what (parts of) services, i.e. Party B has information indicating that Party A is allowed to request status updates concerning line X of bill of lading Y from its ERP system;
  * The Service Consumer (Party A) can authenticate the Service Provider (Party B);
  * The Service Provider (Party B) can authenticate the Service Consumer (Party A).
* **\[VC Variant]**:
  * Service Consumer (Party A) and Service Provider (Party B) have been issued a ParticipantCredential once onboarded into dataspace;
  * Service Consumer (Party A) has been issued a DataRights Credential from the Entitled Party (in this case Party A);
  * Service Provider (Party B) can verify Service Consumer's (Party A) Verifiable Credential/Presentation and viceversa.

### Use case <a href="#usecase-m2minteraction-withfine-grainedauthorization-usecase" id="usecase-m2minteraction-withfine-grainedauthorization-usecase"></a>

The use case consists of the following steps:

1. The Machine Service Consumer (of Party A) requests a service from the Service Provider (Party B);
2. The Service Provider (Party B) authenticates the Machine Service Consumer (of Party A) and validates the iSHARE adherence of the Service Consumer (Party A);
3. The Service Provider (Party B) authorises the Machine Service Consumer of the Service Consumer (Party A) based on the entitlement information registered with the Service Provider (Party B);
4. The Service Provider (Party B) executes the requested service;
5. The Service Provider (Party B) provides the service result to the Machine Service Consumer (of Party A).

As depicted:

<figure><img src="/files/8QBlP83mvbiNfJX1JRnp" alt=""><figcaption></figcaption></figure>

Note that this use case is the same as primary use case 1, as found under [detailed Functional descriptions](/detailed-descriptions/functional).

### Sequence diagram <a href="#usecase-m2minteraction-withfine-grainedauthorization-sequencediagram" id="usecase-m2minteraction-withfine-grainedauthorization-sequencediagram"></a>

<figure><img src="/files/RWjbSDyVj5UfXA39QVVr" alt=""><figcaption></figcaption></figure>

{% hint style="info" %}
**\[VC Variant]:** Authentication and Validation of iSHARE adherence is made through ParticipantCredential verification
{% endhint %}

What needs to be implemented technically for this use case is described [generically](/detailed-descriptions/technical/technical-standards), and specifically per role in the [iSHARE Developer Portal](https://dev.ishare.eu/).


# Use case: H2M interaction (with coarse-grained authorisation)

This use case showcases iSHARE Trust Framework's key functionality, '[support Human to Machine (H2M) interaction](/main-aspects-of-the-ishare-trust-framework/key-functionality/support-human-to-machine-h2m-interaction)'.

The example described in the linked chapter is as follows:

* Human X, working for Party A, requests a status update from the ERP system (machine) of Party B. It does so via a user interface.

To showcase the key functionality '[facilitate flexible authorisations](/main-aspects-of-the-ishare-trust-framework/key-functionality/facilitate-flexible-authorizations-applicable-in-any-context)', Party A's ERP system (machine) is allowed to request ANY information about ANY (part of a) bill of lading. This can be considered a coarse-grained authorisation.

The following explains this example in detail, utilising the iSHARE Trust Framework.

### Roles and Relations <a href="#usecase-h2minteraction-withcoarse-grainedauthorization-rolesandrelations" id="usecase-h2minteraction-withcoarse-grainedauthorization-rolesandrelations"></a>

The following roles are fulfilled in this use case:

* Party A requests a status update, so it is the participant fulfilling the **Service Consumer role**.
* Party B responds with the status update, so it is the participant fulfilling the **Service Provider role**.
* No delegation takes place, so Party A also fulfils the **Entitled Party role**.
* Human X is the **Human Service Consumer** that represents Party A.

The only **legal relation** is the mandatory relation between the Entitled Party (Party A) and the Service Provider (Party B), which establishes the entitlements of the Entitled Party (Party A). As depicted:

<figure><img src="/files/kU9kmxfAMr6inDKHjMoV" alt=""><figcaption></figcaption></figure>

### Prerequisites <a href="#usecase-h2minteraction-withcoarse-grainedauthorization-prerequisites" id="usecase-h2minteraction-withcoarse-grainedauthorization-prerequisites"></a>

It is a prerequisite of this use case that:

* **\[Classical JWT]:**
  * The Service Provider (Party B) has and manages its own entitlement information indicating what Entitled Parties are entitled to what (parts of) services, i.e. Party B has information indicating that Party A is allowed to request ANY information about ANY (part of a) bill of lading from its ERP system;
  * The Service Consumer (Party A) has and manages its own authorisation information indicating which Human Service Consumers are authorised to act on its behalf;
  * **The delegation/authorisation responsible at the the Service Consumer (Party A) registers the authorisation information at the Service Provider (Party B);**
  * The Human Service Consumer (Human X) can authenticate the Service Provider (Party B);
  * The Service Provider (Party B) can authenticate the Human Service Consumer (Human X);
  * **The Human Service Consumer (Human X) has been issued identity credentials by the Service Provider (Party B).**
* **\[VC Variant]**:
  * Human Service Consumer (Human X) has been issued an Identity Credential
  * Service Consumer (Party A) and Service Provider (Party B) have been issued a ParticipantCredential once onboarded into data space;
  * Human Service Consumer (Human X) has been issued a DataRights Credential from the Entitled Party (in this case Party A);
  * Service Provider (Party B) can verify Service Consumer's (Party A) Verifiable Credential/Presentation and vice versa.

### Use case <a href="#usecase-h2minteraction-withcoarse-grainedauthorization-usecase" id="usecase-h2minteraction-withcoarse-grainedauthorization-usecase"></a>

The use case consists of the following steps:

1. The Human Service Consumer (Human X) requests a service from the Service Provider (Party B);
2. The Service Provider (Party B) authenticates the Human Service Consumer (Human X), and validates the iSHARE adherence of the Service Consumer (Party A);
3. The Service Provider (Party B) authorises the Human Service Consumer (Human X) of the Service Consumer (Party A) based on the entitlement- and authorisation information registered with the Service Provider (Party B);
4. The Service Provider (Party B) executes the requested service;
5. The Service Provider (Party B) provides the service result to the Human Service Consumer (Human X).

As depicted

<figure><img src="/files/KrYvy4rjT6UNwvhq2K55" alt=""><figcaption></figcaption></figure>

Note that this use case is the same as primary use case 2, as found under [detailed Functional descriptions](/detailed-descriptions/functional).

### Sequence diagram <a href="#usecase-h2minteraction-withcoarse-grainedauthorization-sequencediagram" id="usecase-h2minteraction-withcoarse-grainedauthorization-sequencediagram"></a>

<figure><img src="/files/YoBEr9m5QL0xWjPnFDoE" alt=""><figcaption></figcaption></figure>

{% hint style="info" %}
**\[VC Variant] :** Service Provider checks authentication, delegation, and iSHARE adherence simultaneously by verifying the Service Consumer's Verifiable Presentation (which include Identity and DataRights Credential of the HSC and Participant Credential of the SC).
{% endhint %}

What needs to be implemented technically for this use case is described [generically](/detailed-descriptions/technical/technical-standards), and specifically per role in the [iSHARE Developer Portal](https://dev.ishare.eu/).


# Use case: portable identity

This use case showcases iSHARE Trust Framework's key functionality, '[facilitate portable identity(s) for parties and humans](/main-aspects-of-the-ishare-trust-framework/key-functionality/facilitate-portable-identity-s-for-parties-and-humans)'.

The example described in the linked chapter is as follows:

* Human X, working for Party A, has credentials issued by iSHARE certified Identity Provider Y. The credentials, and thus the identity of Human X, can be used to identify and authenticate Human X at party B.

Human X will now use its Identity Provider Y credentials to request a status update from the ERP system (machine) of Party B.

The following explains this example in detail, utilising the iSHARE Trust Framework.

### Roles and Relations <a href="#usecase-portableidentity-rolesandrelations" id="usecase-portableidentity-rolesandrelations"></a>

The following roles are fulfilled in this use case:

* Party A requests a status update, so it is the legal entity fulfilling the **Service Consumer role**.
* Party B responds with the status update, so it is the legal entity fulfilling the **Service Provider role**;
* No delegation takes place, so Party A also fulfils the **Entitled Party role**.
* Human X is the **Human Service Consumer** that represents Party A.
* Identity Provider Y is one of the **Identity Providers** to which Party B has outsourced identification, authentication and authorisation of humans, and the party that has given Human X his keycard.
* Optionally (and shown in this case), Identity Broker Z is the **Identity Broker** that provides Party B access to different Identity Providers, and that offers Human X the option to choose with which Identity Provider to identify and authenticate itself.

#### Legal relations <a href="#usecase-portableidentity-legalrelations" id="usecase-portableidentity-legalrelations"></a>

* As always, a mandatory relation between the Entitled Party (Party A) and the Service Provider (Party B) establishes the entitlements of the Entitled Party (Party A);
* A mandatory relation between the Service Provider and the Identity Broker covers the use of Identity Broker Z's services, including a connection to several Identity Providers, by the Service Provider (Party B);
* A mandatory relation between the Service Consumer (Party A) and Identity Provider Y covers the use of Identity Provider Y's keycards by the Service Consumer's (Party A's) humans, including Human X.

As depicted:

<figure><img src="/files/z1LJuxWZDul0egPWGD1y" alt=""><figcaption></figcaption></figure>

### Prerequisites <a href="#usecase-portableidentity-prerequisites" id="usecase-portableidentity-prerequisites"></a>

It is prerequisite of this use case that:

* **\[Classic JWT]**
* The Service Provider (Party B) has and manages its own entitlement information indicating what Entitled Parties are entitled to what (parts of) services, i.e. Party B has information indicating that Party A is entitled to status updates from its ERP system;
* The Service Consumer (Party A) has and manages its own authorization information indicating which Human Service Consumers are authorized to act on its behalf;
* **The delegation/authorization responsible at the the Service Consumer (Party A) registers the authorization information at the Identity Provider (Y);**
* The Human Service Consumer (Human X) is able to authenticate the Service Provider (Party B);
* The Service Provider (Party B) is able to authenticate the Human Service Consumer (Human X);
* The Identity Provider (Y) is able to authenticate the Service Provider (Party B);
* The Service Provider (Party B) is able to authenticate the Identity Provider (Y);
* The Identity Broker (Z) is able to authenticate the Service Provider (Party B);
* The Service Provider (Party B) is able to authenticate the Identity Broker (Z);
* **The Human Service Consumer (Human X) has been issued identity credentials by the Identity Provider (Y).**
* **\[VC Variant]**
  * Human Service Consumer (X) has been issued an Identity Credential by the Identity Provider (Y)
  * Service Consumer (Party A) and Service Provider (Party B) have been issued a ParticipantCredential once onboarded into dataspace;
  * Human Service Consumer (Human X) has been issued a DataRights Credential from the Entitled Party (in this case Party A);
  * All parties can verify each others Verifiable Credentials upon request.

The prerequisites in bold are depicted as follows:

<figure><img src="/files/YzMr9MLFwiDY7OgGlK92" alt=""><figcaption></figcaption></figure>

### Use case \[Classic JWT] <a href="#usecase-portableidentity-usecase" id="usecase-portableidentity-usecase"></a>

The use case varies between implementations and consists of the following steps:

1. The Human Service Consumer (Human X) requests a service from the Service Provider (Party B);
2. The Service Provider (Party B) requests a login from the Identity Broker (Z);
3. The Identity Broker (Z) asks the Human Service Consumer (Human X) to select his Identity Provider (Y);
4. The Identity Broker (Z) requests a login from the Identity Provider (Y);
5. The Identity Provider (Y) authenticates the Human Service Consumer (Human X) (based on Human X's credentials);
6. The Identity Provider (Y) issues an identity assertion and an authorisation assertion for the Service Provider (Party B) to the Identity Broker (Z);
7. The Identity Broker (Z) forwards the identity assertion and authorisation assertion to the Service Provider (Party B);
8. The Service Provider (Party B) validates the identity assertion and authorisation assertion through the following steps:
   1. The Service Provider (Party B) authenticates the Identity Broker (Z) and validates its iSHARE certification;
   2. The Service Provider (Party B) authenticates the Identity Provider (Y) and validates its iSHARE certification.
9. The Service Provider (Party B) authenticates the Human Service Consumer (Human X) based on the validity of the identity assertion, and validates the iSHARE adherence of the Service Consumer (Party A);
10. The Service Provider (Party B) authorises the Human Service Consumer (Human X) of the Service Consumer (Party A) based on the authorisation assertion and the entitlement information registered with the Service Provider (Party B);
11. The Service Provider (Party B) executes the requested service;
12. The Service Provider (Party B) provides the service result to the Human Service Consumer (Human X).

### Use Case \[VC Variant] <a href="#usecase-portableidentity-sequencediagram" id="usecase-portableidentity-sequencediagram"></a>

The use case consists of the following steps:

1. The Human Service Consumer (Human X) requests a service from the Service Provider (Party B);
2. The Service Provider (Party B) requests a verifiable presentation (VP) from Human Service Consumer (HSC) with all the required verifiable credentials (Identity, Participant and DataRights);
3. Human Service Consumer (Party A) creates the verifiable presentation (VP) and sends it to Service Provider (Party B);
4. The Service Provider (Party B) verifies the credentials inside the verifiable presentation;
5. The Service Provider (Party B) verifies the revocation status of the credentials;
6. The Service Provider (Party B) verifies the issuer of the credentials;
7. The Service Provider (Party B) executes the requested service;
8. The Service Provider (Party B) provides the service result to the Human Service Consumer (Human X).

As depicted:

<figure><img src="/files/wvoK5ts4O7eTSWOSkqNZ" alt=""><figcaption></figcaption></figure>

Note that this use case is the same as primary use case 3, as found under [detailed Functional descriptions](/detailed-descriptions/functional). In this section, the same use case is also explained without an Identity Broker.

### \[Classic JWT]: Sequence diagram <a href="#usecase-portableidentity-sequencediagram" id="usecase-portableidentity-sequencediagram"></a>

<figure><img src="/files/JCA5ETnKsKr7wsIeEVx7" alt=""><figcaption></figcaption></figure>

### \[VC Variant]: Sequence diagram <a href="#usecase-portableidentity-sequencediagram" id="usecase-portableidentity-sequencediagram"></a>

<figure><img src="/files/j3H7p7cBF2jBJe0IG7zE" alt=""><figcaption></figcaption></figure>

What needs to be implemented technically for this use case is described [generically](/detailed-descriptions/technical/technical-standards), and specifically per role in the [iSHARE Developer Portal](https://dev.ishare.eu/).


# Use case: delegation (and management of consent)

This use case showcases iSHARE Trust Framework's key functionality, enabling[ data exchange based on delegations - even between unknown parties](/main-aspects-of-the-ishare-trust-framework/key-functionality/enable-data-exchange-based-on-delegations-even-between-unknown-parties).

The example described in the linked chapter is as follows:

* Party A hires Trucking Company B to deliver Container X to Party C. Trucking Company B's ERP system asks Party C's ERP system at what time it should deliver the container. Party C's ERP system does not know Trucking Company B, but can check the delegation to Trucking Company B that Party A has registered at Authorisation Registry D. Because this delegation is in order, Party C's ERP system shares a time slot with Trucking Company B's ERP.

The following explains this example in detail, utilising the iSHARE Trust Framework.

After the explanation of the delegation use case, a scenario is introduced that showcases key functionality '[enable control over own data through management of consent](/main-aspects-of-the-ishare-trust-framework/key-functionality/enable-control-over-own-data-through-management-of-consent)'. In this [Use case: delegation (and management of consent)#Alternative scenario on management of consent,](#usecase-delegation-andmanagementofconsent-alternativescenarioonmanagementofconsent) Party C decides to revoke Party A's access to requesting a time slot.

### Roles and Relations <a href="#usecase-delegation-andmanagementofconsent-rolesandrelations" id="usecase-delegation-andmanagementofconsent-rolesandrelations"></a>

The following roles are fulfilled in this use case:

* Delegation takes place, with Party A being the party originally entitled to request a time slot. Party A therefore fulfils the **Entitled Party role**;
* Trucking Company B is delegated the right to request a time slot, so it is the legal entity fulfilling the **Service Consumer role**.
* Party C responds with the time slot, so it is the legal entity fulfilling the **Service Provider role**;
* Authorisation Registry D is the **Authorisation Registry** to which Party A has outsourced the management of delegation information.
* As this is an M2M use case, a **Machine Service Consumer** represents Trucking Company B.

#### Legal relations <a href="#usecase-delegation-andmanagementofconsent-legalrelations" id="usecase-delegation-andmanagementofconsent-legalrelations"></a>

* As always, a mandatory relation between the Entitled Party (Party A) and the Service Provider (Party C) establishes the entitlements of the Entitled Party (Party A);
* A mandatory relation between the Entitled Party (Party A) and the Service Consumer (Trucking Company B) covers the delegation of the right to request a time slot.
* A mandatory relation between the Entitled Party (Party A) and the Authorisation Registry (D) covers the outsourcing of managing delegation information.
* No relation between the Service Consumer (Trucking Company B) and the Service Provider (Party C) is mandatory before service consumption, i.e. the Service Consumer and the Service Provider do not need to know each other. This relation only commences through usage.
* No relation between the Service Provider (Party C) and the Authorisation Registry (D) is mandatory before communication. This relation also commences through usage.

As depicted:

<figure><img src="/files/BYfG0DtwwZewJcChDshn" alt=""><figcaption></figcaption></figure>

### Prerequisites <a href="#usecase-delegation-andmanagementofconsent-prerequisites" id="usecase-delegation-andmanagementofconsent-prerequisites"></a>

The a prerequisites vary depending on the implementation model:

* **\[Classic JWT]**
  * The Service Provider (Party C) has and manages its own entitlement information indicating what Entitled Parties are entitled to what (parts of) services, i.e. Party C has information indicating that Party A is entitled to request a time slot;
  * The Service Consumer (Trucking Company B) is able to authenticate the Service Provider (Party C);
  * The Service Provider (Party C) can authenticate the Service Consumer (Trucking Company B);
  * **The delegation/authorisation responsible at the Entitled Party (Party A) delegates (part of) the Entitled Party's (Party A's) rights (as registered at the Service Provider (Party C)) to the Service Consumer (Trucking Company B). He registers this delegation in an Authorisation Registry (D);**
  * The Service Provider (Party C) knows which Authorisation Registry (D) to request the delegation evidence from;
  * The Service Provider (Party C) can authenticate the Authorisation Registry (D);
  * The Authorisation Registry (D) can authenticate the Service Provider (Party C);
  * It is clear, through scheme agreements, under what conditions an Authorisation Registry can provide delegation information to a Service Provider.
* **\[VC Variant]**
  * The Service Provider (Party C) maintains entitlement info stating Party A is entitled to request a time slot;
  * ParticipantCredentials have been issued by the Participant Registry to Service Provider (Party C) and Service Consumer (Company B) including iSHARE adherence claim;
  * The Entitled Party (Party A) has delegated the right to Service Consumer via Authorisation Registry (Party D), which issued a DataRightsCredential to the Service Consumer (B) upon request;
  * The Machine Service Consumer (MSC) has a wallet able to hold and present the DataRights and Participant Credentials;
  * All parties can verify each others Verifiable Credentials upon request.

The prerequisites in bold are depicted as follows:

<figure><img src="/files/epdRNGdT8PWamqZ3A184" alt=""><figcaption></figcaption></figure>

### **Discovering Authorisation Rules:**

The Service Provider discovers the Authorisation Registry for the specific capability in this order; the first condition that applies determines the Authorisation Registry:

* Entitled Party has registered an Authorisation Registry for the specific capability in its /capabilities endpoint;
* Else the Entitled Party has registered the Authorisation Registry for the specific capability in the Participation Registry;
* Else the Entitled Party has registered an Authorisation Registry for a specific data space in the Participant Registry;
* Else 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).

### Use case <a href="#usecase-delegation-andmanagementofconsent-usecase" id="usecase-delegation-andmanagementofconsent-usecase"></a>

The use case varies depending on implementation model:

**\[Classic JWT]**

1. The Machine Service Consumer (of Trucking Company B) requests a service from the Service Provider (Party C);
2. The Service Provider (Party C) authenticates the Machine Service Consumer (of Trucking Company B) and validates the iSHARE adherence of the Service Consumer (Trucking Company B);
3. The Service Provider (C) discovers the applicable Authorisation Registry (D) as described in *Discovering Authorisation Rules.*
4. The Service Provider (Party C) requests delegation evidence from the Authorisation Registry (D);
5. The Authorisation Registry (D) authenticates the Service Provider (Party C) and validates its iSHARE adherence;
6. The Authorisation Registry (D) authorises the Service Provider (Party C) based on the scheme agreements for providing delegation information;
7. The Authorisation Registry (D) provides the delegation evidence;
8. The Service Provider (Party C) validates the received delegation evidence through the following steps:
   1. The Service Provider (Party C) authenticates the Authorisation Registry (D) and validates its iSHARE certification;
   2. The Service Provider (Party C) authorises the Entitled Party (Party A) based on the entitlement information registered with the Service Provider (Party C), and validates its iSHARE adherence.
9. The Service Provider (Party C) authorises the Machine Service Consumer of the Service Consumer (Trucking Company B) based on the validity of the delegation evidence;
10. The Service Provider (Party C) executes the requested service;
11. The Service Provider (Party C) provides the service result to the Machine Service Consumer (of Trucking Company B).

**\[VC Variant]:**

1. The Machine Service Consumer (MSC) of Trucking Company B requests a service from the Service Provider (Party C);
2. The Service Provider (Party C) requests a Verifiable Presentation (VP) describing the required claims (e.g., DataRightsCredential + ParticipantCredentials);
3. The MSC returns a VP containing the requested credentials;
4. The Service Provider (Party C) verifies the VP (signatures, keys, issuer trust, schema, credentialStatus);
5. The Service Provider (Party C) authorises the MSC based on the verified credentials;
6. The Service Provider (Party C) executes the service;
7. The Service Provider (Party C) provides the service result to the MSC.

As depicted:

<figure><img src="/files/qEUFKQsuV7PPCbLHKUmL" alt=""><figcaption></figcaption></figure>

Note that this use case is exactly the same as derived use case 1c, as found under [detailed Functional descriptions](/detailed-descriptions/functional). This section also includes delegation use cases with delegation information held by other roles than an Authorisation Registry. Note that this use case is exactly the same as derived use case 1c, as found under [detailed Functional descriptions](/detailed-descriptions/functional). This section also includes delegation use cases with delegation information held by other roles than an Authorisation Registry.

#### \[Classic JWT]: Sequence diagram

<figure><img src="/files/tp9LiqcolAiKcfufZyX6" alt=""><figcaption></figcaption></figure>

#### \[VC Variant]: Sequence Diagram <a href="#usecase-delegation-andmanagementofconsent-alternativescenarioonmanagementofconsent" id="usecase-delegation-andmanagementofconsent-alternativescenarioonmanagementofconsent"></a>

<figure><img src="/files/x4CUyNw7mUTJHZohkfcN" alt=""><figcaption></figcaption></figure>

### Alternative scenario <a href="#usecase-delegation-andmanagementofconsent-alternativescenarioonmanagementofconsent" id="usecase-delegation-andmanagementofconsent-alternativescenarioonmanagementofconsent"></a>

This alternative scenario showcases key functionality '[enable control over own data through management of consent](/main-aspects-of-the-ishare-trust-framework/key-functionality/enable-control-over-own-data-through-management-of-consent)'.

The example detailed above is as follows:

* Party A hires Trucking Company B to deliver Container X to Party C. Trucking Company B's ERP system asks Party C's ERP system at what time it should deliver the container. Party C's ERP system does not know Trucking Company B, but can check the delegation to Trucking Company B that Party A has registered at Authorisation Registry D. Because this delegation is in order, Party C's ERP system shares a time slot with Trucking Company B's ERP.

Now imagine:

* Moments before Trucking Company B's ERP system asks Party C's ERP system for a time slot, Entitled Party A revokes Trucking Company B's authorisation to requesting a time slot. Consequently, Trucking Company B's request for a time slot is rejected with a forbidden message; Trucking Company B's request is NOT accepted because Party A has revoked Trucking Company B's authorisation to request a time slot.

#### Prerequisites <a href="#usecase-delegation-andmanagementofconsent-prerequisites.1" id="usecase-delegation-andmanagementofconsent-prerequisites.1"></a>

To the prerequisites, ONLY the following changes:

**\[Classic JWT]**

* The Entitled Party (Party A) changes its entitlement information indicating what Parties are entitled to what (parts of) services, i.e. Party A deletes the information indicating that Party B is entitled to request a time slot.

**\[VC Variant]**

* The Service Provider (Party C) revokes DataRightsCredential status of a party, i.e. Party C deletes the information indicating that Party A is entitled to request a time slot.

#### Use case <a href="#usecase-delegation-andmanagementofconsent-usecase.1" id="usecase-delegation-andmanagementofconsent-usecase.1"></a>

The alternative use case consists of the following steps, with changes to the above use case in bold:

1. The Machine Service Consumer (of Trucking Company B) requests a service from the Service Provider (Party C);
2. The Service Provider (Party C) authenticates the Machine Service Consumer (of Trucking Company B) and validates the iSHARE adherence of the Service Consumer (Trucking Company B);
3. The Service Provider (C) discovers the applicable Authorisation Registry (D) as described in *Discovering Authorisation Rules.*
4. The Service Provider (Party C) requests delegation evidence from the Authorisation Registry (D);
5. The Authorisation Registry (D) authenticates the Service Provider (Party C) and validates its iSHARE adherence;
6. The Authorisation Registry (D) authorises the Service Provider (Party C) based on the scheme agreements for providing delegation information;
7. The Authorisation Registry (D) provides the delegation evidence;
8. The Service Provider (Party C) validates the received delegation evidence through the following steps;
   1. The Service Provider (Party C) authenticates the Authorisation Registry (D) and validates its iSHARE certification;
   2. The Service Provider (Party C) authenticates the Entitled Party (Party A) iSHARE and data space compliance;
9. The Service Provider (Party C) CANNOT authorise the Machine Service Consumer of the Service Consumer (Trucking Company B) based on the validity of the delegation evidence;
10. The Service Provider (Party C) communicates an access forbidden message to the Machine Service Consumer (of Trucking Company B).

#### \[Classic JWT]: Sequence diagram

<figure><img src="/files/O2IDRViF5Uqee9LIhvGr" alt=""><figcaption></figcaption></figure>

#### \[VC Variant]: Sequence Diagram <a href="#usecase-delegation-andmanagementofconsent-alternativescenarioonmanagementofconsent" id="usecase-delegation-andmanagementofconsent-alternativescenarioonmanagementofconsent"></a>

<figure><img src="/files/E5ZAI5E6UcY4X2rCNIwb" alt=""><figcaption></figcaption></figure>

{% hint style="info" %}
Note: The verification process made by the Service Provider (SP) failed after checking the revocation status of the Entitled Party A.
{% endhint %}

What needs to be implemented technically for this use case (and the alternative scenario) is described [generically](/detailed-descriptions/technical/technical-standards), and specifically per role in the [iSHARE Developer Portal](https://dev.ishare.eu/).


# Detailed descriptions

This chapter provides an in-depth overview of all the Functional, Technical, Operational and Legal details of the iSHARE Trust Framework. The following chapters are present in this section:

* [Functional](/detailed-descriptions/functional)
  * [Primary use cases](/detailed-descriptions/functional/primary-use-cases)
  * [Secondary use cases](/detailed-descriptions/functional/secondary-use-cases)
  * [Licenses](/detailed-descriptions/functional/licenses)
  * [Delegation paths](/detailed-descriptions/functional/delegation-paths)
  * [Functional requirements per role](/detailed-descriptions/functional/functional-requirements-per-role)
* [Technical](/detailed-descriptions/technical)
  * [Generic technical standards](/detailed-descriptions/technical/technical-standards)
  * [Structure of delegation evidence](/detailed-descriptions/technical/structure-of-delegation-evidence)
* [Operational](/detailed-descriptions/operational)
  * [Operational processes](/detailed-descriptions/operational/operational-processes)
  * [Service levels](/detailed-descriptions/operational/service-levels)
  * [Communication](/detailed-descriptions/operational/communication)
* [Legal](/detailed-descriptions/legal)
  * [Legal context](/detailed-descriptions/legal/legal-context)


# Functional

This section details the Trust Framework's functionality.

The [use cases depicted in earlier chapters](/use-cases) are only a selection of the iSHARE Trust Framework's full use case scope. This scope is based on [three 'primary' use cases](/detailed-descriptions/functional/primary-use-cases):

1. Machine-to-Machine service provision;
2. Human to Machine service provision with authorisation and identity info held at the Service Provider;
3. Human to Machine service provision with identity info held at the Identity Provider.

These primary use cases have several 'derived' use cases which cover all possible uses.

The primary use cases are supported by '[secondary' use cases](/detailed-descriptions/functional/secondary-use-cases), which include processes related to registration and processes that recur in primary use cases. This section is concluded by functional requirements - those [per role in the scheme](/detailed-descriptions/functional/functional-requirements-per-role) and those for the iSHARE [user interface](/detailed-descriptions/functional/functional-requirements-per-role/user-interface-requirements) in H2M use cases.


# 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 <a href="#primaryusecases-isharetrustframeworkfunctionaldescription" id="primaryusecases-isharetrustframeworkfunctionaldescription"></a>

The iSHARE Trust framework was first explained under [use cases](/main-aspects-of-the-ishare-trust-framework/framework-and-roles). 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.

<figure><img src="/files/ARZPhlado77Zj8XDE4bA" alt=""><figcaption></figcaption></figure>

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](/detailed-descriptions/functional/secondary-use-cases)). 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:

<figure><img src="/files/KmQVpXVmrgwRYL940XLx" alt=""><figcaption></figcaption></figure>

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](/detailed-descriptions/functional/delegation-paths).
* 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](/introduction/goals-and-scope-of-the-ishare-trust-framework):

* **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 <a href="#primaryusecases-threeprimaryusecases" id="primaryusecases-threeprimaryusecases"></a>

1. Machine-to-Machine service provision; Primary use case 1 caters to all Machine-to-Machine cases.
2. 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 <a href="#primaryusecases-derivedusecases" id="primaryusecases-derivedusecases"></a>

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](/detailed-descriptions/technical/technical-standards), 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.

1. The Entitled Party has registered an Authorisation Registry for the specific capability in its /capabilities endpoint;
2. The Entitled Party has registered the Authorisation Registry for the specific capability in the Participant Registry;
3. The Entitled Party has registered an Authorisation Registry for a specific data space in the Participant Registry;
4. The Entitled Party's has set a default Authorisation Registry in the Participant Registry.
5. 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

<table data-header-hidden data-full-width="true"><thead><tr><th></th><th></th><th></th><th></th><th></th><th></th></tr></thead><tbody><tr><td><br><br></td><td><strong>Delegation info PIP/PDP</strong></td><td></td><td></td><td></td><td></td></tr><tr><td></td><td><em>No delegation</em></td><td>Service Provider</td><td>Entitled Party</td><td>Authorisation Reg</td><td>Verifiable Credentials Variant</td></tr><tr><td>Derived use cases**</td><td><a href="https://gitlab.com/ishare-foundation/cab/ishare-trust-framework/-/blob/main/ishare-trust-framework/detailed-descriptions/functional/primary-use-cases/1.-m2m-service-provision">1</a></td><td>1a</td><td><a href="/pages/vXCWUyzd69caNA8xGIb2">1b</a></td><td><a href="/pages/iZLwAtIeCjrV85gjauvn">1c</a></td><td><a href="/pages/h5C4Kk9FhkotubaGoBmY">1d</a></td></tr></tbody></table>

\*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](/detailed-descriptions/functional/primary-use-cases/1.-m2m-service-provision/m2m-service-provision-including-an-app).

\*\*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)

1. The Service Provider can request delegation evidence after a service request from the Service Consumer;
2. The Machine Service Consumer can request delegation evidence and include it in its service request to the Service Provider;
3. 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:

1. 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;
2. 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.

<table data-header-hidden data-full-width="true"><thead><tr><th width="170"></th><th></th><th></th><th></th><th></th><th></th></tr></thead><tbody><tr><td><br><br></td><td></td><td><strong>Delegation evidence PIP/PDP</strong></td><td></td><td></td><td></td></tr><tr><td></td><td></td><td><em>No delegation</em></td><td>Service Provider</td><td>Entitled Party</td><td>Authorisation Reg</td></tr><tr><td><strong>Auth info PIP</strong></td><td>Identity Provider</td><td>2</td><td>2a</td><td>2b</td><td>2c</td></tr></tbody></table>

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](https://gitlab.com/ishare-foundation/cab/ishare-trust-framework/-/blob/main/detailed-descriptions/functional/primary-use-cases/3.-h2m-service-provision-with-identity-info-at-the-ip) is detailed both without an Identity Broker and with one.

### Rest of this section <a href="#primaryusecases-restofthissection" id="primaryusecases-restofthissection"></a>

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](/detailed-descriptions/functional/functional-requirements-per-role/user-interface-requirements).


# 1. M2M service provision

In use case 1, a service is provided by the Service Provider to the Machine Service Consumer.

### Roles <a href="#id-1.m2mserviceprovision-roles" id="id-1.m2mserviceprovision-roles"></a>

<table data-header-hidden data-full-width="true"><thead><tr><th></th><th></th><th></th><th></th><th></th><th></th></tr></thead><tbody><tr><td><br><br></td><td><strong>Delegation info PIP</strong></td><td></td><td></td><td></td><td></td></tr><tr><td></td><td><em>No delegation</em></td><td>Service Provider</td><td>Entitled Party</td><td>Authorisation Reg</td><td>VC Variant</td></tr><tr><td>Use case variation</td><td>1. M2M service provision</td><td>1a</td><td><a href="/pages/vXCWUyzd69caNA8xGIb2">1b</a></td><td><a href="/pages/iZLwAtIeCjrV85gjauvn">1c</a></td><td><a href="/pages/h5C4Kk9FhkotubaGoBmY">1d</a></td></tr></tbody></table>

As no delegation takes place, the legal entity fulfilling the Entitled Party role also fulfils the Service Consumer role.

### Depiction <a href="#id-1.m2mserviceprovision-depiction" id="id-1.m2mserviceprovision-depiction"></a>

#### **Legal relations** <a href="#id-1.m2mserviceprovision-legalrelations" id="id-1.m2mserviceprovision-legalrelations"></a>

<figure><img src="/files/mDEmiK2F6RpAn3PMEvYQ" alt=""><figcaption></figcaption></figure>

#### **Use case interaction** <a href="#id-1.m2mserviceprovision-usecaseinteraction" id="id-1.m2mserviceprovision-usecaseinteraction"></a>

<figure><img src="/files/z0QqmMnh7FRNN60vlkBW" alt=""><figcaption></figcaption></figure>

### Description <a href="#id-1.m2mserviceprovision-description" id="id-1.m2mserviceprovision-description"></a>

**It is a prerequisite of this use case that:**

* The Service Provider has and manages its own entitlement information indicating what Entitled Parties are entitled to what (parts of) services\*;
* The Service Consumer can authenticate the Service Provider.
* The Service Provider is able to authenticate the Service Consumer.
* In this use case, the Entitled Party is also the Service Consumer.

\*The Service Provider can outsource this function to a third party

**The use case consists of the following steps:**

1. The Machine Service Consumer requests a service from the Service Provider.
2. The Service Provider authenticates the Machine Service Consumer and validates the iSHARE adherence of the Service Consumer;
3. The Service Provider authorises the Machine Service Consumer of the Service Consumer based on the entitlement information registered with the Service Provider;
4. The Service Provider executes the requested service;
5. The Service Provider provides the service result to the Machine Service Consumer.

### Sequence diagram <a href="#id-1.m2mserviceprovision-sequencediagram" id="id-1.m2mserviceprovision-sequencediagram"></a>

<figure><img src="/files/dw7R80rMoVxVaqG97Q8R" alt=""><figcaption></figcaption></figure>


# 1b. M2M service provision with the EP storing delegation info

In use case 1b, a service is provided by the Service Provider to the Machine Service Consumer. The Service Consumer has been delegated by the Entitled Party.

### Roles <a href="#id-1b.m2mserviceprovisionwiththeepasthedelegationinfopip-roles" id="id-1b.m2mserviceprovisionwiththeepasthedelegationinfopip-roles"></a>

### Roles <a href="#id-1b.m2mserviceprovisionwiththeepasthedelegationinfopip-roles" id="id-1b.m2mserviceprovisionwiththeepasthedelegationinfopip-roles"></a>

<table data-header-hidden data-full-width="true"><thead><tr><th></th><th></th><th></th><th></th><th></th></tr></thead><tbody><tr><td><br><br></td><td><strong>Delegation info PIP</strong></td><td></td><td></td><td></td></tr><tr><td></td><td><em>No delegation</em></td><td>Service Provider</td><td>Entitled Party</td><td>Authorization Reg</td></tr><tr><td>Use case variation</td><td><a href="/pages/RXIjVhtxRcHeAGWGBqGP">1</a></td><td><a href="/pages/RXIjVhtxRcHeAGWGBqGP">1a</a></td><td>1b</td><td><a href="/pages/iZLwAtIeCjrV85gjauvn">1c</a></td></tr></tbody></table>

{% hint style="info" %}
An Authorisation Registry can be played by an EP itself or another organisation. In this case, the Entitled Party acts as the Authorisation Registry by holding its delegation evidence.
{% endhint %}

Note that interaction sequences are not described in the table above. In derived use case 1b, three interaction sequences are possible depending on who requests delegation info from the Authorisation Registry:

1. The Service Provider can request delegation info after a service request from the Service Consumer.
2. The Machine Service Consumer can request delegation info and include it in its service request to the Service Provider.
3. 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.

Interaction sequence 3 is detailed below.

### Depiction <a href="#id-1b.m2mserviceprovisionwiththeepasthedelegationinfopip-depiction" id="id-1b.m2mserviceprovisionwiththeepasthedelegationinfopip-depiction"></a>

#### Legal relations <a href="#id-1b.m2mserviceprovisionwiththeepasthedelegationinfopip-legalrelations" id="id-1b.m2mserviceprovisionwiththeepasthedelegationinfopip-legalrelations"></a>

<figure><img src="/files/jWaFCYOKLFnRKRYNlgIO" alt=""><figcaption></figcaption></figure>

Note that no prior legal relation exists between the Service Consumer and the Service Provider. Which services can be consumed by the Service Consumer, as delegated by the Entitled Party, is set out in the mandatory relation between this Entitled Party and the Service Provider.

#### Prerequisite registration <a href="#id-1b.m2mserviceprovisionwiththeepasthedelegationinfopip-prerequisiteregistration" id="id-1b.m2mserviceprovisionwiththeepasthedelegationinfopip-prerequisiteregistration"></a>

<figure><img src="/files/H1elwlvRI6ShsHlm7UWh" alt=""><figcaption></figcaption></figure>

**Use case interaction**

<figure><img src="/files/daixeSgWt6LlOZ51dfEq" alt=""><figcaption></figcaption></figure>

### Description <a href="#id-1b.m2mserviceprovisionwiththeepasthedelegationinfopip-description" id="id-1b.m2mserviceprovisionwiththeepasthedelegationinfopip-description"></a>

**It is a prerequisite of this use case that:**

* The Service Provider has and manages its own entitlement information indicating what Entitled Parties are entitled to what (parts of) services\*;
* The Service Consumer can authenticate the Service Provider.
* The Service Provider can authenticate the Service Consumer.
* The delegation/authorisation responsible at the Entitled Party delegates (part of) the Entitled Party's rights (as registered at the Service Provider) to the Service Consumer. He provides the Machine Service Consumer of the Service Consumer with evidence of this delegation.

\*The Service Provider can outsource this function to a third party

**The use case consists of the following steps:**

1. The Machine Service Consumer requests a service from the Service Provider. These requests include the evidence obtained from the Entitled Party.
2. The Service Provider authenticates the Machine Service Consumer and validates the iSHARE adherence of the Service Consumer;
3. The Service Provider validates the received delegation evidence through the following steps:
   1. The Service Provider authenticates the Entitled Party and validates its iSHARE adherence based on the delegation evidence.
   2. The Service Provider authorises the Entitled Party based on the entitlement information registered with the Service Provider.
4. The Service Provider authorises the Machine Service Consumer of the Service Consumer based on the validity of the delegation evidence.
5. The Service Provider executes the requested service.
6. The Service Provider provides the service result to the Machine Service Consumer.

### Sequence diagram <a href="#id-1b.m2mserviceprovisionwiththeepasthedelegationinfopip-sequencediagram" id="id-1b.m2mserviceprovisionwiththeepasthedelegationinfopip-sequencediagram"></a>

<figure><img src="/files/qYoeO1IiSpsrG2Z5vZO7" alt=""><figcaption></figcaption></figure>


# 1c. M2M service provision with the AR storing delegation info

In use case 1c, a service is provided by the Service Provider to the Service Consumer. The Service Consumer has been delegated by the Entitled Party, and the evidence is registered at an Authorisation Registry.

### Roles <a href="#id-1c.m2mserviceprovisionwiththearasthedelegationinfopip-roles" id="id-1c.m2mserviceprovisionwiththearasthedelegationinfopip-roles"></a>

<table data-header-hidden data-full-width="true"><thead><tr><th></th><th></th><th></th><th></th><th></th><th></th></tr></thead><tbody><tr><td><br><br></td><td><strong>Delegation info PIP</strong></td><td></td><td></td><td></td><td></td></tr><tr><td></td><td><em>No delegation</em></td><td>Service Provider</td><td>Entitled Party</td><td>Authorisation Reg</td><td>Verifiable Credentials Variant</td></tr><tr><td>Use case variation</td><td><a href="/pages/RXIjVhtxRcHeAGWGBqGP">1</a></td><td><a href="/pages/RXIjVhtxRcHeAGWGBqGP">1a</a></td><td><a href="/pages/vXCWUyzd69caNA8xGIb2">1b</a></td><td><a href="/pages/iZLwAtIeCjrV85gjauvn">1c</a></td><td><a href="/pages/h5C4Kk9FhkotubaGoBmY">1d</a></td></tr></tbody></table>

Note that interaction sequences are not described in the table above. In derived use case 1c, two interaction sequences are possible depending on who requests delegation info from the PIP:

1. The Service Provider can request delegation info after a service request from the Service Consumer.
2. The Machine Service Consumer can request delegation info and include it in its service request to the Service Provider.

Interaction sequence 1 is detailed below.

### Depiction <a href="#id-1c.m2mserviceprovisionwiththearasthedelegationinfopip-depiction" id="id-1c.m2mserviceprovisionwiththearasthedelegationinfopip-depiction"></a>

#### Legal relations <a href="#id-1c.m2mserviceprovisionwiththearasthedelegationinfopip-legalrelations" id="id-1c.m2mserviceprovisionwiththearasthedelegationinfopip-legalrelations"></a>

<figure><img src="/files/oAnvJ2OLPakXF7NcxCPc" alt=""><figcaption></figcaption></figure>

Note that no prior legal relation exists between the Service Consumer and the Service Provider. Which services can be consumed by the Service Consumer, as delegated by the Entitled Party, is set out in the mandatory relation between this Entitled Party and the Service Provider.

#### Prerequisite registration <a href="#id-1c.m2mserviceprovisionwiththearasthedelegationinfopip-prerequisiteregistration" id="id-1c.m2mserviceprovisionwiththearasthedelegationinfopip-prerequisiteregistration"></a>

<figure><img src="/files/2ZaRwiLS4I8iElbwjLNQ" alt=""><figcaption></figcaption></figure>

#### Use case interaction <a href="#id-1c.m2mserviceprovisionwiththearasthedelegationinfopip-usecaseinteraction" id="id-1c.m2mserviceprovisionwiththearasthedelegationinfopip-usecaseinteraction"></a>

<figure><img src="/files/gwvnNBJWb7PLQ4v6ikmr" alt=""><figcaption></figcaption></figure>

### Description <a href="#id-1c.m2mserviceprovisionwiththearasthedelegationinfopip-description" id="id-1c.m2mserviceprovisionwiththearasthedelegationinfopip-description"></a>

**It is a prerequisite of this use case that:**

* The Service Provider has and manages its own entitlement information indicating what Entitled Parties are entitled to what (parts of) services\*;
* The Service Consumer can authenticate the Service Provider.
* The Service Provider can authenticate the Service Consumer.
* The delegation/authorisation responsible at the Entitled Party delegates (part of) the Entitled Party's rights (as registered at the Service Provider) to the Service Consumer. He registers this delegation in an Authorisation Registry.
* The Service Provider knows/discovers which Authorisation Registry to request the delegation evidence from.
* The Service Provider can authenticate the Authorisation Registry.
* The Authorisation Registry can authenticate the Service Provider.
* It is clear, through scheme agreements, under what conditions an Authorisation Registry can provide delegation information to a Service Provider.

\*The Service Provider can outsource this function to a third party

### **Discovering Authorisation Rules:**

The Service Provider discovers the Authorisation Registry for the specific capability in this order; the first condition that applies determines the Authorisation Registry:

* Entitled Party has registered an Authorisation Registry for the specific capability in its /capabilities endpoint;
* Else the Entitled Party has registered the Authorisation Registry for the specific capability in the Participation Registry;
* Else the Entitled Party has registered an Authorisation Registry for a specific data space in the Participant Registry;
* Else 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).

**The use case consists of the following steps:**

1. The Machine Service Consumer requests a service from the Service Provider.
2. The Service Provider authenticates the Machine Service Consumer and validates the iSHARE adherence of the Service Consumer;
3. The Service Provider discovers (if not known) the applicable Authorisation Registry as described in *Discovering Authorisation Rules.*
4. The Service Provider requests delegation evidence from the Authorisation Registry;
5. The Authorisation Registry authenticates the Service Provider and validates its iSHARE adherence;
6. The Authorisation Registry authorises the Service Provider based on the scheme agreements for providing delegation information;
7. The Authorisation Registry provides the delegation evidence;
8. The Service Provider validates the received delegation evidence through the following steps:
   1. The Service Provider authenticates the Authorisation Registry and validates its iSHARE certification;
   2. The Service Provider authorises the Entitled Party based on the entitlement information registered with the Service Provider, and validates its iSHARE adherence.
9. The Service Provider authorises the Machine Service Consumer of the Service Consumer based on the validity of the delegation evidence;
10. The Service Provider executes the requested service;
11. The Service Provider provides the service result to the Machine Service Consumer.

### Sequence diagram <a href="#id-1c.m2mserviceprovisionwiththearasthedelegationinfopip-sequencediagram" id="id-1c.m2mserviceprovisionwiththearasthedelegationinfopip-sequencediagram"></a>

<figure><img src="/files/8HpBgqGGcdnH6yVdKbG1" alt=""><figcaption></figcaption></figure>


# 1d. M2M service provision with Verifiable Credentials

This subsection shows how [**1a**](/detailed-descriptions/functional/primary-use-cases/1.-m2m-service-provision), [**1b**](/detailed-descriptions/functional/primary-use-cases/1.-m2m-service-provision/1b.-m2m-service-provision-with-the-ep-as-the-delegation-info-pip), and [**1c**](/detailed-descriptions/functional/primary-use-cases/1.-m2m-service-provision/1c.-m2m-service-provision-with-the-ar-as-the-delegation-info-pip) change when using **Verifiable Credentials (VCs)**. With VCs, the execution becomes a single, standard flow; the only difference across variants is who issues the DataRights Credential and how the Machine Service Consumer (MSC) obtains it before calling the Service Provider (SP).

### General prerequisites (VC):

* The Machine Service Consumer (MSC) can hold credentials and create a Verifiable Presentation (VP) upon request;
* The Service Provider (SP) can request and verify VPs (signatures, keys, issuer trust, credential schema, credential status/revocation, and validity window);
* Parties have been issued ParticipantCredentials issued by the Participant Registry during onboarding (evidence of iSHARE adherence);
* Parties can verify each other's credentials upon request (to verify iSHARE adherence, revocation status, and trusted issuer lists when applicable).

{% hint style="info" %}
These credential verification checks (revocation status and whether the credential was issued by a trusted credential issuer) are assumed in every step, even if not explicitly described in the diagrams.
{% endhint %}

### General Execution Flow

1. Service Consumer requests service from Service Provider;
2. Service Provider requests Verifiable Presentation (VP) from Service Consumer;
3. Service Consumer sends the VP with all requested credentials to the Service Provider;
4. Service Provider Verifies VP (iSHARE adherence, signature, keys, issuer trust, schema, revocation status, validation window);
5. Service Provider provides service results to Service Consumer.

{% hint style="info" %}
Steps **1-3** may be combined if the SC includes a VP (with all the required credentials) in the initial request.
{% endhint %}

### 1a. M2M service provision (SC = EP)

No third-party delegation is needed. The Service Consumer (SC) is also the Entitled Party (EP) and already has the right.

#### **Sequence Diagram**

<figure><img src="/files/ZfJES3WYe2RqTisnipG4" alt=""><figcaption></figcaption></figure>

***

### 1b. M2M service provision with the **EP** as the delegation info PIP

The Entitled Party expresses delegation by issuing a DataRights Credential (VC) to the SC/MSC as a prerequisite.

#### **Sequence Diagram**

<figure><img src="/files/nVmJ0ziO5tvKc8VyvqN5" alt=""><figcaption></figcaption></figure>

***

### 1c. M2M service provision with the **AR** as the delegation info PIP

The Authorisation Registry stores the delegation information of the Entitled Party. The Service Consumer first discovers the Authorisation Registry (following Authorisation Registry discovery logic) & requests a DataRights Credential.

#### **Sequence Diagram**

<figure><img src="/files/WO8y1xOPdLdHXCFIP16b" alt=""><figcaption></figcaption></figure>


# M2M service provision including an app

Use case 1 and its variations can 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.

### Roles <a href="#m2mserviceprovisionincludinganapp-roles" id="m2mserviceprovisionincludinganapp-roles"></a>

<table data-header-hidden data-full-width="true"><thead><tr><th></th><th></th><th></th><th></th><th></th><th></th></tr></thead><tbody><tr><td><br><br></td><td><strong>Delegation info PIP</strong></td><td></td><td></td><td></td><td></td></tr><tr><td></td><td><em>No delegation</em></td><td>Service Provider</td><td>Entitled Party</td><td>Authorisation Reg</td><td>Verifiable Credentials Variant</td></tr><tr><td>Use case variation</td><td><a href="/pages/RXIjVhtxRcHeAGWGBqGP">1</a></td><td>1a</td><td><a href="/pages/vXCWUyzd69caNA8xGIb2">1b</a></td><td><a href="/pages/iZLwAtIeCjrV85gjauvn">1c</a></td><td><a href="/pages/h5C4Kk9FhkotubaGoBmY">1d</a></td></tr></tbody></table>

### Depiction <a href="#m2mserviceprovisionincludinganapp-depiction" id="m2mserviceprovisionincludinganapp-depiction"></a>

#### Legal relations <a href="#m2mserviceprovisionincludinganapp-legalrelations" id="m2mserviceprovisionincludinganapp-legalrelations"></a>

<figure><img src="/files/SkdtrBRcPQ4Ws0J0Ubdp" alt=""><figcaption></figcaption></figure>

#### Use case interaction <a href="#m2mserviceprovisionincludinganapp-usecaseinteraction" id="m2mserviceprovisionincludinganapp-usecaseinteraction"></a>

<figure><img src="/files/OrLKof2EMaclSqwVt7AF" alt=""><figcaption></figcaption></figure>

### Description <a href="#m2mserviceprovisionincludinganapp-description" id="m2mserviceprovisionincludinganapp-description"></a>

**As to use case 1, it is a prerequisite of this use case that:**

* The Service Provider has and manages its own entitlement information indicating what Entitled Parties are entitled to what (parts of) services\*;
* The Service Consumer can authenticate the Service Provider.
* The Service Provider is able to authenticate the Service Consumer.
* In this use case, the Entitled Party is also the Service Consumer.

\*The Service Provider can outsource this function to a third party

**The use case consists of the following steps:**

* The Human Service Consumer uses an app to request a service at the Machine Service Consumer - the Human Service Consumer's identity is included in the request.
* The request is mapped to a service request.

1. The Machine Service Consumer requests a service from the Service Provider.
2. The Service Provider authenticates the Machine Service Consumer and validates the iSHARE adherence of the Service Consumer;
3. The Service Provider authorises the Machine Service Consumer of the Service Consumer based on the entitlement information registered with the Service Provider;
4. The Service Provider executes the requested service;
5. The Service Provider provides the service result to the Machine Service Consumer;

* The Human Service Consumer accesses the result through app.

{% hint style="info" %}
**\[VC Variant]:** The HSC stores the Verifiable Credentials in a digital wallet and provides necessary credentials (Participant and DataRights Credential) upon App's request.
{% endhint %}


# 2. H2M service provision with identity info at the IP

In use case 2, a service is provided by the Service Provider to the Human Service Consumer. Identity info is held at the Identity Provider.

### Roles <a href="#id-3.h2mserviceprovisionwithidentityinfoattheip-roles" id="id-3.h2mserviceprovisionwithidentityinfoattheip-roles"></a>

<table data-header-hidden data-full-width="true"><thead><tr><th width="178"></th><th width="164"></th><th></th><th></th><th></th><th></th></tr></thead><tbody><tr><td><br><br></td><td></td><td><strong>Delegation info PIP</strong></td><td></td><td></td><td></td></tr><tr><td></td><td></td><td><em>No delegation</em></td><td>Service Provider</td><td>Entitled Party</td><td>Authorization Reg</td></tr><tr><td><strong>Auth info PIP</strong></td><td>Identity Provider</td><td>2.</td><td>2a</td><td>2b</td><td>2c</td></tr></tbody></table>

As no delegation takes place, the legal entity fulfilling the Entitled Party role also fulfils the Service Consumer role.

Note that an [Identity Broker ](/detailed-descriptions/functional/primary-use-cases/3.-h2m-service-provision-with-identity-info-at-the-ip/with-identity-broker)can be introduced to broker the relation between the Service Provider and the Identity Provider(s). This is optional and useful in situations with several Identity Providers.


# Without Identity Broker

This use case would look as follows without an Identity Broker:

#### Legal view <a href="#id-3.h2mserviceprovisionwithidentityinfoattheip-legalview" id="id-3.h2mserviceprovisionwithidentityinfoattheip-legalview"></a>

<figure><img src="/files/puiBvg9IqzA7edSoRl3v" alt=""><figcaption></figcaption></figure>

#### Prerequisite registration <a href="#id-3.h2mserviceprovisionwithidentityinfoattheip-prerequisiteregistration" id="id-3.h2mserviceprovisionwithidentityinfoattheip-prerequisiteregistration"></a>

<figure><img src="/files/dvAYlpbm8VZ90AB2kq93" alt=""><figcaption></figcaption></figure>

#### Interaction <a href="#id-3.h2mserviceprovisionwithidentityinfoattheip-interaction" id="id-3.h2mserviceprovisionwithidentityinfoattheip-interaction"></a>

<figure><img src="/files/hIJyxU4sbdmA0kO9FeAy" alt=""><figcaption></figcaption></figure>

### Description without Identity Broker <a href="#id-3.h2mserviceprovisionwithidentityinfoattheip-descriptionwithoutidentitybroker" id="id-3.h2mserviceprovisionwithidentityinfoattheip-descriptionwithoutidentitybroker"></a>

**It is a prerequisite of this use case that:**

* The Service Provider has and manages its own authorisation information indicating what Entitled Parties are entitled to what (parts of) services\*;
* The Service Consumer has and manages its own authorisation information indicating which Human Service Consumers are authorised to act on its behalf\*\*;
* The delegation/authorisation responsible at the Service Consumer registers the authorisation information at the Authorisation Registry;
* The Service Provider can authenticate the Human Service Consumer.
* The Identity Provider can authenticate the Service Provider.
* The Service Provider can authenticate the Identity Provider.
* The Human Service Consumer has been issued identity credentials by the Identity Provider.
* In this use case, the Entitled Party is also the Service Consumer.

\*The Service Provider can outsource this function to a third party

\*\*The Service Consumer can outsource this function to a third party

**Authorisation Registry discovery logic:**

The Service Provider discovers the Authorisation Registry for the specific capability in the following order. The first condition that applies, determines the location of the Authorisation Registry.

1. The Entitled Party has registered an Authorisation Registry for the specific capability in its /capabilities endpoint;
2. The Entitled Party has registered the Authorisation Registry for the specific capability in the Participant Registry;
3. The Entitled Party has registered an Authorisation Registry for a specific data space in the Participant Registry;
4. The Entitled Party's has set a default Authorisation Registry in the Participant Registry.

**The use case consists of the following steps:**

(Numbers are intended to explain the use case flow, it might vary from the diagram due to multiple authorisation methods)

1. The Human Service Consumer requests a service from the Service Provider.
2. The Service Provider asks the Human Service Consumer for their Identity Provider information.
3. The Human Service Consumer provides Identity Provider information to the Service Provider.
4. The Service Provider requests a login from the Identity Provider.
5. The Identity Provider requests credentials from the Human Service Consumer.
6. The Human Service Consumer provides credentials to the Identity Provider.
7. The Identity Provider authenticates the Human Service Consumer.
8. The Identity Provider provides an identity token to the Service Provider.
9. The Service Provider validates the Identity Provider’s iSHARE certification and the identity token of the Human Service Consumer.
10. The Service Provider discovers the applicable registry as described in *Discovering Authorisation rules* (if unknown)*.*
11. The Service Provider validates the Human Service Consumer based on the authorisation token (Refer to [methods of authorisation](#methods-of-authorization) on how an authorisation token is obtained.
12. The Service Provider validates authorisation and iSHARE adherence of the Service Consumer.
13. The Service Provider executes the requested service and provides the service result to the Human Service Consumer.

#### Methods of authorisation

Diagram 1: Authorisation via Identity Provider Checking Authorisation Registry (AR)

Diagram 2: Authorisation via Identity Provider Providing ID of Authorisation Registry to the Service Provider for Discovery

Diagram 3: Authorisation via Participant Registry Verifying Service Consumer Before Authorisation Check

### Sequence diagram without Identity Broker <a href="#id-3.h2mserviceprovisionwithidentityinfoattheip-sequencediagramwithoutidentitybroker" id="id-3.h2mserviceprovisionwithidentityinfoattheip-sequencediagramwithoutidentitybroker"></a>

<figure><img src="/files/KZMAtBS5rnXY4oZDa9cF" alt=""><figcaption><p>Authorisation via Identity Provider Checking Authorisation Registry (AR)</p></figcaption></figure>

<figure><img src="/files/LIfUEe4qOXJB9BZfLqA2" alt=""><figcaption><p>Authorisation via Identity Provider Providing ID of Authorisation Registry to the Service Provider</p></figcaption></figure>

<figure><img src="/files/GP9DeVuLdKlx5pF1T94z" alt=""><figcaption><p>Authorisation via Participant Registry Verifying Service Consumer Before Authorisation Check</p></figcaption></figure>


# With Identity Broker

#### Legal relations <a href="#id-3.h2mserviceprovisionwithidentityinfoattheip-legalrelations" id="id-3.h2mserviceprovisionwithidentityinfoattheip-legalrelations"></a>

<figure><img src="/files/Ogigoab96QMGgzJe2uyP" alt=""><figcaption></figcaption></figure>

#### Prerequisite registration <a href="#id-3.h2mserviceprovisionwithidentityinfoattheip-prerequisiteregistration.1" id="id-3.h2mserviceprovisionwithidentityinfoattheip-prerequisiteregistration.1"></a>

<figure><img src="/files/DM780HIUlkSY6X8U3gTN" alt=""><figcaption></figcaption></figure>

#### Use case interaction <a href="#id-3.h2mserviceprovisionwithidentityinfoattheip-usecaseinteraction" id="id-3.h2mserviceprovisionwithidentityinfoattheip-usecaseinteraction"></a>

<figure><img src="/files/wD6Wdx4Caoj8pShr6urL" alt=""><figcaption></figcaption></figure>

### Description with Identity Broker <a href="#id-3.h2mserviceprovisionwithidentityinfoattheip-descriptionwithidentitybroker" id="id-3.h2mserviceprovisionwithidentityinfoattheip-descriptionwithidentitybroker"></a>

**It is a prerequisite of this use case that:**

* The Service Provider has and manages its own authorisation information indicating what Entitled Parties are entitled to what (parts of) services\*;
* The Service Consumer has and manages its own authorisation information indicating which Human Service Consumers are authorised to act on its behalf\*\*;
* The delegation/authorisation responsible for the Service Consumer registers the authorisation information at the Authorisation Registry.
* The Service Provider can authenticate the Human Service Consumer.
* The Identity Provider can authenticate the Service Provider.
* The Service Provider can authenticate the Identity Provider.
* The Identity Broker can authenticate the Service Provider.
* The Service Provider can authenticate the Identity Broker.
* The Identity Broker is able to authenticate the Service Provider;
* The Service Provider is able to authenticate the Identity Broker;
* The Human Service Consumer has been issued identity credentials by the Identity Provider.
* In this use case, the Entitled Party is also the Service Consumer.

\*The Service Provider can outsource this function to a third party

\*\*The Entitled Party can outsource this function to a third party

**Authorisation Registry discovery logic:**

The Service Provider discovers the Authorisation Registry for the specific capability in the following order. The first condition that applies, determines the location of the Authorisation Registry.

1. The Entitled Party has registered an Authorisation Registry for the specific capability in its /capabilities endpoint;
2. The Entitled Party has registered the Authorisation Registry for the specific capability in the Participant Registry;
3. The Entitled Party has registered an Authorisation Registry for a specific data space in the Participant Registry;
4. The Entitled Party's has set a default Authorisation Registry in the Participant Registry.

**The use case consists of the following steps:**

(Numbers are intended to explain the use case flow, it might vary from the diagram due to multiple authorisation methods)

1. The Human Service Consumer requests a service from the Service Provider.
2. The Service Provider requests a login from the Identity Broker.
3. The Identity Broker asks the Human Service Consumer to select their Identity Provider.
4. The Human Service Consumer provides Identity Provider information to the Identity Broker.
5. The Identity Broker requests a login from the Identity Provider.
6. The Identity Provider requests credentials from the Human Service Consumer.
7. The Human Service Consumer provides credentials to the Identity Provider.
8. The Identity Provider authenticates the Human Service Consumer and provides an identity token to the Identity Broker, who forwards it to the Service Provider
9. The Service Provider validates the Identity Broker and Identity Provider’s iSHARE certification.
10. If the selected method of authorisation uses and Authorisation Registry, the Service Provider discovers the applicable registry as described in *Discovering Authorisation rules.*
11. The Service Provider validates the Human Service Consumer based on the authorisation token (Refer to [methods of authorisation](#methods-of-authorization) on how an authorisation token is obtained)
12. The Service Provider validates authorisation and iSHARE adherence of the Service Consumer.
13. The Service Provider executes the requested service and provides the service to the Human Service Consumer.

#### Methods of authorisation

Diagram 1: Authorisation via Identity Provider: Providing an Authorisation Link to the Service Provider

Diagram 2: Authorisation via Participant Registry Verifying Service Consumer Before Authorisation Check

Diagram 3: Authorisation via Identity Provider Checking Authorisation Registry (AR)

Diagram 4: Authorisation via Identity Broker Checking Authorisation Registry (AR)

### Sequence diagram with Identity Broker <a href="#id-3.h2mserviceprovisionwithidentityinfoattheip-sequencediagramwithidentitybroker" id="id-3.h2mserviceprovisionwithidentityinfoattheip-sequencediagramwithidentitybroker"></a>

<figure><img src="/files/tYeD6se1r4SdZoMdiAFK" alt=""><figcaption><p>Authorisation via Identity Provider Providing an Authorisation Link to the Service Provider</p></figcaption></figure>

<figure><img src="/files/0rZeYFZ1Ba39LV59U7sT" alt=""><figcaption><p>Authorisation via Authorisation Registry Verifying Service Consumer getting details from Participant Registry before Authorisation Check</p></figcaption></figure>

<figure><img src="/files/UF2wYqjXSiFpdVE0hvLv" alt=""><figcaption><p>Authorisation via Identity Provider Checking Authorisation Registry (AR)</p></figcaption></figure>

<figure><img src="/files/hCVHin9VjHpFL92AczNK" alt=""><figcaption><p>Authorisation via Identity Broker Checking Authorisation Registry (AR)</p></figcaption></figure>


# H2M with Verifiable Credentials

This subsection shows how the classic H2M sequences changes when using Verifiable Credentials (VCs). With VCs, the execution becomes a single, standard flow; the only difference from the classic variants is that identity information is carried in a Verifiable Presentation (VP) from the Human Service Consumer to the Service Provider. This Identity Credential is part of the prerequisites and is thus not included in the execution flow (no runtime Identity Provider or Identity Broker needed).

### **General prerequisites (VC):**

* The Human Service Consumer (HSC) holds an Identity VC in a wallet and can create a Verifiable Presentation (VP) upon request;
* The Service Provider (SP) can request and verify VPs (signatures, keys, issuer trust, credential schema, credential status/revocation, and validity window);
* Parties have been issued ParticipantCredentials by the Participant Registry during onboarding (evidence of iSHARE adherence);
* Parties can verify each other’s credentials upon request (to verify iSHARE adherence, revocation status, and trusted issuer lists when applicable).

{% hint style="info" %}
These credential verification checks (revocation status and whether the credential was issued by a trusted credential issuer) are assumed in every step, even if not explicitly described in the diagrams.
{% endhint %}

### **General Execution Flow**

1. Human Service Consumer requests service from Service Provider;
2. Service Provider requests Verifiable Presentation from Human Service Consumer;
3. Human Service Consumer sends the Verifiable Presentation with the requested credentials to Service Provider;
4. Service Provider verifies the Verifiable Presentation (iSHARE adherence, signature, keys, issuer trust, schema, revocation status, validity window);
5. SP provides service results to HSC.

{% hint style="info" %}
Steps 1–3 may be combined if the HSC includes a VP (with all required credentials) in the initial request.
{% endhint %}

### A) Without Identity Broker

**1) Authorisation via Identity Provider Checking Authorisation Registry (AR)**

* **Classic JWT :** Service Provider asks Identity Provider; Identity Provider checks Authorisation Registry; Identity Provider issues identity/authorisation token; Service Provider validates multiple tokens.
* **VC:** All Identity Provider and Authorisation Registry runtime calls disappear. Human Service Consumer presents **VP**; any credential required is **in the VP** (Identity and DataRights). Service Provider verifies once, then authorises.

**2) Authorisation via Identity Provider Providing an Authorisation Link to the Service Provider**

* **Classic JWT:** Identity Provider returns a link for Service Provider to fetch and verify.
* **VC:** Link is replaced by the **VP** from the Human Service Consumer. Service Provider verifies locally; no fetch-from-Identity Provider.

**3) Authorisation via Authorisation Registry Verifying Service Consumer using Participant Registry info**

* **Classic JWT:** SP/IdP/AR roundtrips, Authorisation Registry queries Participant Registry, then Service Provider validates.
* **VC:** Participant Registry checks are implicit via ParticipantCredential and issuer trust. Human Service Consumer’s **VP** carries the Identity and Participant credential; Service Provider verifies and applies policy, no Authorisation or Participant Registry runtime calls.

### Sequence Diagram

<figure><img src="/files/1GDmILjwSPoRQj00UA32" alt=""><figcaption></figcaption></figure>

### B) With Identity Broker

{% hint style="info" %}
An **Identity Broker is not required** in the VC runtime. It is **OPTIONAL** and only relays the Verifiable Presentation request and response.
{% endhint %}

For scenarios **1–3**, the sequence diagram is identical to the broker-less flow; just replace the direct Service Provider ↔ Human Service Consumer exchange with Service Provider ↔ Identity Broker ↔ Human Service Consumer (no extra checks or tokens are added).

### Sequence Diagram

<figure><img src="/files/SIu6nGOOfyADYLDFQlsW" alt=""><figcaption></figcaption></figure>


# Secondary use cases

iSHARE Trust Framework's [three primary use cases](/detailed-descriptions/functional/primary-use-cases) are supported by seven secondary use cases. These include:

* Processes related to registration;
* Processes that recur in primary use cases.

#### **Processes related to registration** <a href="#secondaryusecases-processesrelatedtoregistration" id="secondaryusecases-processesrelatedtoregistration"></a>

These four secondary use cases need to be completed before any specific, primary use cases can be initiated.

**Any party** needs to:

{% hint style="success" %}
1a. Register adherence/certification in the Participant Registry

And later needs to be able to:

1b. Modify adherence/certification in the Participant Registry
{% endhint %}

Before initiating Human to Machine use cases, the **Service Consumer** needs to:

{% hint style="success" %}
2a. Create Service Consumer and/or Human Service Consumer identity at Identity Provider. Prerequisites:

* An agreement needs to be in place between the Service Consumer and the Identity Provider.

Later, a Service Consumer needs to be able to:

2b. Modify Service Consumer and/or Human Service Consumer identity at Identity Provider
{% endhint %}

When delegating rights, the **Entitled Party** needs to:

{% hint style="success" %}
3a. Register delegation at Service Provider, Entitled Party, or Authorisation Registry. Prerequisite:

* For registration at the Service Provider or Authorisation Registry, an agreement needs to be in place between the Entitled Party and the Service Provider or Authorisation Registry.

Later, an Entitled Party needs to be able to:

3b. Modify delegation at Service Provider, Entitled Party, or Authorisation Registry
{% endhint %}

When authorising something or one, the **Service Consumer** needs to:

{% hint style="success" %}
4a. Register authorisation at Service Provider, Entitled Party, or Authorisation Registry. Prerequisite:

* For registration at the Service Provider or Authorisation Registry, an agreement needs to be in place between the Service Consumer and the Service Provider or Authorisation Registry.

Later, a Service Consumer needs to be able to:

4b. Modify authorisation at Service Provider, Entitled Party, or Authorisation Registry
{% endhint %}

#### **Processes that recur in primary use cases** <a href="#secondaryusecases-processesthatrecurinprimaryusecases" id="secondaryusecases-processesthatrecurinprimaryusecases"></a>

These three secondary use cases form the wiring of all primary use cases. Without them, primary use cases cannot be completed successfully.

In any primary use case, **any party** needs to:

{% hint style="success" %}
5a. Check whether its counterparty is iSHARE adherent/certified (with the Participant Registry)

5b. Check whether its counterparty’s certificate is valid
{% endhint %}

In any primary use case, the **Service Provider** *also* needs to:

{% hint style="success" %}
6\. Determine an authorisation decision based on entitlement-, delegation-, and/or authorisation info in its own contract administration and/or from external PIPs
{% endhint %}

When delegation- or authorisation info is requested by a Service Provider, an **Authorisation Registry** or **Entitled Party** also needs to:

{% hint style="success" %}
7\. Determine authorisation decision based on the Service Consumer assertion included in the Service Provider’s request
{% endhint %}

{% hint style="info" %}
Please note that the secondary use cases will not be detailed further than the above. No depictions or sequence diagrams are to be developed (contrary to those for the primary use cases). This (deliberately) leaves freedom in implementation. This specifically accounts for the registration of delegations: the way in which delegations are registered (as policies, business rules, in a separate register, or on top of existing applications) is not defined.
{% endhint %}


# Licenses

{% hint style="info" %}
In the context of the iSHARE Framework, 'Licenses' and 'Conditions of Exchange' are equal and can be used interchangeably. In the [iSHARE Terms of Use](/detailed-descriptions/legal#terms-of-use), they are referred to as 'Conditions of Exchange'.
{% endhint %}

Licenses allow an Entitled Party to explicitly specify what a Service Consumer is allowed to do with the consumption of a service or with received data. The licenses are included in the [delegation evidence](/detailed-descriptions/technical/structure-of-delegation-evidence) and are, in this way, applied to specific authorisations. Since all iSHARE participants have signed the terms of use and agree to the underlying scheme rules, participants are legally obliged to comply with the license conditions. In case of any violations, participants can appeal to each other based on the provided licenses.

The licenses, as maintained by iSHARE on [https://licenses.ishare.eu](https://licenses.ishare.eu/), serve as a foundational set provided by iSHARE. Data spaces may extend this set with additional licenses, provided they ensure appropriate legal backing for any additions, such as incorporating them into relevant agreements.

iSHARE licenses are categorised into the following categories:

* General
* Country
* Industry
* Certification

Licenses can be combined using logical operators.


# Delegation paths

A key functionality of the iSHARE Trust Framework is delegating rights to another party, authorising them to act on your behalf. A single delegation was described in the [delegation use case](/use-cases/use-case-delegation-and-management-of-consent).

In essence, Service Providers need to decide whether a Service Consumer is allowed access to a certain resource. To take the right access decisions, Service Providers need to interpret all relevant evidence to come to a decision: in other words, a 'logical sum' of evidence. This page further elaborates on situations where more than one delegation is issued that has overlapping properties.

### Example 1: Single delegation <a href="#delegationpaths-example1-singledelegation" id="delegationpaths-example1-singledelegation"></a>

In the situation of a single delegation, a Service Provider could encounter the following situation:

<figure><img src="/files/eCUedBicCCYPFmmRkaZS" alt=""><figcaption></figcaption></figure>

### Example 2: Simple path of delegation <a href="#delegationpaths-example2-simplepathofdelegation" id="delegationpaths-example2-simplepathofdelegation"></a>

In practice, various organisations can delegate rights to various other organisations. Combining these delegations, a 'path of delegation' can be established, as is illustrated in the following example:

<figure><img src="/files/auBo0tw9PLZksU1MeQJf" alt=""><figcaption></figcaption></figure>

### Example 3: Complex path of delegation <a href="#delegationpaths-example3-complexpathofdelegation" id="delegationpaths-example3-complexpathofdelegation"></a>

The following example illustrates a more complex delegation situation, where specific rights are delegated in terms of actions, resources and the right to further delegate these rights:

<figure><img src="/files/YQLLy5oLvt3tYzqiOfUn" alt=""><figcaption></figcaption></figure>

Party Q resides over party A's resources. When evaluating the available delegation evidence, organisation Q can conclude that organisation D has 'read' rights to resources X and Y, but is not allowed to delegate these reading rights any further.

What is important to note for this path of delegation is that the delegation rights **do not have to be given in a chronological order**. If party C just now delegated rights to D, while party D would have requested access earlier than party C would have delegated rights, the delegation path would not exist.

Within the data spaces/ iSHARE network, it is possible to define more detailed rights to resources, as described in the [key functionality section in the introduction](/main-aspects-of-the-ishare-trust-framework/key-functionality/facilitate-flexible-authorizations-applicable-in-any-context). For a detailed technical explanation of delegations, please refer to the '[structure of delegation evidence](/detailed-descriptions/technical/structure-of-delegation-evidence)' chapter.


# Functional requirements per role

{% hint style="info" %}
*This part of the iSHARE Trust Framework is considered normative and is therefore compliant with RFC 2119.*
{% endhint %}

This chapter summarises the responsibilities and functional requirements per role:

* Adhering roles:
  * [Service Consumer](#functionalrequirementsperrole-serviceconsumerserviceconsumer);
  * [Service Provider](#functionalrequirementsperrole-serviceproviderserviceprovider);
  * [Entitled Party](#functionalrequirementsperrole-entitledpartyentitledparty).
* Certified roles:
  * [Identity Provider](#functionalrequirementsperrole-identityprovideridentityprovider);
  * [Identity Broker](#functionalrequirementsperrole-identitybrokeridentitybroker);
  * [Authorisation Registry](#functionalrequirementsperrole-authorizationregistryauthorizationregistry);
  * [Participant Registry.](#participant-registry)

One requirement to any legal entity fulfilling a role is that they MUST [provide a unique identifier](/detailed-descriptions/functional/functional-requirements-per-role/party-identification).

{% hint style="info" %}
Existing JWT-based flows remain supported; roles MAY use either mechanism where stated.
{% endhint %}

***

### Adhering roles <a href="#functionalrequirementsperrole-adheringroles" id="functionalrequirementsperrole-adheringroles"></a>

Please refer to the [detailed Operation descriptions](/detailed-descriptions/operational) for what criteria need to be met to be onboarded as iSHARE compliant participant.

#### Service Consumer <a href="#functionalrequirementsperrole-serviceconsumerserviceconsumer" id="functionalrequirementsperrole-serviceconsumerserviceconsumer"></a>

The Service Consumer role is fulfilled by a participant who consumes a service, such as data, as provided by a Service Provider. A Service Consumer can be represented by:

1. Machine Service Consumer (MSC): uses the organisation’s certificate (eSeal/X.509) to onboard;
2. Human Service Consumer (HSC): onboarded via an iSHARE-certified Identity Provider/Broker (no own certificate)

The **functional requirements** applicable to Service Consumers are as follows:

* [iSHARE adherence](https://framework.ishare.eu/glossary-and-legal-notices/glossary#glossary-adherence-ishare-adherence-ishare) is REQUIRED;
* For **technical requirements**, refer to [Service Consumer getting started](https://dev.ishare.eu/service-consumer-role/getting-started) in the developer portal.

#### Service Provider <a href="#functionalrequirementsperrole-serviceproviderserviceprovider" id="functionalrequirementsperrole-serviceproviderserviceprovider"></a>

The Service Provider role is fulfilled by a participant who provides a service, such as data, for consumption by a Service Consumer.

The **functional requirements** applicable to Service Providers are as follows:

* [iSHARE adherence](https://framework.ishare.eu/glossary-and-legal-notices/glossary#glossary-adherence-ishare-adherence-ishare) is REQUIRED;
* All user interfaces provided in an iSHARE context MUST comply with the iSHARE's[ user interface requirements](/detailed-descriptions/functional/functional-requirements-per-role/user-interface-requirements);
* Service Provider MUST discover the Authorisation Registry (AR) internally for the requested capability before requesting delegation evidence.
  * either because the Service Provider and Entitled parties have shared an AR internally;
  * or from the EP’s `/capabilities` ; if absent, through the Participant Registry, as described in [*Authorisation Registry discovery logic*](https://app.gitbook.com/s/59lxF3S3XC9lWH5QZRei/use-cases/use-case-delegation-and-management-of-consent#authorisation-registry-discovery-logic)*;*
  * When an Identity Provider provides an authorisation link, the Service Provider MAY use the link and MUST verify the Authorisation Registry through the Participant Registry afterwards.
* For **technical requirements**, refer to [Service Provider getting started](https://dev.ishare.eu/service-provider-role/getting-started) in the developer portal.

#### Entitled Party <a href="#functionalrequirementsperrole-entitledpartyentitledparty" id="functionalrequirementsperrole-entitledpartyentitledparty"></a>

The **Entitled Party** is the participant that holds one or more legitimate rights regarding access to, use of, or control over data and/or data services provided by a [Service Provider (role)](https://framework.ishare.eu/glossary-and-legal-notices/glossary#glossary-serviceprovider-role-serviceprovider-role).

This may include:

* The right to access or consume a data service (e.g. retrieve or send data)
* The right to exercise legal or contractual control over the data itself (e.g. data ownership, stewardship, or regulatory responsibility)

Entitled Party, Service Consumer and Service Provider roles can be fulfilled by the same [participant](https://framework.ishare.eu/glossary-and-legal-notices/glossary#glossary-participant) (for example, a trucking company's entitlement to request Estimated Time of Arrival and optimal route information), but this is not necessary.

The Entitled Party can also delegate its rights to another Service Consumer. In the latter case, this other Service Consumer (or its machines and humans) may consume services on the Entitled Party’s behalf, but it is not necessary.

The **functional requirements** applicable to Entitled Parties are as follows:

* Entitled Party MUST make available to the Service Provider which Authorisation Registry holds delegation evidence by either direct communication, or publishing it per capability in its `/capabilities` endpoint or by registering it in the Participant Registry, as described in [*Authorisation Registry discovery logic.*](https://app.gitbook.com/s/59lxF3S3XC9lWH5QZRei/use-cases/use-case-delegation-and-management-of-consent#authorisation-registry-discovery-logic)
* Entitled Party MAY use different Authorisation Registries for different capabilities or data spaces.
* If the Entitled Party operates its own Authorisation Registry, it MUST meet the Authorisation Registry functional requirements, with the exception that it only provides delegation evidences for itself and not for someone else. In this setup the Entitled Party is an adhering party (not a certified Authorisation Registry).
* If the Entitled Party also acts as a Service Provider, it MUST meet the Service Provider functional requirements for its own services.
* iSHARE adherence is REQUIRED;
  * Note: As the Service Provider determines the Entitled Party, the Service Provider may provide services where the Entitled Party is not iSHARE-adherent. In that case, the Service Provider proxies on the Entitled Party’s behalf under a binding legal agreement, MUST be able to evidence that agreement, and assumes the Entitled Party’s responsibilities and liabilities towards other iSHARE participants for the proxied scope.
* For **technical requirements**, refer to [Entitled Party getting started](https://dev.ishare.eu/entitled-party/getting-started) in the developer portal.

***

### Certified roles <a href="#functionalrequirementsperrole-certifiedroles" id="functionalrequirementsperrole-certifiedroles"></a>

Please refer to the [detailed Operation descriptions](/detailed-descriptions/operational) for what criteria that need to be met to be admitted to the iSHARE network.

#### Identity Provider <a href="#functionalrequirementsperrole-identityprovideridentityprovider" id="functionalrequirementsperrole-identityprovideridentityprovider"></a>

The Identity Provider role is fulfilled by a participant whose tooling identifies and authenticates humans (and specifically, Human Service Consumers representing Service Consumers). An Identity Provider:

* Provides identifiers for humans;
* Issues and manages [credentials](/glossary-and-legal-notices/glossary#glossary-credentialscredentials) (i.e. a password or electronic keycard) for humans;
* Receive authentication requests from Service Providers;
* Provides an online interface to authenticate humans based on their credentials.
* Can hold information on authorisations of humans representing a Service Consumer; i.e. information indicating which humans are authorised to act on a Service Consumer's behalf;
* Can, after successful identification and authentication, based on this information, determine whether the human representing a participant is authorised to take delivery of a service;
* Can confirm the identity, authentication and authorisation information to the Service Provider, by providing an organizationIdentifier attribute, compliant to [ETSI EN 319 412-1 section 5.1.4](https://www.etsi.org/deliver/etsi_en/319400_319499/31941201/01.06.01_60/en_31941201v010601p.pdf).

As a result, Service Consumers are able to re-use their existing identities to authenticate themselves to different service providers whilst allowing Service Providers to optimise their software and processes while being able to serve larger number of consumers

The **functional requirements** applicable to Identity Providers are as follows:

* The Identity Provider MUST have a clear agreement with the Authorisation Registry concerning the process of allowing the registration, updating or removal of an authorisation;
* The Identity Provider MUST prevent a revoked authorisation from being processed as a valid authorisation;
* The Identity Provider MUST ensure that the identification and authentication process conforms to the Level of Assurance requested by the Service Provider.
* The Identity Provider MUST conform to the service levels for Certified Parties as described [here](/detailed-descriptions/operational/service-levels/service-levels-for-certified-parties-satellite) as minimum or as extended by respective data space;
* The Identity Provider MUST NOT claim accordance with a Level of Assurance for which it has not been certified;
* The processes of the Identity Provider MUST be in accordance with the Level of Assurance for which the Identity Provider has been certified;
* The Identity Provider MUST be listed in a Participant Registry as a participant in the role of Identity Provider (certified role) with level of assurance and compliance status;
* The Identity Provider MUST validate the organisation id during onboarding of the organisation following the process defined corresponding to the level of assurance.
* All user interfaces available in an iSHARE context MUST comply with the iSHARE's[ user interface requirements](/detailed-descriptions/functional/functional-requirements-per-role/user-interface-requirements);
* For **technical requirements**, refer to [Identity Provider getting started](https://dev.ishare.eu/identity-provider/getting-started) in the developer portal.

***

#### Identity Broker <a href="#functionalrequirementsperrole-identitybrokeridentitybroker" id="functionalrequirementsperrole-identitybrokeridentitybroker"></a>

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 relationship with each Identity Provider individually, an Identity Broker is introduced. The **Identity Broker** role is fulfilled by a participant 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.

An **Identity Broker** is an OPTIONAL intermediary that lets a Service Provider access multiple Identity Providers through one integration and lets humans choose an Identity Provider. iSHARE already enables direct Service Provider to Identity Provider connections; a broker is used only for consolidation and value-adds. For example, 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.

The **functional requirements** applicable to Identity Brokers are as follows:

* The Identity Broker MUST provide users with an interface to select their Identity Provider.
* The Identity Broker MUST conform to the service levels for Certified Parties as described [here](/detailed-descriptions/operational/service-levels/service-levels-for-certified-parties-satellite);
* The Identity Broker MUST NOT claim accordance with a Level of Assurance for which it has not been certified by the Scheme Owner;
* The processes of the Identity Broker MUST be in accordance with the Level of Assurance for which the Identity Broker has been certified;
* The Identity Broker MUST be listed in a Participant Registry as a participant in the role of Identity Broker (certified role) with level of assurance and compliance status;
* All user interfaces available in an iSHARE context MUST comply with the iSHARE's[ user interface requirements](/detailed-descriptions/functional/functional-requirements-per-role/user-interface-requirements);
* For **technical requirements**, refer to Identity Broker getting started in the developer portal.

***

#### Authorisation Registry <a href="#functionalrequirementsperrole-authorizationregistryauthorizationregistry" id="functionalrequirementsperrole-authorizationregistryauthorizationregistry"></a>

The Authorisation Registry role is fulfilled by a participant who provides delegation evidence as proof of delegations on behalf of entitled parties to other parties. An Authorisation Registry:

* Can hold information on delegations to Service Consumers; i.e. information indicating what parts of the rights of an Entitled Party are delegated to a Service Consumer;
* Has a process in place allowing for the registration, update and revocation of delegations;
* Can check, based on this information, whether a participant is authorised to take delivery of a service;
* Can confirm whether this is the case with the Service Provider.

As a result, Adhering Parties can outsource tasks concerning the management of delegation information to an Authorisation Registry instead of implementing their own tooling.

The **functional requirements** applicable to Authorisation Registries are as follows:

* The Authorisation Registry MUST have a clear agreement with the delegating entity concerning the process of allowing the registering, updating or removing of a delegation;
* The Authorisation Registry MUST prevent that a revoked delegation is processed as a valid delegation;
* The Authorisation Registry MUST conform to the service levels for Certified Parties as described [here](/detailed-descriptions/operational/service-levels/service-levels-for-certified-parties-satellite);
* The Authorisation Registry MUST NOT claim accordance with a Level of Assurance for which it has not been certified by the Scheme Owner;
* The Authorisation Registry MAY support receiving and processing delegation creation requests in line with iSHARE specifications;
* The processes of the Authorisation Registry MUST be in accordance with the Level of Assurance for which the Authorisation Registry has been certified;
* The Authorisation Registry MUST be listed in a Participant Registry as a participant in role of Authorisation Registry (certified role) with level of assurance and compliance status;
* For **technical requirements**, refer to [Authorisation Registry getting started](https://dev.ishare.eu/authorisation-registry-role/getting-started) in the developer portal.

***

#### Participant Registry

The Participant Registry role is fulfilled by a participant who validates and onboards the participants into the data space. The Data Space Governance Body defines the requirements and governs the process of onboarding participants into the data space. A Participant Registry:

* Can hold information on all participants in the data space; i.e. information indicating their level of assurance, services offered and roles performed in the data space.
* Has processes and criteria in place allowing for the onboarding or registration, update and review of participants;
* Can confirm whether a participant is a member of the data space.
* Can register and maintain claims for participants that are registered by other Participant Registries, provided that such claims are within the scope of the data space it governs and that mandatory validation requirements are fulfilled before claim submission.

The **functional requirements** applicable to Participant Registries are as follows:

* The Participant Registry MUST have a clear process and criteria agreed with the data space (governance body) concerning the onboarding, registering, updating or reviewing of a participant;
* The Participant Registry MUST conform to the service levels for Certified Parties as described [here](/detailed-descriptions/operational/service-levels/service-levels-for-certified-parties-satellite);
* The Participant Registry MUST NOT claim accordance with a Level of Assurance for which it has not been certified by the Scheme Owner;
* The processes of the Participant Registry MUST be in accordance with the Level of Assurance for which the Participant Registry has been certified;
* The Participant Registry MUST enable Service Providers to discover the Authorisation Registry through the Participant Registry when it is not declared in the Entitled Party’s `/capabilities` , following [*Authorisation Registry discovery logic.*](https://app.gitbook.com/s/59lxF3S3XC9lWH5QZRei/use-cases/use-case-delegation-and-management-of-consent#authorisation-registry-discovery-logic)
* The Participant Registry MUST be listed in a Participant Registry as a participant in the role of Participant Registry (certified role) with level of assurance and compliance status.
* The Participant Registry MAY register and maintain claims (e.g., data space memberships, roles, or credentials) for participants that are registered by other Participant Registries. Such actions MUST follow the defined operational and governance processes, ensuring proper validation, authenticity, and traceability of claims.
* The Participant Registry, on behalf of the scheme owner, can also onboard participants to be compliant with the iSHARE framework, but not in a data space;
* For **technical requirements**, refer to [Participant Registry getting started](https://dev.ishare.eu/participant-registry-role/getting-started) in the developer portal.


# Party identification

{% hint style="info" %}
*This part of the iSHARE Trust Framework is considered normative and is therefore compliant with RFC 2119.*
{% endhint %}

In order for parties to identify other parties, any party fulfilling a role in an iSHARE-based Data Space MUST provide a unique identifier. The following rules apply:

* Each Data Space MUST select one or more appropriate legal entity identifier(s) used for the identification of participants in the data space. It MAY define its own identifier for use within the data space, keeping the following in mind:
  * The identification (number/string) MUST be unique for each participant of the Data Space
  * The identification must comply with the [\<method>:\<value> format](#format-definition)
  * There will be no predefined list of approved identifiers published by the Scheme Owner
  * The use of a [DID method](https://www.w3.org/TR/did-spec-registries/#did-methods) is recommended, but other methods, including self-defined methods, are also permitted
* Each participant of a Data Space MUST have an iSHARE-ID, which is derived with the following considerations:
  * The iSHARE-ID will be in the form of an [iSHARE DID](https://did.ishare.eu/)
  * The iSHARE-ID uniquely identifies an iSHARE participant across data spaces
  * The iSHARE-ID must be provided to the participants by the first iSHARE Participant Registry where a party onboards
  * The iSHARE-ID will be equal to the organizationIdentifier, an attribute in the PKI certificate of the participant. Alternatively, for the parties onboarded via the certified identity providers without PKI certificates, the organizationIdentifier MUST be equal to the organizationIdentifier provided by the identity provider.

{% hint style="info" %}
**Note**

For example, when a Participant is onboarded using an eIDAS certificate, the identifier in the Subject of the eIDAS certificate is in the ASN.OID - "2.5.4.97" or commonly known as *OrganizationIdentifier* (issued by a Trust Service Provider (TSP)), with the format of this field described in [ETSI EN 319 412-1 V1.5.1, paragraph 5.1.4](https://www.etsi.org/deliver/etsi_en/319400_319499/31941201/01.05.01_60/en_31941201v010501p.pdf).
{% endhint %}

### Party Identification Model

1. Primary Identifier (id)
   * This is the iSHARE DID of the party.
   * It is the canonical identifier for the party across Data Spaces.
2. Also Known As (alsoKnownAs)
   * This is an array containing all other identifiers by which the party is recognised.
   * It may include DIDs using other methods, web identifiers, or self-defined identifiers.

In the Party model, identification information is structured into two parts. This structure replaces the former single array of identifiers.

#### Format Definition

Each identifier follows the format:

```
<method> : <value>
```

Where:

* \<method> defines the namespace or identification method (e.g., did:ishare, did:web, did:key, eori, oin, dataspace\_selfdefined\_identifier, etc.).
* \<value> is the unique value within that method’s name space.

#### Example

```
{
  "id": "did:ishare:EU.NL.NLNTR-12345678",
  "alsoKnownAs": [
    "did:ebsi:LEIXG-724500AZSGBRY55MNS59",
    "did:key:z6MkhfrsD3GUMjGvRxTTSamE1WnS9w3nDJLeZzT1KZVrU5tE",
    "AS.JA.NTA:1234567890123"
  ]
}
```

The iSHARE DID method is specified on <https://did.ishare.eu/>.

{% hint style="info" %}
**Note on backwards compatibility:** Any existing participants that have been registered with an EORI number will be migrated, and the EORI number will be kept in the party identifier array eori:\<existing EORI number>.
{% endhint %}

#### Notes

* The id element contains the primary iSHARE DID.
* The alsoKnownAs array may contain zero or more additional identifiers.
* Any identifiers previously stored in the old party identifier array MUST now be included under alsoKnownAs.
* Existing participants with an EORI number will be migrated, and the EORI number will be retained in the alsoKnownAs array as:

```
"eori:EU.EORI.NL123456789"
```


# User interface requirements

{% hint style="info" %}
*This part of the iSHARE Trust Framework is considered normative and is therefore compliant with RFC 2119.*
{% endhint %}

For all human-to-machine interactions, as in [primary use case 3](/detailed-descriptions/functional/primary-use-cases), an interface is required. This interface MUST comply with the following guidelines:

* The name of the legal entity that provides a broker service or identity provisioning service MUST be clearly visible;
* During the process of authentication, information not directly relating to the identity provision process or supporting the identity provision process MAY NOT be present. Links to websites irrelevant to the identity provisioning process or advertisements MAY NOT be present;
* Parties facilitating the identity provision process MAY use their own corporate styling and logos;
* The iSHARE brand MUST be shown during the identity provision process. Showing the iSHARE brand MUST be in line with iSHARE [communication](/detailed-descriptions/operational/communication) guidelines;
* Human Service Consumers that are being identified through the use of a browser MUST be able to verify the URL and used SSL certificate during all steps of the identity provisioning process.

Please note that extra guidance will need to be added for the context of apps: how can Human Service Consumers verify that they are not being tricked?


# Technical

This section covers the Technical details of the iSHARE Trust Framework.

The section starts out with a chapter containing an [overview of relevant technical standards](/detailed-descriptions/technical/technical-standards) that apply to the Trust Framework in general. Next, this section provides a dedicated chapter on the ['delegation evidence structure'](/detailed-descriptions/technical/structure-of-delegation-evidence), a JSON data structure which specifies how Authorisation Registries and Entitled Parties need to be able to present delegation evidence upon request.

Role-specific API requirements and the APIs can be found in the dedicated [iSHARE Developer Portal](https://dev.ishare.eu/).

* [Generic technical standards](/detailed-descriptions/technical/technical-standards)
* [Structure of delegation evidence](/detailed-descriptions/technical/structure-of-delegation-evidence)


# Technical standards

This chapter contains information on the technical standards that are applied in the iSHARE Framework, relevant to all parties involved.

The iSHARE Trust Framework provides an API architecture, which enables all parties involved to engage in direct communication. For interoperability reasons, it makes use of widely used open standards. Modified implementations of OAuth 2.0 and OpenID Connect 1.0 are used to facilitate an ecosystem in which parties can interact with previously unknown parties.

{% hint style="info" %}
**Note**

More information on iSHARE specific technical standards can be found in the [Developer Portal](https://dev.ishare.eu/introduction/specific-technical-standards) and our [Trust Body of Knowledge](https://trustbok.ishare.eu/apply-ishare/technical-standards).
{% endhint %}


# Structure of delegation evidence

{% hint style="info" %}
*This part of the iSHARE Trust Framework is considered normative and is therefore compliant with RFC 2119.*
{% endhint %}

This page describes (and prescribes) how participants can communicate about authorisations irrespective of the policy languages used by them. This way it allows interoperability between participants to exchange authorisations

In iSHARE based the data spaces delegation evidence expresses the delegation of rights from a delegator (the party that delegates rights; the `policyIssuer`) to the delegate (the party that receives the delegated rights; i.e. the `accessSubject`). Rights are expressed in `rules` in terms of allowed `actions` to be performed on resources, under the `license(s)` as defined in `policySets`.

Delegation evidence is modelled as a JSON object inspired by the XACML 3.0 specifications and structured as follows:

<figure><img src="/files/SxuI15n4SJL8ihbJY7im" alt=""><figcaption></figcaption></figure>

The JSON object consists of a root `delegationEvidence` element (modelled after an XACML `PolicySet` element) containing one or more `policySet` objects in the `policySets` array. The root element is only meant as a container element and extends the XACML specifications to cater for some iSHARE required metadata, such as timestamps. Each of the second level `policySet` elements only act as a container for the actual `policy` elements with an indication of the rights in this `policySet` can be further delegated (with `maxDelegationDepth`) and what [`license(s)`](/detailed-descriptions/functional/licenses) do apply. No other delegation logic is conveyed at the second level `policySet`. Each `policy` An element is used to express the actual rights being delegated.

The root `delegationEvidence` The element contains the following parameters.

| Parameter            | Contained in         | Type   | Required   | Description                                                                                                                                                                                                                                                                                                                                                                                                |
| -------------------- | -------------------- | ------ | ---------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `delegationEvidence` | <p><br></p>          | { }    | Yes        | The root of any delegation evidence                                                                                                                                                                                                                                                                                                                                                                        |
| `notBefore`          | `delegationEvidence` | int    | Yes        | Unix timestamp in UTC indicating the start of validity period of this delegation evidence. SHOULD equal the time of issuing of the evidence unless historic evidence is requested.                                                                                                                                                                                                                         |
| `notOnOrAfter`       | `delegationEvidence` | int    | Yes        | Unix timestamp in UTC indicating the end of validity period of this delegation evidence. It is up to the issuer off the evidence to set this time. Note that a reasonable amount of time SHOULD be allowed for processing of longer delegation paths. Also note that evidence cannot be revoked, so setting very long validity periods SHOULD be avoided.                                                  |
| `policyIssuer`       | `delegationEvidence` | string | Yes        | [Party Identifier](/detailed-descriptions/functional/functional-requirements-per-role/party-identification) of the delegator (the delegating entity)                                                                                                                                                                                                                                                       |
| `target`             | `delegationEvidence` | { }    | Yes        | Root level MUST contain an `accessSubject` attribute. No other elements are allowed. It makes the entire delegation evidence applicable only to this `accessSubject`.                                                                                                                                                                                                                                      |
| `accessSubject`      | `target`             | string | Yes        | [Party Identifier](/detailed-descriptions/functional/functional-requirements-per-role/party-identification) of the delegate (the entity that receives the delegated rights)                                                                                                                                                                                                                                |
| `policySets`         | `delegationEvidence` | \[ ]   | Yes (1..n) | Container for one or more objects containing `policy` elements with an indication for further delegation. Note that `policySet` elements within one `delegationEvidence` MUST not restrict each other, but rather offer a mechanism to express additional rights. They MUST be evaluated in a "permit-override" manner, allowing a "Permit" if only one of the `policySet` elements evaluates to "Permit". |

The second-level objects in `policySets` each contains the following parameters. Other parameters are not allowed. Note that the XACML spec is heavily restricted, a.o., for the reason to prevent redundancy (and resulting possible conflicts) with the root `policySet` element.

| Parameter            | Contained in  | Type | Required   | Description                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                |
| -------------------- | ------------- | ---- | ---------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `maxDelegationDepth` | `policySets`  | int  | No         | Optional element that, if present, indicates that further delegation of the rights, conveyed in the `policy` elements that are part of this `PolicySet`, is allowed. The value indicates the delegation steps that are allowed after this step in order to evaluate the entire delegation path to "Permit"                                                                                                                                                                                                                 |
| `target`             | `policySet`   | { }  | Yes        |                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            |
| `environment`        | `target`      | { }  | Yes        |                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            |
| `licenses`           | `environment` | \[ ] | Yes        | Defines which [iSHARE licenses](/detailed-descriptions/functional/licenses) apply to this `policySet`. Defined as an array, licenses is now a structured object that supports logical composition of URIs (e.g., allOf, anyOf) to express multiple applicable licenses and their relationships. This allows for complex licensing scenarios such as conditional usage, combinations of geographical constraints, or certification requirements. For more information on [licences](https://dev.ishare.eu/licenses-model) . |
| `policies`           | `policySets`  | \[ ] | Yes (1..n) | Used to express the actual rights being delegated. Note that `policies` within one `policySets` object MUST not restrict each other, but rather offer a mechanism to express additional rights. They MUST be evaluated in a "permit-override" manner, allowing a "Permit" if only one of the `policy` elements evaluates to "Permit".                                                                                                                                                                                      |

A `Policy` element contains the following parameters.

| Parameter     | Contained in | Type   | Required   | Description                                                                                                                                                                                                                        |
| ------------- | ------------ | ------ | ---------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `target`      | `policies`   | string | Yes        | Describes the target, in terms of resource and action, this policy applies to. It is also the scope that is permitted through the default Rule. Additional conditions that may be passed on along with the default rule            |
| `resource`    | `target`     | { }    | Yes        | Defines the data or asset to which the delegated rights apply, including its type, unique identifiers, and optional attributes describing specific elements of that resource                                                       |
| `type`        | `resource`   | string | Yes        | <p>String which describes the type of resource to which the rules apply.<br><br>The use of the type "iSHARE.DELEGATION" is reserved for <a href="https://dev.ishare.eu/reference/authorisation-rules">authorisation rules</a>.</p> |
| `identifiers` | `resource`   | \[ ]   | Yes        | Array of strings containing one or more resource identifiers. Depending on the `Type` an `identifier` SHOULD be a urn.                                                                                                             |
| `attributes`  | `resource`   | \[ ]   | No         | Optional array of attributes of the resources the delegated rights apply to. If omitted defaults to all attributes. Depending on the `Type` an `attribute` SHOULD be a URN.                                                        |
| `actions`     | `target`     | \[ ]   | Yes        | Array specifying the operations (e.g., ISHARE.READ) that the delegate is permitted to perform on the defined resources.                                                                                                            |
| `rules`       | `policies`   | \[ ]   | Yes (1..1) | Contains one Rule element.                                                                                                                                                                                                         |

The `Rule` element contains the following parameters.

| Parameter    | Contained in | Type   | Required | Description                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            |
| ------------ | ------------ | ------ | -------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `effect`     | `rules`      | string | Yes      | Contain 'Permit' or 'Deny', as the outcome of Authorization Registry logic.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            |
| `conditions` | `rules`      | {}     | No       | <p>Optional conditions which must be evaluated. For guidance on how to interoperably define conditions, refer to the page about delegation evidence conditions (When SC requests the delegation token, then AR can include this condition so that the delegation token is only applicable at that specific SP. Alternatively, when SP is requesting token that condition is not sent in rules but is part of enviornment conditions under resource which AR must process and apply). The following keywords in conditions are reseved:<br><code>serviceProviders</code>: reserved keyword for a condition that contains a list of party identifiers of serviceProviders which are allowed to provide services to the accessSubject</p> |

Example delegation JSON:

```json
// Organisation A delegates rights to organisation B. A allows B 
// READ and CREATE access to all ETA and WEIGHT of A's containers 
// of which the data is located at service provider C and can only 
// be accessed with service provider C. Furthermore, all 
// rights of B are allowed under the iSHARE license 
// https://licenses.ishare.eu/general-non-commercial-use/1.0, 
// in France and Belgium only, and B has the right to delegate its 
// right two more times.

{
    "delegationEvidence": {
        "notBefore": 1509633681,
        "notOnOrAfter": 1509633741,
        "policyIssuer": "did:ishare:EU.NL.NTRLNL-10000005",
        "target": {
            "accessSubject": "did:ishare:EU.NL.NTRLNL-10000001"
        },
        "policySets": [
            {
                "maxDelegationDepth": 2,
                "target": {
                    "environment": {
                        "licenses": [
                            {
                                "allOf": [
                                    "https://licenses.ishare.eu/general-non-commercial-use/1.0",
                                    {
                                        "anyOf": [
                                            "https://licenses.ishare.eu/country/be/1.0",
                                            "https://licenses.ishare.eu/country/fr/1.0"
                                        ]
                                    }
                                ]
                            }
                        ]
                    }
                },
                "policies": [
                    {
                        "target": {
                            "resource": {
                                "type": "GS1.CONTAINER",
                                "identifiers": ["*"],
                                "attributes": ["GS1.CONTAINER.ATTRIBUTE.ETA", "GS1.CONTAINER.ATTRIBUTE.WEIGHT"]
                            },
                            "actions": ["ISHARE.READ", "ISHARE.CREATE"]
                        },
                        "rules": [
                            {
                                "effect": "Permit",
                                "conditions": {
                                    "anyof": [
                                        {
                                            "leftOperand": "serviceProvider",
                                            "operator": "equal",
                                            "rightOperand": "did:ishare:EU.NL.NTRNL-10000003"
                                        }
                                    ]
                                }
                            }
                        ]
                    }
                ]
            }
        ]
    }
}
```


# Example cases

The main variations in the JSON code for delegationEvidence are the (1-n) `policySets`, `policies` and `rules` arrays. These variations are based on the most efficient way of expressing the rights that an `accessSubject` has.

Various examples are described in the table below.

<table data-full-width="true"><thead><tr><th>Description</th><th>Code</th></tr></thead><tbody><tr><td><p>Organisation A delegates rights to organisation B. A allows B READ and CREATE access to all ETA and WEIGHT of A's containers, of which the data is located at service provider C and can only be accessed with service provider C. However, A does not allow B to CREATE to ETA information and completely denies access to data regarding container ID.00000000000001. Furthermore, all rights of B are allowed under the iSHARE license https://licenses.ishare.eu/general/resharing-with-adhering-parties/1.0, and B has the right to delegate its rights two more times.</p><p><br>The code shows default access to a set of resources, with a few exceptions in terms of actions or specific resources. This results in additional "Deny" rules within the policy.</p></td><td><p>Code - for visual/reading purposes Bron uitklappen</p><pre class="language-json"><code class="lang-json">{
    "delegationEvidence": {
        "notBefore": 1509633681,
        "notOnOrAfter": 1509633741,
        "policyIssuer": "did:ishare:EU.NL.NTRNL-10000005",
        "target": {
            "accessSubject": "did:ishare:EU.NL.NTRNL-10000001"
        },
        "policySets": [
            {
                "maxDelegationDepth": 2,
                "target": {
                    "environment": {
                        "licenses": ["https://licenses.ishare.eu/general/resharing-with-adhering-parties/1.0"]
                    }
                },
                "policies": [
                    {
                        "target": {
                            "resource": {
                                "type": "GS1.CONTAINER",
                                "identifiers": ["*"],
                                "attributes": ["GS1.CONTAINER.ATTRIBUTE.ETA", "GS1.CONTAINER.ATTRIBUTE.WEIGHT"]
                            },
                            "actions": ["ISHARE.READ", "ISHARE.CREATE"],
                            "environment": {
                                "serviceProviders": ["did:ishare:EU.NL.NTRNL-10000003"]
                            }
                        },
                        "rules": [
                            {
                                "effect": "Permit"
                            },
                            {
                                "effect": "Deny",
                                "target": {
                                    "resource": {
                                        "attributes": ["GS1.CONTAINER.ATTRIBUTE.ETA"]
                                    },
                                    "actions": ["ISHARE.CREATE"]
                                }
                            },
                            {
                                "effect": "Deny"
                            }
                        ]
                    }
                ]
            }
        ]
    }
}
</code></pre></td></tr><tr><td><p>Organisation A delegates rights to organisation B. A allows B READ access to all ETA of A's containers, of which the data is located at service provider C and can only be accessed with service provider C. A also allows B CREATE access to all WEIGHT of A's containers, at any service provider possible. Furthermore, all rights of B are allowed under the iSHARE license https://licenses.ishare.eu/general/resharing-with-adhering-parties/1.0, and B has the right to delegate its rights two more times.</p><p><br></p><p>The code shows that the same delegation rights and licenses apply to a resource set, but different actions are allowed to different subsets of these resources. This results in variations in policies within the policy sets.</p></td><td><p>Code - for visual/reading purposes Bron uitklappen</p><pre class="language-json"><code class="lang-json">{
    "delegationEvidence": {
        "notBefore": 1509633681,
        "notOnOrAfter": 1509633741,
        "policyIssuer": "did:ishare:EU.NL.NTRNL-10000005",
        "target": {
            "accessSubject": "did:ishare:EU.NL.NTRNL-10000001"
        },
        "policySets": [
            {
                "maxDelegationDepth": 2,
                "target": {
                    "environment": {
                        "licenses": ["https://licenses.ishare.eu/general/resharing-with-adhering-parties/1.0"]
                    }
                },
                "policies": [
                    {
                        "target": {
                            "resource": {
                                "type": "GS1.CONTAINER",
                                "identifiers": ["*"],
                                "attributes": ["GS1.CONTAINER.ATTRIBUTE.ETA"]
                            },
                            "actions": ["ISHARE.READ"],
                            "environment": {
                                "serviceProviders": ["did:ishare:EU.NL.NTRNL-10000003"]
                            }
                        },
                        "rules": [
                            {
                                "effect": "Permit"
                            }
                        ]
                    },
                    {
                        "target": {
                            "resource": {
                                "type": "GS1.CONTAINER",
                                "identifiers": ["*"],
                                "attributes": ["GS1.CONTAINER.ATTRIBUTE.WEIGHT"]
                            },
                            "actions": ["ISHARE.CREATE"]
                        },
                        "rules": [
                            {
                                "effect": "Permit"
                            }
                        ]
                    }
                ]
            }
        ]
    }
}
</code></pre></td></tr><tr><td><p>Organisation A delegates rights to organisation B. A allows B READ and CREATE access to all ETA and WEIGHT of A's containers, of which the data is located at service provider C, and rights can only be used with service provider C. Furthermore, all rights of B are allowed under the iSHARE license https://licenses.ishare.eu/general/resharing-with-adhering-parties/1.0, and B has the right to delegate its rights two more times. A also provides B READ access to the Container origins, but does not allow delegation for this information, and it is only accessible under the iSHARE license <a href="https://licenses.ishare.eu/general-non-commercial-use">https://licenses.ishare.eu/general-non-commercial-use</a>.</p><p>The code shows two groups of resources with specific policies, executed under different licenses and delegation rights. This results in variations on the <code>policySets</code> level within the <code>delegationEvidence</code>.</p></td><td><p>Code - for visual/reading purposes Bron uitklappen</p><pre class="language-json"><code class="lang-json">{
    "delegationEvidence": {
        "notBefore": 1509633681,
        "notOnOrAfter": 1509633741,
        "policyIssuer": "did:ishare:EU.NL.NTRNL-10000005",
        "target": {
            "accessSubject": "did:ishare:EU.NL.NTRNL-10000001"
        },
        "policySets": [
            {
                "maxDelegationDepth": 2,
                "target": {
                    "environment": {
                        "licenses": ["https://licenses.ishare.eu/general/resharing-with-adhering-parties/1.0"]
                    }
                },
                "policies": [
                    {
                        "target": {
                            "resource": {
                                "type": "GS1.CONTAINER",
                                "identifiers": ["*"],
                                "attributes": ["GS1.CONTAINER.ATTRIBUTE.ETA", "GS1.CONTAINER.ATTRIBUTE.WEIGHT"]
                            },
                            "actions": ["ISHARE.READ", "ISHARE.CREATE"],
                            "environment": {
                                "serviceProviders": ["did:ishare:EU.NL.NTRNL-10000003"]
                            }
                        },
                        "rule": {
                            "effect": "Permit"
                        }
                    }
                ]
            },
            {
                "target": {
                    "environment": {
                        "licenses": ["https://licenses.ishare.eu/general-non-commercial-use/1.0"]
                    }
                },
                "policies": [
                    {
                        "target": {
                            "resource": {
                                "type": "GS1.CONTAINER",
                                "identifiers": ["*"],
                                "attributes": ["GS1.CONTAINER.ATTRIBUTE.ORIGIN"]
                            },
                            "actions": ["ISHARE.READ"]
                            },
                        "rule": {
                            "effect": "Permit"
                        }
                    }
                ]
            }
        ]
    }
}
</code></pre></td></tr></tbody></table>


# Data Rights Credential (VC)

This page explains how delegation evidence can be conveyed as a Verifiable Credential (VC), without changing the existing policy model (`policyIssuer`, `accessSubject` , `policySets` , `rules`). The purpose is interoperability with ecosystems using VCs while preserving iSHARE semantics.

#### Main Differences

* **Semantics stay the same**: the delegation evidence JSON (targets, actions, constraints, licenses, validity) and the authorisation decision logic at the Service Provider are unchanged.
* **Envelope and Transport changes**: instead of receiving and sending a signed JWT, parties issue and present a VC (or a Verifiable Presentation). Status lists enable revocation and suspension states that are not available with plain short-lived JWTs.
  * The Authorisation Registry MAY issue the credential (on behalf of the Entitled Party) and MAY act as the Verifiable Data Registry; alternatively, scheme owner/data spaces publish the JSON Schemas.

### Credential Structure

When using VCs, the Authorisation Registry can issue a **DatarightsCredential** that embeds the existing **datarights evidence**. Service Providers verify the credential (including revocation status) and then evaluate the embedded policies as they do today. A **DatarightsCredential** issued by, or on behalf of, the Authorisation Registry carries the current evidence under `credentialSubject.datarightsEvidence`. The VC conforms to VC Data Model 2.0 (JSON-LD or VC-JWT).

```json
{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://schemas.ishare.eu/v3/datarights.json"
  ],
  "id": "http://authorisationregistry.example/credentials/e25d402a-d240-48e7-b749-fb5b01546bfd",
  "type": [
    "VerifiableCredential",
    "DatarightsCredential"
  ],
  "issuer": "did:ishare:EU.NL.NTRNL00000000",
  "validFrom": "2025-05-10T08:00:00Z",
  "credentialSubject": {
    "id": "did:ishare:EU.NL.NLNTR-12345678",
    "alsoKnownAs": [
      "did:elsi:LEIXG-724500AZSGBRY55MNS59",
      "did:key:z6MkhfrsD3GUMjGvRxTTSamE1WnS9w3nDJLeZzT1KZVrU5tE",
      "did:web:example.com",
      "AS.JA.NTA:1234567890123"
    ],
    "datarightsEvidence": {
      "notBefore": 1541058939,
      "notOnOrAfter": 2147483647,
      "policySets": [
        {
          "maxDelegationDepth": 0,
          "target": {
            "environment": {
              "licenses": [
                "https://licenses.ishare.eu/general-unrestricted/1.0"
              ]
            }
          },
          "policies": [
            {
              "target": {
                "resource": {
                  "type": "GS1.CONTAINER",
                  "identifiers": [
                    "180621.ABC1234"
                  ],
                  "attributes": [
                    "GS1.CONTAINER.ATTRIBUTE.ETA"
                  ]
                },
                "actions": [
                  "ISHARE.READ"
                ]
              },
              "rules": [
                {
                  "effect": "Permit",
                  "conditions": {
                    "allOf": [
                      {
                        "leftOperand": "serviceProvider",
                        "operator": "equal",
                        "rightOperand": "did:ishare:EU.NL.NTRNL-10000003"
                      }
                    ]
                  }
                }
              ]
            }
          ]
        }
      ]
    }
  },
  "credentialStatus": {
    "id": "https://authorisationregistry.example/status/2025-05#12345",
    "type": "BitstringStatusListEntry",
    "statusPurpose": "revocation",
    "statusListIndex": "12345",
    "statusListCredential": "https://authorisationregistry.example/status/2025-05"
  }
}
```


# Operational

This section covers the Operational details of the iSHARE Trust Framework.

The Scheme Owner facilitates the correct operation of the Trust Framework and the network through administering several aspects:

* [Operational processes](/detailed-descriptions/operational/operational-processes)
* [Service levels](/detailed-descriptions/operational/service-levels)
* [Communication](/detailed-descriptions/operational/communication)

The Scheme Owner is part of a wider governance framework, which can be found in the [introduction of the Trust Framework](/introduction/governance).

The assumptions underlying the processes and service levels can be found [here](/glossary-and-legal-notices/assumptions).


# Operational processes

This section describes the operational processes necessary to administer the iSHARE Trust Framework (specifications), network and brand.

Per the process described in this section, the goal and responsibilities (per party) are described before a process sequence is included.

The following processes are described:

* [Admission](/detailed-descriptions/operational/operational-processes/admission)
* [Withdrawal or Downgrade](/detailed-descriptions/operational/operational-processes/withdrawal-or-downgrade)
* [Warnings, Suspension and Exclusion](/detailed-descriptions/operational/operational-processes/warnings-suspension-and-exclusion)
* [Incident Management](/detailed-descriptions/operational/operational-processes/incident-management)
* [Change Management](/detailed-descriptions/operational/operational-processes/change-management)
* [Management reporting](/detailed-descriptions/operational/operational-processes/management-reporting)


# Admission

{% hint style="info" %}
*This part of the iSHARE Trust Framework is considered normative and is therefore compliant with RFC 2119.*
{% endhint %}

This admission process describes the steps that all parties MUST take to be admitted to the iSHARE network. For Certified Parties, including Participant Registry, additional steps are required and are described below. The process is the responsibility of, and facilitated by, the Participant Registry (or the Scheme Owner). The process of onboarding and admission can be delegated to a Participant administrator. During rollout, existing JWT flows remain supported; VCs are an additional, optional path for parties that implement them.

**Admission** of prospective iSHARE participants includes:

* A potential Adhering Party wants to start fulfilling one or more [adhering role(s)](/main-aspects-of-the-ishare-trust-framework/framework-and-roles#frameworkandroles-adheringroles) in the network.
* A potential Certified Party wants to start fulfilling one or more [certified roles(s)](/main-aspects-of-the-ishare-trust-framework/framework-and-roles#frameworkandroles-certifiedroles) in the network.
* An already adhering and/or Certified Party wants to expand its current role(s) by one or more roles (s) in the network.

{% hint style="info" %}
This process is for official onboarding to the iSHARE Ecosystem/ network.\
For development and testing, admission to the test network is required. Refer to the Getting Started[ section](https://dev.ishare.eu/introduction/getting-started) for more information.
{% endhint %}

### Goal <a href="#admission-goal" id="admission-goal"></a>

The goal of the admission process is to let prospective participants join the iSHARE Network in a simple and controlled way. A controlled admission process is important to warrant trust in the iSHARE Trust Framework. It provides assurance that all parties signing an accession agreement fulfil the scheme's accession criteria.

### Admission criteria <a href="#admission-admissioncriteria" id="admission-admissioncriteria"></a>

To be admitted to the iSHARE network as a participant, prospective participants MUST comply with several criteria\*:

* Provide a signed [iSHARE accession agreement](/detailed-descriptions/legal#accession-agreement), including [Terms of Use](/detailed-descriptions/legal#terms-of-use);
* Provide a valid [Party Identifier](/detailed-descriptions/functional/functional-requirements-per-role/party-identification).
* Irrespectively, a party identifier compliant with the iSHARE DID method MUST be automatically derived from the identification credential (PKI certificate or signed token);
* Provide an eIDAS Qualified Certificate for advanced or qualified eSeals or onboard using an iSHARE certified Identity Provider where allowed;
* Provide a successful test report of the iSHARE conformance test tool.

\* Data spaces MAY require additional admission criteria (consult Data Space Governing Body).

| Role/Requirement                                                                                                   | Adhering party                                                                                | Certified party      | Participant Registry |
| ------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------- | -------------------- | -------------------- |
| Valid party identifier                                                                                             | X                                                                                             | X                    | X                    |
| Successful test report of [iSHARE conformance test tool](https://dev.ishare.eu/introduction/conformance-test-tool) | X (only for Service providers)                                                                | X                    | X                    |
| Signed [Accession agreement](/detailed-descriptions/legal#legal-documents)                                         | X                                                                                             | X                    | X                    |
| eIDAS Qualified Certificate for advanced or qualified eSeals                                                       | X (only for Service Providers or Service Consumers that use machine to machine communication) | X                    | X                    |
| Register with an iSHARE certified Identity Provider                                                                | X (for Service Consumers or Entitled Parties without Qualified eSeal)                         |                      |                      |
| Onboarded by                                                                                                       | Participant Registry                                                                          | Participant Registry | Scheme Owner         |
| Assessment framework\*                                                                                             | <p><br></p>                                                                                   | X                    | X                    |

The above table shows the Onboarding/ Admission criteria and the Onboarding parties involved.

X = required.

**\* The assessment framework is available below. Data space may apply its own assessment framework for adhering parties and extend the iSHARE Assessment Framework for certified parties**

#### Assessment framework

The following file holds the assessment framework for Certified Parties.

{% file src="/files/DaTKrGIFfp1EeBWcinEr" %}
iSHARE Assessment Framework for Certified Parties
{% endfile %}

### Responsibilities <a href="#admission-responsibilities" id="admission-responsibilities"></a>

Several parties have responsibilities and tasks in the admission process:

* The Participant Registry MUST facilitate the onboarding process while safeguarding the integrity and trust.
* For Participant Registries supporting VCs, they MUST issue compliant VCs to participants requesting onboarding as well as reissuance and revocation of VCs throughout the participant life cycle.
* The Participant Registry MAY delegate its onboarding responsibilities to another party if required; however, it remains responsible and in contact for its participants and the Scheme Owner, as it is the certified party for onboarding.
* **The Scheme Owner MUST onboard/admit the participants playing the role of a Participant Registry. The Scheme Owner MAY admit other participants in the iSHARE network until further notice;**
* The prospective participant MUST implement what is necessary for complying and maintaining compliance with the relevant admission criteria of being a participant in specified role(s).
* Before submitting any claims or registering additional attributes for a participant, the Participant Registry MUST process and verify all mandatory admission and validation requirements as defined by the framework. This ensures that all registered claims are based on verified participant records and compliant admission procedures.

### Sequence <a href="#admission-sequence" id="admission-sequence"></a>

1. An authorised representative of the prospective participant registers with a Participant Registry and provides the Participant Registry with:
   1. Primary contact details: name, role, e-mail;
   2. Description of the intended activities for participating and onboarding in this data space/ecosystem and use of the iSHARE framework;
   3. At least one acceptable, valid legal entity identifier as required by the Participant Registry (nationally or internationally recognised unique identifier which can be verified).
2. The Participant Registry checks whether there are potential impediments that could block the completion of the admission process for the prospective participant:
   1. E.g. previous exclusions from a Data space/iSHARE network in the recent past.
3. The Participant Registry MUST facilitate testing and certification of the prospective participant.
   1. The Participant Registry MAY provide testing material and documentation on the test environment: certificates, keys, SDKs, etc..
   2. For prospective Certified Parties, it MUST include role-specific non-technical requirements.
4. The prospective participant formally requests admission to the particular data space by providing:
   1. An iSHARE accession agreement signed by an authorised representative of the prospective participant;
   2. The eSEAL digital certificate (public key) that will be used (if applicable, see table above);
   3. An iSHARE conformance test tool report.
   4. Any other requirements for admission to the particular data space (such as a signed NDA);
   5. For a prospective Certified Party: The level of assurance for which the prospective Certified Party wants to be certified, accompanied by a filled-in [Assessment Framework](#assessment-framework) (and related evidence) to prove that the operational processes of the prospective Certified Party comply with the indicated level of assurance.
   6. For prospective Certified Parties, additional verification may be required.
      1. The prospective Certified Party can request a signed NDA from the Participant Registry before providing the Assessment Framework and related evidence.
5. The Participant Registry verifies the acceptance of the prospective participant's admission request and its conformance with the admission criteria.
   1. For prospective Adhering Parties, the Participant Registry has 5 working days, unless otherwise stated/agreed, to verify the acceptance of the prospective participant’s admission request and its conformance with the admission criteria;
   2. For prospective Certified Parties, the Participant Registry has 30 days, unless otherwise stated/agreed, to verify the acceptance of the prospective participant's admission request and its conformance with the admission criteria, but aims to respond as soon as possible.
6. The Participant Registry records the participant’s status in the Participant Registry.
7. Once the participant has been accepted, the Participant Registry communicates the verified acceptance to the new Participant, and in the case of Verifiable Credentials issues a ParticipantCredential to the Party.

### Criteria for participation

All participants must be assessed on adherence to the criteria set for participation in this admission process. To accommodate step-by-step onboarding, the following criteria are available.

#### Legal adherence <a href="#admission-legaladherence" id="admission-legaladherence"></a>

* Legal adherence: The Participant has signed the iSHARE Accession Agreement, including the iSHARE Terms of Use.
* No legal adherence: The Participant has not yet signed the necessary agreements.

#### Compliance <a href="#admission-technicalcompliance" id="admission-technicalcompliance"></a>

Compliance includes multiple aspects of participation, such as technical and operational adherence.

* Compliance: Compliance was verified by verifying that all the requirements of onboarding are fulfilled, including the successful test report of the Conformance Test Tool (CTT) for technical compliance.
* No compliance: Compliance has not been verified. Note that this indication will limit the available options for data sharing for this participant.


# Withdrawal or Downgrade

{% hint style="info" %}
*This part of the iSHARE Trust Framework is considered normative and is therefore compliant with RFC 2119.*
{% endhint %}

The withdrawal process describes the steps that parties MUST take to withdraw from a particular data space or the iSHARE network.

**Withdrawal** or downgrade includes:

* A Certified Party or Adhering Party wants to withdraw from the data space/iSHARE network;
* A Certified Party wants to downgrade to an Adhering Party.
* Any other situation in which an Adhering party or Certified Party (un)expectedly withdraws from the data space or iSHARE network (e.g. bankruptcy).

The **term of notice** for withdrawal is 1 month for Adhering Parties, and 6 months for Certified Parties.

### Goal <a href="#withdrawalordowngrade-goal" id="withdrawalordowngrade-goal"></a>

The goal of the withdrawal process is to let parties withdraw from the data space/iSHARE network in a simple and controlled way, minimising impact to the trust and disruption to the functioning of the data space/iSHARE network.

### Responsibilities <a href="#withdrawalordowngrade-responsibilities" id="withdrawalordowngrade-responsibilities"></a>

Several parties have responsibilities and tasks in the withdrawal process:

* The **Data Space Governance Body/Scheme Owner** is responsible for the facilitation of the process, so that the continued operation of the data space and the iSHARE network is not disrupted in any way.
* The **withdrawing/downgrading party** is responsible for delivering a withdrawal plan and for minimising the disruption to the functioning of the data space/iSHARE network. The withdrawing party also benefits from a controlled process itself, as it should help to minimise disruption to internal operations.

### Sequence <a href="#withdrawalordowngrade-sequence" id="withdrawalordowngrade-sequence"></a>

#### Withdrawal of an Adhering Party <a href="#withdrawalordowngrade-withdrawalofanadheringparty" id="withdrawalordowngrade-withdrawalofanadheringparty"></a>

1. The withdrawing party formally indicates its intention to withdraw from the data space to the Data Space Governance Body.
2. The Data Space Governance Body has 5 working days to acknowledge the intention to withdraw of the withdrawing party; the Data Space Governance Body makes the acknowledgement known to the withdrawing party, and provides a date on which the withdrawing party will be considered withdrawn from the data space.
3. The withdrawing party communicates its withdrawal to the parties it interacts (interacted) with in the data space;
4. The withdrawing party, in cooperation with the Data Space Governance Body, withdraws from the data space;
5. In the case of Verifiable Credentials, the Participant Registry updates the status list entry for each affected credential.

#### Withdrawal of or Downgrade of a Certified Party <a href="#withdrawalordowngrade-withdrawalofordowngradeofacertifiedparty" id="withdrawalordowngrade-withdrawalofordowngradeofacertifiedparty"></a>

1. The withdrawing/downgrading party formally indicates its intention to withdraw/downgrade from the data space to the Data Space Governance Body. It includes a withdrawal plan based on the (to be set up) template withdrawal procedure;
2. The Data Space Governance Body has 5 working days to acknowledge the intention to withdraw/downgrade of the withdrawing/downgrading party; the Data Space Governance Body makes the acknowledgement known to the withdrawing/downgrading party, and provides up-to-date guidelines.
3. If necessary, the withdrawing/downgrading party sends an updated withdrawal plan to the Data Space Governance Body, keeping in mind the guidelines provided by the Data Space Governance Body.
4. The Data Space Governance Body accepts the withdrawal/downgrading plan or indicates where it requires changes.
5. The Data Space Governance Body and the withdrawing/downgrading party communicate the intended withdrawal with the data space per date in a dd-mm-yyyy format;
6. The withdrawing/downgrading party, in cooperation with the Data Space Governance Body, withdraws/downgrades from the data space in accordance with the withdrawal plan;
7. The Participant Registry registers and communicates the completed withdrawal to the data space, along with updating the status list entry for each affected credential (In the case of Verifiable Credentials)

#### Withdrawal of or Downgrade of a Participant Registry <a href="#withdrawalordowngrade-withdrawalofordowngradeofasatellite" id="withdrawalordowngrade-withdrawalofordowngradeofasatellite"></a>

1. The withdrawing/downgrading party formally indicates its intention to withdraw/downgrade from the iSHARE network to the Scheme Owner. It includes a withdrawal plan based on the (to be set up) template withdrawal procedure.
2. The Scheme Owner has 5 working days to acknowledge the intention to withdraw/downgrade of the withdrawing/downgrading party; the Scheme Owner makes the acknowledgement known to the withdrawing/downgrading party, and provides up-to-date guidelines.
3. If necessary, the withdrawing/downgrading party sends an updated withdrawal plan to the Scheme Owner, keeping in mind the guidelines provided by the Scheme Owner.
4. The Scheme Owner accepts the withdrawal/downgrading plan or indicates where it requires changes;
5. The withdrawing/downgrading party, in cooperation with the Scheme Owner, withdraws/downgrades from the iSHARE network in accordance with the withdrawal plan;
6. The remaining participants in the data space operated by the withdrawing/downgrading Participant Registry are free to join a different data space, create a new data space or select a new Participant Registry. This is subject to the reason for withdrawal of the Participant Registry. If a security/ compliance breach is reported and the reason for suspension/ withdrawal, the compliance of all members will need to be reevaluated before allowing their participation in the iSHARE network.


# Warnings, Suspension and Exclusion

{% hint style="info" %}
*This part of the iSHARE Trust Framework is considered normative and is therefore compliant with RFC 2119.*
{% endhint %}

The warnings, suspension and exclusion process describes the steps that the Data Space Governance Body/ Scheme Owner MUST take to temporarily suspend or permanently exclude participating parties from the data space/iSHARE Network in case of non-compliance with scheme rules and guidelines, or actions with significant negative impact on the normal operation of the data space/iSHARE Network.

Three classifications of non-compliance are recognised within the iSHARE Trust Framework. Note that the impact or risk described is non-exhaustive.

| Classification          | Impact or risk                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               |
| ----------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Minor non-compliance    | <ul><li>Non-compliance with the iSHARE admission criteria, and/or;</li><li>Non-compliance with the iSHARE service levels, and/or;</li><li>Expired information security certification (e.g. ISO27001, ISAE 3402), and/or;</li><li>Minor data\* security breach, for example, through the loss of a USB stick, laptop, hard disk, or because of hacking attempts or found malware, and/or;</li><li>Fraud or presumption of fraud by, for example, an employee or a hacker.</li></ul>                                                                                           |
| Major non-compliance    | <ul><li>Recurring minor non-compliance, and/or;</li><li>Combinations of minor non-compliance, and/or</li><li>Serious impediment(s) to other Adhering/Certified Party(ies)/Participant Registries, and/or;</li><li>Major data security breach and/or breach that needs to be reported in line with <a href="https://autoriteitpersoonsgegevens.nl/nl/onderwerpen/beveiliging/meldplicht-datalekken">Data leaks reporting(meldplicht datalekken)</a>, and/or;</li><li>(Other) impact on confidentiality and integrity of (data\* within) the iSHARE Trust Framework.</li></ul> |
| Critical non-compliance | <ul><li>Recurring major non-compliance, and/or;</li><li>Network-wide impediment(s) to other parties, and/or;</li><li>(Other) impact on confidentiality and integrity of the iSHARE Trust Framework.</li></ul>                                                                                                                                                                                                                                                                                                                                                                |

\*Data includes the data used for identification, authentication and authorisation purposes in the context of data exchange, but NOT the contents of the actual data exchange.

* **Warnings** are cautionary advice about non-compliance, about what is needed to rectify non-compliance, and by when.
* **Suspension** involves the temporary deactivation of adhering/certified credentials within the iSHARE network.
* **Exclusion** involves permanent deactivation of adhering/certified credentials within the iSHARE network of the excluded party, and involves an iSHARE network-wide notification of exclusion for information purposes.

Before the Data Space Governance Body/ Scheme Owner issues warnings, suspends or even excludes parties, it MUST take into consideration and/or weigh the interests of the iSHARE Trust Framework and the data space/ iSHARE network (i.e. all Adhering/Certified Parties).

### Goal <a href="#warnings-suspensionandexclusion-goal" id="warnings-suspensionandexclusion-goal"></a>

The goal of the warnings, suspension and exclusion process is to warrant trust in the iSHARE Trust Framework, as well as to protect the confidentiality and/or integrity of (data within) the data space/iSHARE network.

### Responsibilities <a href="#warnings-suspensionandexclusion-responsibilities" id="warnings-suspensionandexclusion-responsibilities"></a>

Several parties have responsibilities and tasks in the warnings, suspension and exclusion process:

* The **Steering/Facilitating party** is responsible for the facilitation of the process, to protect the confidentiality and/or integrity of (data within) the data space or iSHARE Network.
* The **Reporting party** can be any party that reports non-compliance.
* The **Non-compliant** **Party** is responsible for acting, at all times but especially after receiving a warning or suspension, in line with the Trust Framework's rules and guidelines.

| **Non-compliant party**    | **Reporting party** | **Steering (facilitating) party** |
| -------------------------- | ------------------- | --------------------------------- |
| Adhering party             | Any                 | Data Space Governance Body        |
| Certified party            | Any                 | Data Space Governance Body        |
| Data Space Governance Body | Any                 | Scheme Owner                      |

### Sequence <a href="#warnings-suspensionandexclusion-sequence" id="warnings-suspensionandexclusion-sequence"></a>

1. The reporting party reports non-compliance to the Steering party, including an estimation of the non-compliance classification.
2. The Steering party assesses the non-compliance and the estimated non-compliance classification by the reporting party, and:
   1. Accepts the non-compliance classification and moves to step 3; or
   2. Changes the non-compliance classification and moves to step 3; or
   3. Rejects the reported behaviour as non-compliance and communicates why to the reporting party.
3. If non-compliance leads to a minor incident, calamity or crisis, the [incident management process](/detailed-descriptions/operational/operational-processes/incident-management) is initiated.
4. The Steering party registers the non-compliance and:
   1. If classified as minor non-compliance, notify the non-complying party of its non-compliance, the reason(s), and the rectifications/adjustments needed within what timespan;
   2. If classified as major non-compliance, it issues the non-complying party an official warning, and communicates its reason(s) and the rectifications/adjustments needed within what timespan.
   3. If classified as critical non-compliance, it suspends the non-complying party, by updating the party's status in the participant registry to 'revoked', until necessary rectifications/adjustments are in place. The Data Space Governance Body communicates this suspension to the data space and the Scheme Owner to the iSHARE network.
5. The non-complying party either:
   1. Rectifies or adjusts within the indicated time span, and informs the Steering party of the rectifications/adjustments; or
   2. Communicates its disagreement with the notification/warning to the Steering party within 5 working days, to which the Steering party MUST reply within 5 working days. The non-complying party is given another 5 working days to respond to the Steering party's latest reply (which can include adjustments to its earlier notification/warning); or
   3. Does not take any action.
6. If sufficient rectifications/adjustments follow in time, step 8 follows. Otherwise, the Steering party:
   1. If classified as minor non-compliance:
      1. Issues the non-complying party a warning, and communicates its reason(s) and the rectifications/adjustments needed within what timespan.
   2. If classified as major non-compliance:
      1. Issues the non-complying party a last warning before suspension, and communicates its reason(s) and the rectifications/adjustments needed within what timespan in order not to be suspended.
   3. If classified as critical non-compliance:
      1. Issues the non-complying party a last warning before exclusion, and communicates its reason(s) and the rectifications/adjustments needed within what timespan in order not to be excluded.
7. If the non-complying party continues to dishonour the (final) warning after a reasonable time, the Steering party:
   1. If classified as minor non-compliance:
      1. Upscales the non-compliance level to major and goes back to step 6b.
   2. If classified as major non-compliance:
      1. Upscales the non-compliance level to critical and goes back to step 4c.
   3. If classified as critical non-compliance:
      1. The Steering party terminates the participation of the non-compliant party by cancellation of the Accession Agreement, resulting in a status change of the Accession Agreement in the participant registry to 'obsolete';
      2. Excludes the non-complying party from the data space/ iSHARE Network, by updating the party's status in the participant registry to 'revoked', and initiates its withdrawal in line (as much as is reasonable) with the [withdrawal process](/detailed-descriptions/operational/operational-processes/withdrawal-or-downgrade);
      3. The Steering party communicates this exclusion to the data space/iSHARE network. The excluded party will not be allowed to take part in the [admission process](/detailed-descriptions/operational/operational-processes/admission) for the next 12 months. Step 7c is followed by step 9.
8. The Steering party considers (new) actions taken by the party adequate, considers the notification or warning honoured and closes the process;
9. The Steering party evaluates the incident with the reporting and/or any other party(ies), and registers the evaluation for future learning.


# Incident Management

{% hint style="info" %}
*This part of the iSHARE Trust Framework is considered normative and is therefore compliant with RFC 2119.*
{% endhint %}

The incident management process describes the steps that the Scheme Owner, Data Space Governance Body, Adhering and Certified Parties MUST take to solve incidents in the iSHARE network.

An **incident** is an event, not part of the standard service operation, that results in a potential impact or risk on the quality, availability, confidentiality and/or integrity of (data within) the *Trust Framework*. This includes the data used for identification, authentication and authorisation purposes in the context of data exchange, but not the contents of the actual data exchange.

Note: Incident resolution is NOT part of regular maintenance, and therefore is NOT subject to maintenance windows as described under [service levels](/detailed-descriptions/operational/service-levels).

Three classifications of incidents are recognised within iSHARE. Note that the impact or risk described is non-exhaustive.

| Classification | Impact or risk                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                 |
| -------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Minor incident | <ul><li>Expected unavailability of < 8 hours of an Adhering Party or < 4 hours of a Certified Party or < 2 hours of the Participant Registry, and/or;</li><li>(Potential) data security breach, for example, through the loss of a USB stick, laptop, hard disk, or because of hacking attempts or found malware, and/or;</li><li>Fraud or presumption of fraud by, for example, an employee or a hacker.</li></ul>                                                                                                                                                                            |
| Calamity       | <ul><li>Direct involvement of three or more Adhering/Certified Parties, and/or;</li><li>Serious impediment(s) to other Adhering/Certified Party(ies), and/or;</li><li>Expected unavailability of > 8 hours of an Adhering Party or > 4 hours of a Certified Party or > 2 hours of the Participant Registry, and/or;</li><li>Data security breach that needs to be reported in line with <a href="https://autoriteitpersoonsgegevens.nl/nl/onderwerpen/beveiliging/meldplicht-datalekken">meldplicht datalekken</a>, and/or;</li><li>(Other) impact on confidentiality and integrity.</li></ul> |
| Crisis         | <ul><li>Involvement of 10 or more Adhering/Certified Parties, and/or;</li><li>Serious impact on image and trustworthiness of iSHARE, and/or;</li><li>Expected unavailability of > 48 hours of a Certified Party or > 12 hours of the Participant Registry, and/or;</li><li>Political implications, and/or;</li><li>Fundamental legal or technical vulnerability.</li></ul>                                                                                                                                                                                                                     |

### Goal <a href="#incidentmanagement-goal" id="incidentmanagement-goal"></a>

The goal of the incident management process is to handle and solve different levels of incidents in a structured way and with minimal disruption to the functioning of the data space/iSHARE network.

### Responsibilities <a href="#incidentmanagement-responsibilities" id="incidentmanagement-responsibilities"></a>

Several parties have responsibilities and tasks in the incident management process:

* The **Steering party** proactively coordinates the handling and solving of incidents, and assists if necessary.
* **All parties** are responsible for reporting all incidents in the data space/iSHARE Network and taking the steps necessary to handle and solve incidents.

| **Non-compliant/Causing party (Incidents pertaining to:)** | **Reporting party** | **Steering (facilitating) party** |
| ---------------------------------------------------------- | ------------------- | --------------------------------- |
| Adhering party                                             | Any                 | Data Space Governance Body        |
| Certified party                                            | Any                 | Data Space Governance Body        |
| Participant Registry                                       | Any                 | Scheme Owner                      |

### Sequence <a href="#incidentmanagement-sequence" id="incidentmanagement-sequence"></a>

Before initiating the process as below, the reporting party, in conjunction with the causing party (if not the same), MUST assess together whether the event deemed an incident is indeed an incident. At any point, the reporting party can approach a legal entity (local or international) for the resolution of the incident. This needs to be informed to the concerned Data Space/ Scheme owner as well.

1. The reporting party reports an incident to the Steering party, including an estimation of the incident classification.
2. The Steering party assesses the incident and the estimated incident classification by the reporting party, and:
   1. Accepts the incident classification and moves to step 3.\
      or
   2. Changes the incident classification and moves to step 3.\
      or
   3. Rejects the reported event as an incident and communicates why to the reporting party.
3. The Steering party registers the incident and initiates incident handling, as follows:
   1. If classified as a **minor** **incident:**
      1. If the minor incident is assessed as the result of non-compliance with rules and guidelines, and/or if it has had a significant negative impact on the normal operation of the data space/iSHARE network, the [warnings, suspension and exclusion process](/detailed-descriptions/operational/operational-processes/warnings-suspension-and-exclusion) will also be initiated;
      2. The Steering party gives the reporting party, the causing party and/or (an)other party(ies) - whichever it deems most capable/suitable - the responsibility of handling the minor incident, under the supervision of the Steering party (see step 4);
      3. The party(s) responsible for handling the minor incident communicate the minor incident, the incident manager, and that the minor incident is being solved, to the parties impacted by it.
   2. If classified as a **calamity**:
      1. If the calamity is assessed as the result of non-compliance with rules and guidelines, and/or if it has had a significant negative impact on the normal operation of the data space, the [warnings, suspension and exclusion process](/detailed-descriptions/operational/operational-processes/warnings-suspension-and-exclusion) will also be initiated;
      2. The Steering party gives the reporting party, the causing party and/or (an)other party(ies) - whichever it deems most capable/suitable - the responsibility of handling the calamity, under the supervision of the Steering party (see step 4);\
         IF there is a data security breach that needs to be reported in line with [Data leaks reporting (meldplicht datalekken)](https://autoriteitpersoonsgegevens.nl/nl/onderwerpen/beveiliging/meldplicht-datalekken) or other relevant regulations, the party(ies) responsible for handling the calamity, report the data security breach to the *Autoriteit Persoonsgegevens* (personal data authority) or other relevant national bodies and follow the authority's guidelines on the rest of the incident management process;
      3. The Steering party informs the data space/iSHARE network of the calamity (and that it is being solved) and who the incident manager is, as well as any parties outside the network that it deems necessary to inform (e.g. branch organisations, the NCSC or even law enforcement);
      4. The Steering party sets up an action plan to minimise risks and damage.
   3. If classified as a **crisis**:
      1. If the crisis is assessed as the result of non-compliance with rules and guidelines, and/or if it has had a significant negative impact on the normal operation of the data space, the [warnings, suspension and exclusion process](/detailed-descriptions/operational/operational-processes/warnings-suspension-and-exclusion) will also be initiated;
      2. The Steering party gives the reporting party, the causing party and/or (an)other party(ies) - whichever it deems most capable/suitable - the responsibility of handling the crisis, under the supervision of and assisted by the Steering party (see step 4). Different to the process for minor incidents and calamities, the Steering party can also choose to take the responsibility of handling the crisis itself, even if it is not the causing party;
         * IF there is a data security breach that needs to be reported in line with [Data leaks reporting (meldplicht datalekken)](https://autoriteitpersoonsgegevens.nl/nl/onderwerpen/beveiliging/meldplicht-datalekken), the party(ies) responsible for handling the calamity report the data security breach to the *Autoriteit Persoonsgegevens* (personal data authority) and follow the authority's guidelines on the rest of the incident management process;
      3. The Steering party informs the data space of the crisis (and that it is being solved) and who the incident manager is, as well as any parties outside the network that it deems necessary to inform (e.g. branch organisations, the NCSC or even law enforcement);
      4. The Steering party sets up an action plan to minimise risks and damage.
4. The Steering party coordinates the contact with the involved parties, monitors progress and assists in handling the incident if necessary. The Steering party also communicates progress to the data space in case of a calamity or crisis. If progress is non-compliant to the incident service level, the Steering party MAY choose to upscale (from incident to calamity or from calamity to crisis);
5. When the incident is handled and therefore solved, the Steering party closes the incident.
   1. In case of a minor incident, the responsible party communicates the incident closure to the parties impacted by it.
   2. In case of a calamity or crisis, the Steering party communicates the incident closure to the data space. The Steering party evaluates the incident with the reporting and/or)other party(ies), and registers the evaluation for future learning. It can choose to share the gained insights with (selected) parties in the data space/iSHARE network.


# Change Management

{% hint style="info" %}
*This part of the iSHARE Trust Framework is considered normative and is therefore compliant with RFC 2119.*
{% endhint %}

The iSHARE Trust Framework is dynamic. The change management process describes the steps that the Scheme Owner MUST take to make changes that impact the Trust Framework or functioning of data spaces operating with the Framework as the standard.

These **changes** include alterations to:

* iSHARE Trust Framework documentation and specifications;
* The Scheme Owner API;
* Scheme Owner tools (e.g. test and certification tools).

### Goal <a href="#changemanagement-goal" id="changemanagement-goal"></a>

The goal of the release management process is to:

* Decide in a standardised, transparent way on what changes are (not) made;
* Release changes in a standardised way, with minimal disruption to the functioning of the iSHARE network.

### Responsibilities <a href="#changemanagement-responsibilities" id="changemanagement-responsibilities"></a>

Several parties have responsibilities and tasks in the release management process:

* The **Scheme Owner** is responsible for the facilitation of a swift course of the process, and for minimising the impact of changes and releases for all participants.
* The **Change Advisory Board** has the responsibility to advise the Scheme Owner on proposed changes.
* **Adhering or Certified Parties** can (cooperatively) prepare and submit a [Request for Change (RFC)](https://gitlab.com/ishare-foundation/cab/rfc) to the Scheme Owner.

### Sequence <a href="#changemanagement-sequence" id="changemanagement-sequence"></a>

The following sequence is based on [ITIL v3](https://wiki.en.it-processmaps.com/index.php/Change_Management).

1. One or several submitting parties (this can also include the Scheme Owner) submit an RFC which describes at a minimum:
   1. A description of the desired change;
   2. A description of the context/immediate cause;
   3. An indication of what priority the change should have.
   4. The potential solution (direction);
   5. The impact on Certified and/or Adhering Parties and the Scheme Owner;
   6. The justification of the change in a business case.
2. The RFC is logged by the Scheme Owner.
3. The Scheme Owner assesses the feasibility and impact of the submitted RFC and:
   1. Schedules the proposed RFC for review by the Change Advisory Board. He communicates this to the submitting party(ies);
   2. Does NOT schedule the proposed RFC for review by the Change Advisory Board. He issues a written statement to the submitting party(ies) explaining why;
4. The Change Advisory Board assesses the RFC and provides the Scheme Owner with advice on how to proceed.
5. Based on the CAB advice, a draft solution and the estimated impact, the Scheme Owner either:
   1. Accepts the RFC and prioritises the change; or
   2. Rejects the RFC;
6. The Scheme Owner issues a written statement to the CAB and the submitting party(ies), explaining the reasoning behind the acceptance/rejection of an RFC and the change's priority;
7. If relevant, the Scheme Owner updates the release calendar and the priority of upcoming changes.
8. The Scheme Owner alters the iSHARE Scheme based on the release calendar and publishes a new version of the scheme accordingly.

**Emergency changes** are changes that MUST be implemented as soon as possible, for example, to resolve a major or critical incident. In case of an emergency change the Scheme Owner accelerates the execution of the process. They can choose to consult (members of) the CAB on an ad-hoc basis if timing permits and deemed necessary.

If a change does NOT impact the legal or technical scheme agreements, the change MAY be made without taking the steps described here. Such changes include (but are not limited to) the restructuring of content, correcting grammatical mistakes, and maintenance of hyperlinks and labels.

### Versioning guidelines <a href="#changemanagement-versioningguidelines" id="changemanagement-versioningguidelines"></a>

Each version of the iSHARE Trust Framework has a unique identifier that conveys the significance of changes between releases, whereby the first sequence is changed for the most significant changes, and changes to sequences after the first digit represent changes of decreasing significance. iSHARE uses a sequence of three digits for its versioning (x.y.z):

1. MAJOR version for significant and/ or backwards-incompatible changes (v1.0 to v2.0)
2. MINOR version for regular changes and/ or new functionality (v1.5 to v1.6)
3. PATCH version for small fixes (v1.7 to v1.7.1)

The Scheme Owner may choose to jump multiple minor versions at a time (v1.2 to v1.5) to indicate significant changes have been made, but are not enough to warrant incrementing a major version number.


# Management reporting

{% hint style="info" %}
*This part of the iSHARE Trust Framework is considered normative and is therefore compliant with RFC 2119.*
{% endhint %}

The management reporting process describes the steps that parties MUST take to deliver management information about the use and working of the iSHARE network.

### Goal <a href="#managementreporting-goal" id="managementreporting-goal"></a>

The goal of the management reporting process is to monitor compliance with service level agreements and to distribute info about the use of the iSHARE network.

### Responsibilities <a href="#managementreporting-responsibilities" id="managementreporting-responsibilities"></a>

Several parties have responsibilities and tasks in the management reporting process:

* The **Scheme Owner** is responsible for delivering its own management information quarterly, and for processing received management information into a report that does not include commercially sensitive information.
* The **Data Space Governance Body** is responsible for delivering management information to the Scheme Owner.
* The **Certified Party** is responsible for delivering management information timely on a monthly basis, to the Data Space Governance Body for their data space.

### Sequence <a href="#managementreporting-sequence" id="managementreporting-sequence"></a>

1. Every month, Certified Parties and the Data Space Governance Body collect management information about:
   1. the use of the data space;
   2. compliance with the service level agreements.
2. Certified Parties and Data Space Governance Body deliver the collected management information to the Scheme Owner in compliance with the standard format and service level.
3. The Scheme Owner processes the received management information on compliance, and, if non-compliance is detected, follows the [warnings, suspension and exclusion process ](/detailed-descriptions/operational/operational-processes/warnings-suspension-and-exclusion)to assess whether this is an incident or structural non-compliance;
4. The Scheme Owner verifies whether each party's management information on the use of the *Trust Framework* is correct:
   1. If correct, step 5 follows directly.
   2. If incorrect, a maximum of 5 working days is available for the party to rectify. If 5 working days are not enough, step 5 follows without the incorrect information.
5. Quarterly, the Scheme Owner processes and anonymises (if necessary) the management information on the use of the *Trust Framework* into a report containing:
   1. Number of Certified Parties (also compared to last month and this month, previous years);
   2. Number of Adhering Parties;
   3. Other information deemed necessary (to be decided); If incorrect information was found and could not be rectified within 5 days in step 4, a description of the missing management information.
6. The Scheme Owner distributes the management report.


# Service levels

This section describes the minimum service levels that apply to iSHARE Adhering Parties and Certified Parties.

{% hint style="info" %}
**The iSHARE Framework defines minimum service levels to improve interoperability**

To improve interoperability between data spaces that are based on the iSHARE Framework, the service levels in this section must be seen as *minimum* service levels. Data Space Governance Bodies may require higher service levels from there participants within their specific data space(s) than defined in this section.
{% endhint %}

A **service level** measures the performance of a service. Per the service level described in this section, an explanation of the service level is given before both the norm and the minimum level are defined.

The following service levels are described per party. Please click on the 'X' in each column to be redirected to the specific service level description.

| <p><br></p>       | [**Adhering Parties**](/detailed-descriptions/operational/service-levels/service-levels-for-adhering-parties) (Providing [System Services](/glossary-and-legal-notices/glossary#system-services)) | [**Adhering Parties**](/detailed-descriptions/operational/service-levels/service-levels-for-adhering-parties)(Not Providing System Services)\*\* | [**Certified Parties/Satellites**](/detailed-descriptions/operational/service-levels/service-levels-for-certified-parties-satellite)                          |
| ----------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Service level** | <p><br></p>                                                                                                                                                                                       |                                                                                                                                                  |                                                                                                                                                               |
| Availability      | [X](/detailed-descriptions/operational/service-levels/service-levels-for-adhering-parties#servicelevelsforadheringparties-availability)                                                           |                                                                                                                                                  | [X](/detailed-descriptions/operational/service-levels/service-levels-for-certified-parties-satellite#servicelevelsforcertifiedparties-satellite-availability) |
| Performance       | [X](/detailed-descriptions/operational/service-levels/service-levels-for-adhering-parties#servicelevelsforadheringparties-performance)                                                            |                                                                                                                                                  | [X](/detailed-descriptions/operational/service-levels/service-levels-for-certified-parties-satellite#servicelevelsforcertifiedparties-satellite-performance)  |
| Incidents         | [X](/detailed-descriptions/operational/service-levels/service-levels-for-adhering-parties#servicelevelsforadheringparties-incidents)                                                              | [X](/detailed-descriptions/operational/service-levels/service-levels-for-adhering-parties#servicelevelsforadheringparties-incidents)             | [X](/detailed-descriptions/operational/service-levels/service-levels-for-certified-parties-satellite#servicelevelsforcertifiedparties-satellite-incidents)    |
| Support           | [X](/detailed-descriptions/operational/service-levels/service-levels-for-adhering-parties#servicelevelsforadheringparties-support)                                                                | [X](/detailed-descriptions/operational/service-levels/service-levels-for-adhering-parties#servicelevelsforadheringparties-support)               | [X](/detailed-descriptions/operational/service-levels/service-levels-for-certified-parties-satellite#servicelevelsforcertifiedparties-satellite-support)      |
| Reporting         | <p><br></p>                                                                                                                                                                                       |                                                                                                                                                  | [X](/detailed-descriptions/operational/service-levels/service-levels-for-certified-parties-satellite#servicelevelsforcertifiedparties-satellite-reporting)    |

{% hint style="info" %}
\*\* In the context of this Framework, the service levels for Availability and Performance mainly apply to system service providers, irrespective of their role.

Adhering parties like Service Consumers and Entitled Parties do not provide System Services (which are catered through the use of systems) and thereby may be exempt from the service levels of Availability and Performance.
{% endhint %}

The service levels are monitored via the [Management Reporting process](/detailed-descriptions/operational/operational-processes/management-reporting).

**No norm** is set for monitoring frequency or detail.


# Service levels for Adhering Parties

{% hint style="info" %}
*This part of the iSHARE Trust Framework is considered normative and is therefore compliant with RFC 2119.*
{% endhint %}

For Adhering Parties that provide system services, the following service levels apply

* [Availability](#servicelevelsforadheringparties-availability)
* [Performance](#servicelevelsforadheringparties-performance)
* [Incidents](#servicelevelsforadheringparties-incidents)
* [Support](#servicelevelsforadheringparties-support)

For Adhering Parties that do not provide system services, only the following service levels apply:

* [Incidents](#servicelevelsforadheringparties-incidents)
* [Support](#servicelevelsforadheringparties-support)

{% hint style="info" %}
In the context of this Framework, the service levels for Availability and Performance mainly apply to [system service providers](/glossary-and-legal-notices/glossary#system-services), irrespective of their role.

Adhering parties like Service Consumers and Entitled Parties do not provide System Services (which are catered through the use of systems) and thereby may be exempt from the service levels of Availability and Performance.

Incidents and Support service levels are still applicable.
{% endhint %}

## Availability <a href="#servicelevelsforadheringparties-availability" id="servicelevelsforadheringparties-availability"></a>

**Availability** is a measure of the time a service is in a functioning condition. It includes the availability window and the maintenance window.

#### Availability window <a href="#servicelevelsforadheringparties-availabilitywindow" id="servicelevelsforadheringparties-availabilitywindow"></a>

The **availability window** includes the times at which Adhering Parties guarantee the availability of their service.

**No norm** is set for Adhering Parties' availability window, to leave Service Providers free to run their service whenever they deem appropriate (e.g. a trucking company does not need to leave its trucks' board computers on 24 hours \* all days of the year).

**Minimum level required** at times deemed appropriate to run service\*\*:\*\* guideline of 95% availability\* per calendar month, from 00:00-23:59h

\*Planned maintenance does NOT count as unavailability

#### Maintenance window <a href="#servicelevelsforadheringparties-maintenancewindow" id="servicelevelsforadheringparties-maintenancewindow"></a>

The **maintenance window** includes the times at which Adhering Parties can perform planned maintenance, that is likely to result in downtime, to their service. If no downtime is expected, maintenance can take place outside of the maintenance window. Planned maintenance does NOT include incident resolution, as this can take place outside the maintenance window as described under [incidents](#servicelevelsforadheringparties-incidents).

**Norm:**

* The maintenance window includes all times outside office hours.
* **No norm** is set for communication about (different forms of) maintenance, as this is a matter between Adhering Parties.

## Performance <a href="#servicelevelsforadheringparties-performance" id="servicelevelsforadheringparties-performance"></a>

**Performance** includes the time it takes for a service to respond when requested or called upon; i.e. the time an Adhering Party's service takes to respond to a received message.

Before an Adhering Party knows whether it may respond to a request, however, it often needs to request (more) information from one or more certified parties; e.g. delegation info or authorisation info. It therefore needs to send out a new message itself, and wait for this message to be responded to by a certified party. While Certified Parties' response times are short, the process of sending out and receiving (sometimes several) new messages before the original request can be answered takes time. Consequently, **no norm** is set for Adhering Parties' total performance. The following **guidelines** are set:

* 95% of Adhering Parties' messages SHOULD be responded to within 2 seconds of receiving all information needed from certified parties;
* 99% of Adhering Parties' messages SHOULD be responded to within 5 seconds of receiving all information needed from certified parties;
* Each Adhering Party SHOULD be able to process at least 100 simultaneous messages while meeting the above requirements.

## Incidents <a href="#servicelevelsforadheringparties-incidents" id="servicelevelsforadheringparties-incidents"></a>

An **incident** is an event, not part of the standard service operation, that results in a potential impact or risk on the quality, availability, confidentiality and/or integrity of (data within) the iSHARE Trust Framework. This ONLY includes the data used for identification, authentication and authorisation purposes in the context of data exchange, but not the contents of the actual data exchange.

Three classifications of incidents are recognised within iSHARE, as explained in the [incident management process](/detailed-descriptions/operational/operational-processes/incident-management):

* Minor incident;
* Calamity;
* Crisis.

**Norm:**

* All incidents MUST be communicated by the Adhering Party(s)to the Scheme Owner directly after they are discovered;
* Communication MUST include date, time, incident level as estimated by the Adhering Party(s), argumentation including impacted service(s), and a potential incident manager;
* In case of a calamity or crisis, the Adhering Party MUST have an incident manager available during working days, and SHOULD have an incident manager available 24 \* 7;
* An update on the incident MUST be communicated to the Scheme Owner\*:
  * For minor incidents, at the end of each working day;
  * For calamities, within 2 hours of every significant update and at the end of each working day.
  * For crises, within 2 hours of every significant update and every 4 hours.
* All incidents SHOULD be handled by the Adhering Party (in cooperation with the Scheme Owner as per the [incident management process](/detailed-descriptions/operational/operational-processes/incident-management)) within 3 working days after being appointed as the responsible party - unless agreed otherwise.

\*In line with the [incident management process](/detailed-descriptions/operational/operational-processes/incident-management), the Scheme Owner presents an overview of current calamities and crises on its website

## Support <a href="#servicelevelsforadheringparties-support" id="servicelevelsforadheringparties-support"></a>

**Support** by Adhering Parties could include answering questions, requests, and complaints from other Adhering Parties.

**No norm** is set for Adhering Parties as it is a matter between them (and other Adhering Parties). The following **guidelines** are set, however:

* Adhering Parties are available for support via e-mail.
* They SHOULD confirm receiving a question/request within 1 working day. They SHOULD send an underpinned reaction (with an answer/solution or, at the very least, a direction) within 5 working days.


# Service levels for Certified Parties

{% hint style="info" %}
*This part of the iSHARE Trust Framework is considered normative and is therefore compliant with RFC 2119.*
{% endhint %}

For Certified Parties, the following service levels apply:

* [Availability](#servicelevelsforcertifiedparties-satellite-availability)
* [Performance](#servicelevelsforcertifiedparties-satellite-performance)
* [Incidents](#servicelevelsforcertifiedparties-satellite-incidents)
* [Support](#servicelevelsforcertifiedparties-satellite-support)
* [Reporting](#servicelevelsforcertifiedparties-satellite-reporting)

## Availability <a href="#servicelevelsforcertifiedparties-satellite-availability" id="servicelevelsforcertifiedparties-satellite-availability"></a>

**Availability** is a measure of the time a service is in a functioning condition. It includes the availability window and the maintenance window.

#### Availability window <a href="#servicelevelsforcertifiedparties-satellite-availabilitywindow" id="servicelevelsforcertifiedparties-satellite-availabilitywindow"></a>

The **availability window** includes the times at which the Certified Party guarantees the availability of their service.

**Norm:** 24 hours \* all days of the year

**Minimum level required:** 99% availability\* per calendar month, from 00:00-23:59h

\*Planned maintenance does NOT count as unavailability

#### Maintenance window <a href="#servicelevelsforcertifiedparties-satellite-maintenancewindow" id="servicelevelsforcertifiedparties-satellite-maintenancewindow"></a>

The **maintenance window** includes the times at which the Certified Party can perform planned maintenance, which is likely to result in downtime, to their service(s). If no downtime is expected, maintenance can take place outside of the maintenance window. Planned maintenance does NOT include incident resolution, as this can take place outside the maintenance window as described under [incidents](#servicelevelsforcertifiedparties-satellite-incidents).

**Norm:**

* The maintenance window includes the nights from Friday to Saturday and from Saturday to Sunday, from 00:00-5.59h.
* Maintenance MUST be announced to the impacted parties directly as well as to the Data Space Governance Body/Scheme Owner\*\*;
* Announcements MUST be made at least 10 working days before the maintenance and MUST include the date, time, and impacted service(s).

\*\*The Scheme Owner/Data Space Governance Body presents an overview of its Certified Parties' current and planned maintenance on its website.

## Performance <a href="#servicelevelsforcertifiedparties-satellite-performance" id="servicelevelsforcertifiedparties-satellite-performance"></a>

**Performance** includes the time it takes for a service to respond when requested or called upon; i.e. the time a Certified Party's service takes to respond to a received message.

**Norm:**

* 95% of Certified Parties' messages MUST be responded to within 2 seconds;
* 99% of Certified Parties' messages MUST be responded to within 5 seconds;
* Each Certified Party MUST be able to process at least 100 simultaneous messages while meeting the above requirements.

## Incidents <a href="#servicelevelsforcertifiedparties-satellite-incidents" id="servicelevelsforcertifiedparties-satellite-incidents"></a>

An **incident** is an event, not part of the standard service operation, that results in a potential impact or risk concerning the quality, availability, confidentiality and/or integrity of (data within) the iSHARE Trust Framework. This ONLY includes the data used for identification, authentication and authorisation purposes in the context of data exchange, but not the contents of the actual data exchange.

Three classifications of incidents are recognised within iSHARE, as explained in the [incident management process](/detailed-descriptions/operational/operational-processes/incident-management):

* Minor incident;
* Calamity;
* Crisis.

**Norm:**

* All incidents MUST be communicated by the Certified Party(ies) to the Scheme Owner/Data Space Governance Body directly after they are discovered;
* Communication MUST include date, time, incident level as estimated by the Certified Party(ies), argumentation including impacted service(s), and a potential incident manager;
* In case of a calamity or crisis, the Certified Party MUST have an incident manager available during working days, and SHOULD have an incident manager available 24 \* 7.
* An update on the incident MUST be communicated to the Data Space Governance Body/Scheme Owner\*:
  * For minor incidents, at the end of each working day;
  * For calamities, within 2 hours of every significant update and at the end of each working day.
  * For crises, within 2 hours of every significant update and every 4 hours.
* All incidents SHOULD be handled by the Certified Party (in cooperation with the Scheme Owner/Data Space Governance Body as per the [incident management process](/detailed-descriptions/operational/operational-processes/incident-management)) within 3 working days after being appointed as the responsible party - unless agreed otherwise.

\*In line with the [incident management process](/detailed-descriptions/operational/operational-processes/incident-management), the Scheme Owner/Data Space Governance Body presents an overview of current calamities and crises on its website

## Support <a href="#servicelevelsforcertifiedparties-satellite-support" id="servicelevelsforcertifiedparties-satellite-support"></a>

**Support** by Certified Party includes answering questions and requests from Adhering Parties.

**Norm:** Certified Parties are available for support via e-mail; they MUST confirm receiving a question/request within 1 working day. They SHOULD send an underpinned reaction (with an answer/solution or, at the very least, a direction) within 5 working days.

## Reporting <a href="#servicelevelsforcertifiedparties-satellite-reporting" id="servicelevelsforcertifiedparties-satellite-reporting"></a>

**Reports** are meant to monitor both compliance with the service level agreements and the (growing) use of the iSHARE network, as described in the [management reporting process](/detailed-descriptions/operational/operational-processes/management-reporting). The following will be reported on (non-exhaustive):

|                                           | Certified party | Participant Registry                                                                         |
| ----------------------------------------- | --------------- | -------------------------------------------------------------------------------------------- |
| Availability                              | Yes             | Yes                                                                                          |
| Number of relations with Adhering Parties | Yes             | Only if operating standalone Participant Registry (disconnected from the distributed ledger) |
| Number of transactions                    | Yes             | No                                                                                           |
| Number of transactions per Adhering Party | Yes             | No                                                                                           |
| Number of incidents.                      | Yes             | Yes                                                                                          |

All Certified Parties are expected to collect management information for each month: 0:00h on the first day to 23:59h on the last.

**Norm:** All Certified Parties MUST deliver the management information about the last month, conform to the iSHARE template, before 23:59h on the 5th working day of the current month.


# Communication

{% hint style="info" %}
*This part of the iSHARE Trust Framework is considered normative and is therefore compliant with RFC 2119.*
{% endhint %}

This section describes the agreements concerning communication about and with the iSHARE brand that are applicable to all Data Space Governance Bodies, Adhering and Certified Parties.

It includes the guidelines for using iSHARE's name, brand, and iSHARE logo.

### Usage of the iSHARE name and brand <a href="#communication-usageofisharenameandbrand" id="communication-usageofisharenameandbrand"></a>

The following communication rules apply when using the iSHARE name and brand:

* All participating parties MUST use the visuals and logos as provided by the iSHARE Style Guide and MUST apply the notation and terminology as described in the Glossary. This creates clarity in the communication and brand image of iSHARE.
* The term iSHARE is used as a brand for machine-to-machine and human-to-machine iSHARE services.
* Participating parties within the iSHARE network MAY use the phrase ‘powered by iSHARE’ to support their own branding;
* If iSHARE is integrated in human-to-machine software, the iSHARE logo SHOULD be used in user interfaces;
* Data Space Governance Bodies, Adhering- and Certified Parties COULD use standard texts, key messages and other textual and visual elements as provided in the communication toolkit provided by the Scheme Owner.

### Usage of the iSHARE logo <a href="#communication-usageofisharelogo" id="communication-usageofisharelogo"></a>

The following basic principles apply to the use of the iSHARE logo:

* Please use enough white space around the logo.
* Do not alter the colouring of the logo (or use the black and white logo).

iSHARE logo material can be downloaded [here](https://dev.ishare.eu/ui-guidelines/sign-in.html).


# Legal

The iSHARE Trust Framework is underpinned by legal agreements to which all participants (both Adhering Parties and Certified Parties) need to adhere. This section contains the relevant legal aspects of the Framework:

| Title                                     | Agreement with version                                                    |
| ----------------------------------------- | ------------------------------------------------------------------------- |
| Terms of Use                              | [Terms-Of-Use](#terms-of-use-1) (05-03-2025)                              |
| Accession Agreement for Adhering Parties  | [Adhering-Parties-Accession-Agreement](#adhering-parties) (05-03-2025)    |
| Accession Agreement for Certified Parties | [Certified-Parties-Accession-Agreement](#certifying-parties) (05-03-2025) |

### Legal Context

This section clarifies which rules and regulations may apply to Framework's participants, and provides information and formats that participants can use to improve their understanding. This section does not aim to be all-encompassing in the sense that it covers all the rules and regulations applicable to the participants; it aims to provide useful information to the Trust Framework's participants. Please note that, depending on an organisation's context and specific focus, different rules and regulations might apply, both stemming from national and international law, which might not be mentioned in this section.

### Terms of Use

The Terms of Use are an appendix to and integral part of the Accession Agreement. The Terms of Use further define the rights and obligations of the various roles within the iSHARE Trust Framework. The Terms of Use provide a uniform set of rules for both the participants and the Scheme Owner, thereby fostering a level playing field between all parties involved.

The Terms of Use are drafted in such a way that data can be exchanged by participants even if they have no other contractual arrangement in place. In that case, the default requirements as outlined in the Terms of Use govern their legal relationship. This includes the (license) conditions that apply to the exchange of data. But the Terms of Use leave room for participants to derogate from or further detail the provisions of the Terms of Use on a bilateral basis. However, there will be certain requirements that participants should comply with at any time, and with which they will not be able to deviate. These are the requirements that deal with the proper functioning of the iSHARE Trust Framework, such as each party's responsibility to safeguard the security of its IT systems (articles 3.5 and 4.1).

#### Furthermore, the Terms of Use include several annexes, amongst which are the pre-defined conditions of exchange, the iSHARE Trust Framework and the standards and specifications. <a href="#terms-of-use" id="terms-of-use"></a>

{% file src="/files/1Y8AMcw7PiuE6PDKBNNt" %}
Terms of Use
{% endfile %}

### Accession Agreement

#### **Adhering Parties**

The main contract between the participant and the iSHARE Scheme Owner. This main contract refers to the terms of use, including all specifications, to which all participants must abide. After signing this Accession Agreement, an organisation becomes a participant of the data space/iSHARE network as an Adhering Party.

{% file src="/files/HJfwHnfVwPZdL8CGZZZc" %}
Accession Agreement for Adhering Parties
{% endfile %}

#### **Certified Parties**

The main contract between the participant and the iSHARE Scheme Owner. This main contract refers to the terms of use, including all specifications, to which all participants must abide. After signing this Accession Agreement, an organisation becomes a participant of the data space/iSHARE network as a Certified Party.

{% file src="/files/jnh5Xz9ShJ1rCU1RsTSi" %}
Accession Agreement for Certified Parties
{% endfile %}

***

### Previous Versions for Agreements

#### Adhering Parties *(*&#x76;ersion 13-02-2023)

{% file src="/files/GxUvhvW4QmfQVKCjgu2I" %}

#### Certified Parties *(*&#x76;ersion 13-02-2023)

{% file src="/files/7EaiZzZIhFzIFzN6FZAf" %}

#### Adhering Parties (version 18-09-2020)

#### Certified Parties (version 18-09-2020)


# Legal context

The Legal Context describes the laws and regulations that are of particular importance for participants when exchanging data within the context of the iSHARE Framework: the eIDAS regulation, the General Data Protection Regulation, competition law and the Dutch civil code. As stipulated in the Accession Agreement and the Terms of Use, all participants are expected to comply with these and all other applicable national and international pieces of legislation.

### Relevant rules, regulations and templates <a href="#legalcontext-relevantrules-regulationsandtemplates" id="legalcontext-relevantrules-regulationsandtemplates"></a>

* [Dutch Civil Code](/detailed-descriptions/legal/legal-context/dutch-civil-code)
* [Regulation on Electronic Identification and Trust Services (eIDAS)](/detailed-descriptions/legal/legal-context/regulation-on-electronic-identification-and-trust-services-eidas)
* [Applicable competition law](/detailed-descriptions/legal/legal-context/applicable-competition-law)
* [General Data Protection Regulation (GDPR)](/detailed-descriptions/legal/legal-context/general-data-protection-regulation-gdpr)


# Dutch Civil Code

In setting up the iSHARE Trust Framework, the relevant provisions of the Dutch Civil Code need to be taken into account. This primarily relates to the Accession Agreements and the Terms of Use, which need to be drafted in accordance with Dutch contract law. With the expansion of the iSHARE Trust Framework, other national and international laws may become relevant as well. Any specific (national and international) rules, for example, the transport and logistics sector, such as rules for agreements on the carriage of goods, fall outside the scope of this legal framework. These types of sector-specific rules are not relevant for operating and using the iSHARE Trust Framework, although participants may need to adhere to them when contracting services through the Framework.


# Regulation on Electronic Identification and Trust Services (eIDAS)

The eIDAS Regulation – formally the Regulation on electronic identification and trust services for electronic transactions in the internal market – was adopted on 23 July 2014. It aims to provide a predictable regulatory environment to enable secure and seamless electronic interactions between businesses, citizens and public authorities throughout the entire EU. It ensures that people and businesses can use their own eIDs to access public services in other EU countries and enhances cross-border interoperability of electronic trust services.

The first section of the eIDAS Regulation relates to the government-recognised eIDs and establishes a legal framework that will allow all EU countries to recognise each other’s eIDs. The second section of eIDAS deals with the various electronic signatures (i.e. simple, advanced and qualified). It clarifies existing rules, but also introduces a new legal framework for electronic signatures, seals and timestamps. The new legal framework is not mandatory but introduces certain requirements that can be followed in order to grant greater legal certainty and to improve the reliability of these services.

For the iSHARE Trust Framework, the governing body will determine which eID providers are to be used, which trust service providers are to be engaged and the roles these trust service providers have within the iSHARE Trust Framework. The selection of eID and trust service providers is also relevant for the international orientation of the iSHARE Trust Framework and to foster the cross-border interoperability of electronic trust services.


# Applicable competition law

### Agreements <a href="#applicablecompetitionlaw-agreements" id="applicablecompetitionlaw-agreements"></a>

Depending on whether an agreement or other behaviour has an effect in the entire EU or not, EU competition law or national competition law (and enforcement) applies. Competition law prohibits agreements that restrict competition, unless there is a justification for them.

There are different types of agreements with different rules. The rules for agreements between companies at the same level of the production chain are generally stricter than those for companies at different levels of the production chain. The iSHARE Trust Framework facilitates both horizontal and vertical exchanges of information.

What is problematic under competition law is the exchange of information that is sensitive to competition, such as price lists, data on turnover, etc. Restrictive effects may, for instance, be found in cases where exchanges of information enable companies to be better aware of each other’s market strategies. Agreements that have as their purpose or effect the restriction of competition (such as price fixing, market sharing) are very likely to be prohibited. On the other hand, a justification for exchanging information can be found if this leads to efficiency gains. To determine whether there are indeed efficiency gains, three conditions must be taken into account:

1. The efficiency must at least be partially passed on to the consumers who are affected by the restriction (e.g. quicker delivery of products or reduction of search costs).
2. The agreement must not restrict competition more than is necessary for the attainment of the efficiency gains (proportionality requirement).
3. The restriction of competition must not result in the total elimination of competition. As a result, competition law leaves room for such agreements.

The iSHARE Trust Framework could lead to efficiencies (e.g. in terms of costs or by removing barriers).

It is important to carefully draft the agreements and always assess whether they could restrict competition, and whether a restriction could be justified by, for example, efficiencies. Admittedly, it is mainly up to the participants sharing data to comply with competition law, but the iSHARE Trust Framework itself is not designed in a way to directly or indirectly hurt competition. In all cases, an important principle of the iSHARE Trust Framework is to create a level playing field.

### Dominant position <a href="#applicablecompetitionlaw-dominantposition" id="applicablecompetitionlaw-dominantposition"></a>

Competition law also deals with the abuse of a dominant position. Companies can also have a dominant position collectively. Whether there is a dominant position is assessed based on market shares, amongst other factors. When there is a (collective) dominant position, it is important to assess whether, for example, parties not participating in data spaces/iSHARE network are excluded from the market via abuse of dominance. A dominant position is not in itself anti-competitive. Only when that position is exploited to eliminate competition is it considered an abuse. Examples of practices that can (but do not necessarily have to) lead to abuse of dominance are exclusive dealing agreements, a refusal to supply, and certain pricing practices.

The iSHARE Trust Framework is intended to be an open framework, accessible to any party – admitted to the iSHARE Trust Framework or not - seeking to use its functionalities.


# General Data Protection Regulation (GDPR)

On the 25th of May 2018, the Dutch privacy law (*Wet bescherming persoonsgegevens*) was overhauled by a European privacy regulation, the ‘General Data Protection Regulation’ (GDPR). This regulation will ensure that the same privacy rules apply throughout the entire EU and will entail substantial changes for businesses and industry.

Two of those changes are the requirements of ‘privacy by design’ and ‘privacy by default’. Broadly speaking, this means that privacy must be taken into account throughout the entire process in which products and services are developed. This can be achieved by using techniques such as pseudonymisation and by processing as little personal data as possible, i.e. by processing only the necessary personal data. This requirement of necessity also applies to the accessibility of data (i.e. who has access to which data) and the period for which data are retained. The default settings of a product or service must also be as privacy-friendly as possible. Products and services will therefore have to be developed and designed in such a way as to ensure that they are ‘privacy proof’.

Personal data must be protected adequately, via technical and organisational measures. For example: passwords, encryption, secure (SSL/TLS) network connections and pseudonymisation of data. Technical norms such as the ISO 27001 are not mandatory, but in practice, they are the best way to make sure a service provider uses adequate protection. Service providers who are able to provide a statement from an independent auditor offer even more security. The most well-known statements are the ISAE 3402 and the SSAE No. 16. When you exchange data within the iSHARE Trust Framework and you adhere to the iSHARE technical specifications, this means that you comply with GDPR with respect to the *technical* security measures required for the exchange of personal data.

Although the majority of data shared via the iSHARE Trust Framework may not be personal data, there could be personal data involved. For example, data relating to employees or clients of participating parties. If personal data is shared via the iSHARE Trust Framework, the participating parties will need to have a legal basis to do so. A legal basis can be, for example, consent of the data subjects, or an agreement to which the data subject is a party.

When data is exchanged between two data controllers, both need a legal basis for this. A data exchange agreement also needs to be concluded. When a data processor processes personal data on behalf of the controller, they are obliged to enter into a data processing agreement. The GDPR explains what such an agreement should contain.

Within the iSHARE Trust Framework, the participating parties are in control with respect to the types and amount of data they like to share and, in this respect, should also easily facilitate the conclusion of data processing or data sharing agreements. To facilitate participants in their GDPR compliance efforts between themselves, two contract templates can be used: depending on the role of the respective parties, they can either use the Data Processing Agreement or the Data Exchange Agreement as a basis for their contractual arrangements. Before using any of these contract templates, it should first and foremost be assessed whether the personal data can actually be lawfully processed or exchanged.

In certain cases, the GDPR requires that the privacy effects of a project be assessed in advance (a Privacy Impact Assessment). This is the case when the processing of personal data constitutes a high risk for the data subjects. For certain companies, for example, companies which monitor individuals or systematically process sensitive data, it will become mandatory to have a Privacy Officer.

For more information on how GDPR affects you, we provide a [GDPR Factsheet](https://gitlab.com/ishare-foundation/cab/ishare-trust-framework/-/blob/main/.gitbook/assets/336035905.pdf).


# Glossary and legal notices

This chapter includes the iSHARE glossary and legal notices. It is presented as follows:

* [Glossary](/glossary-and-legal-notices/glossary)
* [Legal notices](/glossary-and-legal-notices/legal-notices)
* [Assumptions](/glossary-and-legal-notices/assumptions)


# Glossary

DISCLAIMER: All descriptions are definitions written by iSHARE, unless specified otherwise. DGA definitions are sourced from [Regulation (EU) 2022/868, Article 2](https://eur-lex.europa.eu/EN/legal-content/summary/european-data-governance.html?utm_source=chatgpt.com) and DSSC from official [website](https://dssc.eu/space/bv15e/777333342/Alphabetical+List+of+All+Defined+Terms+in+Blueprint+v1.5).

* [ABAC](#glossary-abacabac)
* [Accountability](#glossary-accountabilityaccountability)
* [Adherence](#glossary-adherence-ishare-adherence-ishare)
* [Adhering Party (role)](#adhering-party)
* [API](#glossary-apiapi)
* [Attestation](#glossary-authenticationauthentication)
* [Authentication](#glossary-authenticationauthentication)
* [Authenticity](#glossary-authenticityauthenticity)
* [Authorisation](#glossary-authorisationauthorization)
* [Authorisation Registry (role)](#glossary-authorisationregistry-role-authorizationregistry-role)
* [Caching](#glossary-cachingcaching)
* [Certificate authority](#glossary-certificateauthoritycertificateauthority)
* [Certification](#glossary-certification-ishare-certification-ishare)
* [Certified Party (role)](#glossary-confidentialityconfidentiality)
* [Change Advisory Board](#glossary-confidentialityconfidentiality-2)
* [Claim](#glossary-confidentialityconfidentiality-1)
* [Confidentiality](#glossary-confidentialityconfidentiality)
* [Conformance Test Tool (CTT)](#conformance-test-tool-ctt)
* [Connector](#connector-dssc)
* [Council of Participants](#glossary-credentialscredentials)
* [Credentials](#glossary-credentialscredentials)
* [CRUD](#glossary-crudcrud)
* [Data](#data) [or Data Set](#glossary-dataclassificationdataclassification)
* [Data Altruism](#data-altruism)
* [Data classification](#glossary-dataclassificationdataclassification)
* [Data exchange](#glossary-dataexchangedataexchange)
* [Data Governance Act](#data-governance-act)
* [Data Holder](#data-holder)
* [Data Intermediation Service](#data-intermediation-service)
* [Data Space](#glossary-dataspacedataspace)
* [Data Space Governance Body(role)](#glossary-satellite-role-satellite-role)
* [Data User](#data-user)
* [Delegation](#glossary-delegationdelegation)
* [eIDAS](#glossary-eidaseidas)
* [eIDAS 2](#glossary-encryptionencryption)
* [Encryption](#glossary-encryptionencryption)
* [Entitled Party (role)](#glossary-entitledparty-role-entitledparty-role)
* [European Digital Identification (EUDI) Wallet](#european-digital-identification-eudi-wallet)
* [Evidence](#evidence-dssc)
* [iSHARE-ID](#glossary-ishare-id)
* [Holder](#glossary-humanserviceconsumer-role-humanserviceconsumer-role)
* [HTTP(S)](#glossary-http-s-http-s)
* [Human Service Consumer (role)](#glossary-humanserviceconsumer-role-humanserviceconsumer-role)
* [Identification](#glossary-identificationidentification)
* [Identity Broker (role)](#glossary-identitybroker-role-identitybroker-role)
* [Identity Provider (role)](#glossary-identityprovider-role-identityprovider-role)
* [Integrity](#glossary-integrityintegrity)
* [iSHARE Network](#glossary-isharenetworkisharenetwork)
* [Issuer](#glossary-jsonjson)
* [JSON](#glossary-jsonjson)
* [JWT](#glossary-jwtjwt)
* [Levels of assurance](#glossary-levelsofassurancelevelsofassurance-loa)
* [Machine Service Consumer (role)](#glossary-machineserviceconsumer-role-machineserviceconsumer-role)
* [Non-repudiation](#glossary-non-repudiationnon-repudiation)
* [OAuth](#glossary-oauthoauth)
* [OIN](#glossary-oinoin)
* [OpenID Connect](#glossary-openidconnectopenidconnect)
* [Participant](#participant)
* [Participant Registry (role)](#participant-registry-role)
* [Party ID](#glossary-pdppdp)
* [PDP](#glossary-pdppdp)
* [PEP](#glossary-peppep)
* [PIP](#glossary-pippip)
* [PKI](#glossary-pkipki-publickeyinfrastructure)
* [PKI Root](#glossary-pkirootpkiroot)
* [RBAC](#glossary-rbacrbac)
* [Responsibility](#glossary-responsibilityresponsibility)
* [REST](#glossary-restrest-ful)
* [Scheme](#glossary-schemescheme)
* [Scheme Owner (role)](#glossary-schemeowner-role-schemeowner-role)
* [Service Consumer (role)](#glossary-serviceconsumer-role-serviceconsumer-role)
* [Service Provider (role)](#glossary-serviceprovider-role-serviceprovider-role)
* [Service provision](#glossary-serviceprovisionserviceprovision)
* [Signing](#glossary-signingsigning)
* [Status Code](#glossary-statuscodestatuscode-responsecode)
* [Subject](#glossary-tlstls)
* [TLS](#glossary-tlstls)
* [Token](#glossary-tokentoken)
* [Trust Anchor](#trust-anchor-dssc)
* [Trust Framework](#trust-framework)
* [Verifiable Credentials](#verifiable-credentials)
* [Verifier](#verifier-dssc)
* [Zero trust](#zero-trust)

***

### ABAC <a href="#glossary-abacabac" id="glossary-abacabac"></a>

ABAC (Attribute-Based Access Control) is assigning authorisations based on attributes (contextual pieces of information that are relevant to an access decision, such as device type, [RBAC](#glossary-rbacrbac) role, time, location, or [CRUD](#glossary-crudcrud) level). The attributes can be associated with all entities that are involved with certain actions, such as the subject, the object, the action itself and the context (e.g. time, location). The attributes are compared with policies to decide which actions are allowed in which context, granting access based on the policy outcomes.

***

### Accountability <a href="#glossary-accountabilityaccountability" id="glossary-accountabilityaccountability"></a>

There is a clear distinction between accountability and [Responsibility](#glossary-responsibilityresponsibility).

**Accountability** can be described as being liable or answerable for the completion of a certain task. Someone or something who is accountable oversees and manages the stakeholder(s) who are responsible for performing the work effort. In order to be effective, accountability should lie with a sole entity or role.

Responsibility may be delegated, but accountability cannot.

***

### Adherence <a href="#glossary-adherence-ishare-adherence-ishare" id="glossary-adherence-ishare-adherence-ishare"></a>

An **iSHARE Adhering Party** adheres to the [iSHARE terms of use](https://gitlab.com/ishare-foundation/cab/ishare-trust-framework/-/blob/main/.gitbook/assets/2774106116.pdf). An iSHARE Adhering Party MUST sign an Accession Agreement with the [Scheme Owner (role)](#glossary-schemeowner-role-schemeowner-role).

***

### Adhering Party

A legal entity, acting as an Entitled Party, a Service Consumer or a Service Provider as defined in the iSHARE Framework, who concluded an Accession Agreement with the Participant Registry or the Scheme Owner. To find more information about it follow the link: [iSHARE roles](https://framework.ishare.eu/main-aspects-of-the-ishare-trust-framework/framework-and-roles).

***

### API <a href="#glossary-apiapi" id="glossary-apiapi"></a>

An API (Application Programming Interface) is a technical interface, consisting of a set of protocols and data structuring standards ('API specifications'), which enables computer systems to communicate directly with each other. Data or services can be directly requested from a server by adhering to the protocols. APIs are used to hide the full complexity of software and make it easy for third parties to use parts of software or data services. APIs are mainly meant for developers to make the creation of new applications that depend on other applications easier.

***

### Attestation <a href="#glossary-authenticationauthentication" id="glossary-authenticationauthentication"></a>

According to [ISO/IEC 17000](https://www.snv.ch/files/content/Dokumente/News%20und%20Newslettertexte/ISO_IEC%2017000_Conformity%20assessment_Vocabulary%20and%20general%20principles.pdf), an attestation is an issue of a statement, based on a decision, that the fulfilment of specified requirements has been demonstrated.

In the iSHARE context, an attestation is a digital statement about a specific claim, that enables digital verification during role-based authorisation, compliance monitoring, and automated onboarding within the Participant Registry.

***

### Authentication <a href="#glossary-authenticationauthentication" id="glossary-authenticationauthentication"></a>

**Authentication** is the process of determining or validating whether someone or something is, in fact, who or what it is claiming to be. There are several means of authenticating the identity of an entity, which can be used alone or in combination:

* Something the entity knows – examples include a password, PIN, passphrase, or answer to a secret question;
* Something the entity possesses – examples include electronic keycard, smartcard, token, and smartphone;
* Something the entity is (biometrics) – examples include recognition by fingerprint, retina, iris, and face;
* Something the entity does (behavioural dynamics) – examples include recognition by voice pattern, swipe characteristics, handwriting characteristics, and typing rhythm;
* Something about the context of the entity – examples include IP address, device type, geolocation, and time of day.

***

### Authenticity <a href="#glossary-authenticityauthenticity" id="glossary-authenticityauthenticity"></a>

In the context of information security, **authenticity** refers to the truthfulness of information and whether this has been sent or created by an authentic sender.

Authenticity can be achieved by digitally [signing](#glossary-signingsigning) a message with the private key of the sender. The recipient can verify the digital signature with the matching public key. Certificates containing public and private keys are issued by a [Certificate Authority.](#glossary-certificateauthoritycertificateauthority)

***

### Authorisation <a href="#glossary-authorisationauthorization" id="glossary-authorisationauthorization"></a>

**Authorisation** is the process of giving someone or something permission to do something, for example, to access services, data or other functionalities. Authorisation is enabled by [Authentication](#glossary-authenticationauthentication). Policies and attributes determine what types of activities are permitted by an entity.

***

### Authorisation Registry (role) <a href="#glossary-authorisationregistry-role-authorizationregistry-role" id="glossary-authorisationregistry-role-authorizationregistry-role"></a>

The **Authorisation Registry**:

* Manages records of [Delegation](#glossary-delegationdelegation) and Authorisation[ ](#glossary-authorisationauthorization)of [Entitled Party (role)](#glossary-entitledparty-role-entitledparty-role) and/or [Service Consumer (role)](#glossary-serviceconsumer-role-serviceconsumer-role);
* Checks based on the registered permission(s) whether a [Machine Service Consumer (role) ](#glossary-machineserviceconsumer-role-machineserviceconsumer-role)Service Consumer is authorised to take delivery of the requested service, and;
* Confirms the established powers towards the [Service Provider (role).](#glossary-serviceprovisionserviceprovision)

Within the Trust Framework, the term Authorisation[ Registry ](#glossary-authorisationregistry-role-authorizationregistry-role)always refers to an external Authorisation Registry (not part of the[ Service Provider (role)](#glossary-serviceprovider-role-serviceprovider-role) or [Entitled Party (role)](#glossary-entitledparty-role-entitledparty-role)).

The Authorisation Registry is a role for which iSHARE [Certification ](#glossary-certification-ishare-certification-ishare)is REQUIRED.

Authorisation Registry is part of the data intermediation service in the [Data Governance Act](#data-governance-act-dga) and can be seen as a Participant Agent Services in DSSC Blueprint. Refer to our [Roles Nomenclature](https://trustbok.ishare.eu/apply-ishare/quick-walkthroughs/role-nomenclature) page to understand how this role is called in different data ecosystems.

***

### Caching <a href="#glossary-cachingcaching" id="glossary-cachingcaching"></a>

Web servers can temporarily store data in order to enable faster access to this data at a later moment; this is called 'caching'.

***

### Certificate Authority <a href="#glossary-certificateauthoritycertificateauthority" id="glossary-certificateauthoritycertificateauthority"></a>

A **Certificate Authority (CA)** is:

* An entity that issues digital certificates.
* A trusted party, and;
* Responsible for the binding of the certificate (registration & issuance).

A digital certificate certifies the ownership of a public key by the named subject of the certificate, so other parties can rely upon signatures or assertions made with the private key that corresponds to the certified public key.

A **Registration Authority** verifies the identity of entities requesting digital certificates to be issued by the CA and validates the correctness of the registration.

A **Validation Authority** verifies the validity of digital certificates on behalf of the CA.

***

### Certification <a href="#glossary-certification-ishare-certification-ishare" id="glossary-certification-ishare-certification-ishare"></a>

Certification is a process where prospective participants, willing to play one of the certified roles as defined in [iSHARE roles](https://framework.ishare.eu/main-aspects-of-the-ishare-trust-framework/framework-and-roles), go through in order to be granted certified status. Certification requires participants go through an assessment framework, in addition to the process every other (adhering) role goes through, to evaluate their organisation's level of assurance. The level of assurance determined helps other participants to expect the level of internal quality processes the certified party follows that helps in trust decision making.

***

### Certified Party <a href="#glossary-confidentialityconfidentiality" id="glossary-confidentialityconfidentiality"></a>

A legal entity, acting as a Participant Registry, an Authorisation Registry, an Identity Broker or an Identity Provider that has been certified by the Scheme Owner or by other Certifying Bodies, who concluded an Accession Agreement with the Participant Registry or the Scheme Owner. To find more information about it follow the link: [iSHARE roles](https://framework.ishare.eu/main-aspects-of-the-ishare-trust-framework/framework-and-roles).

***

### Certification body(/ies) <a href="#glossary-confidentialityconfidentiality" id="glossary-confidentialityconfidentiality"></a>

A Certification Body is an entity that independently checks whether an organisation meets the certification requirements for a specific role in the data ecosystem. If those requirements are met, the organisation can be recognised as certified within the ecosystem.\
\
In the iSHARE Trust Framework, certification is used for roles that other participants must be able to rely on, such as roles that support Identification, Authentication, Authorisation, or Participant Registries.

{% hint style="info" %}
The Scheme Owner currently certifies the roles of Identity Provider, Identity Broker, Authorisation Registry and Participant Registry. A Participant Registry can certify participants on behalf of the Scheme Owner.
{% endhint %}

***

### Change Advisory Board <a href="#glossary-confidentialityconfidentiality" id="glossary-confidentialityconfidentiality"></a>

The Change Advisory Board (CAB) is a governance body within the iSHARE Trust Framework consisting of subject matter experts delegated by participants and data spaces. The CAB advises the Scheme Owner (iSHARE Foundation) on proposed changes to the iSHARE Trust Framework specifications, through Requests for Change (RFCs).  

The CAB operates as a collaborative expert group that reviews, discusses, and provides recommendations on proposed changes. It plays a key role in ensuring that updates to the framework are well-informed, balanced across legal, operational, functional, and technical perspectives, and aligned with the needs of the ecosystem. CAB meetings and co-creation sessions support open participation and community-driven evolution of the framework.

***

### Claim <a href="#glossary-confidentialityconfidentiality" id="glossary-confidentialityconfidentiality"></a>

DSSC defines claim as an assertion made about a [subject](https://www.w3.org/TR/vc-data-model-2.0/#dfn-subjects). (ref. [Verifiable Credentials Data Model v2.0 (w3.org)](https://www.w3.org/TR/vc-data-model-2.0/#dfn-claims).

***

### Conformance Test Tool (CTT)

The iSHARE Conformance Test Tool (CTT) Enables Participants to validate that their systems and components comply with the technical specifications defined in iSHARE Trust Framework. It ensures interoperability between Parties in various roles within and across dataspaces. For full guidance, visit [CTT](https://trustbok.ishare.eu/apply-ishare/conformance-test-tool-ctt).

***

### Connector

DSSC defines connector as a technical component that is run by (or on behalf of) a participant and that provides participant agent services, with similar components run by (or on behalf of) other participants.

Explanatory Text: A connector can provide more functionality than is strictly related to connectivity. The connector can offer technical modules that implement data interoperability functions, authentication interfacing with trust frameworks and authorisation, data product self-description, contract negotiation, etc. We use “participant agent services” as the broader term to define these services.

{% hint style="info" %}
**Note**

This term was automatically generated as a synonym for: data-space-connector.
{% endhint %}

***

### Confidentiality <a href="#glossary-confidentialityconfidentiality" id="glossary-confidentialityconfidentiality"></a>

In the context of information security, **confidentiality** refers to the protection of information from disclosure to unauthorised parties.

Confidentiality can be achieved by the use of cryptography, as well as access control; the message the recipient gets can be proven not to have been read by anyone else but the legitimate sender and recipient.

***

### Council of Participants <a href="#glossary-credentialscredentials" id="glossary-credentialscredentials"></a>

The Council of Participants is a governance body within the iSHARE Trust Framework composed of all parties (or their representatives) that have a contractual relationship with the Scheme Owner and choose to participate. The Council advises the iSHARE Foundation and appoints members of the Supervisory Board, and is responsible for handling escalations regarding the governance of the foundation .

It ensures that participants have influence over governance, oversight, and strategic direction. In practice, it acts as a higher-level decision and escalation body, safeguarding fairness and alignment with participant interests when disputes or unresolved issues arise.

***

### Credentials <a href="#glossary-credentialscredentials" id="glossary-credentialscredentials"></a>

In the context of information security, **credentials** are used to control access of someone or something to something, for example, to services, data or other functionalities. The right credentials validate (i.e. [Authentication](#glossary-authenticationauthentication)) the identity claimed during [Identification](#glossary-identificationidentification).

The best-known example of credentials is a password, but other forms include electronic keycards, biometrics and, for machines, public key certificates.

***

### CRUD <a href="#glossary-crudcrud" id="glossary-crudcrud"></a>

CRUD (acronym for Create, Read, Update, Delete) are considered to be a basic function regarding stored data. In computer programming, possible actions are often mapped to these standard CRUD functions in order to clarify the actions. For example, standard [HTTP(S) ](#glossary-http-s-http-s)actions GET and POST refer to the Read and Create functions regarding stored data.

***

### Data or Data Set <a href="#glossary-dataclassificationdataclassification" id="glossary-dataclassificationdataclassification"></a>

Data or data set in context of iSHARE framework refers to data in its broadest sense. Examples include, but is not limited to, transactional data, data sets, big data, service data, metadata, etc.

[DGA ](https://eur-lex.europa.eu/EN/legal-content/summary/european-data-governance.html?utm_source=chatgpt.com)defines data as any digital representation of acts, facts or information and any compilation of such acts, facts or information, including in the form of a sound, visual or audiovisual recording.

***

### Data Altruism

According to [DGA ](https://eur-lex.europa.eu/EN/legal-content/summary/european-data-governance.html?utm_source=chatgpt.com)data altruism arises when individuals and companies give their consent or permission to make data that they generate available for use in the public interest, voluntarily and without reward. Such data have enormous potential to advance research and to develop better products and services, including in the fields of health, climate action and mobility. Member States may develop national policies to encourage data altruism and an entity engaged in data altruism can apply to be registered as a ‘data altruism organisation recognised in the Union’. The Commission will maintain an EU-level register of these organisations.

***

### Data classification

The classification of data in categories is an important prerequisite for proper Authorisation. Data can be classified by defining their type, location, sensitivity and protection level.

Clustering data in categories not only simplifies the authorisation process (i.e. giving someone or something permission to data), but it also provides a clear overview and lowers the risk of exchanging sensitive data with unauthorised entities. A risk analysis is part of the data classification process.

***

### Data exchange <a href="#glossary-dataexchangedataexchange" id="glossary-dataexchangedataexchange"></a>

Data exchange is the process of supplying data and receiving another (set of) data in return.

***

### Data Governance Act (DGA)

[DGA ](https://eur-lex.europa.eu/EN/legal-content/summary/european-data-governance.html?utm_source=chatgpt.com)is a cross-sectoral instrument that aims to regulate the reuse of publicly/held, protected data, by boosting data sharing through the regulation of novel data intermediaries and by encouraging the sharing of data for altruistic purposes. Both personal and non-personal data are in scope of the DGA, and wherever personal data is concerned, the General Data Protection Regulation (GDPR) applies. In addition to the GDPR, inbuilt safeguards will increase trust in data sharing and reuse, a prerequisite to making more data available on the market.

***

### Data Holder

According to [DGA ](https://eur-lex.europa.eu/EN/legal-content/summary/european-data-governance.html?utm_source=chatgpt.com)definition, a data holder is a legal person, including public sector bodies and international organisations, or a natural person who is not a data subject with respect to the specific data in question, who, in accordance with applicable EU or national law, has the right to grant access to or share certain personal or non-personal data.

Refer to our [Roles Nomenclature](https://trustbok.ishare.eu/apply-ishare/quick-walkthroughs/role-nomenclature) page to understand how this role is called in different data ecosystems.

{% hint style="info" %}
**NOTE:**

Within the iSHARE Framework, a Service Provider may qualify as a Data Holder.
{% endhint %}

***

### Data Intermediary

According to [DGA](https://eur-lex.europa.eu/EN/legal-content/summary/european-data-governance.html?utm_source=chatgpt.com) definition, a Data Intermediary is an entity that supports data sharing between parties, such as data holders, data subjects, and data users, through technical, legal, or organisational means. It is expected to act as a neutral party in that exchange.

{% hint style="info" %}
**NOTE**

Within the iSHARE Framework, a Data Intermediary is an organisation that helps other parties share data, but it does not own, change, or use the data itself. It helps make the exchange possible in a secure and trusted way. Service Providers and Certified parties usually qualify as data intermediaries.s
{% endhint %}

***

### Data Intermediation Service

[DGA ](https://eur-lex.europa.eu/EN/legal-content/summary/european-data-governance.html?utm_source=chatgpt.com)defines data intermediary services as a service that aims to establish commercial relationships for the purposes of data sharing between an undetermined number of data subjects and data holders on the one hand and data users on the other, through technical, legal or other means, including for the purpose of exercising the rights of data subjects in relation to personal data.

***

### Data Space <a href="#glossary-dataspacedataspace" id="glossary-dataspacedataspace"></a>

According to [DSSC](https://dssc.eu/space/bv15e/766061351/Introduction+-+Key+Concepts+of+Data+Spaces#What-about-a-Definition?) and [CEN](https://www.cencenelec.eu/media/CEN-CENELEC/CWAs/RI/2024/cwa18125_2024.pdf), a Data Space is an interoperable framework, based on common governance principles, standards, practices and enabling services, that enables trusted data transactions between participants.

In the context of the iSHARE Trust Framework, a data space can have a single or multiple Participant Registries that operate and work together.

***

### Data Space Governance Body (role) <a href="#glossary-satellite-role-satellite-role" id="glossary-satellite-role-satellite-role"></a>

The Data Space Governance Body is an entity that is the main representative of a data space and is responsible for the [data space](#glossary-dataspacedataspace), including the defining, evolving & maintaining and governing of participant lifecycle processes.

In other dataspace initiatives, this role is also known as Data Space Governance Authority. Refer to our [Roles Nomenclature](https://trustbok.ishare.eu/apply-ishare/quick-walkthroughs/role-nomenclature) page to understand how this role is called in different data ecosystems.

{% hint style="info" %}
**Note**

This role used to be referred as iSHARE Satellite in older versions of iSHARE Specifications
{% endhint %}

***

### Data User <a href="#glossary-delegationdelegation" id="glossary-delegationdelegation"></a>

A natural or legal person who has lawful access to certain personal or non-personal data and has the right, including under Regulation (EU) [2016/679](http://data.europa.eu/eli/reg/2016/679/oj/eng) (see [summary](https://eur-lex.europa.eu/EN/legal-content/summary/general-data-protection-regulation-gdpr.html)) in the case of personal data, to use that data for commercial or non-commercial purposes.

In other dataspace initiatives, this role is also known as Data Consumer, Service Consumer In Refer to our [Roles Nomenclature](https://trustbok.ishare.eu/apply-ishare/quick-walkthroughs/role-nomenclature) page to understand how this role is called in different data ecosystems.

{% hint style="info" %}
**Note**

Within the iSHARE Framework, a **Service Consumer**, as well as an **Entitled Party** may qualify as a **Data User**.
{% endhint %}

***

### Delegation

**Delegation** is the act of empowering someone or something to act for another or to represent other(s).

In the iSHARE ecosystem, a delegated [Service Consumer (role) ](#glossary-serviceconsumer-role-serviceconsumer-role)acts on behalf of an [Entitled Party (role)](#glossary-entitledparty-role-entitledparty-role). It can mean to represent authorisation, consent, delegation, mandate, etc. In VCs, it is also called DataRights Credential.

***

### Delegation paths

Delegation paths describe the sequence of delegations through which rights or permissions are passed from one party to another. In the iSHARE context, they make transparent on whose behalf a Service Consumer is authorised to act.

***

### eIDAS <a href="#glossary-eidaseidas" id="glossary-eidaseidas"></a>

[**eIDAS** ](https://eur-lex.europa.eu/eli/reg/2014/910/oj/eng)is an EU regulation on electronic identification and trust services for electronic transactions in the European Single Market. The regulation provides important aspects related to electronic transactions, such as qualified electronic certificates.

***

### eIDAS 2 <a href="#glossary-encryptionencryption" id="glossary-encryptionencryption"></a>

[eIDAS 2](https://eur-lex.europa.eu/eli/reg/2024/1183/oj/eng) is an updated version of the original eIDAS regulation, which aims to further enhance trust and security in cross-border digital transactions with the EU.

***

### Encryption <a href="#glossary-encryptionencryption" id="glossary-encryptionencryption"></a>

**Encryption** is the process of converting data from plaintext to ciphertext. Plaintext (also called cleartext) represents data in its original (readable) format, whereas ciphertext (also called cryptogram) represents data in an encrypted (unreadable) format.

Decryption is the process of converting data from ciphertext to plaintext.

The algorithm represents the mathematical or non-mathematical function used in the encryption and decryption process.

A cryptographic key represents the input that controls the operation of the cryptographic algorithm. With symmetric encryption, the same key is used for encryption and decryption, whereas with asymmetric encryption, two different, but mathematically related keys are used for either encryption or decryption, a so-called public key and a private key.

A crypto system represents the entire cryptographic environment, including hardware, software, keys, algorithms and procedures.

***

### Entitled Party (role) <a href="#glossary-entitledparty-role-entitledparty-role" id="glossary-entitledparty-role-entitledparty-role"></a>

The **Entitled Party** is the legal person that holds one or more legitimate rights regarding access to, use of, or control over data and/or data services provided by a [Service Provider (role)](https://framework.ishare.eu/glossary-and-legal-notices/glossary#glossary-serviceprovider-role-serviceprovider-role) with which it has a legal agreement.

This may include:

* The right to access or consume a data service (e.g. retrieve or send data)
* The right to exercise legal or contractual control over the data itself (e.g. data ownership, stewardship, or regulatory responsibility)

In cases where the Entitled Party holds primary legal [Responsibility ](https://framework.ishare.eu/glossary-and-legal-notices/glossary#glossary-responsibilityresponsibility)for the data, they are also [accountable ](https://framework.ishare.eu/glossary-and-legal-notices/glossary#glossary-accountabilityaccountability)for ensuring the [Confidentiality](https://framework.ishare.eu/glossary-and-legal-notices/glossary#glossary-confidentialityconfidentiality), [Integrity](https://framework.ishare.eu/glossary-and-legal-notices/glossary#glossary-integrityintegrity), [Availability](https://framework.ishare.eu/detailed-descriptions/operational/service-levels/service-levels-for-adhering-parties), and accurate reporting of that data.

The term Entitled Party may also be referred to in some contexts as Data Owner or Data Rights Holder.

The Entitled Party, [Service Consumer](#glossary-serviceconsumer-role-serviceconsumer-role) and [Service Provider](#glossary-serviceprovider-role-serviceprovider-role) 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, a trucking company's entitlement to request Estimated Time of Arrival and optimal route information), but this is not necessary.

The Entitled Party can also delegate its rights to another Service Consumer. In the latter case, this other Service Consumer (or its machines and humans) may consume services on the Entitled Party’s behalf, but it is not necessary.

[iSHARE Adherence](https://framework.ishare.eu/glossary-and-legal-notices/glossary#glossary-adherence-ishare-adherence-ishare) is REQUIRED for the Entitled Party role.

In other dataspace initiatives, this role is also referred as Data Owner, Data Holder, Data Rights Holder. Refer to our [Roles Nomenclature](https://trustbok.ishare.eu/apply-ishare/quick-walkthroughs/role-nomenclature) page to understand how this role is called in different data ecosystems.

***

### Evidence

According to DSSC evidence can be included by an [issuer](https://www.w3.org/TR/vc-data-model-2.0/#dfn-issuers) to provide the [verifier](https://www.w3.org/TR/vc-data-model-2.0/#dfn-verifier) with additional supporting information in a [verifiable credential](https://www.w3.org/TR/vc-data-model-2.0/#dfn-verifiable-credential) (ref. [Verifiable Credentials Data Model v2.0 (w3.org)](https://www.w3.org/TR/vc-data-model-2.0/#evidence) )

***

### European Digital Identification (EUDI) Wallet

[The European Digital Identity Regulation](https://digital-strategy.ec.europa.eu/en/policies/eudi-regulation) introduces the concepts of EU Digital Identity Wallets. They are personal digital wallets that allow citizens to digitally identify themselves, store and manage identity data and official documents in electronic format. These documents may include a driving licence, medical prescriptions or education qualifications.

### HTTP(S) <a href="#glossary-http-s-http-s" id="glossary-http-s-http-s"></a>

HTTP stands for 'Hypertext Transfer Protocol', and when secured via [TLS](#glossary-tlstls) or SSL, it is referred to as HTTPS (HTTP Secure). It is a protocol for (secure) communication over a computer network and is widely used on the Internet.

***

### Holder <a href="#glossary-humanserviceconsumer-role-humanserviceconsumer-role" id="glossary-humanserviceconsumer-role-humanserviceconsumer-role"></a>

DSSC defines holder as a role an [entity](https://www.w3.org/TR/vc-data-model-2.0/#dfn-entities) might perform by possessing one or more [verifiable credentials](https://www.w3.org/TR/vc-data-model-2.0/#dfn-verifiable-credential) and generating [verifiable presentations](https://www.w3.org/TR/vc-data-model-2.0/#dfn-verifiable-presentation) from them. A holder is often, but not always, a [subject](https://www.w3.org/TR/vc-data-model-2.0/#dfn-subjects) of the [verifiable credentials](https://www.w3.org/TR/vc-data-model-2.0/#dfn-verifiable-credential) they are holding. Holders store their [credentials](https://www.w3.org/TR/vc-data-model-2.0/#dfn-credential) in [credential repositories](https://www.w3.org/TR/vc-data-model-2.0/#dfn-credential-repositories). (ref. [Verifiable Credentials Data Model v2.0 (w3.org)](https://www.w3.org/TR/vc-data-model-2.0/#dfn-holders) )

***

### Human Service Consumer (role) <a href="#glossary-humanserviceconsumer-role-humanserviceconsumer-role" id="glossary-humanserviceconsumer-role-humanserviceconsumer-role"></a>

The **Human Service Consumer** is a role that represents a human (person) who requests, receives, and uses certain services, such as data, from a [Service Provider (role)](#glossary-serviceprovider-role-serviceprovider-role) on behalf of and authorised by the [Service Consumer (role)](#glossary-serviceconsumer-role-serviceconsumer-role).

The Human Service Consumer is not a separate role, but belongs to the Adhering Party Service Consumer.

In the EUDI Wallet ARF context (v2.7.3), comparable actor term is (Wallet) User (See [EUDI Wallet ARF actor mapping](https://trustbok.ishare.eu/understand-ishare/role-nomenclature/eudi-wallet-arf-actor-mapping)).

***

### Identification <a href="#glossary-identificationidentification" id="glossary-identificationidentification"></a>

**Identification** is the process of someone or something claiming an identity by presenting characteristics called identity attributes. Such attributes include a name, user name, e-mail address, etc. The claimed identity can be validated (i.e. [Authentication](#glossary-authenticationauthentication)) with the right [credentials](#glossary-credentialscredentials).

***

### Identity Broker (role) <a href="#glossary-identitybroker-role-identitybroker-role" id="glossary-identitybroker-role-identitybroker-role"></a>

If multiple distinct [Service Providers (role)](#glossary-serviceprovider-role-serviceprovider-role) exist where each data set is protected under a distinct trust domain, multiple [Identity Providers (role)](#glossary-identityprovider-role-identityprovider-role) may be needed. Moreover, the iSHARE Scheme may require different [Levels of assurance](#glossary-levelsofassurancelevelsofassurance-loa) for specific data and may wish to designate specific Identity Providers for specific services.

In order to support multiple Identity Providers (with possible multiple rules) and Service Providers, an **Identity Broker** is required. An Identity Broker allows [Human Service Consumer (role) ](#glossary-humanserviceconsumer-role-humanserviceconsumer-role)to select the Identity Provider they prefer to [Authenticate](#glossary-authenticationauthentication) themselves at. It prevents the need for a direct relationship between all Service Providers and all Identity Providers.

The Identity Broker is a role for which iSHARE [Certification (iSHARE)](#glossary-certification-ishare-certification-ishare) is REQUIRED.

***

### Identity Provider (role) <a href="#glossary-identityprovider-role-identityprovider-role" id="glossary-identityprovider-role-identityprovider-role"></a>

The **Identity Provider**:

* Provides identifiers for [Human Service Consumer](#glossary-humanserviceconsumer-role-humanserviceconsumer-role);
* Issues credentials to Human Service Consumers;
* Manages records of [Authorisation](#glossary-authorisationauthorization) of the [Service Consumer (role)](#glossary-serviceconsumer-role-serviceconsumer-role);
* Identifies and authenticates [Human Service Consumers](#glossary-humanserviceconsumer-role-humanserviceconsumer-role) based on provided credentials
* Checks based on the provided credentials and the registered permission(s), whether a Human Service Consumer (role) Service Consumer is authorised to take delivery of the requested service, and;
* Confirms the established powers towards the [Service Provider (role).](#glossary-serviceprovider-role-serviceprovider-role)
* Possibly provides other information (which are frequently referred to as attributes) about the user that is known to the Identity Provider.

In the iSHARE ecosystem, an Identity Provider could support various methods of [Authentication](#glossary-authenticationauthentication), such as:

* Password authentication;
* Hardware-based authentication (e.g. smartcard, token);
* Biometric authentication;
* Attribute-based authentication.

Depending on parameters such as the quality of the registration process, quality of credentials, use of biometrics or multiple authentication factors and information security, an Identity Provider can provide a client with a high or low confidence in the claimed identity of the user, which is known to the Identity Provider. This is also known as the [Levels of assurance](#glossary-levelsofassurancelevelsofassurance-loa).

The Identity Provider is a role for which iSHARE [Certification (iSHARE)](#glossary-certification-ishare-certification-ishare) is REQUIRED.

In the EUDI Wallet ARF context (v2.7.3), comparable actor terms are PID Provider and/or Attestation Provider (depending on credential type) (See [EUDI Wallet ARF actor mapping](https://trustbok.ishare.eu/understand-ishare/role-nomenclature/eudi-wallet-arf-actor-mapping)).

***

### Integrity <a href="#glossary-integrityintegrity" id="glossary-integrityintegrity"></a>

In the context of information security, **integrity** refers to the protection of information from being modified by unauthorised parties.

In the iSHARE context, integrity is primarily ensured through the signing of the data, for example, the client assertion is signed by the sender so that receiver can be confident it has not been modified.

***

### iSHARE-ID <a href="#glossary-ishare-id" id="glossary-ishare-id"></a>

An iSHARE ID is a Decentralised Identifier (DID) derived based on the existing and pre-validated (by a Trust Service Provider) identifier of a party. All participant registries must derive and register an iSHARE ID for each participant they onboard. iSHARE ID is typically derived from a PKI certificate or a signed token from a certified identity provider. Please refer to [https://did.iSHARE.eu](https://did.ishare.eu) for `ishare` DID method specifications.

iSHARE ID enables identity interoperability and discoverability of participants across multiple data ecosystems, which can be verified.

{% hint style="info" %}
**Note**

iSHARE ID is not meant to replace other identifiers or serve as the only identifier, but it allows parties to be registered with multiple types of identifiers.
{% endhint %}

***

### iSHARE Ecosystem (or Network) <a href="#glossary-isharenetworkisharenetwork" id="glossary-isharenetworkisharenetwork"></a>

The iSHARE Ecosystem (or network) is the collection of ecosystems, participants and data spaces that are established, maintained, and governed accordingly to the iSHARE Trust Framework. The complete decentralised trust ecosystem that is established using the iSHARE Trust Standard for data sharing.

***

### Issuer <a href="#glossary-jsonjson" id="glossary-jsonjson"></a>

A role an [entity](https://www.w3.org/TR/vc-data-model-2.0/#dfn-entities) can perform by asserting [claims](https://www.w3.org/TR/vc-data-model-2.0/#dfn-claims) about one or more [subjects](https://www.w3.org/TR/vc-data-model-2.0/#dfn-subjects), creating a [verifiable credential](https://www.w3.org/TR/vc-data-model-2.0/#dfn-verifiable-credential) from these [claims](https://www.w3.org/TR/vc-data-model-2.0/#dfn-claims), and transmitting the [verifiable credential](https://www.w3.org/TR/vc-data-model-2.0/#dfn-verifiable-credential) to a [holder](https://www.w3.org/TR/vc-data-model-2.0/#dfn-holders). (ref. [Verifiable Credentials Data Model v2.0 (w3.org)](https://www.w3.org/TR/vc-data-model-2.0/#dfn-issuers) )

***

### JSON <a href="#glossary-jsonjson" id="glossary-jsonjson"></a>

JSON is short for 'JavaScript Object Notation' and is an open standard data format that does not depend on a specific programming language. This compact data format makes use of human-readable (easy-to-read) text to exchange data objects (structured data) between applications and for data storage.

JSON is most commonly used for asynchronous communication between browsers and servers.

***

### JWT <a href="#glossary-jwtjwt" id="glossary-jwtjwt"></a>

A JSON Web Token (JWT) is used when [non-repudiation](#glossary-non-repudiationnon-repudiation) between parties is required. A statement, of which the data is encoded in [JSON](#glossary-jsonjson), is digitally signed to protect the [Authenticity](#glossary-authenticityauthenticity) and [Integrity](#glossary-integrityintegrity) of the statement.

***

### Levels of Assurance (LoA) <a href="#glossary-levelsofassurancelevelsofassurance-loa" id="glossary-levelsofassurancelevelsofassurance-loa"></a>

Within online [Authentication](#glossary-authenticationauthentication), depending on the authentication protocol used, the server is to some extent assured of the client's identity. Depending on parameters such as the quality of the registration process, quality of credentials, use of biometrics or multiple authentication factors and information security, an authentication protocol can provide a server with a high or low confidence in the claimed identity of the client. For low-interest products, a low certainty might be sufficient, while for sensitive data, it is essential that a server is confident that the client's claimed identity is valid.

***

### Machine Service Consumer (role) <a href="#glossary-machineserviceconsumer-role-machineserviceconsumer-role" id="glossary-machineserviceconsumer-role-machineserviceconsumer-role"></a>

The **Machine** **Service Consumer** is a role that represents a machine that requests, receives, and uses certain services, such as data, from a Service Provider (role) on behalf of and authorised by the [Service Consumer (role)](#glossary-serviceconsumer-role-serviceconsumer-role).

The Machine Service Consumer is not a separate role, but it belongs to the Adhering Party Service Consumer (role).

***

### Non-repudiation <a href="#glossary-non-repudiationnon-repudiation" id="glossary-non-repudiationnon-repudiation"></a>

In the context of information security, **non-repudiation** refers to the fact that the sending (or broadcast) and receipt of the message cannot be denied by either of the involved parties (sender and recipient).

Non-repudiation is closely related to [Authenticity](#glossary-authenticityauthenticity) and can be achieved by digital [Signing](#glossary-signingsigning) in combination with message tracking.

***

### OAuth <a href="#glossary-oauthoauth" id="glossary-oauthoauth"></a>

OAuth is an open standard for [Authorisation](#glossary-authorisationauthorization), which is used by, i.e. Google, Facebook, Microsoft, Twitter, etc., to let their users exchange information about their accounts with other applications or websites. OAuth is designed to work with [HTTP(S)](#glossary-http-s-http-s). Within iSHARE, a modified version of OAuth 2.0 is used.

Through OAuth, users can authorise third-party applications or websites to access their account information on other 'master' systems without the need to exchange their [Credentials](#glossary-credentialscredentials) with them to log in to the platform. OAuth provides a 'secure delegated access' to resources (email accounts, picture accounts, etc.) on behalf of the resource owner.

It specifies a method for resource owners to authorise third parties' access to their resources without exchanging their credentials (username, password). Authorisation servers (of the platform) issue access tokens to third-party clients (applications or websites) with the approval of the resource owner (= end user). The third-party client needs the access token to get access to the resources that are stored on the resource server (of the master system).

***

### OIN <a href="#glossary-oinoin" id="glossary-oinoin"></a>

The OIN format is used to uniquely identify organisations. OIN stands for Organisation Identifying Number. An OIN consists of the following concatenated elements:

* An 8-digit prefix that tells the register where the number is defined (e.g. Chamber of Commerce, RSIN, etc.)
* A number whose value depends on the register

***

### OpenID Connect <a href="#glossary-openidconnectopenidconnect" id="glossary-openidconnectopenidconnect"></a>

OpenID Connect (OIDC) is the authentication layer that is built on top of the [OAuth](#glossary-oauthoauth) 2.0 protocol, which is an authorisation framework. The OIDC authentication layer allows clients to verify the ID and obtain basic profile information of their end-users

The authentication is performed by the authorisation server (managing the access rights and conditions) in an interoperable and [REST](#glossary-restrest-ful)-like manner. Within iSHARE, OpenID Connect 1.0 is used.

***

### Participant <a href="#glossary-participant" id="glossary-participant"></a>

An organisation or legal entity formally admitted to the iSHARE Ecosystem that assumes one or more defined roles and adheres to the iSHARE Trust Framework’s legal, technical, and governance requirements.

***

### Participant Registry (role)

The Participant Registry ensures smooth onboarding and membership management in a data space. All participants within the Data Space/iSHARE network will be explicitly linked to the Participant Registry responsible for their admission. The Participant Registry is a certified party and can also be the [Data Space Governance Body](#glossary-satellite-role-satellite-role) for the data space.\
\
The Participant Registry plays a fundamental role in any iSHARE use case. As part of the [secondary use cases](/detailed-descriptions/functional/secondary-use-cases), parties will need to register themselves as [certified or a](/main-aspects-of-the-ishare-trust-framework/framework-and-roles)dhere to a Participant Registry. They will also need to consult the Participant Registry to check whether their counterparty is adherent or certified.

In other dataspace initiatives, this role is also referred as Dataspace Registry. Refer to our [Roles Nomenclature](https://trustbok.ishare.eu/apply-ishare/quick-walkthroughs/role-nomenclature) page to understand how this role is called in different data ecosystems.

In the EUDI Wallet ARF context (v2.7.3), comparable actor terms are Registrar (of wallet-relying parties) and related trusted-list concepts (See [EUDI Wallet ARF actor mapping](https://trustbok.ishare.eu/understand-ishare/role-nomenclature/eudi-wallet-arf-actor-mapping)).

***

### Party ID <a href="#glossary-pdppdp" id="glossary-pdppdp"></a>

A *Party ID* is typically a unique identifier issued to a natural person or legal person. A data space may require one or more such identifiers during the onboarding of a participant. A data space may even define its own identifier. The Party ID facilitates the accurate identification and authentication of the relevant entity.

The [iSHARE ID](#glossary-ishare-id) serves as a specific type of Party ID, enabling interoperability of identity across various data ecosystems in a verifiable and trusted manner.

***

### PDP <a href="#glossary-pdppdp" id="glossary-pdppdp"></a>

Policy Decision Point. An entity that evaluates access requests that are received from the policy enforcement point ([PEP](#glossary-peppep)). Subsequently, an answer is sent back to the PEP.

***

### PEP <a href="#glossary-peppep" id="glossary-peppep"></a>

Policy Enforcement Point. An entity that determines whether an action is permitted or not. It takes any access requests and forwards them to the policy decision point ([PDP](#glossary-pdppdp)).

***

### PIP <a href="#glossary-pippip" id="glossary-pippip"></a>

Policy Information Point. An entity that holds policy information and is contacted as a source of information regarding [Delegation](#glossary-delegationdelegation)/[Authorisation](#glossary-authorisationauthorization) information.

***

### PKI (Public Key Infrastructure) <a href="#glossary-pkipki-publickeyinfrastructure" id="glossary-pkipki-publickeyinfrastructure"></a>

A PKI is a system for the distribution and management of digital keys and certificates, which enables secure authentication of parties interacting with each other.

Generally, three different methods exist for creating trust within PKIs. These are through 'Certificate Authorities', 'Web of Trust' and 'Simple PKI'. Within iSHARE, the 'Certificate Authority' approach is used, and as such, the other methods will not be discussed.

A PKI can be considered a chain of certificates. At the beginning of the chain is the root '[Certificate Authority'](#glossary-certificateauthoritycertificateauthority) (CA), a public trusted party which is allowed to digitally sign its own certificates (SSC, self-signed certificate). This '[PKI Root](#glossary-pkirootpkiroot) CA' distributes certificates and encryption keys to organisations. The certificate is signed by the 'root CA' as proof that the owner of the certificate is trusted. These organisations can start distributing certificates as well, if allowed by their root. They become CAs, and as such, sign the certificates that they distribute. Repeating these steps, a chain of certificates is created, with each certificate signed by the CA that distributed the certificate.

Parties need to trust a certificate for [Authentication](#glossary-authenticationauthentication) purposes. Instead of trusting individual certificates of organisations, root certificates can be trusted. By trusting a root, all certificates that have the root within their PKI chains are automatically trusted. Most large root CAs are automatically trusted within web browsers, enabling computers to safely interact with most web servers.

***

### PKI Root <a href="#glossary-pkirootpkiroot" id="glossary-pkirootpkiroot"></a>

A PKI root is another term for a root certificate, and stands for a self-signed public key certificate that identifies the [Certificate Authority](#glossary-certificateauthoritycertificateauthority), the party that is trusted by all members in the trust framework. The most common type of PKI certificates is based on the [X.509](/detailed-descriptions/technical/technical-standards) standard and normally includes the digital signature of the Certificate Authority. The certificate authority issues digital certificates to all members in the trust framework.

***

### RBAC <a href="#glossary-rbacrbac" id="glossary-rbacrbac"></a>

Role-Based Access Control. Assigning authorisations through business roles. An RBAC role represents a set of tasks or activities translated into authorisations, reflecting one or more of the following:

* Organisational structure
* Business processes
* Policies (rules)

RBAC authorisations can either give access to the front door of the information system or can be translated to access rights within the information system (often through application roles or groups).

***

### Responsibility <a href="#glossary-responsibilityresponsibility" id="glossary-responsibilityresponsibility"></a>

There is a clear distinction between responsibility and [Accountability](#glossary-accountabilityaccountability).

**Responsibility** can be described as being tasked with getting the job done. Someone or something who is responsible performs the actual work effort to meet a stated objective.

Responsibility may be delegated, but accountability cannot.

***

### REST(ful) <a href="#glossary-restrest-ful" id="glossary-restrest-ful"></a>

REST stands for 'Representational State Transfer' and is an architectural style for building systems and services. Systems adhering to this architectural style are commonly referred to as 'RESTful systems'. REST itself is not a formal standard, but it is an architecture that applies various common technical standards such as [HTTP(S)](#glossary-http-s-http-s), [JSON](#glossary-jsonjson) and URI.

A RESTful [API](#glossary-apiapi) indicates that the API architecture follows REST 'constraints'. Constraints restrict the way that servers respond and process client requests, to preserve the design goals which are intended by applying REST. The goals of REST are, among others, performance and scalability. Both are of utmost importance in iSHARE.

***

### Scheme <a href="#glossary-schemescheme" id="glossary-schemescheme"></a>

A **scheme** can be defined as a collaborative effort to establish and maintain a set of agreements to achieve a common goal. The iSHARE Scheme is also known as the iSHARE Trust Framework.

iSHARE is a scheme with [common goals](/introduction/goals-and-scope-of-the-ishare-trust-framework). Other schemes include credit card schemes such as MasterCard and Visa, payment scheme iDEAL and identity scheme eHerkenning.

***

### Scheme Owner (role) <a href="#glossary-schemeowner-role-schemeowner-role" id="glossary-schemeowner-role-schemeowner-role"></a>

The **Scheme Owner** represents the body that governs the iSHARE Trust Framework and its participants.

Refer to our [Roles Nomenclature](https://trustbok.ishare.eu/apply-ishare/quick-walkthroughs/role-nomenclature) page to understand how this role is called in different data ecosystems.

***

### Service Consumer (role) <a href="#glossary-serviceconsumer-role-serviceconsumer-role" id="glossary-serviceconsumer-role-serviceconsumer-role"></a>

The **Service Consumer** is the legal entity that consumes the [Service Provider's (role)](#glossary-serviceprovider-role-serviceprovider-role) service based on the [Entitled Party's (role)](#glossary-entitledparty-role-entitledparty-role) rights to that service. It can do so because the Service Consumer is either the same legal entity as the Entitled Party (i.e. it already has these rights) or because the Entitled Party has delegated rights to the [Service Consumer](#glossary-serviceconsumer-role-serviceconsumer-role).

The Service Consumer interacts with the Service Provider in the form of a [Machine Service Consumer (role)](#glossary-machineserviceconsumer-role-machineserviceconsumer-role) or [Human Service Consumer (role)](#glossary-humanserviceconsumer-role-humanserviceconsumer-role).

The Service Consumer is a role for which iSHARE [Adherence (iSHARE)](#glossary-adherence-ishare-adherence-ishare) is REQUIRED.

In other dataspace initiatives, this role is also referred as Data Space Support Organisation. Refer to our [Roles Nomenclature](https://trustbok.ishare.eu/apply-ishare/quick-walkthroughs/role-nomenclature) page to understand how this role is called in different data ecosystems.

In the EUDI Wallet ARF context (v2.7.3), comparable actor term is (Wallet) User (See [EUDI Wallet ARF actor mapping](https://trustbok.ishare.eu/understand-ishare/role-nomenclature/eudi-wallet-arf-actor-mapping)).

***

### Service Provider (role) <a href="#glossary-serviceprovider-role-serviceprovider-role" id="glossary-serviceprovider-role-serviceprovider-role"></a>

The Service Provider is a role that provides certain services, such as data, to a[ Service Consumer (role)](https://framework.ishare.eu/glossary-and-legal-notices/glossary#glossary-serviceconsumer-role-serviceconsumer-role). In the case of data provisioning, the Service Provider is either the Data Owner or, has the case the service pertains to data provisioning, the Service Provider is either the [Entitled Party](#glossary-entitledparty-role-entitledparty-role) or has explicit consent of the[ ](https://framework.ishare.eu/glossary-and-legal-notices/glossary#glossary-dataownerdataowner)[Entitled Party](#glossary-entitledparty-role-entitledparty-role) to provide the services.

The Service Provider is[ ](https://framework.ishare.eu/glossary-and-legal-notices/glossary#glossary-responsibilityresponsibility)responsible for the availability of services, and[ ](https://framework.ishare.eu/glossary-and-legal-notices/glossary#glossary-accountabilityaccountability)accountable for these services if it also has the role of the Entitled Party.

[iSHARE Adherence](broken://spaces/zdKjSSaFEukZOShyTzC9) is REQUIRED for the Service Provider role.

In other dataspace initiatives, this role is also referred as Data Provider, Data Node. Refer to our [Roles Nomenclature](https://trustbok.ishare.eu/apply-ishare/quick-walkthroughs/role-nomenclature) page to understand how this role is called in different data ecosystems.

In the EUDI Wallet ARF context (v2.7.3), comparable actor term is (Wallet-) Relying Party (See [EUDI Wallet ARF actor mapping](https://trustbok.ishare.eu/understand-ishare/role-nomenclature/eudi-wallet-arf-actor-mapping)).

***

### Service provision <a href="#glossary-serviceprovisionserviceprovision" id="glossary-serviceprovisionserviceprovision"></a>

**Service provision** is the act of providing or supplying something for consumption or use. One of the most common forms of service provision is the [Data exchange](#glossary-dataexchangedataexchange).

***

### Signing <a href="#glossary-signingsigning" id="glossary-signingsigning"></a>

**Signing** is the process of [Encryption](#glossary-encryptionencryption) data (message, document, transaction) with the private key of the sender. It enables a receiver to confirm the [Authenticity](#glossary-authenticityauthenticity) of the data. Signing also provides for [Non-repudiation](#glossary-non-repudiationnon-repudiation), so that it is ensured that a sender cannot deny having sent a message.

In most cases, a hash of the data is encrypted. Thus, both the [Integrity](#glossary-integrityintegrity) and the [Authenticity](#glossary-authenticityauthenticity) of the data can be verified. Confirmation takes place by the receiver uses the public key of the sender. The public key is contained in the digital certificate that is sent by the sender along with the signed data. The association of the key pair with the sender MUST be assured by a [Certificate Authority](#glossary-certificateauthoritycertificateauthority).

***

### Status Code / Response Code <a href="#glossary-statuscodestatuscode-responsecode" id="glossary-statuscodestatuscode-responsecode"></a>

After sending an [HTTP(S)](#glossary-http-s-http-s) request to a server, the server responds with (among others) a Status Code, which indicates the outcome of the request made to the server. A well-known response is 404 Not found, indicating that the requested location or resource is not (yet) found.

***

### System Services

In the context of the iSHARE Trust Framework, System Services are catered by the use of systems like APIs, portals or IoT devices. The service levels for Availability and Performance mainly apply to system service providers, irrespective of their role. Thus, organisations providing only business services are exempt from these service level requirements (like [Entitled Party](#glossary-entitledparty-role-entitledparty-role) and [Service Consumers](#glossary-serviceconsumer-role-serviceconsumer-role)).

***

### Subject <a href="#glossary-tlstls" id="glossary-tlstls"></a>

Thing about which [claims](https://www.w3.org/TR/vc-data-model-2.0/#dfn-claims) are made (ref. [Verifiable Credentials Data Model v2.0 (w3.org)](https://www.w3.org/TR/vc-data-model-2.0/#dfn-subjects) )

***

### TLS <a href="#glossary-tlstls" id="glossary-tlstls"></a>

TLS (Transport Layer Security) is a set of protocols that provides for secure communication in computer networks. TLS makes use of cryptography and is widely used by a variety of applications such as web browsing, email and voice-over-IP. Securing [HTTP(S)](#glossary-http-s-http-s) communication via (among others) TLS results in the HTTP(S) protocol. Securing communication with TLS v1.2 is mandatory for all iSHARE communication.

***

### Token <a href="#glossary-tokentoken" id="glossary-tokentoken"></a>

Something that serves as a verifiable representation of some fact, e.g. an identity or entitlement. Within iSHARE, Tokens are issued after completing [API](#glossary-apiapi) requests, which are then used to process the next request. For example, to access a certain service, first, an access token is required. Upon receiving this access token, it can be used to request the service itself.

***

### Trust Anchor

According to [DSSC](https://dssc.eu/space/BVE2/1071255941/Trust+Framework#3.2.1-Trust-Anchors) , Trust Anchors are authoritative entities for which trust is assumed and not derived. Each Trust Anchor is accepted by the data space governance authority in relation to a specific [scope of attestation](https://www.iso.org/obp/ui/#iso:std:iso-iec:17000:ed-2:v2:en:term:7.4).\
Examples include governmental bodies. Their fundamental role is to ensure the authenticity, integrity, security, and reliability of identities, data services and transactions within the data space.

***

### Trust Framework

According to [DSSC](https://dssc.eu/space/BVE2/1071255941/Trust+Framework#3.2.1-Trust-Framework), a trust framework provides the methodology and technical specifications for collecting, organizing, and verifying information to support trust decisions - that is, decisions about whether an entity, piece of information, or transaction can be trusted.

The iSHARE Trust Framework is a collaborative initiative aimed at improving the exchange of data between organizations. It focuses on identification, authentication, and authorization to ensure secure and trusted data sharing. The framework provides a set of agreements and standards that facilitate seamless business data sharing, addressing legal, functional, operational, and technical dimensions to enhance governance and interoperability among participants.

***

### Verifier

DSSC defines verifier as a role an [entity](https://www.w3.org/TR/vc-data-model-2.0/#dfn-entities) performs by receiving one or more [verifiable credentials](https://www.w3.org/TR/vc-data-model-2.0/#dfn-verifiable-credential), optionally inside a [verifiable presentation](https://www.w3.org/TR/vc-data-model-2.0/#dfn-verifiable-presentation) for processing. Other specifications might refer to this concept as a relying party. (ref. [Verifiable Credentials Data Model v2.0 (w3.org)](https://www.w3.org/TR/vc-data-model-2.0/#dfn-verifier) )

***

### Verifiable Credentials

[According to the W3C Verifiable Credentials Data Model v2.0](https://www.w3.org/TR/vc-data-model-2.0/#dfn-verifiable-credential), a verifiable credential is a tamper-evident credential whose authorship can be cryptographically verified. Verifiable credentials can be used to build verifiable presentations, which can also be cryptographically verifiable.

***

### Zero trust

Zero Trust is a principle by which trust is not automatically assumed based on a participant’s presence within a network but is verified just in time(of use). Trust can be evaluated using credentials or dynamically verified trust criteria, ensuring each interaction is authenticated based on current, context-sensitive information. Zero trust principles are rooted in the iSHARE Trust Framework and its components, like the Participant Registry.


# Legal notices

No part of these specifications may be reproduced in any form by print, photo print, microfilm or any other means or stored in an electronic retrieval system, without the prior written consent of the iSHARE Foundation ( successor of the project organisation), which must never be presumed.


# Assumptions

The iSHARE Trust Framework was developed with the following assumptions in mind:

1. **Conditions for the exchange of data are assumed to be established;** The iSHARE Trust Framework needs to rely upon the responsibility of participants to know what rights they have to what data. The Framework is meant as an instrument to exchange data in a uniform, controlled and straightforward way; it is not meant as a means to resolve questions of data ownership. In practice, this means that a party sharing data bears responsibility to sufficiently establish whether the party receiving the data is authorised to receive it.
2. **Data formats and semantics are assumed to be in place;** In order to be able to exchange data, a mutual understanding of the meaning of data and the way data is structured is required. Within the data spaces/iSHARE network, it is assumed that this mutual understanding exists and thus the exchange of data between involved parties is possible (in line with [guiding principle 4](/introduction/guiding-principles)). Please note that this assumption emphasises the need for industry initiatives on data standards and formats.
3. **Data classification has taken place;** It is assumed that within the iSHARE Trust Framework, participants have sufficiently identified and classified their data. iSHARE participants are responsible for the classification of their data; the iSHARE Trust Framework does not prescribe to its participants how to classify their resources. Please refer to [data classification in the glossary](/glossary-and-legal-notices/glossary#glossary-dataclassificationdataclassification) for further details.

### Operational assumptions: <a href="#assumptions-operationalassumptions" id="assumptions-operationalassumptions"></a>

The Operational details of the iSHARE Trust Framework were developed with the following assumptions in mind:

1. **There will be a Scheme Owner of a yet to be defined form;** This can be an existing body or a new body, and/or responsibilities can be split between different bodies.
2. **The Scheme Owner is financed through some type of financing constellation;** This can be through participants paying some type of fee or in any other feasible way. The Operational Working Group did not decide upon the financing constellation of the Scheme Owner.
3. **The complexity of the operational processes is expected to be as follows:**
   * It is considered reasonable to expect between 1000 and 10000 Adhering Parties in the first 5 years after data spaces go live;
   * It is considered reasonable to expect between 20 and 50 Certified Parties in the first 5 years after data spaces go live.
   * It is considered reasonable to expect parties to participate from countries all over the world in the first 5 years.
   * The Scheme Owner aims to keep the effort needed for admission as low as possible for both Adhering and Certified Parties without compromising the integrity of the iSHARE Trust Framework and network.
   * The Scheme Owner regularly tests the robustness of the Trust Framework and plans for mitigation of risks/threats (e.g. identifying Single Points of Failure);
   * The Scheme Owner is assumed to have at least some responsibility in realising sustainable growth of the data space/iSHARE network;
   * The management of disputes regarding the contents of the data shared is not a core role of the Scheme Owner; disputes should be handled by the involved parties.

These assumptions are, in NO WAY, ambitions. They were simply defined to base processes and service levels upon.


# iSHARE Trust Framework

{% hint style="info" %}
This is iSHARE Framework version: 2.2.&#x20;

Framework specifications were updated on Jan 2026 to reflect the updates from version [2.1.1](/version-2.1.1).
{% endhint %}

This document provides a full overview of the current state of the iSHARE Trust Framework.

iSHARE is a collaborative effort to improve conditions for data-sharing for organizations. The functional scope of the iSHARE Trust Framework focuses on topics of identification, authentication and authorization to business data attributes.

<figure><img src="/files/Tro0gGPWqoRU2bD0QKse" alt=""><figcaption></figcaption></figure>


# Introduction

iSHARE is a collaborative effort to improve conditions for data-sharing for organisations aiming to collaborate in a data space. The functional scope of the iSHARE Trust Framework focuses on topics of identification, authentication and authorisation.

## Reader's guide <a href="#introduction-readersguide" id="introduction-readersguide"></a>

* iSHARE's introductory section describes the Framework's starting points: its goals, the guiding principles and the governance of the Trust Framework;
* The '[releases](/version-2.2/releases)' section describes the release notes, planning of future releases and version history of the iSHARE Trust Framework;
* The '[main aspects of the iSHARE Trust Framework](/version-2.2/main-aspects-of-the-ishare-trust-framework)' section summarises the most important functionality of the Framework, roles, and the technical, operational and legal provisions enabling it;
* The '[use cases](/version-2.2/use-cases)' section showcases the key functionalities in four use cases;
* The '[detailed descriptions](/version-2.2/detailed-descriptions)' section explains the in-depth Functional, Technical, Legal and Operational agreements that, together, improve data-sharing;
* The Trust Framework concludes with the '[glossary and legal notices](/version-2.2/glossary-and-legal-notices)' section;

Within the iSHARE Trust Framework documentation, the following notational conventions apply:

* The keywords 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in IETF [RFC 2119](http://www.ietf.org/rfc/rfc2119.txt) whenever this note is at the top of the chapter:
  * *This part of the iSHARE Trust Framework is considered normative and is therefore compliant with RFC 2119.*


# Goals and scope of the iSHARE Trust Framework

The iSHARE Trust Framework is a collaborative effort to improve the exchange of data between organisations in and across data spaces. The Framework results in a set of agreements which improve circumstances for data exchange.

The ambition of iSHARE is to lower barriers for sharing data, to empower new forms of collaboration between organisations and to help scale up existing initiatives that aim to improve conditions for data exchange. The underlying assumption is that if data can flow in a controlled and smart way, it will lead to a more efficient use of infrastructure, less carbon emissions and more competitiveness.

The Trust Framework's scope focuses on three main topics that are crucial in any data exchange context:

1. [Identification;](/version-2.2/glossary-and-legal-notices/glossary#glossary-identificationidentification)
2. [Authentication](/version-2.2/glossary-and-legal-notices/glossary#glossary-authenticationauthentication);
3. [Authorisation](/version-2.2/glossary-and-legal-notices/glossary#glossary-authorisationauthorization).

iSHARE focuses on these three aspects as they are considered indispensable in any communication between parties, also in the context of exchanging logistical data. Within the Trust Framework, agreements are made on the above three topics with the aim of working towards a more uniform, straightforward and controlled way of exchanging data on a bigger scale than is possible right now\*.

* Uniform: one uniform way of working across all types of modalities, small and large organisations, public and private organisations, suppliers and receivers of data or their software partners, etc. iSHARE aims to create new possibilities for efficiency improvements, time gains and cost savings.
* Straightforward: Easy to connect with new, existing and third-party business partners throughout the sector, more certainty on trustworthiness of parties you exchange data with, a building block which is easy to implement by your software partners or your IT department and an addition that empowers your existing solutions.
* Controlled: The basic principle within iSHARE is that the owner of the data stays in control at all times; the owner decides with whom what data is exchanged and on what terms.

These three aims can only be reached when a variety of perspectives are considered during the establishment of the Framework. To this end, a variety of organisations are involved in defining the agreements for iSHARE.

{% hint style="info" %}

* The scope of the iSHARE Trust Framework does not include the specification of possible business models for sharing data and/or payments related to data exchange;
* The iSHARE Trust Framework can in some way be compared with the institute of the passport: the Trust Framework will be usable by anyone who owns a digital identity compatible with the framework. This will greatly simplify authentication and authorisation processes, also between different organisations (however: even though organisations can have valid certificates, it does not rule out possible malign intentions).
  {% endhint %}


# Guiding principles

To achieve the goals of the iSHARE Trust Framework, it is paramount to stay close to a set of guiding principles. As time progresses new principles can be defined, existing principles can be adapted or dropped if deemed necessary. The guiding principles were defined using the format as suggested\* by [TOGAF 9.2 architectural principles](https://pubs.opengroup.org/architecture/togaf9-doc/arch/).

The following principles define the Trust Framework and must be kept in mind at all times during further development (see details of guiding principles below):

<table><thead><tr><th width="135">Principle #</th><th>Principle name</th></tr></thead><tbody><tr><td><strong>1</strong></td><td>Generic building block to enable data exchange</td></tr><tr><td><strong>2</strong></td><td>Limited scope: identification, authentication, and authorisation</td></tr><tr><td><strong>3</strong></td><td>Leverage existing (international) building blocks</td></tr><tr><td><strong>4</strong></td><td>Agnostic towards nature and content of data</td></tr><tr><td><strong>5</strong></td><td>Benefits outweigh investment for all types of participants</td></tr><tr><td><strong>6</strong></td><td>International orientation</td></tr></tbody></table>

## Guiding principles details

<table data-header-hidden><thead><tr><th width="198"></th><th>Generic building block to enable data exchange</th></tr></thead><tbody><tr><td><strong>Principle 1</strong></td><td><strong>Generic building block to enable data exchange</strong></td></tr><tr><td><strong>Statement</strong></td><td>iSHARE provides a generic identification, authentication and authorisation Trust Framework to be used as enabler for data exchange.</td></tr><tr><td><strong>Rationale</strong></td><td>In every exchange of data, identification, authentication and authorisation are fundamental factors. iSHARE aims to simplify processes of identification, authentication and authorisation as a generic solution to facilitate data exchange.</td></tr><tr><td><strong>Implications</strong></td><td><ul><li>The Framework will allow for extension or adaptability so it can be used in situation/sector specific cases;</li><li>The Framework will not cater to a specific sector or market, it is applicable in an N amount of cases;</li><li>The Framework will not be a point solution.</li></ul></td></tr></tbody></table>

<table data-header-hidden><thead><tr><th width="200"></th><th></th></tr></thead><tbody><tr><td><strong>Principle 2</strong></td><td><strong>Limited scope: identification, authentication, and authorisation</strong></td></tr><tr><td><strong>Statement</strong></td><td>The iSHARE Trust Framework's scope is limited to topics of identification, authentication and authorisation in the context of data exchange</td></tr><tr><td><strong>Rationale</strong></td><td>iSHARE aims to improve the circumstances for data exchange and provides focus on the topic of identification, authentication and authorisation. Identification, authentication and authorisation are a fundamental part of any data exchange, but are not solved in a scalable or standardised way at the moment.</td></tr><tr><td><strong>Implications</strong></td><td><ul><li>Without this principle, there is a risk of 'scope creep': related topics could take away the focus off the intended topics</li></ul></td></tr></tbody></table>

<table data-header-hidden><thead><tr><th width="201"></th><th></th></tr></thead><tbody><tr><td><strong>Principle 3</strong></td><td><strong>Leverage existing (international) building blocks</strong></td></tr><tr><td><strong>Statement</strong></td><td>Where possible, iSHARE Trust Framework should be realised using existing and proven standards, technology or initiatives</td></tr><tr><td><strong>Rationale</strong></td><td>By reusing building blocks already available and in use, the impact on organisations to participate in the iSHARE network and the time to adopt the iSHARE Trust Framework are lowered. Standards, technology and initiatives preferably have a broad (international) usage base and are backed by a professional organisation charged with maintenance of the standards, technology or initiatives.</td></tr><tr><td><strong>Implications</strong></td><td><ul><li>the Framework will build on or use existing (international) standards, technology or initiatives where possible;</li><li>the Framework will aim to use open standards, technology or initiatives;</li><li>the Framework may use proprietary standards, technology or initiatives;</li><li>if existing and/or proven standards, technology or initiatives do not provide what is needed, alternative solutions will be sought.</li></ul></td></tr></tbody></table>

<table data-header-hidden><thead><tr><th width="202"></th><th></th></tr></thead><tbody><tr><td><strong>Principle 4</strong></td><td><strong>Agnostic towards nature and content of data</strong></td></tr><tr><td><strong>Statement</strong></td><td>The iSHARE Trust Framework does not concern itself with the contents or nature of data</td></tr><tr><td><strong>Rationale</strong></td><td>Given the generic nature of the iSHARE Trust Framework and the aim to be applicable throughout any sector, it needs to function with any type of possible data and/or any relevant data exchange interaction model. To this end, the contents of data are only considered where it concerns the facilities needed within iSHARE to adequately exchange various types of data (e.g. requirements to security, encryption, etc.). It is up to the participating organisations to ensure that iSHARE adequately fulfils requirements to the process of identification, authentication and authorisation in the context of data exchange.</td></tr><tr><td><strong>Implications</strong></td><td><ul><li>the Framework will not specify the (allowed) content of data exchanges done within a data space( iSHARE context);</li><li>the Framework does not specify content specific data standards;</li><li>the Framework should not have limitations connected to types of data or standards used.</li></ul></td></tr></tbody></table>

<table><thead><tr><th width="203"></th><th></th></tr></thead><tbody><tr><td><strong>Principle 5</strong></td><td><strong>Benefits outweigh investment for all types of participants</strong></td></tr><tr><td><strong>Statement</strong></td><td>The iSHARE Trust Framework needs to be attractive to use and implement for all types of participants/roles in the data space.</td></tr><tr><td><strong>Rationale</strong></td><td>The iSHARE Trust Framework knows different roles with different responsibilities. When a potential participant considers taking a (or multiple) role(s) in the data space, the framework should aim to have the lowest possible threshold to participate for the potential participant. Depending on what the character of the potential participant is (e.g smaller size or larger size organisations) and which role the participant wants to take, this could mean that the impact of implementation needs to be small or that the implementation is kept relatively simple.</td></tr><tr><td><strong>Implications</strong></td><td><ul><li>the framework aims to keep thresholds to participate in the data space (e.g. in terms of implementation impact or onboarding/certification effort) as low as possible for all possible roles;</li><li>the framework strives for the lowest possible impact for participants when changes occur in the future. Changes to used standards will take place; within the framework and its specifications thought needs to be given to how change is dealt with in an efficient way.</li></ul></td></tr></tbody></table>

<table data-header-hidden><thead><tr><th width="204"></th><th></th></tr></thead><tbody><tr><td><strong>Principle 6</strong></td><td><strong>International orientation</strong></td></tr><tr><td><strong>Statement</strong></td><td>The iSHARE Framework needs to look over geographic and sector boundaries to foster international involvement and cooperation</td></tr><tr><td><strong>Rationale</strong></td><td>Every sector is per definition an international sector. The iSHARE Trust Framework needs to facilitate, to the extent that it is practical and possible, international involvement.</td></tr><tr><td><strong>Implications</strong></td><td><ul><li>the Framework needs its participants to provide knowledge and experience on how it can can stay (and become) attractive in the international context.</li></ul></td></tr></tbody></table>

\*Format used for defining guiding principles, based on TOGAF standard:

<table data-header-hidden><thead><tr><th width="203"></th><th></th></tr></thead><tbody><tr><td><strong>Principle name</strong></td><td>Should both represent the essence of the rule as well as be easy to remember. Specific technology platforms should not be mentioned in the name or statement of a principle. Avoid ambiguous words in the Name and in the Statement such as: 'support', 'open', 'consider', and for lack of good measure the word 'avoid', itself, be careful with 'manage(ment)', and look for unnecessary adjectives and adverbs (fluff).</td></tr><tr><td><strong>Statement</strong></td><td>Should succinctly and unambiguously communicate the fundamental rule. For the most part, the principles statements for managing information are similar from one organisation to the next. It is vital that the principles statement be unambiguous.</td></tr><tr><td><strong>Rationale</strong></td><td>Should highlight the business benefits of adhering to the principle, using business terminology. Point to the similarity of information and technology principles to the principles governing business operations. Also describe the relationship to other principles, and the intentions regarding a balanced interpretation. Describe situations where one principle would be given precedence or carry more weight than another for making a decision.</td></tr><tr><td><strong>Implications</strong></td><td>Should highlight the requirements, both for the business and IT, for carrying out the principle - in terms of resources, costs, and activities/tasks. It will often be apparent that current systems, standards, or practices would be incongruent with the principle upon adoption. The impact to the business and consequences of adopting a principle should be clearly stated. The reader should readily discern the answer to: 'How does this affect me?' It is important not to oversimplify, trivialise, or judge the merit of the impact. Some of the implications will be identified as potential impacts only, and may be speculative rather than fully analysed.</td></tr></tbody></table>


# Governance

The iSHARE Trust Framework describes the Governance as follows. The Scheme Owner is the main body involved in the maintenance of the iSHARE Trust Framework.The governance consists of the following bodies. See below for detailed descriptions:

* the iSHARE Foundation, which is the Scheme Owner
* the Executive Board
* the Supervisory Board
* the Council of Participants
* the Change Advisory Board
* the Council of Sponsors

The governance is organised as such that the iSHARE network can operate and grow in a sustainable way. At the same time it provides the appropriate checks and balances that will allow Participants to provide input, supervise ongoing activities and collaboratively influence the growth and development of the iSHARE Trust Framework.Rules about the foundation’s organisation and its governance framework are captured in the statutes of the iSHARE Foundation. The iSHARE Foundation is listed in the Commercial Register (Handelsregister) in the Netherlands maintained by the Chamber of Commerce (Kamer van Koophandel) under registration number 73058289.

<figure><img src="https://ishare.eu/wp-content/uploads/2021/11/iSHARE.Governance.png" alt=""><figcaption></figcaption></figure>

The above figure describes the governance in the Trust Framework. L/O - Legal/Operational. F/T - Functional/Technical.

### Scheme Owner <a href="#governance-schemeowner" id="governance-schemeowner"></a>

The iSHARE Foundation is the Scheme Owner of the iSHARE Trust Framework and is responsible for all activities related to the iSHARE Trust Framework. The iSHARE Scheme Owner consists of:

* An **Executive Board** formed by (an) independent representative(s) of the iSHARE community. Executive board members are selected and chosen by the Supervisory Board. The Executive Board is the highest organ of the Scheme Owner. Executive board members are accountable to the Supervisory Board for the functioning of the iSHARE Foundation and the iSHARE Trust Framework.
* An **operational branch** responsible for day to day management activities. These activities include (amongst others) the following responsibilities:
  * Management of the iSHARE Trust framework (specifications + brand management and marketing);
  * Development and maintenance of tools;
  * Maintenance of the Participant Registry (old term: Satellite);
  * Addition of new data spaces.

### Sponsor(s) <a href="#governance-sponsor-s" id="governance-sponsor-s"></a>

The iSHARE Foundation can receive funding from government and semi-public organisations that wish to support the realisation of the goals of the Foundation. Upon request of such an organisation, the Supervisory Board can decide to grant the organisation the status of Sponsor of the iSHARE Foundation. The organisation maintains the status of Sponsor for the duration that it provides funding to the iSHARE Foundation.

### Supervisory Board <a href="#governance-supervisoryboard" id="governance-supervisoryboard"></a>

* The Supervisory Board is appointed by the Council of Participants and consists of three members
  * One member of the Supervisory Board may be appointed by the Sponsor(s), rather than the Council of Participants, if there are Sponsor(s) present.
* The Supervisory Board supervises the correct functioning of the iSHARE Foundation's Executive Board and elects/dismisses the members of the Executive Board.

The Supervisory Board transferred Scheme Owner activities to the iSHARE Foundation.

### Council of Participants <a href="#governance-councilofparticipants" id="governance-councilofparticipants"></a>

* The Council of Participants consists of all Parties (or representations of these parties) that have a contract with the Scheme Owner/ individual data space and are willing to participate in the Council of Participants' activities.
* The Council of Participants advises the iSHARE Foundation and appoints members of the Supervisory Board.

### Change Advisory Board <a href="#governance-changeadvisoryboard" id="governance-changeadvisoryboard"></a>

* The Change Advisory Board consists of subject matter experts (legal/ operational/ functional/ technical) delegated by the Participants and Data Space Governance Bodies.
* The Change Advisory Board advises the Scheme Owner on changes to the specifications of the iSHARE Trust Framework.


# Releases

This chapter describes the release notes, planning of future releases and version history of the iSHARE Trust Framework.

* [Release notes](/version-2.2/releases/release-notes)
* [Release planning](/version-2.2/releases/release-planning)
* [Version history](/version-2.2/releases/version-history)


# Release notes

The release notes show the release history and the main differences between releases.

<table><thead><tr><th width="225">Release 2.2</th><th></th></tr></thead><tbody><tr><td>Purpose</td><td><ul><li>Improve interoperability among global data ecosystems</li></ul></td></tr><tr><td>Release date</td><td>13 June 2025</td></tr><tr><td>Change log</td><td><p>All included RFCs are available <a href="https://gitlab.com/groups/ishare-foundation/cab/-/issues/?label_name%5B%5D=Release%202.2">here</a>.</p><p><strong>Functional</strong></p><ul><li>Improved iSHARE licenses and release dedicated licenses portal on https://licenses.ishare.eu</li></ul><p><strong>Technical</strong></p><ul><li>Added create and update specifications for managing parties at Participant Registry</li></ul><p><strong>Legal</strong></p><ul><li>Updates to license agreements</li></ul></td></tr></tbody></table>

| Release 2.1.1 |                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            |
| ------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Purpose       | <ul><li>Update links to OpenAPI specifications</li><li>Update relevant endpoints to support new party identifcation model.</li></ul>                                                                                                                                                                                                                                                                                                                                                                                                                                                                       |
| Release date  | 5 January 2026                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                             |
| Change log    | <ul><li>Party-related identifiers have been standardised by replacing partyId with id and alsoKnownAs across relevant endpoints, examples, and schemas to improve consistency and readability.</li><li>The Dataspace endpoint now supports defaultParticipantIdentifierName and defaultParticipantIdentifierPrefix, allowing data spaces to explicitly declare their default participant identifier (defaulting to ishare:did when not specified).</li><li>The User Info and id\_token endpoint now includes clearer examples and the required organisationIdentifier (ETSI/X.509 OID 2.5.4.97).</li></ul> |

<table><thead><tr><th width="225">Release 2.1</th><th></th></tr></thead><tbody><tr><td>Purpose</td><td><ul><li>Introduction of iSHARE-ID to enhance interoperability.</li><li>Update of terminology.</li><li>Introduction of standardised delegation creation requests.</li><li>Respecification of the /capabilities endpoint.</li><li>Decommissioning of PKIOverheid certificates.</li><li>Alternative onboarding for service consumers without PKI certificates.</li></ul></td></tr><tr><td>Release date</td><td>7 March 2025</td></tr><tr><td>Change log</td><td><p>All included RFCs are available <a href="https://gitlab.com/groups/ishare-foundation/cab/-/issues/?label_name%5B%5D=Release%202.1">here</a>.</p><p><strong>Functional</strong></p><ul><li>Supporting multiple identifiers and Introduction of iSHARE-ID</li><li>Updated terminology (Data Space Governance Body and Participant Registry)</li><li>Standardised delegation requests</li></ul><p><strong>Technical</strong></p><ul><li>Multiple party identifiers and iSHARE DID Method</li><li>Respecification of /capabilities endpoint</li><li>Onboarding service consumers without PKI certificates</li></ul><p><strong>Operational</strong></p><ul><li>Updated onboarding processes</li><li>Decommissioning PKIOverheid certificates</li><li>Addition of Brand Guidelines to UI Guidelines</li></ul><p><strong>Legal</strong></p><ul><li>Updates to legal agreements</li></ul></td></tr></tbody></table>

<table><thead><tr><th width="225">Release 2.0.1</th><th></th></tr></thead><tbody><tr><td>Purpose</td><td><ul><li>Release of new framework website</li></ul></td></tr><tr><td>Release date</td><td>3 July 2024</td></tr><tr><td>Change log</td><td><ul><li>Minor typo's only</li><li>All content has been copied to the new framework website</li></ul></td></tr></tbody></table>

<table><thead><tr><th width="225">Release 2.0</th><th></th></tr></thead><tbody><tr><td>Purpose</td><td><ul><li>Updated Roles</li><li>Updated Governance structure</li><li>Distinction and clarity in roles and governance</li><li>Updates in operational and functional processes</li></ul></td></tr><tr><td>Release Date</td><td>30 October 2023</td></tr><tr><td>Change log</td><td><p><strong>Introduction</strong></p><ul><li>Scheme is now known as iSHARE Trust Framework</li><li>Updated goals, scope, guiding principles and governance.</li><li>Federation of Trust Framework</li></ul><p><strong>Functional</strong></p><ul><li>Added new role: Satellite</li><li>Scheme administrator is now Satellite administrator</li><li>Minor fixes in key functionality</li></ul><p><strong>Technical</strong></p><ul><li>Updated Satellite role</li><li>Review of technical standards and minor fixes</li></ul><p><strong>Legal</strong></p><ul><li>Updated Satellite role</li><li>Updated Accession agreement and Terms of Use</li></ul><p><strong>Operational</strong></p><ul><li>New role - Satellite</li><li>Updated the operational processes of admission, withdrawal and incident management processes</li><li>Updated the service levels.</li></ul></td></tr></tbody></table>

<table><thead><tr><th width="225">Release 1.11</th><th></th></tr></thead><tbody><tr><td>Purpose</td><td><ul><li>Updated legal documents</li><li>Added new role: Scheme Administrator</li><li>Updated Governance structure</li><li>Small technical improvements</li></ul></td></tr><tr><td>Release date</td><td>16 November 2020</td></tr><tr><td>Change log</td><td><p><strong>Functional</strong></p><ul><li>Added new role: Scheme Administrator</li><li><p></p><ul><li>Participant admission process</li><li>Governance</li><li>Scheme trust model</li></ul></li><li>Human authorization for IDPs is now optional and no longer mandatory</li></ul><p><strong>Technical</strong></p><ul><li>Human authorization for IDPs is now optional and no longer mandatory. The associated CTT tests are no longer a requirement for certification.</li><li>Scheme administrators added and new attributes added to:</li><li><p></p><ul><li>Track which SA is responsible for the participant</li><li>Express the level of adherence of the participant.</li></ul></li></ul><p><strong>Operational</strong></p><ul><li>Updated the admission process for Scheme Administrator:</li><li><p></p><ul><li>Admission of Scheme Administrator</li><li>Withdrawal of Scheme Administrator</li></ul></li><li><p>Updated the admission process for Parties:</p><ul><li>Admission through Scheme Administrator</li><li>reassignment of Scheme Administrator</li></ul></li><li>Governance structure changed to reflect the transition from project phase</li><li>Added process of determining yearly participation fees.</li></ul><p><strong>Legal</strong></p><p>Updates:</p><ul><li>Updated the Terms of Use to reflect the fact that Adhering Parties and Certified Parties are subject to an annual fee, added article 11 “Participation Fee” and updated the links to the Annexes.</li><li>Updated the Accession Agreement for Certified Parties to reflect the fact that Certified Parties are subject to an annual fee.</li><li>Updated the Accession Agreement for Adhering Parties to reflect the fact that Adhering Parties are subject to an annual fee.</li><li>Renewed the standard NDA due to reflect the relation between the iSHARE foundation, Scheme Owner and Adoption.</li></ul></td></tr></tbody></table>

<table><thead><tr><th width="225">Release 1.10</th><th></th></tr></thead><tbody><tr><td>Purpose</td><td><ul><li>Updated the process for verifying eIDAS certificates</li><li>Update the admission process for Certified Parties</li><li>Added levels of assurance for Certified Parties</li><li>Added support for the usecase where the Entitled Party is not an iSHARE Adhering Party, but is a customer of an iSHARE Service Provider</li><li>Small technical improvements</li></ul></td></tr><tr><td>Release date</td><td>24 June 2019</td></tr><tr><td>Change log</td><td><p><strong>Functional</strong></p><ul><li>Updated the functional requirements for Certified Parties (references to eHerkenning have been removed and replaced by relevant requirements)</li></ul><p><strong>Technical</strong></p><ul><li>Updated the process for verifying eIDAS certificates (now uses the same process as PKI-Overheid certificates)</li><li>Added level of assurance to the Party Info endpoint at the Scheme Owner (for Certified Parties)</li><li>Clarified the use of acr_values in the H2M flow to request a minimal level of assurance</li><li>Clarified the headers used for JWE in the H2M flow</li></ul><p><strong>Operational</strong></p><ul><li><p>Updated the admission process for Certified Parties, including the following changes:</p><ul><li>Admission to eHerkenning is no longer required</li><li>Added the concept of Levels of Assurance for Certified Parties</li><li>Added the Assessment Framework for Certified Parties to determine the Level of Assurance of a Certified Party</li></ul></li></ul><p><strong>Legal</strong></p><ul><li>Updated the terms of use to reflect the usecase where the Entitled Party is not an iSHARE Adhering Party, but is a customer of an iSHARE Service Provider</li></ul></td></tr></tbody></table>

<table><thead><tr><th width="225">Release 1.9</th><th></th></tr></thead><tbody><tr><td>Purpose</td><td>Enable Human to Machine (H2M) authorisations</td></tr><tr><td>Release date</td><td>5 April 2019</td></tr><tr><td>Change log</td><td><p><strong>Functional:</strong></p><ul><li>Updated primary Human to Machine use cases to reflect changes from RFC 010, which added the authorization flow to these cases</li></ul><p><strong>Technical:</strong></p><ul><li>Added technical specifications on the generic authorization flow for Human to Machine (H2M) interactions as facilitated by Identity Providers in the iSHARE Scheme, to reflect changes from RFC 010</li><li>Modified technical specifications for capabilities endpoint of all iSHARE Parties</li></ul><p><strong>Operational</strong></p><ul><li>No changes</li></ul><p><strong>Legal</strong></p><ul><li>Updated governance framework to reflect that Stichting iSHARE Foundation has been created</li></ul><p><strong>Miscellaneous</strong></p><ul><li>Rearranged pages and sections to improve readability</li><li>Material has been moved from the Scheme to the Developer Portal, to improve readability and usability of both</li></ul></td></tr></tbody></table>

<table><thead><tr><th width="225">Release 1.8</th><th></th></tr></thead><tbody><tr><td>Purpose</td><td>Enable Human to Machine (H2M) interactions and finalise contracts for signing between iSHARE Foundation and iSHARE Participants.</td></tr><tr><td>Release date</td><td>31 October 2018</td></tr><tr><td>Change log</td><td><p><strong>Functional:</strong></p><p>-</p><p><strong>Technical:</strong></p><ul><li>Added technical specifications on the generic authentication flow for Human to Machine (H2M) interactions as facilitated by Identity Providers in the iSHARE Scheme.</li></ul><p><strong>Operational</strong></p><p><strong>-</strong></p><p><strong>Legal</strong></p><ul><li>Minor modifications to Terms of Use and the Accession Agreements for Adhering Paries and Certified Parties</li><li>Moved GDPR Factsheet and templates for Data Exchange Agreement and Data Processor Agreements to appendix of the scheme, since they serve merely as an inspiration for participants who want to make additional bilateral arrangements with others they are sharing data with.</li></ul><p><strong>Miscellaneous</strong></p><ul><li>The governance framework is updated</li><li>Rearranged pages and sections to improve readability</li></ul></td></tr></tbody></table>

<table><thead><tr><th width="225">Release 1.7</th><th></th></tr></thead><tbody><tr><td>Purpose</td><td>Create a better overview of all API specs in a singular space, to make it easier for developers to implement iSHARE and to improve readability of the iSHARE Scheme</td></tr><tr><td>Release date</td><td>28 June 2018</td></tr><tr><td>Change log</td><td><p><strong>Functional:</strong></p><p>-</p><p><strong>Technical:</strong></p><ul><li>The API technical specifications are moved to a dedicated developer portal.</li><li>Adjusted specification for JSON Web Token (JWT) to facilitate certificate validation under eIDAS.</li></ul><p><strong>Operational</strong></p><ul><li>The service levels are now structured per participant type (Adhering Party/ Certified Party/ Scheme Owner) to give participants a better overview of their applicable service levels.</li></ul><p><strong>Legal</strong></p><p>-</p><p><strong>Miscellaneous</strong></p><ul><li>Rearranged pages and sections to improve readability</li><li>The governance framework is updated</li><li>The project history is updated</li></ul></td></tr></tbody></table>

<table><thead><tr><th width="225">Release 1.6</th><th></th></tr></thead><tbody><tr><td>Purpose</td><td>Lowering barriers for parties to start using iSHARE</td></tr><tr><td>Release date</td><td>11 May 2018</td></tr><tr><td>Change log</td><td><p><strong>Functional:</strong></p><p>-</p><p><strong>Technical:</strong></p><ul><li>For authentication purposes the use of digital certificates within iSHARE will be limited initially to certificates issued under PKIOverheid.</li></ul><p><strong>Operational</strong></p><ul><li>The admission process for Certified Parties and Adhering Parties are merged to one generic process. Role-specific requirements may apply.</li><li>The order of admission steps is changed to enable new iSHARE entrants to start testing before a contract is signed.</li></ul><p><strong>Legal</strong></p><p>-</p><p><strong>Miscellaneous</strong></p><ul><li>Rearranged pages and sections to improve readability</li><li>The governance framework is updated</li></ul></td></tr></tbody></table>

<table><thead><tr><th width="225">Release 1.5</th><th></th></tr></thead><tbody><tr><td>Purpose</td><td>First public version the iSHARE Scheme that can be used by launching customers</td></tr><tr><td>Release date</td><td>14 December 2017</td></tr><tr><td>Change log</td><td><ul><li>Updated specifications for all content of the iSHARE Scheme:</li><li><p></p><ul><li>Functional</li><li>Technical</li><li>Operational</li><li>Legal</li></ul></li><li>Significantly updated and rearranged sections for readability, including a <a href="/pages/11tBwMlfPJrRXlhlwCfd">main scheme aspects</a>- and illustrative <a href="/pages/7EdDuMW5nHCHrGoGyb3v">use cases</a> chapter with new depictions; Integrated (technical) specifications, generic and per iSHARE role</li></ul></td></tr></tbody></table>


# Release planning

The release planning provides detailed information about changes that are planned for future releases of the Framework. See the [Change Management](/version-2.2/detailed-descriptions/operational/operational-processes/change-management) section for details about the change management process of the iSHARE Trust Framework.

### **Planned releases** <a href="#releaseplanning-plannedreleases" id="releaseplanning-plannedreleases"></a>

Version 2.2 is now live. Further updates and harmonisation of terms is underway. [More details on upcoming changes](https://gitlab.com/ishare-foundation/cab/rfc/-/boards).

The RFCs for this release have been discussed in the CAB meetings.

### **Suggestions** <a href="#releaseplanning-suggestions" id="releaseplanning-suggestions"></a>

If you have any other suggestions to improve the iSHARE Trust Framework, please let us know. The Request For Change procedures can be submitted and processed [here](https://gitlab.com/ishare-foundation/cab/rfc).

Additionally, if you would like to participate in the CAB, please [contact iSHARE Foundation](https://ishare.eu/contact/).


# Version history

* [iSHARE v2.1.1](/version-2.1.1), 5 January 2026
* [iSHARE v2.1](/version-2.1), 7 March 2025
* [iSHARE v2.0.1](https://gitlab.com/ishare-foundation/cab/ishare-trust-framework/-/blob/2.2/.gitbook/assets/iSHARE-Framework-2.0.1.pdf), 3 July 2024
* [iSHARE v2.0](https://gitlab.com/ishare-foundation/cab/ishare-trust-framework/-/blob/2.2/.gitbook/assets/iSHARE%20Framework%20v2.0.pdf), 30 October 2023
* [iSHARE v1.11](https://gitlab.com/ishare-foundation/cab/ishare-trust-framework/-/blob/2.2/.gitbook/assets/2775482429.pdf), 16 November 2020
* [iSHARE v1.10](https://gitlab.com/ishare-foundation/cab/ishare-trust-framework/-/blob/2.2/.gitbook/assets/722173953.pdf), 24 June 2019
* [iSHARE v1.9](https://gitlab.com/ishare-foundation/cab/ishare-trust-framework/-/blob/2.2/.gitbook/assets/628392034.pdf), 5 April 2019
* [iSHARE v1.8](https://gitlab.com/ishare-foundation/cab/ishare-trust-framework/-/blob/2.2/.gitbook/assets/332660850.pdf), 31 October 2018
* [iSHARE v1.7](https://gitlab.com/ishare-foundation/cab/ishare-trust-framework/-/blob/2.2/.gitbook/assets/109182985.pdf), 28 June 2018
* [iSHARE v1.6](https://gitlab.com/ishare-foundation/cab/ishare-trust-framework/-/blob/2.2/.gitbook/assets/70229595.pdf), 11 May 2018
* [iSHARE v1.5](https://gitlab.com/ishare-foundation/cab/ishare-trust-framework/-/blob/2.2/.gitbook/assets/70229563.pdf), 14 December 2017
* [iSHARE v1.2](https://gitlab.com/ishare-foundation/cab/ishare-trust-framework/-/blob/2.2/.gitbook/assets/70227913.pdf), 25 October 2017
* [iSHARE v1.0](https://gitlab.com/ishare-foundation/cab/ishare-trust-framework/-/blob/2.2/.gitbook/assets/70226334.pdf), 23 June 2017
* [iSHARE v0.5](https://gitlab.com/ishare-foundation/cab/ishare-trust-framework/-/blob/2.2/.gitbook/assets/70223171.pdf), 24 March 2017
* [iSHARE v0.3](https://gitlab.com/ishare-foundation/cab/ishare-trust-framework/-/blob/2.2/.gitbook/assets/70228182.pdf), 27 February 2017
* [iSHARE v0.2](https://gitlab.com/ishare-foundation/cab/ishare-trust-framework/-/blob/2.2/.gitbook/assets/70223244.pdf), 13 February 2017
* [iSHARE v0.1](https://gitlab.com/ishare-foundation/cab/ishare-trust-framework/-/blob/2.2/.gitbook/assets/70223607.pdf) (start document)


# Main aspects of the iSHARE Trust Framework

The iSHARE Trust Framework is a combination of Functional, Technical, Operational and Legal agreements to which participating parties adhere. This chapter provides a bird's eye view on the main aspects of iSHARE specifications, and an introduction to more in depth details of the Trust Framework.

This section describes the Trust Framework's:

* [Key functionality](/version-2.2/main-aspects-of-the-ishare-trust-framework/key-functionality)
  * [Support Machine to Machine (M2M) interaction](/version-2.2/main-aspects-of-the-ishare-trust-framework/key-functionality/support-machine-to-machine-m2m-interaction)
  * [Support Human to Machine (H2M) interaction](/version-2.2/main-aspects-of-the-ishare-trust-framework/key-functionality/support-human-to-machine-h2m-interaction)
  * [Facilitate portable identity(s) for parties and humans](/version-2.2/main-aspects-of-the-ishare-trust-framework/key-functionality/facilitate-portable-identity-s-for-parties-and-humans)
  * [Facilitate flexible authorizations, applicable in any context](/version-2.2/main-aspects-of-the-ishare-trust-framework/key-functionality/facilitate-flexible-authorizations-applicable-in-any-context)
  * [Enable data exchange based on delegations - even between unknown parties](/version-2.2/main-aspects-of-the-ishare-trust-framework/key-functionality/enable-data-exchange-based-on-delegations-even-between-unknown-parties)
  * [Enable control over own data through management of consent](/version-2.2/main-aspects-of-the-ishare-trust-framework/key-functionality/enable-control-over-own-data-through-management-of-consent)
  * [Provide a Trust Framework](/version-2.2/main-aspects-of-the-ishare-trust-framework/key-functionality/provide-a-trust-framework)
* [Technical overview](/version-2.2/main-aspects-of-the-ishare-trust-framework/technical-overview)
* [Framework and roles](/version-2.2/main-aspects-of-the-ishare-trust-framework/framework-and-roles)
* [Legal provisions](/version-2.2/main-aspects-of-the-ishare-trust-framework/legal-provisions)
* [Operational provisions](/version-2.2/main-aspects-of-the-ishare-trust-framework/operational-provisions)


# Key functionality

The iSHARE Trust Framework aims to support the following key functionalities:

* [Support Machine to Machine (M2M) interaction](/version-2.2/main-aspects-of-the-ishare-trust-framework/key-functionality/support-machine-to-machine-m2m-interaction)
* [Support Human to Machine (H2M) interaction](/version-2.2/main-aspects-of-the-ishare-trust-framework/key-functionality/support-human-to-machine-h2m-interaction)
* [Facilitate portable identity(s) for parties and humans](/version-2.2/main-aspects-of-the-ishare-trust-framework/key-functionality/facilitate-portable-identity-s-for-parties-and-humans)
* [Facilitate flexible authorizations, applicable in any context](/version-2.2/main-aspects-of-the-ishare-trust-framework/key-functionality/facilitate-flexible-authorizations-applicable-in-any-context)
* [Enable data exchange based on delegations - even between unknown parties](/version-2.2/main-aspects-of-the-ishare-trust-framework/key-functionality/enable-data-exchange-based-on-delegations-even-between-unknown-parties)
* [Enable control over own data through management of consent](/version-2.2/main-aspects-of-the-ishare-trust-framework/key-functionality/enable-control-over-own-data-through-management-of-consent)
* [Provide a Trust Framework](/version-2.2/main-aspects-of-the-ishare-trust-framework/key-functionality/provide-a-trust-framework)

In line with iSHARE' Trust Framework's [guiding principles](/version-2.2/introduction/guiding-principles), these key functionalities might be realised by (re)using existing standards or initiatives.


# Support Machine to Machine (M2M) interaction

The iSHARE Trust Framework aims to support multiple interaction models, of which Machine to Machine (M2M) is one. M2M interaction can be characterised as communication between machines, without interference by a human. In contemporary data communication there is a heavy reliance on M2M interaction.

Example:

* Every day, the ERP system (machine) of party A requests a status update from the ERP system (machine) of party B. Party B's ERP system automatically responds with the requested status update. No humans are needed to interfere.

This example is detailed under [use cases](/version-2.2/use-cases).

The opposite of the M2M interaction model is the [Human to Machine interaction model](/version-2.2/main-aspects-of-the-ishare-trust-framework/key-functionality/support-human-to-machine-h2m-interaction).


# Support Human to Machine (H2M) interaction

The iSHARE Trust Framework aims to support multiple interaction models, of which Human to Machine (H2M) is one. H2M interaction can be characterised as communication between a human and (a) machine(s). A user interface is necessary to enable H2M communication.

Example:

* Human X, working for Party A, requests a status update from the ERP system (machine) of Party B. It does so via a user interface.

This example is detailed under [use cases](/version-2.2/use-cases).

The opposite of the H2M interaction model is the [Machine to Machine interaction model](/version-2.2/main-aspects-of-the-ishare-trust-framework/key-functionality/support-machine-to-machine-m2m-interaction).


# Facilitate portable identity(s) for parties and humans

The iSHARE Trust Framework aims to facilitate (but not impose) the use of one or more so called 'federated identity(s)'. A federated identity is an identity that is spread out and recognised, i.e. portable, across multiple, independent systems.

Within iSHARE Trust Framework, the use of federated identities would reduce costs by eliminating the need for proprietary, or newly issued identity solutions. In order for an identity to become part of iSHARE's federation, the legal entity providing the identity must be certified under the iSHARE Trust Framework.

Example:

* Human X, working for Party A, has a personal keycard issued by iSHARE certified Identity Provider Y. The card, and thus the identity of Human X, can be used to identify and authenticate Human X at party B.

This example is detailed under [use cases](/version-2.2/use-cases).


# Facilitate flexible authorizations, applicable in any context

The iSHARE Trust Framework aims to enable parties to grant other parties or persons access to (parts of) their data or services. Parties within the iSHARE Trust Framework have greatly varying backgrounds, however. Private and public, large and small, different value chains, different geographies, different modalities, etc. For that reason there needs to have a flexible way of expressing authorizations.

Two examples can illustrate different levels of required flexibility:

1. Some parties or contexts require management of authorizations on a very detailed level, e.g. Party A's ERP system (machine) is ONLY allowed to request status updates concerning line X of bill of lading Y;
2. Some contexts require less detailed authorizations, e.g. Party A's ERP system (machine) is allowed to request ANY information about ANY (part of a) bill of lading.

Both examples are explained under use cases: [fine-grained](/version-2.2/use-cases/use-case-m2m-interaction-with-fine-grained-authorization); [coarse-grained](/version-2.2/use-cases/use-case-h2m-interaction-with-coarse-grained-authorization).

The iSHARE Trust Framework envisions a world in which (access) authorizations are flexible in three ways:

* Flexible authorization scope: iSHARE aims to provide a way to add a layer of authorization to any resource or any selection or combination of resources. The authorization scope refers to the objects or resources of a specific party, to which authorizations need to be assigned. The scope can include many or all resources (e.g. all data), or only some resources (e.g. specific data fields or services). Either way, the scope is always governed by a formal agreement and implemented by technical means.
* Granular authorizations: iSHARE aims to provide a granular way to use authorizations for resources. The authorization granularity refers to the characteristics of both the requested resources and the rules (policies, conditions) that apply. Authorizations to resources can be coarse-grained (e.g. someone has access to all data in a certain data scope) or fine-grained (e.g. someone has access to only data with a low sensitivity level). The rules (policies, conditions) that control the authorizations can be fine-grained as well, meaning that many different types of rules can apply, such as time of day, location, organisation, role, and competence level.
* Flexible authorization source: iSHARE aims to provide flexibility to where authorization rules are stored and can be retrieved. The authorization source refers to the location of the rules (policies, conditions) and the attributes (e.g. subject attributes, object attributes) that govern the authorizations. These can be located near the data, at a dedicated source, or a combination thereof. In the current version of the iSHARE Trust Framework, the flexibility in authorization source is described as 'Policy Information Point' or PIP in the [detailed functional descriptions](/version-2.2/detailed-descriptions/functional).


# Enable data exchange based on delegations - even between unknown parties

One of the barriers to exchanging data is often that parties do not know each other sufficiently, and therefore are not able to share data. Often this can only be done after some form of contract has been established.

Within the iSHARE network, it is the explicit aim to make it possible to exchange data for parties that are unknown to each other based on delegations. A delegation within iSHARE functions as evidence that a party is directly or indirectly operating in name of a known party. Based on the delegation a certain (unknown) party has given, a party can decide if this party may receive certain data or not.

Example:

* Party A hires Trucking Company B to deliver Container X to Party C. Trucking Company B's ERP system asks Party C's ERP system at what time it should deliver the container. Party C's ERP system does not know Trucking Company B, but can check the delegation to Trucking Company B that Party A has registered at Authorisation Registry D. Because this delegation is in order, Party C's ERP system shares a time slot with Trucking Company B's ERP.

This example is detailed under [use cases](/version-2.2/use-cases).


# Enable control over own data through management of consent

As described under key functionalities '[facilitate flexible authorisations](/version-2.2/main-aspects-of-the-ishare-trust-framework/key-functionality/facilitate-flexible-authorizations-applicable-in-any-context)' and '[enable data exchange based on delegations](/version-2.2/main-aspects-of-the-ishare-trust-framework/key-functionality/enable-data-exchange-based-on-delegations-even-between-unknown-parties)', the iSHARE Trust Framework aims to enable parties to grant other parties or persons access to (parts of) their data or services. At least as important is the aim to allow parties to modify or withdraw these access rights, to their data or services, whenever they wish. This is called management of consent, and enables full control over own data at any moment in time.

Example:

* In the example described under key functionality '[enable data exchange based on delegations](/version-2.2/main-aspects-of-the-ishare-trust-framework/key-functionality/enable-data-exchange-based-on-delegations-even-between-unknown-parties)', Party A hires Trucking Company B to deliver Container X to Party C. Trucking Company B's ERP system asks Party C's ERP system at what time it should deliver the container. Party C's ERP system does not know Trucking Company B, but can check the delegation to Trucking Company B that Party A has registered at Authorisation Registry D. Because this delegation is in order, Party C's ERP system shares a time slot with Trucking Company B's ERP.
  * Now imagine that moments before Trucking Company B's ERP system asks Party C's ERP system for a time slot, Party C revokes Party A's access to requesting a time slot. Consequently, Trucking Company B's request for a time slot gets an access forbidden message; Trucking Company B's request is NOT accepted because Party A, and therewith delegated Trucking Company B, is no longer authorised to ask for a time slot.

Party C, as showcased, remains in full control over its own data and services at any moment in time. This example is detailed under [use cases](/version-2.2/use-cases).


# Provide a Trust Framework

Within the iSHARE network, it is the explicit aim to define trust based on a synthesis between technological and legal aspects. In practical terms the aim is to let iSHARE participants interact within the network through a party that they know and trust (their Participant Registry) and sign one contract, on the basis of which they have a contract with all participants within the data space/iSHARE network. In other words, participants within the data space/iSHARE network do not need to sign separate contracts with each other to share data with each other (although they are free to define additional contracts that do not conflict with the iSHARE Trust Framework).

An important tool within the Trust Framework are licenses which define the conditions under which data can be exchanged or services can be consumed. For functional details on licenses, see the [Licenses page](/version-2.2/detailed-descriptions/functional/licenses).

The Trust Framework is depicted under [Primary use cases](/version-2.2/detailed-descriptions/functional/primary-use-cases) and needs appropriate technological underpinning so that parties can authenticate each other in a reliable way.


# Technical overview

The iSHARE Trust Framework can be characterised as an API (Application Programming Interface) architecture for identification, authentication and authorisation based on a modified version of the widely used OAuth and OpenID Connect standards. The APIs specified for every role enable standardised interaction between computer systems.

{% hint style="info" %}
**Important**

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 systems send 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.
{% endhint %}

The API architecture of the iSHARE Trust Framework also builds upon the following components:

* **PKI and digital certificates;** For the authentication of parties and machines, iSHARE uses PKI and digital certificates.
* **HTTP over TLS (HTTPS);** iSHARE uses the commonly used HTTP protocol for its communications, including TLS to encrypt the communications.
* **RESTful architectural style;** iSHARE uses the RESTful architectural style to structure APIs and HTTP calls.
* **JSON/JWT;** Data exchanged in the iSHARE context is structured using the JSON standard. Where non-repudiation is required, JWT's are used;
* **XACML.** Delegations are structured according to a JSON port of the XACML standard.

The combination of the above standards and protocols leads to a certain dynamic between the [roles in the Trust Framework](/version-2.2/main-aspects-of-the-ishare-trust-framework/framework-and-roles). In essence, Service Consumers acquire a token which allows them to access certain services from certain Service Providers. The roles specified in the Framework are loosely based on the OAuth standard.

For a full explanation and description of all APIs, standards and protocols, please refer to the [Developer Portal](https://dev.ishare.eu/).


# Framework and roles

The iSHARE Trust Framework aims to provide generic building blocks for service provision, widely applicable in most sectors. This requires that the Framework can be applied to the wide variety of use cases possible in practice. This chapter explains the framework, its roles, and its relations, step-by-step.

{% hint style="info" %}
**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.
{% endhint %}

The iSHARE Framework consists of six roles that, depending on the situation, interact with each other based on the Trust Framework agreements. A party can fulfill multiple roles at the same time. Each role has a certain function in the framework and bears certain responsibilities, as described below:

<figure><img src="/files/bzekyBNkvAANiFcyts4R" alt=""><figcaption></figcaption></figure>

Any party fulfilling a role in the iSHARE 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 <a href="#frameworkandroles-adheringroles" id="frameworkandroles-adheringroles"></a>

In any 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.

#### **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.

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 <a href="#frameworkandroles-certifiedroles" id="frameworkandroles-certifiedroles"></a>

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, the iSHARE Trust Framework recognises several certified roles fulfilled by legal entities that offer outsourced identification, authentication, and authorisation tooling to Adhering Parties.

As detailed under [functional requirements per role](/version-2.2/detailed-descriptions/functional/functional-requirements-per-role), to become an iSHARE Certified Party, a legal entity must (first) be admitted as a participant by the Scheme Owner/Participant Registry (in the relevant role).

**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:

* Provides identifiers for humans;
* Issues credentials (i.e. a password or electronic keycard) to humans;
* On the basis of this identification information, identifies and authenticates humans for Service Providers.
* Holds information on authorisations of humans representing a Service Consumer; i.e. information indicating which humans are authorised to act on a Service Consumer's behalf.
* Can check, on the basis of this information, whether a human representing a legal entity is authorised to take delivery of a service;
* Can confirm whether this is the case to the Service 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 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:

* Can holds information on delegations to Service Consumers; i.e. information indicating what parts of the rights of an Entitled Party are delegated to a Service Consumer.
* Can check, on the basis of this information, whether a machine representing a legal entity is authorised to take delivery of a service;
* Can confirm whether this is the case to the Service Provider.

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.

#### **Participant Registry (**[**previously called Satellite**](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/1)**)**

The Participant Registry ensures smooth membership management. All participants within the Data Space/iSHARE network will be explicitly linked to the Participant Registry responsible for their admission.\
\
The Participant Registry plays a fundamental role in any iSHARE use case. Every participant of the iSHARE Trust Framework can check with the Participant Registry whether other parties participate in iSHARE.

### iSHARE compatible software <a href="#frameworkandroles-isharecompatiblesoftware" id="frameworkandroles-isharecompatiblesoftware"></a>

Next to iSHARE adherence and certification, the concept of iSHARE compatibility exists. This concept is reserved for software that technically adheres to the 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 href="#frameworkandroles-roleoftheschemeowner" id="frameworkandroles-roleoftheschemeowner"></a>

The Scheme Owner role is fulfilled by the legal entity that keeps the Framework, and its network of participants, operating properly. How exactly is found under the [detailed Operational descriptions](/version-2.2/detailed-descriptions/operational).

The Scheme Owner is responsible for admission of the Participant Registries and the overall maintenance of the iSHARE Trust Framework.

Please refer to the [detailed](/version-2.2/detailed-descriptions/functional)[ descriptions ](/version-2.2/detailed-descriptions/functional)for details on how the Scheme Owner facilitates and federates trust in the iSHARE Trust Framework.

### Role of the Data Space Governance Body <a href="#frameworkandroles-roleofthesatellite" id="frameworkandroles-roleofthesatellite"></a>

The Data Space Governance Body role is fulfilled by the entity that is responsible for the data space, including the defining, evolving & maintaining and governing of participant life-cycle processes. This role can be fulfilled by a legal entity or by a non legal entity (a group of parties with a certain governance). For reference, the definition of data spaces can be based on the [iSHARE Data Space Template](https://template.ishare.eu/) and this body is responsible for defining, evolving and governing the building blocks there in.

The Data Space Governance Body can also be the **Participant Registry** for their data space. Please note that the Data Space Governance Body does not have an active role in any use cases within the iSHARE network.

{% hint style="info" %}
Legal entities can have both roles simultaneously, or a \*\*`Data Space Governance Body`\*\*could use (contract) a legal entity to fulfill the role of **`Participant Registry`**
{% endhint %}

### Role of the Participant Administrator (previously Satellite administrator) <a href="#frameworkandroles-roleofthesatelliteadministrator" id="frameworkandroles-roleofthesatelliteadministrator"></a>

This role is not a part of the new (harmonised) version of the Framework. To know more about the Participant Administrator role in a data space, go to the [knowledge base](https://trustbok.ishare.eu/enable-ishare/introduction).

### Framework and roles in use cases <a href="#frameworkandroles-frameworkandrolesinusecases" id="frameworkandroles-frameworkandrolesinusecases"></a>

All of iSHARE's use cases can be depicted in the iSHARE Trust 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](/version-2.2/detailed-descriptions/functional/delegation-paths).
* 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:

<figure><img src="/files/bzekyBNkvAANiFcyts4R" alt=""><figcaption></figcaption></figure>

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 use cases](/version-2.2/use-cases), all legal relations are shown before the actual interaction is plotted in the framework.


# Legal provisions

The legal underpinning of iSHARE Trust Framework consists of a contract between all iSHARE participants and the iSHARE Scheme Owner (the so-called Accession Agreement). This contract can be signed with the Participant Registry instead. Based on this one contract with the Scheme Owner or Participant Registry, all participants are bound to the common iSHARE terms of use and can appeal to each other to abide by these rules (in legal terms this is called perfection (Dutch: *derdenwerking*)).

Two main documents make up iSHARE's legal provisions:

1. **The Accession Agreement** The main contract between the participant and the iSHARE Scheme Owner/Participant Registry. This contract refers to the terms of use, including all iSHARE specifications, to which all participants must abide. After signing the Accession Agreement, a party becomes a participant of the iSHARE network either as an Adhering Party or a Certified Party. There are two separate Accession Agreements: one for Adhering Parties and one for Certified Parties.
2. **The Terms of Use** The Terms of Use further define the rights and obligations of every iSHARE Participant and the Scheme Owner/Participant Registry. The Terms of Use apply to any party that has signed the Accession Agreement. The Terms of Use also state that participants fully abide by the iSHARE specifications.

**Data space agreements** - The data space can choose to embed the Accession Agreement and Terms of Use in its data space specific agreements. The data spaces can also have additional agreements for its members.

For the details of the Accession Agreements, the full version of the Terms of Use and the information available on legal context, please refer to the [detailed Legal descriptions](/version-2.2/detailed-descriptions/legal).

### Licenses <a href="#legalprovisions-licenses" id="legalprovisions-licenses"></a>

Within the iSHARE network, it is possible to explicitly provide instructions on how a service may be consumed or under which conditions data is exchanged. These instructions or conditions are called licenses. Licenses are a crucial part of the iSHARE Trust Framework because they provide its participants the possibility to clearly state what is and what is not allowed.

Since all participants are bound to the same contract and underlying Trust Framework rules, participants are legally obliged to comply with the license conditions and can appeal to each other to follow the provided licenses. Licenses apply beyond the transaction and are included in [delegation evidence](https://framework.ishare.eu/detailed-descriptions/technical/structure-of-delegation-evidence), allowing for machine-readable and combined usage rules.

Please refer to the iSHARE Terms of Use for a detailed legal explanation.


# Operational provisions

The iSHARE Trust Framework is constantly improved in collaboration with its stakeholders. Keeping the Trust Framework, and the network operating properly is facilitated by the iSHARE Scheme Owner.

The main responsibilities of the Scheme Owner include:

* Management of the iSHARE Trust Framework (specifications);
* Management of the iSHARE network (participants);
* Management of the iSHARE brand.

To fulfil its responsibilities, the Scheme Owner facilitates the correct operation of the iSHARE Trust Framework and network through administering several aspects:

* [Operational processes](/version-2.2/detailed-descriptions/operational/operational-processes)
* [Service levels](/version-2.2/detailed-descriptions/operational/service-levels)
* [Communication](/version-2.2/detailed-descriptions/operational/communication)

The Scheme Owner is part of a wider governance framework, which can be found in the [introduction of the Framework](/version-2.2/introduction/governance).


# Use cases

This chapter builds on the [iSHARE Trust Framework](/version-2.2/main-aspects-of-the-ishare-trust-framework/framework-and-roles) to showcase the [key functionalities](/version-2.2/main-aspects-of-the-ishare-trust-framework/key-functionality) in four use cases:

1. **Use case:** [**M2M interaction (with fine-grained authorisation)**](/version-2.2/use-cases/use-case-m2m-interaction-with-fine-grained-authorization) showcases:
   * [Support Machine to Machine (M2M) interaction](/version-2.2/main-aspects-of-the-ishare-trust-framework/key-functionality/support-machine-to-machine-m2m-interaction);
   * [Facilitate flexible authorizations, applicable in any context](/version-2.2/main-aspects-of-the-ishare-trust-framework/key-functionality/facilitate-flexible-authorizations-applicable-in-any-context).
2. **Use case:** [**H2M interaction (with coarse-grained authorisation)**](/version-2.2/use-cases/use-case-h2m-interaction-with-coarse-grained-authorization) showcases:
   * [Support Human to Machine (H2M) interaction](/version-2.2/main-aspects-of-the-ishare-trust-framework/key-functionality/support-human-to-machine-h2m-interaction);
   * [Facilitate flexible authorizations, applicable in any context](/version-2.2/main-aspects-of-the-ishare-trust-framework/key-functionality/facilitate-flexible-authorizations-applicable-in-any-context).
3. **Use case:** [**portable identity**](/version-2.2/use-cases/use-case-portable-identity) showcases:
   * [Facilitate portable identity(s) for parties and humans](/version-2.2/main-aspects-of-the-ishare-trust-framework/key-functionality/facilitate-portable-identity-s-for-parties-and-humans).
4. **Use case:** [**delegation (and management of consent)** ](/version-2.2/use-cases/use-case-delegation-and-management-of-consent)showcases:
   * [Enable data exchange based on delegations - even between unknown parties](/version-2.2/main-aspects-of-the-ishare-trust-framework/key-functionality/enable-data-exchange-based-on-delegations-even-between-unknown-parties);
   * [Enable control over own data through management of consent](/version-2.2/main-aspects-of-the-ishare-trust-framework/key-functionality/enable-control-over-own-data-through-management-of-consent).

### **Structure**

Each use case includes:

* A description and depiction of the roles and relations;
* A description of the prerequisites, and a depiction of prerequisite registration;
* A description and depiction of the use case;
* A sequence diagram;
* A reference to what needs to be technically implemented for this use case.

The depicted use cases are only a selection of iSHARE Trust Framework's use case scope. For the full scope, please refer to the [detailed Functional descriptions](/version-2.2/detailed-descriptions/functional).


# Use case: M2M interaction (with fine-grained authorization)

This use case showcases iSHARE Trust Framework's key functionality '[support Machine to Machine (M2M) interaction](/version-2.2/main-aspects-of-the-ishare-trust-framework/key-functionality/support-machine-to-machine-m2m-interaction)'.

The example described in the linked chapter is as follows:

* Every day, the ERP system (machine) of Party A requests a status update from the ERP system (machine) of Party B. Party B's ERP system automatically responds with the requested status update. No humans are needed to interfere.

To showcase the key functionality '[facilitate flexible authorizations](/version-2.2/main-aspects-of-the-ishare-trust-framework/key-functionality/facilitate-flexible-authorizations-applicable-in-any-context)', Party A's ERP system (machine) is ONLY allowed to request status updates concerning line X of bill of lading Y. This can be considered a fine-grained authorization.

The following explains this example in detail, utilising the iSHARE Trust Framework.

### Roles and Relations <a href="#usecase-m2minteraction-withfine-grainedauthorization-rolesandrelations" id="usecase-m2minteraction-withfine-grainedauthorization-rolesandrelations"></a>

The following roles are fulfilled in this use case:

* Party A requests a status update, so it is the legal entity fulfilling the **Service Consumer**-role;
* Party B responds with the status update, so it is the legal entity fulfilling the **Service Provider**-role;
* No delegation takes place, so Party A also fulfils the **Entitled Party**-role;
* As this is a M2M use case, a **Machine Service Consumer** represents Party A.

The only **legal relation** is the mandatory relation between the Entitled Party (Party A) and the Service Provider (Party B), which establishes the entitlements of the Entitled Party (Party A). As depicted:

<figure><img src="/files/fL8I9ZydTul71bXsLWBA" alt=""><figcaption></figcaption></figure>

### Prerequisites <a href="#usecase-m2minteraction-withfine-grainedauthorization-prerequisites" id="usecase-m2minteraction-withfine-grainedauthorization-prerequisites"></a>

It is prerequisite of this use case that:

* The Service Provider (Party B) has and manages its own entitlement information indicating what Entitled Parties are entitled to what (parts of) services, i.e. Party B has information indicating that Party A is allowed to request status updates concerning line X of bill of lading Y from its ERP system;
* The Service Consumer (Party A) is able to authenticate the Service Provider (Party B);
* The Service Provider (Party B) is able to authenticate the Service Consumer (Party A).

### Use case <a href="#usecase-m2minteraction-withfine-grainedauthorization-usecase" id="usecase-m2minteraction-withfine-grainedauthorization-usecase"></a>

The use case consists of the following steps:

1. The Machine Service Consumer (of Party A) requests a service from the Service Provider (Party B);
2. The Service Provider (Party B) authenticates the Machine Service Consumer (of Party A) and validates the iSHARE adherence of the Service Consumer (Party A);
3. The Service Provider (Party B) authorizes the Machine Service Consumer of the Service Consumer (Party A) based on the entitlement information registered with the Service Provider (Party B);
4. The Service Provider (Party B) executes the requested service;
5. The Service Provider (Party B) provides the service result to the Machine Service Consumer (of Party A).

As depicted:

<figure><img src="/files/my1y671vPZa0vgCmO8yE" alt=""><figcaption></figcaption></figure>

Note that this use case is exactly the same as primary use case 1, as found under [detailed Functional descriptions](/version-2.2/detailed-descriptions/functional).

### Sequence diagram <a href="#usecase-m2minteraction-withfine-grainedauthorization-sequencediagram" id="usecase-m2minteraction-withfine-grainedauthorization-sequencediagram"></a>

<figure><img src="/files/Xl4S7keU49EEyg0P40FL" alt=""><figcaption></figcaption></figure>

What needs to be implemented technically for this use case is described [generically](/version-2.2/detailed-descriptions/technical/technical-standards), and specifically per role in the [iSHARE Developer Portal](https://dev.ishare.eu/).


# Use case: H2M interaction (with coarse-grained authorization)

This use case showcases iSHARE Trust Framework's key functionality '[support Human to Machine (H2M) interaction](/version-2.2/main-aspects-of-the-ishare-trust-framework/key-functionality/support-human-to-machine-h2m-interaction)'.

The example described in the linked chapter is as follows:

* Human X, working for Party A, requests a status update from the ERP system (machine) of Party B. It does so via a user interface.

To showcase the key functionality '[facilitate flexible authorizations](/version-2.2/main-aspects-of-the-ishare-trust-framework/key-functionality/facilitate-flexible-authorizations-applicable-in-any-context)', Party A's ERP system (machine) is allowed to request ANY information about ANY (part of a) bill of lading. This can be considered a coarse-grained authorization.

The following explains this example in detail, utilising the iSHARE Trust Framework.

### Roles and Relations <a href="#usecase-h2minteraction-withcoarse-grainedauthorization-rolesandrelations" id="usecase-h2minteraction-withcoarse-grainedauthorization-rolesandrelations"></a>

The following roles are fulfilled in this use case:

* Party A requests a status update, so it is the legal entity fulfilling the **Service Consumer**-role;
* Party B responds with the status update, so it is the legal entity fulfilling the **Service Provider**-role;
* No delegation takes place, so Party A also fulfils the **Entitled Party**-role;
* Human X is the **Human Service Consumer** that represents Party A.

The only **legal relation** is the mandatory relation between the Entitled Party (Party A) and the Service Provider (Party B), which establishes the entitlements of the Entitled Party (Party A). As depicted:

<figure><img src="/files/pjmzNcWwoNh3y9M1FQJr" alt=""><figcaption></figcaption></figure>

### Prerequisites <a href="#usecase-h2minteraction-withcoarse-grainedauthorization-prerequisites" id="usecase-h2minteraction-withcoarse-grainedauthorization-prerequisites"></a>

It is prerequisite of this use case that:

* The Service Provider (Party B) has and manages its own entitlement information indicating what Entitled Parties are entitled to what (parts of) services, i.e. Party B has information indicating that Party A is allowed to request ANY information about ANY (part of a) bill of lading from its ERP system;
* The Service Consumer (Party A) has and manages its own authorization information indicating which Human Service Consumers are authorized to act on its behalf;
* **The delegation/authorization responsible at the the Service Consumer (Party A) registers the authorization information at the Service Provider (Party B);**
* The Human Service Consumer (Human X) is able to authenticate the Service Provider (Party B);
* The Service Provider (Party B) is able to authenticate the Human Service Consumer (Human X);
* **The Human Service Consumer (Human X) has been issued identity credentials by the Service Provider (Party B).**

### Use case <a href="#usecase-h2minteraction-withcoarse-grainedauthorization-usecase" id="usecase-h2minteraction-withcoarse-grainedauthorization-usecase"></a>

The use case consists of the following steps:

1. The Human Service Consumer (Human X) requests a service from the Service Provider (Party B);
2. The Service Provider (Party B) authenticates the Human Service Consumer (Human X), and validates the iSHARE adherence of the Service Consumer (Party A);
3. The Service Provider (Party B) authorizes the Human Service Consumer (Human X) of the Service Consumer (Party A) based on the entitlement- and authorization information registered with the Service Provider (Party B);
4. The Service Provider (Party B) executes the requested service;
5. The Service Provider (Party B) provides the service result to the Human Service Consumer (Human X).

As depicted

<figure><img src="/files/QuBFF4dDcnCJrrxMRpJy" alt=""><figcaption></figcaption></figure>

Note that this use case is exactly the same as primary use case 2, as found under [detailed Functional descriptions](/version-2.2/detailed-descriptions/functional).

### Sequence diagram <a href="#usecase-h2minteraction-withcoarse-grainedauthorization-sequencediagram" id="usecase-h2minteraction-withcoarse-grainedauthorization-sequencediagram"></a>

<figure><img src="/files/M1Pqf8REL0v61Zxq4H87" alt=""><figcaption></figcaption></figure>

What needs to be implemented technically for this use case is described [generically](/version-2.2/detailed-descriptions/technical/technical-standards), and specifically per role in the [iSHARE Developer Portal](https://dev.ishare.eu/).


# Use case: portable identity

This use case showcases iSHARE Trust Framework's key functionality '[facilitate portable identity(s) for parties and humans](/version-2.2/main-aspects-of-the-ishare-trust-framework/key-functionality/facilitate-portable-identity-s-for-parties-and-humans)'.

The example described in the linked chapter is as follows:

* Human X, working for Party A, has credentials issued by iSHARE certified Identity Provider Y. The credentials, and thus the identity of Human X, can be used to identify and authenticate Human X at party B.

Human X will now use its Identity Provider Y credentials to request a status update from the ERP system (machine) of Party B.

The following explains this example in detail, utilising the iSHARE Trust Framework.

### Roles and Relations <a href="#usecase-portableidentity-rolesandrelations" id="usecase-portableidentity-rolesandrelations"></a>

The following roles are fulfilled in this use case:

* Party A requests a status update, so it is the legal entity fulfilling the **Service Consumer**-role;
* Party B responds with the status update, so it is the legal entity fulfilling the **Service Provider**-role;
* No delegation takes place, so Party A also fulfils the **Entitled Party**-role.
* Human X is the **Human Service Consumer** that represents Party A;
* Identity Provider Y is one of the **Identity Providers** to which Party B has outsourced identification, authentication and authorisation of humans, and the party that has given Human X his keycard.
* Optionally (and shown in this case), Identity Broker Z is the **Identity Broker** that provides Party B access to different Identity Providers, and that offers Human X the option to choose with which Identity Provider to identify and authenticate itself.

#### Legal relations <a href="#usecase-portableidentity-legalrelations" id="usecase-portableidentity-legalrelations"></a>

* As always, a mandatory relation between the Entitled Party (Party A) and the Service Provider (Party B) establishes the entitlements of the Entitled Party (Party A);
* A mandatory relation between the Service Provider and the Identity Broker covers the use of Identity Broker Z's services, including a connection to several Identity Providers, by the Service Provider (Party B);
* A mandatory relation between the Service Consumer (Party A) and Identity Provider Y covers the use of Identity Provider Y's keycards by the the Service Consumer's (Party A's) humans, including Human X.

As depicted:

<figure><img src="/files/s4RFcSR71xe1GetQ5zGe" alt=""><figcaption></figcaption></figure>

### Prerequisites <a href="#usecase-portableidentity-prerequisites" id="usecase-portableidentity-prerequisites"></a>

It is prerequisite of this use case that:

* The Service Provider (Party B) has and manages its own entitlement information indicating what Entitled Parties are entitled to what (parts of) services, i.e. Party B has information indicating that Party A is entitled to status updates from its ERP system;
* The Service Consumer (Party A) has and manages its own authorization information indicating which Human Service Consumers are authorized to act on its behalf;
* **The delegation/authorization responsible at the the Service Consumer (Party A) registers the authorization information at the Identity Provider (Y);**
* The Human Service Consumer (Human X) is able to authenticate the Service Provider (Party B);
* The Service Provider (Party B) is able to authenticate the Human Service Consumer (Human X);
* The Identity Provider (Y) is able to authenticate the Service Provider (Party B);
* The Service Provider (Party B) is able to authenticate the Identity Provider (Y);
* The Identity Broker (Z) is able to authenticate the Service Provider (Party B);
* The Service Provider (Party B) is able to authenticate the Identity Broker (Z);
* **The Human Service Consumer (Human X) has been issued identity credentials by the Identity Provider (Y).**

The prerequisites in bold are depicted as follows:

<figure><img src="/files/On8NpwuYn7rnCXdx3sDW" alt=""><figcaption></figcaption></figure>

### Use case <a href="#usecase-portableidentity-usecase" id="usecase-portableidentity-usecase"></a>

The use case consists of the following steps:

1. The Human Service Consumer (Human X) requests a service from the Service Provider (Party B);
2. The Service Provider (Party B) requests a login from the Identity Broker (Z);
3. The Identity Broker (Z) asks the Human Service Consumer (Human X) to select his Identity Provider (Y);
4. The Identity Broker (Z) requests a login from the Identity Provider (Y);
5. The Identity Provider (Y) authenticates the Human Service Consumer (Human X) (on the basis of Human X's credentials);
6. The Identity Provider (Y) issues an identity assertion and authorization assertion for the Service Provider (Party B) to the Identity Broker (Z);
7. The Identity Broker (Z) forwards the identity assertion and authorization assertion to the Service Provider (Party B);
8. The Service Provider (Party B) validates the identity assertion and authorization assertion through the following steps:
   1. The Service Provider (Party B) authenticates the Identity Broker (Z) and validates its iSHARE certification;
   2. The Service Provider (Party B) authenticates the Identity Provider (Y) and validates its iSHARE certification.
9. The Service Provider (Party B) authenticates the Human Service Consumer (Human X) based on the validity of the identity assertion, and validates the iSHARE adherence of the Service Consumer (Party A);
10. The Service Provider (Party B) authorizes the Human Service Consumer (Human X) of the Service Consumer (Party A) based on the authorization assertion and the entitlement information registered with the Service Provider (Party B);
11. The Service Provider (Party B) executes the requested service;
12. The Service Provider (Party B) provides the service result to the Human Service Consumer (Human X).

As depicted:

<figure><img src="/files/7UE72GX3whzyMw2YUp0v" alt=""><figcaption></figcaption></figure>

Note that this use case is exactly the same as primary use case 3, as found under [detailed Functional descriptions](/version-2.2/detailed-descriptions/functional). In this section, the same use case is also explained without an Identity Broker.

### Sequence diagram <a href="#usecase-portableidentity-sequencediagram" id="usecase-portableidentity-sequencediagram"></a>

<figure><img src="/files/F7ak3WpIosaP3WEBHhjB" alt=""><figcaption></figcaption></figure>

What needs to be implemented technically for this use case is described [generically](/version-2.2/detailed-descriptions/technical/technical-standards), and specifically per role in the [iSHARE Developer Portal](https://dev.ishare.eu/).


# Use case: delegation (and management of consent)

This use case showcases iSHARE Trust Framework's key functionality '[enable data exchange based on delegations - even between unknown parties](/version-2.2/main-aspects-of-the-ishare-trust-framework/key-functionality/enable-data-exchange-based-on-delegations-even-between-unknown-parties)'.

The example described in the linked chapter is as follows:

* Party A hires Trucking Company B to deliver Container X to Party C. Trucking Company B's ERP system asks Party C's ERP system at what time it should deliver the container. Party C's ERP system does not know Trucking Company B, but can check the delegation to Trucking Company B that Party A has registered at Authorization Registry D. Because this delegation is in order, Party C's ERP system shares a time slot with Trucking Company B's ERP.

The following explains this example in detail, utilising the iSHARE Trust Framework.

After explanation of the delegation use case, a scenario is introduced that showcases key functionality '[enable control over own data through management of consent](/version-2.2/main-aspects-of-the-ishare-trust-framework/key-functionality/enable-control-over-own-data-through-management-of-consent)'. In this [Use case: delegation (and management of consent)#Alternative scenario on management of consent,](#usecase-delegation-andmanagementofconsent-alternativescenarioonmanagementofconsent) Party C decides to revoke Party A's access to requesting a time slot.

### Roles and Relations <a href="#usecase-delegation-andmanagementofconsent-rolesandrelations" id="usecase-delegation-andmanagementofconsent-rolesandrelations"></a>

The following roles are fulfilled in this use case:

* Delegation takes place, with Party A the party originally entitled to request a time slot. Party A therefore fulfils the **Entitled Party**-role;
* Trucking Company B is delegated the right to request a time slot, so it is the legal entity fulfilling the **Service Consumer**-role;
* Party C responds with the time slot, so it is the legal entity fulfilling the **Service Provider**-role;
* Authorization Registry D is the **Authorization Registry** to which Party A has outsourced managing delegation information.
* As this is a M2M use case, a **Machine Service Consumer** represents Trucking Company B.

#### Legal relations <a href="#usecase-delegation-andmanagementofconsent-legalrelations" id="usecase-delegation-andmanagementofconsent-legalrelations"></a>

* As always, a mandatory relation between the Entitled Party (Party A) and the Service Provider (Party C) establishes the entitlements of the Entitled Party (Party A);
* A mandatory relation between the Entitled Party (Party A) and the Service Consumer (Trucking Company B) covers the delegation of the right to request a time slot;
* A mandatory relation between the Entitled Party (Party A) and the Authorization Registry (D) covers the outsourcing of managing delegation information.
* No relation between the Service Consumer (Trucking Company B) and the Service Provider (Party C) is mandatory before service consumption, i.e. the Service Consumer and the Service Provider do not need to know each other. This relation only commences through usage;
* No relation between the Service Provider (Party C) and the Authorization Registry (D) is mandatory before communication. This relation also commences through usage.

As depicted:

<figure><img src="/files/NM9DKi27sWCaFSffaiBW" alt=""><figcaption></figcaption></figure>

### Prerequisites <a href="#usecase-delegation-andmanagementofconsent-prerequisites" id="usecase-delegation-andmanagementofconsent-prerequisites"></a>

It is prerequisite of this use case that:

* The Service Provider (Party C) has and manages its own entitlement information indicating what Entitled Parties are entitled to what (parts of) services, i.e. Party C has information indicating that Party A is entitled to request a time slot;
* The Service Consumer (Trucking Company B) is able to authenticate the Service Provider (Party C);
* The Service Provider (Party C) is able to authenticate the Service Consumer (Trucking Company B);
* **The delegation/authorization responsible at the Entitled Party (Party A) delegates (part of) the Entitled Party's (Party A's) rights (as registered at the Service Provider (Party C)) to the Service Consumer (Trucking Company B). He registers this delegation in an Authorization Registry (D);**
* The Service Provider (Party C) knows which Authorization Registry (D) to request the delegation evidence from;
* The Service Provider (Party C) is able to authenticate the Authorization Registry (D);
* The Authorization Registry (D) is able to authenticate the Service Provider (Party C);
* It is clear, through scheme agreements, under what conditions an Authorization Registry can provide delegation information to a Service Provider.

The prerequisites in bold are depicted as follows:

<figure><img src="/files/NnwElhqJLI3FFrKn0PI9" alt=""><figcaption></figcaption></figure>

### Use case <a href="#usecase-delegation-andmanagementofconsent-usecase" id="usecase-delegation-andmanagementofconsent-usecase"></a>

The use case consists of the following steps:

1. The Machine Service Consumer (of Trucking Company B) requests a service from the Service Provider (Party C);
2. The Service Provider (Party C) authenticates the Machine Service Consumer (of Trucking Company B) and validates the iSHARE adherence of the Service Consumer (Trucking Company B);
3. The Service Provider (Party C) requests delegation evidence from the Authorization Registry (D);
4. The Authorization Registry (D) authenticates the Service Provider (Party C) and validates its iSHARE adherence;
5. The Authorization Registry (D) authorizes the Service Provider (Party C) based on the scheme agreements for providing delegation information;
6. The Authorization Registry (D) provides the delegation evidence;
7. The Service Provider (Party C) validates the received delegation evidence through the following steps:
   1. The Service Provider (Party C) authenticates the Authorization Registry (D) and validates its iSHARE certification;
   2. The Service Provider (Party C) authorizes the Entitled Party (Party A) based on the entitlement information registered with the Service Provider (Party C), and validates its iSHARE adherence.
8. The Service Provider (Party C) authorizes the Machine Service Consumer of the Service Consumer (Trucking Company B) based on the validity of the delegation evidence;
9. The Service Provider (Party C) executes the requested service;
10. The Service Provider (Party C) provides the service result to the Machine Service Consumer (of Trucking Company B).

As depicted:

<figure><img src="/files/K6i56NyMZ4AJRsgu9uuR" alt=""><figcaption></figcaption></figure>

Note that this use case is exactly the same as derived use case 1c, as found under [detailed Functional descriptions](/version-2.2/detailed-descriptions/functional). This section also includes delegation use cases with delegation information held by other roles than an Authorization Registry.

### Sequence diagram <a href="#usecase-delegation-andmanagementofconsent-sequencediagram" id="usecase-delegation-andmanagementofconsent-sequencediagram"></a>

<figure><img src="/files/qZNY8OzFEtC1rv9CLptR" alt=""><figcaption></figcaption></figure>

### Alternative scenario on management of consent <a href="#usecase-delegation-andmanagementofconsent-alternativescenarioonmanagementofconsent" id="usecase-delegation-andmanagementofconsent-alternativescenarioonmanagementofconsent"></a>

This alternative scenario showcases key functionality '[enable control over own data through management of consent](/version-2.2/main-aspects-of-the-ishare-trust-framework/key-functionality/enable-control-over-own-data-through-management-of-consent)'.

The example detailed in the above is as follows:

* Party A hires Trucking Company B to deliver Container X to Party C. Trucking Company B's ERP system asks Party C's ERP system at what time it should deliver the container. Party C's ERP system does not know Trucking Company B, but can check the delegation to Trucking Company B that Party A has registered at Authorization Registry D. Because this delegation is in order, Party C's ERP system shares a time slot with Trucking Company B's ERP.

Now imagine:

* Moments before Trucking Company B's ERP system asks Party C's ERP system for a time slot, Party C decides to revoke Party A's access to requesting a time slot. Consequently, Trucking Company B's request for a time slot gets an access forbidden message; Trucking Company B's request is NOT accepted because Party A, and therewith delegated Trucking Company B, is no longer authorised to ask for a time slot.

#### Prerequisites <a href="#usecase-delegation-andmanagementofconsent-prerequisites.1" id="usecase-delegation-andmanagementofconsent-prerequisites.1"></a>

To the prerequisites, ONLY the following changes:

* The Service Provider (Party C) changes its entitlement information indicating what Entitled Parties are entitled to what (parts of) services, i.e. Party C deletes the information indicating that Party A is entitled to request a time slot.

#### Use case <a href="#usecase-delegation-andmanagementofconsent-usecase.1" id="usecase-delegation-andmanagementofconsent-usecase.1"></a>

The alternative use case consists of the following steps, with changes to the above use case in bold:

1. The Machine Service Consumer (of Trucking Company B) requests a service from the Service Provider (Party C);
2. The Service Provider (Party C) authenticates the Machine Service Consumer (of Trucking Company B) and validates the iSHARE adherence of the Service Consumer (Trucking Company B);
3. The Service Provider (Party C) requests delegation evidence from the Authorization Registry (D);
4. The Authorization Registry (D) authenticates the Service Provider (Party C) and validates its iSHARE adherence;
5. The Authorization Registry (D) authorizes the Service Provider (Party C) based on the scheme agreements for providing delegation information;
6. The Authorization Registry (D) provides the delegation evidence;
7. The Service Provider (Party C) validates the received delegation evidence through the following steps:
   1. The Service Provider (Party C) authenticates the Authorization Registry (D) and validates its iSHARE certification;
   2. The Service Provider (Party C) CANNOT authorize the Entitled Party (Party A) based on the entitlement information registered with the Service Provider (Party C)
8. The Service Provider (Party C) CANNOT authorize the Machine Service Consumer of the Service Consumer (Trucking Company B) based on the validity of the delegation evidence;
9. The Service Provider (Party C) communicates an access forbidden message to the Machine Service Consumer (of Trucking Company B).

#### Sequence diagram <a href="#usecase-delegation-andmanagementofconsent-sequencediagram.1" id="usecase-delegation-andmanagementofconsent-sequencediagram.1"></a>

<figure><img src="/files/Ta7QshisiL8kbwqxzDSW" alt=""><figcaption></figcaption></figure>

What needs to be implemented technically for this use case (and the alternative scenario) is described [generically](/version-2.2/detailed-descriptions/technical/technical-standards), and specifically per role in the [iSHARE Developer Portal](https://dev.ishare.eu/).




---

[Next Page](/llms-full.txt/1)