EIP-2844 解读为 JSON-RPC 增加 DID 签名与解密方法did_authenticate / did_createJWS / did_decryptJWE【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPsEIP-2844Add DID related methods to the JSON-RPC是一份 Standards Track / Interface 类以太坊改进提案提出在钱包与 DApp 之间的 JSON-RPC 接口上新增三个以did_*为前缀的方法将 W3C 去中心化标识符DID与 IETF JOSEJWS 签名、JWE 加密标准引入以太坊钱包生态。本文以 EIPS/eip-2844.md 为骨架结合仓库内相关 EIP如 EIP-1102、EIP-1474与 EIP 流程规范 eip-1.md系统讲解三个方法的参数、返回值、权限模型、算法建议、安全考量与既有实现帮助读者掌握用 DID 替代裸地址做身份发现、用 JOSE 做标准签名与加密的钱包接口设计思路。提案背景为什么需要给钱包加 DID 与 JOSE此前方案的局限在 EIP-2844 之前社区曾有两轮为以太坊钱包增加解密能力的尝试对应 issue #130 与 PR #1098。该路线使用x25519-xsalsa20-poly1305这一非标准编码方式表示加密数据虽能能用但有明显缺陷编码非标准密文表示方式没有对接 IETF 的 JOSEJSON Object Signing and Encryption系列标准与主流生态互操作成本高公钥不可发现仅知道对方一个以太坊地址时无法检索到对方的x25519公钥因而无法对对方加密数据。DID 带来的公钥可发现性W3C DID 标准的核心能力是给定一个 DID总能解析出包含公钥的 DID Document。这正是解决公钥可发现性的关键——Alice 只要知道 Bob 的 DID就能拿到 Bob 的公钥用于加密与验签。提案明确指出当时以太坊社区已有现成实现例如did:ethr与did:3且 JOSE 与 DID 的互操作如 did-jwt也已存在。因此本提案不重新发明轮子而是搭桥让以太坊钱包通过 JSON-RPC 暴露 DID 能力使 DApp 获得标准化的认证JWS 签名与解密JWE 解密接口从而支撑传统 JWT 认证、Secure Data Store、IPFS 加密数据等新兴用例。提案定位与状态在仓库中EIPS/eip-2844.md 的元数据如下eip: 2844title: Add DID related methods to the JSON-RPCauthor: Joel Thorstensson (oed)status: Stagnant停滞未进入最终化流程type: Standards Trackcategory: Interfacecreated: 2020-08-01按照 eip-1.md 对 EIP 类型的定义Interface 类 Standards Track EIP 面向语言级标准与方法命名如同 EIP-6 对方法名的规范、EIP-1474 对 JSON-RPC 方法集的规范。本提案正属于此类它不改变共识层只规定钱包与 DApp 之间 JSON-RPC 方法的名字、参数与返回值语义。值得注意的是其底层 JSON-RPC 规范基础是 EIP-1474Remote procedure call specification同属 Interface 类、同样处于 Stagnant 状态——理解这一点有助于把握该提案的规范层属性它定义的是接口约定而非链上行为。规范总览did_*前缀下的三个方法提案在 JSON-RPC 中新增三个方法统一使用did_*前缀方法作用核心输入核心输出did_authenticate认证当前 RPC 连接并授权路径权限nonce、aud、paths带权限声明的 JWSdid_createJWS创建 JSON Web Signaturepayload、protected、did、revocable含jws属性的对象did_decryptJWE解密给定的 JWEjwe、did含cleartextbase64pad 编码的对象提案不强制任何特定的 DID method 或 JOSE 算法钱包实现者可自由选择这保证了格式对具体密码学实现的无关性。方法一did_authenticate——连接级身份认证与授权语义认证当前 RPC 连接到 DID 方法。钱包应弹窗提示用户是否允许当前连接访问用户 DID 及给定的paths。Paramsnonce—— 随机字符串用作挑战challengeaud—— 认证响应的预期受众audiencepaths—— 字符串数组。Returns一个 general serialization 的 JWS其负载payload包含以下属性nonce—— 原样回显的挑战随机串did—— 完成认证的 DIDpaths—— 被授予权限的路径exp—— Unix 时间戳超过该时间 JWS 应视为无效aud—— 可选受众应与发起请求的域名匹配。此外JWS 的protected header必须额外加入kid属性其值由 DID 及用于签名的keyFragment共同构成以指明签名密钥提案引用了 did-jose-extensions 的细节讨论。该方法在语义上与 EIP-1102 的eth_requestAccounts一脉相承EIP-1102 让 DOM 环境在用户批准前不暴露任何账户did_authenticate则在 DID 语境下做同样的opt-in——未经用户确认不暴露 DID 与路径权限。两者的共同哲学是用户同意consent是钱包暴露身份信息的先决条件。方法二did_createJWS——用 DID 密钥签发标准签名语义创建 JSON Web SignatureJWS。Paramspayload—— 待签名的负载可以是 JSON 对象或base64url编码的字符串protected—— protected headerJSON 对象did—— 用于签名的 DID可携带 key fragment字符串revocable—— 密钥轮换时 JWS 是否可被撤销布尔值默认false。Returns一个对象jws属性上挂载 general serialization 的 JWS。Recommendation签名建议使用secp256k1以太坊已广泛使用备选ed25519。revocable与kid的交互规则这是本方法最值得细读的设计点直接关系签名可验证性与密钥轮换当revocable为false时JWS 签名不应可能被撤销。对did:key这类本身不可撤销的 DID method天然满足对支持密钥撤销的 DID method则必须在kid中包含version-id以精确指向 DID Document 的某个具体版本防止密钥轮换后签名失去可验证锚点当revocable为true时对于支持密钥撤销的 DID methodkid中不得包含version-id——此时签名可随密钥版本演进被撤销。换言之kid是否携带版本信息是调用方对签名是否可被撤销的显式声明。方法三did_decryptJWE——基于路径权限的解密语义解密给定的 JWEJSON Web Encryption。Paramsjwe—— general serialization 的 JWE字符串did—— 尝试解密的 DID字符串。Returns一个对象明文cleartext以base64pad编码multibase 规范下的 base64 变体带填充赋给cleartext属性。Recommendation解密建议使用xchacha20poly1305AEAD配合x25519做密钥协商。与权限系统的联动关键设计如果明文对象中含paths属性且其中某条路径已通过did_authenticate认证则解密可无需用户确认直接完成。这使先授权路径、后自动解密的流程得以成立避免每次解密都打断用户。Rationale为什么选 DID JOSE提案的 Rationale 部分阐明两个决策依据复用成熟标准DID 与 JOSE 在现有系统与新系统中已有广泛支持钱包实现者可自行选择要支持的签名与加密算法因为这两种格式对具体密码学实现保持中立避免数据锁定权限系统受此前社区评论启发issue #130 的讨论等采用路径前缀而非origin 绑定从而避免围绕来源域origin形成数据锁定。权限系统基于路径前缀的轻量授权提案提出一个简单权限模型客户端可通过路径前缀请求权限例如/some/permission请求解密 JWE 时钱包检查解密后负载是否含paths属性若不含该属性用户可能被提示确认当前 RPC 连接即该 DApp是否允许读取解密数据若含paths属性字符串数组则逐一比对其中路径前缀与用户已授权的前缀只要命中其一解密即自动进行无需用户确认。该模型刻意保持简单它只规定路径前缀匹配这一核心机制至于钱包如何向用户征求同意UI 形态、超时策略等完全交由钱包实现者决定。这也直接呼应了提案的安全考量章节——权限系统是该 EIP 最主要的安全考量点但提案不深入威胁模型只给出建议方向。安全考量与算法建议标准可信度JOSE 与 DID 均经过大量公开审查其自身安全性不在本文档讨论范围签名算法推荐secp256k1以太坊原生算法签名验证生态成熟备选ed25519加解密算法推荐xchacha20poly1305广泛可用、性能出色、已用于 TLS配合x25519密钥协商权限系统的责任边界最主要的攻击面是权限系统本身但 EIP 不规定其细粒度工作方式最终由钱包实现决定如何征求用户同意。参考实现与生态印证提案正文列出了多个参考实现均来自 DID/JOSE 生态可视为该接口设计的落地佐证项目角色IdentityWallet3box/identity-wallet-js钱包侧did_*方法的实现基于 3ID DIDkey-did-provider-ed25519ceramicnetwork钱包侧did_*方法实现基于did:keyjs-didceramicnetwork消费did_*方法的小型库MinimalCipherdigitalbazaarJWE 的 DID 相关加密实现从实现分布可以看出该提案的双端结构钱包端IdentityWallet、key-did-provider-ed25519实现did_*方法提供签名与解密能力应用端js-did作为客户端消费这些方法MinimalCipher 则补充 JWE 加密侧实现。这印证了提案的互操作目标——同一套方法约定可同时服务于不同 DID method3ID、did:key与不同算法组合。结语一份接口规范的遗产与启示EIP-2844 最终停留在 Stagnant 状态未成为最终标准但它在以太坊钱包接口演进中留下了清晰印记它将身份从地址提升到DID 文档可发现公钥的层面并将签名/加密统一到 JOSE 标准格式同时以路径前缀权限系统平衡了可用性与用户授权。对于今天仍在设计钱包 DID 可验证数据接口的开发者而言本提案的三个方法、revocable/kid的版本语义、路径前缀授权模型依然是值得直接参考的接口蓝本。其底层依赖的 EIP-1474 JSON-RPC 规范 与同源授权思想 EIP-1102 也一并收录于本仓库可供交叉阅读。注本文所有内容基于仓库中 EIPS/eip-2844.md 原文整理涉及的算法推荐、权限模型与实现信息均以该文档记载为准EIP-2844 状态为 Stagnant任何基于本文的实现决策都应结合最新生态现状评估。【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考