SD-JWT VCの正体を暴く！W3C VCとIETF規格の狭間で生まれた選択的開示の新世界 🔐
🚀 はじめに
身分証明書をスマホに入れて、必要なときに“必要な部分だけ”見せられたら便利だと思いませんか？
例えば、お酒を買うときに『私は20歳以上です』だけ証明できて、名前や住所は見せなくていい。
そんな夢みたいな仕組みを実現するのが SD-JWT VC なんです。
デジタル証明書（Verifiable Credential, VC）の世界で、これまで課題だったのが“見せる情報を選べない”こと。
そこに新しく登場したのが、選択的開示をネイティブでサポートする SD-JWT VC なんです。
VCの世界ではW3C VC Data Model（JSON-LD/LDP形式）が有名ですよね。でも最近、SD-JWT VCという新しい選手が登場してきました。しかも、IETFが作ったバージョンとW3C VC Data Model 2.0で言及されたバージョンの2つがあるんです。
さてさて、今回はこの規格の乱立状況と、それぞれの違い、そして実際のファイル構造まで深掘りしてみましょう。
🛠️ まずはW3C VC（JSON-LD/LDP）の特徴と課題
1. W3C VCの基本構造
W3C VCは、Linked Data（JSON-LD）を採用し、@contextにより意味論（セマンティクス）を外部参照する仕様を使います。
{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://w3id.org/citizenship/v1"
],
"type": ["VerifiableCredential", "PermanentResidentCard"],
"credentialSubject": {
"id": "did:example:123",
"givenName": "太郎",
"familyName": "山田",
"birthDate": "1990-01-01",
"address": {
"streetAddress": "東京都渋谷区...",
"postalCode": "150-0001"
}
}
}
一言で言えば、「意味論を重視したリッチなデータ構造」です。@contextによって、データの意味を外部のスキーマで定義できるのが特徴です。
2. JSON-LD/LDPの課題
従来は「全部見せるか、全部隠すか」に寄りがちでしたが、SD-JWT や BBS+ を組み合わせれば、必要な項目だけを開示する設計が可能です。
💡 IETFって？
W3CがWeb標準を定める団体なのに対して、IETF（Internet Engineering Task Force）はインターネット全体のプロトコル標準（HTTP、TLS、OAuthなど）を策定してきた技術コミュニティです。
VCの世界はW3Cの守備範囲ですが、「JWTをどう拡張して安全に使うか」といった領域はJWTやOAuthを管轄しているIETFの方が専門。
そのため、VCの中でも特にJWTベースのSD-JWT VCについてはIETFが主導して仕様化を進めているんです。
📌 SD-JWT VCの2つの顔
IETFバージョン vs W3C VC 2.0での扱い
W3CはVC Data Modelを定義し、IETFはJWT/SD-JWTといった表現・伝送形式を策定している。両者は競合というより補完関係にある。
では、なぜSD-JWT VCには2つのバージョンがあるのでしょうか？
| 項目 | IETF SD-JWT VC | W3C VC 2.0 + SD-JWT |
|---|---|---|
| 規格主体 | IETF OAuth WG | W3C VCWG |
| typヘッダー |
dc+sd-jwt（2024年11月〜） |
仕様で明示なし |
| メディアタイプ | application/sd-jwt |
application/vc+sd-jwt |
| データモデル | 独自（VCDMを使わない） | VCDMとの互換性重視 |
| @context | 不要 | 必要（JSON-LDとの共存） |
| 選択的開示 | ネイティブサポート | SD-JWTを追加的に利用 |
| 仕様の成熟度 | ◎ Draft進行中 | ◎ W3C勧告（2025年） |
typヘッダー変更の経緯（技術的な詳細）
IETFのSD-JWT VC仕様では、2024年11月にtypヘッダーをvc+sd-jwtからdc+sd-jwtに変更しました。これは「vc」というメディアタイプ名をW3Cが先に登録していたため。
一方、W3Cの「Securing VCs using JOSE and COSE」仕様では、メディアタイプとしてapplication/vc+sd-jwtを使用しますが、JWTのtypヘッダーについては明確な規定がありません。
つまり、IETFの独立仕様とW3C経由のSD-JWTでは、微妙に異なる実装になっているんです。移行期間中は両方の値を受け入れる実装が推奨されています。
要は、IETFは「シンプルで実装しやすい」を重視し、W3Cは「既存のVCDMとの互換性」を重視した結果、2つの流派が生まれたというわけです。
🔄 ファイル構造を見てみよう
SD-JWT VCの基本構造
IETF版の例では typ ヘッダーは { "alg": "ES256", "typ": "dc+sd-jwt" } とされ、ペイロードのトップレベルに vct が置かれる。W3C版では @context や _sd が含まれる場合がある。
それでは実際のファイル構造を見てみましょう。SD-JWT VCは以下のような構造になっています：
{
// 選択的開示可能なクレームのハッシュ配列
"_sd": [
"CrQe7S5kqBAHt-nMYXgc6bdt2SH5aTY1sU_M-PgkjPI",
"JzYjH4svliH0R3PyEMfeZu6Jt69u5qehZo7F7EPYlSE",
"eluV7Og3gSNII8EYnsxA_A5Ee7qMdWh0zejnfh1MBj"
],
// 必須フィールド
"vct": "https://credentials.example.com/identity_credential",
"iss": "https://issuer.example.com",
"iat": 1683000000,
"exp": 1883000000,
"_sd_alg": "sha-256",
// キーバインディング用のcnfクレーム
"cnf": {
"jwk": {
"kty": "EC",
"crv": "P-256",
"x": "TCAER19Zvu3OHF4j4W4vfSVoHIP1ILilDls7vCeGemc",
"y": "ZxjiWWbZMQGHVWKVQ4hbSIirsVfuecCE6t4jT9F2HZQ"
}
}
}
IETF仕様ではvctは衝突耐性名（Collision-Resistant Name）として定義されており、URNやURLを用いることが推奨される。
🔍 イメージ: _sd配列は「ブラインドボックスのラベル」みたいなもの。中身は見えないけど、何が入っているかは後で選択的に開示できる。
Disclosureの構造
選択的開示の肝となるDisclosureは、以下のような三要素の配列です：
// Disclosure の中身（平文）
["2GLC42sKQveCfGfryNRN9w", "familyName", "山田"]
// ↑ランダムソルト ↑属性名 ↑値
// Base64URLエンコード後
"WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgImZhbWlseU5hbWUiLCAi5bGx55SwIl0"
これは「開封用の鍵」みたいなものです。この鍵を渡すことで、特定の情報だけを開示できるんです。
最終的なSD-JWT VCフォーマット
発行者は、署名済みJWTとDisclosuresをチルダ（~）で結合します：
<Issuer-signed JWT>~<Disclosure 1>~<Disclosure 2>~...~<Disclosure N>~
実際の例：
eyJhbGciOiJFUzI1NiIsInR5cCI6ImRjK3NkLWp3dCJ9.eyJfc2QiOlsi
Q3JRZTdTNWtxQkFIdC1uTVlYZ2M2YmR0MlNINWFUWTFzVV9NLVB...長いJWT
...~WyI2cU1RdlJMNWhhaiIsICJmYW1pbHlfbmFtZSIsICLlsbHnlLAiXQ~
WyJlSThaV0FkRmticUthYW10UzBRIiwgImJpcnRoRGF0ZSIsICIxOTkwLTAxLTAxIl0~
パッと見は複雑そうですが、要は「JWT本体 + 開示したい情報の鍵」という流れです。
💡 実際の活用シーン
選択的開示の具体例
発行時には全ての情報が含まれていますが、提示時にホルダーが必要なDisclosureだけを含めることで、選択的開示を実現します。
実装例：年齢確認のみのケース
// ホルダーが年齢情報のDisclosureだけを選んで提示
const presentationForAgeVerification =
jwt + "~" + birthDateDisclosure; // 名前と住所のDisclosureは含めない
// 検証者側では年齢情報だけが見える
{
"vct": "https://credentials.example.com/identity_credential",
"iss": "https://issuer.example.com",
"birthDate": "1990-01-01", // これだけが開示される！
// 名前と住所は隠されたまま
}
2025年5月、W3C VC Data Model 2.0が正式に勧告化され、JOSE/COSEやSD-JWTなど複数の表現形式が正式に定義された。
🚧 現在の課題と展望
規格の乱立問題
まるで、VHSとベータマックス、HD DVDとBlu-rayの争いを見ているようで...（若い人は知らないかもしれませんが😅）
相互運用性への動き
2024年後半から2025年にかけて、ChromeのDigital Credentials APIやAndroid/Wallet、SafariのDC API対応など主要ブラウザ・OSでW3C VC 2.0連携の動きが進んでいる。
統合への試み：
- デュアルフォーマット対応 - 発行者が複数形式を同時発行
- プロトコルの共通化 - OpenID Connectベースの統一
- ブリッジ仕様の開発 - 形式間の変換ツール
企画倒れに終わった過去の統合規格には少し気の毒ですが、技術の世界では良いものが生き残るのは常です。
今後の展望
今後は以下のような流れが予想されます：
- 短期的（2025年） - 各規格の並存と使い分け
- 中期的（2026-2027年） - デファクトスタンダードの確立
- 長期的（2028年以降） - 統一規格または完全な相互運用性の実現
💡 まとめ
ポイント
- W3C VC（JSON-LD）は意味論重視だが選択的開示が課題
- SD-JWT VCは選択的開示をネイティブサポート
- IETFとW3Cで微妙に異なる規格が存在
- ファイル構造は JWT + Disclosures のシンプルな形式
- 規格の統合はまだ道半ば
まとめると、SD-JWT VCによって「プライバシーを守りながらデジタル証明書を活用する時代」が来たと言えます。
選択的開示という考え方は、「必要最小限の情報共有」という現代のプライバシー要求に完璧にマッチしています。W3C VCの「全部か無か」というアプローチから、「必要な分だけ」というアプローチへの転換は、まさにパラダイムシフトと言えるでしょう。
ともあれ、SD-JWT VCの登場でWeb3時代の本格的なプライバシー保護が実現に近づいたのは確かでしょう。規格の乱立という笑えない状況はありますが、エンドユーザーにとって使いやすい形に収束していくことを期待しています。
📚 参考資料
技術仕様書・関連ドキュメント
IETF関連：
- IETF SD-JWT Specification - 選択的開示の基本仕様
- IETF SD-JWT VC - SD-JWT VCの仕様
W3C関連：
- W3C VC Data Model 2.0 - VCデータモデルの最新版
- W3C Securing VCs using JOSE and COSE - JOSEとCOSEを使ったVC保護
実装ガイド：
- EBSI SD-JWT Guide - 実装者向けガイド
- OpenID for VC Issuance - 発行プロトコル
2025年1月作成
NONENTROPY JAPAN株式会社は、Blockchain、IPFS、DID/VC、生成AIなどを活用し、Web3時代の信頼を支える技術を開発しています！技術情報を中心に投稿します！
Discussion