要約

  • W3Cは9月24日、Bitstring Status List v1.1を初の公開作業草案として発行した。v1.0は既存の勧告であり、両者の成熟度は違う。
  • 新しい簡潔な項目には基底URLと32ビットの索引が入る一方、失効などの状態目的は検証者が変換時に指定する。
  • 大きな共有リストを指せることだけでは、実際の利用者集団の匿名性や取得したリストの有効性は決まらない。

「どのリストの何番目か」が分かっても、「何を確かめたいのか」が決まらなければ判断はできない。W3Cの検証可能なクレデンシャル作業部会が公開した Bitstring Status List v1.1 の草案は、この違いを際立たせる。新設された TerseBitstringStatusListEntry は、容量の限られた用途を念頭に、基底URLと索引だけで状態情報への参照を表す。検証者はそれを通常の状態リスト項目へ戻して照会する。

前提となる共有ビット列は新発明ではない。2025年5月の v1.0 はW3C勧告で、クレデンシャルごとの個別照会が発行者による追跡を招き得ることを踏まえ、多数の状態を一つのリストにまとめる。元のクレデンシャルと状態リストの発行者が別でもよい点も既存の規定だ。今回の v1.1 は勧告へ向けた最初の公開作業草案にすぎず、W3Cや会員の承認済み実装指針として扱うことはできない。

追加された変換の仕組みは具体的だ。簡潔な索引は符号なし32ビット整数で表せる値とし、一つのリスト長を 2²⁶ 項目、選択し得るリスト番号を 2⁶ とする。索引をリスト長で割った商がリスト番号、余りがリスト内の位置になる。基底URLの後ろに状態目的と番号を連結して参照先を組み立てる。これはアドレスの設計であって、64個のリストが実際に公開されたという報告ではない。

省略された statusPurpose は検証者が渡す。草案は、通常は簡潔な項目そのものにデジタル署名があり、その検証を変換に先立って行うべきだとも述べる。署名は元の参照を固定できる。しかし、ある取引で停止を調べるべきか失効を調べるべきか、その選択に署名だけで答えは出ない。照会先のリストも取得して証明を検査しなければならない。

更新の判断も残る。保有者が署名済みリストを一緒に提示すれば、発行者への即時アクセスを避けられる場合がある。他方、検証者は新しい版を求めるかもしれない。任意の ttl は更新を試す目安で、有効期間を延ばす条項ではない。草案が注意するように、索引空間が広くても実際の発行件数が少なければ集団としての秘匿性は弱まり得る。

出典