最新の更新
隔離した Cloudflare Tunnel のテストで、コネクターのハイブリッド鍵交換と、Tunnel 経由で API のヘルスチェックに到達できることを確認しました。
10月11日、検証用クライアントから Cloudflare、および Cloudflare と Railway 上のテスト用 cloudflared コネクターとの間で、いずれも X25519MLKEM768 のネゴシエーションと証明書検証に成功しました。Cloudflare とコネクターの間では QUIC/TLS 1.3 を使用しました。
Tunnel を通した API ヘルスチェックの応答は HTTP 200 で、ランダムなリクエスト ID も送信値と一致し、API への到達を確認しました。テスト終了後、関連するテスト用リソースは削除しました。
新しい x402 monitor のレポートと署名付き tree head、Service Receipt v2、ホスト版 Apostille Core 0.3 には ML-DSA-65 署名を導入済みです。新しいデータベースバックアップは AES-256 でデータを暗号化し、ML-KEM-768 + X25519 のハイブリッド方式でファイル鍵を保護します。10月10日、実際のバックアップと隔離した PostgreSQL への復元演習がともに成功しました。
実測した範囲
今回の結果は隔離テストによるもので、本番のルーティングは変更していません。確認したのはハイブリッド鍵交換であり、証明書認証のポスト量子対応や経路全体の暗号化を示すものではありません。テストでは、コネクターからプライベートネットワーク経由で API に接続する区間は HTTP を使用しました。
以前の更新
新しい x402 monitor のレポートと署名付き tree head、Service Receipt v2、ホスト版 Apostille Core 0.3 は、現在 ML-DSA-65 で署名されます。過去の Ed25519 記録は、従来のアルゴリズムで引き続き検証できます。
10月10日、本番の新しいバックアップで、ファイル鍵のラッピングを ML-KEM-768 + X25519 に切り替えました。実際のバックアップと、隔離環境での復元演習がともに成功しています。過去のバックアップは変更していません。
10月10日（台北時間）、検証用クライアントから ifandonlyif.io の Cloudflare エンドポイントに接続し、証明書検証を有効にした状態で X25519MLKEM768 が選択されました。他のクライアントでは結果が異なる場合があります。
今回の変更が示す範囲
特定の層での移行が進んだもので、システム全体のポスト量子対応を意味しません。ウォレットとチェーンの暗号、Groth16 は従来のままです。署名は内容の真実性を証明せず、署名鍵の盗難やハードウェアの侵害を防ぎません。
更新
新しい x402 monitor のレポート、transparency log の tree head、Service Receipt は ML-DSA-65（FIPS 204）で署名されます。ホスト版 Apostille は Core 0.3 のみを発行し、Apostille SDK と CLI の v0.4.0-alpha.1 は既定で ML-DSA-65 の key を作成します。以前の Ed25519 署名は、検証可能な履歴として引き続き有効です。
新しい key は、API レスポンスではなく、公開リポジトリのレビュー済みコピーから pin してください。
従来方式のままの部分
Ethereum ウォレットの同意とオンチェーンのアンカリングは secp256k1 を使います。既存の Core 0.1 workspace は読み取り専用です。署名が示すのは、誰がどのバイト列に署名したかであり、endpoint や成果物が安全であることではありません。
更新
サプライチェーン API プレビューに、リリース証拠の登録、受信者ポリシー、metadata 評価、リリース撤回の 7 つの route を追加しました。導入時は自分の workspace 内の既存の Core 0.1 または Core 0.3 certificate に対応していました。その後のホスト版の署名切り替えにより、Core 0.1 workspace は読み取り専用になりました。issuer と producer の key は自分のポリシーで pin してください。bundle やディレクトリ内の key が自動的に信頼されることはありません。
連携前に GET /api/apostille/v1/status を確認してください。enabled が true で、features に supply_chain_releases が含まれている必要があります。
この確認で分かること
ポリシー結果は、署名付き証拠、提出された metadata、サービス側の現在の観測を組み合わせたものです。API は実際のファイルのバイト列を検査しないため、ファイルの hash とサイズを署名付き manifest と自分で照合してください。マルウェアスキャンではなく、有効な署名はファイルの安全性を意味しません。
更新
Apostille Local の alpha.2 ソースプレビューに、OpenAI Chat Completions に加えて Anthropic Messages API のサブセット（POST /v1/messages：テキスト、ストリーミング、カスタムツール使用、JSON Schema 出力）を追加しました。管理者が有効にしたローカルモデルで動作し、Claude のモデル重みは含まれず、Anthropic クラウドへもリクエストしません。
汎用 CLI と SDK で署名付き workflow metadata を記録でき、Flower の例も任意で利用できます。gateway は既定でプロンプトや回答を保存しません。パッケージ registry には未公開で、Apostille Core 0.1 は変更ありません。
記録で確認できること
受信者は、独立して入手した key pin と自分のポリシーでオフライン検証します。記録は、回答の正しさ、モデルが実際に実行されたこと、データが環境外へ出ていないことを証明しません。
更新
IFF と Apostille のサインインサービスを更新しました。ページを再読み込みし、既存の ID で再度サインインしてください。API クライアントが 401 Unauthorized を受け取った場合は、サインインをやり直し、保存しているセッション認証情報を更新してください。workspace とレコードは保持されます。
更新
Apostille Core 0.1 の Go SDK と CLI を v0.1.0-alpha.1 としてインストールできます。hosted service も同じ release を使用しています。
go get github.com/ifandonlyif-io/iff-apostille@v0.1.0-alpha.1
go install github.com/ifandonlyif-io/iff-apostille/cmd/apostille@v0.1.0-alpha.1
その後、Core 0.3（ML-DSA-65）が v0.3.0-alpha.1（クライアントは v0.3.1-alpha.1）として公開されました。当時の hosted service は Core 0.1 と 0.3 を発行し、issuer pin を公開していました。既定の署名バージョンは Core 0.1 でしたが、耐量子なのは Core 0.3 の署名のみです。現在の動作は10月10日の署名切り替えをご覧ください。
オフライン検証は署名とバイトの対応を確認します。信頼には独立して選んだ issuer と key pin が必要で、内容の真実性や法的な本人性は証明されません。
更新
匿名 HTTP MCP alpha：IFF の読み取り専用ツール 13 個を /mcp/iff、Apostille の読み取り専用ツール 7 個を /mcp/apostille で利用できます。アカウント、OAuth、秘密鍵、元ファイルは不要で、IFF のツールが支払いを実行することはありません。
Apostille の信頼は、呼び出し側が指定した issuer/key pin のみに基づきます。検証は hosted service 上で実行されるため、結果は IFF に関する独立した証拠ではありません。
更新
ローカル stdio の Go MCP server 2 つが内部 alpha になりました：iff-mcp（IFF の証拠とログ用 14 ツール、支払いなし）と apostille-mcp（20 ツール。既定ではオフライン検証、任意で承認済みの署名・送信）。
どちらも公開配布や hosted はなく、@ifandonlyif/x402-preflight にも含まれません。そちらの verify_x402_endpoint 単一ツールは変更ありません。
更新
Apostille の任意 profile として、非公開の ERC-8004 agent identity binding と、実験的なローカル ZK budget proof を追加しました。IFF x402 monitor、anchor、reputation には反映されません。
オフライン検証には正確な issuer と key pin が必要です。token の所有は組織の身元、endpoint の管理権限、支払い権限を証明しません。ZK proof は、署名済みの 1–16 個の金額の合計が受信者の上限以下であることを、ローカルの単一当事者開発環境で示します。
更新
Apostille Core 0.1 alpha では、bot の成果物にローカルで署名し、受信者が bundle をオフライン検証できます。IFF が受け取るのは元ファイルではなく署名付き manifest で、公開には明示的な PublicationGrant が必要です。IFF x402 のエビデンスカード、monitor 観測、webhook、透明性ログとは分離されています。
信頼には、独立して入手した issuer URI と key fingerprint の pin が必要です。有効な bundle は、内容の真実性、組織の身元、TEE での実行、現在の失効状態を証明しません。
言語
ホームページ、ガイド、API ドキュメント、SDK ガイド、更新情報を英語、日本語、繁体字中国語、簡体字中国語で読めます。技術用語、API 名、コードは原文のままで、receipt verifier は英語のみです。
改善
receipt の結果は、入力や時刻に合わせてクリアまたは期限切れになります。endpoint owner は、claims リストで 1 つのファイルに複数の所有権 claim を置けます。追加時は既存の claim を残してください。各 endpoint には、それぞれ対応する challenge が必要です。
ライブ検索に、未記録 URL 向けの「監視対象として送信」と、送信済み向けの「進捗を確認」を追加しました。BSC の例と
Naven の Robinhood Chain Ping resource に公開 observed ティアのカードがあります。所有権は未検証で、0G の公開ネットワーク対応は未完了です。
修正
ブラウザとサーバーの receipt 検証で、入力、issuer、timestamp の規則を統一し、key directory の更新は一時的な障害から回復します。検証済みのリダイレクトを辿るのは robots.txt の取得のみで、endpoint の probe は引き続き辿りません。
directory の一致は key を識別するだけです。独立した信頼には、正確な issuer と、別経路で入手した完全な key fingerprint が必要です。
実験的
IFF の任意の署名付き Service Receipt envelope を確認するブラウザ検証ツールです。receipt JSON を貼り付けるか読み込むと、解析と署名検証はローカルで実行され、issuer の識別時に公開 key directory を取得することがあります。API 呼び出し側が有効にした場合のみで、通常の preflight レスポンスは変わりません。
この機能の範囲
x402 の支払いレシートではありません。支払い、サービス提供、呼び出し元の身元、リモート実行、結果の正しさ、安全性のいずれも証明しません。