Linked Data Signature

A Linked Data Signature is a cryptographic signature attached directly to a JSON-LD document as a proof property, the predecessor to what's now formally called a Data Integrity Proof (see that entry). "Linked Data" here refers to JSON-LD's RDF-graph model: rather than signing raw JSON bytes (where reformatting whitespace would break the signature), a Linked Data Signature is computed over a canonicalized form of the underlying graph, so the signature survives re-serialization as long as the meaning of the data hasn't changed.

A Linked Data Signature block looks close to what a Data Integrity Proof looks like today, because Data Integrity is its direct successor:

"proof": {
  "type": "Ed25519Signature2020",
  "created": "2026-05-01T10:30:00Z",
  "verificationMethod": "did:example:issuer#key-1",
  "proofPurpose": "assertionMethod",
  "proofValue": "z3FXQ..."
}

The difference from the modern spec is mostly naming: earlier suite names like Ed25519Signature2020 and BbsBlsSignature2020 named a signature scheme directly in the type field, one suite = one type name. The current Data Integrity spec replaced this with a single generic DataIntegrityProof type plus a separate cryptosuite field (eddsa-rdfc-2022, bbs-2023, see Cryptographic Suite): a cleaner separation between "this is a Data Integrity proof" and "which specific algorithm bundle secures it." The two shapes describe the same underlying idea; Data Integrity formalized and superseded the earlier Linked Data Proofs lineage rather than replacing it with something unrelated.

Where it comes from

Linked Data Signatures began as a Digital Bazaar community specification from roughly 2015 onward, with Dave Longley, Manu Sporny, and David I. Lehn among its authors, largely the same people who went on to edit the W3C Data Integrity spec that formalized this work (see that entry). Solidus authored none of it.

Solidus status

Documented in Solidus's own type definitions, in the older form; absent from the live wire format. Solidus's published CredentialProof type (@solidus-network/types) literally names Ed25519Signature2020, meaning Solidus's own documented credential-proof shape is, technically, a genuine Linked Data Signature from the pre-Data-Integrity lineage, not the newer cryptosuite-named successor described in the Data Integrity Proof and Cryptographic Suite entries. But per those same entries' live checks, dated 2026-07-17: the actual running testnet issuer never produces this proof block. Its live wire format is JOSE/SD-JWT instead. This shape is real in Solidus's published type definitions and nowhere in what a verifier actually receives today.

Proof you can run yourself: npm view @solidus-network/types, read CredentialProof.type directly, the literal 'Ed25519Signature2020' is right there. Then curl -s https://capture-api.solidus.network/.well-known/openid-credential-issuer and see a completely different, JOSE-based format live.