参考

DID Connect 工作流程

术语表#

我们可以将完整的 DID Connect 流程称为 DID Connect 会话，会话中涉及的各方包括

  • 用户(代理)：通常指支持 DID Connect 协议的数字钱包，能够管理用户的数字身份和数字资产，例如 DID Wallet
  • DApp：可以是任何类型的去中心化应用，在DID Connect会话中的应用通常需要用户提供某些信息来完成特定的业务流程，在ArcBlock生态系统中，应用通常被称为 Blocklet。
  • Relay：在 DID Connect 过程中，Relay 负责维护会话状态，并中继和验证应用程序请求与用户响应。该服务通常部署于 Web 服务器，依赖底层存储持久化会话状态。
  • 请求声明：指应用程序依照协议组装并发送给用户的数据项，用以阐明其需要用户执行的各项操作。可同时发送多个请求。
  • 响应声明：指用户在审查并同意应用程序的请求后，由钱包组装并提交给应用程序的数据片段。

流程图#

完整的 DID Connect 会话 流程如下图所示。

Image

对各步骤的说明如下。

  1. 用户通过提供数字身份、数据签名、交易签名、可验证声明、资产所有权证明、通行证等信息，与应用程序进行交互。
  2. 应用程序会生成一个 DID Connect 会话，并将其保存至 Relay，从而获取该会话的 deepLink
  3. 应用程序向用户呈现 deepLink 二维码，用户使用 DID Wallet 扫描该二维码。
  4. 钱包扫码完成后，应用程序会将从用户处获取的所需信息（请求声明）以标准格式保存至 Relay。
  5. 钱包从应用程序获取到所请求的声明，解析后将其呈现给用户。
  6. 用户审阅并同意该钱包
  7. 钱包将响应（Response Claims）提交至 Relay，该响应会由 Relay 进行验证并存储在会话中。
  8. 应用程序通过订阅或轮询获取钱包的响应，进而继续业务流程

针对上述流程的补充说明。

  • 步骤4 独立于步骤2 进行合并，以便在某些情况下，应用程序可以在确定需要用户何种确切信息之前，知晓用户的身份。例如，当应用程序需要为某个账户提供通行证时。
  • 在第六步，用户可选择在钱包中拒绝，应用程序将收到拒绝通知，并可执行相应回调。
  • 在步骤 7，若当前会话需分多步处理，则将重复步骤 5，直至所有步骤完成。
  • 为确保良好的用户体验，DID Connect 会话中的大部分等待均已设置超时。

此外，步骤4和8可能不会在浏览器中执行。这主要是因为某些计算无法在浏览器端完成，另一些则因其敏感性而不适宜在此环境下进行。

  • 应用程序可以在会话创建时提供一个 API，供 Relay 在钱包被清空时请求，以获取 Requested Claims。
  • 应用程序可在会话创建时提供一个API，当钱包提交响应声明时，Relay便会将请求转发至此。

在这种情况下，整个过程如下图所示。

Image

状态机视角#

如果您并非开发人员，本部分可略过。

因为整个 DID Connect 流程涉及钱包、应用程序、用户以及可能的远程 API，其状态流转及分支情况复杂，因此，一个 DID Connect 会话 的完整过程最适宜通过 状态机 进行描述。

正常情况下，一个成功的 DID Connect 会话 的完整状态变更序列是

  • 启动: 会话已启动
  • 加载中: 指会话正在创建或加载中
  • 已创建：会话已成功创建，待扫描。
  • 钱包扫描: 钱包已扫描
  • walletConnected: 钱包已选择当前会话使用的身份
  • appConnected: 应用已确定当前会话所需的请求声明
  • 钱包已批准: 钱包已核阅并提交了其响应声明
  • appApproved: 应用程序已处理响应声明，并已作出回应。
  • 已完成: 会话已结束

除了这些正常流程之外，一个 DID Connect 会话可能会处于多种异常状态。

  • 已拒绝: 用户已在钱包中拒绝当前操作
  • 错误：流程中任何环节发生错误，会话即会终止。
  • 超时：等待钱包或应用程序完成操作时，操作已超出预设时间
  • 取消：用户在浏览器中取消了该操作


DID Connect 协议
类型速查表