要約

  • IESGは9月1日、SD-JWT VC第19版についてIETF全体のLast Callを開始した。OAuth Working GroupはProposed Standardとしての公開を求めており、意見期限は9月15日である。承認はまだ決まっていない。
  • 必須のvctが主たる型を示し、発行者はaka_vctsで追加の型を主張できる。Type Metadataのextendsは型同士の継承関係を作る。
  • これらは照合と規則の再利用には役立つが、発行者を認可しない。第19版は、発行者の身元、信頼状態、登録・認定を別途確認するよう求める。
  • Type MetadataのPublisherにも別の権限根拠が必要だ。取得経路やハッシュが正しくても、そのPublisherが型を定義する権限までは証明できない。
  • 各エコシステムが発行者とPublisherの根拠を分けて記録する「権限レシート」を持てば、IETFに世界共通の信頼レジストリを運営させずに境界を実装できる。

型が一致しても、判断は終わっていない

今回のニュースは、新しい資格情報形式が直ちに標準になったという話ではない。9月1日にdraft-ietf-oauth-sd-jwt-vc-19がLast Callへ入り、OAuth Working GroupがProposed Standardとしての公開を求めた、という段階である。証拠の締切時点でDatatrackerは「In Last Call」を示し、IESGのtelechat日は未設定、IANA reviewは必要なままだった。

IESGの案内によれば、Last Callは通常、コミュニティに開かれた最終審査段階である。したがって、9月15日までは文言や設計を検証する期間であり、採択を祝う期間ではない。将来のRFC番号も最終文面もまだ存在しない。

基礎となるRFC 9901は、JSON Web Tokenの選択的開示を定めている。発行者はJSONデータと、後で開示できる項目のダイジェストを署名する。保有者は相手に応じて一部だけを提示できる。検証者は発行者署名と開示内容を確かめ、方針上必要なら保有者の鍵との結び付きも検証する。

SD-JWT VCは、その仕組みを資格情報として扱うための形式と処理規則を加える。必須のvctは、大文字小文字を区別する衝突耐性のある型識別子である。ただし、草案自身は具体的なvctを一つも定義しない。意味、claimの規則、形式外の発行・検証方針は各エコシステムが定める。

これは責任放棄ではない。旅券、職業免許、卒業資格、社内証明を発行できる主体は、同じ技術形式を使っても同じ統治制度には属さない。共通仕様が決めるべきなのは記述と検証の方法であって、世界中の発行権限ではない。

extendsとaka_vctsは異なる近道を提供する

Type Metadataのextendsは、ある型が別の型を継承することを表す。Consumerは親のメタデータを先に処理し、その後に子の規則を重ねる。子は表示情報などを調整できるが、親で必須とされたclaimを任意に変えたり、選択的開示について固定されたalwaysやneverを弱めたりできない。

一方、aka_vctsは資格情報の中で発行者が行う主張である。特定の型を持つ資格情報が、さらに別の一般的な型にも該当すると示せる。発行時や提示時に相手が一般型を求めている場合に便利で、Type Metadataがなくても使える。配列の順番には意味がなく、列挙した型がextendsで結ばれている必要もない。

処理上の柔軟性は大きい。しかし、第19版はその先に明瞭な停止線を置く。悪意ある発行者は、正当な型を模倣したり、その型を継承すると宣言したりできる。型階層だけを理由に受け入れてはならず、発行者の身元、信頼状態、関連する認定やレジストリを独立に確認しなければならない。aka_vctsも発行者自身の主張にすぎず、その存在は発行権限の証拠ではない。

つまり、ソフトウェアは「要求された型に当てはまる」と「この主体が発行してよい」を別々の結果として持つ必要がある。両方を一つのチェックマークに変換した瞬間、意味上の互換性が制度上の委任へ化ける。

Type Metadataの公開者も審査対象である

草案にはPublisherという役割がある。Type Metadataや補助文書を公開する主体で、標準化団体、コミュニティ、エコシステムの権威などが想定される。資格情報の発行者と同一とは限らない。

Publisherは、型の表示名、claimの構造、描画方法、extendsの関係などを文書にできる。ConsumerはHTTPSで取得し、integrity情報によって版が改変されていないか確認できる。しかし、安全な通信と正しいハッシュは「この文書を受け取った」という証拠であり、「この主体が型を定義してよい」という証拠ではない。

