Storing Policy Sets

Policy Storage in Authorization Registries

Authorization Registries (ARs) are a cornerstone of the iSHARE Trust Framework. They store delegation policies and issue delegation evidence that confirms which organisations are authorised to act on behalf of others. While the iSHARE specifications describe the structure of policy sets and how delegation evidence is exchanged, they deliberately do not prescribe how policies must be stored internally.

This article clarifies how policy sets can be stored within an AR. It draws on lessons from existing implementations and ecosystem practices, while reaffirming that the iSHARE framework provides flexibility. The outcome of issue DVP-90 — that rules must not contain targets when used in delegation evidence — is also reflected here, ensuring that storage approaches remain consistent with specification requirements.

Storing Policy Sets in Practice

Document-Oriented Databases

Some ARs favour document-oriented databases such as MongoDB or CouchDB because policy sets in iSHARE are already expressed as JSON. Storing them natively avoids translation overhead and makes evaluation straightforward: queries can directly target JSON fields such as issuer, subject, or target.

In practice, this approach aligns with how other data spaces manage JSON evidence. For example, the i4Trust GlobShare platform used MongoDB to store context data for supply chain visibility. Although GlobShare was not an Authorisation Registry, the lesson transfers easily: schema flexibility and JSON-native querying reduced integration costs and accelerated iteration. For ARs, the same method can streamline evidence issuance by avoiding translation between formats.

The trade-off is in auditing and complex queries. Document stores handle real-time lookups well but may require custom indexing or secondary systems for bulk reporting.

Relational Databases

Many AR operators already rely on relational infrastructures such as PostgreSQL or SQL Server. In these cases, policy sets may be stored in JSONB columns or decomposed into fully relational tables.

The iSHARE Authorization Registry reference implementation takes this path: policies are seeded into relational tables, and indexes are applied on issuer, subject, and resource identifiers. This model supports powerful auditing; for instance, in Dutch logistics pilots, AR operators needed to check whether a Shipper had accidentally issued overlapping delegations in the past six months. With SQL, such queries were trivial to execute.

The trade-off here is rigidity. Every change in the iSHARE policy schema may require migrations or redesigns, slowing down adoption of new specification updates. Still, for regulated sectors where auditability and transactional guarantees outweigh flexibility, SQL remains attractive.

Policy Engines

A third model integrates ARs with dedicated policy engines such as Open Policy Agent (OPA) or AuthzForce. Here, the AR translates iSHARE JSON policy sets into the engine’s native format (e.g. OPA’s Rego rules) and delegates evaluation.

This approach is particularly compelling in complex governance environments. For example, in the energy sector, pilots aligned with Gaia-X have explored centralising access control in OPA. Integrating ARs with such engines would allow compliance teams to manage rules in one place, while still enabling iSHARE-compliant delegation evidence issuance. The downside is additional complexity: ARs must maintain translation logic, and tracing why a policy evaluation failed may require navigating two systems.

Hybrid and Ledger-Based Approaches

Some AR implementers experiment with hybrid approaches to balance operational speed and compliance assurance. A common pattern is to store JSON policies in a document store for fast retrieval while simultaneously logging every change into an append-only ledger.

In one mobility pilot inspired by iSHARE, policy updates were mirrored to a blockchain ledger. This gave operators the speed of a document store combined with immutability guarantees demanded by regulators. Such an approach also helps in scenarios where disputes may arise over who authorised access, as cryptographic logs provide indisputable proof. Nonetheless, the trade-off is operational overhead: maintaining two storage backends requires careful governance and resourcing.

Design Considerations for AR Implementers

Regardless of the chosen storage model, certain principles are essential. Policy sets must be retrievable quickly, since delegation evidence requests depend on real-time evaluation. They must be stored with integrity, protected against unauthorised modification, and retained in a way that supports auditing. Indexing key attributes such as issuer and subject improves performance, while staging environments for policy updates help avoid errors. Crucially, policies must be validated before storage to ensure they follow iSHARE’s rules; for example, that no targets appear inside rules when used in delegation evidence (as clarified in DVP-90).

A Flexible but Consistent Approach

By not prescribing a single storage method, the iSHARE Trust Framework allows Authorization Registries to adopt solutions that best suit their operational context. Whether through document stores for agility, relational databases for auditability, policy engines for expressiveness, or hybrids for compliance resilience, the goal remains the same: to ensure policies can be stored, retrieved, and validated in a way that supports secure and reliable issuance of delegation evidence.

This flexibility is a strength, but it comes with responsibility: AR implementers must balance technical efficiency with governance needs. By learning from related data spaces, from GlobShare’s MongoDB deployment to SQL-based iSHARE pilots, the ecosystem can evolve storage practices that are both practical and compliant, reinforcing trust across the iSHARE framework.