Two Standards Bodies, One Presentation Protocol: How ISO and OpenID Are Ending the mdoc-vs-SD-JWT War Without Picking a Winner

1. The Verifier That Has to Speak Two Languages#

A bar in Marseille wants to do the simplest thing in the world: confirm that a customer is over 18 without reading their name, address, or birthday. Two customers hold up their phones. The first presents an ISO mdoc, the mobile driving licence format built by the automotive-and-documents standards world. The second presents an SD-JWT VC, the JSON-based credential built by the web-identity world. To accept both, the bar's verifier app has to implement two completely different presentation protocols, authored by two standards bodies that, for years, never sat in the same room.

Here is the question, far deeper than it looks: why does accepting a digital ID require speaking two languages at once, and what would it take to speak just one?

The instinct is to call this a format war and predict a winner. That instinct is wrong, and the reason it is wrong is the whole point of this article. The customer's two phones are not the problem. Each credential arrives wrapped in its own request-and-response machinery.

To read the mdoc, the verifier speaks ISO/IEC 18013-7's Device Request and Device Response. To read the SD-JWT VC, it speaks OpenID for Verifiable Presentations (OID4VP), an OAuth-shaped Authorization Request and Authorization Response. Two protocols, two code paths, two conformance regimes, two sets of edge cases. That is the hidden two-stack tax.

flowchart LR
V["One verifier app"] --> S1["Stack 1: ISO Device Request/Device Response"]
V --> S2["Stack 2: OID4VP Authorization Request/Response"]
S1 --> M["mdoc (CBOR/COSE)"]
S2 --> J["SD-JWT VC (JSON/JWS)"]

The tax is invisible in a demo and expensive in production. Every verifier that wants to serve the whole market pays it twice: once to build each stack, and forever to maintain both. And it exists at a layer most people never name, because they collapse two independent ideas into one.

Once you separate those layers, the headline rewrites itself.

The mdoc-versus-SD-JWT-VC "war" was never a format war. The pain a verifier feels comes from having to implement two entirely different presentation protocols. Fix the protocol layer, and the two formats can coexist untouched.

That fix now has a name and a date. In June 2026, ISO and the OpenID Foundation chartered a joint group, the Digital Credentials Harmonized Presentation (DCHP) Working Group, to develop one harmonized Digital Credentials Request Protocol that carries both mdoc and SD-JWT VC. Its first meeting is Monday, 29 June 2026 ^{[1] [4]}.

To see why one credential moment needs two protocols, you have to visit two rooms that, for most of the last decade, never shared a table.

2. Two Lineages, Two Rooms#

Credential presentation was solved twice, by two communities that optimized for different worlds and never had to agree. Neither was wrong. They simply answered different questions, and each answer came with its own protocol attached.

Room A: the documents-and-devices world#

The first room is ISO/IEC JTC 1/SC 17, the committee behind cards and security devices for personal identification, and specifically its Working Group 10, home of the mobile driving licence ^[6]. Its members carried decades of experience with physical identity documents, chip cards, and issuing-authority public-key infrastructure, with organizations like AAMVA (the American Association of Motor Vehicle Administrators) at the table. In September 2021 they published ISO/IEC 18013-5:2021, which defined the mDL and, with it, the mdoc ^[7].

The design center was an officer checking a licence at the roadside with no connectivity. That priority explains everything downstream: a binary encoding for compactness, a device-to-device retrieval model over QR, NFC, and Bluetooth Low Energy, and no assumption that anyone is online. It was high-assurance identity, in person, and it shipped with its own request-and-response model baked in. Its only online mode was a limited, privacy-problematic server retrieval, in which the verifier fetched the data from the issuer's own server; it had no model for a holder to present an mDL remotely to a website of their choosing.

Room B: the web-identity world#

The second room was the open web's identity community, spread across the W3C, the IETF, and the OpenID Foundation. It began with a shared vocabulary rather than a protocol. In November 2019 the W3C published the Verifiable Credentials Data Model 1.0, standardizing the issuer-holder-verifier triangle and a JSON/JSON-LD shape for a credential ^[8]. That was a data model, deliberately silent about the wire exchange, which left room for a presentation protocol to grow up beside it.

Two things grew there. On the format side, Daniel Fett and colleagues started SD-JWT at the IETF OAuth Working Group around 2022, a way to add selective disclosure to signed JSON Web Tokens; the credential profile built on top became SD-JWT VC ^[9]; the base SD-JWT draft was later published as RFC 9901 ^{[10] [11]}. On the protocol side, the OpenID Foundation published its "OpenID for Verifiable Credentials" whitepaper in May 2022 and the early editors' draft of OID4VP, framing presentation as an OAuth-family Authorization Request and Authorization Response ^[12].

That attribution matters and is easy to get wrong. SD-JWT VC belongs to the IETF ^[13]; OID4VP belongs to the OpenID Foundation's DCP Working Group. OpenID's contribution is the protocol, not the format. Kristina Yasuda (Keio University) is a useful bridge figure to hold onto: she co-authored RFC 9901 and edits OID4VP, one person linking the IETF credential format and the OpenID presentation protocol ^[11]. Daniel Fett and Brian Campbell similarly span SD-JWT and SD-JWT VC ^[9].

