Skip to main content

SD-JWT VC credential format

When a user presents their digital credentials, they shouldn't have to reveal everything on the credential just to prove a single fact. The SD-JWT VC (SD-JWT-based Verifiable Credentials) format solves this by allowing holders to share only the specific attributes a Relying Party requests, while keeping everything else private.

SD-JWT VC vs SD-JWT

SD-JWT VC and SD-JWT are two related but distinct specifications. SD-JWT (RFC 9901) defines the selective disclosure mechanism—the salted-hash technique that enables attribute-level disclosure from a signed JWT. SD-JWT VC (draft-ietf-oauth-sd-jwt-vc-15) builds on that mechanism to define a credential format with attestation metadata, proof mechanisms, and device binding. When this page refers to the credential format, it uses "SD-JWT VC." When it refers to the underlying disclosure mechanism, it uses "SD-JWT."

The Truvity EUDIW Connector uses SD-JWT VC as the credential format for remote verification flows. The EUDI ecosystem mandates two attestation formats: SD-JWT VC and ISO/IEC 18013-5 (mDoc). Both can be used for remote presentation flows via OID4VP, while ISO/IEC 18013-5 also supports proximity flows. The connector focuses on SD-JWT VC.

The EUDI ecosystem also requires the HAIP profile on top of SD-JWT VC to ensure interoperability between Wallet Units and Relying Parties. HAIP constrains the options in SD-JWT VC to specific choices required for the ecosystem.

Why SD-JWT VC matters​

Physical identity documents force an all-or-nothing disclosure. Showing your ID card to prove your age also reveals your name, address, and photo. SD-JWT VC transforms this by enabling granular, attribute-level disclosure.

This capability directly supports two core requirements of the EUDI ecosystem:

  • Data minimization (GDPR Article 5(1)(c)): You request only the attributes you need, and the wallet enforces this constraint
  • User control (eIDAS 2.0): Users see exactly what data is requested and must explicitly consent before sharing

How SD-JWT VC works​

An SD-JWT VC credential separates into three conceptual layers.

Issuer-signed payload​

The issuer signs a payload that contains two categories of information: attestation metadata and cryptographic digests of attributes. The attestation metadata—such as the issuer identity, attestation type, and validity period—is always visible to the Relying Party. The attribute digests are one-way hashes that enable selective disclosure: the actual attribute values aren't included in the signed payload.

Because the issuer signs both the metadata and the digests, they can't be tampered with. Any modification invalidates the signature.

Disclosures​

Each sensitive attribute is packaged as a separate disclosure containing a random salt and the attribute value. The issuer provides these disclosures to the holder alongside the signed payload.

During presentation, the holder selects which disclosures to include. The connector hashes each received disclosure and compares it against the digests in the signed payload. If they match, the attribute is authentic.

Key binding​

Device binding (called "key binding" in the SD-JWT VC specification) proves that the presenter is the legitimate holder of the credential. The issuer embeds the holder's public key in the signed payload. During presentation, the wallet signs a challenge from the connector using the corresponding private key.

Device binding is mandatory for PIDs (Personal Identification Data) because they require a high level of assurance. For other SD-JWT VC attestations, device binding is recommended but not mandatory. A Relying Party can request key binding proof via the presentation request, and the connector requests it by default.

This mechanism prevents credential theft. Even if an attacker obtains the credential data, they can't present it without the private key stored in the holder's secure hardware.

Verification process​

When the connector receives an SD-JWT VC presentation, it performs a series of checks:

  1. Signature validation: Confirms the issuer's signature on the payload is authentic
  2. Disclosure matching: Hashes each received disclosure and verifies it matches a digest in the signed payload
  3. Key binding verification: Validates the holder's proof of possession using the public key embedded in the credential
  4. Replay protection: Confirms the presentation is bound to the current session and can't be reused
  5. Transaction binding: If the request included transactional data, verifies the holder signed over it
  6. Revocation status: Checks whether the issuer has revoked the credential

Privacy and security features​

Unlinkability​

Each disclosure includes a unique random salt. This prevents correlation attacks where verifiers could track a user across sessions by comparing identical hashes. With unique salts, the same attribute produces a different hash in every issuance.

Transaction binding​

For high-value operations, you can include transactional data in the presentation request (for example, "authorize payment of EUR 50 to Merchant X"). The wallet signs over this data as part of the key binding proof, creating a cryptographic link between the user's consent and the specific action. This prevents a valid presentation from being replayed in a different context.

Further reading​