> For the complete documentation index, see [llms.txt](https://trustbok.ishare.eu/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://trustbok.ishare.eu/apply-ishare/authorisation/the-authorisation-registry.md). # 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.
--- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## 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, and the optional `goal` query parameter: ``` GET https://trustbok.ishare.eu/apply-ishare/authorisation/the-authorisation-registry.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.