Summary

  • 個人提出のInternet-Draftは、発行者が参照したチェーン状態に対してウォレット条件を評価し、JWKSでオフライン検証できる真偽値を返す形を示す。
  • JSON形式で署名対象になるのは id、pass、results、attestedAt であり、expiresAt、kid、ラッパー、通常はウォレット自体の識別は外側にある。
  • 署名検証は発行者の観測記録を認証する。参照ブロックのファイナリティ、現在の状態、replay防止、後続処理の認可までは証明しない。

正しい署名が古い世界を指す

あるサービスが、ウォレットに必要な残高があるかを問い合わせる。発行者はチェーンのデータ源を読み、ブロックを選び、pass: true と署名する。数秒後、依存側は署名を正しく検証する。しかしその間に残高は移動し、indexerが遅れていたかもしれず、reorgで参照状態がcanonical historyから外れた可能性もある。

暗号は破られていない。署名は「この発行者が、この参照と時刻で、この評価を記録した」と証明しただけだ。「ウォレットは今も条件を満たし、行動してよい」という文は、後から運用側が付け足したものになる。

01版は2026年9月27日提出。DatatrackerではIndividual Submissions、streamなし、ActiveとI-D Existsである。JWT、JWKS、JOSEをこの用途に組み合わせる文書で、新しいwire protocolではない。WG採択、IETF合意、RFC、相互運用実績、導入実績として扱ってはならない。

署名境界は四つのメンバー

JSONの署名オブジェクトは id、pass、results、attestedAt から成る。各resultには評価条件、conditionHash、チェーン固有の参照が入る。EVMならブロック番号と時刻、XRPLならledger indexと利用可能なhash、Solanaならslot、Bitcoinならtipの高さとhashである。

bare schemeは送信されたメンバー順序そのものに依存する。01版が追加したdomain-separated schemeはメッセージ種別とversionを付け、RFC 8785でJSONをcanonicalizeする。これは同じ検証bytesを再構成しやすくする仕組みだ。RPC sourceが正しいか、ブロックがfinalかを決める仕組みではない。

kid はJWKSから鍵とschemeを選ぶ。欠落または未知なら unverifiable であり、refuted ではない。別の鍵で代用してはならない。鍵追加直後には、古いJWKS cacheを持つ検証者だけが判定不能になる。この差は知識の差であり、偽造の証拠ではない。

ウォレットbindingも形式ごとに違う。署名されたJSON objectは一般にウォレット名を持たない。条件がaddressを含む場合はあるが、二次受領者が推測してよいわけではない。JWTは sub と exp を署名する。JWT claimを利用するならJWT自身を検証し、隣のJSON署名で代用しない。

鮮度はアンカーを読む側の責任

result内のチェーン参照と署名済み attestedAt は保護された鮮度アンカーである。ただし許容できる年齢は取引ごとに違う。署名の年齢とブロックの年齢、実際の行動時刻を分けなければならない。今作られた署名でも、古すぎるブロックを指し得る。

JSONの expiresAt は未署名のTTL hintだ。01版は、署名済み attestedAt と発行者の公開windowを超えていないか確認するよう求める。改ざん耐性のある期限が必要ならJWTの署名済み exp を使う。それでもexpiry checkはRECOMMENDEDである。監査は実施したかどうかを独立して記録すべきだ。

replayにも別の判断が要る。署名済み id でseen-setを作れるが、nonceやaudience bindingはintegration profileに残される。時間内だから一回限り、あるいは特定の相手向けだとは限らない。

チェーンは署名後にも歴史を変える

草案はRPC routing、indexer選択、archive node、finality、data availabilityを範囲外とし、署名後のreorgで観測状態が非canonicalになり得ると明記する。確認深度、強いファイナリティ、独立source、無効化手順は運用設計である。

conditionHash の再計算は宣言条件の改変を検出する。しかし正しいchain、block、業務thresholdを選んだことまでは証明しない。Merkle proofが値をstate rootに結び付けても、そのrootを十分finalと認める判断と、歴史的事実を今の認可に使う判断は残る。

発行者の観測時計、チェーンのcanonicality時計、依存側の決定時計は別々に進む。artifactは三つを結ぶだけで、一つにはしない。

緑の一項目をやめる

Lu Hengのreality-layerの考え方は、署名表現、発行者観測、canonical state、current state、service outcomeを分離する。Running-Code Primacyは稼働中のチェーンと実結果をラベルより上位に置く。Minimum Initial Specificationは共有formatを狭く保ち、finalityと認可を明示的なローカル判断にする。

記録には、発行者、kid、schemeとdomain tag、再構成bytes hash、primary/companion verdict、condition hash、wallet binding、chain reference、独立照合とfinality、時刻、expiry、replay/audience、認可rule、行動結果が必要である。

出典と限界

これらはIETF合意、WG採択、実装、導入、独立観測、finality、ウォレット支配やholder consent、認可、settlement、delivery、service outcomeを立証しない。草案内の採用例は、別途確認しない限り著者によるinformative claimである。