The load-bearing point#

Here is the fact the rest of the story hangs on: each room shipped its credential format fused to its own request-and-response protocol. The ISO world bound mdoc to Device Request/Device Response. The web world bound SD-JWT VC to OID4VP's Authorization Request/Response. Neither treated "how you ask for a credential" as a separable layer that could be shared. So the moment a verifier needed to accept both, it inherited both protocols. The two-stack tax was not a bug anyone introduced; it was the sum of two independently reasonable designs.

timeline
title Two lineages, then convergence
2019 : W3C Verifiable Credentials Data Model 1.0 (web lineage begins)
2021 : ISO/IEC 18013-5 mdoc and proximity Device Request/Response (ISO lineage begins)
2022 : SD-JWT started at the IETF : OID4VP editors draft and OIDF whitepaper
2024 : ISO/IEC TS 18013-7 first edition gives mdoc an online path by profiling OID4VP
2025 : ISO/IEC TS 18013-7 second edition (29 May) : OID4VP 1.0 reaches Final : SD-JWT becomes RFC 9901
2026 : La Ciotat interop event : DCHP joint working group chartered

Two rooms, two credentials, two protocols. So how did each one actually make a holder show a credential? Put the two mechanisms side by side, and the split stops being abstract.

3. How Each World Made a Holder Show a Credential#

Start with the ISO world, because it is the one most web developers have never seen. Its presentation exchange assumes no network at all.

The flow begins with Device Engagement: the verifier's reader and the holder's phone bootstrap a set of ephemeral keys, typically by scanning a QR code or tapping over NFC. That handshake establishes an encrypted channel over Bluetooth Low Energy, NFC, or Wi-Fi Aware.

Across that channel the verifier sends a Device Request, a CBOR structure naming the exact data elements it wants. The wallet answers with a Device Response containing only those elements, carrying two signatures: the issuer's COSE signature over the Mobile Security Object (proving the data is authentic) and the device's own key (proving this phone is the legitimate holder) ^[7].

sequenceDiagram
participant V as Verifier reader
participant H as Holder wallet
V->>H: Device Engagement (QR or NFC bootstraps ephemeral keys)
Note over V,H: Encrypted channel over BLE, NFC, or Wi-Fi Aware
V->>H: Device Request (CBOR list of wanted data elements)
H->>V: Device Response (only the requested elements)
Note over V,H: COSE issuer authentication plus device-key mdoc authentication
Note over V,H: No party needs to be online

Now the web world, which assumes the opposite: everyone is online, and the exchange looks like OAuth. Per the OID4VP 1.0 Final specification, section 8.2, the verifier builds an Authorization Request carrying response_type of vp_token, a nonce, a state, and a dcql_query describing which credentials and claims it needs ^[14].

That dcql_query is the verifier's shopping list, written in the Digital Credentials Query Language (DCQL), OID4VP's own JSON query object for naming credentials and claims independent of their format; its full structure does real work in the practical guide. The request can be sent by value or fetched by reference through a request_uri, and it "can be displayed to the End-User either directly (as a link) or as a QR Code" ^[14].

The wallet authenticates the request, gets the user's consent, and assembles a vp_token. Using response mode direct_post, it sends that token back as an HTTP POST to the verifier's response_uri ^[14].

sequenceDiagram
participant V as Verifier
participant W as Wallet
V->>W: Authorization Request (response_type vp_token, nonce, state, dcql_query)
Note over V,W: Delivered by value or by request_uri, renderable as a QR code
W->>W: Authenticate request and obtain user consent
W->>V: vp_token by response mode direct_post (HTTP POST to response_uri)
V->>W: HTTP 200 with optional redirect_uri

One exchange is device-centric and offline-rooted; the other is online and OAuth-rooted. Neither could simply swallow the other: the ISO model was never web-native, and the web model was never the ISO device-retrieval model. Yet look closely at how each one actually protects and discloses a claim, and something surprising appears: the two mechanisms are almost the same idea in two encodings.

Both worlds support selective disclosure, but they implement it differently.

The SD-JWT mechanism is worth seeing in code, because it explains a design choice that trips up implementers. RFC 9901 uses source-string hardening: each disclosable claim becomes a Disclosure (a JSON array of salt, name, value) that is base64url-encoded, and the issuer embeds a digest of that encoded string under _sd. The wire form joins the issuer-signed JWT, the chosen Disclosures, and an optional Key Binding JWT with the ~ character. The verifier hashes each Disclosure exactly as received and matches it against the issuer's _sd list ^[11].

// SD-JWT wire form (RFC 9901): issuer-signed JWT, then one Disclosure per claim,
// then an optional Key Binding JWT, all joined by "~".
const issuerJwt = "******"; // its payload carries the _sd digest list
const discAge  = "WyJzYWx0IiwgImFnZV9vdmVyXzE4IiwgdHJ1ZV0";    // ["salt","age_over_18",true]
const discName = "WyJzYWx0MiIsImdpdmVuX25hbWUiLCJBbGV4Il0";     // ["salt2","given_name","Alex"]

