DID/VCの技術仕様を整理する。DIDメソッド、証明形式、mdoc、OpenID【後編】

ZenChAIne·2026年9月25日

DIDVCEthereum

はじめに

「VCに対応したウォレット」と「VCを発行できるサービス」があれば、そのままつながるのだろうか。実装を始めると、証明の形式、署名方式、発行や提示の手順、対応する仕様の版まで確かめることになる。同じVCという言葉だけでは、接続の条件を決められない。

前編ではSSIの思想とDID/VCの背景を、中編では国内外の導入状況とmdocの利用を紹介した。後編では、研修会社が修了証を発行し、受講者がウォレットに保存し、転職先へ提示する例を使って、各仕様が何を担当するのかを整理する。仕様の確認日は2026年9月18日である。DIDメソッドの全体像と中編の採用事例は、同月24日に追加確認した。

この記事のポイント

DIDメソッドは、識別子を作り、鍵などの情報を参照・更新する方法を定める。証明書の形式や発行手順は、別に選ぶ。
W3C VC、IETFのSD-JWT VC、ISOのmdocには、それぞれデータや検証のルールがある。共通する目的があっても、同じ形式として読み込めるわけではない。
OpenID4VCIは発行、OpenID4VPは提示の手順を扱う。mdocもこれらと組み合わせられる。
受け入れる発行者、失効、鍵の変更、端末紛失、基盤の廃止まで含めて設計する。相互運用には、参加者が同じ仕様の組み合わせを選ぶ必要がある。

一枚の修了証に、どの仕様が関わるのか？

修了証を使うまでには、発行者を識別し、証明する内容をデータにし、利用者へ渡し、提示先で検証する処理がある。一つの仕様が全部を決める構成ではなく、処理ごとに共通ルールを組み合わせる。

決めること	修了証の例	関係する仕様・設計
識別と鍵の参照	どの研修会社が発行したか、どの鍵で検証するか	DID CoreとDIDメソッド、または証明形式が定める別の識別・鍵参照方式
証明する内容	誰が何の研修を修了したか	W3C VC Data Model、SD-JWT VC、mdocと用途ごとの項目定義
改ざんと署名の検証	受け取った修了証が発行時の内容か	採用する形式に対応した署名・検証方式
発行	研修会社から受講者のウォレットへ渡す	OpenID4VCIなど
提示	採用企業の要求に応じて受講者が示す	OpenID4VPなど
業務で受け入れる条件	どの研修会社、資格、有効期間を認めるか	発行者の審査、信頼リスト、接続先との運用合意

この表は、すべての行でDIDやブロックチェーンを使うという設計ではない。たとえばmdocでは発行者の電子証明書を使う構成があり、DIDで鍵を探す必要がない。先に受け入れ先の要件を確かめると、必要な組み合わせを絞りやすい。

DIDには、作り方や公開鍵の参照方法が異なる、多数のDIDメソッドがある。 2026年9月24日に確認したW3Cのメソッド一覧には、200以上のメソッドが掲載されている。 did:web:example.comなら、didが共通の接頭辞、webがメソッド名、example.comがその方式で使う識別情報だ。どのメソッドを使うかによって、検証に必要な公開鍵などをどこから取得するのかが変わる。

W3CのDID Coreが定めているのは、この共通の書式や、公開鍵などを記述するDID Documentのデータモデル、メソッドが満たすべき要件である。個々のメソッドは、企業や開発コミュニティなどが、それぞれの基盤や用途に合わせて策定している。すべてをW3Cが作ったわけではなく、一覧への掲載もW3Cによる推奨や品質保証を意味しない。共通の仕様があり、その具体的な実現方法には多くの選択肢がある、という関係だ。

中編で紹介した取り組みは、どのメソッドを使うのか？

導入事例を見ると、同じ仕組みの中でも発行者と利用者でメソッドを使い分ける場合がある。また、デジタル証明を使う事例のすべてがDIDを前提にしているわけではない。中編で取り上げた事例を、公式資料で確認できた範囲で対応させると、次のようになる。

