SD-JWT VC packages claims as a signed JWT where individual claims can be withheld at presentation without breaking the issuer signature. It is one of three attestation formats the ARF recognises, alongside ISO/IEC 18013-5 mdoc and W3C VCDM v2.0, and it is identified by the media type dc+sd-jwt.
Technical standardReviewed 7 October 2026
Inside the wallet, which belongs to the user and is under their control.
Issuer
Signs credentials: a member state, university, bank or employer
Issuance
EUDI Wallet
Belongs to the user, who decides what to share
Presentation
Relying party
The service that requests and checks the data
Trust layer: who is allowed to sign, and is it still valid?
Rules: the law and technical framework behind it all
The issuer signs a JWT holding salted hashes of each claim rather than the values, and hands the holder the disclosures separately. At presentation the holder sends only the disclosures for the claims being revealed, and the verifier recomputes the hashes to confirm they match what was signed.
That is how selective disclosure works cryptographically. The issuer does not need to know in advance which subset gets revealed, and the verifier does not have to take the holder’s word about what was left out.
One detail catches people out. PID is not an SD-JWT VC credential, it is issued in both formats at once, because SD-JWT VC attestations cannot be presented in proximity. The mdoc copy is what a reader standing in front of you uses. Remote presentation of the SD-JWT VC copy runs over OpenID4VP as profiled by HAIP.
Defined in
IETF draft-ietf-oauth-sd-jwt-vc; ARF v3.0.0 sections 5.4.1 and 5.4.3, requirement PID_02
Selective disclosure is an argument you can make in an audit. This is the mechanism that turns "we only received age_over_18" into something verifiable rather than a policy promise.