// The holder chooses to reveal only age_over_18; the name stays withheld.
const wire = [issuerJwt, discAge].join("~") + "~";
console.log("presented:", wire);

// Source-string hardening: hash the Disclosure string exactly as transmitted
// (a real verifier uses SHA-256 + base64url; this stand-in keeps the demo self-contained).
function digest(s){ let h = 0; for (const c of s) h = (h * 31 + c.charCodeAt(0)) >>> 0; return "sha256:" + h.toString(16); }

// The digests the issuer embedded under _sd inside the signed JWT payload:
const _sd = [digest(discAge), digest(discName)];

for (const d of wire.split("~").slice(1).filter(Boolean)) {
const matched = _sd.includes(digest(d));
console.log(matched ? "ACCEPT" : "REJECT", d.slice(0, 20) + "...");
}
// Rule (RFC 9901 section 7): a Disclosure with no matching _sd digest MUST be rejected;
// an _sd digest with no Disclosure is simply left undisclosed. The name digest above is
// present in _sd but never disclosed, which is exactly correct.

Now do the same anatomy for the mdoc, because the parallel is the point. The Device Response is a CBOR DeviceResponse structure; each document inside it carries an IssuerSigned part whose data elements are grouped under namespaces such as org.iso.18013.5.1, and a claim is addressed by exactly two strings, [namespace, data element identifier], returned as a CBOR data item ^{[14] [15]}.

Each released element is an IssuerSignedItem, which in the ISO/IEC 18013-5 data model is the tuple { digestID, random, elementIdentifier, elementValue }, where random is a per-element salt ^[7]. Integrity is anchored by issuerAuth, a COSE-signed Mobile Security Object (MSO) whose ValueDigests structure maps, per namespace, each digestID to a digest ^[16]. ※ The MSO is the mdoc's integrity anchor: one COSE signature over the digests of every element, so the issuer signs the whole set once and the holder later reveals any subset without a new signature ^[7].

Verification then mirrors SD-JWT almost step for step. The holder returns only the chosen IssuerSignedItem values; the verifier recomputes each item's digest and matches it against the signed MSO ValueDigests entry, exactly as the SD-JWT verifier matched Disclosure digests against _sd. Finally it checks deviceAuth, the deviceSignature, to prove the phone holds the mdoc's device key, the mdoc analogue of the optional Key Binding JWT ^[16]. Lay the two mechanisms next to each other and they line up member for member.

The two formats are the same disclosure idea -- salted-hash selective disclosure over one stable issuer signature -- in two encodings. In one line: mdoc is CBOR/COSE, a compact binary encoding with integer keys; SD-JWT VC is JSON/JWS text plus base64url-encoded Disclosures, and base64url inflates bytes by roughly a third ^[11]. The two are not trivially interconvertible, which is why "just merge them" is harder than it sounds. Note also the shared consequence, paid off in section 8: because both re-present one fixed issuer signature, both sit on the linkable side of the privacy line. That shared shape is a gift to the harmonizer, because it means a single request protocol can drive either one. So the pressure fell on making the two protocols reach toward each other, one waypoint at a time.

4. Five Generations Toward One Protocol#

Nobody planned convergence. It happened because every partial fix left one stubborn gap that only the next step could close. Trace the chain and a pattern appears: each generation solved a real problem and, in doing so, exposed the next one. The two credential formats ride through the entire chain unchanged. What moves is the protocol.

Generation 1: proximity mdoc (2021). ISO/IEC 18013-5 delivered high-assurance identity for an officer at the roadside, offline, device to device ^[7]. The gap was named by its own scope: its only online mode was server retrieval, in which the verifier fetched the data from the issuer's own server, a limited and privacy-problematic path. If you wanted a holder to present an mDL directly to a website, the standard had no model for it.

Generation 2: OID4VP (2022 to 2025). In parallel, the web world built an online presentation protocol on OAuth's Authorization Request and Response, adding a native query language along the way. The OpenID Foundation approved OID4VP 1.0 as a Final Specification in July 2025 ^[17]. ※ The Final vote was 79 approve, 2 object, 17 abstain: 98 ballots cast, which cleared the required quorum ^[17].

This is the step most people miscategorize. OID4VP is not a successor to the mdoc; it is a parallel origin in the other room. Its gap was symmetric to Generation 1's: it was never the ISO device-retrieval model, so the mDL world could not migrate onto it wholesale. Two base protocols now existed, and neither was going away. There is exactly one clean supersession inside this story: OID4VP originally expressed "what the verifier wants" with DIF Presentation Exchange, and OID4VP 1.0 replaced it with the native Digital Credentials Query Language (DCQL, the dcql_query parameter) ^[14]. Everything else here is a scope boundary, not a defeat.

