Appearance

SD-JWT VC vs. ISO mdoc for wallet verification ​

SD-JWT VC and ISO mdoc are two credential formats that can be used in wallet presentation flows. They can both support selective disclosure, but they use different data structures, cryptographic proofs, and verifier processing. Choose based on the credential issued, the target wallets, and the profile your relying-party integration supports.

At a glance ​

SD-JWT VCISO mdoc
Typical representationSigned JWT plus selectively released disclosuresCBOR-based mobile document with issuer authentication and device response
Credential typeThe vct value identifies the credential typeThe docType identifies the mobile document type
Selective disclosureHolder shares disclosures whose digests are bound to the signed JWTWallet returns requested document elements under the applicable mdoc profile
Holder or device bindingA Key Binding JWT can bind the presentation to the verifier and transactionDevice authentication uses the mdoc session transcript and requested profile
Common ecosystem examplePID or other JSON-claim credentials where issued in this formatMobile driving licence and other ISO mobile documents
OID4VP query metadatavct_valuesdoctype_value

The table describes format-level differences. A deployment profile may add requirements or constrain supported algorithms, transport, issuer trust, and holder binding.

How the formats differ ​

SD-JWT VC ​

An SD-JWT combines an issuer-signed JWT with optional disclosures. The signed payload contains digests for selectively disclosable values; a presentation includes the disclosures the holder chooses to share. When the profile requires cryptographic holder binding, the presentation also includes a Key Binding JWT.

The SD-JWT format is specified in RFC 9901. SD-JWT VC defines its use for verifiable credentials; check the applicable profile and issuer metadata rather than assuming every SD-JWT is an SD-JWT VC.

ISO mdoc ​

An mdoc is a mobile document format defined by the ISO/IEC 18013 and related standards. An mDL is one document type within that ecosystem. The verifier checks the issuer-authenticated document and, when required by the profile, the wallet device response bound to the presentation session.

For mdoc, request the intended document type and namespace as well as the specific data elements. The exact transport, trust anchors, and proof checks depend on the mdoc and OID4VP profile in use.

Both formats can use OID4VP ​

OID4VP is the presentation protocol, not a credential format. Its DCQL query uses vct_values to select SD-JWT VC types and doctype_value to select mdoc document types. The verifier and wallet need compatible format and protocol profiles; accepting one does not imply support for the other.

The verifier must bind each returned presentation to the expected verifier and transaction, then check issuer trust, credential validity, requested claims, and format-specific holder proof. See OID4VP nonce and state validation for transaction binding details.

How to choose a format ​

Start from the credentials your intended issuers actually provide and the wallets your users can access. Then confirm:

  • the credential type or mdoc docType and claim names for the profile;
  • how issuer authenticity and status are established;
  • whether the profile requires holder or device binding;
  • which claims the wallet can selectively disclose;
  • which wallets and presentation modes are supported in your target market;
  • what fallback path is available when a wallet cannot satisfy the request.

Neither format is universally more private or more interoperable. Data minimization depends on what the request asks for, what the credential contains, and how the profile and verifier process the response.

Implement both paths with DLBR ​

DLBR's API accepts vc+sd-jwt requests with vct_values and mso_mdoc requests with doc_type and namespace. Review the format-specific guides:

References ​

Built for developers integrating privacy-preserving identity verification.

© DLBR