中編の取り組み	確認できたメソッドや検証の仕組み	資料から分かる範囲
OpenCerts v3（シンガポール）	発行者に`did:web`	公式の移行ガイドで明記。発行機関のドメインでDID Documentを公開する。旧OpenAttestation形式まで同じ方式だったという意味ではない
EBSI（欧州）	法人に`did:ebsi`、個人に`did:key`	公式のVC説明で区別。法人のDIDは登録簿で管理し、個人のDIDは公開鍵から導く
EUDI Wallet（EU）	本人識別情報などの検証に電子証明書（X.509）を用いる	アーキテクチャ文書では、本人識別情報や適格属性証明などにX.509を用い、非適格属性証明には別の信頼モデルも認める。EBSIのメソッドをEU全体の採用方式とは扱えない
カリフォルニア州のモバイル運転免許証	mdocの発行者を電子証明書で検証	DMVの公式FAQは、発行元の信頼を確かめるIACAルート証明書を説明。DIDメソッド名で分類する方式とは異なる
日本のTrusted Web	構想全体として一つのメソッドに対応するものではない	デジタル庁の説明は、データのやり取りと検証、ガバナンスを扱う。実装を調べる際は個々の実証や製品の資料を確認する
マイナンバーカードを活用したチケット実証	確認した公表資料ではメソッドを特定できない	デジタル庁の発表と添付資料は本人確認結果のVC利用を説明しているが、具体的なメソッド名は確認できなかった
GビズIDと接続した法人・製造情報の実証	確認した公表資料ではメソッドを特定できない	NTTデータグループの実証報告書にはDID/VCの利用が記載されているが、具体的なメソッド名は確認できなかった

例えばEBSIでは、法人を公開された登録簿で識別するdid:ebsiと、公開鍵の情報を識別子に含めるdid:keyを使い分けている。個人のdid:keyはEBSIのDID登録簿へ登録しない。同じサービスの発行者と保有者が、必ず同じメソッドを使うわけではないことが分かる。

この後は、前編のEthereum上の取り組みにつながるdid:ethr、EBSIの個人向けDIDに使われるdid:key、OpenCertsの発行者にも使われるdid:webを比べる。 Ethereumのレジストリ、公開鍵そのもの、Webのドメインという三つの起点から、更新の方法と管理上の責任の違いを見ていこう。

メソッド	識別・参照の起点	更新を考えるときの要点
`did:ethr`	Ethereumのアドレスとレジストリ	管理者や委任先などの更新を、チェーンの記録から解決する
`did:key`	識別子に含まれる公開鍵の情報	同じDIDのまま鍵を更新したり、メソッドの機能で無効化したりできない。鍵を替えるとDIDも変わる
`did:web`	WebのドメインとHTTPSで配布する文書	文書を更新できるが、ドメインや配信基盤の管理が継続して必要

did:ethr：アドレスを出発点に、制御を更新する

did:ethrは、ERC-1056のレジストリを使うDIDメソッドだ。アドレスを起点にしながら、管理者の変更や委任などを扱える。メソッド仕様では、レジストリのイベントを使ってDID Documentを構成する。

利用する側には、ネットワークへのアクセスや、履歴を正しく解決する処理が必要になる。過去に発行された証明を検証したいなら、現在の鍵だけを見るのか、発行時点の状態も扱うのかを決める必要がある。DIDの仕様名だけでは、アプリケーションの検証方針までは決まらない。

did:key：公開鍵からDIDを作る

did:keyは、公開鍵の種類と値を文字列に符号化してDIDに含める方式である。メソッド仕様に従えば、その識別子から公開鍵を取り出し、DID Documentを組み立てられる。この処理にはブロックチェーンへの登録も、Webサーバーへの問い合わせも必要ない。中編で紹介したEBSIでは、個人のDIDにこの方式を使っている。

公開鍵からDIDが決まるため、鍵を替えるとDIDも変わる。同じDIDを保ったまま鍵を更新する機能や、そのDIDを無効化する機能は、メソッド自体にはない。秘密鍵を紛失したり漏えいしたりした場合は、新しいDIDへの切り替えと、それに結び付いた証明の再発行などをサービス側で設計する必要がある。

なお、DIDを無効化できないことと、そのDIDに関係するVCを失効できないことは別の話だ。VCの失効をどう扱うかは、後述する証明の状態確認の仕組みで決める。

did:web：企業のWeb運用を使う

did:webは、ドメインに対応するHTTPSの場所からDID Documentを取得する方式だ。仕様は、DIDから文書の取得先を導く方法を定めている。既存のWeb運用を使えるため、組織が発行者として使う場面では検討しやすい。

この方式では、ドメインや配信サーバーを管理し続ける必要がある。ドメインを失ったとき、企業の統合でURLが変わったとき、署名鍵を更新した後も過去の証明を検証したいときに、何を維持するかを決めなければならない。「ブロックチェーンを使わない」ことと「管理不要」は同じではない。

