W3C VC, SD-JWT VC, and mdoc: Comparing the Same Training Credential

ZenChAIne·October 6, 2026

DIDVCSD-JWTmdocDigital Identity

Introduction

A learner carries a training certificate in a wallet and presents it to a prospective employer. The employer checks who issued it and what it says. The learner can avoid sharing information the employer does not need.

That is a familiar digital credential scenario. Building it requires a more specific decision: what should the training provider issue? W3C VC, SD-JWT VC, and ISO mdoc are three prominent names a team will encounter.

These names do not describe three interchangeable file formats. W3C VC centers on a data model and associated securing mechanisms. SD-JWT VC defines digital credentials using SD-JWT. ISO mdoc provides a mobile document structure and authentication mechanisms. A deployment must also agree on exchange protocols and issuer acceptance rules.

This article compares them using a fictional training certificate. Sources were checked on October 5, 2026. The structures below are explanatory examples, not credentials issued by a tested product integration.

Why are there several standards?

Digital credentials require several kinds of agreement: how to describe a claim, how to detect changes to it, and how to exchange it. Standards organizations approach those tasks from different starting points.

The World Wide Web Consortium, W3C, develops Web standards. Its Verifiable Credentials Data Model describes claims, issuers, holders, and verifiers. The Internet Engineering Task Force, IETF, standardizes Internet technologies, including the JWT and SD-JWT specifications. ISO and IEC are international standards organizations; their joint ISO/IEC 18013-5 standard addresses mobile driving licences.

Those origins do not impose a simple division between “Web credentials” and “government credentials.” A private training provider could design a credential using mdoc structures. Whether a particular wallet accepts that document type and issuer is a separate product and ecosystem question.

Question	W3C VC	IETF SD-JWT VC	ISO mdoc
What is the central specification about?	A credential data model, used with a securing mechanism	Rules for digital credentials using SD-JWT	Mobile document data and authentication
How is the content identified?	Properties such as `issuer`, `type`, and `credentialSubject`	`iss`, `vct`, and individual claims	`docType`, namespaces, and data elements
How is it encoded and protected?	A JSON-LD model with mechanisms such as Data Integrity or JOSE/COSE	Signed JWT data and Disclosures	CBOR data and mechanisms including COSE signatures
Can some attributes be withheld?	Depends on the chosen securing mechanism	Claims made selectively disclosable by the issuer can be withheld	Individual data elements can be selected
How is the presenting party checked?	Depends on the presentation mechanism and policy	A deployment can require Key Binding	Device authentication uses a key associated with the document

The comparison starts from the W3C data model, the IETF SD-JWT VC draft, and the ISO public overview. “Supports W3C VC” alone does not identify a signature or selective disclosure mechanism.

How would each represent the same certificate?

Suppose a fictional training provider certifies that Hanako Yamada completed course SEC-101 on September 30, 2026. The employer needs the learner's name, the course code, and the completion date. It does not need the email address included in this example credential.

Attribute	Example value	Disclose to this employer?
Course code	SEC-101	Yes
Completion date	2026-09-30	Yes
Name	Hanako Yamada	Yes, for this scenario's identity matching
Email	hanako@example.com	No

In a real service, whether the credential needs an email address at all is a design decision. For this article, we assume the training certificate includes one so that we can explain selective disclosure. Verification metadata, such as the issuer and validity information, does not necessarily disappear when personal attributes are withheld.

W3C VC: define the claims, then choose their protection

In the W3C model, issuer identifies the issuer and credentialSubject describes the subject. The @context establishes the meaning of terms. If participants introduce their own course code property, they need to agree on its meaning.

json

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    {
      "TrainingCompletionCredential": "https://training.example/vocab#TrainingCompletionCredential",
      "courseId": "https://training.example/vocab#courseId",
      "completedOn": "https://training.example/vocab#completedOn",
      "email": "https://schema.org/email"
    }
  ],
  "type": ["VerifiableCredential", "TrainingCompletionCredential"],
  "issuer": "https://training.example/issuers/1",
  "validFrom": "2026-10-01T00:00:00Z",
  "credentialSubject": {
    "name": "Hanako Yamada",
    "courseId": "SEC-101",
    "completedOn": "2026-09-30",
    "email": "hanako@example.com"
  }
}

This JSON describes what goes on the certificate. On its own, it would not let an employer detect someone changing the learner's name or course code. The training provider adds a digital signature so that a recipient can check whether the content matches what that issuer signed. The W3C data model defines how to express the content; a separate mechanism makes it verifiable.

