An Empirical Evaluation of Signing and Verification Performance of Verifiable Credential Formats: A Cross-Language Benchmark of SD-JWT VC, W3C VCDM, and mdoc

Abstract

We compare the signing and verification performance of three Verifiable Credential (VC) formats--SD-JWT VC; the W3C Verifiable Credentials Data Model 2.0 with a Data Integrity cryptosuite (W3C VCDM); and mdoc (ISO/IEC 18013-5)--over one scope: issue, present with selective disclosure, verify. Node.js, Go and Python implementations ran in four environments, one a cloud VM (N=2,000 across five runs; medians of each statistic and the spread). For an end-to-end exchange disclosing 5 of 20 attributes, the total (issue, present, verify) on Node.js in the cloud VM is 0.265 ms for mdoc, 0.298 ms for SD-JWT VC and 0.534 ms for W3C VCDM. The four span a factor of five in speed; across them W3C VCDM takes 1.73--2.04x mdoc and 1.57--1.79x SD-JWT VC--at least five times our 10% band--and the ordering survives unifying the algorithm on Ed25519 and P-256. The mdoc--SD-JWT VC difference is not robust: the totals differ by 12%, 28%, 19% and 10% in the four environments, and at verification mdoc is the slower in one of them. RDFC-1.0 canonicalization produces the gap: the cryptosuite canonicalizes twice per operation, so one exchange canonicalizes six times. We attribute that cost to the specification rather than to a library mainly by replacing RDFC-1.0 with JCS, which brings W3C VCDM verification to within 5% of SD-JWT VC in three environments and within 12% in the fourth; three implementations in three languages agree, though they share a lineage. Because eddsa-rdfc-2022 has no derivation step, presenting a subset re-signs it; ecdsa-sd-2023, which preserves the issuer signature, costs 3.4 ms to issue and 1.5--2.4 ms to derive and verify there. With production education schemas, canonicalization costs 31--49x a simple credential across the four, and blank node labeling is not the driver. The measured path ends at the issuer signature check.