W3C VC、SD-JWT VC、mdocの違いと使い分け。同じ修了証で比べてみる

ZenChAIne·2026年10月6日

DIDVCSD-JWTmdocデジタルアイデンティティ

はじめに

研修の修了証をスマホで持ち歩き、転職先へ提示する。証明が本物かはシステムで確かめられ、採用に不要な情報まで相手に渡さずに済む。 DID/VCの説明で描いてきた利用場面だが、作ろうとすると「どの形式の証明を発行するか」という選択が待っている。

代表的な候補が、W3C VC、SD-JWT VC、ISO mdocだ。前回の技術仕様編では全体像を紹介した。今回は同じ修了証を例に、保存するデータと、相手が検証する処理を比べていく。

W3C VCは証明のデータモデルを中心とする規格群、SD-JWT VCはSD-JWTを使ってデジタル証明を表す仕様、mdocはモバイル文書の仕組みである。同じ粒度のファイル形式が三つ並んでいるわけではない。選ぶ際には、形式に加えて、署名方式、受け渡しの手順、受け入れる発行者の条件を合わせる。

仕様の確認日は2026年10月5日。以下の修了証は架空の教材であり、JSONなどは構造の説明用に示す。製品間の接続試験を行った結果ではない。

なぜ、証明に複数の規格があるのか？

デジタル証明には、データの意味を共通にする仕事、改ざんを検出する仕事、スマホから相手へ渡す仕事がある。標準化団体ごとに出発点が異なり、すべてを一つの文書で決めてきたわけではない。

W3C（World Wide Web Consortium）はWebの標準を作る団体で、VC Data Modelでは「誰が、誰について、何を証明するのか」を表す共通モデルを定める。 IETF（Internet Engineering Task Force）はHTTPやTLSなどのインターネット技術を標準化する技術コミュニティで、JSONのデータを署名付きで扱うJWTや、そこから一部の項目を提示するSD-JWTを策定してきた。 ISOとIECは国際標準化団体で、共同規格のISO/IEC 18013-5はモバイル運転免許証の仕組みを扱っている。

この違いから、W3C VCを「Web用」、mdocを「政府用」と用途で固定してしまうのは早い。実際に採用できるかは、証明を受け取るウォレットや提示先が扱う文書種別、検証の条件によって決まる。民間の研修会社でもmdocの構造を使う設計は考えられるが、その独自の修了証を市販のウォレットが受け入れるかは別途確認する必要がある。

3つの規格の違い

観点	W3C VC	IETF SD-JWT VC	ISO mdoc
中心となる仕様	VC Data Modelと保護方式の仕様	SD-JWTと資格情報の型や処理の規則	モバイル文書のデータと認証の仕組み
内容の表し方	`issuer`、`credentialSubject`、`type`など	`iss`、`vct`と個々の属性	`docType`、名前空間、データ要素
符号化と署名	JSON-LDを扱うモデルにData IntegrityやJOSE/COSEなどを組み合わせる	JSONの情報を署名付きJWTと開示情報で扱う	CBORのデータとCOSEによる署名などを使う
一部の項目だけの提示	採用する保護方式による	発行時に選択可能にした項目を開示する	発行者が署名した情報と照合できる単位で要素を選ぶ
提示する側の鍵の確認	採用する提示方式と運用で決める	Key Bindingを要求する構成を選べる	文書に関連付けた端末鍵による認証がある

「W3C VC」という名前だけでは、署名や選択的開示の方式は決まらない。 ここを一つの完成した形式として比較すると、「W3C VCにはできないがSD-JWT VCにはできる」といった説明を誤りやすい。表はW3Cのデータモデル、IETFのSD-JWT VC仕様、ISOの公開概要を起点に整理した。

同じ修了証を、どう表すのか？

架空の研修会社が、受講者の山田花子に安全研修の修了証を発行する。採用企業は「認めている研修会社のSEC-101を修了した本人か」を知りたいが、受講者のメールアドレスは必要としていない。

