要約

  • ウォレット状態証明の第-01版は2026年9月27日付の個人提出Internet-Draftで、IETFによる承認、作業部会での採択、RFC化を意味しない。
  • JSONの署名対象は最上位のid、pass、results、attestedAt。条件の中にアドレスが入る場合はあるが、署名済みオブジェクト全体が対象ウォレットを必ず名指すわけではない。
  • JSONのexpiresAtも署名外にある。別途発行されるJWTではsubとexpが署名されるが、受け手はJWT自体を検証し、両形式が同時に届いた場合は整合性も確認する必要がある。

判定と対象が離れる瞬間

改訂草案の仕組みでは、発行者が公開されたチェーンの状態を読み、運用者が指定した条件を評価し、真偽値などに署名する。検証者は公開鍵集合を利用し、発行者への都度の照会なしに署名を確認できる。ウォレットの所有者が本人確認書類を提示する方式ではなく、残高そのものを示さずに閾値を満たすか伝えることも想定する。

ここで、照会したサービスと利用を許可するサービスが違う場合を考える。前者はどのアドレスを入力したか知っている。後者が受け取るのは署名済みのJSONだけかもしれない。第5節が署名対象として列挙する最上位の項目は四つであり、そこに共通のウォレット欄はない。個別のevaluatedConditionにアドレスが含まれればresultsの一部として保護される。しかし、それは条件ごとの性質であって形式全体の保証ではない。「どの財布についての合格か」を別の照会記録から結び直さなければならない場面が残る。

署名が正しいことと、その結び直しが正しいことを混同してはいけない。対応付けを誤った結果、別の口座のアクセスが開く可能性はある。ただし、これは設計上の条件付きリスクを示す例であり、実際の攻撃や事故を報じているわけではない。発行者の署名が示すのは、その発行者が特定のバイト列に責任を持つという事実であって、受け渡し先の台帳が正しい相手を指したという事実ではない。

「検証不能」と「偽」の違い

第-01版はkidに基づく鍵選択と署名方式の選択を詳しくした。kidがなく、または手元のJWKSに見当たらなければ、署名は「検証不能」である。指定された鍵で照合して失敗したときの「否定された署名」とは区別する。古いJWKSを更新して再試行する余地はあっても、先頭の鍵や組み込み鍵に勝手に差し替えて受け入れることは草案が禁じる。どちらの状態も「認めてよい」とはならないが、原因が違うため運用記録も分けるべきだ。

同じく、各evaluatedConditionからconditionHashを再計算することが求められる。書き換えの検出には役立つが、条件にアドレスが入っていなければ、正しいハッシュでも対象は補えない。新たなドメイン分離方式や追加の署名方式も導入されたものの、署名アルゴリズムを増やすだけで、要求と応答の結び付けが自動的に生まれるわけではない。

時間の判断は受け手にも残る

JSONではattestedAtと各結果に付くチェーン上の観測参照が署名される一方、expiresAtは隣接する署名外の項目だ。受け手は発行者が公表した有効期間と署名済み時刻を照合し、延ばされた期限を拒否できる。また、自分が必要とする最大経過時間を署名済みの時刻やブロック参照に適用できる。第12節は鍵選択、署名バイト列の復元、署名照合、条件ハッシュの確認を必須とするが、鮮度と期限の確認は推奨としている。したがって、仕様を読んだだけで、あらゆる利用先が同じ古さの基準を実行すると考えることはできない。

JWTを要求する場合は別の署名済みトークンが隣に届く。実際に評価されたウォレットを表すsub、署名対象の期限exp、保護されたヘッダーのkidがある。JWTの値を使うサービスは、そのJWTを独立に検証しなければならない。両方届いた際には対応する項目の整合も調べ、失敗したJWTや食い違うJWTを含む応答は拒否する。JSON側の検証成功をJWT側の検証成功として流用できない。

条件とチェーンが許すときにはMerkle証明を付ける選択もある。草案は利用できない条件を認め、使える場合でも元の残高などを露出し得ると注意する。発行者への依存を減らす検証と、不要な数値を見せない設計との交換である。いずれもウォレットの対応付けを省略する理由にはならない。

第-01版は既存形式の署名範囲を明示したが、第-00版の署名が引き続き検証できると改訂履歴に記す。「新しい版が対象アドレスを署名から外した」と書くのは不正確だ。Datatracker上の状態は、RFCの流れに属さない個人提出の活発な草案で、IESGではI-D Exists。著者が挙げる実用例や採用例を、この報道だけで実際の導入証拠とは扱わない。

出典