3 个不稳定版本

0.2.0 2022 年 3 月 4 日
0.1.1 2021 年 9 月 22 日
0.1.0 2021 年 4 月 14 日

#662 in HTTP 服务器

Apache-2.0Apache-2.0…

205KB
4K SLoC

DIDKit HTTP

DIDKit 将其功能作为 HTTP 服务器公开。

构建

$ cargo build

安装

$ cargo install --path .

CLI

didkit-http

运行 DIDKit HTTP 服务器。命令输出正在监听的 URL,并在被中断之前运行。

选项

  • -s, --host <host> - 要监听的域名。默认为 127.0.0.1
  • -p, --port <port> - 要监听的端口。默认为操作系统选择的随机端口。
  • -k, --key <key> - 用于颁发凭证和展示的 JWK 的文件名。
  • -j, --jwk <jwk> - 用于颁发凭证和展示的 JWK。
  • -r, --did-resolver <url> - DID 解析 HTTP(S) 端点 URL,用于解析 DIDs 和内部解析器不支持的反向解析 DID URLs。等同于环境变量 DID_RESOLVER

发行者密钥

使用 -/--key-path-/--jwk 选项提供发行者密钥。如果没有提供,则发行功能不可用。如果提供了一个,则该密钥将被用于签名所有凭证和陈述,无论发行请求中的证明选项如何。如果提供了多个密钥,发行请求可以通过证明选项中 verificationMethod 属性中的 DID 识别要用于签名的密钥;如果在该属性中没有识别出密钥,则使用第一个密钥。

Rust 库

Rust 包 didkit-http 包含了 DIDKit 的 HTTP 服务器实现作为一个 Rust 库。结构体 didkit_http::DIDKitHTTPMakeSvc 实现了 Tower (hyper) Service)。

API

可验证凭证和可验证陈述

以下路由实现了 W3C CCG 的 VC (HTTP) API (vc-http-api) v0.0.1。POST 主体应该是 application/json。成功输出将是 application/json;在错误情况下,它将是 application/json 或纯文本。有关更多详细信息,请参阅 vc-api

限制

最大负载大小

DIDKit HTTP 的 POST 端点实现了 2MB 的请求负载最大大小,以防止因过大的负载而耗尽资源。此限制在常量 MAX_BODY_LENGTH 中,但在将来可能会使其可配置:[https://github.com/spruceid/didkit/issues/236](https://github.com/spruceid/didkit/issues/236)。

POST /credentials/issue

发行一个可验证凭证。服务器使用其配置的密钥和给定的链接数据证明选项来生成一个证明并将其附加到给定的凭证。成功时,返回生成的可验证凭证,HTTP 状态码为 201。

POST /credentials/verify

验证一个可验证凭证。服务器使用给定的链接数据证明选项验证给定的凭证。为了成功验证,凭证必须至少包含一个验证成功的证明。验证结果包括执行检查的列表、应向用户标记的警告以及遇到的错误。成功时,错误列表将为空,HTTP 状态码为 200。

POST /presentations/prove

创建一个可验证陈述。给定一个陈述和链接数据证明选项,服务器使用其密钥生成一个证明并将其附加到陈述。成功时,返回可验证陈述和 HTTP 状态码 201。

POST /presentations/verify

使用给定的证明选项验证一个可验证陈述。返回验证结果。HTTP 状态码 200 表示验证成功。

DIDs (去中心化标识符)

以下路由实现了 DID 解析 HTTP(S) 绑定

GET /identifiers/<uri>

将DID解析为DID文档,或将DID URL解析为资源。参数 <uri> 是要解析或解引用的DID或DID URL。

安全考虑

Spruce除了在反向代理的情况下,不使用任何生产环境中的DIDKit HTTP,并且不推荐在没有全面审查安全级别的情况下用于生产用例。以下列表并不全面,但在任何此类审查中都应予以考虑。

授权

DIDKit HTTP没有实现任何端点授权或访问控制。任何客户端都可以使用发行凭证/展示端点从服务器密钥请求签名/证明。为了限制对DIDKit HTTP的一些或所有端点的访问,应部署DIDKit HTTP后端带有适当设置的代理。

拒绝服务

DIDKit HTTP没有实现针对资源耗尽的完全保护。客户端可能通过过慢和/或并发请求使服务器过载。为了防止资源耗尽,部署应使用具有速率限制的代理、在多个DIDKit HTTP实例之间进行负载均衡,以及/或其他保护措施。

依赖

~49–67MB
~1M SLoC