項目	教材の値	採用企業へ提示するか
研修コード	SEC-101	提示する
修了日	2026-09-30	提示する
氏名	山田花子	今回は本人照合のために提示する
メールアドレス	hanako@example.com	提示しない

実サービスでは、そもそも証明にメールアドレスを入れる必要があるかも検討すべきだが、今回は選択的開示を説明するため、修了証に含まれているという前提で話を進める。どの方式でも、発行者名、有効期間、署名などの検証に必要な情報まで、すべて隠れるわけではない。

W3C VCでは、属性の意味と保護方式を決める

W3Cのモデルでは、発行者をissuer、証明の対象となる人や物の属性をcredentialSubjectに置く。 @contextは、項目名がどの意味を指すかを定めるための情報だ。独自の研修コードを追加するなら、項目の意味も参加者の間で共有する。

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": "山田花子",
    "courseId": "SEC-101",
    "completedOn": "2026-09-30",
    "email": "hanako@example.com"
  }
}

このJSONは、修了証に何を書くかを示したものだ。これだけでは、誰かが研修コードや氏名を書き換えても、受け取った企業は気付けない。そこで、発行した研修会社がデータに電子署名を付け、受け取った側が「この発行者が署名した内容から変わっていないか」を確かめられるようにする。 W3C VCのデータモデルで内容の書き方を決めたうえで、それを検証するための仕組みを組み合わせるわけだ。

その仕組みの一つが、W3CのData Integrityである。電子署名などの検証用の情報をデータに添え、その作り方と確かめ方を定めている。ただし、Data Integrityという名前だけで、使う暗号方式や一部の項目を伏せられるかまで決まるわけではない。

修了証全体に通常の電子署名を付けた場合、受講者がメールアドレスを削ると、署名したときの内容と変わってしまう。メールアドレスを伏せながら修了の事実を示すには、項目を伏せても残りの内容を検証できる「選択的開示」に対応した方式を、発行時から使う必要がある。 Data Integrityには、この選択的開示に対応する方式も用意されている。つまり、「W3C VCでは一部の項目を隠せない」のではなく、組み合わせる方式によってできることが変わる。

また、W3C VCの内容を、次に説明するSD-JWTの仕組みで保護する方法もある。 W3C VCとSD-JWTは組み合わせて使えるが、それだけでIETFの「SD-JWT VC」と同じ形式になるわけではない。同じ署名の仕組みを使っても、証明の項目名や構造に違いがあるためだ。

SD-JWT VCでは、署名する情報と開示する情報を分ける

SD-JWT VCは、JSONの属性をJWTの仕組みで扱い、必要に応じて一部の属性だけを開示する。 JWT（JSON Web Token）は属性情報を表す形式で、この用途では発行者が署名したデータを使う。 SD-JWTのSDはSelective Disclosure、つまり選択的開示を指す。

発行者は、個別に開示できる属性について、ランダムな値、項目名、値をまとめた開示情報を作る。その開示情報からハッシュを計算し、署名対象に入れる。ハッシュは、受け取ったデータが元のデータと一致するかを照合するための値だ。

説明のために、発行前の内容を並べると次のようになる。 vctは修了証などの種類を識別する項目で、W3Cのtypeや@contextと同じ構造ではない。

json

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

これは加工前の入力例であり、全項目をこのまま署名付きJWTに入れると全項目が見える。個別開示する項目は、発行時に開示情報へ移し、そのハッシュを_sdなどへ入れてから署名する。採用企業へ提示するとき、ウォレットは氏名、研修コード、修了日の開示情報を渡し、メールアドレスの開示情報は渡さない。

検証者は、発行者の署名を確かめ、受け取った開示情報のハッシュを再計算して一致を調べる。開示情報は復号用の鍵ではなく、示したい属性そのものを含むデータである。 Base64urlで符号化していても暗号化ではないため、受け取った相手は内容を読める。仕組みはRFC 9901に定義されている。

