# 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.md) 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. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://trustbok.ishare.eu/apply-ishare/authorisation.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.