SD-JWT VC vs mdoc(ISO/IEC 18013-5):EUDIウォレットのフォーマット比較

最終確認日: 2026年10月5日 · 法的助言ではありません

SD-JWT VCは、署名付きJSON Web Tokenとしてまとめられた検証可能なクレデンシャルで、クレームを1つずつ開示できます。mdocはISO/IEC 18013-5フォーマットのモバイル文書です。この規格は当初、モバイル運転免許証のために作成されました。EUDIウォレットのアーキテクチャ・リファレンスフレームワーク(ARF)は、この2つをウォレットの必須フォーマットとしています。3つ目のフォーマットであるW3C Verifiable Credentials Data Model 2.0は任意とされ、「非適格EAAのみを対象とする」とされています。^[1]

本ガイドは、検証者を構築する開発者向けに両者を比較します。根拠はARF v3.0.0、OpenID for Verifiable Presentations(OpenID4VP)1.0の本文、およびEU官報です。PIDは個人識別データ(person identification data)を指します。

SD-JWT VCとは

ARFは「SD-JWT-based Verifiable Credentials」を、検証可能なクレデンシャルを表現するためのデータフォーマットと処理ルールと説明しています。SD-JWTは「『Selectively Disclosable JSON Web Token』の略」です。^[1] JSONエンコーディング、選択的開示を備えた証明メカニズム、任意のデバイスバインディングを含みます。^[1]

OpenID4VPではフォーマット識別子はdc+sd-jwtで、クエリはvct_valuesでクレデンシャルの種類を指定します。^[4] 以下は仕様書にある発行済みペイロードの例で、8つのダイジェストのうち2つに短縮しています。^[4]

{ "_sd": [ "jsu9yVulwQQlhFlM_3JlzMaSFzglhQG0DpfayQwLUK4", "TGf4oLbgwd5JQaHyKVQZU9UdGE0w5rtDsrZzfUaomLo" ], "vct": "https://credentials.example.com/identity_credential", "_sd_alg": "sha-256", "cnf": { "jwk": { "kty": "EC", "crv": "P-256" } } }

mdoc(ISO/IEC 18013-5)とは

ISO/IEC 18013-5は、免許証の属性、そのConcise Binary Object Representation(CBOR)によるエンコーディング、識別子の衝突を防ぐ名前空間、選択的開示を備えた証明メカニズム、必須のデバイスバインディング、近接でのやり取りを定めています。^[1]

運転に特有なのは免許証のデータモデルだけです。ARFは、それ以外の要素はすべて「汎用的であり、PIDを含む他のあらゆる種類の証明に使用できる」としています。^[1]

OpenID4VPは、これらのクレデンシャルを「CBORでエンコードされ、COSE_Sign1で保護される」ものと説明し、フォーマット識別子mso_mdocを割り当てています。クエリはdoctype_valueで文書の種類を指定します。^[4]

各フォーマットでの選択的開示の仕組み

選択的開示により、利用者は一部の属性を共有して残りを秘匿でき、検証者は引き続き発行者の署名を確認できます。eIDAS 2はウォレットにこれを可能にすることを求めています。^[6] ARFはSD-JWTの仕組みを「ソルト付きハッシュ」と呼び、「[ISO/IEC 18013-5]で同じ目的に使われる仕組みと概念的に同一である」としています。^[1]

1つの仕組みに、2つのエンコーディングがあります。^[1][4]

上記の例では、_sd配列にSHA-256ダイジェストが格納されています。各ディスクロージャーは、ランダム値、クレーム名、クレーム値からなる配列です。名の場合は["2GLC42sKQveCfGfryNRN9w", "given_name", "John"]となり、そのハッシュがリストの最初のダイジェストです。検証者は、受け取った各ディスクロージャーをハッシュ化し、署名済みペイロード内でそのダイジェストを探します。^[4]

クレームの指定方法は異なります。JSONクレデンシャルの場合、クレームパスは["address", "street_address"]のようなキーのリストです。mdocの場合、パスは「文字列型の2つの要素を含む」ものです。名前空間とデータ要素識別子で、たとえば["org.iso.18013.5.1", "first_name"]となります。^[4]

鍵バインディングとデバイスエンゲージメント

デバイスバインディングは、クレデンシャルをユーザーのウォレット内に保持された鍵に結び付けます。そのため、クレデンシャルは複製できません。検証者は、クレデンシャル内の公開鍵に対応する秘密鍵で新しいランダムデータに署名するようウォレットに求め、これを確認します。^[1] 名称は異なります。「[ISO/IEC 18013-5]では『mdoc認証』と呼ばれる。[SD-JWT VC]では『鍵バインディング』と呼ばれる。」^[1]

PIDでは、どちらのフォーマットでもデバイスバインディングが必須です。^[1][4]