One such mechanism is W3C Data Integrity. It defines how to attach verification information, such as a digital signature, to data and how to check it. The name alone does not specify which cryptographic method is used or whether some attributes can be withheld.

If an ordinary digital signature protects the entire certificate, deleting the email address changes the signed content. To withhold that address while still proving course completion, the issuer must use a method that lets a recipient verify the remaining claims. This is selective disclosure, and Data Integrity includes a method that supports it. Whether a W3C VC supports selective disclosure therefore depends on the mechanism chosen.

W3C credentials can also be protected using SD-JWT, which the next section explains. Combining them does not automatically produce the same format as an IETF SD-JWT VC: sharing a signing mechanism does not make their property names and data structures identical.

SD-JWT VC: separate signed digests from disclosed claims

SD-JWT VC uses the JWT ecosystem to express digital credentials. JWT stands for JSON Web Token; the issuer uses a signed token in this setting. Selective disclosure lets a holder choose among claims the issuer made separately disclosable.

Before that processing, our example content might look like this:

json

{
  "iss": "https://training.example",
  "vct": "https://training.example/types/completion",
  "name": "Hanako Yamada",
  "course_id": "SEC-101",
  "completed_on": "2026-09-30",
  "email": "hanako@example.com"
}

The vct identifies the credential type. This is an input example, not a selectively disclosable signed payload. Leaving every attribute in plaintext inside the signed JWT would expose every attribute.

For an individually disclosable object property, the issuer creates a Disclosure containing a random salt, a property name, and its value. It encodes that data and places its digest in the signed payload. The holder sends the signed JWT with only the Disclosures needed for a presentation. The verifier recomputes their digests and checks them against the signed values.

A Disclosure is data containing the claim, not a decryption key. Base64url encoding is not encryption. An employer receiving the email Disclosure can read the email address. These mechanisms are defined in RFC 9901.

SD-JWT and SD-JWT VC also have different specification statuses. SD-JWT is published as RFC 9901. The SD-JWT VC document checked for this article is draft-19. Integration records should identify both the specification and the revision an implementation targets.

mdoc: document types, namespaces, and authenticated elements

An mdoc is a mobile document using the structures of ISO/IEC 18013-5. A mobile driving licence, or mDL, is a prominent use of those structures. CBOR provides binary encoding, while COSE provides mechanisms including signatures.

A training credential design would need a document type and a namespace for its attributes. Namespaces distinguish properties belonging to different document definitions. The following is an explanatory sketch, not encoded CBOR or a registered training credential standard:

text

Document type: org.example.training.completion
Namespace: org.example.training.1
  name: Hanako Yamada
  course_id: SEC-101
  completed_on: 2026-09-30
  email: hanako@example.com
 
Issuer-authenticated information includes:
  digests of data elements
  document type, validity information, and device public key

The Mobile Security Object, MSO, contains information the issuer protects, including element digests and a device public key. The wallet selects elements to present; the verifier checks their digests against the authenticated values. The Multipaz MSO API documentation makes these structures visible in an implementation.

Issuer authentication also uses certificates. The GOV.UK Wallet issuer guidance describes an issuing authority certificate authority and document signing certificates. A verifier must establish trust in the relevant authority, as well as check the signature.

The example above describes how to structure a training certificate as an mdoc. In practice, the training provider and employer must agree on its fields, their meaning, and how signatures will be verified. The learner's wallet must also be able to receive and present that certificate.

Does selective disclosure make presentations anonymous?

Withholding an email address reduces disclosure. It does not necessarily prevent two presentations from being linked. Names, persistent identifiers, or repeated signed material can still give verifiers a way to recognize the same credential.

Ordinary SD-JWT presentations can reuse the same issuer-signed JWT. An mdoc configuration that repeatedly reveals the same issuer-authenticated material or device key can also allow correlation. Privacy design must consider issuance, reuse, and the selected cryptographic mechanisms, as well as the list of disclosed attributes.

Selective disclosure also differs from proving a condition about hidden data. Disclosing a birth date reveals the date. To reveal only “over 18,” a system can issue a dedicated age-threshold claim or use a separately supported predicate-proof mechanism. Selecting an attribute does not itself calculate and prove a hidden predicate.

For our training example, removing the name might be desirable if the employer only needs evidence of completion. But then the system still needs a way to establish that the applicant is the person entitled to use that credential. Those decisions belong together.

