SD-JWT Vs Data Integrity Proof Verifiable Credentials

W3C’s VC-JOSE-COSE specification standardizes three ways to secure a Verifiable Credential — JOSE/JWS, SD-JWT, and COSE — and AuthiChain’s protocol spec uses none of them: it signs with a Data Integrity proof (Ed25519Signature2020) over JCS-canonicalized JSON instead.

Why AuthiChain

• SD-JWT adds selective disclosure — a holder reveals some claims and withholds others from the same signed credential — a feature a provenance record for a physical item does not need, because an item’s identity and history are not secrets to partially hide
• A Data Integrity proof signs the record’s JSON structure directly; JOSE and COSE wrap the credential inside a JWT or CBOR envelope first — both are valid, W3C-conformant ways to secure the same VC Data Model 2.0 payload
• protocol/SPEC.md §3.2 requires RFC 8785 (JCS) canonicalization specifically so two independent verifiers derive byte-identical input from the same record — a property any of the three securing mechanisms could satisfy, but only Data Integrity is what is actually implemented today

How it works

Issue a unique identifier per unit, anchor its record on-chain for tamper-evidence, and let anyone verify it with a single scan. Plans start at $49/mo.

FAQ

Is a Data Integrity proof less standard than SD-JWT?

No — both are W3C-defined ways to secure the same VC Data Model 2.0 credential. VC-JOSE-COSE and Data Integrity are parallel securing mechanisms, not a newer one replacing an older one.

Does AuthiChain support SD-JWT credentials?

Not today — the reference verifier implements Ed25519 Data Integrity proofs only. Selective disclosure matters more for identity credentials than for a provenance record meant to be checked in full.