Skip to content

Identity and trust

Decentralised identity with DID Web

Participants in the dataLOFT data space are identified by did:web URIs. A did:web DID is resolved by fetching a JSON-LD document from a well-known URL path on the participant's domain. The DID document declares the participant's public keys and service endpoints.

Each participant's DID document is served at:

https://<participant-domain>/.well-known/did.json

A DID document contains a verificationMethod that declares the participant's public key in JWK format and links it to an X.509 certificate via the x5u field. The certificate serves as the trust anchor. In the dataLOFT reference deployment, this is the participant's Let's Encrypt certificate.

Example DID document:

{
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://w3id.org/security/suites/jws-2020/v1"
  ],
  "id": "did:web:portal.dataspace.fun",
  "verificationMethod": [
    {
      "@context": "https://w3c-ccg.github.io/lds-jws2020/contexts/v1/",
      "id": "did:web:portal.dataspace.fun#X509-JWK2020",
      "type": "JsonWebKey2020",
      "controller": "did:web:portal.dataspace.fun",
      "publicKeyJwk": {
        "kty": "RSA",
        "n": "1us8TTUM-...",
        "e": "AQAB",
        "alg": "RS256",
        "x5u": "https://portal.dataspace.fun/.well-known/x509Certificate.pem"
      }
    }
  ],
  "assertionMethod": [
    "did:web:portal.dataspace.fun#X509-JWK2020"
  ]
}

In the dataLOFT reference deployment, HST-DID generates and hosts this document for each participant. It derives the DID document from the participant's Let's Encrypt certificate, which means the public key in the DID document corresponds to the certificate's key pair. The private key of that pair is what a participant uses to sign verifiable credentials.

Authentication with DPoP

Dataspace requests are authenticated using DPoP tokens (RFC 7800). A DPoP token is a short-lived JWT that proves possession of a private key. In the dataLOFT implementation, the token's iss (issuer) field contains the participant's did:web URI rather than a URL.

When RUN-DSP receives an incoming DSP request, it forwards the DPoP token to the Signature-Auth-Handler for validation. The handler:

  1. Verifies the token's expiry and structure.
  2. Resolves the issuer's DID document by fetching it from the participant's domain.
  3. Verifies the token's signature against the public key declared in the DID document.
  4. Queries FC-Service to confirm that the participant is registered in the catalogue.

If all checks pass, the request is authenticated. If any check fails, the request is rejected before RUN-DSP processes it further.

Relationship to Gaia-X Trust Framework

The use of did:web and verifiable credentials is aligned with the Gaia-X Trust Framework. Gaia-X requires participants to express their identity as self-descriptions backed by verifiable credentials signed by a Gaia-X-endorsed trust anchor. The dataLOFT identity model is designed to be compatible with this requirement.

No central identity server

The identity model does not require a central IdP. Trust is established through cryptographic proof (DPoP signature) and catalogue membership (FC-Service registration). Any participant can verify another participant's identity without contacting a central authority.