SD-JWT VCについて、OpenID4VPのルールは厳格です。require_cryptographic_holder_bindingがtrue（デフォルト）の場合、ウォレットはKey Binding JWT付きで「SD-JWTを返さなければならない（MUST）」とされています。nonceクレームはリクエストのnonceと一致し、audは貴社のClient Identifierと一致しなければなりません。ただしDigital Credentials API経由の場合は、origin:を先頭に付けた貴社のオリジンと一致する必要があります。^[4]

デバイスエンゲージメントはmdocだけのものです。近接フローでは、ユーザーがQRコードを表示するか、NFCタグを提示します。そこには、リーダーがNFC、Bluetooth Low EnergyまたはWi-Fi Awareの接続を開き、その上に認証・暗号化されたチャネルを構築するために必要な情報が含まれています。両者の間にインターネット接続はありません。^[1]

mdoc（ISO/IEC 18013-5）による近接提示（簡略版）。^[1]

ユーザーに表示される画面:

提示プロトコル: OpenID4VP、ISO/IEC 18013-7、近接提示

ARFは、ウォレットが扱うものを挙げています。近接ではISO/IEC 18013-5、リモートではOpenID4VPまたはISO/IEC 18013-7です。^[1]

ARFに基づく、各プロトコルが扱うフォーマットの対応。^[1]

SD-JWT VCのアテステーションは「近接提示では使用できない」とされています。ISO/IEC 18013-7は「[ISO/IEC 18013-5]準拠フォーマットのアテステーションの要求と提示にのみ使用できる」とされています。OpenID4VPは「リモート提示のトランザクションフローにのみ適している」とされ、両方のフォーマットを扱います。^[1] OpenID4VP 1.0は2025年7月10日にFinal Specificationになりました。^[5]

ARFは、デバイスをまたぐカスタムURIスキームを推奨していません。こうしたフローは「フィッシングやリレー攻撃に対して脆弱である」ためです。ARFは代替としてDigital Credentials APIを挙げています。^[1] このAPIはまだW3Cのドラフトで、Chrome 141ではデフォルトで有効になります。^[9][10] ISOは18013-7の2024年版技術仕様を廃止・置換済みとしており、第3版が策定中です。コードがどの版を対象にしているか確認してください。^[7][8] リクエストの詳細はOpenID4VP検証者ガイドにあります。

実施規則(EU) 2026/1731がPIDに求めること

PIDフォーマットに関する最初の規則である実施規則(EU) 2024/2977は、PIDは「2つのフォーマットで発行されなければならない」と定めていました。ISO/IEC 18013-5:2021とVerifiable Credentials Data Model 1.1です。^[2][3] 2026年7月の改正法がこの一文を置き換えました。現在、PIDは「実施規則(EU) 2024/2979の附属書IIの第5項（SD-JWT VCフォーマット）および第6項（ISO/IEC-mdocフォーマット）に定める標準に従って発行されなければならない」とされています。^[2]

1. 2024年12月4日最初の規則2024/2977: 18013-5とVCDM 1.1。
2. 2026年7月22日改正2026/1731: SD-JWT VCとmdoc。
3. 2026年7月23日ARF v3.0.0改正法に整合。
4. 2026年12月24日ウォレット提供期限加盟国ごとに1つのウォレット。
5. 2028年8月11日顔写真該当する場合、利用者が明示的にオプトアウトしない限り、顔写真の要件が適用されます。

PIDフォーマットに関する法令の変遷。^[1][2][3][6]

同じ法令は、実施規則（EU）2024/2982に対する附属書で、2つの提示プロファイルを定めています。「ISO/IEC-mdocプロファイル」と「OpenID4VC-HAIPプロファイル」です。^[2]

• 登録証明書を送信します。verifier_infoの要素の1つは「登録証明書を含まなければならない」とされています。^[2]
• アクセス証明書を、x509_hash Client Identifier Prefixのリーフ証明書として使用します。^[2]
• Digital Credentials APIを介したmdocについては、「ISO/IEC 18013-7:2025の附属書C」に従います。^[2]

登録についてはEUDIウォレットの依拠当事者向けガイドで、スケジュールについては2026年と2027年のEUDIウォレットの期限で解説しています。

SD-JWT VCとmdoc（ISO/IEC 18013-5）の比較表

ARFに基づく。ただし、PIDの行（実施規則2026/1731）と最後の2行（OpenID4VP 1.0）を除く。^[1][2][4]

米国のモバイル運転免許証は、近接での提示にISO/IEC 18013-5を基盤としている。^[7][8] EUの年齢確認ソリューションは、必須の提示方式としてゼロ知識証明を挙げ、「フォールバックとして通常のmDoc提示」を用いるとしている。^[13] モルドバのEVO Walletは、HAIP 1.0に従ってプロファイルされたOpenID4VP 1.0とISO/IEC 18013-5 mdocの組み合わせを文書化している。^[11]