W3C VC、SD-JWT VC、mdocは、何を定めているのか？

DIDメソッドと同じように、デジタル証明を表す仕様にも複数の選択肢がある。 W3C、IETF、ISO/IECなどが、それぞれの用途や技術を背景に標準化を進めており、現在も複数の系統が並立している。あらゆる用途で「これを選べばよい」と言える、唯一の形式に統一されたわけではない。利用する制度やサービスで採用形式が指定される場合もあるため、実装者は用途と接続先に合わせて選ぶ必要がある。

ここでは、代表的な三つの系統として、W3C VC、IETFのSD-JWT VC、ISOのmdocを紹介する。中編のOpenCerts、EUDI Wallet、スマートフォンの身分証を理解する際にも登場する仕様だ。証明を提示する手順を定めたOpenID4VP 1.0も、この三系統をそれぞれ扱っている。複数の形式を扱えるウォレットや検証サービスを作る、という選択肢もある。

ただし、三つは同じ範囲を定めた仕様ではない。 W3C VCは証明の基本的なデータモデルを定め、署名方式などを別の仕様と組み合わせる。 SD-JWT VCとmdocを比較するときも、情報の表し方に加え、署名や保有者の確認方法まで見ていこう。

W3C VC：証明の基本モデルと、署名の方式を組み合わせる

VC Data Model 2.0では、発行者をissuer、証明対象についての情報をcredentialSubjectなどの項目で表す。@contextは用語の意味を解釈するために使い、typeは証明の種類を示す。有効期間や状態情報を参照する項目もあり、用途に応じて必要な条件を決める。

研修の修了証なら、研修名や修了日を何という項目で表すか、その値を相手も同じ意味で読めるかを合わせる必要がある。基本モデルは、あらゆる業界の資格名や認定基準まで定めるものではない。

証明をどう署名して検証するかには、別の仕様がある。Data Integrity 1.0は、署名などの証明情報を表すproofの構造と、検証のための共通の処理を定める。具体的な暗号処理はcryptosuiteと呼ぶ仕様で選ぶため、「Data Integrity対応」でも、相手と同じ方式を扱えるかの確認が要る。

Securing Verifiable Credentials using JOSE and COSEは、JSONやCBORのデータを署名・暗号化する技術をW3C VCに適用する方法を定める。JSONはテキストで構造を表す形式、CBORはデータをバイナリで表す形式である。W3C VCを選ぶことと、署名の形式を決めることは、別々に必要な判断だ。

SD-JWT VC：開示する項目を選べる資格情報

IETFのSD-JWT（RFC 9901）は、JSON Web Tokenという署名付きデータの仕組みに、項目ごとの選択的開示を加える。発行者は隠せる項目をランダム値と組み合わせたハッシュとして署名対象に含め、保有者は見せたい項目を復元・検証する情報だけを相手へ渡す。利用者が署名済みの本文を自由に書き換える方式ではない。

SD-JWT VCは、SD-JWTをデジタル資格情報として使うための形式と処理を定める。たとえばvctで資格情報の種類を示し、発行者、鍵、型に関する情報をどう扱うかを規定する。2026年9月18日の確認時点ではInternet-Draftであり、基礎となるSD-JWTがRFCになったこととは策定段階が異なる。

名前にVCが含まれていても、W3C VC Data Modelに従うことを自動で意味しない。逆にW3Cの仕様側にもSD-JWTを使う保護方式があるため、「SD-JWTという単語があるからIETFのSD-JWT VC形式だ」とも判断できない。相手が要求するデータモデルと、そのデータを署名・提示する方式を確認したい。

mdoc：モバイル文書を、発行者と端末の両方から検証する

mdocは、ISO/IEC 18013-5などに基づくモバイル文書の形式だ。中編で紹介したモバイル運転免許証（mDL）は、その代表的な用途である。データ項目を名前空間ごとにまとめ、CBORやCOSEを使う構成を取る。

発行者の署名で保護するデータには、Mobile Security Object（MSO）と呼ぶ構造がある。GOV.UK Walletの実装文書は、MSOの署名を検証するために、発行用の電子証明書と、その発行元へさかのぼる証明書チェーンを使う構成を説明している。何を信頼の起点とするかは、受け入れる側が決める必要がある。

