Alert Source Discuss
🚧 Stagnant Standards Track: Interface

EIP-2844: 向 JSON-RPC 添加与 DID 相关的方法

Authors Joel Thorstensson (@oed)
Created 2020-08-01
Discussion Link https://github.com/ethereum/EIPs/issues/2845

Table of Contents

简单总结

在新的 did_* 前缀下，向 JSON-RPC 添加新方法以用于签名和解密 JOSE 对象。

摘要

此 EIP 描述了要添加到 JSON-RPC 的三个新方法，这些方法使钱包能够支持去中心化身份标识符 (DID) 以及JSON 对象签名和加密 (JOSE)。这些标准使钱包能够支持数据解密以及经过身份验证的数据，两者都使用 JOSE 标准格式。借助这些新方法，应用程序可以从用户钱包请求 DID，从中可以解析 DID 文档。 DID 文档包含可用于加密和签名验证的公钥。这使得 Alice 仅通过知道 Bob 的 DID 即可发现 Bob 的公钥。此 EIP 不强制使用任何特定的 DID 方法或 JOSE 算法，钱包可以随意实现这些方法。

动机

之前已经进行过一次主要的尝试 (#130, #1098)，以标准方式向以太坊钱包添加解密功能。之前的方法使用了一种非标准的方式来编码和表示使用 x25519-xsalsa20-poly1305 加密的数据。虽然这种方法确实提供了一种向钱包添加加密支持的功能性方法，但它没有考虑到在标准化加密数据表示方式方面所做的类似工作，即使用 JOSE。这是 IETF 提出的用于表示签名和加密对象的标准。先前方法的另一个缺点是，如果仅知道以太坊地址，则无法从另一个用户那里检索 x25519 公钥。公钥发现是 W3C DID 标准工作的核心，在该标准中，给定一个 DID，始终可以发现包含公钥的文档。该标准的实现已经存在，并在以太坊社区内得到采用，例如 did:ethr 和 did:3。 JOSE 和 DID 之间的互操作性 已经存在，并且正在努力 加强它。添加对 JOSE 和 DID 的支持将使以太坊钱包能够支持广泛的新用例，例如使用 JWT 的更传统的身份验证，以及新的新兴技术，例如 安全数据存储 和 IPFS 中的加密数据。

规格

在新的 did_* 前缀下指定了三种新的 JSON-RPC 方法。

身份验证

验证当前 rpc 连接到 DID 方法。

提示用户授予当前连接访问用户 DID 和给定 paths 的权限。

方法:

did_authenticate

参数:
  • nonce - 用作质询的随机字符串
  • aud - 身份验证响应的预期受众
  • paths - 字符串数组
返回:

包含以下属性的具有通用序列化的 JWS：

  • nonce - 用作质询的随机字符串

  • did - 授予身份验证的 DID
  • paths - 授予权限的路径
  • exp - JWS 应被视为无效的 unix 时间戳
  • aud - JWS 的可选受众，应与发出请求的域匹配

应将具有表示 DID 的值的附加属性 kid 和用于签署 JWS 的 keyFragment 添加到受保护的标头 (详细信息)。

CreateJWS

创建 JSON Web 签名 (JWS)。

应将具有表示 DID 的值的附加属性 kid 和用于签署 JWS 的 keyFragment 添加到受保护的标头 (详细信息)。当 revocable 设置为 false 时，不应可以撤销 JWS 签名。对于某些 DID 方法，例如 did:key，情况总是如此。对于其他支持密钥撤销的方法，需要在 kid 中包含 version-id 以引用 DID 文档的特定版本。当 revocable 设置为 true 时，对于支持密钥撤销的 DID 方法，version-id 不得包含在 kid 中。

方法:

did_createJWS

参数:
  • payload - 要签名的有效负载，json 对象或 base64url 编码的字符串
  • protected - 受保护的标头，json 对象
  • did - 应签署消息的 DID，可能包括密钥片段，字符串
  • revocable - 密钥轮换时使 JWS 可撤销，布尔值默认为 false
返回:

一个对象，该对象在 jws 属性上包含具有通用序列化的 JWS。

建议:

使用 secp256k1 进行签名，或者使用 ed25519。

DecryptJWE

解密给定的 JWE。

如果 cleartext 对象包含一个属性 paths，该属性包含一个字符串数组，并且其中的一个路径已经使用 did_authenticate 进行了身份验证，则应在没有用户确认的情况下进行解密。

方法:

did_decryptJWE

参数:
  • jwe - 具有通用序列化的 JWE，字符串
  • did - 应该尝试解密 JWE 的 DID，字符串
返回:

一个对象，该对象包含使用 base64pad 编码的 cleartext，并分配给 cleartext 属性。

建议:

使用 xchacha20poly1305 和 x25519 实现密钥协商解密。

理由

此 EIP 选择依赖 DID 和 JOSE，因为许多当前系统和新系统已经在许多地方支持这些标准。通过使用 DID 和 JOSE，钱包实现者还可以选择他们想要支持的签名和加密算法，因为这些格式对于特定的加密实现来说是相当不可知的。

权限系统

提出了一个简单的权限系统，客户端可以通过路径前缀请求权限，例如 /some/permission。当请求解密 JWE 时，钱包应检查解密的有效负载是否包含 paths 属性。如果此属性不存在，则可能会提示用户确认是否允许给定的 rpc 连接（应用程序）读取解密的数据。如果 paths 属性存在于解密的数据中，它应该包含一个字符串路径数组。如果其中一个路径前缀与用户已经授予权限的路径前缀之一匹配，则应自动进行解密，而无需任何用户确认。

这个简单的权限系统受到之前的一些评论 (1, 2) 的启发，但避免了围绕来源的数据锁定。

实施

IdentityWallet: 使用 3ID DID 实现钱包端的 did_* 方法。

key-did-provider-ed25519: 使用 did:key 方法实现钱包端的 did_* 方法。

js-did: 一个使用 did_* 方法的小型库。

MinimalCipher: 用于 JWE 的 DID 相关加密的实现。

安全考虑

JOSE 和 DID 都是经过大量审查的标准。本文档不考虑它们的安全性。在规范部分，给出了关于使用哪种算法的建议。对于签名，以太坊已经使用了 secp256k1，对于解密，xchacha20poly1305 被广泛使用，性能非常好，并且已经在 TLS 中使用。

此 EIP 的主要安全考虑因素是建议的权限系统。这里可以考虑各种威胁模型。但是，除了提出一种方法之外，此 EIP 没有详细说明它应该如何工作。最终，由钱包实现来选择如何征求用户的同意。

版权

通过 CC0 放弃版权及相关权利。

Citation

Please cite this document as:

Joel Thorstensson (@oed), "EIP-2844: 向 JSON-RPC 添加与 DID 相关的方法 [DRAFT]," Ethereum Improvement Proposals, no. 2844, August 2020. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-2844.