> 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/storing-policy-sets.md). # 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

--- # 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/storing-policy-sets.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.