Signal — チャネル信頼
詐欺師はWhatsAppやTelegramで銀行、配送業者、店舗になりすまします。Signalはメッセージが公式チャネルから来たかを数秒で確認します。
技術的な現実：非対称な戦略
WhatsApp Cloud API: メッセージがビジネス番号に転送されたとき、Webhook に含まれるのは転送した人の電話番号と context.forwarded、そして内容だけです。 元の送信者は決して含まれません. 転送された WhatsApp のチェックでは内容とリンクしか分析できません。チャネルの帰属は送信側の申告から得ます。
Telegram Bot API: forward_origin には元の送信者が含まれます（プライバシー設定の場合を除く → MessageOriginHiddenUser）。第三者による検証で、受信側での本当の帰属とネイティブのバッジが可能になります。
Brand Claim Boundary（要石）
各ブランドは自らの 公式境界: を宣言し署名します。使用するドメイン、WhatsApp 番号、Telegram チャネル、短縮リンクはそれだけです。エンジンは署名済みの allowlist に対して、 その対象が境界の内側か外側か を問います。境界とは、次に公開されたエントリのことです： Official Channel Log 。
黄金律：レジストリの事実であって、意図ではない
SecureStamp が意図を主張することはありません。verdict は事実の 閉じた 集合です:
PERTENECEそのチャネルは、ブランドが宣言し署名した境界の内側にあります。NO_PERTENECEそのチャネルは境界の外側です。観測されたシグナルを伴う場合もあります。COUNTERSTAMPブランドがそのチャネルに対して確認済みの counter-stamp を発行しました。DISPUTEDその案件は異議申し立て中で、正当な手続きの途上にあります。UNKNOWNそのブランドは SecureStamp で境界を宣言していません。
5 つの状態は L1〜L5 に対応します。強い L1 の状態には、ブランドが署名した counter-stamp が次の状態であることが必要です： confirmed。アルゴリズムによる判定が意図を推し量ることはありません。
二つのログ（TLP モデル）と透明性
Official Channel Log — TLP:CLEAR: ブランド自身のチャネルに関する一次情報の主張。公開の照会、履歴、失効。
Abuse Transparency Log — TLP:AMBER: 第三者による主張。公開されるのは暗号学的なコミットメントと集計値のみで、詳細は制限されます。個別の事例は公開ツリーヘッドに対する Merkle 包含証明 で証明します。
counter-stamp のライフサイクル
恣意的なブラックリストではありません。状態と正当な手続きがあります。
L1 を有効にできるのは confirmed だけです。 disputedはチャネル所有者のための異議申し立ての経路です。
Trust Receipt（ES256、共有 JWKS）
検証のたびに Trust Receipt: が生成されます。ES256 で署名され、タイムスタンプ付きで、ID はSSF-EV-…、誰でも再検証できます。SecureStamp の公証鍵を再利用するため、第三者はメールの切手と同じ/.well-known/jwks.json で receipt を検証できます。ヘッダーは typ: SSCT-receipt.
API
| POST | /api/signal/verify | エンジンを実行し、レジストリの事実と署名付き Trust Receipt を返します。 |
| GET | /api/signal/receipts/{id} | 公開 JWKS に対して Trust Receipt を再検証します。 |
| POST | /api/signal/brands | ブランドの境界を宣言・更新します。 |
| POST | /api/signal/counter-stamps | counter-stamp を開始します。 |
| PATCH | /api/signal/counter-stamps | counter-stamp の状態を遷移させます。 |
Disclaimer: SecureStamp が証明するのは、あるチャネルがブランドの宣言した公式境界に属することと、receipt の完全性です。送信者の意図やメッセージ内容の真実性を証明するものではありません。