Googleの検証手順では、発行者の証明書とMSOの署名、提示された項目のハッシュに加え、端末側の署名も確認する。要求ごとの値などを含む通信の記録と提示を関連付け、発行者が署名したデータを読み取るだけで検証を終えない構成である。

mdocには項目を選んで提示する仕組みがあるが、必要な情報の選択画面や、鍵の保存、機種変更の手続きまで、形式名だけで同じになるわけではない。ISO/IEC 18013-5の公開概要でも、保有者の同意を得る方法やデータ・秘密鍵の保管要件は同文書の範囲外とされている。仕様とウォレットの製品設計を分けて読む必要がある。

三つの形式を比較するときの入口

形式・モデル	読み始める仕様	合わせて確認すること
W3C VC	VC Data Model 2.0	項目の意味、Data IntegrityやJOSE/COSEなどの保護方式
SD-JWT VC	IETFのSD-JWT VC仕様とRFC 9901	資格情報の型、開示可能な項目、保有者の鍵との結び付け、仕様の版
ISO mdoc	ISO/IEC 18013-5など	文書種別、項目の名前空間、発行者の証明書、端末側の検証

どれを選ぶかは、提示先が受け入れる形式から考える。研修会社の都合で形式を選んでも、受講者のウォレットや採用企業が読めなければ、別の書類を求められることになる。

OpenID4VCIとOpenID4VPは、どう使うのか？

異なるサービスの間でIDに関する情報を扱う共通仕様を作る団体に、OpenID Foundationがある。ここでは、証明の発行と提示についても仕様を策定している。

OpenID for Verifiable Credential Issuance、略してOpenID4VCIは、発行者からウォレットへ証明を渡す手順を扱う。OpenID for Verifiable Presentations、略してOpenID4VPは、検証者が証明を求め、ウォレットが提示するための手順を扱う。発行仕様は2025年9月にFinal承認、提示仕様1.0は2025年7月のFinal文書として公開されている。

たとえば「VCのJSONを読み込める」実装でも、相手が指定する発行手順に対応していなければ、利用者は証明を受け取れない。データを解釈できることと、サービスとして受け渡せることは別の対応範囲である。

さらに、仕様の選択肢を絞り、実装同士でつながる条件を定める文書をプロファイルと呼ぶ。OpenID4VC High Assurance Interoperability Profile 1.0は、SD-JWT VCやISOのモバイル文書と、OpenIDの発行・提示手順を組み合わせる際の要件を定めている。すべての選択肢を実装するより、相手と同じ組み合わせを選ぶことが接続には必要だ。

修了証の発行から提示までを追う

OpenID4VCI 1.0では、ウォレットが発行者の提供する証明や接続先の情報を取得し、発行に必要な認可を得て、証明を要求する。利用者を認証して発行を認める流れや、発行のために事前に用意したコードを使う流れなどがある。研修を本当に修了したかは、研修会社が発行前に確認する。

転職先へ提示するときは、OpenID4VP 1.0で検証者が必要な証明や項目を要求し、ウォレットが対応する証明を返す。DCQLという問い合わせの形式を使い、求める資格情報や項目の条件を表せる。検証者は受け取った証明の形式に応じて署名などを確かめ、自社が受け入れる研修かどうかを判断する。

OpenID4VCIとOpenID4VPは複数の証明形式を扱い、mdocも対象になる。「OpenIDのVC」という独立した証明書形式が、W3C VCやmdocの隣に一つ増えるわけではない。証明の形式と受け渡しの手順を組み合わせる関係である。

ブラウザからウォレットを呼ぶ仕組みは、さらに別にある

Webサイトから端末の証明を要求する接点には、W3CのDigital Credentials APIがある。これはブラウザとウォレットなどの間を取り持つAPIであり、そのAPIを使っただけで証明がW3C VC形式になるわけではない。

Appleの2025年の説明では、このAPIからISO 18013-7の要求プロファイルを使ってmdocを提示する例がある。Googleのオンライン提示資料はOpenID4VP 1.0とmdocを組み合わせている。どちらもmdocに対応しているという情報に加え、接続する製品と版が、どの提示手順に対応するかを確かめたい。

選択的開示と、保有者の確認はどう違うのか？

選択的開示は、証明に含まれる項目のうち、提示する項目を選ぶ仕組みだ。たとえば住所と資格名を含む証明から、対応する方式で資格名だけを提示できれば、相手に住所を渡さずに済む。

