# Welcome to the Trust Body of Knowledge {% hint style="info" %} Information Point**:** This content is being developed continuously. {% endhint %} ## Overview > The iSHARE Trust Framework serves as the foundational layer for data spaces. Its primary function is to facilitate secure and efficient data sharing. To complement the Trust Framework and promote its adoption, there is need for bringing the value of data spaces to individuals and organisations. The Body of Knowledge is all things - data sharing. > The Knowledge base here is a non-exhaustive list of design principles, tools and information to lower the barriers to adoption of data spaces. It provides programmatic access to conceptual models for data sharing. In addition it explains the core reasoning for designing an architecture or framework for sharing data. ## Quick links {% content-ref url="/pages/q8ywbhBdpmiY8eEbK10v" %} [iSHARE Trust Framework](/understand-ishare/ishare-trust-framework) {% endcontent-ref %} {% content-ref url="/pages/L78XyEnhnNtXmWYtm7Q5" %} [General FAQs](/understand-ishare/general-faqs) {% endcontent-ref %} {% content-ref url="/pages/dmZhRANrEMcFHOvykkwT" %} [Technical Standards](/apply-ishare/technical-standards) {% endcontent-ref %} {% content-ref url="/pages/7kK4i1hH0PkcOHlE9Ghw" %} [Quick walkthroughs](/apply-ishare/quick-walkthroughs) {% endcontent-ref %} {% content-ref url="/pages/6UZjyqOCgn2bu0FOTdNP" %} [Technical FAQs](/apply-ishare/technical-faqs) {% endcontent-ref %} # Introduction **What Are Data Spaces?** Data spaces are virtual environments where different organisations can share and exchange data securely and efficiently. In a data space, data providers, consumers, and other participants collaborate to create value from data while maintaining control over it. Data spaces are designed to be interoperable and flexible, allowing participants from different sectors and industries to connect and share data according to agreed-upon rules and standards.
**Why Share Data?** **Sharing data between organisations can lead to many benefits. Such as:** 1. **Improved collaboration:** Access to shared data ensures all stakeholders work from the same information, making coordination smoother and reducing duplication. 2. **Better decision-making:** Real-time, reliable data enables organizations to respond quickly and base decisions on evidence rather than assumptions. 3. **Innovation:** Combining data from different sources generates new insights that can drive the development of products, services, and business models. **Sector specific impact of data sharing:** **Healthcare:** data sharing can improve patient care by ensuring that all providers have access to the most up-to-date information. **Logistics:** data sharing can optimise supply chains, reduce costs, and improve efficiency. By sharing data, organisations can also unlock new insights and create innovations that would not be possible with siloed data. {% embed url="" %} **Introduction to the iSHARE Trust Framework** The iSHARE Trust Framework is a set of agreements and standards designed to facilitate secure and trusted data sharing between organisations. It provides a common framework that ensures all participants in a data space can trust each other and the processes involved in exchanging data. The iSHARE Framework covers important aspects such as identity management, authentication, authorization, and data access, ensuring that data is only shared with the appropriate parties and under the right conditions. **Why Is iSHARE Relevant to Data Sharing?** In the digital age, the importance of secure and efficient data sharing is crucial. The iSHARE Trust Framework is particularly relevant because it addresses the main challenges of data sharing—trust, security, and interoperability. By using iSHARE, organisations can confidently share data knowing that all participants adhere to the same rules and standards. This not only reduces the risk of data breaches but also streamlines the process of setting up data-sharing agreements between different parties. {% embed url="" %} **Current Applications of the iSHARE Trust Framework in Data Sharing** The iSHARE Trust Framework is being utilised in various industries to facilitate data sharing. For example, in logistics, it helps companies share data across supply chains, improving coordination and reducing inefficiencies. In smart cities, it enables the sharing of data between different city services and private companies, enhancing urban living. By providing a trusted environment for data sharing, iSHARE is helping organisations across different sectors unlock the full potential of their data. {% embed url="" %} **For the Dutch version, visit the following link:** [**https://www.youtube.com/watch?v=54wux8OXMBI**](https://www.youtube.com/watch?v=54wux8OXMBI) **iSHARE-Based Data Ecosystems** An iSHARE-based data ecosystem is a group of organisations that agree to share data with each other — safely, quickly, and with full control — using a shared set of rules called the iSHARE Trust Framework. 🚫 No Central Storage Instead of sending all data to one big database, each organisation keeps its own data. When another party needs access, they can request it directly — just like borrowing a book from a library, instead of copying the whole library. ✅ Full Control Each organisation decides: * Who gets access * What data they can see * When and how long they can use it 🌍 For Example * A transport company shares delivery updates with a port terminal * A farmer shares soil data with a weather service * A hospital shares patient data with a specialist — securely and only for the right purpose *** **Key Takeaways:** * Data spaces are secure environments that allow organizations to share and exchange data under common rules. * Sharing data improves collaboration, supports better decision-making, and fosters innovation. * The iSHARE Trust Framework provides agreements and standards that ensure secure, trustworthy, and standardised data sharing. * iSHARE Trust Framework is relevant because it addresses the main challenges of data sharing: trust, security, and interoperability. * iSHARE Trust Framework is already applied in many sectors including logistics and smart cities to improve efficiency and coordination. * iSHARE-based ecosystems use a decentralized model, allowing participants to retain control of their own data while gaining shared insights.
# Design Principles At the core of [iSHARE](https://ishare.eu) lies a vision for open, federated, and interoperable data sharing, ensuring data accessibility for all users, both new and established, without the dominance of any single entity. To understand the practical application of data spaces for businesses, it’s essential to explore the different layers involved: **Layer 1 - Applications and Users** Every data space is driven by a practical use case where data exchange directly impacts stakeholders, driving demands and the resources needed for implementation. Some examples include: * Sustainability Reports: for secure access to energy, building and energy label data. * CO2 Reports and Advice: to reduce CO2 emissions in logistics. * Traffic and Water Management Inspection (IVW): for road safety through data collection on transported goods. **Layer 2 – Data Space Building Blocks** Building blocks are crucial for facilitating data exchange in an open and federated manner. They provide: * Data Sovereignty and Trust: to ensure data stays within authorised boundaries. * Data Value Creation: to maximise data utility and profitability. * Data Space Governance: for structured oversight. * Data Interoperability: for standardising communication protocols. **Layer 3 – Data Availability** Data sources within a data space require access control, software, and API authorisations. Different classifications of data include: * Public/ open data: No access control or usage restrictions are necessary. * Licensed data: Access control based on conditions. * Business confidential data: Specific policies required. * Consumer confidential data: Specific access policies are necessary for privacy reasons. Together, these layers facilitate secure and sovereign data exchange, certification, and governance, fostering collaboration across Europe and beyond.
# Data Sharing Principles Characteristics, Challenges, and Archetypes **Characteristics of Data Sharing** Data sharing enables third parties, such as companies, individuals, and public institutions, to access data sets to develop new applications and services. The terms of data use and availability are determined by legal agreements between data providers, data consumers, and other involved roles, depending on the use case. Data sharing has many characteristics, highlighting that there is no single approach, as it depends on multiple factors, as shown below.
Infrastructure
  1. Data marketplace
  2. Solutions
Technology
  1. Blockchain
  2. Cloud computing
Legal concepts
  1. Agreements
  2. Contracts
Services
  1. Connecting
  2. Privacy-as-a-service
  3. Analytics
Customer Groups
  1. B2B
  2. C2B/B2C
Actors
  1. Data owner
  2. Data consumer
  3. Data provider
Data types
  1. Anonymous personal data
  2. Metadata
  3. Aggregated data
*** **Challenges in Data Sharing: Not as Simple as it Seems** While the benefits of data sharing, such as scientific progress, transparency, and collaboration, are clear, the complexities and ethical concerns involved should not be overlooked. 1. Ethical Concerns: Participants may not fully understand how their data could be accessed and used by others, especially by those with conflicting interests. This creates significant ethical issues, especially in areas involving sensitive or identifiable information. 2. Confidentiality Issues: Anonymised data can sometimes be re-identified when combined with external information, posing risks to participant confidentiality. 3. Impact on Business Integrity: Mandatory data sharing without safeguards can compromise business integrity, potentially affecting industries and regulatory policies. **What is a data ecosystem all about?** A data ecosystem integrates data from multiple sources to create value through processing. A successful ecosystem ensures these three priorities are met: 1. Building Economies of Scale: Attract participants by lowering barriers to entry. 2. Generating Customer Benefits: Establish clear benefits and dependencies beyond the core product to create high exit barriers over time. 3. Fostering Collaboration: Motivate multiple parties with similar interests to collaborate and pursue shared objectives. *** **Scope of Data Ecosystems** Data ecosystems can be categorised into different archetypes based on their scope, data aggregation models, service types, and engagement methods: 1. Data Utilities: Aggregate data sets to provide tools and services to other businesses (e.g., credit bureaus, consumer-insights firms). 2. Operations Optimisation Centres: Integrate data within the business and across the value chain to achieve operational efficiencies (e.g., supply chain integration). 3. End-to-End Cross-Sector Solutions: Integrate multiple partner data sets to offer comprehensive services through a single solution (e.g., car reselling platforms, testing platforms, partnership networks). 4. Marketplace Solutions: Act as a conduit between suppliers and consumers or businesses, offering products and services (e.g., Amazon, Alibaba). 5. B2B Infrastructure: Provide core infrastructure solutions on which other companies can establish their ecosystem businesses (e.g., data-management platforms, payment infrastructure providers). **The Blueprint of a Successful Data Ecosystem** Data ecosystems hold significant value, but entry barriers are typically high; therefore, companies must understand the potential obstacles. Success depends on finding the right business model to generate revenue and ensuring active participation. The next step is to prioritise strategic partnerships that offer compelling value propositions and deliver excellent customer experiences to attract end customers and collaborators. **Steps to Share Data Among Ecosystem Partners** The standard data-sharing mechanisms among partners typically follow three steps: 1. Establishing a secure connection and trust. 2. Exchanging data through cloud infrastructure and client marketplaces. 3. Storing results is necessary. These steps should be followed by adopting a decentralised and federated identity management approach, such as an open data-mesh architecture. # iSHARE Trust Framework ## Video Overview Here you can find a short introduction about the iSHARE Trust Framework explained by our executive director, Gerard van der Hoeven {% embed url="" %} # Role Mapping The iSHARE Trust Framework defines a set of roles that apply to legal entities participating in data sharing ecosystems. These roles are designed to align conceptually with those used in complementary initiatives such as IDSA, DSSC, and regulations like the EU Data Governance Act. Although each initiative has its own approach to defining roles, the comparison table below provides an overview of how these roles relate to one another. This helps create a shared understanding across data space communities and supports interoperability and trust. **Adhering roles** | Roles in iSHARE | Alternative names currently in use for this role | IDSA | Data Space Protocol | Data Governance Act | DSSC Blueprint | | ---------------- | ------------------------------------------------ | ------------- | ------------------------------------------------------------------------------ | --------------------------- | ------------------------------------------- | | Service Consumer | Data Consumer, Data User, Data Recipient | Data Consumer | Participant, fulfilling their technical requirements using a Participant Agent | Data user | Data product consumer | | Service Provider | Data Provider, Data Node | Data Provider | Participant, fulfilling their technical requirements using a Participant Agent | Data holder | Data product owner or Data product provider | | Entitled Party | Data Owner, Data Holder | Data Owner | | Data subject or data holder | Data product owner or Data rights holder | **Certified roles** | Roles in iSHARE | Alternative names currently in use for this role | IDSA | Data Space Protocol | Data Governance Act | DSSC Blueprint | | ---------------------- | ------------------------------------------------ | ---- | ---------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Identity Provider | Human Identity Provider | | | | Can be seen as a Trust anchor | | Identity Broker | | | | | | | Authorisation Registry | | | | Part of a data intermediation service | Can be seen as a Participant Agent Services | | Participant Registry | | | Not present, this role will likely fulfill it’s technical requirements by using a Dataspace Registry | *Competent Authorities* for both *data intermediation services* and *data altruism organisations* | A combination and/or parts of Data Space Registry, Registry, Validation & Verification Service, Compliance Service, Notary, Intermediary, Federation Services, Data Space Intermediary, Conformity Assessment Body, Common Intermediary | **Other relevant roles** These roles are necessary in the framework and data spaces context however, they are not necessarily registered as participants. The roles will still be essential to enable trusted data sharing and governance around it. | Roles in iSHARE | Alternative names currently in use for this role | IDSA | Data Space Protocol | Data Governance Act | DSSC Blueprint | | -------------------------- | ------------------------------------------------------------------------- | ------------------- | ------------------- | --------------------------------------------------------------------- | --------------------------------- | | Scheme owner | | | | | (Data Space) Support Organisation | | Data Space Governance Body | Data Space Coordinator, Scheme Satellite, Data Space Governance Authority | Dataspace Authority | Dataspace Authority | May be considered equivalent to European Data Innovation Board (EDIB) | (Data space) governance authority | # EUDI Wallet ARF actor mapping This page maps iSHARE roles to the closest actor terms used in the **EUDI Wallet Architecture and Reference Framework (ARF)**. The mapping is only applicable in wallet-based interaction patterns (e.g., a service requests/receives attributes from an EUDI Wallet). It is not intended as a general-purpose crosswalk between iSHARE and data space initiatives already covered on the[ Role Nomenclature](/understand-ishare/role-mapping) page. {% hint style="info" %} This mapping is based on the **latest tagged ARF release:** [**v2.7.3**.](https://eudi.dev/2.7.3/#architecture-and-reference-framework) {% endhint %}
iSHARE roleClosest ARF actor term(s)Notes / when this applies
Service Provider Relying Party, Relying Party InstanceWhen the Service Provider requests/receives PID or attestations from a Wallet Unit to deliver a service.
Service Consumer User (often: Wallet User)When the consumer interacts using a Wallet Unit (directly or via a solution acting on the user's behalf).
Human Service Consumer Wallet UserThe human actor controlling/using the Wallet Unit in the interaction flow.
Identity Provider PID Provider and/or Attestation ProviderDepends on what is issued/managed: PID (identity) vs attestations (attributes).
Participant Registry Registrar (e.g., for relying parties); related Trusted List conceptsOnly for wallet-ecosystem registration/listing (not a full equivalent of iSHARE participant lifecycle governance).
Certified PartyConformity Assessment Body (CAB) (closest concept)Only in the sense of conformity assessment/certification used in the EUDI Wallet ecosystem.
Trust AnchorTrust AnchorSame term in ARF; used for anchors that support verification/trust decisions in wallet interactions.
The following iSHARE roles are primarily data-space governance/federation roles out of scope for wallet interaction actor mapping (see [Glossary](https://framework.ishare.eu/glossary-and-legal-notices/glossary)) : * **Scheme Owner** * **Data Space Governance Body** * **Authorisation Registry** * **Identity Broker** # Zero Trust #### Trust in Data Sharing Data sharing requires a strong foundation of trust, which can be established in two main ways: through a standardised onboarding and assessment process or via specific, event-based assessments. These methods are often combined, with organisations tailoring their approach to suit their needs. Frameworks choose to incorporate both, bringing in the concept of zero trust such that trust is verified just in time (of use) rather than assumed. This article aims to clarify how the iSHARE Trust Framework embodies these zero-trust principles, supporting secure and verified data interactions. #### Zero Trust in the iSHARE Trust Framework The iSHARE Trust Framework has always enabled secure data sharing rooted in zero trust principles, where trust is not automatically assumed. Instead, organisations interact based on specific, dynamically verified trust criteria. This model allows for flexible, context-sensitive trust requirements—whether through data space membership, certifications, or recommendations. Zero Trust, at its core, requires that trust be verified, based not on mere presence in the network but on current, context-driven credentials. iSHARE Framework has supported this by establishing trust based on particular conditions relevant to each interaction. Organisations can specify trust requirements—whether tied to specific data spaces, certifications, or other verifiable credentials—ensuring that each interaction meets precise security needs. The iSHARE Trust Framework inherently offers organisations the tools to dynamically set and verify trust levels. To further enable zero trust principles, Verifiable Credentials (RFC040) facilitate context-specific interactions, while multiple identification methods (RFC031) provide flexibility beyond traditional EORI-based verification. Additionally, it enables organisations to engage with others in the network at a more granular trust level, tailored to the specific needs of the data space or organisational standards. The iSHARE Participant Registry (Satellite) has also been designed to align with Zero Trust, using distributed ledger technology to manage interoperability among data spaces. Now, with RFC044, organisations have the option to operate the Participant Registry independently of a distributed ledger, making it adaptable for more flexible trust assessments aligned with Zero Trust. These existing features underscore how the iSHARE Framework supports trust assessments that adapt dynamically to each interaction. #### Trust Verification in iSHARE-based Data Spaces Data spaces using the iSHARE Trust Framework approach trust through a multi-layered assessment process. Data Owners or Providers make trust-based decisions while the Authorisation Registry (AR) stores access policies and manages cross-space trust chains. When Data Consumers request access, their credentials are authenticated, continuously adjusting trust levels as necessary. This ensures a responsive, context-sensitive assessment for interactions across various ecosystems. #### Maintaining Robust Security in a Zero Trust Model Security within a zero-trust model relies on rigorous, continuous verification, with each access request subject to strict identity management and policy enforcement. The AR holds detailed policies to dictate conditions for data access, while the onboarding process fosters mutual vetting between data-sharing parties, supporting decentralised, flexible trust-building that complies with iSHARE specifications. Automated processes for connector and API use minimise errors, bolstering security and ensuring that trust assessments are based on accurate and secure credentials. Regular security testing and compliance with international standards further strengthen the framework against potential threats. #### Additions for Zero Trust The iSHARE Trust Framework is a base layer for data spaces or ecosystems for use in data sharing. This is important to understand in the context of zero trust, as the Framework allows the addition of robust connectors for zero trust checks without hindering any functionality. Organisations can define stricter requirements for their ecosystems beyond the prescribed trust elements provided by the Framework. #### A Continued Commitment to Zero Trust This clarification underscores that Zero Trust has always been central to iSHARE’s approach, allowing for precise, evolving trust assessments. As data-sharing needs grow, iSHARE remains committed to refining its Trust Framework to support secure, dynamic interactions, maintaining the robust, flexible ecosystem that participants rely on for resilient data-sharing.
# General FAQs
What is iSHARE? iSHARE Foundation is a non-profit organisation maintaining the [iSHARE Trust Framework](https://framework.ishare.eu/), which consists of agreements and technical specifications that facilitate secure data exchange between organisations
What are data spaces? Data Spaces are secure environments that allow participants to exchange data freely while adhering to established rules that ensure data sovereignty and transparency. Data spaces support a decentralised approach where data remains with the provider, and only metadata or algorithms are shared. Learn more about this topic in our [Cookbook for Data Spaces](https://ishare.eu/home/ecosystem/ishare-in-data-spaces/cookbook-for-data-spaces-en/).
Why is trust a crucial component in data sharing? Trust is a fundamental factor in data sharing, as it establishes the organisational foundation to exchange data with confidence. It ensures that data sharing is done securely and confidentially, even after it's handed over to other parties. This entails implementing adequate data protection measures, such as encryption and access controls, to safeguard the privacy and security of the data. It minimises the risk of unauthorised access, loss, or theft, which fosters collaboration and innovation. When parties have mutual trust, they are more inclined to openly share data and collaborate on developing new insights and solutions.
How do Data Spaces differ from traditional data exchange models? Traditional data exchanges often involve centralised solutions where data is transferred and stored in a central repository. In contrast, data spaces operate on a decentralized model, allowing data providers to retain control over their data. Participants share only what is necessary, such as metadata or algorithms, without relinquishing ownership of the data itself.
What are the core principles of data spaces? Data Spaces are built on several core principles, including: * **Decentralisation**: Ensuring that no single entity controls the entire data space. * **Openness**: Allowing broad participation while adhering to shared standards. * **Transparency**: Making data usage and governance clear to all participants. * **Sovereignty**: Ensuring data owners retain control over their data. * **Interoperability**: Facilitating seamless data exchange across different systems and platforms.
Why do we need building blocks for Data spaces? Building Blocks are elements essential for designing a data space and promoting its sustainability and growth. These Building Blocks are tailored to meet the specific requirements of different use cases, such as smart cities, fintech, industrial IoT, or healthcare. In general, they serve the following purposes: * Data Interoperability: These building blocks facilitate efficient data exchange among participants, enabling a complete separation between data providers and consumers. * Data Sovereignty and Trust: These building blocks provide technical assets that ensure participants in a data space can trust each other and exercise sovereignty over the data they share * Data value creation: These building blocks support the creation of multi-sided markets where participants can generate value out of sharing data (i.e., creating data value chains). * Data Space Governance: These building blocks consist of a set of agreements and practices that ensure proper management, sharing, and appropriate use of data within the data space.
Is the iSHARE Trust Framework a building block? The iSHARE Trust Framework provides several building blocks for data sharing. This enables secure and standardised data sharing by incorporating agreements and technical specifications for identity and access management. These building blocks can be integrated with other building blocks of data spaces to establish a comprehensive and secure data-sharing environment that aligns with an organisation’s unique needs and requirements.
How is the Participant Registry in the iSHARE network unique? The Hyperledger based Participant Registry is the Trust Anchor and within a data space plays a crucial role in ensuring trust and compliance. It is responsible for evaluating whether parties adhere to the data space agreements. In a data space, the Data Space Governance Body maintains the Participant Registry of data space participants. Each participant in the data space is linked to the Data Space Governance Body through the Participant Registry. They can verify in the Participant Registry whether other parties in the data space are trusted and compliant. When a participant seeks admission to the data space, the Data Space Governance Body verifies their compliance with technical standards, their verified identity, and their signed contract. This onboarding process establishes a user-friendly approach to data sharing while upholding security measures. Certified parties, due to their role in the iSHARE network, undergo a more stringent evaluation process. The Trust Framework also provides an assessment framework to ensure that certified parties meet the specific requirements associated with their role. To learn more about the Participant Registry and its primary use cases within the iSHARE Trust Framework, continue reading [here](https://ishareworks.atlassian.net/wiki/spaces/IS/pages/70222268/Primary+use+cases).
What is different about the iSHARE Trust Framework? The iSHARE Trust Framework serves as the base layer for a data space, playing a crucial role in ensuring trust and compliance. The Trust Framework provides federated governance and data sovereignty to a data space as well as facilitates user-friendly onboarding of compliant parties.
How to start using the iSHARE Trust Framework? You can start using the [iSHARE Trust Framework](https://framework.ishare.eu/) for data sharing by implementing the technical specifications, defining your governance and collaborating with like-minded organisations. We provide the DSSC based [Data space template](http://template.ishare.eu/) to help you define your data space.
How to join a data space based on the iSHARE Trust Framework? You will have to comply with the [technical specifications](https://dev.ishare.eu/demo-and-testing/ctt.html) as well as the [operational](https://framework.ishare.eu/is/admission) and [legal agreements](https://framework.ishare.eu/is/legal) set by the data space. Once the Data Space Governance Body or other delegated entity or organisation has verified that you comply with all the necessary requirements, you can join the data space.
How to set up a data space using the iSHARE Trust Framework? 1. Explore the Technical implementation using our [Developer portal](https://dev.ishare.eu/introduction/getting-started.html) and the [Postman collections](https://dev.ishare.eu/demo-and-testing/postman.html) to understand the iSHARE flows. 2. Request Access to Experimental or Test Data space through . 3. Try Out Adhering Roles using our pre-existing test participant registry. 4. Deploy your own test data space using our [GitHub repository](https://github.com/iSHAREScheme/iSHARESatellite). 5. [Schedule a call with us](http://ishare.eu/contact) to discuss further collaboration and setting up a production level data space based on the iSHARE Trust Framework.
# Introduction iSHARE Trust Framework was developed to improve data exchange between parties. The underlying assumption is that if data can flow in a controlled and efficient way, it will lead to efficient use of infrastructure, less carbon emissions and more competitiveness. iSHARE focuses on three aspects (Identification, Authentication, and Authorisation) as they are considered indispensable in any communication between parties. The iSHARE Trust Framework is used for identification, authentication and authorisation based on OAuth and OpenID Connect standards. The iSHARE Trust Framework facilitates data spaces to organise their governance in addition to IAM and Operational workflows. For the technical implementation of data spaces, there are specific architectural requirements that need to be fulfilled. They are essential for creating a secure, efficient, and interoperable way to foster growth across various sectors. ### Implement the iSHARE Trust Framework in your data space
Learn the Fundamentals Start by learning about the fundamentals of [the iSHARE Trust Framework](https://framework.ishare.eu/introduction/goals-and-scope-of-the-ishare-trust-framework) and the [guiding principles](https://framework.ishare.eu/introduction/guiding-principles).
Explore Your Role [Explore the different roles within the trust framework and the basic M2M and H2M flows](https://framework.ishare.eu/main-aspects-of-the-ishare-trust-framework/key-functionality)
Understand the iSHARE Flows Navigate the [Developer Portal to familiarise yourself with iSHARE flows. ](https://dev.ishare.eu/introduction/getting-started)
Refer to the Open Source Components Our open source API specification can referred to in [Swagger](https://app.swaggerhub.com/search?owner=iSHARE).
Try the Postman Collections Use the [iSHARE Postman collections](https://dev.ishare.eu/reference/postman-collections) to familiarise yourself with data flows and processes.
Walkthroughs and Implementation Access [walkthrough demos](/apply-ishare/quick-walkthroughs) to guide you through various steps in the implementation process, ensuring a smooth and effective setup.
Compliance Testing To verify compliance of your implementation setup, use our automated API testing environment, [Conformance Test Tool (CTT)](https://dev.ishare.eu/introduction/conformance-test-tool) which helps confirm that your API services meet the required standards.
Setting up a test data space Deploy a test data space using the resource available in our [GitHub repository](https://github.com/iSHAREScheme/iSHARESatellite) and DSSC based [Dataspace Template](https://template.ishare.eu/).
Explore the Trust Body of Knowledge For more information on implementing iSHARE, [FAQs](/apply-ishare/technical-faqs), [Technical Standards](/apply-ishare/technical-standards) and [Test Certificates](/apply-ishare/test-certificate) can found in the following sections.
# Test Certificate In order to get an iSHARE Test certificate, the iSHARE organization needs to have: * Your company common name * Your company country * Your company EORI number (used as iSHARE identifier) [Click here](https://ca7.isharetest.net:8442/ejbca/ra/index.xhtml) to request your test certificate directly. To generate certificates and access the test satellite you need to enroll (request new certificate) and generate a test eiDAS certificate by selecting postpone for Key-pair generation. You also require a valid EORI but for the experimental phase, you can use test EORIs. {% hint style="info" %} Note: Please note that test certificates should ONLY be used for testing purposes and to communicate test data. They are not reliable enough to be used for authentication outside of the test network, nor were they designed and distributed for that purpose. The iSHARE organisation provides the test certificates without warranty of any kind, and shall in no event or case be liable for any damage or liability in connection with the use of the test certificates {% endhint %} ### iSHARE Test CA iSHARE Test certificates are issued by the iSHARE Test Certificate Authority. Please download the certificates as they are needed to trust iSHARE Test certificates when interacting with the test environment. In case your knowledge of certificates could use a quick refreshment, please refer to the iSHARE Certificate ‘Cheat sheet’. This document gives a brief overview of common certificate types, how certificates are used within iSHARE and various OpenSSL commands for certificate conversion. Below is the certificate cheat sheet. You can use the script in the following link to extract the certificate public keys and private key in various formats: {% hint style="info" %} For more information on digital certificates, visit [Certificates Cheat Sheet](/apply-ishare/certificates-cheat-sheet). {% endhint %} {% hint style="info" %} [`Various CA roots`](https://ca7.isharetest.net:8442/ejbca/retrieve/ca_certs.jsp) {% endhint %} ### How to get an iSHARE Test Certificate? {% stepper %} {% step %} ### Go to the iSHARE Test Certificate Site {% endstep %} {% step %} ### Choose the Certificate Request Options * Make a new Request * Certificate Type- 'request\_test\_certificate\_server' * Key-pair Generation- 'Postpone' * Token type- 'P12 file' {% endstep %} {% step %} ### Fill in Information Fields * CN, Common Name - 'Test Participant Registry Name' * serialNumber, Serial number (in DN)- 'EU.EORI.CountryORGNAME' * O, Organization - 'Company Name' * C, Country (ISO 3166) - 'NL' {% endstep %} {% step %} ### Provide User Credentials * Username - keep it unique to identify yourself or the organisation. It can be the same as CN * Email- Enter your company email to receive certificate confirmation. (Temporary and Personal Emails won't be considered) {% endstep %} {% step %} ### Confirm Request You will receive an email confirmation of the request with the Status 'Pending' {% endstep %} {% step %} ### Wait for the iSHARE Foundation to process the request You will receive an email confirmation of the request with the Status 'Approved' {% endstep %} {% step %} ### Generate and Download your Test Certificate * The confirmation email contains a link to generate the certificate * Download the .p12 file, which is your certificate with both your public and private keys {% endstep %} {% step %} ### Extract Public and Private Keys * Open the command prompt or terminal and navigate to the location of the .p12 file using cd Command * Once you are in the folder containing .p12 file, enter the Command (Replace filename with the name of your certificate generated) * For Public Certificate: *openssl pkcs12 - in filename.p12 -out publiccert.pem -nokeys -legacy* * For Private Key: *openssl pkcs12 - in filename.p12 -out privatekey.pem -nocerts -legacy* (Password for Private Key will be attached along with Certificate Confirmation Email) * Public Certificate will be created in the same folder under 'publiccert.pem' and Private Key will be created in the same folder under 'privatekey.pem'. You can share only the Public Certificate with your Participant Registry {% endstep %} {% endstepper %} # eSEALS and key vaults **Securing eIDAS eSeal private keys for advanced eSeals with key vault solutions** In the iSHARE ecosystem, ensuring the authenticity and integrity of data exchange is paramount. A crucial component of this is the use of qualified or advanced electronic seals (eSeals) to sign JSON Web Tokens (JWTs). These eSeals rely on eIDAS-compliant certificates, and the secure management of their private keys is of utmost importance. This article explains how key vault solutions can be leveraged to create, store, and utilize these private keys effectively, enhancing security and enabling controlled access for IT providers. ## The Importance of Secure Private Key Management for iSHARE eSeals The private key associated with an eIDAS eSeal certificate is the cryptographic secret that allows an organization to create legally binding electronic seals. Compromising this key would undermine the trust and validity of all signed iSHARE JWTs. Therefore, robust security measures are essential to protect it throughout its lifecycle. While advanced eSeals don't have specific requirements for private key storage, qualified eSeals mandate that keys be stored in a QSCD (which includes USB tokens, smartcards, and certified HSMs). This article outlines how to enhance the security for private keys used in advanced eSeals. ## Key Vaults: A Secure Haven for Private Keys Key vault solutions are purpose-built services designed to securely store and manage cryptographic keys, secrets, and certificates. They provide a centralized and hardened platform with features like: * Hardware Security Modules (HSMs): Many key vaults offer the option to store private keys within tamper-proof HSMs, providing a high level of physical and logical security. * Access Control: Granular role-based access control (RBAC) allows organizations to define precisely who can access and perform operations on the stored keys and secrets. * Auditing and Logging: Comprehensive audit trails track all access attempts and operations performed within the key vault, providing transparency and accountability. * Lifecycle Management: Key vaults often offer features for managing the lifecycle of keys and certificates, including rotation, expiration, and renewal. * Integration with Services: They are designed to integrate seamlessly with various cloud services and applications, allowing for secure key usage without exposing the actual key material. ## Popular Key Vault Solutions Several well-established key vault solutions are available, catering to different infrastructure preferences: * HashiCorp Vault (open source): An open-source and multi-cloud secrets management tool that can be self-hosted or consumed as a managed service. * OVHcloud Key Vault (EU): OVHcloud's secure key management solution, providing HSM-backed key storage and management within their European cloud infrastructure. * Azure Key Vault (global): Microsoft's cloud-based key management service, offering secure storage for keys, secrets, and certificates with robust access control and integration with Azure services. * AWS Key Management Service (KMS) and AWS Secrets Manager (global): Amazon Web Services provides KMS for managing encryption keys and Secrets Manager for securely storing and retrieving secrets, including private keys. * Google Cloud Key Management Service (KMS) and Secret Manager (global): Google Cloud Platform offers KMS for cryptographic key management and Secret Manager for storing and managing sensitive data like private keys. * There are other solutions available. ## Utilising Key Vaults for iSHARE eSeal Private Keys: A Step-by-Step Guide 1. Private Key Generation within the Key Vault: Instead of generating the private key locally, most key vault solutions offer the capability to generate the key pair directly within the secure environment of the vault. This ensures that the private key never leaves the protected boundary. You would typically initiate a key generation process specifying the desired key algorithm (RSA) and key size. 2. Certificate Signing Request (CSR) Generation: Once the key pair is generated, the key vault can often assist in creating a Certificate Signing Request (CSR). The CSR contains the public key and identifying information about the organization. This CSR is then securely transmitted to the chosen eIDAS-compliant Certificate Authority (CA). 3. Certificate Issuance and Storage: After verifying the organisation's identity, the CA will issue the eSeal certificate. This certificate, containing the organisation's public key and signed by the CA, can then be imported and associated with the corresponding private key within the key vault. Some key vaults allow direct import of the certificate, while others might require storing it as a separate secret and establishing the association through configuration. 4. Securely Signing iSHARE JWTs: The crucial aspect is that the private key should never be exported or shared directly from the key vault. Instead, applications and services that need to sign iSHARE JWTs should be configured to interact with the key vault's signing APIs. When a signing request is made, the application sends the data to be signed to the key vault. The key vault then uses the associated private key to perform the signing operation and returns the signed JWT without ever revealing the private key itself. ## Enabling IT Providers with Controlled Access This approach offers a significant advantage when working with external IT providers who need to sign iSHARE JWTs on behalf of an organization. Instead of granting the IT provider direct access to the sensitive private key, the organization can grant the provider's applications or services limited permissions within the key vault. These permissions would typically be restricted to performing signing operations using the specific private key associated with the eSeal certificate. This ensures that the IT provider can fulfill their function without gaining full control over the organisation's private key, significantly reducing the risk of unauthorized access or misuse. The organisation retains full control over the key and can revoke access at any time. Benefits of Using Key Vaults for iSHARE eSeal Private Keys: * Enhanced Security: Private keys are protected within a hardened environment, often backed by HSMs. * Centralised Management: Provides a single point of control for managing eSeal keys and certificates. * Reduced Risk of Key Compromise: Prevents direct access to the private key, minimising the attack surface. * Granular Access Control: Allows precise control over who can perform specific operations. * Improved Auditability: Provides a clear record of all key access and usage. * Facilitates Secure Collaboration: Enables IT providers to perform signing operations without gaining full key access. * Compliance with Regulations: Helps organisations meet the stringent security requirements of eIDAS and iSHARE. While key vaults offer significant security advantages, they also present certain challenges: * Expertise and Misconfigurations: Implementing and managing a key vault demands specific expertise, and misconfigurations can still lead to security vulnerabilities. * Single Point of Failure: Dependence on a key vault creates a single point of failure; if the vault becomes unavailable, services relying on it may be disrupted. * Cost: The cost of deploying and maintaining key vaults, especially those with HSMs, can be substantial. * Integration and Code Modifications: Integrating existing applications with key vaults often necessitates code modifications, which can be time-consuming. * Backup and Disaster Recovery: Organisations must ensure proper backup and disaster recovery strategies for their key vault data. ## Conclusion Leveraging key vault solutions is a best practice for securely managing the private keys of eIDAS eSeal certificates used for signing iSHARE JWTs. By generating and storing private keys within these secure environments and utilizing their signing capabilities, organizations can significantly enhance the security and integrity of their iSHARE transactions. Furthermore, this approach enables controlled access for IT providers, fostering collaboration while maintaining the crucial security of their private keys.
# Procuring advanced or qualified eIDAS eSeal Certificates {% hint style="success" %} Please find guidance on procuring advanced or qualified eIDAS eSeal certificates here: . This information is maintained on GitHub to allow parties to contribute their own experience to it. {% endhint %} # Technical Standards iSHARE can be described as an API architecture, which enables all parties involved to engage in direct communication. For interoperability reasons, iSHARE 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. Pre-registration, therefore, is not a prerequisite and this requires alterations to the official standards. Also, for the authentication of parties within an iSHARE context, iSHARE uses PKI and digital certificates relating to all participating parties. *** ### API 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 directly communicate 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 depending on other applications easier. APIs are used in iSHARE to facilitate direct and realtime communication between different parties, eliminating the need for a central platform. iSHARE APIs are designed to be RESTful, and JSON is used for structuring data. iSHARE prescribes caching requirements relating to the use of APIs in various situations. *** ### Caching Caching is a way to boost performance efficiency. Often data is temporarily stored on a different medium, to enable faster access to the data. For every API exposed under iSHARE caching MUST Be made explicit to the API consumer. If a response is not cacheable it MUST contain the following headers: ``` Cache-Control: no-store Pragma: no-cache ``` If a response is cacheable it MUST contain the following headers: ``` Cache-Control: max-age=31536000 ``` {% hint style="info" %} **Note** max-age MAY vary {% endhint %} *** ### **Date/time formatting** iSHARE adopts internationally recognized standards for expressing dates and times: * **UTC (Coordinated Universal Time)** – Time standard unaffected by time zones or daylight saving time. * **Unix Timestamp** – The number of seconds elapsed since the Unix epoch (1970-01-01T00:00:00Z, UTC). * *Example:* `1536089675` represents **2018-09-04T19:34:35Z**. * **RFC3339 /** **ISO 8601 Date-Time Format** – A human-readable and machine-parseable representation of date and time in UTC, using the Z suffix (as defined in [ISO 8601](https://www.iso.org/iso-8601-date-and-time-format.html) and [RFC 3339](https://www.rfc-editor.org/rfc/rfc3339.html)). * *Example:* `2025-09-22T14:05:30.123Z`. **Requirement**\ All date-time values **MUST** be expressed in UTC and **MUST** follow the ISO 8601 extended date-time format with milliseconds and the `Z` UTC indicator, e.g. `YYYY-MM-DDTHH:MM:SS.sssZ`. Except unless explicitly specified, ISO8601 date-time in UTC is the default format. An exception is for example the iSHARE JWT, which specifies the use of a Unix Timestamp (in line with the JWT standard). ### DID A DID (Decentralised Identifier) is issued to legal entities during onboarding in compliance with the iSHARE framework, utilising the did method. DID Method is used to issue a unique iSHARE identifier to legal entities when onboarding following the iSHARE framework compliant method `did:ishare`. This identifier follows a standardised format conforming to global decentralised identity protocols and points to a REST-compliant API for retrieval. The identifier consists of the organisation’s unique ID as defined by national or international standards (e.g., PKI certificate or eIDAS), ensuring secure identity verification. Core elements about DID can be found [here](https://www.w3.org/TR/did-core/). #### Format The format for `did:ishare` conforms to the \[redacted] specification. It consists of the `did:ishare` prefix followed by *\[ISO 2 Letter Continent Code].\[ISO 2 Letter Country Code].* followed by a URL that points to REST complaint API (returning the DID document) which ends with `/organizationIdentifier` entity identifier in the PKI certificate or nationally recognised legal entity identifier provided by a certified identity provider. The REST endpoint MAY be authenticated. If it needs authentication, then it MUST be complaint to iSHARE Specifications. In case of latter the organistion identifier MUST be the same as the value of organisationIdentifier attribute in the x509 eSEAL certificate should the same entity procure such one at a later time. In short it MUST be complaint to \*/joint-iso-itu-t/ds/attributeType/organizationIdentifier or /joint-iso-ccitt/ds/attributeType/organizationIdentifier \* For example: If the organisation Id of the Organisation ABC Corp is NTRNL0123456789 as defined by the country as nationally recognised legal entity identifier then it must be the organisation ID provided by the certified identity provider of that organisation. Additionally, when the organisation ABC Corp procures the eSEAL certificate (x509) it MUST have the same value in the organisationIdentifier attribute. ``` did-ishare-format := did:ishare:[].[]. organizationIdentifier := value of "/joint-iso-itu-t/ds/attributeType/organizationIdentifier"|"/joint-iso-ccitt/ds/attributeType/organizationIdentifier" (asn1 oid - 2.5.4.97) from the x509 certificate representing eIDAS eSEAL or equivalent ``` Alternatively, nationally recognised legal entity identifier based on the same rules as for x509 eSEALs provided as validated organisationIdentifier by a certified identity provider for roles which do not require x509 certificate during onboarding: ``` did-ishare-format := did:ishare:[].[]. ``` **ID** * Id must be based on the identifier in the PKI certificate where it is equal to or formated from value of organizationIdentifier (asn1 oid - 2.5.4.97). For EU the value contined in the organizationIdentifier is based on the eIDAS specifications. The ID from the identity provider MUST be complaint to \*/joint-iso-itu-t/ds/attributeType/organizationIdentifier or /joint-iso-ccitt/ds/attributeType/organizationIdentifier \*. **Example** A sample of did document can be generated based on crieteria by the participant itself anytime : **DID Document** ``` { "id": "did:ishare:EU.NL.NTRLNL0123456789" } ``` *** ### HTTP(S) HyperText Transfer Protocol (Secure) is a communication protocol. iSHARE Scheme communication MUST be carried out over the HTTP protocol, and secured through TLS 1.2 resulting in HTTPS. iSHARE authentication/authorisation data is generally transferred in HTTP Headers. These headers can become very large when containing multiple encrypted certificates or JWT’s. iSHARE parties SHOULD configure their web servers to accept HTTP headers of larger sizes (usually 10K or more) to minimise implementation impact on current services. The most recent version of the HTTP specification can be found at [w3.org](https://www.w3.org/Protocols/). After sending a HTTP request to a server, the server responds with (among others) a Status Code which indicates the outcome of the request made to the server.
HTTPverbCRUDEntire Collection (e.g. /parties)Specific Item (e.g. /parties/{id})
POSTCreate201 (Created), ‘Location’ header with link to /customers/{id}containing new ID.

404 (Not Found),

409 (Conflict) if resource already exists.

GETRead200 (OK), list of customers. Use pagination, sorting and filtering to navigate big lists.

200 (OK), single customer.

404 (Not Found) if not found or invalid.

PUTUpdate Replace404 (Not Found), unless you want to update/replace every resource in the entire collection.

200 (OK) or 204 (No Content).

404 (Not Found) if not found or invalid.

PATCHUpdate Modify404 (Not Found), unless you want to modify the collection itself.

200 (OK) or 204 (No Content).

404 (Not Found) if not found or invalid.

DELETEDelete404 (Not Found), unless you want to delete the whole collection,not often desirable.

200 (OK).

404 (Not Found) if not found or invalid.

*** ### JSON JSON (JavaScript Object Notation) is a data formatting standard. JSON 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. Within iSHARE, JSON is used as data structuring standard for scheme related communication. For the most recent version of the JSON specification visit [json.org](https://www.json.org/json-en.html). *** ### JWT JWT (JSON Web Token) is an open standard that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. This information can be verified and trusted because it is digitally signed. Because of its size, it can be sent through an URL, POST parameter, or inside an HTTP header. Additionally, due to its size its transmission is fast. A JWT is used in iSHARE when exchanging claims between parties. These claims are signed using the JSON Web Signature (JWS) standard to ensure non-repudiation of these claims. [JWT section](broken://pages/P3Y2TM0H8UmbteRUKA9R) describes how iSHARE uses JWTs and what the specifications for iSHARE JWTs are, while the official standard can be found at [tools.ietf.org (RFC 7519)](https://tools.ietf.org/html/rfc7519). *** ### OAuth 2.0 OAuth is a widely used security standard that enables secure access to protected resources in a fashion that is friendly to web APIs. It is a delegation protocol that provides authorization across systems. OAuth is about *how to get a token* and *how to use a token*. OAuth replaces the password-sharing anti pattern with a delegation protocol that’s simultaneously more secure and more usable. OAuth focused on solving a small set of problems and solving them well, which makes it a suitable component within larger security systems. iSHARE uses the OAuth 2.0 protocol for authenticating parties and providing access tokens when requesting access to a service within iSHARE. For the most recent version of the OAuth 2.0 specification visit [oauth.net](https://oauth.net/2/). *** ### OpenID Connect 1.0 OpenID Connect is a simple identity layer on top of the OAuth 2.0 protocol specific for human subjects. It is used to obtain identity information for a human subject. Besides authenticating a human subject, the OpenID Connect flow can also be used to communicate information of the human subject to a server. For more information please read [official OpenID Connect specification](https://openid.net/specs/openid-connect-core-1_0.html). Just as in OAuth 2.0, iSHARE deviates from the original standard to allow for information exchange with previously unknown parties. Identity Providers need to provide API access to iSHARE participants based on whitelisted PKI, clients need not to be pre-registered at an Identity Provider. *** ### PKI A PKI (Public Key Infrastructure) is a system for 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 PKI’s. 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 as a chain of certificates. At the beginning of the chain is the root Certificate Authority (CA), a public trusted party which is allowed to digitally sign their own certificates (SSC, self-signed certificate). This Root 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 issuing certificates as well, if allowed by their root. They become CA, and as such sign the certificates that they issue. Repeating these steps, a chain of certificates is created, with each certificate signed by the CA who issued the certificate. Parties need to trust a certificate for authentication 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 CA’s are automatically trusted within web browsers, enabling computers to safely interact with most web servers. For authentication purposes, iSHARE requires adhering and Certified Parties to acquire an X.509 certificate which is distributed by a trusted root under certain PKIs (Public Key Infrastructure). For interoperability on a European scale, all trusted roots under the eIDAS regulation will be trusted within iSHARE. The eIDAS regulation aims to provide secure and seamless electronic interactions between businesses, citizens and public authorities throughout the entire EU. A main part of this regulation is that each EU country is required to establish and maintain trusted lists, among which trusted root information is found. Each EU country is required to implement these trusted lists in their own countries. Therefore, iSHARE aims to make use of these trusted lists as trust roots within iSHARE to ensure secure and seamless interaction throughout the EU. ### RESTful Representational State Transfer (REST) 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, JSON and URI. RESTful systems are able to process common HTTP operations, such as GET, POST and DELETE. Within iSHARE RESTful architectural principles MUST be applied to the APIs that are specified. A RESTful API indicates that the API architecture follows REST constraints. Constraints restrict the way that servers respond and process client requests, in order to preserve the design goals which are intended by applying REST. Goals of REST are, among others, performance and scalability. Both are of utmost importance in iSHARE. ### TLS Transport Layer Security (TLS) is a cryptographic protocol that describes communication security for computer networks. It is used to secure the HTTP protocol, resulting in HTTPS. Within iSHARE, TLS versions up to end of life MUST be used for securing all HTTP communications. Currently this means TLS 1.2 or 1.3. For the most recent version of the specification read RFC 5246 *** ### XACML 3.0 XACML (eXtensible Access Control Markup Language) is an XML-based specification that is designed to control access to applications. One of the main advantages of this specification is that applications and systems with their own and different authorization structure can be integrated into one authorization scheme. authorization and the rules surrounding it can be managed centrally regardless of authorization mechanism of the applications themselves. This phenomenon is called externalisation. XACML is derived from SAML and provides the underlying specification for ABAC (Attribute-Based Access Control). XACML is also suitable to be used in combination with RBAC (Role-Based Access Control). Moreover, with the help of XACML authorization can be arranged and managed in detail. This is called fine-grained authorization . XACML supports the use of security labels, rules with arbitrary attributes, rules with a certain duration and dynamic rules. In XACML two main functions can be distinguished. One function defines the criteria with which authorization are assigned, such as ‘only an experienced user from department X is allowed to modify documents’. The other function compares the criteria with the rules or policies to determine whether a person is allowed to perform the operation on the object or not. The architecture of XACML is fairly complex. This is partly due to the fact that it is difficult to fit the various components of XACML in the application landscape. These components should be positioned in such a way that the owner of the data can somehow control the authorization to his or her data, but at the same time the components should be positioned in such a way that the performance is not negatively influenced. This is extra important when independent parties need to cooperate with each other and want to jointly organise the access to their applications. Finally, applications need to be compatible with XACML. XML-based standard for defining authorisation policies. Within iSHARE, a JSON port of XACML 3.0 is used to enable parties to communicate delegation evidence. Visit [docs.oasis-open.org](http://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html) for the most recent version of this specification. *** ### X.509 In cryptography, X.509 is a standard defining the format of public key certificates. X.509 certificates are used in many Internet protocols, including TLS/SSL, which is the basis for HTTPS, the secure protocol for browsing the web. They are also used in offline applications, like electronic signatures. An X.509 certificate contains a public key and an identity (a hostname, or an organization, or an individual), and is either signed by a certificate authority or self-signed. When a certificate is signed by a trusted certificate authority, or validated by other means, someone holding that certificate can rely on the public key it contains to establish secure communications with another party, or validate documents digitally signed by the corresponding private key. The most recent version of this specification can be found at [tools.ietf.org (RFC 5280)](https://tools.ietf.org/html/rfc5280). X.509 is used in iSHARE as a standard defining the format of public key certificates. # Identification # Multiple Identifiers #### Why a Single Identifier is Insufficient for the iSHARE Foundation In the iSHARE Trust Framework, relying on a single identifier for the authentication and onboarding of participants is inadequate due to the complexity of interactions within the data ecosystem. The Framework’s reliance on Economic Operators Registration and Identification (EORI) numbers for identifying participants presents limitations. Not all organisations use EORI numbers, especially those outside international trade and customs. EORI numbers are further limited to European economic operators, excluding non-European entities and organisations operating with industry-specific identifiers, which led to the need for multiple identifiers to lower barriers to iSHARE participation. #### Understanding Multiple Identifiers in the iSHARE Trust Framework The iSHARE Trust Framework promotes secure and standardised data sharing among trusted partners by using multiple identifiers. This approach ensures accurate identification, authentication, and authorisation across the data ecosystem with different roles and implementation processes to maintain trust and security in data sharing. Participants are assigned unique identifiers (such as EORI numbers), validated through digital certificates issued by Identity Providers. These certifications, along with authorisation tokens managed by Authorization Registries, define and control access rights and permissions. This layered approach ensures secure and verifiable interactions between iSHARE participants. #### Types and Roles of Multiple Identifiers in the iSHARE Trust Framework 1. Participant Identifiers: Uniquely identify each entity within the iSHARE Trust Framework, assigned during registration and stored in a central registry. 2. User Identifiers: Identify individual users within participant organisations by linking the internal user management system and integrating it with iSHARE's authentication mechanisms. 3. Service Identifiers: Uses service metadata for service discovery and access requests, which help distinguish between different services or APIs offered by participants. 4. Session Identifiers: Generated dynamically through the session tokens and cookies for tracking user sessions for security and auditing purposes. 5. Unique Identifiers: Ensure each participant is assigned a unique identifier (EORI number) for distinct identity across the iSHARE Trust Framework. #### Technical Implementation of Multiple Identifiers 1. Digital Certification: Issued by Identity Providers to authenticate and validate participant identities, ensuring secure data exchange. 2. Tokens: Issued by Authorization Registries to manage and grant specific access rights. 3. Identification Process: Use Public Key Infrastructure (PKI) to securely manage and verify identifiers, with each participant and service possessing a unique key pair in the iSHARE Trust Framework. 4. Authentication Mechanisms: Ensures robust protocols like JWTs (JSON Web Tokens), which enable the integrity and authenticity of data exchanges. 5. Authorisation Workflow: Defines and enforces authorisation policies, using relevant identifiers to grant users and service permissions. #### Advantages of Using Multiple Identifiers * Enhanced Security: Ensures only verified participants can access services, reducing unauthorised access and simplifying security policy management. * Scalability: Supports the efficient management of a growing number of participants and services. * Interoperability: Consistent identifiers across the iSHARE Trust Framework ensure seamless interaction between diverse systems and services. * Auditability: Comprehensive tracking of identifiers maintains the detailed log's compliance with regulatory requirements. #### Role of Decentralised Identifiers (DIDs) in Managing Multiple Identifiers Decentralised Identifiers (DIDs) manage identifiers in a decentralised manner without relying on central authorities. In the iSHARE Trust Framework, DIDs enable participants to create and control their identifiers, enhancing privacy and security. This includes: * Flexibility: Data Space Authorities can select suitable identifiers for participants with a preference for DID methods. * Unique IDs: Each participant receives a unique iSHARE-ID in the form of a Decentralised Identifier (DID). * PKI Integration: The iSHARE-ID is derived from a participant’s PKI certificate, ensuring secure and verifiable identification. * Alignment with Global Standards: DIDs support global initiatives like GAIA-X, IDS, and EBSI, improving inclusivity and secure data exchange. #### Role of iSHARE ID in the DID Method The iSHARE ID is a unique identifier assigned to each participant within the iSHARE Trust Framework for secure and interoperable data sharing across various data spaces. This identifier is provided in the form of a Decentralised Identifier (DID) and is derived from a participant’s Public Key Infrastructure (PKI) certificate, ensuring data sharing among participants is secure and authenticated. Here’s how it works: 1. DID Format: The iSHARE ID uses the DID format, which ensures that identifiers can be easily resolved and verified across various systems and data spaces. 2. Unique Identification: Each iSHARE ID is derived from a participant's PKI certificate, ensuring that each identifier is securely tied to a verifiable digital certificate. 3. Interoperability: DIDs enable iSHARE IDs to interact seamlessly with other DID-based identification systems, allowing engagement across multiple data spaces without compatibility issues. 4. Multiple Identifiers: DIDs support multiple identifier formats within a single DID document. This means that, in addition to the iSHARE ID, other identifiers such as industry-specific or self-defined identifiers can also be included. 5. Verifiability: Since the iSHARE ID is derived from a PKI certificate, it can be programmatically verified, ensuring trust and security in the participant's identity. #### Updates Introduced by RFC031 in the iSHARE Trust Framework. 1. Alternative Identifiers: The framework now supports multiple identifiers beyond the EORI number, reducing participation barriers. 2. iSHARE-ID: Each participant receives a unique iSHARE-ID in the form of a Decentralised Identifier (DID), derived from their PKI certificate for secure identification. 3. Interoperability: DIDs enable seamless interaction with other DID-based systems, enhancing interoperability across data spaces. 4. Multiple Identifier Support: Participants can include multiple identifiers within a single DID document, allowing broader recognition. 5. Enhanced Cryptographic Methods: The framework incorporates advanced cryptographic techniques for improved security. 6. Support for Decentralised Identifiers: Integrating DIDs reduces reliance on central authorities, increasing security. # eiDAS 2.0 & Digital wallet #### What is eIDAS 2.0? eIDAS 2.0 is the next evolution of the Electronic Identification, Authentication and Trust Services Regulation (eIDAS), which was first introduced by the European Union in 2014. The initial regulation aimed to create a unified framework for electronic identities and trust services across Europe, allowing for secure cross-border transactions between individuals, businesses, and public authorities. With the rapid growth of digital services and the need for more secure, scalable digital identity solutions, the European Commission proposed eIDAS 2.0 in 2021 to modernize the existing framework. This update brings significant improvements in security, usability, and interoperability, ensuring that European citizens and businesses can safely and easily participate in the digital economy. A key innovation under eIDAS 2.0 is the introduction of the European Digital Identity Wallet. This wallet allows users to store and manage digital identification and verification data, such as national IDs, medical certificates, and professional qualifications, in one place. The wallet can be used across both public and private services, offering users more control over their data. In addition to the wallet, eIDAS 2.0 extends its scope to cover a broader range of trust services like electronic signatures and time-stamping, providing a more robust framework for digital transactions across the European Union. #### Key Features of eIDAS 2.0 One of the most prominent features of eIDAS 2.0 is the European Digital Identity Wallet, a new solution aimed at allowing users to store and share their identity and other personal data in a secure and standardized way. The wallet will be available to all EU citizens, residents, and businesses. It enables individuals to authenticate their identity and share verified information across borders, which will be accepted by public and private sectors alike. The wallet not only simplifies identity management but also gives users greater control over what personal data they share and with whom. eIDAS 2.0 also introduces increased interoperability among digital identity systems across EU member states. The regulation sets out standards and technical specifications for secure data sharing and identity verification, ensuring that users can seamlessly verify their identity across borders. This will enable EU citizens to access services in other countries without the need for multiple digital identities or manual verification processes. In addition, eIDAS 2.0 expands on the trust services supported under the regulation, enhancing features like electronic signatures, seals, time-stamping, and website authentication. These enhancements are designed to facilitate secure transactions and promote trust between parties involved in digital interactions. Another critical aspect of eIDAS 2.0 is the mandatory acceptance of the European Digital Identity Wallet by both the public sector and many private services. Governments across the EU will be required to accept the wallet for identity verification and service access. This requirement extends to some private sector organizations, especially those providing essential services such as banking, utilities, and healthcare, where verified digital identities are crucial. #### Relevance of eIDAS 2.0 and the Digital Wallet in Data Sharing and Digital Identity eIDAS 2.0 and the European Digital Identity Wallet are significant advancements for cross-border data sharing and digital identity management in Europe. By providing a secure, standardized method for verifying identity, the regulation removes many barriers to cross-border interactions. For instance, an individual residing in one EU country can use the wallet to access government services or healthcare in another member state without the need for separate verification processes. This interoperability fosters trust and security in cross-border data exchanges, empowering users to control their data in a transparent and compliant manner. One of the primary benefits of eIDAS 2.0 is the simplification of digital identity management. The European Digital Identity Wallet acts as a universal, portable digital identity that can be used across a wide range of services, reducing the need for multiple logins, credentials, or accounts. This harmonized approach helps prevent identity theft and fraud while enhancing the user experience by making digital services more accessible. Whether interacting with public administrations or private services, users can use the wallet to securely share verified information with confidence that their data will be protected. Moreover, eIDAS 2.0 serves as an enabler for data spaces, including sector-specific data spaces like healthcare, energy, or finance. In these data spaces, stakeholders exchange data for various purposes such as research, innovation, or service delivery. The regulation ensures that identities of the participants are securely verified, which is crucial for trusted data exchanges. The framework provided by eIDAS 2.0 also aligns with GDPR principles, ensuring that users maintain control over their data and that sensitive information is shared securely and only with authorized entities. #### How to Authenticate Using a Digital Wallet or Assure Trust? The European Digital Identity Wallet uses a variety of mechanisms to ensure secure digital identity verification. The wallet allows individuals and businesses to store verified digital identity attributes, such as personal identification numbers, diplomas, or licenses. When accessing a service, the wallet enables users to share the required credentials securely. These credentials are verified against trusted sources, such as government-issued IDs or trusted authorities, to ensure that the information is authentic. This process reduces the risk of identity fraud and simplifies the verification process for both users and service providers. In addition, the wallet supports Multi-Factor Authentication (MFA), which adds a layer of security to the authentication process. MFA may involve using a combination of something the user knows (such as a password), something they have (like a mobile device or smart card), and something they are (biometric data such as fingerprints or facial recognition). This layered security approach ensures that only the rightful owner of the wallet can access and share their personal data. The wallet also relies on trusted certificates and cryptographic signatures to assure trust in transactions. When a user shares their data or signs a document using the wallet, the system uses cryptographic keys and certificates issued by trusted service providers to verify the transaction. These digital signatures ensure that the identities involved are legitimate and that the information has not been tampered with, thereby assuring trust in the transaction. One of the most critical features of the wallet is its consent management system, which empowers users to control their data. Before any data is shared, users must explicitly consent to what information they are providing and to whom. This feature ensures compliance with privacy regulations such as the GDPR, giving individuals full transparency over how their data is used. By managing consent, the wallet builds trust between users and service providers, ensuring that data exchanges are both secure and ethical. Finally, trust in the digital identity ecosystem is ensured through a system of trust anchors, which are certified trust service providers that issue digital certificates for identity verification. These trust anchors form the foundation of the eIDAS 2.0 framework, ensuring that all identity verification processes and transactions are backed by reliable and certified authorities. The entire chain of trust is verifiable, giving users and service providers confidence that the identities involved in digital transactions are authentic and secure. #### Conclusion eIDAS 2.0 and the European Digital Identity Wallet are foundational components of Europe’s digital transformation. By providing a secure, interoperable, and user-centric digital identity solution, eIDAS 2.0 facilitates trusted cross-border transactions and data sharing while safeguarding individual privacy. As digital identity becomes increasingly critical to a wide range of sectors—from healthcare to finance—the introduction of this regulation ensures that Europe remains at the forefront of secure digital innovation, enabling both individuals and businesses to thrive in a digitally interconnected world.
# Authentication In today’s interconnected digital landscape, secure data sharing is critical, and the iSHARE Trust Framework plays a key role in facilitating this. iSHARE Framework uses a federated governance model, allowing diverse entities to collaborate based on shared rules. This article will explore the mechanism of authentication within iSHARE Trust Framework with a specific focus on the OAuth protocol, how it ensures trust, and the flexibility it provides to participants. ### iSHARE Trusted Framework’s Federated Governance Model and Trust iSHARE Trust Framework operates within a “federated model”, where different organisations collaborate under a common governance model. This shared governance ensures that all participants agree on the rules for securely sharing data while maintaining the autonomy of individual relationships. In this system, parties must be “discoverable”, adhering to specific trust or onboarding requirements that guarantee they meet ecosystem standards. However, authentication within iSHARE Framework is not rigidly defined—there’s flexibility in how participants manage access approvals. While iSHARE Framework sets the groundwork for secure interactions, the ultimate decision to grant access lies with the data owners and service providers, providing a balanced approach to security and operational flexibility. ### OAuth in iSHARE Trust Framework iSHARE Trust Framework uses the[ OAuth 2.0](https://trustbok.ishare.eu/apply-ishare/technical-standards) protocol for authenticating parties and providing access tokens when requesting access to a service within iSHARE. For the most recent version of the OAuth 2.0 specification visit[ oauth.net](https://oauth.net/2/). OAuth 2.0 plays a central role in iSHARE Trust Framework’s authentication process. OAuth allows trusted entities to securely share data without exposing sensitive credentials, like usernames and passwords. In iSHARE Framework, OAuth is enhanced by iSHARE-specific requirements that ensure compatibility with the federated trust model. OAuth is a widely used security standard that enables secure access to protected resources in a fashion that is friendly to web APIs. It is a delegation protocol that provides authorization across systems. OAuth is about how to get a token and how to use a token. OAuth replaces the password-sharing anti pattern with a delegation protocol that’s simultaneously more secure and more usable. OAuth focused on solving a small set of problems and solving them well, which makes it a suitable component within larger security systems. ### Key Elements of OAuth in iSHARE: #### • Real-Time Authentication: Rather than requiring pre-registration, OAuth in the iSHARe Framework enables real-time verification of organisations through the Participant Registry. This approach allows participants to interact with new organisations instantly, based on their adherence to the ecosystem's protocols. #### • Public Key Infrastructure (PKI): Trust between organisations is established through PKI certificates, which verify the identities of participants. These certificates are checked against a trusted list maintained by the Participant Registry, and only organisations with valid status can engage in data-sharing activities. PKI is very useful to computer systems for tracking and sorting dated information in dynamic and distributed applications both online and client side. OAuth, in conjunction with PKI, ensures that authentication is robust yet flexible, allowing interactions between previously unknown parties. ### Discoverability and Zero Trust A core component of iSHARE Trust Framework is discoverability. Associations can make themselves visible within the network, while individual members remain private, enhancing security and flexibility. This setup is aligned with the principles of a zero-trust environment, where no participant is inherently trusted. All interactions are authenticated and verified in real-time, relying on the OAuth 2.0 flow for the secure exchange of tokens, allowing participants to trust each other dynamically without prior relationships. ### Authentication in iSHARE iSHARE Trust Framework has a unique approach to authentication, which centres around the OAuth protocol and a flexible governance model. iSHARE Trust Framework offers more autonomy to data owners and allows for tailored conditional authorizations based on specific requirements. ### Conditional Authorization and Flexibility The Framework’s flexibility extends to conditional authorisations. Data owners can specify conditions that must be met before access is granted, such as the fulfilment of legal, security, or contractual obligations. This is supported by OAuth 2.0, which allows for fine-grained access controls via tokens. Each token encapsulates the precise scope of access, making it easy for data owners to enforce their policies while adhering to the overall governance of the ecosystem. The inclusion of conditional authorisations provides organisations with the flexibility to maintain control over their data while adhering to strict security standards. ### Building Trust Iteratively Trust in iSHARE Trust Framework is built iteratively between associations. In the early stages of data-sharing relationships, trust may be limited, but it allows for progressive collaboration. OAuth’s flexible authentication process, combined with additional the trust mechanisms, allow participants to progressively increase their confidence in their data-sharing partners. ### Conclusion Authentication flows are built on a foundation of trust, flexibility, and layered security, with OAuth 2.0 serving as the backbone for secure interactions. By allowing for real-time verification and dynamic interactions, the Framework provides an adaptable and scalable solution for organisations that need to share data securely across associations. As the Framework continues to evolve, ongoing improvements in trust mechanisms and security features will further solidify its role in facilitating safe, and by enhancing role clarity, and enabling fine-grained delegation policies, iSHARE is not only reinforcing its position in the federated governance space but also laying the groundwork for future-proof data ecosystems. # oAuth Implementation ### OAuth in the iSHARE Trust Framework The iSHARE Trust Framework has always enabled secure, certificate-based authentication between participants without bilateral preregistration at each Service Provider. This approach is grounded in self-sovereign principles: organisations authenticate using their eIDAS or eSeal certificates (PKI-based certificates), dynamically validated against the iSHARE Participant Registry. While OAuth 2.0 is widely used as an industry standard for token-based authentication, most off-the-shelf implementations assume that every client must be preregistered with an Authorisation Server before obtaining a token. iSHARE’s design takes a different path: preregistration is handled centrally through the Participant Registry rather than separately at every Service Provider. As a result, Service Consumers generate JWT client assertions signed with their certificates, and Service Providers verify them directly in real time. Despite this difference, iSHARE does not diverge from OAuth principles. Its authentication process closely follows the Client Credentials Grant described in RFC 7521 Section 6.2, where a client acts on its own behalf by presenting a digitally signed JSON Web Token. RFC 7523, which defines JWT profiles for OAuth 2.0, matches iSHARE’s mechanism: the Service Consumer generates a client\_assertion signed with its certificate, and the Service Provider validates this assertion against trusted certificate roots listed in the iSHARE Participant Registry. This article aims to clarify how the iSHARE Trust Framework implements OAuth 2.0 in a way that supports dynamic, certificate-based trust while remaining aligned with established industry standards. It explains how iSHARE specifications build on OAuth profiles such as RFC 7521 and RFC 7523, why Service Consumers do not need to preregister with Service Providers, and which libraries already support these mechanisms. This article reflects the outcome of RFC051, which was approved by iSHARE to provide further clarity on its OAuth implementation. ### A Standards-Based Approach The alignment between iSHARE and these RFCs means that Service Providers do not need to develop custom authentication systems. Existing OAuth 2.0 libraries already support JWT-based client assertions and can be configured or extended further to satisfy iSHARE’s certificate validation requirements. Mature tools such as Keycloak for Java, Authlib for Python, and Duende Identity Server for .NET provide native support for these flows. Similarly, cryptographic libraries such as Bouncy Castle, OpenSSL and Python’s cryptography module can perform X.509 certificate validation, including checking certificate chains, revocation status, and key usage attributes. For developers, this means implementing iSHARE does not require building new security components. Instead, it is a matter of configuring well-known components to base authentication on certificates rather than on local preregistration. This lowers implementation effort, avoids duplication, and reduces the security risks that come with custom code. By aligning with RFC 7521 and RFC 7523, iSHARE remains interoperable with mainstream OAuth 2.0 tooling while preserving its decentralised trust model. ### How OAuth Works in iSHARE Each Service Provider hosts its own /token endpoint. When a Service Consumer wants to access a service, the Service Consumer creates a self-signed JWT client assertion using its eIDAS or eSeal certificate and sends this in a POST /connect/token request to the Service Provider. The Service Provider validates the signature, checks the certificate chain against trusted Certificate Authorities listed in the iSHARE Participant Registry, and verifies that the certificate is valid and not revoked. To complete the process, the Service Provider creates its own iSHARE client assertion and exchanges it with the Participant Registry for an access token. It may then query the registry to confirm party details such as identity, certificate, and status. If the verification succeeds, the Service Provider issues a bearer token to the Service Consumer for use in subsequent API calls. This approach means that Service Providers do not need to maintain client registries. Trust is established dynamically at runtime, ensuring a fully decentralised model.
Figure 1: iSHARE oAuth M2M Authentication Flow For a more detailed technical reference on how authentication flows are implemented in practice, including request formats and validation steps, see the[ iSHARE Developer Portal](https://dev.ishare.eu/reference/authentication). ### Supporting Implementations The main work is configuring standard libraries to perform certificate trust-chain validation against the iSHARE Participant Registry. To help participants adopt these flows with confidence, iSHARE Foundation is extending its developer documentation to explain how iSHARE maps directly onto OAuth 2.0 standards. The documentation will provide guidance on configuration patterns, practical examples, and a curated list of libraries that already support JWT-based assertions and certificate validation. These resources will enable Service Providers to integrate iSHARE authentication flows quickly, securely, and without unnecessary complexity. ### A Continued Commitment to Standards The approval of [RFC051](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/20) confirms that iSHARE’s OAuth implementation remains aligned with widely adopted industry standards while retaining its core principles of decentralisation and dynamic trust. By using certificates validated against the Participant Registry, iSHARE participants achieve secure, standards-compliant authentication without bilateral preregistration — a design that supports interoperability across diverse data spaces and technology stacks. This clarification underscores that iSHARE is not diverging from OAuth but extending it in a way already foreseen by its own RFCs. As new tools and frameworks continue to mature, iSHARE participants will increasingly benefit from library support that reduces integration effort while maintaining full compliance with the Trust Framework.
# Authorisation Server under Service Provider ### Delegating Authentication in Data Sharing Authentication is a fundamental element of trust in data sharing. As previously mentioned, in the iSHARE Trust Framework, this is achieved through dynamic, certificate-based mechanisms that remove the need for preregistration at each Service Provider. While effective, this approach requires every Service Provider to implement its own authentication endpoint. For some organisations, this can create operational challenges, increase maintenance effort, and raise the barrier to entry. To address this, RFC051 introduced the option of delegating authentication to an Authorisation Server operating under the responsibility of the Service Provider. This article clarifies how such a role fits within the iSHARE Trust Framework and what it means for participants across the ecosystem. ### Authorisation Servers in the iSHARE Trust Framework The concept of an Authorisation Server is well established in OAuth 2.0. It is responsible for validating credentials and issuing bearer tokens that clients can present to access protected resources. Within iSHARE, the same principle can apply, but adapted to certificate-based authentication and the Participant Registry. In this option, a Service Provider may rely on an Authorisation Server (sometimes also referred to as a Security Token Service, STS) within its trusted zone. The Authorisation Server validates client assertions, checks the certificate against the iSHARE Participant Registry, and issues an access token. The Service Provider then accepts this token as proof of authentication, reducing the need to implement these steps directly. From the perspective of the Service Consumer, the process remains unchanged. It generates a signed client assertion with its certificate and submits this to the Service Provider’s /token endpoint. What happens next differs: rather than the Service Provider validating everything itself, it forwards the assertion to its Authorisation Server. The Authorisation Server performs the cryptographic checks, validates the certificate against the Participant Registry, and exchanges its own client assertion with the Registry to confirm the Service Consumer’s details and compliance. Only once this chain of validation succeeds does the Service Provider receive a bearer token that it can safely issue to the Service Consumer. The diagram below illustrates this end-to-end flow in a machine-to-machine (M2M) scenario, showing the interactions between the Service Consumer, Service Provider, Authorisation Server, and the iSHARE Participant Registry.
Figure 1: iSHARE Authentication flow with Authorisation Server under SP - M2M This separation of responsibilities allows Service Providers to rely on specialised, standards-based infrastructure for token issuance and validation, while preserving iSHARE’s decentralised trust model. ### Benefits and Implications Delegating authentication to an Authorisation Server offers significant advantages. First, it lowers the complexity for Service Providers. Instead of maintaining custom implementations of the /token endpoint, they can make use of an Authorisation Server that is already configured to handle JWT-based client assertions and certificate validation. This reduces the risks of errors and ensures a more consistent security posture. Second, the Authorisation Server role is transparent to other participants in the ecosystem. From the outside, nothing changes: the Service Consumer interacts with the Service Provider as before, unaware that the Service Provider is relying on an Authorisation Server internally. This means no additional coordination or onboarding is needed with other parties. Third, this option creates flexibility in how Service Providers adopt iSHARE. They can choose to run their own Authorisation Server, or contract a third party to provide one, as long as it is iSHARE-compliant. In such cases, the Service Provider and the Authorisation Server provider bilaterally agree on service conditions, but the Service Provider remains fully responsible within the iSHARE framework. Fourth, using an Authorisation Server under the Service Provider role preserves the neutrality of the Participant Registry. Unlike other models where the Participant Registry would act itself as the central token service, this option avoids introducing additional liabilities or centralisation at the registry level. This keeps iSHARE aligned with its decentralised design principles. Finally, Authorisation Servers may also act as bridges between different data spaces. By verifying assertions and issuing tokens across boundaries, they can enable interoperability without requiring every Service Provider to directly manage cross-space authentication. In some scenarios, privacy may even improve. Since the Service Consumer interacts only with the Service Provider, details of its activities may not be directly visible to other infrastructure components. These benefits come with clear boundaries: accountability does not shift. Service Providers remain responsible for the authentication processes they rely on, even if they delegate the technical implementation to an Authorisation Server. They must ensure that certificate validation against the Participant Registry is correctly performed, and that the Authorisation Server operates within agreed compliance levels. ### Maintaining Alignment with Standards Introducing an Authorisation Server under the Service Provider role brings iSHARE even closer to mainstream OAuth practices while retaining its distinct approach to decentralised trust. By leveraging RFC 7521 and RFC 7523, Service Providers can configure existing identity and access management tools to support iSHARE’s certificate-based model. This creates opportunities to scale implementations more efficiently while maintaining full compliance with the Trust Framework. ### A Continued Commitment to Secure Data Sharing The approval of RFC051 confirms that using an Authorisation Server under the Service Provider role is fully compatible with iSHARE principles. It is not a replacement for iSHARE’s existing model but an option that participants can adopt to reduce complexity and improve alignment with OAuth standards depending on the specific use-case scenario. This clarification reflects once again iSHARE’s ongoing commitment to lowering entry barriers, supporting flexible implementation choices, and maintaining a robust foundation for trusted data sharing. # Authorisation Within the iSHARE Trust Framework, authorisation is the answer to a fundamental question in any data space: who is allowed to access what, under which conditions, and on whose behalf? Getting this right, especially across organisations that may be unknown to each other, operating in different sectors, or under different legal regimes, is one of the hardest challenges in data sharing. iSHARE addresses it through a structured, flexible, and delegable model for authorisation. This article explains how that model works: the concepts it is built on, the roles it involves, and the technical and governance layers that make it trustworthy across complex, multi-party environments. ### The problem authorisation solves Trust in a data space does not end with knowing who someone is. Identification tells you a party is who they claim to be. Authorisation tells you what that party is actually permitted to do. Without a shared, interoperable way to express and verify those permissions, data providers are left with two options: either they only share data with parties they personally know and have individually contracted, or they open access broadly and lose control. iSHARE is designed to offer an alternative option, where you can share data with new parties that control the access. By standardising how authorisations are expressed, delegated, stored, and verified, the framework makes it possible for a data provider to share information with a party they have never met before, as long as that party can demonstrate it is acting on behalf of someone the data provider trusts. This is what enables data exchange at scale, across sector and organisational boundaries. Example: Party C does not know Trucking Company B. But Party A — whom Party C does know — has delegated rights to Trucking Company B, and registered that delegation at an Authorisation Registry. Party C can verify the delegation and serve the request, without needing a direct relationship with Trucking Company B beforehand.

Figure 1. Example of a delegation trust chain.

### Where authorisation fits in the trust chain iSHARE structures trust across three interdependent layers: * Identification — establishing that a party exists and is registered in the ecosystem * Authentication — verifying that a party is who it claims to be in a given interaction * Authorisation — confirming what that party is permitted to do, and on whose behalf These layers build on each other. Authorisation is only meaningful if the party has first been identified and authenticated. Together, they form the foundation for secure, verifiable data exchange between parties across a data space. ### Three dimensions of flexibility One of the core design principles of the iSHARE authorisation model is flexibility. Organisations participating in data spaces have vastly different needs, different sectors, different data sensitivity levels, and different governance structures. The framework, therefore, supports authorisation that is flexible in three distinct ways:

Figure 2. Flexibility on authorisation

### Delegation: authorisation beyond known parties At the heart of iSHARE's authorisation model is delegation. A delegation is a formal, verifiable statement that an Entitled Party/ Data Rights Holders — the organisation that holds the original right to access a service or data set — has transferred (part of) those rights to another party, which then acts as a Service Consumer on their behalf. Delegation makes it possible to do something that would otherwise require bilateral contracts between every pair of parties: it allows a data provider to accept access requests from parties it has never directly contracted with, as long as a trusted chain of delegation can be verified. The party receiving the delegation does not need to be known in advance. The delegation evidence is what grants access. Delegations can also be chained: Party A delegates to Party B, who delegates to Party C. As long as the chain is valid and verifiable, Party C can act on behalf of Party A — even across multiple registries and organisations. The rules governing how these chains are constructed, verified, and limited are described in detail in the [Delegation Chains](/apply-ishare/authorisation/delegation-chains) section. ### Management of consent Granting access is only half the picture. The iSHARE framework places equal importance on the ability to modify or withdraw access at any moment. This is referred to as management of consent, and it is what gives data owners genuine control over their data, not just at the moment of initial setup but continuously throughout the data sharing relationship. When a delegation is revoked, it takes immediate effect. A party that previously had valid delegation evidence will find that evidence invalid on the next verification check. There is no lag, no grace period by default, and no way for the downstream party to continue acting on a revoked authorisation. This is enforced at the level of the Authorisation Registry, which must prevent revoked delegations from being processed as valid. {% hint style="info" %} This is a normative requirement: the Authorisation Registry MUST prevent a revoked delegation from being processed as a valid delegation. {% endhint %} ### M2M and H2M authorisation The iSHARE authorisation model supports both Machine-to-Machine (M2M) and Human-to-Machine (H2M) interactions, recognising that data spaces involve both automated system integrations and human users acting on behalf of organisations. #### Machine-to-Machine ([M2M](https://framework.ishare.eu/use-cases/use-case-m2m-interaction-with-fine-grained-authorization)) In M2M flows, a Machine Service Consumer requests access to a service or data set. The Service Provider verifies the request by checking delegation evidence either held internally or retrieved from an Authorisation Registry. The entire flow is automated: no human involvement is required once the delegation has been registered. This is the primary flow for ERP-to-ERP integrations, logistics systems, and other machine-operated data exchanges. #### Human-to-Machine ([H2M](https://framework.ishare.eu/use-cases/use-case-h2m-interaction-with-coarse-grained-authorization)) In H2M flows, a human user acts on behalf of an organisation. Identity verification uses [OpenID Connect 1.0](https://dev.ishare.eu/introduction/specific-technical-standards/openid-connect-1.0), extended by iSHARE to include organisational authorisation. The Service Provider checks both who the user is and what their organisation has authorised them to do. To protect individual privacy, users are identified through pseudonyms rather than personal identifiers, in alignment with GDPR requirements. Two interaction patterns exist for H2M: a service-specific check (verifying access to one specific service) and a portal approach (retrieving all authorisations available to the user in order to surface relevant services). ### The role of the Authorisation Registry The Authorisation Registry (AR) is the role in the iSHARE ecosystem that makes delegation scalable. Rather than requiring each organisation to build and operate its own authorisation infrastructure, the AR provides a shared, certified service for storing delegation policies and issuing delegation evidence. When a Service Provider needs to verify whether a Service Consumer has the right to act on behalf of an Entitled Party, it requests delegation evidence from the relevant Authorisation Registry. The AR evaluates the stored policies against the request and returns a signed response either confirming or denying the delegation. The Service Provider then makes its access decision based on that evidence. The Authorisation Registry is described in full on its own page, including its functional requirements, deployment models, and role in the iSHARE v3.0 architecture. See the next page. # The Authorisation Registry The [Authorisation Registry (AR)](https://framework.ishare.eu/main-aspects-of-the-ishare-trust-framework/framework-and-roles#authorisation-registry) is a role in the iSHARE Trust Framework responsible for storing delegation and authorisation information and issuing delegation evidence on behalf of [Entitled Parties](https://framework.ishare.eu/main-aspects-of-the-ishare-trust-framework/framework-and-roles?fallback=true#entitled-party). It is the operational backbone of scalable, interoperable authorisation in a data space. This page describes what the AR is, what it must do, how it fits within the broader architecture, and how it has evolved in [iSHARE Trust Framework](https://framework.ishare.eu/). ### What the Authorisation Registry does The Authorisation Registry role is fulfilled by a legal entity that provides solutions for Entitled Parties for the storage of delegation and authorisation information. In practical terms, an AR: * Holds delegation evidence on behalf of [Entitled Parties](https://framework.ishare.eu/main-aspects-of-the-ishare-trust-framework/framework-and-roles?fallback=true#entitled-party) which is the information indicating which parts of an Entitled Party's rights have been delegated to a [Service Consumer](https://framework.ishare.eu/main-aspects-of-the-ishare-trust-framework/framework-and-roles#service-consumer) acting on its behalf. * Evaluates whether a party is authorised to take delivery of a data/service, based on the stored delegation information. * Evaluates the Entitled Party's policies and returns the outcome as signed delegation evidence, which the [Service Provider](https://framework.ishare.eu/main-aspects-of-the-ishare-trust-framework/framework-and-roles#service-provider) relies on to make its access decision. * Supports the registration, update, and revocation of delegations. * Can issue [DataRights Verifiable Credentials](https://framework.ishare.eu/detailed-descriptions/technical/structure-of-delegation-evidence/data-rights-credential-vc) on behalf of Entitled Parties, for use in VC-based authorisation flows * Can expose delegation evidence via standard endpoints for both [machine (M2M)](https://framework.ishare.eu/use-cases/use-case-m2m-interaction-with-fine-grained-authorization) and [human (H2M)](https://framework.ishare.eu/use-cases/use-case-h2m-interaction-with-coarse-grained-authorization) consumers As a result, Entitled party can outsource the management of authorisation and delegation information to an Authorisation Registry, rather than building and maintaining their own tooling. ### Normative requirements The following requirements apply to any party fulfilling the Authorisation Registry role within the iSHARE Trust Framework: * The AR MUST have a clear agreement with the delegating entity concerning the process of registering, updating, or removing a delegation. * The AR MUST prevent a revoked delegation from being processed as a valid delegation * The AR MUST conform to the service levels for Certified Parties * The AR MUST NOT claim accordance with a Level of Assurance for which it has not been certified by the Scheme Owner * The AR MAY support receiving and processing delegation creation requests in line with iSHARE specifications * The processes of the AR MUST be in accordance with the Level of Assurance for which it has been certified * The AR MUST be listed in a Participant Registry as a participant in the role of Authorisation Registry (certified role) with level of assurance and compliance status {% hint style="info" %} For technical implementation requirements, refer to the [Authorisation Registry getting started page](https://dev.ishare.eu/authorisation-registry-role/getting-started). {% endhint %} ### Position in the iSHARE architecture The Authorisation Registry operates at the authorisation layer of the iSHARE architecture. The layer concerned with what parties are permitted to do, once they have been identified and authenticated. It interacts with several other roles in the framework:

Figure 3. Diagram of the AR in the iSHARE architecture

#### Participant Registry The Participant Registry is where an AR is listed and discoverable. When a Service Provider needs to verify delegation evidence, it can look up the relevant AR through the Participant Registry. The AR must be registered there with its role, Level of Assurance, and compliance status. In v3.0, the AR may also be discoverable per capability or per data space through Participant Registry entries, giving Service Providers a structured way to find the right AR for a given interaction. #### Entitled Party The Entitled Party is the organisation that holds the original right to a service or data set, and that delegates (part of) those rights to others. The Entitled Party registers delegations at the AR. It is also responsible for managing those delegations over time, including revocation. The AR acts as the Entitled Party's authorisation infrastructure, not as an independent authority. #### Service Provider The Service Provider is the data or service provider that receives access requests and must verify whether the requesting party is authorised. It contacts the AR to obtain delegation evidence, then validates that evidence to make its access decision. In some flows, the Service Consumer may collect and present the delegation evidence directly, but the AR remains the source of that evidence. #### Service Consumer The Service Consumer (or its Machine Service Consumer) is the party requesting access. It may present delegation evidence that it has pre-collected from the AR, or allow the Service Provider to retrieve it. In VC-based flows, the Service Consumer holds a Data Rights Credential issued by the AR and presents it directly. ### How an authorisation decision is made Understanding the AR's role is easiest through the step-by-step flow of a typical M2M authorisation decision:

Figure 4. Example of M2M authorisation decisions

### Benefits of the Authorisation Registry model The AR model provides value at multiple levels of the ecosystem:

Figure 4. Example of M2M authorisation decisions

### Evolution of the Authorisation Registry The iSHARE Trust Framework has introduced several important extensions to the Authorisation Registry model, reflecting lessons from real-world data space deployments and the growing maturity of the ecosystem. #### Multiple ARs per service or capability An Entitled Party can assign a different AR per service or capability, rather than being bound to a single registry across all contexts. A logistics company might use a sector-specific AR for shipment status delegations and a community AR for port berth allocations, without any conflict. Service Providers discover the applicable AR through a structured lookup process (described [here](https://dev.ishare.eu/reference/authorization)). #### Conditional delegation Delegations can be constrained by time windows, data attributes, certification levels, or other contextual conditions. This makes it possible to express much more precise authorisation rules. For example, a delegation that is only valid during working hours, or only for data below a certain sensitivity threshold. (See more [here](https://dev.ishare.eu/reference/delegation-conditions)) #### Verifiable Credentials integration The framework supports a VC-based variant for authorisation flows. Instead of retrieving delegation evidence from an AR at runtime, a Service Consumer can hold a Data Rights Verifiable Credential issued by the AR and present it directly to the Service Provider, reducing latency and supporting offline or constrained environments, while maintaining the same governance guarantees. #### Improved discoverability ARs can be discovered per capability through the Entitled Party's [/capabilities endpoint](https://dev.ishare.eu/all-roles-common-endpoints/capabilities), rather than only through a global Participant Registry entry. This makes discovery more precise and reduces the risk of a Service Provider contacting the wrong AR for a given interaction.
# Delegation Delegation is the mechanism through which an Entitled Party transfers (part of) its rights to another party, enabling that party to act on its behalf in a data space. It is what makes iSHARE's vision of data exchange between previously unknown parties possible in practice. This section introduces the concept of delegation, explains how it works within the iSHARE framework, and provides the foundation for understanding the more detailed topics that follow: delegation chains, policy storage, and AR per capability. ### What delegation is When an organisation holds the right to access a service or data set (as an Entitled Party), it does not always act on that right directly. It may hire a transporter, appoint a representative, or integrate a third-party system. Delegation is the formal, verifiable record of that appointment. In iSHARE, a delegation takes the form of a [delegation evidence](https://framework.ishare.eu/detailed-descriptions/technical/structure-of-delegation-evidence) object: a signed statement, issued by an Authorisation Registry, that confirms a specific party has been granted specific rights by a specific Entitled Party, under specific conditions. Service Providers use this evidence to decide whether to serve a request, without needing a direct contractual relationship with the requesting party. {% hint style="info" %} Delegation evidence is not a password or a session token. It is a structured, policy-governed statement about who has been authorised to do what, on whose behalf, under what conditions. It can be evaluated, chained, and revoked. See more [here](https://framework.ishare.eu/detailed-descriptions/technical/structure-of-delegation-evidence) {% endhint %} ### Delegation Evidence The delegation evidence is the signed response from the AR. It confirms whether the requested delegation is valid and, if so, under what conditions. It is the artefact that the Service Provider uses to make its access decision. The [structure of delegation evidence](https://framework.ishare.eu/detailed-descriptions/technical/structure-of-delegation-evidence) follows the iSHARE specification precisely: rules within delegation evidence must ensure consistent evaluation across ARs. ### Conditions in delegation iSHARE introduces conditions as a formal element of delegation policies. A delegation can now be valid only under specified conditions, for example: * Time-based conditions: the delegation is only valid between certain dates or times * Attribute-based conditions: the delegation applies only when the requesting party holds a specific certification or attribute * Data-scoped conditions: the delegation applies only to data meeting specific criteria Conditions can be evaluated either at the AR (during evidence issuance) or at the Service Provider (at access time), depending on what information is available where. The framework specifies the evaluation logic and what must be documented for audit purposes. ### Revocation and management of consent A delegation can be revoked at any time by the Entitled Party. Revocation is immediate: once a delegation is revoked at the AR, subsequent evidence requests for that delegation will return a denial. Service Providers should not cache delegation evidence beyond its stated validity period, and should revalidate on each access request for sensitive resources. This revocation capability is what gives Entitled Parties genuine control over their data, not just at the point of granting access, but continuously, for as long as the delegation exists.

Figure 5. Revocation and management of consent

# Delegation Chains This article explains how delegation chains can be managed in line with the iSHARE Trust Framework. It does not introduce new specifications, but rather explains how the existing delegation specifications can be applied in different ways. The aim is to highlight patterns for managing delegation chains in complex data spaces, drawing on both research and real-world practice. Different models are possible, and the model choice may vary across data spaces or even individual parties. The approaches described here are therefore illustrative and not prescriptive. Altogether, participants are encouraged to evaluate which patterns best fit their requirements, to adapt them as needed, and to share their experiences with the iSHARE Foundation so that the ecosystem can continue to refine and optimise delegation practices. Overview of Delegation Models: * [Recursive Path Models](/apply-ishare/authorisation/delegation-chains/recursive-path-models): Each delegation points to its previous step so the full path can be reconstructed. (Variants: Previous Party-ID and Previous Delegation-ID). * [Concatenation Models](/apply-ishare/authorisation/delegation-chains/concatenation-models): Each new delegation is embedded in the chain (or an ID list) for single-step validation. Trades some privacy and flexibility for performance. * [Macaroon Model](/apply-ishare/authorisation/delegation-chains/macaroon-model): Token-based delegation with caveats; efficient and private, more complex to revoke and govern. ### Delegation in Complex Data Sharing Data sharing is crucial for enabling third parties (including companies, individuals, and public institutions) to access data sets for the development of new applications and services. The iSHARE Trust Framework was developed to facilitate trusted data exchange between parties, particularly focusing on identification, authentication, and authorisation (IAA). These elements are indispensable for any communication between parties in a data-sharing environment. In practical implementations, particularly within the larger supply chains, delegation chains are a common occurrence. For example, a shipper authorises Transporter A, who subcontracts to B, who relies on C. When C arrives at the warehouse, it must prove it acts legitimately on the shipper’s behalf, which requires validating the entire delegation path. Similar multi-hop patterns occur in healthcare referrals and other domains. This creates a complex delegation chain that must be managed effectively to ensure security, privacy, and efficiency. A visual example from the healthcare sector is portrayed below:

Figure 6: A simplified illustration of a single delegation chain.

Within iSHARE, evidence objects already carry links that help reconstruct paths (e.g., `delegation_path`, `previous_steps`) so an Authorisation Registry (AR) can verify that rights have been passed correctly. In practice, however, as paths span more parties and ARs, validation slows down, revocations ripple unpredictably, and privacy leaks if too much chain detail is exposed. While the iSHARE Trust Framework provides technical specifications and a robust authentication flow for managing delegations, several constraints arise when dealing with extended and complex delegation chains. These include privacy concerns, complexity in managing delegation policies, flexibility to adapt to varying scenarios, risks related to security, and efficiency in processing delegation evidence. Moreover, delegation chains are rarely linear. They can split into multiple parallel paths and later converge, introducing ambiguity and potential policy conflicts, as illustrated in Figure 1.2.

Figure 7: An example delegation chain containing a parallel path.

Current solutions have not fully addressed these challenges, particularly when delegation chains become long and involve multiple parties. The need for a systematic approach to improving the delegation model is evident. The goal of this article is to strengthen iSHARE’s delegation model so that multi-party chains remain verifiable, private, and performant without sacrificing interoperability. We treat ARs as evidence validators that answer valid/invalid while revealing as little path detail as possible, and we evaluate alternative models that change what is recorded per step: previous delegation ID vs. previous party ID, or encapsulate constraints cryptographically (e.g., macaroons). ### Principles for Delegation Paths While iSHARE’s current specification supports delegations, extended and complex chain**s** surface constraints that current solutions do not fully balance theese main principles: 1. Privacy: Ensure confidentiality by implementing zero-knowledge principles, limiting visibility of roles and identities within the delegation chain. 2. Complexity: Manage multiple delegation policies and traceable paths effectively, accommodating intricate delegation chains without excessive complexity. 3. Flexibility: Provide adaptable solutions that support various scenarios, including those with overlapping dates and changing paths. 4. Risks: Mitigate security vulnerabilities and unauthorised access by implementing robust verification processes and tamper-proof evidence management. 5. Efficiency: Optimise processes to minimise overhead and reduce the number of interactions needed to verify delegation evidence. Importantly, Authorisation Registries cannot hand out delegation evidence to any requester. The requesting party must provide sufficient proof that they are entitled to receive the delegation evidence. For instance, by being explicitly named as the delegated entity (to entity to whom entitlements are delegated) or by demonstrating that they act on behalf of the delegated entity through valid credentials. Only then does the Authorisation Registry issue delegation evidence. Empirically, long chains and cross-organisation settings amplify these constraints. A hybrid study of literature and real-world data spaces shows privacy is a dominant concern, with a partial mismatch between academic focus (revocation propagation, efficiency) and operational focus (transparency, interoperability). This underscores the need for systematic, model-level improvements rather than ad-hoc fixes.
# Recursive Path Models Recursive models extend each delegation with a pointer to its predecessor, allowing the entire chain to be reconstructed step by step. They preserve a natural sense of lineage: validation means “walking backwards” through the authorisation trail until the original data owner is reached. Within this family, two main approaches can be distinguished: storing the identifier of the delegating party or the identifier of the preceding delegation evidence. #### **Previous Party ID** In this approach, each delegation explicitly records the identifier of the party that granted the rights. Validation then becomes a matter of recursively checking: did C receive rights from B, did B from A, and did A from the data owner? This model has an important strength: it allows parallel paths to converge. Imagine Party 2 receiving rights from both the shipper and an intermediary subcontractor. Party 2 can then consolidate these rights into a single delegation to Party 3. This flexibility is especially valuable in dynamic ecosystems like logistics, where subcontracting is fluid and paths can change from one shipment to the next. *Figure 2.1* illustrates this type of scenario, while *Figure 2.2* shows the basic model structure.

Figure 8: The scenario where two paths converge to a single point, and is further delegated.

Figure 9: A delegation model where the delegation evidence contains a reference to the
party before the current party.

Revocation under this model is also more resilient. If one upstream link is revoked but an alternative path remains valid, downstream rights can continue without disruption. This avoids unnecessary breakage of chains, a key advantage when multiple contracts or delegations overlap in time. The trade-off comes with privacy and performance. Each delegation reveals the identity of the delegator, which means parties always see at least their immediate predecessor. In most real-world cases this does not leak new information — a party usually knows who authorised them — but it contrasts with more opaque models. Validation also requires contacting the relevant Authorisation Registries (ARs) for each hop. Without caching or AR identifiers embedded in evidence, this can create latency across large or multi-registry chains. Overall, the Previous Party ID model fits dynamic, flexible environments such as logistics supply chains, where subcontracting and path changes are common, and resilience is valued over strict traceability.

Table 1: The key strengths and weaknesses of the previous party-based delegation model.

#### Previous Delegation ID Instead of recording the delegating party, this model stores a reference to the identifier of the previous delegation evidence itself. Each link therefore points to a specific, immutable piece of evidence. When validating, the chain can be reconstructed exactly, as if following a linked list of evidence objects back to the original data owner. The result is deterministic and offers audit-friendly traceability. Revocation is simple and unambiguous: if one link is revoked, all downstream delegations that depend on it automatically become invalid. This is attractive in regulated environments, where clear lineage and unbroken audit trails are critical. For example, in finance or healthcare, auditors may demand proof of every delegation hop, and regulators may require certainty that no rights persist after revocation. *Figure 2.3* illustrates this model.

Figure 10: A delegation model where a reference is stored to the previous delegation

Nonetheless, this strictness makes the model fragile. Even if a party had rights through another route, those rights are lost if the specific referenced link breaks. The model enforces lineage over flexibility, which can be problematic in real-world scenarios where overlapping delegations exist. Validation also requires multiple recursive lookups across registries, potentially introducing latency unless discovery mechanisms or caching are in place. The Previous Delegation ID model is therefore best suited for audit-heavy domains where lineage is more important than resilience such as finance, healthcare, or government data sharing — even if that means sacrificing some flexibility and robustness.

Table 2: The key strengths and weaknesses of the previous delegation-based delegation
model.

# Concatenation Models Concatenation models aim to reduce validation overhead by embedding the entire delegation chain (or a compressed version of it) directly into each new piece of evidence. Instead of requiring recursive lookups across multiple registries, the authorisation path is self-contained and can be validated in a single step. This makes the model appealing for efficiency, though it comes with trade-offs in flexibility and privacy. Two variants exist: a full concatenation model and an ID-only concatenation model. #### Full Concatenation In this variant, every new delegation includes the full chain of delegations that preceded it. For example, if Party D is authorised via A → B → C → D, then the evidence held by D contains all the steps A→B, B→C, and C→D. Validation is straightforward: the chain can be checked locally without contacting external registries. This approach maximises efficiency. Since all information is bundled in the evidence, validation requires no additional network calls. However, the cost of this simplicity is privacy and evidence size. Each delegate receives visibility into the full chain, including parties upstream that they might not need to know. As chains grow longer, the evidence becomes larger, raising concerns about performance, scalability, and metadata leakage. #### ID-only Concatenation To address the privacy and scalability issues of the full model, the ID-only variant stores only delegation identifiers, not the full evidence contents. Each new delegation includes a concatenated list of the IDs of all upstream delegations. This provides a middle ground. The validation process still requires looking up the referenced IDs in the relevant registries, but since the list is provided up front, traversal can be more efficient than recursive linked-list models. Privacy is better preserved than in the full model, since delegatees see only opaque identifiers rather than identities or detailed delegation data. However, revocation handling becomes trickier. If an upstream ID is revoked, the entire concatenated list may need to be revalidated, and the chain can break unless alternative paths exist. Additionally, while smaller than full concatenation, the ID list still grows linearly with chain length. Both the full and ID-only approaches illustrate the trade-off between efficiency, privacy, and scalability. The core idea remains the same: by concatenating the delegation path into each new evidence object, validation can be streamlined. The difference lies in how much information is carried along — either full delegation details or just opaque identifiers. *Figure 3.1* below presents the generic concatenation model, and the accompanying Table 3.1 summarises the main strengths and weaknesses of both variants.

Figure 11: A delegation model where the delegation evidence contains a reference to all
delegations that lead to it. (Whether ID-only or full)

Table 3: The key strengths and weaknesses for the concatenation-based delegation model.

# Macaroon Model Macaroons are a cryptographic, token-based delegation mechanism that encode authorisations together with constraints, called *caveats*. Unlike structural models that explicitly trace delegation paths, macaroons provide a way to embed rules directly in the token. Each new party can append additional caveats when delegating rights further, creating a compact but flexible chain of constraints. For example, the data owner issues a macaroon authorising access to a dataset. When Party A delegates to Party B, it adds caveats such as *“only valid until tomorrow”* or *“only for transport documents”*. Party B can then further delegate to Party C, adding new caveats on top of the existing ones. Validation means checking that all caveats are satisfied: if any fail, the macaroon is invalid. This design offers strong privacy benefits. Since macaroons only contain embedded caveats, downstream parties do not see the full delegation path or identities of all intermediaries. Furthermore, validation is fast: it requires only cryptographic checks on the token itself, without registry lookups. However, macaroons have significant limitations in flexibility. Once caveats are embedded, they cannot be modified, and revocation is difficult because there is no central registry to consult. Revoking one macaroon typically requires reissuing all tokens. This makes macaroons less suited for ecosystems where revocation propagation is critical. Additionally, while caveats allow for constraints like expiration dates or access scopes, they cannot easily represent complex policies or alternative delegation paths. The macaroon model is therefore best suited for privacy-sensitive contexts where delegation chains are relatively short-lived, efficiency is critical, and fine-grained constraints are more important than revocation flexibility.

Figure 12: A delegation model where the data owner creates a macaroon using a trusted
party, which is then passed along the delegation chain.

Table 4: The key strengths and weaknesses for the macaroon-based delegation model.

# Context Matters Simulation and case studies (including logistics, healthcare, and cross-border data spaces) confirm that no single model solves all challenges. Recursive models provide flexibility and revocation robustness, but require multiple lookups. Concatenation models improve efficiency, but at the cost of privacy and adaptability. Macaroons excel in privacy and speed, but complicate governance and auditing. The choice of model depends on context: logistics chains may favour flexibility (Previous Party ID), regulated sectors may prioritise auditability (Previous Delegation ID), performance-driven IoT exchanges may prefer concatenation, and privacy-sensitive domains may lean towards macaroons. For iSHARE, the key is not to prescribe a single approach, but to ensure interoperability across models. The framework’s attributes (`delegation_path`, `previous_steps`) and clarifications (e.g., rules must not contain targets in delegation evidence) provide the baseline for compatibility. This allows ARs and participants to adopt the model that best fits their context without fragmenting the ecosystem. The following Table gives a final overview of the benefits and limitations of each model:

Table 5: Consolidated strengths and weaknesses across delegation models.

### A Continued Commitment to Optimisation The models presented illustrate that there are several valid methods to manage delegation chains, each with their own strengths and trade-offs. Recursive approaches emphasise resilience and flexibility, concatenation offers speed and implementation ease, and macaroons provide strong privacy and cryptographic efficiency. By documenting these patterns side by side, implementers can make informed choices suited to their requirements, while ensuring interoperability across data spaces. This approach reinforces that the data spaces remains secure. # Storing Policy Sets ## Storing Policy Sets Policy sets are the structured rules that an Authorisation Registry evaluates when a Service Provider requests delegation evidence. They define, for a given Entitled Party, which parties have been granted which rights to which resources, under which conditions. The iSHARE specification describes the structure of policy sets and how delegation evidence is exchanged, but deliberately does not prescribe how policies must be stored internally. This article clarifies how policy sets can be stored within an AR. It also emphasises that the rules must not contain targets when used in delegation evidence, a constraint that any storage approach must respect. ### Who owns policies Policies are owned by the Entitled Party. The AR stores and evaluates them on the behalf of Entitled Party, but the Entitled Party is the authority that defines the access rights. This distinction matters: an AR should not modify policies without the Entitled Party's instruction, and the Entitled Party retains the right to register, update, or revoke delegations at any time. In practice, the relationship between an Entitled Party and its AR is governed by a formal agreement, one of the normative requirements for the AR role. That agreement covers the process by which the Entitled Party manages its delegation policies through the AR. ### Policy structure A policy set in iSHARE is a JSON structure consisting of three nested levels: #### Policy Sets Defines broad conditions under which the enclosed policies operate, including the maximum delegation depth (limiting how many times rights can be re-delegated) and the target environment (the legal and operational context, including relevant [licences](https://licenses.ishare.eu/)). #### Policies Within a policy set, each policy is a specific declaration of rights. It identifies the resource (what is being accessed), the permitted actions (read, write, delete, etc.), and the allowed service providers (restricting who can act on behalf of the data owner). This granularity ensures that permissions are contextually precise and cannot be applied to unintended resources. Policies define what is allowed. There are machine-readable rules that define who can do what on which resource, under which conditions. They specify: * which resource or service is involved * which actions are permitted * which parties or roles are involved * optional conditions Policies can be: * [coarse-grained](https://framework.ishare.eu/use-cases/use-case-h2m-interaction-with-coarse-grained-authorization) (broad access) * [fine-grained](https://framework.ishare.eu/use-cases/use-case-m2m-interaction-with-fine-grained-authorization) (very specific access) #### Rules Rules are the core of the access control decision and define how decisions are made within a policy. They specify whether access is permitted or denied, and under what conditions. A default permit rule provides a baseline, while additional deny rules constrain it. Note that in delegation evidence (as distinct from stored policies), rules must not contain targets. Rules may include conditions such as: * time * location * organisational attributes #### Conditions iSHARE extends policies with [delegation conditions](https://dev.ishare.eu/reference/delegation-conditions): structured constraints that further limit when a delegation is valid. These can include time windows, attribute requirements, or certification levels. Conditions can be evaluated at the AR or at the Service Provider, depending on where the relevant context is available. More about supported conditions [here](https://dev.ishare.eu/reference/delegation-conditions#supported-condition-types). {% hint style="info" %} See more [here ](https://framework.ishare.eu/detailed-descriptions/technical/structure-of-delegation-evidence)in the iSHARE Trust Framework, Structure of Delegation Evidence. {% endhint %} #### **Expressing policies as ODRL** While iSHARE defines how policy sets are structured and how delegation evidence is exchanged, it does not define how those rules should be expressed in the usage-control policy languages are consumed by the roles in a wider data space. This is where ODRL ([W3C Open Digital Rights Language](https://www.w3.org/TR/odrl-model/)) becomes relevant. ODRL is a machine-readable language for expressing usage rights, permissions, prohibitions, and obligations and is the policy vocabulary used in wider data ecosystems. Where an iSHARE policy set answers who may perform which action on which resource, ODRL provides a standard way to carry the usage terms attached to that decision into the data plane. The mapping runs through the policies and rules that make up a policy set. Each policy declares, in machine-readable form, which resource is involved, which actions are permitted, and which parties may act; its rules declare whether those actions are permitted or denied, and under which conditions. Implementing ODRL in an iSHARE delegation therefore means adding a translation step rather than changing how policies are stored: validated delegation evidence is mapped onto an ODRL policy, with the policy issuer becoming the assigner, the access subject the assignee, each policy's resource and actions becoming the ODRL target and actions, permit rules becoming permissions, deny rules becoming prohibitions, and conditions such as time windows or attribute requirements becoming constraints. Because iSHARE rules are limited to permit and deny, they map cleanly onto ODRL permissions and prohibitions. ### Storage approaches in practice The iSHARE framework provides flexibility in how policies are stored. Several approaches are used across the ecosystem: #### Document-oriented databases Because iSHARE policy sets are expressed as JSON, document-oriented databases such as MongoDB or CouchDB allow policies to be stored natively, avoiding translation overhead. Queries can target JSON fields directly (issuer, subject, target), making evaluation straightforward. This approach is well-suited for ARs that prioritise agility and iteration speed. The trade-off is in complex auditing and bulk reporting, which may require custom indexing or secondary systems. #### Relational databases Many AR operators rely on relational infrastructure such as PostgreSQL or SQL Server. Policies can be stored in JSONB columns or decomposed into fully relational tables. The iSHARE AR reference implementation uses this approach: policies are seeded into relational tables with indexes on issuer, subject, and resource identifiers. This model supports powerful auditing, SQL queries can easily check for overlapping delegations or historical access grants. The trade-off is rigidity: schema changes in the iSHARE specification may require migrations. #### Policy engines A third approach integrates ARs with dedicated policy engines such as Open Policy Agent (OPA) or AuthzForce. The AR translates iSHARE JSON policy sets into the engine's native format and delegates evaluation. This is compelling in complex governance environments, for example, energy sector data spaces aligned with Gaia-X, where centralised access control management is valuable. The downside is additional complexity: the AR must maintain translation logic, and tracing why a policy evaluation failed requires navigating two systems. #### Hybrid and ledger-based approaches Some implementations combine fast operational storage with immutable audit logging. A common pattern stores JSON policies in a document database for retrieval speed while mirroring every change to an append-only ledger. This gives operators the performance of a document store alongside the immutability guarantees that regulators or dispute resolution processes may require. The trade-off is operational overhead: maintaining two storage backends requires careful governance and resourcing. ### Design considerations for AR implementers

Figure 13: Design considerations for AR implementers

# Authorisation Registry per service (capability) RFC056 introduces the ability for an Entitled Party to use different Authorisation Registries for different services/capabilities within the same data space. Further, it also defines how a Service Provider should discover which Authorisation Registry to contact before requesting delegation evidence. This is a change to how ARs are discovered and not to how delegation evidence is evaluated once you have it (see [Delegation Chains](/apply-ishare/authorisation/delegation-chains)). ### Why this matters In real world use cases, one Entitled Party may participate in multiple contexts (supply chains, modalities, regions, single transactions, etc), and different services can require domain-specific authorisation logic. This means that a single and fixed Authorisation Registry per data space is too rigid. Allowing an Authorisation Registry per capability preserves choice and lowers coupling, while keeping discovery predictable for implementers. On a broader note, this also enables better operational scaling: the same Authorisation Registry can serve multiple data spaces and multiple capabilities, so communities with strong policy or compliance needs don’t have to duplicate infrastructure. ### Authorisation Registry Discovery Logic The step-by-step logic Service Providers follow to find the correct Authorisation Registry is defined in the Authorisation Registry Discovery logic section of the Trust Framework. An Entitled Party can indicate, per capability, which Authorisation Registry issues the delegation evidence that Service Providers should rely on. That is, Service Providers perform a discovery step before calling an Authorisation Registry for delegation evidence. Authorisation Registries can now serve multiple Entitled Parties, services, and data spaces without being “hard-wired” to one space. ### What stays the same The way Service Providers validate evidence and make an access decision does not change. RFC056 leaves delegation paths/chains and token validation intact; it only clarifies which Authorisation Registry a Service Provider should contact for this capability. ### Implications for Participants #### Entitled Parties (EP) Entitled Parties can choose the Authorisation Registry that will store their delegation evidence for each capability. For instance, a community Authorisation Registry at a port for berth allocation, and a sector Authorisation Registry for shipment status. They make the Authorisation Registry discoverable by declaring the Authorisation Registry per capability in /capabilities; otherwise register it in the Participant Registry (per capability, per data space, or as default). #### Service Providers (SP) Before asking for delegation evidence, a Service Provider discovers the applicable Authorisation Registry for the given capability. In some H2M variants, an Identity Provider or Broker may supply an authorisation link; Service Providers can follow the link to obtain evidence and then verify the Authorisation Registry’s identity in the Participant Registry. #### Authorisation Registries (AR) Will be referenced per capability and across multiple data spaces. Functionally, issuing evidence doesn’t change; operationally, onboarding may broaden to cover multiple EPs and services. #### Participant Registries (PR) Participant Registries expose Authorisation Registry information so Service Providers can discover an Authorisation Registry when it isn’t declared per capability by the Entitled Party. This makes the Entitled Parties' intent visible and auditable across the ecosystem. ### Compatibility and rollout This feature is designed to be backwards-compatible. If an Entitled Party does nothing new, Service Providers will still find an Authorisation Registry through existing Participant Registry entries. Caching and expiry practices don’t change: Service Providers may cache discovery results within sensible validity windows and refresh when statements (capabilities or Participant Registry entries) change or expire. \
# Deployment & Use Cases The iSHARE Trust Framework allows flexibility in how the Authorisation Registry is implemented and operated. Depending on governance requirements, operational scale, and the structure of a data space, different deployment models can be adopted. This section describes a general overview of those models and illustrates how the AR is applied in practice across real data spaces. ### Deployment models The iSHARE framework does not prescribe a single deployment model for Authorisation Registries. Several patterns are used in practice, each suited to different governance and operational contexts: {% hint style="info" %} Similarly, the iSHARE Trust Framework does not define one single implementation. All the following deployment models can be implemented using either [Verifiable Credentials](https://framework.ishare.eu/detailed-descriptions/technical/structure-of-delegation-evidence/data-rights-credential-vc) or [API flow](https://dev.ishare.eu/authorisation-registry-role/delegation-endpoint). {% endhint %} #### Single AR as a shared service in a data space A single AR serves all participants in a given data space. This is the simplest model and the easiest to govern collectively. It works well for tightly scoped data spaces with a defined membership and a shared governance body.

Figure 14: AR as a single shared service under governance authority

#### Distributed or federated AR Multiple ARs operate within the same data space, each serving different participants or capability areas. Service Providers discover the applicable AR per capability. This model scales better for large or heterogeneous data spaces and allows specialised governance for different types of delegations.

Figure 15: Distributed or federated AR under the governance authority

{% hint style="info" %} These are the very first basic deployment models; however, please keep in mind that there could be more variations and alternatives. For example, there can be multiple Authorisation Registries per Data Sharing Initiative and per service. {% endhint %} ### Use Cases The following examples illustrate how the Authorisation Registry is applied across real data spaces — what role it plays, and what value it provides to participants. See more use cases here. #### 1. DVU ([Datastelsel Verduurzaming Utiliteit - Data System for Sustainability in Utility Buildings](https://ishare.eu/ecosystem/ishare-in-data-spaces/dvu/)) DVU enables trusted data sharing to support sustainability and energy optimisation of non-residential buildings, involving building owners, energy service providers, technology providers, and public authorities. Role of the Authorisation Registry: * Stores and enforces delegation policies that govern which parties may access building and energy consumption data on behalf of data owners * Issues delegation evidence to Energy Companies, confirming that a Consumer has been authorised by the relevant Building Owner * Enables building owners to set, update, and revoke access rights at any time, maintaining control over sensitive energy data throughout the data sharing lifecycle Value: * Allows building owners to share sensitive consumption data with confidence, knowing that access is governed and revocable * Removes the need for bilateral access agreements between every pair of participants * Supports scalable data sharing for energy optimisation, digital twin development, and CO2 reduction reporting #### 2. DMI ([Dutch Metropolitan Innovations](https://ishare.eu/ecosystem/ishare-in-data-spaces/dmi/)) DMI develops and manages data infrastructure for smart, sustainable urbanisation and mobility, bringing together public authorities, infrastructure operators, and private organisations in a governed, federated data space. Role of the Authorisation Registry: * Governs access control at every point in the DMI data flow, ensuring that only authorised parties can request and receive data * Stores delegation policies on behalf of Entitled Parties, enabling data owners to define access rights per participant, capability, or context * Works alongside AMdEX and the iSHARE governance layer to enforce compliance before any transaction is processed Value: * Supports trusted collaboration across public and private stakeholders with fundamentally different mandates and risk profiles * Enables data owners ,including municipalities, to share data transparently and with full auditability * Reduces onboarding friction for new participants by providing a shared authorisation infrastructure rather than requiring per-relationship setup # Participant Registry The iSHARE Trust Framework defines the Participant Registry (formerly known as the Satellite) as a certified role that functions as one of the Trust Anchors of a data space, enabling participants to verify whether other parties are recognised, compliant, and eligible to interact within that environment. In practice, the Participant Registry provides a reliable and machine-readable source of information about participants. This includes their identity, roles, capabilities, and status within a data space. By making this information accessible, it allows organisations to establish trust in a consistent and automated way, building on agreed terms of use and any additional data space role-specific agreements. The term trust anchor refers to the Participant Registry's role as an important point of trust: participants rely on it to verify whether another party is part of the data space and meets the criteria defined by the Governance Authority (Data Space Governance Body). The Participant Registry is therefore not just a directory of organisations, but an important element for enabling secure, scalable, and interoperable data sharing. ### Participant Registry in the iSHARE Architecture Within the iSHARE architecture, the Participant Registry helps establish trust between participants. While it does not directly participate in operational data exchange flows, it provides the prerequisite layer of trust, discoverability and interoperability that makes such interactions possible.
Each participant in a data space is explicitly linked to a Participant Registry responsible for its admission. This ensures that membership and compliance are governed in a structured and verifiable way. Data Space Governance Authority defines the criteria and processes for onboarding participants, which are then executed by the Participant Registry. The function of a Participant Registry can be performed by the Data Space Governance Authority. These two roles are interlinked and crucial to the scaling up of the data space. The Participant Registry operates as part of a broader trust infrastructure, interacting with other roles such as [Authorisation Registries](https://framework.ishare.eu/main-aspects-of-the-ishare-trust-framework/framework-and-roles#authorisation-registry) and [Identity Providers](https://framework.ishare.eu/main-aspects-of-the-ishare-trust-framework/framework-and-roles#identity-provider). It enables participants to discover relevant information needed to make interactions, such as identifying which Authorisation Registry to use when this is not explicitly declared.
From a technical perspective, the Participant Registry exposes standardised interfaces (APIs) through which participant information, claims, and capabilities can be found. These interfaces allow systems to automatically retrieve and validate information about other parties. The iSHARE Trust Framework further enables interoperability across data spaces by supporting a distributed model of Participant Registries. This means that multiple registries can coexist, each governed by its own data space, while still enabling the exchange and validation of information across these environments.
{% hint style="info" %} Discover more from: **•** Roles and Responsibilities [here](https://trustbok.ishare.eu/~/revisions/OaLCkc0KBQ7izbiIkrRW/apply-ishare/participant-registry/role-and-responsibilities) **•** How It Works [here](https://trustbok.ishare.eu/~/revisions/z5o5UNy6S99ltLU8ivCZ/apply-ishare/participant-registry/how-it-works) **•** Functional Capabilities [here](https://trustbok.ishare.eu/~/revisions/z5o5UNy6S99ltLU8ivCZ/apply-ishare/participant-registry/functional-capabilities) **•** Deployment & Use Cases [here](https://trustbok.ishare.eu/~/revisions/z5o5UNy6S99ltLU8ivCZ/apply-ishare/participant-registry/deployment-and-use-cases) {% endhint %} ### Resources and Guidance Explore the following resources to integrate the Participant Registry within your data space: **•** [**Participant Management**](/apply-ishare/quick-walkthroughs/participant-management) Explains a detailed walkthrough on how organisations can manage their participants and update information in the participant registry through our User Interface. **•** [**Getting Started Guide**](https://github.com/iSHAREScheme/iSHARESatellite/blob/main/docs/INSTALL.md#deploy) A step-by-step introduction for organisations looking to onboard with a Participant Registry, including prerequisites. **•** [**Deployment Guide**](https://www.ishare.eu/deployment-guide/) Covers technical implementation details for deploying the Participant Registry within your data space, including key cloak setup, defining passwords, and best practices. • [**Swagger Specification**](https://app.swaggerhub.com/apis/iSHARE/i-share_satellite/1.0) Provides the Open API definitions for integration with the iSHARE Framework. Developers can use these specifications to interact with the Participant Registry and other components. # Role and Responsibilities The data space Governance Authority defines the requirements for participation and oversees the onboarding process of participants. Within this, the Participant Registry (PR) plays a facilitating role by operationalising these rules and supporting trust assurance. It acts as the practical mechanism through which governance decisions are executed. The Participant Registry is responsible for managing the lifecycle and trust status of participants within a data space. Its responsibilities are laid out in the iSHARE Trust Framework and governed by the data space Governance Authority. #### Onboarding and admission A primary responsibility of the Participant Registry is to validate and onboard participants into a data space. This includes verifying that organisations meet the criteria defined by the governance authority and ensuring that onboarding processes are consistently applied. The framework requires that the Participant Registry operates based on clearly defined processes and criteria for onboarding, registration, updating, and reviewing participants. These processes must align with the level of assurance for which the Participant Registry has been certified. {% hint style="info" %} Note: To be onboarded to the iSHARE Ecosystem, either as an [adhering or certified party](https://framework.ishare.eu/main-aspects-of-the-ishare-trust-framework/framework-and-roles#frameworkandroles-roleofthesatellite), there is a specific admission criterion and onboarding process that the parties need to fulfil (See more [here](https://framework.ishare.eu/detailed-descriptions/operational/operational-processes/admission)). This can be applied in Data Spaces where the iSHARE Trust Framework is integrated; however, each data space is free to further define criteria for its own participants. {% endhint %} #### Participant information management The Participant Registry maintains information about all registered participants. This includes: * identity and identifiers * roles performed within the data space * services offered * level of assurance and compliance status This information forms the basis for other participants to assess whether interaction is possible and under what conditions, in line with the access rules defined in the [Authorisation Registry](https://trustbok.ishare.eu/apply-ishare/authorisation). #### Claims management ([Claim Models](https://dev.ishare.eu/participant-registry-role/claim-models)) In line with the [iSHARE Trust Framework version 3.0](https://framework.ishare.eu/), participant information is structured around claims. The Participant Registry is responsible for registering and maintaining these claims, ensuring they are valid, up to date, and within the scope of the data space. Claims represent specific attributes or statements about a participant, such as: * membership in a data space * roles performed * certifications or credentials * capabilities or services offered The Participant Registry is responsible for maintaining these claims and ensuring they are: * validated before registration * aligned with governance rules * traceable to their source The framework also allows Participant Registries to maintain claims for participants registered by other registries, provided that governance and validation requirements are met. This supports interoperability across data spaces. #### Membership and status validation (Maps to the [Data Space Membership Claim](https://dev.ishare.eu/participant-registry-role/claim-models#dataspace-membership-claim)) The Participant Registry enables participants to verify whether another party: * is a member of the data space (and currently active) * meets the required compliance criteria (with the framework and data space) * holds specific roles or attributes (level of assurance) This validation is typically performed automatically by systems querying the Participant Registry before initiating interactions, and is fundamental for establishing trust before interactions take place. #### Support for discovery The Participant Registry builds the context of a data space and supports the discovery of relevant components within the iSHARE ecosystem. Through endpoints such as /capabilities, participants can expose information about: * available services * supported functionalities * relevant endpoints This allows other participants to identify how and where to interact with a given party. In addition, the Participant Registry plays a role in Authorisation Registry discovery, enabling service providers to determine the appropriate Authorisation Registry when it is not explicitly specified. For example, it must enable service providers to determine which [Authorisation Registry](https://framework.ishare.eu/main-aspects-of-the-ishare-trust-framework/framework-and-roles#authorisation-registry) to use when this information is not otherwise available. #### Compliance and certification (maps to the [Framework Compliance Claim](https://dev.ishare.eu/participant-registry-role/claim-models#framework-compliance-claim)) As a [certified role](https://framework.ishare.eu/main-aspects-of-the-ishare-trust-framework/framework-and-roles#frameworkandroles-certifiedroles) within the iSHARE Trust Framework, the Participant Registry must: * comply with defined service levels for certified parties * operate in accordance with its certified level of assurance * avoid making claims beyond its certification scope In addition, the Participant Registry itself must be registered as a participant, including its role, level of assurance, and compliance status. #### What the Participant Registry does not do To clarify its role within the architecture, the Participant Registry: * does not enforce access control decisions (this is handled by Authorisation Registries) * does not authenticate users or systems (this is the role of Identity Providers) * does not directly participate in data exchange flows Instead, it provides the trusted information layer that enables these processes to function reliably.
# How It Works Although the Participant Registry is not explicitly shown in operational data exchange flows, it plays a critical role as a prerequisite for trusted interactions. A typical sequence of how it is used can be described as follows:
While the Participant Registry plays an important role within the iSHARE Trust Framework, it typically operates in the background rather than directly interacting with participants. Instead, it provides the trust context that enables interactions to take place, as illustrated in this[ use case](https://ishare.eu/ecosystem/ishare-in-data-spaces/dvu/). Without this layer, participants would need to establish trust manually, significantly reducing scalability and interoperability. ### Importance and Value The Participant Registry is a foundational component for enabling trusted, scalable, and interoperable data spaces.
#### Benefits for different stakeholders

# Functional Capabilities The [Participant Registry provides a set of functional capabilities](https://framework.ishare.eu/detailed-descriptions/functional/functional-requirements-per-role#participant-registry) that enable participants and systems to retrieve, verify, and manage trusted information about organisations within a data space. These capabilities are laid out in the iSHARE Trust Framework and implemented through standardised data models and interfaces. #### Participant identification & metadata At its core, the Participant Registry maintains a structured representation of each participant. This includes identifiers (such as EORI or DID), organisational information, and metadata describing the participant’s role within the data space. Each participant is represented as a “party”, accessible via standardised endpoints. This allows other participants to retrieve consistent and machine-readable information when initiating interactions. #### Trusted lists & certificates To support secure communication, the Participant Registry provides access to trusted technical information, such as: * certificates and public keys * trusted lists * framework and data space references This information allows systems to: * verify digital signatures * establish secure connections * ensure that interactions occur within a trusted environment #### Verifiable Credentials integration The iSHARE Trust Framework enables the Participant Registry to issue Participant Credentials as [Verifiable Credentials (VCs).](https://dev.ishare.eu/roles/verifiable-credential-support-per-role) These credentials: * are issued to onboarded participants * can be stored in digital wallets * can be presented to other parties during onboarding or service usage When a credential is presented, the receiving party can verify: * the issuer (Participant Registry) * the integrity of the credential (signature) * the schema and structure * the current validity status This capability complements traditional registry lookups and enables portable trust across data spaces, allowing participants to reuse verified credentials in different contexts. #### APIs & endpoints (See more [Here](https://dev.ishare.eu/participant-registry-role/getting-started)) The Participant Registry exposes its functionality through a set of standardised APIs. These enable automated interaction and integration with other components in the ecosystem. Key endpoints include: * /parties — retrieve participant information * /claims — retrieve claims associated with participants * /capabilities — discover supported functionalities * trusted list, data spaces and framework endpoints Optional endpoints may support: * creation and updating of participants and claims (typically restricted to authorised onboarding systems) These interfaces ensure that the Participant Registry can act as a machine-readable and interoperable source of truth for participant data. # Deployment & Use Cases The iSHARE Trust Framework allows flexibility in how the Participant Registry is implemented and operated across data spaces. Depending on governance, scale, and technical preferences, different deployment models can be adopted. #### 1. Centralised model In a pilot or earlier phase, single Participant Registry cab be responsible for managing all participants within a data space. * One common registry acts as the primary source of trust assurance * Simplifies governance and onboarding processes * Easier to manage consistency and compliance This model is typically suitable for: * Organisations piloting trusted data exchange in sectors with tightly governed or sensitive data. * Highly secure environments with a single governance authority #### 2. Federated model In a federated model, multiple Participant Registries coexist, each responsible for a subset of participants or domains. * Each registry operates under its own governance context * Participant information can be shared across registries * Claims may be maintained across registries when allowed This model supports: * collaboration between multiple data spaces * domain-specific governance structures #### 3. Distributed / decentralised model The iSHARE Trust Framework supports a distributed approach, where Participant Registries operate as nodes within a broader network. * No single central authority controls all participant data * Registries contribute to a shared trust infrastructure * Interoperability is enabled through common standards and governance This model aligns with: * cross-data space interoperability * scalability across sectors and geographies
#### Considerations When choosing a deployment model, data spaces typically consider: * governance structure and responsibilities * level of trust required between domains * scalability and performance needs * interoperability requirements Regardless of the model, all Participant Registries must operate in accordance with the iSHARE Trust Framework to ensure consistent trust and verification. ### Use Cases (See more [here](https://ishare.eu/ecosystem/ishare-in-data-spaces/)) This section illustrates how the Participant Registry is applied in practice, focusing on its role in enabling trust, verification, and discoverability. #### 1. DVU ([Datastelsel Verduurzaming Utiliteit - Data System for Sustainability in Utility Buildings](https://ishare.eu/ecosystem/ishare-in-data-spaces/dvu/)) DVU focuses on enabling trusted data sharing to support the sustainability and energy optimisation of utility buildings and non-residential buildings, involving stakeholders such as building owners, service providers, technology providers, and public authorities. Role of the Participant Registry: * Ensures that organisations participating in the DVU data space are validated and onboarded according to governance and sustainability-related criteria * Maintains participant information and claims, such as roles (e.g. building owner, energy service provider) and relevant capabilities * Enables participants to discover and verify trusted counterparts before exchanging building, energy, or performance data Value: * Supports secure and trusted collaboration across stakeholders involved in building sustainability * Reduces onboarding complexity for new participants in the ecosystem * Enables scalable data sharing to support energy optimisation, monitoring, and reporting use cases #### 2. DMI ([Dutch Metropolitan Innovations](https://dmi-ecosysteem.nl/)) DMI focuses on enabling data-driven collaboration within metropolitan environments, involving public authorities, infrastructure operators, and private organisations working on mobility, infrastructure, and urban development. Role of the Participant Registry: * Ensures that organisations participating in the DMI data space are properly onboarded and validated according to governance rules * Maintains participant information and claims, including roles (e.g. public authority, service provider) and capabilities * Enables participants to discover and verify trusted partners before exchanging data or services Value: * Supports trusted collaboration across public and private stakeholders in urban environments * Reduces friction in onboarding new participants into the ecosystem * Enables scalable and interoperable data sharing for mobility and infrastructure use cases #### 3. BDI ([Basic Data Infrastructure](https://ishare.eu/home/ecosystem/data-spaces/bdi/)) The Basic Data Infrastructure (BDI) is a Dutch initiative designed as a federative, “soft” infrastructure, a set of agreements that enables secure, trusted, and automated data sharing across the logistics and supply chain sector. It connects a wide range of stakeholders, including shippers, logistics service providers, ports, and authorities, without requiring a central platform. Role of the Participant Registry: * Supports the federative model by enabling trusted identification and verification of participants across organisational boundaries * Maintains claims related to roles, participation, and compliance within the logistics ecosystem * Enables participants to discover and validate trusted partners before initiating data exchange * Supports interoperability across domains by allowing claims to be recognised beyond a single registry Value: * Enables trust without centralisation, aligning with the federative nature of BDI * Reduces the need for bilateral agreements between supply chain partners * Supports scalable and automated data sharing across complex logistics networks * Facilitates interoperability between different systems and data spaces #### 4. SAGE/ GDDS (Data Space for a Sustainable Green Europe) SAGE focuses on enabling trusted data sharing to support sustainability goals across Europe, involving a wide range of participants such as public authorities, private organisations, and service providers. Role of the Participant Registry: * Ensures that participants are onboarded according to governance rules aligned with sustainability objectives * Maintains claims related to roles, compliance, and potentially sustainability-related attributes * Enables participants to verify trusted counterparts across organisational and national boundaries Value: * Supports trustworthy collaboration in sustainability-driven ecosystems * Enables controlled and transparent participation aligned with policy and regulatory requirements * Facilitates interoperability between diverse stakeholders contributing to green initiatives #### 5. WEBUILD (Wallet Ecosystem for Business and payments Use cases on Identification, Legal representation and Data sharing) In ecosystems using Verifiable Credentials: Role of the Participant Registry: * Issues Participant Credentials as Verifiable Credentials * Acts as a trusted issuer within the ecosystem * Enables verification of credentials across data spaces Value: * Supports portability of trust across different environments * Reduces reliance on registry lookups alone * Enables participants to prove attributes independently # APIs APIs are essential for different systems to connect and communicate with each other. They define how applications interact, exchange data, and execute functions without needing to understand each other’s internal workings. \ \ In the context of **iSHARE**, APIs form the backbone for secure, standardised, and automated data sharing between multiple stakeholders across sectors like logistics, energy, and agriculture. Within the **iSHARE Framework**, specific APIs-such as **token**, **delegation**, and **capabilities**—are crucial for enabling trust-driven and compliant data exchange. {% content-ref url="/pages/NkW5i00yLbllEmQgEk01" %} [Capabilities endpoint](/apply-ishare/apis/capabilities-endpoint) {% endcontent-ref %} # Capabilities endpoint #### **Technical Overview** The Capabilities Endpoint is a vital feature for service providers which offers a comprehensive overview of the capabilities and available features of an iSHARE party. This endpoint returns an iSHARE-signed JSON Web Token (JWT) that provides detailed information about the supported versions, roles, and features of the service provider. Hence, the Capabilities Endpoint enhances interoperability and data sharing across diverse systems by offering a clear overview of what services are available, how they can be accessed, and the requirements for their use #### **The Core Functionality of Capabilities Endpoint:** The Capabilities Endpoint serves as a standardised interface that enables entities within the iSHARE Trust Framework to discover and interact with each other's services and capabilities. This provides querying information about available data-sharing services, including their features, access requirements, and operational details, which are: **Service Discovery:** This allows users to identify and access various data-sharing services available within the ecosystem. **Capability Information:** This provides detailed descriptions of the functionalities and conditions for using individual services. **Standardised Interaction:** This ensures consistent and reliable communication between various systems (data owners, data providers, Authorization Registry, Service Provider/Consumer, Identity Provider, building a data space) through adherence to standardised protocols. #### **How is the Capabilities Endpoint Functionality Implemented?** The Functionality of the Capabilities Endpoint is implemented through a combination of RESTful API interfaces and standardised data models. These APIs allow for querying and retrieving information about available services, including their capabilities, access requirements, and usage conditions. In this process, the iSHARE Trust Framework ensures that all interactions are secure, consistent, and compliant with data-sharing standards. **Key aspects of the implementation include:**
* API Specifications: Uses the RESTful API architecture for a detailed specification outline on how to interact with the endpoint, including request formats, response structures, and error handling. * Data Models: Uses Standardised data models to describe service capabilities and requirements, ensuring consistent interpretation of data across different systems. * Security Measures: Authentication and authorization mechanisms are integrated for secure access to the endpoint, ensuring that only authorised entities can interact with the data and services. #### **Practical Implementation Steps for the Capabilities Endpoint** 1\. Send the Request: To access the capabilities endpoint, follow these steps: * GET Request: Use the URL . * Authorization (Optional): Include an Authorization header with a bearer token if Required. * Format: Authorization: Bearer \ 2. Receive the Response: The endpoint will respond with a JSON Web Token (JWT) containing capabilities information. The content and structure of the JWT depend on whether an access token is provided. Without Access Token: The response will include details of public endpoints only, including general features and the Access Token endpoint. With Access Token: The response will include both public and restricted endpoints which may include more sensitive or specialised features. Understand the JWT Structure: The JWT includes the following details: 1. capabilities\_info: Contains information such as: * party\_id: The unique identifier of the party. * ishare\_roles: The roles assigned to the party (e.g., ServiceProvider). * supported\_versions: Versions of the service that are supported. * supported\_features: Information on available features. 2. public: Lists features accessible to everyone, including: * id: Unique identifier for the feature. * feature: Name of the feature. * description: A brief overview of the feature. * url: Link to access the feature. 3. restricted (optional): Lists features that are accessible only with a valid access token, similar to public features but with restricted access. #### How Capabilities Endpoint Benefits Business and Data Sharing Use Cases For businesses and data-sharing use cases, the Capabilities Endpoint offers several advantages: * Enhanced Visibility: Businesses can gain insights into what services and features are supported, helping them make informed decisions about integrating with or utilising different iSHARE Foundation services. * Feature Discovery: Organisations can easily identify both public and restricted features of iSHARE Trust Framework allowing them to understand what functionalities are available and how to access them. * Role and Version Information: The endpoint provides details about the roles assigned to the iSHARE party (e.g., ServiceConsumer, ServiceProvider) and the versions of the endpoints they support, which is crucial for compatibility and integration planning.
#### Recent Updates in the Capabilities Endpoint: The capabilities endpoint and its JWT structure are designed to evolve with iSHARE standards and practices. As the new versions of iSHARE or additional features are introduced, the capabilities information provided through this endpoint will be updated accordingly. This ensures users always have access to the most current and relevant information about available services and features. * Enhanced Security Features: Improvements in authentication and authorization protocols to address security challenges and ensure data protection. * Extended Data Models: Updates to the data models to support additional types of services and capabilities, improving the flexibility and applicability of the endpoint. * Performance Optimisation: Enhancement of API performance to handle higher volumes of requests and provide faster response times. #### What are the Future Possibilities for the Evolution of the Capabilities Endpoint? The Technology related to the Capabilities Endpoint is expected to evolve in several ways: * Improved Data Exchange: Future updates could include enhancements to data exchange protocols and formats, making the capabilities endpoint even more robust in providing capabilities information. * Dynamic Capabilities: The endpoint may evolve to offer more real-time information, reflecting changes in capabilities as they occur rather than at scheduled intervals. * Advanced Interoperability: As the iSHARE ecosystem grows, the endpoint may integrate with other data-sharing standards and frameworks, providing a more seamless experience for users. * Enhanced Security Measures: Advances in security measures may lead to improved authentication and authorization mechanisms, impacting how access tokens and JWTs are handled. # Quick walkthroughs To streamline the implementation, here are several guided walkthroughs covering various components * [ ] [Participant Management ](/apply-ishare/quick-walkthroughs/participant-management) * [ ] [Postman Collections ](/apply-ishare/quick-walkthroughs/postman-collections) * [ ] [Demo Videos](/apply-ishare/quick-walkthroughs/demo-videos) ([Getting an access token ](https://youtu.be/bH6rjBm3wUA), [Authorisation Registry demo](https://youtu.be/uiizp9OXCJg)) # Participant Management (Adding Participants on the Participant Registry UI) This page explains how a Participant can be added to the Participant Registry. #### 1. Fill out participant details

Adding Participant Details

Participant details While generating/obtaining the certificate, a valid **PartyID** is also required. This PartyID or identifier is used to register the participant in the dataspace.\ The **party name** is the Organisation Name used to generate/obtain the certificate.\ **Adherence status** should be active for participants that are in compliance with the dataspace agreements.\ **Capabilities url** is an optional URL for parties providing services, referring to the [Capabilities endpoint](https://dev.ishare.eu/common/capabilities.html) used to discover the participant's services. \ **Registrar Data Space ID** - is the ID of the dataspace onboarding the participant.
#### 2. Adding the certificate If a certificate is required (see below), upload the certificate and click 'Save'.

Certificates addition in the Participant Registry

#### 3. Add an Authorisation Registry and additional details For parties with the role of Entitled Party, optionally an Authorisation Registry can be added.

Adding Additional Details

AR & additional details Authorisation Registry and Additional Participant Details are optional.
#### 4. Add agreements and add the party to the right dataspace Add two agreements (Terms of Use and Accession Agreement) and optionally extra agreements that are specific for a data space.

Adding Agreements

Agreements The signed Terms Of Use and Accession Agreement are required for all participants. Dummy agreements can be added for test environment. For Certified Parties - Certified Parties agreement is required. For more information on the Legal agreements required for onboarding participants to a dataspace, refer to the [Legal Agreements in the Trust Framework.](https://framework.ishare.eu/detailed-descriptions/legal)
#### 5. Add party roles Select the roles which the participant will fulfill.

Adding Roles

Roles A minimum of one role is required to be added. Organisation or Participants can also play multiple roles. For clarity on Roles used in the Trust Framework,[ refer here](https://framework.ishare.eu/main-aspects-of-the-ishare-trust-framework/framework-and-roles).
{% hint style="info" %} For all participants with the role of Service Provider, Service Consumer with machine-to-machine API implementation, Authorization Registry or Identity Provider a certificate is required. * For production implementations refer to [iSHARE's eSEAL Guide](https://github.com/iSHAREScheme/eSEALsGuide). * For UAT/test implementations refer to [creating a test certificate](/apply-ishare/test-certificate). {% endhint %} # Postman Collections ### Walkthrough of Postman (demo 1a) {% embed url="" %} ### Walkthrough of Postman (demo 1b) {% embed url="" %} *** ### Stepwise Guide If you have downloaded the test postman collection you can retrieve fictive date on a fictive container from Warehouse13. As you may know Warehouse13 is the dummy Service Provider for people wanting to try out iSHARE. So you in the role of ABC Trucking can get container data by following these steps: 1. In Postman make sure you Global Variable is set to: “iSHARE Test”
2. Open this request and hit send to receive an Access Token:
3. Open this request and hit send to receive date on container #180621:
The parameters of this request includes the Client Assertion that you send in step #2 PLUS the actual Access Token that you get from step #2. # Demo Videos This section contains various video demos of iSHARE in action. Below some videos timestamps are included. These are abbreviations for the test parties: * **AR** - Authorisation Registry * **SO** - Scheme Owner (since iSHARE 2.0 this role is performed by the Satellite or Participant Registry - wherever SO is mentioned, this must be interpreted as Participant Registry) * **W13** - Warehouse 13 (Service Provider) ### Getting an access token {% embed url="" %} Video on how to get an access token {% endembed %} Slides are available here: {% file src="/files/ru7AizXkOYk6y89l0DWL" %} ### Authorization Registry {% embed url="" %} # Conformance Test Tool (CTT) ## What is Conformance Testing? For any organization aiming to use the iSHARE Framework, meeting its technical and compliance standards is crucial. The [Conformance Test Tool (CTT)](https://dev.ishare.eu/introduction/conformance-test-tool) plays a pivotal role in this process, helping parties verify that their API services are aligned with iSHARE requirements. Conformance testing is an integral process that ensures each participant’s system adheres to the established standards and protocols of the [iSHARE Trust Framework](https://framework.ishare.eu). This testing verifies that systems are correctly implemented according to iSHARE requirements, guaranteeing that all interactions within the network are interoperable and compliant with the framework. ## The Importance CTT in the iSHARE Ecosystem iSHARE Framework is structured around robust common standards, where every participant—whether a Service Provider, Authorization Registry, or Identity Provider—must demonstrate conformance. The CTT is at the heart of this validation process, functioning as an evaluator of technical readiness. By using the tool, parties can assess their compliance with iSHARE’s API requirements, a critical step before fully joining the network. Passing the CTT signifies that an organization’s API services operate within iSHARE specifications, minimizing the risk of operational failures or security breaches once in production. What makes the CTT essential, beyond its technical assessments, is its role in preserving trust. For iSHARE Framework, trust between participants is paramount. The tool, by ensuring adherence to shared standards, reinforces the collective reliability and security of the entire ecosystem. ## How Does the CTT Work in iSHARE? The [iSHARE Conformance Testing Tool](https://ctt.isharetest.net/admin) (CTT) is an automated tool designed to verify that participants’ systems meet iSHARE’s compliance standards. The CTT operates through a sequence of test cases tailored to the specific role an organization seeks to fulfill within the network. Each role corresponds to distinct API requirements, meaning that testing isn’t a one-size-fits-all solution. Instead, the tool dynamically adjusts based on the endpoints relevant to the party being tested. For example, Service Providers need to verify that their /token and /capabilities endpoints are functioning within specification, while Authorisation Registries face additional checks for their delegation mechanisms. Each test case is meticulously designed to cover a range of potential interactions, ensuring that the organisation’s system can handle both routine and edge-case scenarios. For technical users, the CTT provides logs and raw data, allowing for granular examination of the system’s behavior under test conditions. This depth of feedback is especially useful in multi-step test cases where complex interactions are being simulated Participants can log into the CTT portal to run role specific test cases on their API services. After completing a test run, the CTT provides detailed feedback, including whether the participant has passed or failed the tests. This tool plays a key role in the onboarding process, facilitating the smooth integration of new participants into the network. ## Delegation as a Key Component of Testing Of particular significance in the CTT process is the testing of delegation capabilities, especially for Authorization Registries. Delegations form the core of how access rights are managed and transferred within the iSHARE network. Ensuring that these transfers function properly is essential for maintaining the network’s integrity. The CTT evaluates an organisation’s ability to correctly respond to delegation requests. A typical test involves verifying that the /delegations endpoint appropriately handles both permit and deny responses, depending on the context of the request. ## Reinforcing Trust and Security The Conformance Test Tool is more than just a technical requirement for joining the iSHARE Trust Framework’s network; it is also a tool for reinforcing trust and security. In an ecosystem as decentralized and interconnected as [iSHARE](https://ishare.eu/home/about/trust-framework/) , trust between participants is non-negotiable. When an organization passes the CTT, it’s not merely a green light for technical compliance; it’s an indicator that the organization has the capacity to operate securely within the wider data-sharing ecosystem. Security breaches, operational failures, and non-compliance issues not only jeopardize the individual organization but can also damage the credibility of the entire ecosystem. Therefore, the CTT acts as a first line of defense, ensuring that only organizations with robust and compliant technical infrastructures can join the production environment. ## Ongoing Relevance: Future Proofing Through Continuous Testing As the iSHARE Framework continues to evolve and new participants bring innovative services into the ecosystem, the need for ongoing validation becomes more critical. The CTT is not a one-time test but an evolving platform that adapts to new technical requirements as the ecosystems expand. This adaptability is crucial for maintaining the relevance and security of the network over time. For instance, as new services and roles are introduced, the CTT will evolve to incorporate additional test cases, ensuring that every organization—regardless of its function in the network—can be tested against the latest standards. In this way, the CTT future-proofs the ecosystem by maintaining high levels of security and operational integrity as the network grows. ## Can the CTT Be Tailored to Specific Data Spaces or Use Cases? The CTT is designed with adaptability in mind, enabling customisation to suit specific roles within the ecosystem. While the Framework ensures interoperability, the tool can be tailored to address the unique requirements of different applications. This flexibility ensures that the ecosystem can support a wide array of use cases, while still adhering to its essential principles of trust and compliance. The iSHARE Conformance Test Tool (CTT) is an essential component for ensuring that participants meet the necessary standards required to operate within the ecosystem. By automating the compliance verification process and providing tailored tests for different roles, the CTT facilitates seamless integration and consistent data sharing across the ecosystem. The [next steps](https://dev.ishare.eu/introduction/conformance-test-tool#what-is-next) involve passing the test run for your specific role to ensure your compliance with onboarding requirements in the iSHARE production environment. For further details on utilising the CTT, please refer to the [dedicated CTT page](https://dev.ishare.eu/introduction/conformance-test-tool) in our developer portal. ## Conclusion The Conformance Test Tool (CTT) is a critical safeguard within the iSHARE ecosystem, serving both as a compliance check and as a mechanism for maintaining trust and security across the network. It offers participants a detailed, self-service testing mechanism to ensure their API services align with iSHARE standards. By simulating real-world interactions and testing key elements such as delegation and token exchanges, the CTT provides assurance that every participant in the network can operate in a secure and compliant manner. As the Framework continues to evolve, the ongoing role of the CTT in validating new services and ensuring adherence to standards will remain vital to the ecosystem’s success. In short, the CTT not only ensures the smooth onboarding of new participants but also strengthens the very foundation of trusted data-sharing.
# Certificates Cheat Sheet ## About digital certificates A digital certificate, also known as a public key certificate, is used to cryptographically link ownership of a public key with the entity that owns it. Digital certificates are for sharing public keys to be used for encryption and authentication. Each public key has a corresponding private key, data encrypted using either one of the keys can only be decrypted with its counterpart. As the private key is kept secret, data that is decrypted using the public key indicates that the source of the information can only be the holder of the private key. Digital certificates include the public key being certified, identifying information about the entity that owns the public key, metadata relating to the digital certificate and a digital signature of the public key created by the issuer of the [certificate](https://www.techtarget.com/searchsecurity/definition/digital-certificate). Certificates come in various formats, of which the common ones are described [here](https://www.sslshopper.com/ssl-converter.html). ### PEM Format The PEM format is the most common format that Certificate Authorities issue certificates in. PEM certificates usually have extensions such as .pem, .crt, .cer, and .key. They are Base64 encoded ASCII files and contain "-----BEGIN CERTIFICATE----- " and "-----END CERTIFICATE-----" statements. Server certificates, intermediate certificates, and private keys can all be put into the PEM format. Apache and other similar servers use PEM format certificates. Several PEM certificates, and even the private key, can be included in one file, one below the other, but most platforms, such as Apache, expect the certificates and private key to be in separate files. ### DER Format The DER format is simply a binary form of a certificate instead of the ASCII PEM format. It sometimes has a file extension of .der but it often has a file extension of .cer so the only way to tell the difference between a DER .cer file and a PEM .cer file is to open it in a text editor and look for the BEGIN/END statements. All types of certificates and private keys can be encoded in DER format. DER is typically used with Java platforms. ### PKCS#7/P7B Format The PKCS#7 or P7B format is usually stored in Base64 ASCII format and has a file extension of .p7b or .p7c. P7B certificates contain "-----BEGIN PKCS7-----" and "-----END PKCS7-----" statements. A P7B file only contains certificates and chain certificates, not the private key. Several platforms support P7B files including Microsoft Windows and Java Tomcat. ### PKCS#12/PFX Format The PKCS#12 or PFX format is a binary format for storing the server certificate, any intermediate certificates, and the private key in one encryptable file. PFX files usually have extensions such as .pfx and .p12. PFX files are typically used on Windows machines to import and export certificates and private keys. Please note that for Java the PKCS12 format is now recommended as an industrial standard, removing the need for creating a Java key store (JKS). ## iSHARE specific certificate types Within iSHARE, certificates and public keys are used for 3 main purposes. Identification & authentication of a legal entity, digital signatures to protect the integrity of digital claims and securing HTTP connections to servers. As specific internal usage and storage of certificates and key pairs is very much dependant on the on-premise situation, this section details only the standardised usage of certificates regarding iSHARE. This entails API HTTP requests, and certificate details found in these requests. On certificates itself, the common X.509 format is used, where the intended key usage contains ‘Digital Signature’. As for certificate authorities (CA), iSHARE trusts CAs that are certified to issue [certificates ](https://ec.europa.eu/digital-single-market/en/trust-services-and-eid)within the eIDAS framework. More specifically, only so-called ‘qualified seals’ within the scope of eIDAS. Within the Netherlands, during start-up phase ‘PKI-Overheid Server certificates’ will be allowed. In general, the OAuth access token request is where certificates are used by a client as prove to their identity claim (“client\_assertion”). The other main use is for signing server responses in the form of (signed) JSON Web Tokens. Please refer to [jwt.io](https://jwt.io) for everything related to JSON Web Tokens, and for libraries for various programming languages that provide functionality for creating, signing and validating JSON Web Tokens. ### iSHARE JSON Web token ‘x5c’ header When creating an iSHARE compliant JWT, the header field of this token contains an ‘x5c’ parameter. This field contains an array of strings. The value of the string is a PEM encoded certificate, without the BEGIN and END tags, as depicted on the right. The certificate used must match the certificate used by the client in the iSHARE admission process. iSHARE Scheme Owner /testing/generate-jws * certificateHash (request header) SAH256 hash (without “:”) of certificate associated with private key Note: this API is only for testing and is not available for production, participants must be able to create their own JWS iSHARE Scheme Owner /testing/generate-jws * privateKey (request body) raw ‘text’ of PEM formatted RSA private key * Endpoint only accepts iSHARE Test certificates as input and will discard the private key after creating a signed JWT Note: this API is only for testing and is not available for production, participants must be able to create their own JWS iSHARE Scheme Owner /certificate\_validation * certificate (request body) raw ‘application/json’, array with strings * Each string is a PEM encoded certificate, which is then base64 UTF8 encoded Note: this API is for temporary use only, as it is recommended to do certificate validation yourself. The Scheme Owner is not liable for invalid responses from this endpoint ## OpenSSL conversion commands Certificate formats can be converted into one another, enabling developers to acquire a suitable certificate format for their systems. This can be done via online tools or services, but also directly on your machine using OpenSSL. By using OpenSSL, you can keep your sensitive data on your machine, rather than sharing it online. After installing OpenSSL on your machine, you can use the following commands for certificate/key conversion. Please refer to [www.openssl.org ]()to learn more about OpenSSL. #### .p12 to .pem conversion Convert .p12 (certificate+key) to .pem in new file ``` Openssl pkcs12 -in filename.p12 -out filename.pem ``` Convert .p12 (certificate+key) to .pem (certificate only) in new file ``` Openssl pkcs12 -in filename.p12 -out filename.pem -nokeys ``` Convert .p12 (certificate+key) to .pem (private key only) in new file ``` Openssl pkcs12 -in filename.p12 -out filename.pem -nocerts ``` #### .pem to .der conversion Convert .pem (certificate) to .der (certificate) in new file ``` Openssl x509 -outform der -in filename.pem -out filename.der ``` Convert .der (certificate) to .pem (certificate) in new file ``` Openssl x509 -inform der -in filename.der -out filename.pem ``` #### .pem to .p7b conversion Convert .pem (certificate) to .p7b certificate (requires CA certificate as well) ``` Openssl cr12pkcs7 -nocrl -certfile filename.pem -out filename.p7b -certfileCAcertificatefilename.pem ``` Convert .p7b (certificate) to .pem (certificate) ``` Openssl pkcs7 -inform der -in filename.p7b -out filename.pem ``` #### .pem various actions Inspect .pem (private key) cryptographic details, such as modulus and exponent, display in terminal ``` Openssl rsa -inform PEM -text -noout < filename.pem ``` Inspect .pem (certificate) SHA256 hash, display in terminal ``` Openssl x509 -in filename.pem -sha256 -noout -fingerprint ``` # Technical FAQs
What is the purpose of postman collections? Through the postman collections, you can now test how the dummy party ABC Trucking interacts with the Participant Registry, Warehouse 13 and the Authorisation Registry! Please don’t forget to also install the Test environment to get the correct variable [Here is a quick walkthrough on using them](/apply-ishare/quick-walkthroughs/postman-collections). You can find the private keys of ABC Trucking in these Postman collections. Of course, real users should never under any circumstance share private keys of their certificates. In these collections however, it is necessary to share the private keys so that you may impersonate ABC Trucking.
What do I do when I encounter Certificate Export Error? Using OpenSSL to export the certificate from an iSHARE Test certificate file (P12), might result in an error. **Command:** ```html openssl pkcs12 -in infile.p12 -nodes -nokeys -out outfile.pem ``` **Enter Import Password:**
**Result:** Error outputting keys and certificates ```html 40D2B40002000000:error:0308010C:digital envelope routines:inner_evp_generic_fetch:unsupported:crypto/evp/evp_fetch.c:373:Global default library context, Algorithm (RC2-40-CBC : 0), Properties () ``` **Explanation:** This means that the RC2-40-CBC key algorith is not available. Try the following command: ```html openssl pkcs12 -in infile.p12 -nodes -legacy -nokeys -out outfile.pem ``` Or try a different workstation to extract the certificate.
What do I do when I encounter Private Key Export Error? Using OpenSSL to export the private key from an iSHARE Test certificate file (P12), might result in an error. **Command:** ```html openssl pkcs12 -in infile.p12 -nocerts -out outfile-key.pem ``` **Enter Import Password:**
**Result:** Error outputting keys and certificates ```html 40D2B40002000000:error:0308010C:digital envelope routines:inner_evp_generic_fetch:unsupported:crypto/evp/evp_fetch.c:373:Global default library context, Algorithm (RC2-40-CBC : 0), Properties () ``` **Explanation:** This means that the RC2-40-CBC key algorith is not available. Try the following command: ```html openssl pkcs12 -in infile.p12 -legacy -nocerts -out outfile-key.pem ``` Or try a different workstation to extract the key. **Convert key into RSA key** If you want to convert the key into an RSA key use the following command ``` openssl rsa -in outfile-key.pem -out outfile-key-rsa.pem ```
What should be in the 'aud' parameter of an access token? The "aud" parameter should be a single string value with the identifier of the target organization (and not an array). For example, for i4Trust experiments, the target is the i4Trust Satellite or Participant Registry, which has the identifer "EU.EORI.NLi4TRUSTSAT". Therefore, the "aud" parameter is - aud: "EU.EORI.NLi4TRUSTSAT"
What kind of token is prerequisite in an M2M flow? For M2M flow, you'll need to obtain an access token by providing a signed iSHARE-JWT at the token endpoint of the service provider.
API specification for H2M interaction iSHARE specifications are generic and caters to different possible scenarios, some of them are mentioned in the dev portal. A user may be working for multiple organisations and while using the same identity provider in which case the additional steps of organisation selection are to be followed. If the user only is known for one organisation within IDP then that flow is not necessary.
Identity provider for organisations In the examples, the IDPs are shown as locally hosted components, but it symbolises that they are actually provided by service providers (IDPs) and each organisation has the right to choose its own preferred IDP. In experiment and in PoC, technically hosting IDP only allows you to demonstrate the concept, however, in production you would use a real IDP which meets the specifications. Due to standardised specifications you do not need to recode when you switch from one provider to another.
Where do I find information for user interaction with service provider? The [**Authorization page**](https://dev.ishare.eu/reference/authorization.html) (dev portal) explains that user interaction with the service provider can happen in two ways: the service specific or the portal approach. The explanation of these methods describes the difference in the request parameter of the /userinfo endpoint.
Different policy-expiration deadlines for different policy-targets For example, if policy contains two different resource-types, can each resource type have its own policy expiration deadline attribute? Answer - Yes, ideally you should be able to create separate policies for such reasons, however, as far as the reference implementations, this is not yet supported. If you need to use this feature then you may need to make some changes to the code base. For one delegation evidence there is one defined time limit. There are no time-limit parameters within the "policySets' ' array; which is the array that contains specific policies. You could have many delegation evidences, containing policies with different time limits.
Can a JWT be hardcoded if it is according to iSHARE specifications? JWT token cannot be hardcoded as it is usually valid only for 30 seconds so you need to generate new one every time.
Is the /createpolicy endpoint in the AR ( after the successful authentication, with the access token) the only way to create a new policy? For creation of policies if you are using iSHARE test AR instance then make sure that you have access to GUI where you can also create policy via GUI apart from API. For getting access to AR GUI, share a valid EORI number and email ID for a participant who would create policy for that EORI number, so access can be granted. <[support@ishare.eu]> Note: one email ID can only be associated with 1 EORI number. Once the details are shared, you should receive an email to setup your account. Even if email is not received, you can go to the and use forgot password to setup your account with this email id. Note, if you get forbidden message after login, then make sure that you are on correct URL. The GUI for AR can be accessed from here: For the endpoints swagger for AR:\
Can you give me an example of a delegation mask that uses delegation_path? [As specified on the dev portal](https://dev.ishare.eu/delegation/delegation-request.html), it is an array of EORI (ID) of participants which form the path in the delegation chain. There is no example given there, but it is a full list of EORIs which determine the sequence of delegation path to aid Service Provider to traverse through that path for determining the authorisation. So to explain: If EU.EORI.XX020 is service consumer and EU.EORI.XX002 is the Service Provider and EU.EORI.XX010 is the entitled party who gave rights to EU.EORI.XX0nn where nn > 10 until 20 (assuming that is the delegation path i.e. from 10-->20, just for this example, of course its not real) then the delegation\_path array will contain EORIs from EU.EORI.XX010 -> EU.EORI.XX020. That could be for example:\ \[EU.EORI.XX010, EU.EORI.XX013, EU.EORI.XX016, EU.EORI.XX020]\ \[EU.EORI.XX010, EU.EORI.XX015, EU.EORI.XX020]\ \[EU.EORI.XX010, EU.EORI.XX017, EU.EORI.XX013, EU.EORI.XX016, EU.EORI.XX020]... and the list can go on with any permutations and combinations. However, it could also be that due to privacy reasons, only n-1 delegator id is available, then it would be issuer of the issuer, issuer and subject (service consumer), in which case it's path is not conclusive and Service provider will have to use different mechanisms to traverse through the path (not specified).
Invalid JWT tokens when server time is out of sync with the local time of the computer When the server time is out of sync with the local time of the computer, this might lead to invalid JWT tokens. Using a leeway can prevent this problem.
Is it possible to deploy the Participant Registry across multiple machines for redundancy? Yes, the standard iSHARE [Participant Registry installation guide](https://github.com/iSHAREScheme/iSHARESatellite/blob/main/docs/INSTALL.md) describes a single-VM setup for simplicity, but the components can be distributed across multiple servers. A custom deployment plan must be created for such environments, and the iSHARE team will support to help align with framework compliance.
What should be configured as valid redirect URLs in the IDP? While wildcards are allowed, it is recommended to verify that redirection only occurs to the URL specified in the signed authentication request. Alternatively, clients can be registered without a security key and then set redirect URLs.
How can I obtain a test certificate to participate in the iSHARE test environment? To obtain a test certificate for use in the iSHARE test environment, you need to follow the steps outlined on the Trust Body of Knowledge. The process involves generating a Certificate Signing Request through the iSHARE Certification Portal. Detailed instructions are available here: [Apply for a test certificate](https://trustbok.ishare.eu/apply-ishare/test-certificate).
How can I register with a Participant Registry in one of the roles? The Party can be created through the /parties endpoint via APIs or manually through the Participant Registry UI. This endpoint allows a Participant Registry to create a participant based on OIDC proof from a certified IDP. It is important to ensure you are compliant with the requirements for the role you want to perform before registering with the Participant Registry
Can different policySets within a delegation evidence have their own validity periods? Currently, notBefore and notOnOrAfter timestamps are defined at the root level of the delegation evidence and apply to all policySets. For finer granularity, iSHARE will be updating this through [RFC041](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/4).
Can there be multiple Authorisation Registries per Data Space? Yes, there can be multiple ARs for each data space. While through [RFC056](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/25) in Release 3.0, a single AR can also function for multiple data spaces.
Should the x5c header in a client assertion contain the full certificate chain? Yes, the full chain (excluding the root CA) must be present in the x5c header. The root CA’s fingerprint must match an entry on the Participant Registry’s trusted list. This allows service providers to validate the certificate path without making external calls.
What should the Authorisation Registry return if a delegation request is unauthorized due to missing context? It is recommended to return a 401 Unauthorized response when the requester lacks sufficient proof, such as not being the issuer, access subject, or lacking valid previous steps. This approach is clearer than returning an empty delegation evidence and helps prevent an ambiguous interpretation of access denial.
Are service providers required to check certificate revocation using OCSP (Online Certificate Status Protocol) or CRL (Certificate Revocation List)? While not strictly required, OCSP or CRL checks are recommended depending on the risk profile of the implementation. These checks help ensure that revoked certificates are not accepted.
What happens if the partyID and certificate serial number mismatch during participant creation? There is currently no enforced validation between partyID and certificate serial number. Incorrect associations must be corrected by deleting the participant and re-registering, as partyID can’t be modified in the Participant Registry UI.
Who is allowed to query the /delegation endpoint in the Authorisation Registry? Any party with a valid client assertion may query the endpoint. However, it is recommended that requestors who are not the issuer or accessSubject provide proof (via previous\_steps) of a legitimate access right. The conformance test assumes this behaviour but does not enforce it strictly, as data spaces may define stricter rules.
Can a party register multiple certificates with the Participant Registry? Yes, a party can register multiple certificates. This allows flexibility in managing identities, supporting different environments (ex., test and production), or ensuring redundancy.
What should I do if OpenSSL reports ‘unable to verify the first certificate’ when testing a Participant Registry peer connection? This error means the certificate chain is incomplete or the root CA is not trusted. Add the CA certificate to your system and verify that the peer’s certificate chain includes all necessary intermediaries. Use openssl verify to confirm that the certificate can be validated.
What is the purpose of the /dataspaces endpoint in the Participant Registry specification? The /dataspaces endpoint lists registered Data Spaces and their details. It is used by Participants to discover the available Data Spaces. Documentation on its usage is available in the latest iSHARE developer portal.
Can participants be transferred between different Participant Registries? Yes, in theory, participants can be transferred between different (participant registry) nodes, as they are interconnected through the same Hyperledger Fabric network. Functionality to support such transfers is part of [RFC064](https://gitlab.com/ishare-foundation/cab/rfc/-/blob/ac118179053a9e95513bc3e3f51cc49abf620dfd/RFC%20Documents/RFC064/README.md).
Why might a Participant Registry peer fail to join a Hyperledger Fabric channel with a TLS error? A “TLS handshake failed” or “certificate signed by unknown authority” error usually indicates that the client does not trust the signer of the server’s TLS certificate. This can happen if the root or intermediate CA certificate is missing or misconfigured. Ensure the client trusts the CA that issued the peer’s certificate and that the certificate chain is properly configured.
Which checks must a Participant Registry perform before accepting a certificate during party registration? The Participant Registry must verify that the certificate meets the main requirements, including the validity of the Subject Name and relevant attributes. These checks ensure the certificate aligns with the participant’s declared identity and trust requirements.
# Functional Use Cases This chapter builds on the [iSHARE Trust Framework](https://framework.ishare.eu/main-aspects-of-the-ishare-trust-framework/framework-and-roles) to showcase the [key functionalities](https://framework.ishare.eu/main-aspects-of-the-ishare-trust-framework/key-functionality) in additional use cases: \ \ 1\. H2M service provision with identity info at the SP # H2M service provision with identity info at the SP In this functional use case, a service is provided by the Service Provider to the Human Service Consumer. Identity info is held at the Service Provider. ### Roles


Delegation info PIP
No delegationService ProviderEntitled PartyAuthorization Reg
Auth info PIPService Provider2. H2M service provision with identity info at the SP2a2b2c
As no delegation takes place, the legal entity fulfilling the Entitled Party-role also fulfils the Service Consumer-role. ### Depiction #### Legal relations
#### Prerequisite registration & Use case interaction
### Description **It is 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 has and manages its own authorization information (acting as a Human AR) indicating which Human Service Consumers are authorized to act on its behalf\*\*; * The delegation/authorization responsible at the the Service Consumer registers the authorization information at the Service Provider; * The Human Service Consumer is able to authenticate the Service Provider; * The Service Provider is able to authenticate the Human Service Consumer; * The Human Service Consumer has been issued identity credentials by the Service 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 **The use case consists of the following steps:** 1. The Human Service Consumer requests a service from the Service Provider; 2. The Service Provider authenticates the Human Service Consumer, and validates the iSHARE adherence of the Service Consumer; 3. The Service Provider authorizes the Human Service Consumer of the Service Consumer based on the entitlement- and authorization information registered with the Service Provider;; 4. The Service Provider executes the requested service; 5. The Service Provider provides the service result to the Human Service Consumer. ### Sequence diagram
# Introduction Data spaces interested in the iSHARE Trust Framework can the [data space template](https://template.ishare.eu/) to simplify the overarching adoption of the Framework. The template acts as bridging documentation to ensure better alignment to introduce specific additions to data spaces while maintaining references to the Trust Framework. This aids in version management and interoperability among different data spaces, thereby extending the iSHARE Trust Framework’s scope and usability. **How iSHARE Lays the Foundation for Collaborative Partnerships?** iSHARE enables the important layer of trust in data sharing by providing a base layer of requirements and establishing agreements aimed at enhancing exchange conditions and empowering new forms of collaboration. The decentralised iSHARE Trust Framework gives complete control to data owners. Some practical examples include: **Data Space for Sustainability of Non-Residential Buildings (DVU)**: The [DVU (Datastelsel Verduurzaming Utiliteit)](https://www.rvo.nl/nieuws/energiegebruik-gebouwen-inzien-met-nieuw-datastelsel) data space aims to enhance energy efficiency in Dutch businesses. It provides quick access and analysis of energy usage, improving data accessibility and security. It allows comparisons of energy consumption per square meter across different building types. **i4Trust:** [i4Trust](https://i4trust.org/), a collaboration between [iSHARE Foundation](https://ishare.eu/nl/home/over/de-stichting/), [FIWARE,](https://www.fiware.org/) and[ FundingBox](https://fundingbox.com/), aims to speed up data space development in Europe. It offers an adoption acceleration program providing funding, technical support, and mentoring. **Basic Data Infrastructure (BDI):** The [Basic Data Infrastructure (BDI)](https://bdinetwork.org/) expands Data Spaces into the physical domain, aligning with conventional and innovative data sharing methods vital for operations and supply chains. It relies on comprehensive agreements for automated and secure communication. Additionally, BDI fosters agreements on language and concepts, enhancing communication by incorporating semantics for automated processing and mutual understanding of data formats. **iSHARE Interoperability: A Path to European Adoption for Data Sharing** The true realisation of this vision occurs as more companies embrace the iSHARE Trust Framework as their preferred base layer and standard for data exchange. This evolution signifies a pivotal moment in shaping the future of data exchange and governance. # Data Space Designers The Complexity of Designing Data Spaces Designing a data space is no simple task. Think of it like building a massive marketplace where organisations and different parties come together to share their data efficiently, safely, and fairly. This data space must operate under clear guidelines and rules so that everyone benefits without confusion or conflict. It’s not just about connecting computers; it's about building an environment where every participant—whether large or small—has something valuable to offer and gain. To make this happen, you need to work through three essential layers: the business layer, the governance layer, and the technology layer. {% tabs %} {% tab title="Business Layer" %} The first layer, the business layer, is all about incentives—who gets what and why they should be part of the data space. For a data space to work, organisations need to find value in participating. They should be able to access valuable data that helps them solve problems, make better decisions, or improve their services. It’s like a marketplace where every vendor and customer finds something they need, whether it’s raw data for research, insights for business growth, or innovations for better customer service. {% code overflow="wrap" fullWidth="true" %} ``` For example, if you’re building a health data space, hospitals might want to easily store and share patient records. Researchers might want access to anonymised data to improve treatments, while patients will need control over who can access their sensitive information. The key to a successful data space is that all participants find value in the exchange of data, making the space sustainable and attractive. ``` {% endcode %} {% endtab %} {% tab title="Governance Layer" %} The governance layer is where the rules of the data space are established. In order for everyone to participate fairly and smoothly, there need to be clear guidelines on how data is shared, who has access, and under what conditions. This layer ensures that all participants know how to interact, what the boundaries are, and how data flows without any one party taking over. {% code overflow="wrap" %} ``` For example, in a manufacturing data space, there need to be rules about what data is visible to other participants, what remains private, and how disputes are resolved. This governance structure ensures transparency and trust among participants, fostering a collaborative environment where data can flow freely and securely. ``` {% endcode %} {% endtab %} {% tab title="Technology Layer" %} The technology layer is the backbone of the data space. It ensures that the system works for everyone, no matter how small or big they are. This means creating a robust, scalable infrastructure that can handle vast amounts of data and many users at once. The technology must be secure and flexible, allowing the data space to grow over time. {% code overflow="wrap" %} ``` For example, in a logistics data space where buses, trucks, and stores all share data to improve deliveries, the technology has to handle real-time updates, manage a growing number of participants, and ensure the data flows seamlessly across different systems. Without a strong technology layer, the data space risks crashing under pressure or becoming outdated too quickly. ``` {% endcode %} {% endtab %} {% endtabs %} *** ## The Role of Federation in Data Spaces As data spaces grow, it becomes harder for one organization to manage everything. This is where federation comes in. In a federated data space, different parties help manage specific parts of the system. These helpers, or federated bodies, ensure that the data space remains organised, secure, and functional, even as more participants join. Federation also leads to decentralisation, where no single group or person controls the entire data space. Instead, different sections look after themselves, but they all agree on basic principles. This decentralisation spreads out responsibility, making the system more flexible and fair. Everyone has a role, and no single entity holds all the power. {% hint style="success" %} For example, in a large smart city data space, you might have one group managing traffic data, another handling energy usage, and yet another responsible for public transportation data. These groups work together under shared rules but manage their own sections independently. {% endhint %} *** ## Aligning the Design Phase with the Use Case Before you even begin building a data space, it’s essential to align the design with the specific use case. This means gathering ideas from all potential participants and figuring out how they will use the data space to meet their needs. {% hint style="success" %} For instance, let’s consider a health data space. Hospitals want to securely store and share patient records. Researchers need access to anonymised data for studies, while patients want to control who sees their data. These different use cases must be aligned so that all participants can share data and benefit from it. The key is to start small—perhaps with just a few hospitals sharing basic patient information—and expand later by adding more participants and features as the system proves itself. This approach ensures that the data space remains manageable and functional as it grows. {% endhint %} *** ## Balancing Business Needs with Technical Innovation A key challenge in designing data spaces is balancing business needs with technological innovation. {% hint style="success" %} Let’s look at a smart city data space as an example. City planners might need real-time traffic data to manage flow and public transportation efficiently. On the other hand, tech companies might want to use that data to create new apps, like smart parking solutions or real-time traffic updates. The city must balance its resources: ensuring that essential services like traffic lights and buses run smoothly while encouraging innovation that could improve quality of life. If the city only focuses on the basic services, it risks missing out on groundbreaking solutions. But if it focuses too much on the latest technology, it could lose track of the essential services people rely on every day. {% endhint %} *** ## Building from Scratch vs. Harmonising Existing Technology When building a data space, organisations face a big decision: should they build from scratch or use existing technology? Building from scratch offers full customisation to meet specific needs, but it’s costly, time-consuming, and risky. On the other hand, using existing technology is faster and cheaper because the solution is already proven. However, it may not offer the same level of customisation. For many organisations, this trade-off between speed and control is a critical decision. {% hint style="success" %} For example, a logistics company might use common infrastructure but build a custom tool that directly connects their fleet of trucks with the stores they deliver to. This allows them to see every aspect of the data flow, design security protocols and data management systems. {% endhint %} *** ## The Foundation of a Data Space: Infrastructure The infrastructure behind data spaces is like the foundation of a building—it must be strong, flexible, and capable of growing as demands increase. As more participants join a data space, the system must scale up to accommodate more users and data. Efficient infrastructure ensures that data can be shared quickly and reliably, even as the volume of data grows. Maintenance and upgrades are also crucial for keeping the data space relevant, secure, and functional. {% hint style="success" %} For example, in a health data space that starts with a few hospitals, the infrastructure must grow to handle more healthcare providers as they join. This might involve upgrading servers, improving bandwidth, or introducing cloud-based systems that can adapt to the needs of the data space. {% endhint %} *** ## Conclusion Designing and managing a data space is a complex, multi-layered process that requires careful planning and execution. To succeed, you need to ensure that the data space fits the needs of all participants, balances basic necessities with innovative technologies, and makes strategic decisions on whether to build from scratch or leverage existing solutions. Clear governance and infrastructure sustainability are the cornerstones of a functional, secure, and future-proof data space that can serve its participants effectively for years to come. iSHARE Trust Framework and the DSSC blueprint are good starting points for the design and creation of a data space. Through the [data space template](https://template.ishare.eu/) and the co-creation methodology, components can be combined and integrated to achieve the core functionality of a data space. # Business Models for Data Spaces Designing Sustainable Business Models for Data Spaces As digital ecosystems become increasingly interconnected, data spaces have emerged as essential platforms for secure data sharing, collaboration, and innovation. Data spaces allow organisations, companies, and institutions to exchange data within a trusted environment, unlocking new value propositions and boosting the utility of shared data. However, for these spaces to be viable over time, they need strong business models that ensure economic sustainability while balancing costs, revenues, and the contributions of various stakeholders. This article explores the critical components of sustainable business models for data spaces, focusing on how they can be structured for long-term success, while addressing the challenges of maintaining fairness, security, and value creation for all participants. *** **The Importance of a Sustainable Business Model** A well-designed business model is crucial to keep a data space operational, both in terms of cost-efficiency and value creation. For instance, standardising the interfaces used for data sharing can significantly reduce operational expenses, enabling smoother interactions between participants and increasing the overall value of the data space. Additionally, robust business models empower data owners to maintain control over how their data is used while still maximising its utility for participants. Unlike traditional single-entity business models, data spaces operate on a multi-sided, collaborative model. This structure involves multiple stakeholders, including data providers, recipients, and service providers, all contributing to the space’s value. The challenge is to ensure that this collaborative model is sustainable, meaning the costs and benefits are shared fairly among participants, and that the space continues to operate and grow in the long term. *** **Key Components of a Sustainable Business Model for Data Spaces** 1. Balancing Costs and Revenues: A sustainable business model must strike a balance between the costs of maintaining the data space and the revenues or benefits it generates. Data spaces are resource-intensive; they require infrastructure for secure data exchanges, governance frameworks, and intermediary services like identity management and data cataloguing. Whether the data space operates as a for-profit marketplace or a non-profit initiative, its financial structure must be solid enough to cover operational costs while incentivizing ongoing participation. 2. Multi-Sided and Collaborative Models: Interactions between different parties within a data space are foundational to its success. These interactions foster interoperability and value creation by enabling seamless data sharing. The more entities that join the data space, the more valuable it becomes—a concept known as network effects. As the number of participants increases, the potential for data exchange and innovation grows, making the space more attractive to new members. This creates a self-reinforcing cycle that enhances the space’s economic sustainability, driving greater collaboration and utility for all parties involved. 3. Value Proposition and Creation: A core aspect of any business model is the ability to create value for both data providers and data consumers. This could include direct financial returns, improved services, or new business opportunities. When participants see real value in sharing their data, they are more likely to engage actively, fostering a vibrant ecosystem where data flows securely and efficiently. The challenge for business models is to ensure that these benefits are fairly distributed, maintaining a healthy balance between value creation and cost-sharing. 4. Intermediary Services: Key services such as identity management, data cataloguing, and connection provision are necessary to streamline operations within the data space. These intermediaries ensure smooth and secure collaboration, which is crucial for economic sustainability. 5. Governance and Compensation Mechanisms: Data spaces require robust governance frameworks that align with their broader strategic goals. Transparent governance helps ensure that data-sharing policies are enforced fairly and that all participants understand their roles and responsibilities. Additionally, compensation mechanisms must incentivize participation while maintaining fairness. For example, models like the "reaper pays" principle ensure that those who derive the most value from the data space contribute proportionately more to its upkeep. Governance also plays a key role in maintaining trust within the data space. Participants need to be confident that their data is being shared securely and ethically, which makes transparent governance not just a good practice, but a necessity for long-term sustainability. 6. Strategic Alignment: The business model must align with the data space’s broader strategic goals - whether they are market-driven, cooperative, or mission-based. The model should consider legal constraints, operational scalability, and revenue distribution to ensure that all participants benefit fairly. Goals can be short-term, such as expanding market share, or long-term, such as achieving sustainability or meeting societal objectives like CO2 emissions reduction. By analysing these goals and aligning the business model accordingly, data spaces can ensure that they remain economically viable while also achieving their broader objectives. *** **Economic Sustainability: Data Spaces and Governance Models** Data spaces can be created through different pathways, each influencing the business model's structure: * Commercially Driven: Organisations might run the data space like a business, setting the rules and making sure everything runs smoothly. They might charge participants to use the data space, but they also make sure it’s well-maintained and offers valuable services. * Cooperative Initiatives: Data space participants work together to make decisions. This model works well when everyone has equal stake and benefits from the data space. * (Non)Governmental or NGO-Driven: Data spaces initiated by public bodies or NGOs are often subvention-funded and may evolve into more cooperative structures over time. These spaces prioritise social impact or public interest over direct commercial returns, yet must still develop sustainable business models to ensure long-term viability. The choice of governance model—whether commercial, democratic, or cooperative—directly impacts the economic structure and decision-making process of the data space. Ensuring that governance aligns with the strategic goals of the participants is key to maintaining economic balance. The key is to have a clear governance model that everyone agrees on. This keeps the data space fair, transparent, and efficient. *** **Business Models for Economic Sustainability** The governing body of a data space plays a central role in defining the business model. Several models have proven effective for ensuring that data spaces remain economically viable: * Fair Share Model: All participants contribute equally to the operating costs, making this model typical for cooperative data spaces. Each stakeholder shares the financial responsibility of maintaining the space. * Beneficiary Pays Principle: In this model, stakeholders who derive the most benefit from the data space’s services (e.g., through higher usage or commercial gain) bear a larger share of the costs. This ensures that resource-heavy participants contribute more to sustaining the space. * Prime Stakeholder Funded: A primary stakeholder, such as a key service provider or NGO, funds the operations of the data space. This model lowers the entry barrier for other participants, facilitating broader participation while ensuring the space's economic sustainability. * Government Funded: In some cases, governments finance data spaces to support national or international economic and social goals.Government-funded data spaces often align with broader economic or social goals, such as improving public health or boosting digital infrastructure.This approach significantly reduces the cost burden on participants, making it easier to scale and sustain the data space. This model is especially useful for data spaces that prioritise societal impact over direct commercial returns. *** **Participant Roles and Their Economic Contributions** Understanding the motivations of participants is critical for developing a balanced business model. Typically, participants in a data space take on one or more of the following roles: * Data Owner: Holds the rights to share data and benefits from sharing it, either directly (through revenue) or indirectly (through improved services or business opportunities). * Data Provider: Offers data services that are either commercially driven or community-focused. Providers may share their own data or facilitate the sharing of data on behalf of owners. * Data Consumer: Those who use the shared data to create new products, services, or insights, often feeding value back into the data space. To ensure sustainability, the business model must consider how these roles can contribute financially to the maintenance and growth of the data space. Certified roles, such as the Authorisation Registry (AR) and Identity Providers, are essential for maintaining the security and trust within a data space. The AR ensures that data-sharing policies are strictly followed, while Identity Providers verify and authenticate the identities of participants. These services play a vital role in ensuring smooth, secure operations, but they also come with costs that must be accounted for. It's the responsibility of the data space to ensure there is enough financial support to maintain these critical roles. Another crucial part of the ecosystem is the underlying technology and services that power the data space. These systems, which handle data cataloguing, identity management, and secure data transmission, are the backbone of the entire operation. As more participants join, the data space must continually update its infrastructure to handle increased data exchange and ensure the space remains efficient and scalable. Factoring these costs into the business model is vital to sustaining long-term growth and enhancing data exchange capabilities ***
Data Monetisation in Data Spaces At its core, data monetisation in data spaces refers to the process of generating financial value from data. Unlike traditional data exchanges that may focus solely on selling data as a commodity, data spaces enable more complex, multi-faceted business models that involve collaboration, data reuse, and innovation Data is not just an asset in isolation; it becomes more valuable when it is combined, enriched, and used within a larger ecosystem. The monetisation strategies for data spaces must therefore move beyond simply "selling data" and instead focus on leveraging data as a strategic asset that drives value across various touch points. For instance, participants in a data space could monetise their data by granting access to analytics services, creating new data-driven products, or developing enhanced business services for consumers. 1. Pay-per-Use Model:\ One of the most straightforward ways to monetise data in a data space is through a pay-per-use model. In this system, participants pay based on the volume or type of data they consume. This model is highly scalable and flexible, allowing for granular control over who can access specific datasets. It is particularly useful for organisations that want to share only select portions of their data and retain control over its broader use. 2. Subscription-Based Model:\ Another common approach is a subscription-based model, where participants pay a regular fee to access the data space or certain premium features. This approach provides a predictable revenue stream, which can be used to fund the ongoing operation of the data space, including the maintenance of technology and certified roles like the Authorisation Registry and Identity Providers. Subscription models encourage long-term engagement and can foster stable relationships between data providers and consumers. 3. Data-as-a-Service:\ This model allows data providers to package their data into services that participants can access on-demand. Instead of simply selling raw data, organisations provide curated datasets or insights that can be integrated into other platforms or applications. For example, a healthcare data space might offer anonymised patient data and clinical outcomes as a service to pharmaceutical companies, enabling them to develop more effective treatments. DaaS helps monetize data by embedding it into real-time decision-making processes, making the data more actionable and valuable. 4. Freemium Model:\ The freemium model allows basic access to the data space for free, while more advanced features or premium datasets are locked behind a paywall. This approach can help attract a broad base of participants by reducing the initial barriers to entry. Over time, as participants see the value of the data space and need more advanced services or data, they are more likely to convert to paying customers. This model can be particularly effective for encouraging innovation, as smaller organisations or startups gain access to data they otherwise wouldn’t be able to afford. 5. Revenue Sharing Models:\ In collaborative data spaces, especially those that operate in a multi-sided environment, revenue-sharing agreements are often established between data providers, intermediaries, and consumers. For example, when data leads to the development of a commercial product or service, the data owner may receive a share of the revenue generated. This model encourages cooperation and ensures that each participant in the data space benefits financially from their contributions. *** #### Conclusion In summary, designing a sustainable business model for data spaces requires careful consideration of the ecosystem’s needs, participant roles, and governance frameworks. A well-crafted model ensures collaboration, maximises value for all participants, and provides a fair distribution of costs. By incorporating emerging technologies and aligning with global standards, data spaces can continue to thrive in the evolving digital landscape, unlocking new opportunities for innovation, economic growth, and social impact.
# Governance in Data Spaces ## Role of governance in data spaces To ensure a data space thrives, effective governance is essential. Within data ecosystems, some guiding principles help establish governance structures, emphasising key elements like trust, liability for licence violations, and the confidentiality of data transactions. Key Activities in Data Space Governance include: 1. Defining, establishing, and managing the data space. The governance body plays a central role in shaping the data space by defining its purpose, setting legal and operational frameworks, and managing its overall structure. This includes deciding what types of data will be shared, outlining the rules for participation, and ensuring that the space is aligned with its goals. Once established, the body continues to oversee the daily operations, making sure everything runs efficiently and according to plan. 2. Facilitate the ongoing development of the data space. Governance is responsible for ensuring the data space adapts and grows over time. This involves identifying areas where improvements or new technologies can be introduced, updating policies to meet evolving legal and regulatory requirements, and encouraging innovation among participants. By doing so, the governance body ensures that the data space remains relevant and competitive. 3. Define through co-creation what standards are used within the data space Participants in the data space work together with the governance body to define important standards, such as how data is structured (semantics), how systems communicate (APIs), and how trust is established among participants. This co-creation process ensures that the standards reflect the collective needs of all participants, making the data space fair and effective for everyone involved. 4. Oversee operational processes like onboarding and off-boarding. Governance also handles the important tasks of managing how participants join or leave the data space. This includes setting up clear guidelines for onboarding new members, ensuring they meet necessary trust and security requirements, and managing the off-boarding process to protect data integrity when participants exit. These processes help maintain a stable and secure environment within the data space. 5. Facilitate conformance testing To ensure that all participants follow agreed-upon standards and protocols, governance facilitates regular conformance testing. This process checks whether systems and data exchanges meet the technical and legal requirements of the data space. By enforcing these standards, governance helps maintain the quality and trustworthiness of the ecosystem. 6. Monitor the data space, including compliance and dispute resolution. Governance plays a crucial role in monitoring the data space to ensure that all participants comply with the agreed standards and rules. This includes managing audits, resolving disputes between participants, and addressing any breaches of the legal framework. By doing so, governance helps maintain trust and security across the space. ### Governance Structure and Sustainability in Data Spaces Data space governance is generally entrusted to a governing body that acts on behalf of the stakeholders involved. This body plays a crucial role in ensuring that the interests and concerns of all participants are adequately represented and addressed Regardless of its form, the governing body is essential for creating a transparent and accountable framework for decision-making, establishing trust among participants, and guiding the overall development and sustainability of the data space One of the key roles of the governance organiser is to assess the "trustworthiness" of data space participants. This assessment can be handled by the governing body itself or given in hands of other participant within the data space or handed over to an organisation or overarching body outside the data space. Fundamental responsibility of the governance organiser is to evaluate the "trustworthiness" of participants in the data space. This assessment is crucial for ensuring that all members adhere to agreed standards and practices, thereby maintaining the integrity and security of the data environment. The governance body itself often conducts this assessment, using established criteria to evaluate factors such as a participant's compliance with legal and ethical standards, data management practices, and previous conduct within the data space. By doing so, the governing body can ensure that all participants are reliable and that the overall ecosystem remains secure and trustworthy. Data spaces can incorporate additional clauses, including financial contributions, collective decisions on new participants, collective authorisations for data checks, and exceptions for specific players with unique roles or liabilities. The overarching cooperation or the agreement requires consensus among data space participants on functional, technical, operational, and legal aspects. While some agreements are reusable (e.g., rulebooks), others are specific to use cases. Using a legal "umbrella agreement" from a Trust Framework establishes legal interoperability across data spaces, facilitating the use of each other's data sources with shared certainty on user rights, liability, and protection. The operational maturity of services is crucial. Clear and committed Service Level Agreements (SLAs) among data space participants are essential. iSHARE Trust Framework provides basic SLA, but as each data space is unique, it can be more stringent. It's vital to make agreements about access, incident management, release management, and reporting. These are provided by the iSHARE Trust Framework and be further built upon by the data spaces. Ensuring the sustainability of the data space involves determining financing models, such as membership fees and subscriptions. Having a strategy and working business model is crucial. Questions related to governance continuity include monitoring compliance, determining who pays for services, defining participation rates, establishing rates for different data services, and outlining the admission process for new participants to safeguard interests.
# Data Act The [EU Data Act](https://eur-lex.europa.eu/eli/reg/2023/2854/oj) is one of the key building blocks of the European data economy. Applicable since 12 September 2025, it creates harmonised rules on access to and use of data generated by connected products and related services. In practice, the Data Act gives users greater control over the data they help generate. It enables individuals and organisations using connected products, such as vehicles, industrial machinery, smart appliances, medical devices, or agricultural equipment, to access that data and, where relevant, share it with third parties of their choice. For businesses, the Data Act is not only a legal compliance topic. It is also a practical data-sharing challenge. Once an organisation has the right to access data, the next question becomes: how can that data be shared securely, transparently, and under agreed conditions? This is where trusted data-sharing frameworks become relevant. iSHARE Trust Framework helps organisations move from legal permission to operational trust by supporting clear agreements, roles, identification, authorisation, and controlled data access across ecosystems.
### 1. Why the Data Act matters Data has become a strategic resource for innovation, competitiveness, and better decision-making. Connected products and digital services generate large volumes of data every day, yet much of this data remains locked within closed systems or controlled by a limited number of actors. This creates several challenges: * users often cannot access the data generated by the products they own, rent, or lease; * businesses may struggle to obtain data needed to offer repair, maintenance, optimisation, or other data-driven services; * smaller companies may face unfair contractual terms when negotiating access to data; * cloud customers may find it difficult or costly to switch providers; * data spaces need interoperability and trusted governance to scale. The Data Act addresses these challenges by creating clearer rules for who can access data, under what conditions, and with which safeguards. ### 2. What the Data Act does in simple terms The Data Act introduces rules for fair access to and use of data. It focuses especially on data generated by connected products and related services, but it also covers other important areas of the data economy. In simple terms, the Data Act: * gives users of connected products access to data generated through their use of those products; * allows users to request that this data is shared with third parties; * defines conditions for mandatory business-to-business data sharing; * protects businesses, especially SMEs, from unfair contractual terms; * allows public sector bodies to request data from businesses in exceptional situations; * makes it easier for customers to switch between cloud and edge service providers; * introduces safeguards against unlawful access to non-personal data by foreign governments; * supports interoperability for data spaces, data processing services, and smart contracts. The regulation therefore combines legal rights, market fairness, technical interoperability, and data governance principles. ### 3. Who is affected by the Data Act? The Data Act affects a broad group of actors across the data economy.
This broad scope means the Data Act is relevant not only for legal teams, but also for product designers, data strategists, IT providers, cloud service providers, data space operators, and ecosystem coordinators. ### 4. What data is covered? The Data Act mainly focuses on data generated by connected products and related services. A connected product is a physical item that obtains, generates, or collects data about its use, performance, or environment and can communicate that data. Examples include connected vehicles, industrial machines, smart home devices, medical devices, energy systems, and agricultural equipment. A related service is a digital service connected to the functioning of the product. For example, an app that controls, monitors, or adapts a connected product may qualify as a related service.
This distinction is important. The Data Act is not designed to transfer every possible insight from a data holder to a user. It focuses on making accessible the data generated by the use of connected products and related services, while preserving incentives to invest in data-driven innovation. ### 5. Main rights and obligations under the Data Act #### 5.1 Users gain access to connected-product data The Data Act gives users the right to access data generated by connected products and related services. This access should be provided in a clear, secure, timely, and usable way. Users may also ask that the data be shared with a third party of their choice. This can help create more competitive markets for repair, maintenance, insurance, optimisation, energy management, logistics, and other data-driven services. For example, a company using connected industrial equipment may be able to request access to performance data and share it with a third-party maintenance provider. This can support predictive maintenance, reduce downtime, and improve operational efficiency. #### 5.2 Data holders must share data under fair conditions Where a data holder is legally required to make data available, the terms must be fair, reasonable, non-discriminatory, and transparent. This is especially important in business-to-business relationships where one party depends on another party’s data to provide a service or compete in a market. The Data Act also allows data holders to request reasonable compensation in some cases. However, safeguards exist to prevent excessive charges, particularly for SMEs and not-for-profit research organisations. #### 5.3 SMEs are protected against unfair contractual terms The Data Act addresses situations where a stronger party imposes unfair “take-it-or-leave-it” contractual terms on another business. This protection applies to contractual terms related to data access and use, liability, remedies, or termination of data-related obligations. The aim is to make data-sharing contracts more balanced and prevent larger actors from using their bargaining power to block fair access to data. #### 5.4 Public bodies can request data in exceptional cases The Data Act allows public sector bodies, the European Commission, the European Central Bank, or Union bodies to request data from businesses where there is an exceptional need. This can include public emergencies such as natural disasters, public health emergencies, or major cybersecurity incidents. In certain non-emergency situations, public bodies may request non-personal data where it is necessary for a specific public-interest task provided by law. These requests must be specific, proportionate, transparent, and limited to what is necessary. #### 5.5 Cloud switching becomes easier The Data Act introduces rules to reduce lock-in in cloud and edge computing services. Customers should be able to switch between data processing service providers more easily, with fewer commercial, technical, contractual, and organisational obstacles. This supports competition, resilience, and multi-cloud strategies. It also helps organisations avoid excessive dependence on a single provider. #### 5.6 Non-personal data receives protection from unlawful foreign government access The Data Act includes safeguards to prevent unlawful access to non-personal data stored in the EU by third-country governments. This does not prohibit international data transfers. Instead, it creates conditions and protections to ensure that access requests from non-EU authorities do not undermine EU law, fundamental rights, national security interests, trade secrets, or commercially sensitive information. #### 5.7 Interoperability becomes a legal priority The Data Act recognises that access rights are only useful if data can actually flow between systems. It therefore introduces requirements and expectations around interoperability for data spaces, data processing services, data-sharing mechanisms, and smart contracts. This is particularly relevant for Common European Data Spaces, where many organisations need to share data across sectors, borders, platforms, and trust domains. ### 6. From legal access to trusted data sharing The Data Act creates rights and obligations. However, rights and obligations alone do not make data sharing operational. For data sharing to work in practice, organisations need answers to practical questions: * Who is requesting access to the data? * What role does that organisation or person have? * Is the request based on a valid agreement? * What data is the requester allowed to access? * For what purpose may the data be used? * How is consent, authorisation, or delegation managed? * How can access be audited, verified, and revoked? * How are trust and compliance maintained across multiple participants? This is the bridge between the Data Act and trust frameworks. The Data Act says that data should be accessible under certain conditions. iSHARE Trust Framework helps ecosystems define and enforce those conditions in a trusted, scalable, and interoperable way. ### 7. Where iSHARE Trust Framework fits The Data Act strengthens the legal foundation for data access and use. iSHARE Trust Framework supports the operational foundation for trusted data sharing. In a data-sharing ecosystem, it is not enough to know that a party has requested access. Participants need a reliable way to verify identities, roles, authorisations, agreements, and policies. This is especially important when data is shared across organisational boundaries, sectors, or countries.
In this sense, the Data Act and iSHARE Trust Framework are complementary. The Data Act clarifies when access to data should be possible. iSHARE Trust Framework helps make that access trustworthy, controlled, and operational. ### 9. Conclusion The Data Act is an important step toward a fairer and more competitive European data economy. It gives users stronger rights to access and share data generated by connected products and related services. It also introduces rules for fair business-to-business data sharing, public-sector access in exceptional cases, cloud switching, third-country access safeguards, and interoperability. For organisations, the Data Act should not be seen only as a compliance obligation. It is also an opportunity to rethink how data is shared, accessed, governed, and trusted. This is where iSHARE Trust Framework can play a meaningful role. By supporting trusted identification, authorisation, agreement-based access, and scalable ecosystem governance, it can help organisations turn the Data Act’s legal framework into practical, secure, and interoperable data sharing. The future of the European data economy will not depend only on whether data can be accessed. It will depend on whether data can be shared with trust.