第7.8節は、Publisherが当該型について権威ある主体として認められていない限り、Type Metadataを正確または意味のあるものと仮定してはならないとする。さらに、どのPublisherがどの型について認可され、どの条件で依拠できるのかを、エコシステムがガバナンスまたは認定の仕組みで定めるよう勧めている。

ここには二本の権限線がある。一本は、発行者と発行許可を結ぶ。もう一本は、Publisherと型定義の権限を結ぶ。同じ組織が両方を担う場合でも、根拠や有効期間、適用範囲が同じとは限らない。記録まで統合する理由にはならない。

署名は鍵の支配を示し、委任を生まない

草案は暗号検証を軽視していない。適用方針が認める発見・検証方法を使い、署名鍵が発行者に属することを確認できなければ、資格情報を拒否しなければならない。この規則は、誰の鍵がデータを保護したのかを確定するために不可欠である。

ただし、自分の鍵を正当に管理していることと、政府や専門機関から発行を委任されたことは別である。認可されていないPublisherでも、整合したメタデータ階層を公開できる。integrity値は、不正な内容であっても変更されていないことを正確に示せる。

Heng Luのいうmandate launderingは、このすり替えを捉える。技術的な器が、本来は参照するだけだった権限の源泉として扱われる。ウォレットでは、見慣れた型、有効な署名、「検証済み」の表示が一直線に並ぶ。その表示が何を検証したのか説明しなければ、利用者は鍵の確認を発行権限の確認だと読む。

第19版は、その推論を仕様上は明確に禁止した。残る課題は、ログや画面が禁止線を消さないことである。

受け入れ判断に権限レシートを付ける

世界共通の発行者名簿を新設する必要はない。各エコシステムが、自ら受け入れる「発行者と型」の組み合わせごとに、小さな権限レシートを管理すればよい。

レシートは、実際に処理したvct、受け入れたaka_vcts、完全なextendsチェーンを記録する。次に、発行者識別子、鍵の発見・検証方法、発行を認めるレジストリ、認定、法令、契約、trust listの記録を示す。

別欄ではType MetadataのPublisher、文書の版とintegrity参照、Publisherに型を定義・記述する権限を与えた根拠を示す。適用される地域や制度、有効期間、検証方針の版、判断時刻も必要だ。最後に、署名、型照合、alias、継承、メタデータ取得のいずれも単独では制度的権限を証明しない、と明記する。

否定的な状態も分けなければならない。「未確認」「根拠を取得できない」「期限切れ」「適用外」「権限なし」は異なる。公開証拠が見つからないことだけで、発行者を無権限と断定してはいけない。

このレシートは本稿の提案であり、第19版の要件ではない。資格情報本文を書き換えるものでもない。共通形式が意図的に外部方針へ残した判断を、後から再構成できるようにするだけである。

統治をワイヤ形式へ押し戻さない

国家資格と大学の証明書、企業バッジ、民間会員証では、権限の源泉が全く異なる。IETFが一つのスキーマに埋め込めば、ローカルな制度が新しい中央運営者へ依存し、権限変更のたびに共通形式が古くなる。

したがって、レシートを置く場所はエコシステムのprofile、検証者方針、ウォレットのtrust設定、制度運営者のregistryである。IETFは型の表現と処理、そして権限を自動継承しない境界を維持する。誰が免許を発行できるかまでは決めない。

プライバシーにも注意が要る。vctとaka_vctsは選択的に隠せず、資格情報の用途を示してしまう場合がある。また、保有者ごとに異なる発行者識別子を検証者がオンライン解決すると、悪意ある発行者は提示場所や回数を追跡できると草案は警告する。権限レシートは安定した発行者・型の組に結び、cacheやpinningを可能にし、提示ごとの発行者照会を避けるべきである。

出典

  1. IETF — SD-JWT VC第19版のLast Call
  2. IETF Datatracker — SD-JWT VC文書記録
  3. IETF Internet-Draft — SD-JWT VC第19版
  4. RFC 9901 — Selective Disclosure for JSON Web Tokens
  5. IESG — Last Call Guidance to the Community
  6. IETF — OAuth Working Groupのcharter
  7. Heng Lu — Mandate Laundering