x402のpayToが
変わったら、
何を比較する？

5項目の比較

要件全体から確認する。

payToの値は、ネットワーク、アセット、金額、スキーム、リソースと併せて初めて意味を持ちます。アドレスだけを切り離して比較するのではなく、クライアントが実際に受け取ったチャレンジをタイムスタンプとともに保存し、保存済みの観測と比較してください。

payTo

その支払いオプションで提示された受取先です。差がある場合、クライアントが別の受取先の値への支払いを求められたことを示します。

ネットワーク＋アセット

決済の文脈です。別ネットワーク上の同じアドレス文字列や、別のアセット識別子に使われる同じティッカーは、同一の支払いオプションではありません。

金額

金額はIFFの完全なオプションフィンガープリントに含まれます。スキーム、ネットワーク、アセット、受取先が同じで金額だけが変わった場合、プリフライト比較ではamount_onlyに分類できます。

リソース

エンドポイントURLによってIFFのレコードと比較範囲が決まります。ホストやパスが異なる場合は、別のリソースとして確認してください。リソースはIFFの支払いオプションのフィンガープリントには含まれません。

結論を出す前に文脈を確認

変更が通常の運用による場合もある。

プロバイダーは、資金管理用アドレスのローテーション、カストディの移行、アセットやネットワークの変更、価格の更新、新しいリソースパスのデプロイを行うことがあります。キャッシュされたチャレンジや遅延したチャレンジにより、正当な移行が一時的に不一致に見える場合もあります。これらは調査すべき可能性であり、IFFが理由として立証するものではありません。

古い観測には別の制限もあります。IFFは新しい要件を最新の観測期間と比較し、matches_last_observedを報告しますが、判定はstaleのままです。条件が最後に保存されたエビデンスと一致するかは分かりますが、古いエビデンスを最新にはできません。

レコードに含まれる情報

履歴から順序を確認し、動機は断定しない。

最新の公開エビデンスカードには、現在保存されている支払いオプションと観測時刻が表示されます。requirements.currentとrequirements.historyのブロックは、連続したフィンガープリントの期間を、初回観測、最終観測、観測回数とともに要約します。公開履歴から、正規化されたオプションセットが変わったことは分かりますが、変更前後を説明する平文や、変更を行った運用者の特定情報は示されません。

1. 正確なリソースを照合する。パスを含め、同じ正規化済みの公開HTTPSエンドポイントを比較します。
2. タイムスタンプと鮮度を確認する。古いチャレンジと新しい観測が、異なる正当な状態を示している場合があります。
3. 提示されたすべてのオプションを比較する。オプションの順序や重複項目は正規化済みセットの差になりません。一方、スキーム、ネットワーク、アセット、受取先、金額は差になります。
4. 所有権と要件を分けて考える。所有権ディメンションがverifiedであることは、オリジンの管理権限を記録します。支払いアドレスの管理権限は証明せず、observedティアのカードでは所有権が未検証の場合があります。
5. 自身の保留・エスカレーション規則を適用する。変更が自身のポリシーの基準を超える場合は、別の信頼できる経路でプロバイダーに確認します。