依拠当事者がサポートすべきフォーマット

ウォレットユニットは両方のフォーマットを扱い、PIDは両方のフォーマットで発行される。^[1][2] 本ガイドのために確認した文書には、依拠当事者に両方の要求を義務付ける規定はない。実務上の解釈は次のとおり。リモートの検証者はどちらでも要求できる。インターネット接続のないリーダーにはmdocが必要となる。mdocは近接で機能する唯一のフォーマットである。^[1]

OpenID4VPのDigital Credentials Query Language（DCQL）では、1つのリクエストにdc+sd-jwtクエリとmso_mdocクエリを並べて含めることができる。仕様書にはそのようなリクエストの例が示されている。^[4] ARFによれば、依拠当事者は、トラステッドリストまたはトラステッドエンティティリストのトラストアンカーに照らして発行者の署名を検証し、ステータスリストまたは失効リストで失効を確認し、デバイスバインディングを検証する。^[1]

eIDAS 2（Regulation (EU) 2024/1183）の下で、各加盟国は2026年12月24日までに少なくとも1つのウォレットを提供しなければならない。また、強力なユーザー認証の使用を義務付けられている民間の依拠当事者は、2027年12月24日までに、ユーザーの要求に応じてウォレットを受け入れなければならない。零細企業と小企業は適用除外となる。^[6] 各国の状況はEUDIウォレット導入状況トラッカーで確認できる。

ライブラリとテストツール

本ガイドが依拠する情報源は、オープンソースのライブラリを挙げていません。そのため、本セクションでも挙げません。ただし、テストの実施場所と、選んだライブラリで確認すべき点は示されています。

• conformance.eudi.dev で適合性テストを実行してください。これは ARF v3.0.0 のリリースノートに記載されています。^[1]
• docs.eudi.dev のリファレンス実装のドキュメントを読んでください。^[1]
• 公開されている検証者の実装を確認してください。モルドバ国立銀行は、金融機関向けにソースコード付きのデモ検証者を公開しています。^[12]
• ライブラリが基本仕様だけでなく HAIP にも準拠しているか確認してください。^[1]
• ライブラリが ISO/IEC 18013-7 のどの版を実装しているか確認してください。^[2][8]

Didit によるEUDIウォレット検証の支援

Didit での EUDIウォレットの受け入れは近日対応予定です。EUDIウォレットのスケジュールに合わせてロードマップに組み込まれており、現在お使いのワークフローと同じ流れで利用できるようになります。リモートでの本人確認は現在すでに可能です。

• 現在、Didit ではデジタルIDウォレットを通じて 5 つの国のeIDが稼働しています。MitID、BankID Sweden、Finnish Trust Network、Smart-ID、Mobile-ID です。eID検証をご覧ください。
• それ以外の利用者には、本人確認書類の検証を、NFCチップの読み取り、ライブネス検知、顔照合と組み合わせて使います。KYC チェック一式の費用は $0.33 です。
• AMLスクリーニングは同じフロー内で $0.20 で実行されます。

ウォレットのドキュメントでは、eIDを国ごとに有効化する方法を説明しています。

よくある質問

出典

1. Architecture and Reference Framework v3.0.0、GitHubのeu-digital-identity-wallet、2026年7月23日リリース。
2. 欧州委員会実施規則 (EU) 2026/1731、EUR-Lex、2026年7月22日付官報。
3. 個人識別データに関する欧州委員会実施規則 (EU) 2024/2977、EUR-Lex、2024年12月4日付官報。
4. OpenID for Verifiable Presentations 1.0、OpenID Foundation、最終仕様。
5. OpenID for Verifiable Presentations 1.0 Final Specification Approved、OpenID Foundation、2025年7月10日。
6. 規則 (EU) 2024/1183（eIDAS 2）、EUR-Lex、2024年4月30日付官報。
7. ISO/IEC 18013シリーズ、モバイル運転免許証、ISO規格ページ。
8. ISO/IEC 18013-7、ISO規格ページ。
9. Digital Credentials、W3Cドラフト。
10. Digital Credentials API shipped、Chrome for Developers。
11. EVO Wallet開発者ガイド、モルドバ政府、egov4dev。
12. BNMデモ検証者、モルドバ政府、egov4dev。
13. EU年齢確認ソリューション、技術ポータル、ageverification.dev。

SD-JWT VCとmdoc（ISO/IEC 18013-5）は、同じ約束を実現する2つのエンコーディングです。その約束とは、ユーザーが管理する署名付き属性です。Diditのウォレット受け入れへの取り組みはEUDIウォレットのソリューションページで、各国のスキームはすべて国別eIDスキームでご確認ください。