開示する項目を選ぶ処理と、誕生日から「18歳以上」という条件を計算して証明する処理は異なる。SD-JWTでその項目を選んで示すなら、発行者が年齢条件を表す項目を発行するなどの設計が要る。計算結果だけを示す暗号方式や、提示のたびに同一人物だと結び付けられにくくする仕組みは、別途検討する対象だ。

開示する項目を減らせても、同じ識別子を繰り返し提示すれば、利用履歴を関連付けられることがある。状態確認の通信先に、いつどこで証明を使ったかが伝わる設計も考えられる。個人情報の項目数だけでなく、識別子と通信の流れも確認したい。

用途によっては、提示した人が証明に関連付けられた鍵を使えるかも、別に確かめる必要がある。保有者の鍵に証明を関連付け、その鍵を使えることを提示時に確かめる方式を、holder bindingと呼ぶ。SD-JWTでは対応する鍵による追加のJWTを使う方法があり、mdocには端末による認証の仕組みがある。

鍵を使えることだけでは現実の受講者と同一かは分からないため、発行時の本人確認や端末の認証も必要になる。盗んだデータの提示を防ぐ処理と、人の身元を確認する業務は、両方必要になる。

失効や鍵の変更は、どこで扱うのか？

署名が正しくても、証明を今使ってよいとは限らない。検証者は、証明の有効期間、必要な状態情報、発行者を受け入れる条件を確かめる。資格が取り消された場合と、発行用の鍵が漏えいした場合では、止める対象が違う。

W3Cには、複数の証明の状態をビット列のリストで表すBitstring Status Listという仕様がある。証明ごとに発行元へ問い合わせる形を避けやすくする設計だが、採用する形式や接続先が同じ状態確認の方式を使うかは確認が要る。

鍵を更新するときも、新しい鍵だけを配布すれば済むとは限らない。修了証を数年後にも検証するなら、過去の署名を検証する鍵や電子証明書をどう参照できるようにするかを決める。鍵の変更、漏えいによる失効、証明の再発行を一つの操作として扱わず、どの証明への影響を伝える必要があるかを整理したい。

接続確認では、正常な修了証だけでなく、期限切れ、取り消し済み、鍵が変わった後の古い証明、状態情報を取得できない場合も試す。通信が失敗した際に受付を止めるのか、確認を保留するのかは、用途ごとの運用条件になる。

Ethereumのウォレットでは、操作や復旧をどう扱うのか？

Ethereumを使う場合、利用者に秘密鍵の保管やネットワーク処理の手数料であるガス代の支払いをすべて任せると、サービスの導入が難しくなることがある。アカウント抽象化は、アカウントの認証や操作のルールをプログラムで扱いやすくするための取り組みだ。

ここで扱うウォレットは、Ethereumのアカウントを操作するためのものだ。資格証などを保管・提示するデジタルアイデンティティウォレットすべてに、ガス代や以下の仕組みが必要なわけではない。

ERC-4337は、アカウントの操作手順を変える

ERC-4337では、利用者の操作をUserOperationというデータとして受け取り、Bundlerと呼ぶ処理主体がチェーンへ送る。EntryPointというコントラクトを通じて、アカウントが操作を検証・実行する構成である。

この仕組みを使うと、アカウントの実装に応じて、複数の確認方法や操作のまとめ実行などを設計できる。Paymasterという仕組みを組み合わせれば、サービス側などが条件付きでガス代を負担することもできる。

利用者に代わって支払う主体が必要なため、事業者は利用回数、対象となる操作、不正利用への対処を決める必要がある。仕様に対応したというだけで、すべての操作が無料になる説明はできない。

鍵を復旧するための実装と運用

プログラムで認証や操作のルールを定めるスマートアカウントでは、別の端末や信頼する相手の承認などを使って、制御する鍵を変更する仕組みを設計できる。しかし、ERC-4337が特定の復旧方法をすべてのアカウントへ自動で追加するわけではない。

誰が復旧を承認できるか、承認者が乗っ取られたらどうするか、復旧を止められる期間を設けるか。これは製品ごとの設計になる。アカウントを取り戻せても、紛失したVCのデータが自動で戻るとは限らず、証明の再発行も別に扱う必要がある。

EIP-7702は、通常の外部所有アカウントにコードへの委任を設定する仕組みを導入した。委任は一つの取引の間だけで必ず消えるものではなく、設定を変更するまで残り得る。そのため、何のコードへ権限を渡し、どう解除するかまで利用者を守る設計が要る。

