要約

  • 2026年10月2日公開の Using KYAPay Tokens 01版は、トークンを扱う主体を「verifier」から「recipient」へ変更し、識別と受け入れは別だと明記した。署名が正しくても、許可、制限、追加確認、拒否は受信側のローカル判断である。
  • その境界は後段にも続く。bearer token は秘密鍵の所持を証明せず、発行時の人間による委任は継続的な操作を証明せず、PAYの取引情報は決済完了や商品の引き渡しを証明しない。

認証の設計では、成功という一語が多すぎる事実を飲み込みやすい。draft-skyfire-oauth-using-kyapay-tokens-01 が行った役割名の変更は、その圧縮を避けるための重要な修正だ。トークンを読むシステムは、単なる検証器ではなく受信者である。

受信者には次の行為を決める権限が残る。対象リソースサーバー、エッジ事業者、ボット管理、詐欺対策、アカウント乗っ取り防止、顧客ID基盤は、同じ署名結果を受け取っても異なる結論を出せる。公開情報の閲覧と口座変更で同じ保証を要求する必要はない。

KYAは人間の本人、エージェントを動かすプラットフォーム、個別エージェントを区別して記述する。PAYは支払い文脈を加える。これによりIPアドレスやUser-Agentだけで自動アクセスの主体を推測するより、判断材料は良くなる。ただし答えられるのは「発行者が誰を背後にいると述べたか」であって、「この操作を許可せよ」ではない。

01版は identification と admission を分け、サイト固有のポリシーエンジンへトークンを入力する。結果は通過、速度制限、追加認証、拒否のいずれにもなり得る。単一の「検証済みエージェント」表示に縮めると、人・プラットフォーム・エージェントごとの保証と操作の重大度が消える。

文書の制度上の位置も分けて読む必要がある。二つのKYAPay文書は個人提出のInternet-Draftで、凍結したDatatracker情報にはstream、標準化段階、WG採択がない。OAuthメーリングリストは議論先であり、合意の証拠ではない。提案されたHTTPフィールドやJWT claimは、IANAの現行レジストリへ載るまでは割り当てではない。

検証処理は複数の独立した判断から成る。まず受信者が発行者を信頼するか決め、JOSEヘッダーと署名、exp、iat、jti、aud、実行環境を確認する。次にKYAかPAYかを識別し、人、プラットフォーム、エージェントの保証を別々に読む。KYAPay-Token ヘッダーの存在だけを、人間が今操作している印として扱ってはならない。

既定の提示方式はbearerである。コピーを入手した者は有効期間中に提示できる。短い寿命、TLS、狭いaudience、jtiの再送記録は被害範囲を小さくするが、送信者がエージェントの秘密鍵を保持している証明にはならない。

関連するtoken 02版はcnf claimを許す。確認鍵を参照し、外側のプロトコルが実際のproofを要求し、受信者がそれを検証するとき、sender constraintを作れる。しかし署名済みJWTの中に鍵名があるだけではproofは実行されていない。署名検証と鍵所持検証を同じ監査項目にしてはいけない。

委任には時間の境界もある。草案が示すのは発行時に本人がエージェントを許可したという状態であり、寿命中ずっと本人が制御したという事実ではない。発行後にホストが侵害され、プラットフォーム登録が失われ、本人が権限を撤回する可能性がある。01版には失効機構がないため、重大な操作ほど新鮮なchallengeや別の確認が要る。

発行者への信頼も署名から自動的には生まれない。署名が正しいとは、その鍵がオブジェクトへ署名したということだ。本人確認の質、エージェント登録、プラットフォーム管理が受信者の基準を満たすかは別問題である。草案自身が大規模なissuer trustを未解決とし、現状では帯域外の関係に依存すると記す。信頼リストの版を判断記録へ含めるべき理由である。

PAYは支払いの全工程を代表しない。対象、金額、通貨を結び、一取引用credentialと一回限りのcryptogramを運べば、盗用や条件差を見つけやすくなる。それでも加盟店の受理、ネットワーク承認、清算、最終決済、取消不能、配送はそれぞれ別の出来事だ。

監査可能なreceiptには、草案とprofile、発行者と鍵セット、本人確認の根拠と保証、token hash、署名とclaimの結果、audienceと環境、再送判定、bearerか鍵所持proofか、ローカルポリシーと追加認証、アプリが実行した結果を残す。支払いでは承認、清算、決済、取消の参照を追加し、PAY claimへ吸収しない。

Heng Luの最小初期仕様は、共有すべき最小claimと不変条件を決め、結果に関わる政策をローカルに残す設計を支持する。Running-Code Primacyは、登録や署名でなく実際に動いたアプリを見ることを求める。Reality Layersは発行者の主張、暗号検証、鍵所持、ポリシー判断、利用者の結果を一つの「許可」に畳まない。

recipientという語は責任の所在を見える形に戻した。発行者は主張し、トークンは運び、検証器は確認する。受信者は自分の入口を管理し、アプリは実行結果を記録する。

情報源