Linked Data Signatures: the Proof Format Behind Your Credential
It is not the proof format behind your credential, and the first honest thing this page can do is say so. The heading above comes from our content plan; the format it names appears in our published type definitions and nowhere in the credentials we actually issue. The term is spec.
What a Linked Data Signature is
A family of proof formats for JSON-LD documents, from the lineage that preceded the current W3C Data Integrity work. The distinguishing idea is canonicalisation: before signing, the document is transformed into a deterministic form, so that two JSON documents which mean the same thing, different key order, different context expansion, produce the same bytes and therefore the same signature.
That is genuinely powerful. It means a signature survives reserialisation, and a verifier does not have to receive the exact byte sequence the issuer signed.
It is also where the complexity lives. Canonicalising a graph is far more work than hashing a string, and the security of the result depends on the canonicalisation being right.
Suite names from this lineage look like Ed25519Signature2020.
What our published type contains
export interface CredentialProof {
type: 'Ed25519Signature2020'
created: string
verificationMethod: string
proofPurpose: 'assertionMethod'
proofValue: string
}
That is, precisely, a Linked Data Signature proof block, the suite name, the creation time, the key to verify against, the purpose, and the signature value.
So our documented credential-proof shape belongs to this lineage, not to the newer cryptosuite-named successor. See the cryptosuite field for why that distinction matters and proofPurpose for the field beneath it.
And what the running issuer emits: none of it
The live wire format is JOSE/SD-JWT. The issuer advertises vc+sd-jwt and signs with a JOSE
algorithm identifier. There is no canonicalisation step, no proof object, no proofValue, and no
JSON-LD processing in the path that issues credentials today.
This shape exists in our published type definitions and nowhere in the live wire format. We are stating that plainly rather than letting a type definition imply otherwise: a published interface is documentation, and someone will reasonably read it as a description of what they will receive.
Why the gap exists, without dressing it up
Two credential families are accepted by the European wallet architecture: SD-JWT VC and ISO mDoc. We implement the first. Neither of them is JSON-LD Data Integrity.
The type predates the shipped path. It was not updated when the wire format was chosen, and that is the whole explanation, not a migration in progress, not a dual-format strategy. A stale type is a documentation defect, and this page is where we say so rather than where we explain it away.
What a researcher should record
- Solidus does not implement Linked Data Signatures. No canonicalisation, no Data Integrity proof emission.
- Our published type describes one anyway, in the pre-2022 naming lineage.
- Score us on the wire format, not the type. The credential you receive is an SD-JWT.
- Selective disclosure here is salted-hash based, not JSON-LD-derived, see why each disclosed field carries its own salt.
The one thing worth saying for the format itself
Canonicalisation solves a real problem we simply do not have. Our credentials travel as compact tokens whose exact bytes are what gets verified, so reserialisation-survival is not a requirement in our path.
That is a reason the choice is defensible. It is not a reason the type definition should say something different from the wire, and we are not going to use it as one.