Generation 3: online mdoc via TS 18013-7 (2024 to 2025). ISO's response to its own gap was telling. Rather than fork a rival web protocol from scratch, it reached into the web protocol. ISO/IEC TS 18013-7 -- a first edition in 2024, superseded by a second edition published 29 May 2025 -- augments the mDL "with presentation of a mobile driving licence to a reader over the internet" by profiling OpenID4VP for the online flow ^{[18] [19]}.

One chronological subtlety matters, because it is easy to state wrong: the references to OID4VP 1.0 Final and HAIP 1.0 Final belong to the standard's draft appendices, the ones exercised at La Ciotat in May 2026, not to the published 29 May 2025 edition, which necessarily predates OID4VP reaching Final in July 2025 ^[2]. Either way, this was the first real convergence point: an mdoc carried through an OID4VP-profiled exchange. But it was a profile bolted onto one protocol, not a merger. The two base models still, in the DCHP announcement's own words, "take different approaches to credential presentation" ^[1].

Generation 4: La Ciotat (May 2026). Paper profiles are cheap; interoperability is earned in a room full of implementers. At the 13th ISO mDL interoperability test event in La Ciotat, France, on 28 to 29 May 2026, teams ran ISO/IEC 18013-5 and the TS 18013-7 draft appendices together with OID4VP 1.0 Final and HAIP 1.0 against the OpenID Foundation's conformance suite ^[2].

Generation 5: DCHP (June 2026). The diagnosis produced a treatment. In June 2026, ISO's WG10 and WG4 and the OpenID Foundation's DCP Working Group chartered the joint Digital Credentials Harmonized Presentation Working Group to develop one harmonized Digital Credentials Request Protocol that "supports the exchange of multiple credential formats (mdoc and SD-JWT VC)," with a first meeting on 29 June 2026 ^[1]. It is a chartered deliverable, not a shipped one; the spec workspace at the time of writing holds only a stub README ^[21].

flowchart TD
G0["2019: W3C VC Data Model (data model, no protocol)"]
G1["Gen 1 (2021): ISO 18013-5 proximity mdoc"]
G2["Gen 2 (2022 to 2025): OID4VP online, Final July 2025"]
G3["Gen 3 (2024 to 2025): ISO TS 18013-7 online mdoc profiles OID4VP"]
G4["Gen 4 (May 2026): La Ciotat proves both stacks interoperate"]
G5["Gen 5 (June 2026): DCHP one harmonized request protocol"]
G0 --> G1
G0 --> G2
G1 --> G3
G2 --> G3
G3 --> G4
G4 --> G5

Laid out as a table, the through-line is the "gap that drove the next step" column: no generation was defeated, each was simply incomplete on its own.

Five generations, and the industry still ships two protocols. So what insight finally reframes the problem so that one protocol becomes possible, without anyone having to lose?

5. Decouple the Protocol from the Format#

The reframe is almost embarrassingly simple, and it is why nobody had to "win": stop treating the credential format and the presentation protocol as one thing.

For years, the two rooms each shipped a bundle. If you wanted the mdoc, you took Device Request/Device Response with it. If you wanted SD-JWT VC, you took OID4VP with it. The bundle felt natural because each format was born inside its protocol. But the bundle was never necessary. A protocol is a way to ask for and return a credential; a format is what the credential is. Once you insist on that separation, the whole conflict changes shape. You no longer need one format to defeat the other. You need one protocol that can request and carry either one.

You do not unify by choosing a winner. You unify by decoupling: separate the presentation protocol from the credential format, and one harmonized request protocol can carry either mdoc or SD-JWT VC. The two formats never have to change.

The reason this is a breakthrough and not a fantasy is that most of it already exists. OID4VP's vp_token is deliberately format-agnostic, and DCQL queries credentials independently of their encoding ^[14]. ISO/IEC TS 18013-7 already carries an mdoc through an OID4VP-profiled online flow ^[18]. In other words, a single protocol that carries both formats is within reach of constructions that already ship today. The remaining work is reconciliation and joint ratification, not the invention of a new cryptographic primitive.

flowchart TD
V["Verifier"] --> P["One harmonized request protocol (DCHP)"]
P --> M["mdoc (CBOR/COSE) stays distinct"]
P --> J["SD-JWT VC (JSON/JWS) stays distinct"]
M --> W["Wallet returns the requested format"]
J --> W

Seeing the two layers on separate axes makes the scope of the fix precise. DCHP acts on exactly one of them.

The technical insight, though, is only half the story. The other half is institutional, and it matters just as much. Standards bodies do not merge by good intentions; a shared spec that lives inside one organization's process tends to be treated as that organization's property. DCHP is engineered to avoid exactly that failure mode.

This is where the article's title stops being a play on words and becomes a precise claim. "One Credential Presentation" means one protocol, not one format. The formats persist on purpose. The EU Digital Identity Wallet Architecture and Reference Framework v2.9 mandates both mdoc and SD-JWT VC as baseline, because each serves a domain the other does not ^[3]. Harmonization at the protocol layer is the objective; harmonization at the format layer is neither the plan nor a desirable one.

