< ニュースルームに戻る

SSP Identity Signing とリクエスト認証が到着

·5 分で読める·SSP Editorial Team 著
指紋、チェック付きの盾、南京錠、鍵のアイコンが見出し「SSP Identity Signing とリクエスト認証」の上に並ぶカバー。

2025-12-27 の v1.29.0 と 2026-01-02 の v1.30.0 の間に、SSP は変更履歴では小さく、アーキテクチャ図では大きく見える二つのリリースを出荷しました。v1.29.0 はリクエスト認証を追加 — ウォレットは受け取るすべての dApp リクエストの送信元と完全性を検証します。v1.30.0 は SSP Identity Signing を追加 — ウォレットはトランザクションに署名するだけでなく、リモートサービスに対して自分自身の身元を証明できます。両者は WalletConnect で開いた dApp リクエスト面を堅牢化し、元の Identity 機能 をサービスがチャレンジできる一級プリミティブに変えます。

リクエスト認証が着陸(v1.29.0)

dApp リクエスト — これに署名、あれを承認、このチェーンへ切替 — はトランスポート経由でウォレットに届きます。WalletConnect ではそのトランスポートはリレー経由のセッション、インページプロバイダではそれは Chrome 拡張のメッセージです。それぞれ少なくとも一つの信頼ギャップがあります:リレーは偽装でき、ページはフィッシングクローンであり得、メッセージは偽造され得ます。

リクエスト認証はそれらのギャップをウォレット側から閉じます。SSP が確認画面を描画する前に、誰が何を要求しているのかを検証します。リクエストが主張する送信元は、それを配信したトランスポートと突き合わせられます。ペイロードは完全性をチェックされ — ウォレットは転送中に改変されたリクエストには署名しません。さらにリクエストはウォレットがすでに保持しているセッション状態と照合され、別のセッションから再生されたリクエストが他人のペアリングを使って忍び込まないようにします。

これらは正当な dApp が署名を求めたときに見えるものを何も変えません。確認画面は同じに見えます。変わるのは、dApp とその画面の間の経路に、トランスポートが誰のために配信しているかについて正直であると信じる代わりに、ウォレット自身が強制するガードレールがあることです。

Identity Signing が続く(v1.30.0)

一週間後、v1.30.0 は逆方向へ進みました。それまで SSP Identity はメッセージ — ユーザーが鍵を制御していることを証明する文字列 — に署名できました。v1.30.0 は身元として署名する機能を追加します:リモートサービスは期待する SSP Identity を名指しするチャレンジを発行でき、ウォレットはサービスが検証できるかたちでレスポンスをその身元に結びつける署名を返します。

差は微妙で、しかし荷重を担います。メッセージへの署名は、鍵が何かを制御していることを証明します。身元署名は、鍵が名前付きの身元を制御していることを証明します — サービスが権限、残高、サブスクリプションとすでに紐づけている安定したハンドル。サービスが「ユーザーがそこにいるか」だけでなく「これはこのアカウントを作成した同じユーザーか」を知る必要がある場合、身元署名はループを閉じます。v1.30.0 はまた、リクエストポップアップ処理を磨きました — ちらつきが減り、ドロップしたポップアップが減り、フォーカス復帰が速くなりました。

なぜ dApps にとって重要か

dApp の脅威モデルは小さな根本原因のセットを共有します。送信元の偽装 — 悪意あるページが信頼されたページのふりをする。再生されたリクエスト — あるセッションで署名されたペイロードがキャプチャされ、別のセッションで提出される。フィッシング面 — 確認画面で正当に見えるリクエストが、実際には攻撃者のコントラクトに向かう。

リクエスト認証はこの三つすべてを狭めます。なぜならウォレットがトランスポートを権威として扱うのをやめるからです。送信元はトランスポートと一致しなければならず、ペイロードは送られたものと一致しなければならず、セッションはペアリングされたものと一致しなければなりません。各チェックはそれ自体は小さく、合わさることで確認画面をユーザーが現実を映していると信頼できるものにします。身元署名は別の攻撃 — 再ペアリングによるアカウント乗っ取り — を狭めます。なぜなら名前付きの身元としてウォレットに署名を求めるサービスは、「ウォレットがサインインした」を検証可能な結びつきに変えるからです。

WalletConnect とどう合うか

WalletConnect は数千の dApp への扉を開きました。v1.29.0 はその扉に錠を、v1.30.0 はドアベルを追加しました。両者は同じ面に着地します:リクエストフロー。リクエスト認証は、ウォレットが見るリクエストが dApp が送信したリクエストであることを保証します。身元署名は、dApp が見るレスポンスがあなたのウォレットが送ったものであり、dApp が期待していた身元によって署名されていることを保証します。このペアは WalletConnect セッションを「ブロブを交換する二つのエンドポイント」から「互いに自分が誰であるかを証明できる二つのエンドポイント」に変えます。

Identity から Identity-Signing へ

元の SSP Identity 機能 はウォレットに安定した身元面を与えました — 支出に使うトランザクションアドレスとは別に、メッセージングと証明のために導出されたアドレス。それは導入編でした。v1.30.0 は続編です:同じ身元が、いまやサービスが名指しで要求でき、自分側で検証できるクレデンシャルとして使えます。

これがウォレットが単なる鍵保持者ではなく一級の身元プリミティブになるということの姿です。v1.29.0 は入力を信頼に値するものにし、v1.30.0 は出力を検証可能にします。ほとんどのユーザーは差を直接見ることはないでしょう。しかしこの面に対して統合する dApp とサービスは、SSP がいまや毎回、自分が誰かを証明し、誰が問うているかを検証できることを発見するでしょう。

この記事をシェアする

関連記事