You do not choose one. The EUDI framework requires support for both, and the Architecture and Reference Framework already assigns them: proximity presentation follows ISO/IEC 18013-5, and remote presentation goes through OpenID for Verifiable Presentations, where both formats are profiled.
So the real decision is sequencing. If your users present remotely, in a browser or an app, build SD-JWT VC first. If they present in person, at a counter or a gate, build ISO mdoc first.
The dated fact that settles most of the argument is a Commission Implementing Regulation. The OpenID4VC High Assurance Interoperability Profile, version 1.0, is referenced in CIR (EU) 2026/1731, and that profile covers OpenID for Verifiable Credential Issuance, OpenID for Verifiable Presentations, IETF SD-JWT VC and ISO mdoc together, in one document. That is the answer to which format is the European one. Both.
What are the concrete differences you will hit in implementation?
Does the ARF actually let you choose?
Not on the presentation mode, which is the part most people think is a choice. The Architecture and Reference Framework is explicit. For remote presentation flows, the wallet implements OpenID for Verifiable Presentations. For proximity presentation flows, it adheres to ISO/IEC 18013-5. That decision is already made, and it maps almost exactly onto the two formats, because ISO 18013-5 is both a format and a proximity protocol.
Where you do have latitude is on remote flows. In OpenID4VP, both mso_mdoc and dc+sd-jwt are valid, and the high assurance profile covers combined issuance of both. So a remote-only service can reasonably start with SD-JWT VC alone and add mdoc later. Whether the obligation applies to you at all is a separate question, covered in which sectors must accept the EUDI Wallet. The surrounding engineering work is in our relying party integration guide.
What does the draft status of SD-JWT VC mean for a project starting now?
It means version pinning is a real task, not a formality. SD-JWT is RFC 9901 and stable. SD-JWT VC is draft-ietf-oauth-sd-jwt-vc-18, dated 3 August 2026, on the standards track and not yet an RFC. The European Commission assessed draft 11 from October 2025 and identified no gaps, while noting the specification was still evolving and would need reassessment once final.
The ecosystem responded to exactly this problem. In October 2025 both OpenID4VCI and OpenID4VP froze the version of SD-JWT VC they reference, and the high assurance profile followed. So the practical answer is not to track the latest draft. It is to track whichever draft the profile you are conforming to has frozen, and to record that version number in your own documentation.
What do you actually have to build on the verifier side?
The formats differ, and the surrounding work is largely the same, which means the format decision is smaller than it looks. Common to both: building the presentation request, where recent OpenID4VP work uses DCQL rather than earlier presentation definition approaches. Resolving trust, which in the EU context means ETSI trusted list resolution and the List of Trusted Lists, a different model from the certificate chain validation used with the Portuguese Citizen Card. Verifying holder binding where enforced. Checking status. And deciding what to keep, which is a record that a verification happened rather than a copy of the credential.
So which do you build first?
Four questions, in order. The first one that gives a clear answer decides it. Do users ever present in person, at a counter, gate or device, in which case ISO mdoc first, because proximity is 18013-5 and there is no alternative path. Is every interaction remote, in which case SD-JWT VC first, for the lower integration cost. Do you already know which format your first live counterparty issues, in which case match it, because testing against something real beats architectural preference. And are you building for a sector where mDL is the primary credential, such as transport or vehicle rental, in which case mdoc first and expect it to stay primary.
And one architectural instruction that survives whichever answer you got. Keep the format handling behind an interface, and make your application logic ask what was verified and to what assurance level, never what the credential contained structurally. The second format is coming. Whether it arrives in six months or two years, the cost of adding it is set by a decision you make now.
Frequently asked questions
The two formats
What is the difference between SD-JWT VC and ISO mdoc?
Does the EUDI Wallet require both credential formats?
Standards status and identifiers
Is SD-JWT VC a finished standard?
What are the credential format identifiers in OpenID4VP?
Sequencing
Which format should a remote-only service implement first?
Can you avoid supporting CBOR?