"The DCHP WG will develop a technical specification for a harmonized Digital Credentials Request Protocol that brings these together, and supports the exchange of multiple credential formats (mdoc and SD-JWT VC)." ^[1]

If the protocol can be unified in principle, the obvious next question is empirical: how unified is the world today, in the window before the harmonized protocol ships?

6. Where Things Stand in Mid-2026#

Right now there is no single leader, and that is by mandate, not accident. The EU Digital Identity Wallet Architecture and Reference Framework v2.9 states it in one breath: for remote presentation the wallet implements OID4VP "in combination with the W3C Digital Credentials API," while for proximity presentation the same wallet "adheres to the ISO/IEC 18013-5 standard" ^[3]. That sentence is the state of the art: two presentation protocols, required together, carrying two formats, with a browser API emerging beneath them.

Consider each piece in turn.

On the web side, OID4VP 1.0 Final is the mature, IPR-protected, conformance-tested protocol. It carries SD-JWT VC natively and mdoc through the TS 18013-7 profile, and it asks for claims through DCQL.

OID4VP does not run alone in the field; it runs pinned by a profile, because a base protocol with dozens of options is not yet an interoperable one.

"Build on HAIP" is often said and rarely unpacked, so here is what the profile actually pins, drawn from HAIP 1.0 Final. This table is the difference between a slogan and a specification you can implement against.

On the proximity side, ISO/IEC 18013-5's Device Request/Device Response remains the offline baseline, and TS 18013-7:2025 extends the same model over the internet by profiling OID4VP ^[18]. Above both protocols, a common entry point is taking shape in the browser.

The distinction to hold onto is that the Digital Credentials API is an invocation layer, not a third protocol. The API carries an inner protocol (such as OID4VP) inside a protocol field and an opaque data field. It brokers how the wallet is summoned; it does not define how the credential is requested and returned. That is still OID4VP's job, and tomorrow it could be DCHP's ^[24]. It is also still a Working Draft, not a W3C Recommendation, and the EUDI ARF treats it as optional today, with custom URL schemes allowed as a fallback ^{[24] [3]}.

Behind all of this sits a legal clock. Regulation (EU) 2024/1183, eIDAS 2, entered into force on 20 May 2024, with EU Member States expected to provision wallets around the end of 2026 and private-sector acceptance following roughly a year later ^[25]. That is why "just pick one stack" is not on the table for a European verifier: acceptance of the baseline is heading toward a legal obligation.

The one clean piece of published evidence that the current world works is La Ciotat itself.

"...a strong signal that OpenID for Verifiable Presentations and HAIP are ready for real-world deployment." -- Joseph Heenan, OpenID Foundation ^[2]

One trap deserves a warning, because it is easy to propagate.

And DCHP itself? Chartered, in active formation, first meeting 29 June 2026, with a spec repository that so far holds only a README ^{[1] [21]}. It is the intended future single stack, and it does not yet exist.

That is the whole official world: two protocols, two formats, one invocation layer. But the field is bigger than the baseline. What else is out there, and does any of it ride the harmonized protocol?

7. Beyond the Two Baseline Formats#

This is not a "which format wins" scoreboard. It is a map of a bigger country than the two-format headline suggests, and drawing it honestly is part of getting the thesis right. DCHP's chartered scope is the presentation of mdoc and SD-JWT VC ^[1]. Those are the two EUDI-baseline formats, not the only formats that exist.

Start with the data model that sits beside them. The W3C Verifiable Credentials Data Model 2.0, a Recommendation from May 2025, with JSON-LD Data Integrity proofs, is a securing family in its own right ^[26], descended from the 1.0 model that opened the web lineage in 2019 ^[8]. Then there is the format that looks like it should work and does not.

A plain JWT-VC is a JSON Web Signature over a fixed payload. It structurally cannot do selective disclosure, because JWS signs the exact bytes a verifier must reconstruct in full; you cannot drop a claim without breaking the signature. That limitation is precisely why SD-JWT (RFC 9901) was created, and why SD-JWT VC, not JWT-VC, became the web-side baseline ^[11]. It is a clean illustration that format choices are driven by what the cryptography can and cannot express.

The more interesting frontier is privacy. Both baseline formats are linkable: every showing re-presents the same issuer signature.

Two families attack that gap. BBS signatures, an IRTF draft, sign multiple messages under one constant-size signature and let the holder produce zero-knowledge proofs that disclose a subset while revealing nothing about the undisclosed messages or the signature itself, which yields unlinkable presentations ^[27]. Longfellow-zk, an open-source project from Google, takes a different route: it proves statements in zero knowledge over an issuer's existing signature, for example an ECDSA-signed mdoc, so the issuer does not have to migrate to a new scheme ^[28]. Hyperledger AnonCreds, in the Aries family, is a mature anonymous-credential system built on CL signatures, with predicate proofs and unlinkable presentations ^[29]. It sits in a separate stack, outside the EUDI baseline and outside DCHP's chartered scope.

