ODRL
Under the Hood

The policy representation problem

A data governance policy is a statement about what can and cannot be done with data. Every organisation has them. The problem is not a shortage of policies. It is a shortage of policies that machines can read.

Text-based policies (PDFs, wiki pages, README sections, catalog description fields) share three structural weaknesses. They cannot be composed across systems: a prohibition written in one team's wiki cannot be referenced by another team's pipeline. They cannot be validated: there is no way to check whether a proposed data use is consistent with a text policy without a human reading it. And they cannot be enforced: a notebook that loads a CONFIDENTIAL dataset has no mechanism to consult a document.

The deeper issue is vocabulary. Two organisations that want to enforce compatible policies need to agree on what words mean. "Distribute" means different things to a media licensing lawyer and a data engineer. In a federated architecture (a data mesh, a data space, a multi-cloud lakehouse) policies travel across organisational and system boundaries. If the vocabulary is not shared, enforcement cannot be.

The Open Digital Rights Language (ODRL) is a W3C recommendation (first published 2018, active since 2002) that solves both problems at once. It provides a precisely defined information model for expressing policies and expresses that model in JSON-LD, where every concept is identified by a URI rather than an arbitrary string. The vocabulary is shared by definition.

The information model: six building blocks

The ODRL information model has six core concepts. Everything in an ODRL policy is one of these things or a relationship between them.

The relationships between these concepts are intentionally minimal. A Policy contains Rules. Each Rule references an Action and an Asset. Parties are associated at the Rule level. Constraints qualify Rules. That is the entire model. The simplicity is not a limitation. It is what makes ODRL composable across systems that know nothing about each other beyond the standard.

Actions form a hierarchy

The ODRL action vocabulary is not a flat list. Actions form a subsumption hierarchy: odrl:use is the broadest action and subsumes nearly everything below it. A permission for odrl:use implicitly permits odrl:distribute, odrl:reproduce, odrl:present, and more: unless those are explicitly prohibited in the same policy.

This matters for governance because it determines what a prohibition actually blocks. A prohibition on odrl:distribute does not block odrl:reproduce, even though both are sub-actions of odrl:use. Precision at the action level is the mechanism for expressing nuanced policies: "You may use this data for internal analytics but may not share it externally" without ambiguity.

The four policy types

ODRL defines four Policy subtypes that map to distinct real-world governance workflows. Understanding which type to use and when is the difference between a policy that supports a governance process and one that merely describes it.

The Set type is the right choice for a data catalog: it expresses the terms of use for a dataset without presuming a specific consumer. The Offer type becomes relevant in marketplace contexts, where a data provider publishes the terms they are willing to offer before any specific consumer has agreed. The Agreement type is the output of a successful negotiation. It binds both parties to specific terms and is the type used in data space bilateral contracts. The Request type supports the access request workflow: a consumer expresses what permissions they need before a provider decides whether to grant them.

Constraints: precision without programming

An ODRL rule without constraints is binary: the action is either permitted or it is not. Constraints are the mechanism for expressing everything in between. They are the reason ODRL can encode policies like "employees in the EU may use this dataset for internal analytics before 2027, up to 1,000 queries per day" in a form that a machine can evaluate without human interpretation.

Every constraint is a triple: a left operand (the property being constrained), an operator (the comparison), and a right value (the bound).

The left operand vocabulary

ODRL defines a rich set of left operands covering time, geography, purpose, payload, party attributes, and data characteristics. The most frequently used in data governance contexts:

• odrl:dateTime: absolute time bound (ISO 8601)
• odrl:elapsedTime: relative duration from first use (ISO 8601 duration)
• odrl:purpose: declared use purpose, typically a URI from a purpose taxonomy
• odrl:spatial: geographic region, typically a GeoNames URI
• odrl:count: maximum number of permitted uses
• odrl:payAmount: monetary payment condition (with unit)
• odrl:industry: industry sector of the assignee, often a NAICS or SIC code URI
• odrl:deliveryChannel: the channel through which the asset is delivered
• odrl:event: triggered by an external event (e.g., a regulatory event)