SD-JWTとSD-JWT VCは、仕様の進み具合も分けて見る必要がある。 SD-JWTはRFC 9901として公開されているが、2026年10月5日に確認したSD-JWT VCはdraft-19であり、まだ草案だ。同じSDKでも、どの草案を対象にしているかを記録して接続を確かめる。

mdocでは、文書種別と名前空間の中に項目を置く

mdocはmobile documentの略で、ISO/IEC 18013-5のモバイル文書の構造を使う。モバイル運転免許証はmDLと呼ばれ、mdocを使う代表的な文書だ。データを短く符号化するCBORと、CBORの署名などを扱うCOSEを利用する。

修了証をmdocとして設計するなら、文書の種類を表すdocTypeと、項目をまとめる名前空間を決める。名前空間は、たとえば別々の制度が同じnameという項目名を使っても、どの制度の項目か区別するための単位だ。次は実際のCBORデータではなく、教材用の構造図である。

text

文書種別: org.example.training.completion
名前空間: org.example.training.1
  name: 山田花子
  course_id: SEC-101
  completed_on: 2026-09-30
  email: hanako@example.com
 
発行者が署名して保護する情報:
  データ要素ごとのハッシュ
  文書種別、有効期間、端末の公開鍵など

発行者が保護する情報をまとめた構造をMSO（Mobile Security Object）と呼ぶ。ウォレットは必要なデータ要素を選んで送り、検証者はそのハッシュをMSO内の値と照合する。 Multipazの公開API資料でも、文書種別、要素のハッシュ、端末鍵、有効期間という構造を確認できる。

発行者の署名を確認する際には電子証明書も使う。たとえばGOV.UK Walletの発行者向け資料は、発行者の認証局と文書署名用の証明書を用意する手順を説明している。検証者は署名が計算上正しいかに加え、その証明書の信頼元を受け入れてよいか判断する。

ここまで説明したのは、mdocの形式で修了証のデータを作る方法だ。実際に使うには、研修会社と採用会社で修了証の項目や意味、署名の検証方法を合わせ、受講者のウォレットもその修了証を受け取って提示できる必要がある。

選択的開示で、何が隠れて何が残るのか？

どの方式を使う場合も、選択的開示と匿名性は分けて考える。メールアドレスを渡さなくても、氏名や同じ証明を識別できる情報を毎回渡していれば、利用履歴を結び付けられる可能性がある。

普通のSD-JWTでは、同じ発行者署名付きJWTを複数回提示することが、その提示同士を関連付ける手がかりになる。 mdocも、同じ発行者署名や端末公開鍵などを繰り返し提示する構成なら、相手が関連を見つけ得る。発行単位や利用回数、採用する暗号方式まで含めて設計する必要があり、「項目を隠せたから追跡されない」とは言えない。

もう一つ、項目を選ぶことと、計算結果だけを証明することにも違いがある。生年月日の項目を渡せば、相手には誕生日まで伝わる。「18歳以上」だけを伝えるなら、発行者がその真偽を表す項目を発行する方法や、条件を証明する別の仕組みを検討する。

この修了証でも同じだ。採用企業に氏名が不要で、認められた研修の修了だけを確認できればよいなら、必要な項目を減らせるかもしれない。ただし、研修を修了した人と応募者をどう照合するかは、その設計と一緒に決める必要がある。

証明をコピーした別人の提示を、どう防ぐのか？

発行者の署名は、証明が発行後に変わっていないかを確認するために使う。そのファイルを今持っている人が、修了した受講者本人かどうかまで自動で分かるわけではない。

SD-JWTではKey Bindingという方式を使える。証明に保有者の公開鍵を関連付け、提示するときに対応する秘密鍵で追加のJWTを署名する。検証者は宛先、今回の要求を識別するnonce、提示内容のハッシュなどを確かめ、古い提示の使い回しを拒否する。

これは仕様に方法があるだけで、すべてのSD-JWTの提示で自動的に強制されるわけではない。修了証をコピーした人に使わせたくないなら、発行者、ウォレット、検証者の間でKey Bindingを使う条件を合わせる。鍵を操作できることと、現実の本人確認を済ませたことも区別する。