The sizes matter, because they show why the choice is a genuine trade rather than a free lunch. A BBS signature over BLS12-381 is a constant 80 octets (a group element plus a scalar, 48 + 32), no matter how many attributes it covers; a BBS proof is 272 + 32U octets, where U is the number of undisclosed messages, freshly randomized on every presentation ^[27]. The mdoc and SD-JWT VC byte counts, by contrast, have no reproducible primary and are left un-benchmarked here.

There are also several invocation and retrieval paths, not just formats: OID4VP, ISO device retrieval, the W3C Digital Credentials API, and proprietary wallet SDKs. DCHP addresses one slice of this map: the request protocol for the two baseline formats. Whether W3C VC DM 2.0, AnonCreds, or BBS ever becomes requestable over the harmonized protocol is an open design and political choice, not a settled fact. The formats still compete on their merits; harmonization does not end that competition, and it was never meant to.

One of these alternatives hints at something the baseline formats simply cannot do. Follow that thread and it leads straight to the hard limits of what harmonization can ever achieve.

8. What Harmonization Can and Cannot Do#

Harmonization is powerful and bounded. Three walls are worth knowing before you over-promise it, and telling them apart is the difference between a realistic roadmap and a pitch.

Wall one is not really a wall: one protocol carrying two formats is achievable. This is close to a constructive proof rather than a hope. OID4VP's vp_token is already format-agnostic, DCQL already queries across formats ^[14], and TS 18013-7 already carries an mdoc through an OID4VP-profiled flow ^[18]. So DCHP's deliverable is within reach of known constructions; the hard part is reconciliation and dual ratification, not discovering a missing primitive.

Wall two is permanent and, more surprisingly, desirable: you cannot merge the two formats. CBOR/COSE and JSON/JWS are not two skins on one object. They are different serialization and signature models, one binary and offline-rooted, the other text and web-rooted, and they were optimized for constituencies that do not fully overlap ^[11].

Wall three is the deep one: selective disclosure and multi-show unlinkability cannot both come free from the baseline. Both mdoc and SD-JWT VC re-present a stable issuer signature on every showing (the mdoc's COSE-signed Mobile Security Object, the SD-JWT's issuer-signed JWT plus salted digests), so colluding verifiers, or an issuer watching verifiers, can correlate presentations by that fixed cryptographic material ^[11]. Escaping the correlation is provably not a matter of a better presentation protocol. It requires a different format class:

$\text{selective disclosure} \;+\; \text{multi-show unlinkability} \;\Longrightarrow\; \text{zero-knowledge (or one-time-use) format}$

One route is one-time-use or batch issuance: mint many single-use credentials and spend each once. That route pays in issuance and storage, not compute. The other route is zero-knowledge proofs of a signature, as in BBS, whose 272 + 32U-octet proof the draft describes as unlinkable: its value is "indistinguishable from random even if generated from the same signature" ^[27]. Because two such proofs cannot be linked back to one signature, the verifier is left holding no reusable correlation handle at all. The two routes trade the same quantity in opposite directions:

$\text{one-time-use issuance, storage, re-issuance} = \mathcal{O}(n_{\text{presentations}}) \qquad\text{vs.}\qquad \text{BBS holder storage} = \mathcal{O}(1)$

Batch issuance pays $\mathcal{O}(n_{\text{presentations}})$ in logistics and near-zero in compute; BBS pays $\mathcal{O}(1)$ in storage (one reusable signature) and instead spends fresh prover compute on every proof ^[27]. Either way, the escape lives in the format, never in the request protocol.

flowchart TD
S["A credential presentation"] --> D{"Is a stable issuer signature re-shown on every use?"}
D -->|Yes| L["Linkable: mdoc, SD-JWT VC (selective disclosure only)"]
D -->|No, a zero-knowledge proof is shown instead| U["Unlinkable: BBS, Longfellow-zk"]

Two smaller walls round out the picture. The leading unlinkable option, BBS, is pairing-based over BLS12-381, and its own draft flags post-quantum security as an open consideration, so it is not itself a post-quantum construction ^[27]. The ideal of unlinkable and post-quantum at once is not available in a deployed, standardized format today. And even a technically perfect harmonized specification must ratify through two bodies with different processes and IPR regimes, a bound on delivery speed rather than on mathematics ^[23].

Two coexisting formats is not an unfinished job; it is the correct end state. Merging CBOR/COSE and JSON/JWS would break one constituency, and no presentation protocol can move a credential from linkable to unlinkable. Harmonization unifies the wire and stops exactly there.

If some walls are permanent, the interesting frontier is the one that is merely unsettled. What is genuinely still open?

9. What Is Still Unsettled#

The harmonized protocol is not a finished answer. It is a set of good, hard, unanswered questions with a first meeting on the calendar. Here are the ones worth watching.

Reconciling two request-and-response models into one. This is the core deliverable: produce a single protocol whose semantics subsume both ISO/IEC 18013-7's Device Request/Device Response and OID4VP's Authorization Request/Authorization Response, which today "take different approaches to credential presentation" ^[1]. A targeted search of the public record turns up no authoritative technical design yet, which is exactly what a pre-first-meeting working group should look like; everything else is downstream of getting this right.

