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. That is, meaning that a single Authorisation Registry can serve multiple services, capabilities, and Data Spaces. Further, it also defines how a Service Provider should discover which Authorisation Registry to contact before requesting delegation evidence. This is a surgical change to where evidence is obtained and not to how delegation evidence is evaluated once you have it (see Delegation Chains).

Why this matters

In real data spaces, 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 are 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 backward-compatible. If an Entitled Party does nothing new, Service Providers will still find an Authorisation Registry through existing Participant Registry entries (e.g., data-space or default).

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.