検査資格の番号だけ隠して有効性だけ見せる──JWTの『選択的開示』をCBORに持ち込むSD-CWTを読む

IETF SPICEワーキンググループのドラフト「SD-CWT」は、SD-JWTと同じ選択的開示（自分の持つクレームのうち一部だけを相手に見せる）の仕組みを、省リソース環境向けのCBOR Web Token（CWT）に持ち込む。3つのプロトタイプ実装（Rust・Python・TypeScript系）が公開されており、いずれも『相互運用テストは未実施、本番投入は時期尚早』と明記されている、というドラフト本文の中身をそのまま示す。

検査資格を持つ人が、「検査に合格したこと」だけを証明したいのに、資格証には検査員のライセンス番号や過去の検査日一覧まで一緒に書き込まれている——電子的な資格証明（Verifiable Credential）では、こうした「持っている情報の一部だけを選んで見せる」ニーズがある。JSON世界ではSD-JWTという仕様がこれを解決しているが、IoT機器や省リソース環境ではJSONではなくCBOR（バイナリ形式）が使われる。IETF SPICE（Secure Patterns for Internet CrEdentials）ワーキンググループのドラフト「SD-CWT（Selective Disclosure CBOR Web Tokens）」（著者はMichael Prorock氏（mesur.io）・Orie Steele氏（Tradeverifyd）・Henk Birkholz氏（Fraunhofer SIT）・Rohan Mahy氏の4名。Transmuteは著者組織ではなく、Appendix E.1のプロトタイプ提供元）の本文を確認すると、この選択的開示の仕組みをCBOR Web Token（CWT）向けに移植する仕様であることが分かる。

3行まとめ

SD-CWTは、CWT（CBOR Web Token、RFC 8392）に対してSD-JWT（RFC 9901）と同様の「選択的開示」を持ち込むIETF標準化トラックのドラフト。SPICEワーキンググループの08版は2026年6月1日公開、失効予定は2026年12月3日

発行者（Issuer）が特定のクレームを「Redacted（編集済み）」なハッシュ値に置き換えてSD-CWTを発行し、保有者（Holder）が提示先ごとに「開示するクレーム」を選んで、コピー&ペースト攻撃を防ぐ鍵バインディング（Key Binding Token）付きで提示する、という3者間モデル

3つのプロトタイプ実装（Transmute社のTypeScript系・SimpleLogin社のRust・Tradeverifyd社のPython）が公開されているが、いずれも「相互運用テストは未実施」「本番投入には未対応」と実装状況（Appendix E）に明記されている

IETF Datatrackerで確認したところ、このドラフトは既にWG（SPICEワーキンググループ）での審議を終えて「Submitted to IESG for Publication」の段階にあり、意図するステータスは「Proposed Standard」。IESG状態は「AD Evaluation」（担当エリアディレクターChristopher Inacio氏によるレビュー中）、文書シェパードはMichael B. Jones氏

検査資格の例で見る「一部だけ見せる」仕組み

ドラフトのSection 3が挙げる具体例が分かりやすい。検査員の資格に紐づくCWTには、検査の合否・検査員のライセンス番号・過去の検査日リスト・検査地域といった複数のクレームが含まれる。

/most_recent_inspection_passed/ 500: true,
/inspector_license_number/ 501: "ABCD-123456",
/inspection_dates/ 502 : [ 1549560720, 1612498440, 1674004740 ],
/inspection_location/ 503: { "country": "us", "region": "ca", "postal_code": "94188" }

このうち「合否」「最新の検査日」「検査国」は常に開示される固定クレームとして扱い、ライセンス番号のような残りのクレームは、発行者がハッシュ値（Redacted Claim Hash）に置き換えてSD-CWTを発行する。保有者は、提示する相手ごとに、ハッシュの元になった値（Salted Disclosed Claim）を「開示する／しない」を選べる。ドラフトの説明はこうだ。

It enables the Holder of a CWT to disclose or withhold special claims marked as selectively disclosable by the Issuer of a CWT, when presenting those claims to a Verifier.

（CWTの保有者が、発行者によって選択的開示可能とマークされた特定のクレームを、検証者に提示する際に開示するか差し控えるかを選べるようにする）

「コピペ攻撃」を防ぐ鍵バインディング

選択的開示だけでは、SD-CWTを盗んで別人がそのまま提示する「コピー&ペースト攻撃」を防げない。ドラフトはこの対策として、保有者が確認鍵（Confirmation Key）で署名した「Key Binding Token（KBT）」を、提示のたびに新しく作って添付する仕組みを定義している。