Conformance for a protocol that does not exist yet. La Ciotat validated the old stacks against the OpenID Foundation's conformance suite ^[30]. A new protocol needs its own test suite before anyone can call it deployment-ready, and an open question is whether ISO and the OIDF share one suite or maintain two aligned ones across their certification regimes.

Fitting under the browser. The W3C Digital Credentials API carries an inner protocol inside a protocol and data envelope, and OID4VP already rides it. A harmonized protocol would need its own registered protocol identifier there, and the API is still a Working Draft, optional in the ARF today ^[24]. Misalignment at the invocation layer would quietly reintroduce fragmentation one level up.

Unlinkability for the baseline at scale, and why no protocol can supply it. This is the open problem most likely to be misunderstood, so it is worth doing mechanistically. RFC 9901 spells out the only baseline escape from linkability: batch issuance. The issuer mints a batch of credentials over the same claims, and the holder spends a different one with each verifier or even each session ^[11].

But it only works under strict hygiene: new Key Binding keys and new salts MUST be used for every credential in the batch, and the time claims (iat, exp, nbf) must be randomized or rounded. Otherwise the bound holder key, the salted digests, or the timestamps quietly re-link the very showings you tried to separate ^[11]. OID4VP says the same operationally: use multiple instances of a credential, each with unique issuer signatures and keys, and discard each after one use ^[14].

That hygiene is not free. The batch must be sized to the number of distinct verifiers and sessions a holder will encounter, so issuance, wallet storage, and periodic replenishment all scale as $\mathcal{O}(n_{\text{presentations}})$, and replenishment re-introduces an online dependency on the issuer ^[11]. You buy unlinkability with logistics, not cryptography.

Here is the load-bearing part, the reason this belongs in an article about presentation protocols at all. No request protocol can substitute for batch issuance, because the linkable handle is the issuer's signature and the bound public key, presented directly to the verifier, who could forward it to the issuer. That material lives inside the credential, beneath the presentation layer. DCQL and OID4VP only choose which claims and which format populate the vp_token; they cannot alter the signature bytes ^{[11] [14]}.

And even batch issuance only defeats verifier-to-verifier and presentation linkage; it "cannot work for Issuer/Verifier unlinkability," a limit RFC 9901 says "applies to all salted hash-based approaches, including mDL/mDoc" ^[11]. ※ Two different linkabilities hide under one word. Batch issuance can break verifier-to-verifier correlation (two shops cannot tell it was the same holder). It cannot break issuer-to-verifier correlation (an issuer colluding with a verifier still recognizes its own signature). Only a zero-knowledge format closes the second gap ^[11]. Closing that gap needs a zero-knowledge format such as BBS, whose per-presentation proof leaves the verifier no reusable handle to forward ^[27]. The whole thesis lands here: harmonizing the request protocol moves no credential across the privacy axis, because the limit sits in the format, one layer below anything a protocol can touch.

Post-quantum presentation. Identity credentials can outlive classical-cryptography safety margins, yet the baseline rests on classical ECDSA and EdDSA signatures, and even BBS is pairing-based ^[27]. A selectively-disclosable, ideally unlinkable, post-quantum format is an acknowledged frontier with nothing deployed.

Which other formats, if any, ride along. OID4VP's format-agnostic design shows the protocol can be extensible, but DCHP's charter names only mdoc and SD-JWT VC ^[1]. Whether W3C VC DM 2.0, AnonCreds, or BBS ever become requestable over the harmonized protocol is a design and political choice that has not been made.

The governance question that could undo it. Can two bodies ratify and maintain one specification without it forking back into two? The dual-adoption Working Procedures are engineered to make that possible ^[23], but no charter can guarantee it. This is an inferred risk, not a documented event: no outcome exists yet for a working group that has not held its first meeting.

None of this blocks you from acting today. In fact, waiting is the one clear mistake.

10. What to Build Today#

You do not get to wait for the harmonized protocol. A verifier shipping in 2026 needs a build that is correct now and forward-compatible later, and the good news is that the two goals point the same way.

The core decision is to build a format-agnostic verifier that accepts both mdoc and SD-JWT VC. The EUDI ARF mandates both as baseline, so "pick one" is not a compliant option for anyone serving the European market ^[3]. Concretely, that means dispatching on the presented credential rather than assuming a single format.

// A both-formats verifier detects the presented credential and routes it.
// mdoc is CBOR/COSE (binary); SD-JWT VC is the "~"-delimited JSON/JWS form.
function detectFormat(presented) {
if (typeof presented !== "string") return "mdoc";     // CBOR bytes, not text
if (presented.includes("~")) return "sd-jwt-vc";      // JWT ~ Disclosure ~ ... ~ KB-JWT
return "unknown";
}

