ERC-5573 ReCaps：登录签名之外再授权一串能力清单

用钱包登录网站时弹出的那条签名消息，很多人从来没读完整。它原本是登录凭证，但有应用把它悄悄变成万能通行证：你点了确认，它转身就拿这份签名去访问你的存储、你的数据接口。2021 年 7 月 20 日创建、状态为 Draft 的 ERC-5573（又名 SIWE ReCaps）就是冲着这个缝隙来的：在 ERC-4361 登录签名之上，把“你允许这个应用替你做哪些事”逐条写死进签名内容。本文按原文拆这套机制。

登录授权分家，对应 web2 的两份协议

抽象部分把它定位成 ERC-4361 的扩展层：SIWE 解决账户向服务的身份认证，ReCaps 解决获得认证之后，账户授权该服务以你的名义去第三个服务办事。动机部分给了一个精准的类比：SIWE 认证相当于 OpenID Connect 的角色，ReCaps 相当于 OAuth2 的角色——先证明你是谁，再限定这个应用能替你干什么。动机里描述的场景很具体：网站认出你之后，想替你调用一个云存储服务，没有统一授权通道时它要么索要过多权限，要么各搞一套暗号。ReCaps 要给这条授权链一个确定的形状。

授权条款塞进签名语句的语法

规范的写法是纯文法式的。签名消息的 statement 字段在经过 ReCap 变换后，必须匹配一条 ABNF 语法：原始声明之后接一句固定引导语“I further authorize the stated URI to perform the following actions on my behalf:”，随后是一条条编号条目，每条按“编号、能力命名空间、能力名、资源”的结构拼接，比如以括号数字开头，写明动作命名空间加动作名，再接 for 引住的目标资源，句末一个句点。资源标识本身是一个 ReCap URI，内含符合模式定义的详情对象，把授权粒度的机器可读版本带在身上。验证侧流程同样机械：按 ERC-4361 验签，取出 URI 字段，从 resources 字段最后一条读出 ReCap URI，再断言 statement 恰好以变换后的语句结尾。签名没改密码学，改的是文本内容的构造规则——授权范围被折成规范化语句后参与签名哈希，事后增删任何一条，签名即失效。

语法读一遍就够用的句子

规范里那段形式语法定义读起来费力，骨架其实只有四要素：编号、能力命名空间、动作名、目标资源，一条条目读起来就是“在第几号、对什么资源、可以执行哪类命名空间下的哪些动作”，条目用编号串联、句点收尾。设计意图写在明面上——给人类核对用的：签名弹窗空间有限，一串可逐条点数的文字条目，比一坨不透明的授权哈希更接近知情同意。验证侧流程同样机械：先按 ERC-4361 验签本身，再从 resources 字段末条取出 ReCap URI，最后断言语句结尾与变换后的句子完全一致——授权内容被折进签名哈希，多改一个字，签名当场作废。变换算法还保证原始声明保留在引导语之前，“认证归认证、授权归授权”的分界线落在明文里，用户不需要任何工具就能用肉眼审一遍自己批了什么。

Draft 状态与读签名的好习惯

按 ercs 仓库记录，ERC-5573 停在 Draft。理解它的最佳姿势是把它当一面镜子：它照出的问题今天仍然存在——钱包弹窗里那一屏文本，就是你签下的合同正文。ReCaps 给出的原则可以脱离标准本身使用：授权应当有范围、有编号、可逐条核对，超出登录本意的动作不该藏在同一次点击里。实操层面有三条好习惯。第一，登录签名里的 statement 出现与本服务无关的授权句式时，停下来逐条读懂再决定；第二，能选只读就不要给写权限，能选单次就不要给持久授权；第三，警惕把登录签名复用作操作凭证的站点——登录归登录、链下代操作归链下代操作，两者混签在一起时，风险边界由谁解释就不是你说了算。标准没有推翻任何机制，只是提醒：签名字段的每一行都是承诺，越界授权从“允许应用代你做事”那句话开始。

本文为机制说明，不构成任何投资建议。