Policy-Based Data Access Control (PBAC)

• PBAC is a model that defines data access using machine-readable policies, integrating contextual and relationship data for fine-grained authorization.
• It leverages standards like ODRL/ODS to model subjects, actions, targets, and constraints using JSON-LD or RDF for clear policy specification.
• Its architecture features a multi-phase workflow that compiles high-level policies into graph models for scalable, sub-millisecond access control decisions.

Policy-Based Data Access Control (PBAC) is a foundational paradigm for enforcing flexible, context-aware, and fine-grained authorization over digital resources. PBAC frameworks specify access requirements as machine-readable policies that are evaluated at request time, factoring in attributes, relationships, provenance, purposes, and contextual constraints. This article synthesizes technical developments in PBAC, with a particular focus on relationship-based paradigms, expressive LLMs, policy execution architectures, and validation in federated and multi-tenant environments, as exemplified in recent works (Plaza-Ortiz et al., 30 May 2025).

1. Policy Modeling and the ODRL Data Spaces (ODS) Profile

PBAC systems model access requirements as policies that combine subjects (users, roles), actions, resources, and constraints. The Open Digital Rights Language (ODRL) provides an extensible policy language that has been adopted and profiled for data spaces in the ODRL Data Spaces (ODS) specification (Plaza-Ortiz et al., 30 May 2025). The ODS profile extends the ODRL Core Model with domain-specific vocabulary and elements (Table 1, Sec. 2):

• Subjects specialize odrl:assignee: ODS:Consumer (data user), ODS:Provider (publisher), ODS:Broker (intermediary), ODS:Monitor (compliance).
• Actions extend odrl:action: ODS:Subscribe, ODS:Request_data, ODS:Retention, ODS:Train, ODS:Kill_job.
• Resources identify odrl:Asset instances: datasets, streams, services.
• Constraints (odrl:constraint) express cardinality, temporal, or custom path-based conditions.
• Duties (odrl:duty) encode obligations tokenized to permissions (e.g., logging, notification).

Policy instances are expressed using JSON-LD or RDF, mapping ODS elements to concrete access statements. For example:

{ "@type": "odrl:Permission", "odrl:assignee": { "@id": "ods:Consumer" }, "odrl:action": { "@id": "ods:Subscribe" }, "odrl:target": { "@id": "ex:DataStream" }, "odrl:constraint": [ { "odrl:leftOperand": "odrl:dateTimeInterval", "odrl:operator": "odrl:lte", "odrl:rightOperand": "2025-12-31T23:59:59Z" } ] }

This schema supports operationalization of policy-based access aligned with data space semantics and governance requirements.

2. Relationship-Based Formalism and Access Control Graphs

To model data space scenarios where access depends not only on static attributes but also on contextual relationships (e.g., approvals, memberships, delegations), PBAC frameworks integrate Relationship-Based Access Control (ReBAC) semantics (Plaza-Ortiz et al., 30 May 2025). Here, the system state is a labeled directed graph $G = (E, R)$ where:

• $E$: entities (identities, assets, services).
• $R \subseteq E \times L \times E$: labeled binary relations, with $L$ being relationship types (e.g., "providedBy", "subscribedTo", "memberOf").

A policy references subgraphs or paths in $G$, for example:

$$\exists\,e_1,\dots,e_n\in E:\;(u\xrightarrow{l_1}e_1\xrightarrow{l_2}\cdots\xrightarrow{l_n}a)$$

meaning there exists a relationship path from user $u$ to asset $a$ following $(l_1, ..., l_n)$. The operational semantics reduces policy evaluation to reachability queries on $G$, supporting expressive context-dependent access control.

3. Execution Engine Architecture and Policy Enforcement Workflow

Section 3 and Figure 1 in (Plaza-Ortiz et al., 30 May 2025) specify a multi-phase policy execution workflow that bridges high-level ODRL policies to a backend-optimized enforcement substrate (OpenFGA):

1. Policy Creation: Stakeholders author ODRL/ODS policies (JSON-LD or RDF).
2. Policy Parsing and Analysis: Front-end parser produces an Abstract Syntax Tree (AST), validates ODS vocabulary, and extracts relevant policy artifacts (subjects, actions, targets, constraints, duties).
3. Transformation to Executable Model:
   • AST is compiled to an OpenFGA model in JSON, specifying types (entities), relations (actions, assets, etc.), and tuple-to-relation rules.
   • Permission tuples are generated from ODRL grant entries and attached constraints.
4. Deployment to OpenFGA: The engine stores the model and permission tuples in OpenFGA via its management API.
5. Authorization Evaluation: On access requests $(u, a, \alpha)$, the system invokes OpenFGA’s Check API. OpenFGA performs graph-traversal queries to resolve reachability, returning ALLOW or DENY.
6. Enforcement: The outcome is enforced by the gateway or service mediating the request.

This architecture decouples high-level policy expression from efficient, scalable enforcement, integrating state-of-the-art authorization graph engines.

4. Validation and Application in Federated Data Spaces

A demonstrative use case encodes a canonical scenario: a Consumer is permitted to Subscribe to dataset "DS1" (owned by Provider "P1") only if Broker "B1" has approved the subscription (Plaza-Ortiz et al., 30 May 2025). The ODS policy includes a constraint on ods:hasApproval, which is translated by the execution pipeline into OpenFGA relations:

• Entity types: user, dataset, broker.
• Relations: "hasApproval" $\langle$user, broker$\rangle$, "canSubscribe" $\langle$user, dataset$\rangle$.

With the tuple ("C1", "hasApproval", "B1") present, an OpenFGA rule encodes the logic that "C1" can subscribe to "DS1" iff approval by "B1" is attested. Empirical evaluation shows enforcement correctness across all tested scenarios, and the system achieves sub-millisecond decision latency in development-scale deployments (Sec. 3.3).

5. Lessons Learned, Limitations, and Future Directions

Key outcomes of the ODS-based PBAC approach include:

• The ODS profile situates ODRL semantics directly in data space environments, introducing richer subject and action modeling tailored for federated, role-differentiated ecosystems.
• Relationship-centric translation to OpenFGA provides a performant, scalable evaluation substrate, and integration with federated identity is direct, as identity nodes map to graph vertices.
• Current support centers on access permissions; express usage control (e.g., transformations, chained or temporal obligations) will require additional semantic and engine extensions.
• Obligations and duties in policy are represented but lack formal evaluation semantics in the current execution architecture.
• Large-scale, multi-tenant performance analysis remains an open area.

Future research imperatives include the formalization of ODS duty and usage-control constructs, integration of privacy-leakage analysis for policy metadata, support for broader enforcement backends (e.g., Cedar, XACML ReBAC), and the design of cross-standard PBAC frameworks for interoperability (Plaza-Ortiz et al., 30 May 2025).

6. Comparative Landscape and Integration Potential

PBAC, as exemplified by the ODS model, addresses limitations inherent in static access control frameworks (DAC, RBAC, ABAC) by enabling context- and relationship-aware policy specification and automated execution (Plaza-Ortiz et al., 30 May 2025). The combination of expressive policy languages, formal ReBAC underpinnings, and scalable policy execution engines supports fine-grained, dynamic enforcement necessary for distributed, federated data spaces. The extensibility of the ODRL/ODS framework positions it for integration with evolving identity, privacy, and usage-control standards. Further, the translation-and-compilation approach demonstrated with OpenFGA facilitates adaptation to additional backend enforcement technologies as new requirements and architectural paradigms emerge.