How do we stop someone presenting a copied certificate?

An issuer signature establishes integrity and origin. It does not, by itself, establish that the person holding the file completed the course.

SD-JWT provides optional Key Binding. The issuer associates the credential with a holder public key, and the holder signs a Key Binding JWT during presentation. The verifier checks the signature and transaction-specific values such as the audience, nonce, and hash of the presented SD-JWT and Disclosures.

The deployment must require and enforce this check where it is needed. A format supporting Key Binding does not mean every verifier automatically uses it. Possession of the key also remains distinct from the real-world identity checks used when issuing the credential.

mdoc device authentication uses the device key associated with the MSO and authenticates a response for the current interaction. W3C VC deployments choose suitable presentation and holder verification mechanisms. Device unlocking, key storage, lost-device handling, and reissuance still require product and operational decisions.

Are exchange protocols a separate choice?

OpenID4VCI handles credential issuance to wallets. OpenID4VP handles requesting and presenting credentials. They support multiple credential formats, with format-specific parameters and processing.

Sending an mdoc through OpenID4VP does not turn it into a W3C VC. Participants must agree on a format, supported algorithms, protocol versions, requested claims, and trust configuration.

mdoc is not restricted to proximity interactions. Apple's Web identity presentation session and Google Wallet's online acceptance documentation describe online presentation. Browser and wallet integration is another part of the configuration to confirm.

A wallet accepting several formats is also different from a converter between them. Converting an SD-JWT VC into an mdoc changes what is signed. The original signature cannot simply be transferred. Issuing several formats from the original issuer and having an intermediary sign a converted credential imply different responsibilities and trust relationships.

Where should a training provider start?

Start with the wallet learners will use and the employers that will accept the certificate. Choosing only the format most convenient for the issuer can produce credentials nobody at the destination can process.

Situation	What to verify first
The recipient requires a W3C model and a specific securing mechanism	The required vocabulary, protection mechanism, and presentation processing
The recipient accepts SD-JWT VC in a Web/API deployment	Draft revision, disclosure choices, Key Binding, and issuer key discovery
The recipient accepts mdoc and expects mobile presentation	Document type, namespaces, certificate trust, device keys, and presentation method
Recipients require different formats	Multiple issuance from shared business data, with coordinated updates and revocation

Issuer authority remains a separate requirement. Our trust registry article examines that distinction: being able to verify a training provider's signature is not the same as accepting its certificate as a qualification.

The gap between portability and integration work

My view is that fragmented integration requirements are one reason digital credentials remain difficult to adopt. Self-sovereign identity aims to give people control over information they can carry across service boundaries. That requires participants to share enough rules about meaning and verification to process what a person presents.

Yet “VC support” tells a learner very little about whether a certificate will work with the next employer. Engineers must reconcile formats, algorithms, revisions, and trust settings. Issuers pay for that integration work before users can experience the promised portability.

Different requirements do justify different mechanisms. A proximity identity check and an online training verification do not have identical constraints. Rather than predict one winning format, I would define a working configuration for the actual participants, test it, and publish its limits. This is an engineering judgment, not an empirical finding about adoption rates from the comparison above.

The next article will introduce OSS projects such as walt.id, Procivis One, Credo, and Multipaz: who develops them, which parts of the system they implement, and what evidence supports their use. Hands-on credential issuance follows that selection work.

FAQ

Does any of this require a blockchain?

No. W3C VC does not mandate DIDs, and SD-JWT VC and mdoc can also be deployed without a blockchain. Holding a credential independently of a service is a design objective; choosing a ledger is a separate technical decision.

Does a wallet supporting all three solve interoperability?

It helps expand the formats a holder can receive. The verifier must still support the selected securing mechanism and exchange protocol, understand the claims, and accept the issuer. Wallet format support alone does not prove interoperability across the system.

Can selective disclosure reveal only that someone is over 18?

Selecting and disclosing a birth-date claim reveals the date itself. A dedicated age-threshold claim or an additional proof mechanism is needed to disclose only the condition. The selected credential and verifier must support that design.

Summary

Compare the configuration that participants will actually use: the credential model, securing mechanism, selected attributes, holder or device authentication, and exchange protocols. For a training service, test a learner receiving a certificate, presenting the required information to an employer, and being refused when the credential no longer meets the agreed acceptance rules.

References

🇯🇵 日本語で読む