mdocには、MSOに関連付けた端末鍵で、今回の通信に対応する応答を認証する仕組みがある。 W3C VCでも、採用する提示方式で保有者の確認を設計する。端末ロック、鍵の保管、紛失時の再発行は製品と運用の仕事であり、形式名を選ぶだけで済む部分ではない。

ウォレットへ渡す手順は、形式とは別なのか？

証明をウォレットへ発行するOpenID4VCIと、ウォレットが相手へ提示するOpenID4VPは、複数の証明形式を扱う。 mdocをOpenID4VPで送っても、データがW3C VCへ変換されるわけではない。仕様を組み合わせて、一連の受け渡しを作る関係である。

OpenID4VCI 1.0とOpenID4VP 1.0では、形式ごとにパラメーターや処理が定められている。接続時には、データ形式に加えて、発行と提示の仕様の版、要求する属性、利用する暗号方式も合意する。

スマホとブラウザの接点にも別の仕組みがある。 AppleのWeb向け解説やGoogle Walletのオンライン提示資料は、mdocをWeb上で提示する流れを紹介している。 mdocは、スマホを読み取り機にかざす場面だけに使うものではない。

複数形式を扱えるウォレットも、異なる形式を無条件に変換しているとは限らない。 SD-JWT VCをmdocへ作り直せば、署名対象の構造が変わるため、元の署名をそのまま移すことはできない。誰が変換後の内容に責任を持って署名するかを決める必要があり、元の発行者が複数形式を発行する設計とは区別したい。

修了証サービスなら、どこから選べばよいのか？

最初に決めたいのは、受講者が使うウォレットと、採用企業が受け入れる証明の条件だ。発行システムを作りやすい形式だけで選ぶと、発行はできても提示先が読めない修了証になってしまう。

状況	比較の始め方
相手がW3Cのデータモデルと特定の署名方式を指定している	指定された組み合わせで属性を表し、提示と検証ができるか確かめる
相手がSD-JWT VCを受け入れ、Web/API中心に構築する	対応する草案の版、開示項目、Key Binding、発行者の鍵の取得方法を合わせる
相手がmdocを受け入れ、モバイルでの提示を求める	文書種別、名前空間、電子証明書の信頼元、端末鍵、提示方法を合わせる
相手によって受け入れる形式が違う	共通の修了データから複数形式を発行し、取消や更新を同期する案を比較する

発行者の権限も、前回までの信頼レジストリの話につながる。研修会社が有効な署名を付けられることと、その研修会社の修了証を採用企業が資格として認めることは別だ。形式の検証と、どの発行者を認めるかという判断を両方設計する。

規格の多さと、持ち運べる証明との距離

私は、証明をサービスから独立して持ち運べるという思想に対して、実装の接続条件が細かく分かれていることが、普及を難しくしている理由の一つだと考えている。自己主権型アイデンティティ、SSIが目指すのは、特定のサービスに管理を任せきりにせず、利用者自身が必要な相手へ情報を渡せる状態だ。そのためには、渡す側と受け取る側が、項目の意味と検証の手順を共通に理解できなければならない。

ところが利用者から見ると、「VCに対応しています」と言われても、自分のスマホで受け取り、転職先へ提示できるかが分かりにくい。開発者も、形式、署名、仕様の版、信頼設定を組み合わせて確かめる必要がある。この負担は、利用者が証明を持つ利点を感じる前に、導入の費用として発生する。

もちろん、すべての違いをなくせば済む話でもない。近接提示とWeb上の手続きでは条件が異なり、制度ごとに必要な本人確認も違う。だから私は、規格の勝者を予想するより、まず修了証を使う参加者の間で接続できる構成を決め、その範囲と制約を公開する方が実務的だと考える。

これは筆者の見解であり、今回の比較から普及の原因を実証したものではない。次のOSS紹介記事では、この構成を作る道具として、walt.id、Procivis One、Credo、Multipazなどの開発元と役割を整理する。

Zenn で読む note で読む