SD-JWT is a selectively disclosable JSON Web Token format for presenting only chosen claims from a credential, while mdoc is a mobile document format defined for constrained, device-based identity credentials. Both support privacy-preserving disclosure, but they are different credential models. Practitioners should align wallet support, verifier requirements, and disclosure rules to the chosen format.
Why SD-JWT and mdoc Are Different Credential Models
SD-JWT and mdoc both aim to reduce disclosure, but they are built for different credential ecosystems. SD-JWT is a token-centric format that lets a holder reveal only selected claims from a signed JSON-based credential. mdoc is a device-oriented mobile document format designed around constrained, reader-facing presentation workflows such as mobile driving licences and related identity documents.
The practical difference is not just syntax. SD-JWT fits better where JSON-native issuance and verification are already in place, while mdoc fits environments that expect ISO-style mobile document handling, device engagement, and reader authentication. That means a wallet, issuer, and verifier stack may support one format cleanly and still not support the other without additional protocol work.
For a broader implementation view, the Verifiable Credentials Guide covers where SD-JWT VC, mdoc, and related presentation patterns sit inside the wider verifiable-credentials ecosystem.
What Changes for Wallets, Issuers, and Verifiers
Wallet support is often the first constraint. An SD-JWT wallet must handle selective disclosure over claim sets and present disclosures in a way verifiers can validate against the original token. An mdoc wallet must support document presentation, device binding or device engagement flows, and the reader expectations defined by mobile document standards.
Issuer and verifier requirements also differ. With SD-JWT, the issuer is usually working in a token-oriented identity stack and the verifier evaluates selectively disclosed claims against token integrity. With mdoc, the verifier is usually built for a document model that expects structured data elements, reader authentication, and a presentation flow suited to mobile identity documents. The result is that interoperability is not automatic even when both formats deliver similar privacy outcomes.
These ecosystem differences matter because the same credential content can be operationally easy in one model and awkward in the other. The more tightly your relying parties are tied to mobile document standards, the more likely mdoc is the natural fit. The more your environment already uses JSON-based verifiable credentials, the more SD-JWT usually aligns with existing tooling.
For the mdoc side of that split, the Mobile Driving Licence (mDL) Guide explains the ISO 18013-5 and 18013-7 context that shapes mdoc deployment and reader behaviour.
How to Choose the Right Format for a Use Case
The right choice depends on the relying-party model, the wallet platform, and the disclosure rules you need to enforce. If your use case is a general verifiable-credential deployment with JSON-based claims and broad ecosystem tooling, SD-JWT is often easier to integrate. If your use case is a regulated mobile identity document or a proximity-style presentation workflow, mdoc is usually the more natural model.
Privacy goals alone do not decide the format. Both can support selective disclosure, but they do so through different structures and operational assumptions. The important design question is whether you need a flexible credential token model or a mobile document model with device and reader constraints. That choice affects verification logic, user experience, and future interoperability.
Practitioners should also align the chosen format with their trust framework and presentation protocol. A deployment that mixes unsupported wallet behaviour, unclear disclosure rules, or mismatched verifier expectations will fail even if the credential format is technically correct.
Risk and Threat Considerations
Format mismatch creates security and operational risk because the verifier may accept the wrong presentation assumptions, or a wallet may expose disclosures in a way the relying party did not intend. The main failure mode is not that the format is insecure by itself, but that ecosystem assumptions, reader support, and disclosure handling do not line up cleanly.
Failure mechanism: A team treats SD-JWT and mdoc as interchangeable, then builds issuance or verification logic that cannot correctly process the chosen credential model, weakening interoperability and increasing the chance of broken or inconsistent validation.
Impact: Users face failed presentations, issuers inherit support complexity, and verifiers may accept incomplete or malformed disclosures unless the whole stack is tested against the exact format in use.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-63 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Selective disclosure and wallet-based presentation are identity-assurance concerns. |
| Recommendation — Align credential presentation and verifier expectations to the assurance level and authenticator model. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Both formats rely on controlled credential material and lifecycle handling. |
| IA-9 — Service Identification and Authentication | Verifier-to-wallet exchanges depend on strong mutual authentication and trusted presentation paths. | |
| Recommendation — Manage credential lifecycle, rotation, and revocation for the credential material in use. Authenticate service and verifier endpoints before accepting credential presentations. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Credential verification flows fail if presentation or token validation is weak. |
| API5 — Broken Function Level Authorization | Verifier logic must enforce which claims may be disclosed and consumed. | |
| Recommendation — Validate presentation and token authentication paths so malformed disclosures are rejected. Enforce function-level authorization on every claim-processing path. | ||
Practitioner Guidance
What to verify: Confirm the wallet, issuer, and verifier all support the same format, not just the same claims. Test disclosure, revocation or status handling, and presentation flow end to end before rollout.
Decision rule: If your relying parties are already anchored in mobile document standards, choose mdoc and optimise for reader and device behaviour. If your ecosystem is JSON-credential centric and needs flexible selective disclosure, choose SD-JWT and keep the verifier logic tightly scoped to that model.
Practitioner takeaway: The key decision is ecosystem fit, not feature parity, because SD-JWT and mdoc can both protect privacy while still requiring different wallets, verifiers, and disclosure rules.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org