> 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/authorisation-registry-per-service-capability.md).

# 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.md)).

### 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.

\ <br>


---

# 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/authorisation-registry-per-service-capability.md?ask=<question>&goal=<endgoal>
```

`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.