在 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,这种传输是经由中继的会话;对于 inpage provider,它是一条 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 让输出可验证。大多数用户永远不会直接看到差别。但与这一面集成的 dApps 和服务会发现,SSP 现在每次都能证明自己是谁、并验证谁在问 — 每一次。