function verify(presented) {
switch (detectFormat(presented)) {
  case "mdoc":
    return "route to CBOR/COSE path: check MSO issuer signature and device key";
  case "sd-jwt-vc":
    return "route to JSON/JWS path: verify issuer JWT, match _sd digests, check optional KB-JWT";
  default:
    return "reject: unrecognized credential format";
}
}

console.log(verify("eyJhbGci...~WyJzYWx0Iiwi...~"));   // SD-JWT VC
console.log(verify(new Uint8Array([0xa3, 0x01])));      // mdoc (CBOR bytes)

Underneath that dispatch, implement against OID4VP 1.0 Final plus HAIP 1.0 for the web side ^{[14] [16]}, and ISO/IEC 18013-5 and TS 18013-7 for proximity and online mdoc ^[18].

"Build on HAIP" has a concrete meaning, worth stating as a checklist rather than a slogan. Sign your Authorization Requests as JAR objects delivered by request_uri, identified by an x509_hash verifier certificate that is not self-signed. Require response encryption using JWE ECDH-ES over P-256 with A256GCM, realized as direct_post.jwt on redirects or dc_api.jwt in the browser, with a fresh ephemeral encryption key per request.

Drive the request with DCQL, and support the aki trusted_authorities query so ISO and web trust roots travel together. Advertise the mso_mdoc and dc+sd-jwt format identifiers, and always require a Key Binding JWT for a key-bound SD-JWT VC ^{[16] [9]}. Invoke through the W3C Digital Credentials API where it is available, and keep custom URL schemes as a fallback ^[24].

The query is where the thesis becomes one line of code. DCQL lets a verifier ask for a claim, not a format, and a Credential Set expresses "accept either" so one request covers both wallets.

// DCQL (dcql_query): one mdoc query + one SD-JWT VC query, tied by an
// "any-of" credential set so the verifier accepts whichever the holder has.
const dcql_query = {
credentials: [
  { id: "age_mdoc",  format: "mso_mdoc",
    meta:   { doctype_value: "org.iso.18013.5.1.mDL" },
    claims: [{ path: ["org.iso.18013.5.1", "age_over_18"] }] },   // [namespace, element]
  { id: "age_sdjwt", format: "dc+sd-jwt",
    meta:   { vct_values: ["urn:eudi:pid:1"] },
    claims: [{ path: ["age_over_18"] }] }                          // JSON path pointer
],
// options is the any-of operator: satisfy age_mdoc OR age_sdjwt, not both.
credential_sets: [
  { options: [ ["age_mdoc"], ["age_sdjwt"] ], required: true }
]
};
console.log(JSON.stringify(dcql_query, null, 2));

That single query is the response-side dispatcher's twin: one asks for either format, the other routes whichever comes back. Together they are the whole thesis, expressed twice in about forty lines.

A few implementation pitfalls carry real cost. Never re-canonicalize SD-JWT Disclosures: RFC 9901 deliberately uses source-string hardening, so you must hash the base64url string exactly as transmitted, and a verifier that re-serializes before hashing will get digest mismatches ^[11]. Decide Key Binding by policy, not by presence: whether a Key Binding JWT is required must not be inferred from whether one was supplied ^[11].

Ignore any _sd digest with no matching Disclosure, and reject any Disclosure that matches no digest ^[11]. Prefer delivering large OID4VP requests by reference through request_uri rather than stuffing a full request object into a QR code ^[14]. And budget for two toolchains: a both-formats verifier needs CBOR/COSE libraries for mdoc and JWT/JSON/base64 libraries for SD-JWT VC.

What not to do is just as short: do not bet on one format winning, do not conflate the acronyms, and do not block production waiting for the harmonized protocol to ship. Build for both today, and the harmonized protocol becomes an upgrade, not a rewrite.

One Protocol, Two Formats, by Design#

Go back to the bar in Marseille. Two phones, two credentials, one over-18 check, and a verifier forced to speak two languages. The mistake almost everyone makes is to see that scene as a format war and wait for a winner. It never was a format war. The tax the verifier pays lives one layer down, in the presentation protocol, in the fact that mdoc arrived fused to Device Request/Device Response and SD-JWT VC arrived fused to OID4VP.

Separate those layers and the whole problem dissolves in the right place. A single harmonized Digital Credentials Request Protocol, built jointly by ISO and the OpenID Foundation and adoptable by both, can carry either credential without either standards body surrendering ^[1]. That is what DCHP is for, and its first meeting is 29 June 2026.

"One Credential Presentation" means one protocol, not one format. The wire can converge; the credentials do not have to.

The limits are as important as the promise. Harmonization can unify the wire, but it cannot merge CBOR/COSE and JSON/JWS into one format, and it cannot move a credential from linkable to unlinkable, because both baseline formats re-present a stable issuer signature by construction ^[11]. The EUDI framework mandates both formats precisely because each owns a domain the other does not ^[3]. So two formats surviving is not a loose end for a future working group to tidy up. It is the correct design, and recognizing that is exactly what let the protocol converge without a war.

Someday the bar's verifier will speak one protocol. It will still, happily, accept both credentials.