要約

  • RFC 9901では、Holder は Issuer が渡した Disclosure のうち、ゼロ件、一部、または全部を Verifier に出せる。出した値は署名済み JWT の digest と照合できる。
  • 照合は「この値が Issuer の署名構造に属する」ことを示すだけで、非開示の主張の不存在、現在の事実、またはローカルな許可を示さない。

選択的開示の失敗は、暗号が破られたときだけに起きるわけではない。検証者が一つの有利な値を受け取り、見えない残りを勝手に「問題なし」と読むときにも起きる。RFC 9901 の設計は、まさにその残りを Holder が選んで見せないことを可能にしている。

SD-JWT では、Issuer が JWT に署名する。選択開示できる claim の平文の代わりに digest を置くことができる。Disclosure にはランダムな salt、必要なら claim 名、そして値が入る。Holder は発行時に資料を受け取り、提示時には Verifier ごとに選んだ Disclosure だけを送る。Verifier は digest を計算し直し、Issuer が署名した JWT にそれが入っていることを確かめる。

ここで確定する命題は細い。「この提示された値は、この Issuer が署名した構造に結び付く」。それは「関連する値はすべて提示された」ではない。RFC 9901 は Holder が任意の部分集合を送ることを許す。Issuer は常時見える claim と選択開示 claim を混ぜられ、claim 数を読ませないため decoy digest も置ける。画面に項目がないことから、その項目が偽、空、不要だとは読めない。

役割ごとに文章を分けるべきである。Issuer は構造に署名し、何を選択開示可能にするか決める。Holder は今回の相手に対して開示集合を決める。Verifier は署名と digest を検証する。アプリケーションは claim の意味を読み、自分のルールで証拠が足りるかを決め、必要なら処理を実行する。「資格が証明された」という一文は、この異なる所有者の仕事を一つに見せてしまう。

Issuer の署名があっても、現実に関する空白は埋まらない。署名は発行後の構造の完全性を守るが、Issuer がどう確認したか、値が今も妥当か、ある claim がすべてのアプリで同じ意味を持つかは決めない。RFC 7519 は claim の表現を、IANA は名称の共有を支える。どの claim が必要で、どの欠落を拒否するかは、用途別プロファイルと Verifier の方針に残る。

Key Binding は任意の追加証拠である。Verifier が求める場合、Holder は SD-JWT の hash、nonce、audience を含む KB-JWT に秘密鍵で署名する。これはこの提示で鍵を保持していることを示せる。しかし全 claim の開示、claim の現在性、行為の許可までは示さない。逆に Key Binding を強制しない相手には、SD-JWT を持つ者が第三者へ転送し、Disclosure を取り除くこともできる。受け取った表現だけから、現在の提示者や元の相手を決めてはならない。

RFC 9901 は重要な制御を隠すことも認めない。真正性や有効性の評価に不可欠な内容を、Issuer は選択開示可能にしてはならない。何が不可欠かはプロファイルに依存する。Verifier は Issuer の署名と各 Disclosure の digest を検証する。RFC 8725 が促す明示的な型も、別の JWT 用途を取り違えないための境界である。

運用記録には、Issuer と鍵方針、明示型とプロファイル、必要 claim、提示 claim、digest 結果、Key Binding の要否、nonce、audience、方針版、最終遷移を別々に残すべきだ。「credential verified」という単一の成功表示は、判断を再現する材料を失わせる。

Heng Lu の表現・局所判断・実行結果を分ける姿勢は、ここでは編集上の抑制として働く。RFC 9901 は限定的な主張を可搬にし、Holder のプライバシー選択を守る。非開示を完全な情報へ変えたり、検証を実行権限へ変えたりはしない。

Sources