How identity and policy actually work
§2 of 4 · ~3 min read
Three standards sit underneath the connector: Verifiable Credentials carry identity, ODRL carries policy, DSP carries the wire conversation between connectors. None of them are Kaphera inventions; all three are open standards governed in the open. The Tier 1 §2 primitives are real because these three exist.
Verifiable Credentials (W3C)
A verifiable credential is a signed claim about an entity. “This organisation is registered in the Catena-X consortium, signed by the Catena-X identity authority, valid until 2027-06-30.” The signature is what makes the claim verifiable: anyone holding the credential’s public-key chain can check the signature without contacting the issuer. The issuing platform does not have to be online for the verification to work.
The W3C published the Verifiable Credentials data model as an open specification in 2019, with a 2.0 revision finalised in 2025. Choosing W3C VCs over a Kaphera-specific identity format is what makes cross-dataspace recognition workable: a credential issued for Catena-X can be presented to a Mobility Data Space connector, and the format does not need translation. They differ from a username and password (which is shared secret authentication) and from a TLS certificate (which proves a server’s hostname, not an organisation’s role). VCs prove “this entity has this role, signed by this authority”, which is the shape org-level identity needs.
ODRL (Open Digital Rights Language)
ODRL is the policy language. A policy in ODRL looks something like: “the OEM may use this dataset for emissions reporting, must retain it no longer than 18 months, must delete it on contract termination, may not redistribute it to a third party”. Each clause is a structured rule, not free-text. The W3C published ODRL 2.2 as a Recommendation in 2018; the dataspace community uses a profile of it.
A language matters more than a permission flag because policies in real supply-chain contracts have shape: temporal constraints (retention windows), purpose constraints (allowed uses), recipient constraints (who can hold the data downstream), audit constraints (what records must be kept). Connectors negotiate ODRL policies during contract formation; the data plane refuses transfers that the control plane has not approved against the agreed clauses. The audit trail records the exact ODRL policy under which each transfer happened, which is what makes a regulator’s after-the-fact reconciliation possible.
DSP (Dataspace Protocol)
DSP is the wire protocol. It is what bytes flow between connectors when they discover each other’s catalogues, negotiate contracts, and execute transfers. Built on HTTP and JSON-LD, governed by the Eclipse Dataspace Working Group, derived from the older IDS protocol that the IDSA published before the work moved to Eclipse. DSP defines three flows: catalogue exchange (what is on offer), contract negotiation (terms and signing), and transfer process (how a data plane is invoked once a contract is signed).
DSP carries the wire-level conversation that the §1 walkthrough described: the catalogue request, the contract proposal, the wallet check, the contract sign-off, the transfer instruction. Without a shared wire protocol, every pair of connectors would need a bespoke integration, which is the §4 “custom B2B APIs” problem from Tier 1. With it, any DSP-compliant connector can talk to any other.
Why these specific standards
Three standards picked off three different shelves: W3C for identity, W3C-published ODRL for policy, Eclipse for the wire protocol that carries them both. None of them is dataspace-specific in origin; each has independent adoption beyond this domain. Choosing them was the right call because regulation requires open, vendor-neutral, and machine-enforceable. W3C VCs and ODRL existed and met those criteria. DSP was built specifically to fit the dataspace pattern but built in the open, with a charter that prevents any single member from controlling its evolution.
The combination is what makes the §1 transfer narrative actually work end-to-end. Each component does one thing, defined by an open spec, and replaceable in principle without breaking the others. That is what gives the architecture longevity.
Previous: ← §1 Inside a connector Next: §3 Kaphera architecture →