When I use a resource I don’t host myself, a storage service, a compute service, a dataset, I have to trust it on points I cannot see: where it runs, under which jurisdiction, with what guarantees, and who is responsible for it. That information usually lives on a marketing page or in a contract clause, and I have no simple way to check it. I take it on faith.
Dataspaces, those settings where several actors share resources, answer differently. Every resource is described there in a format the machine can read, that description is signed, and anyone can verify it without asking anyone. This article explains how that description works, how it is verified, and how far the trust it provides actually goes.
Describing the resource in a machine-readable format
The starting point is that the resource describes itself. It does so in a structured document that other programs can read and compare, and not in a sheet meant for a human reader. In the vocabulary of dataspaces, that document is called a self-description.
Technically, it is a W3C Verifiable Credential, in the JSON-LD format. A Verifiable Credential is a set of statements (claims) about an entity, issued by someone and signed. Here, simplified, is the description of a storage service.
{
"@context": ["https://www.w3.org/ns/credentials/v2",
"https://w3id.org/gaia-x/development#"],
"type": ["VerifiableCredential"],
"issuer": "did:web:storage.example",
"credentialSubject": {
"id": "https://storage.example/offers/objects-eu",
"type": "gx:ServiceOffering",
"gx:providedBy": "did:web:storage.example",
"gx:location": "FR",
"gx:dataProtectionRegime": ["GDPR2016"],
"gx:certification": "ISO/IEC 27001",
"gx:endpoint": "https://storage.example/connector"
},
"proof": {
"type": "JsonWebSignature2020",
"verificationMethod": "did:web:storage.example#x509",
"jws": "eyJhbGciOiJ..."
}
}
It reads without effort. The provider (storage.example) offers a storage service
located in France, subject to the GDPR, certified ISO 27001, reachable at a given
address. The proof block, at the end, contains the signature. The same structure
serves for a dataset or for the provider itself: resource and participant alike,
everything is described in this single format.
The benefit is concrete. Where each provider usually presents its guarantees in its own way, here everyone uses the same structured vocabulary. A jurisdiction compares to a jurisdiction, a certification to a certification, by a program, without human reading.
A signed, verifiable description
A description can be written any way at all. What makes it reliable is the signature.
The Verifiable Credential format became a W3C standard in May 2025. Its central property is that a credential is tamper-evident, in the sense that any alteration shows, and that its author can be verified cryptographically. The model defines three roles: the issuer writes and signs the description, the holder presents it, the verifier checks it.
The three roles of the model. The issuer signs the description, the holder presents it, the verifier checks it offline with the public key, without contacting the issuer.
The verifier depends on no one else. The verifier doesn’t need to call the issuer back, nor connect to a central server, nor get any authorization. The signature is checked offline, with the public key. That is the concrete meaning of the word “auditable”: a check I can run myself, whenever I want, and not a promise of transparency.
Going back to a root of trust
There is still a weak point. A signature proves that the description has not been modified and that it comes from a particular key. It does not say whether I should trust the owner of that key. Anyone can sign a description stating “I am located in France and certified”.
That is the role of the root of trust. The signing key must connect, through a chain of certificates, to an entity recognized by the dataspace, what is called a trust anchor. A compliance service performs this check: it controls the form of the description, verifies each signature, and confirms that the key goes back to a recognized root. Without that link, the description is rejected.
A verification result looks like this.
{
"signatureValid": true,
"chainsToTrustAnchor": true,
"trustAnchor": "did:web:registry.example",
"issuerVerified": true
}
At this point, I no longer trust on faith. The description is intact, it comes from an actor whose identity has been established, and its statements commit someone identifiable. If the service claims to be in France without being so, it is no longer a harmless marketing line: it is a signed, false, and traceable statement.
The data stays at its source
One important point: describing a resource does not amount to moving it. What travels in the dataspace is the description, not the data. The data stays with its holder and moves, peer to peer, only once an agreement has been negotiated. The dataspace is not a central warehouse where everything would be copied, but a layer of verifiable descriptions above resources that stay where they are.
The data stays with the provider. Only the signed description is published to the catalogue; the data itself moves only peer to peer, after an agreement.
Without buying the rhetoric that comes with it
A legitimate objection: all this comes from heavily branded projects, with a strong discourse on sovereignty. One may not want to subscribe to it.
Good news, the building blocks are standards, not the political project. The Verifiable Credential is a W3C recommendation. Decentralized identifiers (DID) too. The description vocabularies, the policy languages, the catalogues, are open specifications. Several implementations exist, including reusable Eclipse components outside any label. One can take the mechanics, describe and verify resources, without adopting anything of the rest. The part that interests me is not an ideology, it is a format and a signature.
When the description is not enough: attestation
Everything above provides one thing: the verifiable certainty of what a resource claims to be. That is already a lot, but it stays declarative. The service claims to be in France and certified, and I can verify it; nothing yet guarantees that my data, once sent to it, will be handled as expected.
To close that gap, some dataspaces go further and ask the infrastructure to prove its integrity before receiving anything at all. This is the principle of remote attestation. Before releasing any data, the connector on the other side proves, physically, that it runs an approved and unmodified software stack. The proof relies on dedicated hardware, a TPM chip and a measured boot, which record the state of the system and present it in a tamper-proof way. As long as that proof is not provided and validated, the data does not leave.
The integrity proof looks like this.
{
"attestation": {
"platform": "did:web:client.example",
"measuredBoot": "sha256:7f3a...e21",
"stack": "trusted-connector 1.4 (approved)",
"tpm": "TPM 2.0",
"verdict": "trusted"
},
"transferAllowed": true
}
The Trusted Connector of the Industrial Data Spaces works this way: integrity measurement, remote attestation, and negotiation of the trust level and the usage policy before the transfer. A stricter variant, confidential computing, protects the data during its processing, so that even the operator of the machine cannot read it.
The difference is clear. With the signed description alone, the infrastructure is a responsible participant: what it states is verifiable, and it is accountable if it lies. With attestation, it becomes a participant that enforces: it receives the data only after proving that it will handle it as agreed.
Two levels of trust. At the declarative level, you verify what the resource claims. With attestation, the infrastructure proves its integrity before receiving the data.
Limits
The strong level has a cost. The attestation hardware, the certified connectors and confidential computing are not the default setting, but the exception reserved for sensitive cases. Most exchanges stop at the declarative level and rely, for the rest, on the contract and on traceability. The verifiable description brings accountability, not the technical impossibility of doing wrong.
Conclusion
Even at the declarative level alone, something changes. I choose a resource on facts I can check myself, and not on its marketing sheet: its jurisdiction, its certifications and its responsible party are written in a single format, signed, and tied to an established identity.
This is a building block I am watching closely for my sport coach. It handles health data and already chooses between local processing and the cloud. The day it has to talk to outside resources, being able to verify them rather than trust them will not be a luxury. That will be the subject of another article.