仕様が多いことは、普及を難しくしているのか？

実装者にとって難しいのは、仕様名の数だけでなく、どの組み合わせなら接続できるかを判断することだ。「VC対応」という製品説明から、証明形式、署名方式、発行・提示の手順、状態確認まで一致しているかは分からない。

修了証のサービスで考えてみよう。発行者とウォレットが同じデータ形式を扱えても、発行手順の版が違えば受け取れない。受け取れても、転職先のシステムが違う署名方式しか扱えなければ検証できない。技術上つながっても、研修名や資格の意味が相手と違えば、業務上の判断には使えない。

SSIが目指すのは、特定の巨大企業やサービスだけにIDや証明の管理を委ねず、利用者自身が主導権を持ち、必要な情報を自分の判断で相手に渡せるようにすることだ。DID/VCも、利用者が証明を保管し、必要な相手に提示するために使われている。ここでいう共有は、個人のデータを誰にでも公開することではない。利用者が選んだ相手へ、サービスの境界を越えて証明を持ち運べるということだ。

証明をサービス間で持ち運ぶには、渡す側と受け取る側が、データのレイアウトや項目の意味、受け渡しと検証の手順を共通に理解できなければならない。すべての用途を一つの形式に統一する必要はなくても、互いに扱える形式と手順についての合意は大前提になる。中央の事業者が全員の仕様を決める構成ではないからこそ、参加者同士で共有するルールが欠かせない。

ところが現状は、「DID/VC対応」と一括りにできないほど、実装に必要な細かな仕様や選択肢が分かれている。利用者がサービスを越えて証明を持ち運ぶことを目指しているのに、どのウォレットやサービスでも使える状態にはまだ届いていない。私には、この思想と実装の隔たりが、矛盾するかのようにも映る。

私は、共通に使える仕組みを目指しながら、そのための仕様の組み合わせや接続条件がまだ十分にそろっていない過渡期にあることが、普及を難しくしている理由の一つだと考えている。開発者の選定や接続確認の負担に加え、利用者も事業者も「この証明を持っていれば、どこで使えるのか」を見通しにくい。それでは、サービスから独立して証明を持つ利点も実感しにくい。

一方、すべての仕様が同じ目的で競合しているわけでもない。証明形式と提示手順は併用するものであり、複数の形式にも対象とする利用場面や既存基盤の違いがある。採用先の共通条件を決め、必要な選択肢を絞ることが接続の助けになる。

OpenID4VC High Assurance Interoperability Profile 1.0は、そのための取り組みの一つで、2025年12月にFinalとして公開された。SD-JWT VCやmdocとOpenIDの手順を組み合わせ、セキュリティやプライバシーに関する共通の要求を定めている。ただし、どの研修会社の証明を受け入れるかという業務上の判断まで代わりに決めるものではない。

標準化は、現在どこまで進んでいるのか？

DID/VCの基本的なデータモデルに加え、異なる製品同士で証明を発行・提示するための仕様も整ってきた。採用する際には、仕様ごとに正式版と策定中の版を確かめる必要がある。

時期	出来事	意味
2019年11月	VC Data Model 1.0がW3C勧告に	発行者・保有者・検証者による証明の基本モデルを標準化
2022年7月	DID Core 1.0がW3C勧告に	DIDの構文やDID Documentの共通モデルを標準化
2025年5月	VC Data Model 2.0がW3C勧告に	証明のデータモデルを更新
2025年7月・9月	OpenIDの提示・発行仕様がそれぞれFinalに	ウォレットとサービスの間の手順を共通化
2025年11月	SD-JWTがRFC 9901として公開	開示する項目を選べる署名付きデータの仕様を整備
2025年12月	OpenID4VCの相互運用プロファイル1.0がFinalに	SD-JWT VCやmdocと発行・提示手順の組み合わせを規定
2026年9月時点	DID 1.1、VC 2.1などの次版を検討中	勧告済みの版と、策定中の版が並行して存在

日付と策定段階は、VCの初期仕様の履歴、DIDの版一覧、VCの版一覧、OpenIDの提示仕様、発行仕様の承認発表、RFC 9901に基づく。

2026年9月17日時点で、DID 1.1はCandidate Recommendation Snapshot、VC 2.1はWorking Draftである。新しい番号が付いた文書を見つけても、すでに正式な勧告に置き換わったとは限らない。採用時には、実装がどの版を対象にしているかまで見る必要がある。