The Holder also proves possession of the confirmation method (defined in [RFC8747]) to prevent copy and paste attacks.

（保有者は、コピー&ペースト攻撃を防ぐため、確認方式（RFC 8747で定義）の保有を証明する）

さらに、実際に開示するクレームの数より多くの「デコイ（decoy）ダイジェスト」を混ぜることができる仕組みも用意されている。これにより、検証者側は提示されたSD-CWTの見た目だけから、発行者が元々いくつのクレームを選択的開示可能にしていたかを正確には推測できなくなる、という設計だ。

SD-JWTとの差分5点（Appendix B）

ドラフトのAppendix B「Comparison to SD-JWT」を実際に開いて読むと、CBOR/COSE流儀に合わせるための具体的な差分が5項目に整理されていた。RFC 9901（SD-JWT）の該当箇所とも突き合わせた結果を表にする。

項目	SD-JWT（RFC 9901）	SD-CWT（本ドラフト）
メディアタイプ	`application/sd-jwt`	`application/sd-cwt`
Key Binding Token用メディアタイプ	`application/kb+jwt`	`application/kb+cwt`
構造化サフィックス	`+sd-jwt`	`+sd-cwt`
編集済みクレームキーの配列	JSON配列`_sd`	CBOR Simple Value（IANA割当申請番号59）
ディスクロージャ内の要素順	salt, key, value	salt, value, key（強く型付けされた言語での高速パース向け）
デコイダイジェストの扱い	発行者・保有者間でも開示しない	発行者・保有者間では開示される
confirmationクレーム	任意	発行時にREQUIRED
Key Binding Token	任意	提示時にREQUIRED

ディスクロージャの要素順を「salt, value, key」に入れ替えている理由についてドラフトは「CBOR配列の2番目の要素が常にvalueになるため、強く型付けされたプログラミング言語でのパースが速く効率的になる」と説明している。またIANA Considerationsの Content-Formats（17.7節）を確認すると、application/sd-cwtとapplication/kb+cwtは、CoAP Content-Formats登録でもそれぞれID 293・294として登録申請されていることが分かった。

3つのプロトタイプ、すべて「本番投入は時期尚早」

Appendix Eの実装状況セクションには、3つのプロトタイプが記載されている。

E.1. Transmute Prototype [...] Implementation Experience: No interop testing has been done yet. The code works as a proof of concept, but is not yet production ready.

（Transmuteプロトタイプ。実装経験：相互運用テストはまだ行われていない。コードは概念実証としては動くが、本番投入にはまだ対応していない）

同じ文言（相互運用テスト未実施・本番未対応）が、SimpleLogin社のRust実装（github.com/beltram/esdicawt、Apache-2.0ライセンス）、Tradeverifyd社のPython実装（Appendix E.3）のいずれについても繰り返されている。Rust実装は「redacted_claim_keysにタグ付きキーの代わりにCBOR SimpleValueをラベルとして使っている点を除けば仕様に近く、検証の一部はまだ未実装」と、仕様との差分まで具体的に記載されていた。Transmute社のTypeScript系実装もgithub.com/transmute-industries/sd-cwt（Apache-2.0）として公開されており、「mainブランチは本仕様に近い機能を実装しているが、サンプルデータ生成のために破壊的変更を伴う改訂を予定している」と、これから仕様が変わりうることも明記されている。

SPICE WGの外での標準化進捗までは追えていない

この記事で確認できたのは、ドラフト本文（08版）とDatatrackerのステータス表示、およびRFC 8392・RFC 9901の該当箇所との突き合わせまでだ。次の点は裏取りできていない。

IESGの「AD Evaluation」の後、実際にRFC番号が割り当てられて発行されるまでの見込み時期は、Datatrackerのステータス表示以上の情報を持たない
この記事を書いている自分自身は、COSE（CBOR Object Signing and Encryption）やCWTを実装した経験がなく、Rust・Python・TypeScriptいずれのプロトタイプも実際に動かして検証してはいない
Appendix F「RATSアーキテクチャとVerifiable Credentialsの関係」で説明されている、RATS（Remote ATtestation procedureS）ロールとの対応関係については、この記事ではドラフト本文の目次を確認した以上には踏み込んでいない
Zenn・Qiitaともに、SD-CWT単体を扱った記事は検索時点で見当たらなかった

関連記事: MCP（Model Context Protocol）とは

感想・指摘はコメント欄へ。