Logical constraints: composing conditions

Individual constraints can be combined using logical operators. A logical constraint wraps multiple atomic constraints into a compound condition.

• odrl:and: all operand constraints must be satisfied
• odrl:or: at least one operand constraint must be satisfied
• odrl:xone: exactly one operand constraint must be satisfied

This makes it possible to express "use is permitted if (purpose is InternalAnalytics AND spatial is EU) OR the assignee is a VerifiedResearchInstitution" as a single machine-evaluable expression, without encoding that logic in application code where it will drift from the policy document.

The JSON-LD wire format: a complete example

The following is a realistic ODRL Agreement between a financial data provider and a buy-side consumer, granting use rights for internal analytics while prohibiting redistribution, with a market data licensing obligation and a time bound. Every concept is identified by a URI.

{
  "@context":  "http://www.w3.org/ns/odrl.jsonld",
  "@type":     "Agreement",
  "uid":      "https://catalog/agreements/a91c3d27-f5e2",
  "profile":  "https://catalog/profiles/financial-data",

  // The parties to this agreement
  "assigner": { "uid": "https://providers.example/acme-data" },
  "assignee": { "uid": "https://consumers.example/buyside-fund" },

  "permission": [{
    "target": "https://catalog/datasets/equities-eod-prices",
    "action":  "use",
    "constraint": [
      {
        "leftOperand":  "purpose",
        "operator":     "isA",
        "rightOperand": "ex:InternalRiskAnalytics"
      },
      {
        "leftOperand":  "dateTime",
        "operator":     "lt",
        "rightOperand": {
          "@value": "2027-06-30T23:59:59Z",
          "@type":  "xsd:dateTime"
        }
      }
    ],
    // Duties: obligations that must be fulfilled when exercising this permission
    "duty": [
      {
        "action": "compensate",
        "constraint": [{
          "leftOperand":  "payAmount",
          "operator":     "eq",
          "rightOperand": "1500.00",
          "unit":          "http://dbpedia.org/resource/Euro"
        }]
      },
      {
        "action": "inform",
        "assignee": "https://providers.example/acme-data"
      }
    ]
  }],

  "prohibition": [
    { "target": "https://catalog/datasets/equities-eod-prices", "action": "distribute" },
    { "target": "https://catalog/datasets/equities-eod-prices", "action": "reproduce" },
    { "target": "https://catalog/datasets/equities-eod-prices", "action": "derive" }
  ]
}

Several things are worth observing about this document. The assigner and assignee are both identified by URI; no names, no email addresses, no strings that can drift. The constraint on the permission uses purpose isA ex:InternalRiskAnalytics, where ex:InternalRiskAnalytics is itself a URI that can be resolved to a definition. The duty structure demonstrates how obligations attach to permissions rather than floating free: the compensate and inform duties are only triggered when the permission is exercised.

And critically: the entire document is a valid JSON object. A consuming system does not need an ODRL library to extract the prohibitions; it can traverse the JSON. An ODRL-aware system can do full policy evaluation. This spectrum of interoperability is intentional.

Profiles: extending the core vocabulary

ODRL's core vocabulary covers a wide range of generic data governance scenarios, but domain-specific requirements (financial regulation, healthcare, data space connector policies) need additional vocabulary terms. ODRL supports this through profiles.

A profile is a document that defines extensions to the ODRL vocabulary, typically new actions or new left operands, scoped to a specific domain or system. Profiles can also restrict the policy types or constraint operators that are valid within that domain. A policy document declares its profile using the odrl:profile property.

How ODRL improves governance: six concrete mechanisms

The governance improvements from ODRL are not rhetorical. They are direct consequences of the model's properties. Here are the six that matter most in practice.

The interoperability point deserves elaboration. Governance frameworks that rely on proprietary metadata schemas. A catalog's internal classification field, a pipeline's custom tags, collapse when data crosses system boundaries. The receiving system does not know what the tags mean. ODRL does not have this problem: the vocabulary is public, the semantics are defined, and any ODRL-aware system can evaluate a policy produced by any other ODRL-aware system.

The evaluation algorithm

The ODRL Information Model specification defines a normative evaluation algorithm. Given a policy and a proposed action-party-asset triple, the evaluator:

1. Collects all Rules from the Policy whose target matches the Asset and (if applicable) whose assignee includes the Party.
2. Evaluates each Rule's Constraints. A Rule is active only if all its Constraints are satisfied.
3. If any active Prohibition applies to the Action: the action is prohibited.
4. If an active Permission applies to the Action and all its Duties are satisfiable: the action is permitted.
5. Otherwise: the action is not permitted (the ODRL closed-world assumption; absence of permission is prohibition).

This algorithm is deterministic and requires no judgement. A conforming implementation in any language produces the same answer given the same inputs. That is what makes enforcement possible at machine scale.

How ODIN implements ODRL

ODIN's ODRL implementation takes the standard's flexibility and constrains it to a specific, practical governance model: policies are derived automatically from element classifications and vocabulary concept mappings, so that data owners do not need to author ODRL by hand.

The derivation follows a deterministic pipeline:

The result is exposed at GET /api/v1/datasets/{id}/terms-of-use, which returns the ODRL JSON alongside a plain-English summary and a derivationDetails object documenting exactly which elements and vocabulary signals produced the policy. The dcat:hasPolicy property on the dataset entity points to the same policy document, making it discoverable through standard DCAT tooling.

From advisory to enforceable

Understanding the ODRL model makes the path from policy storage to policy enforcement concrete. ODRL was designed for enforcement. The evaluation algorithm exists precisely because the specification authors intended policies to be evaluated by machines, not read by humans.

The enforcement integration points follow naturally from the model:

• API gateway enforcement: A gateway can call GET /datasets/{id}/terms-of-use before proxying a data request, evaluate the ODRL policy against the requesting party and intended action, and reject requests that violate prohibitions or fail constraint checks.
• OPA policy integration: The ODRL JSON can drive an Open Policy Agent policy that evaluates the same rules as Rego. The ODRL document is the source of truth; OPA is the enforcement runtime.
• Keycloak scope constraints: The access level from the derived ODRL policy maps directly to OAuth scopes. A CONFIDENTIAL dataset requires a scope that can only be granted to identities in the data owner's approved list, derived from the ODRL assignee Party constraint.
• AI agent tool guards: An AI agent that calls data catalog APIs can receive the ODRL policy alongside the dataset metadata and evaluate permitted actions before constructing a query. The policy is not advisory to the agent. It is a structured input to its tool-use logic.
• Data space connectors: In an IDS/Eclipse EDC architecture, the ODRL policy (as an Offer or Agreement) is the contract that governs connector-to-connector data transfer. Enforcement is built into the connector protocol, not bolted on separately.

None of these integration points require modifying the ODRL policy document. The same JSON-LD that a data owner accepts in the catalog UI is the input to every enforcement mechanism. That is the value of the standard: write the policy once, enforce it everywhere.

What the standard actually gives you

ODRL is not magic. A badly specified policy (wrong action vocabulary, missing constraints, no parties identified) does not improve governance just because it is expressed in JSON-LD. The standard provides the grammar; the governance work is still required to produce a policy that accurately reflects intent.

What the standard does give you is a foundation that does not rot. A custom classification scheme, a proprietary metadata field, an internal tag vocabulary; these all become technical debt the moment they cross a system boundary. An ODRL policy document can be handed to any ODRL-aware system: A partner organisation's catalog, a data space connector, an AI agent, a compliance auditor's tooling. Then, it is evaluated without translation.

Governance at scale is a vocabulary problem before it is a technology problem. The same policy intent expressed in a hundred different proprietary systems produces a hundred different enforcement behaviours. Expressed in ODRL, it produces one. The standard is the coordination mechanism that makes federated governance possible; dataset by dataset, classification by classification, as the policies accumulate into something that actually works.