- For setting up an HTTP server, whether for internal use, over the open internet, or both, we recommend using our dockerized HTTP server. Instructions below
- Instructions for building manually can be found on the main Installation page
- Rather than design our own API, we have opted to adopt (and contribute to) the W3C Credentials Community Group's neutral, open standard for VC-handling APIs, the vc-http-api; we invite you to consider doing the same for your projects, if it is a reasonable fit for your needs. For details, see that project's documentation and its separate use cases document.
- The server is run as a Rust "Tower" Service, which can be spun up with a single line upon installation.
The HTTP server is containerised and available under
You can use the images as a CLI:
Note: You can pass JWKs either by sharing a volume with
docker run --volume, or by passing the JWK directly with
docker run -e JWK=$MY_JWKor
docker run didkit-http --jwk $MY_JWK.
See the repo's Dockerfile for further details.
Run a DIDKit HTTP server. The command outputs the URL it is listening on, and runs until interrupted.
-s, --host <host>- Hostname to listen on. Default is
-p, --port <port>- Port to listen on. Default is a random OS-chosen port.
-k, --key <key>- Filename of a JWK to use for issuing credentials and presentations.
-j, --jwk <jwk>- JWK to use for issuing credentials and presentations.
Provide issuer keys using the
--jwk options. If none are provided, issuance functionality will be unavailable. If one is provided, that one will be used to sign all credentials and presentations, regardless of the proof options in the issuance request. If more than one key is provided, the issuance request may identify which key to use for signing by its DID in the
verificationMethod property of the proof options; if none is identified in that property, the first key is used.
You can set the environment variable
HTTP_PROXY to have DIDKit use a proxy.
Both HTTP and SOCKS protocols are supported.
didkit-http contains DIDKit's HTTP server implementation as a Rust
didkit_http::DIDKitHTTPMakeSvc implements a Tower
The following routes implement W3C CCG's VC HTTP API (vc-http-api) v0.0.1. POST bodies should be typed as
application/json. Output will be
application/json on success; on error it will be either
application/json or plain text. For more details, see the documentation for the vc-http-api specification.
Issue a verifiable credential. The server uses its configured key and the given linked data proof options to generate a proof and append it to the given credential. On success, the resulting verifiable credential is returned, with HTTP status 201.
Verify a verifiable credential. The server verifies the given credential with the given linked data proof options. To successfully verify, the credential must contain at least one proof that verifies successfully. Verification results include a list of checks performed, warnings that should be flagged to the user, and errors encountered. On success, the errors list will be empty, and the HTTP status code will be 200.
Create a verifiable presentation. Given a presentation and linked data proof options, the server uses its key to generate a proof and append it to the presentation. On success, returns the verifiable presentation and HTTP status 201.
Verify a verifiable presentation using the given proof options. Returns a verification result. HTTP status 200 indicates successful verification.
|DIF Universal Resolver Driver, Dockerized HTTP server||DIF Universal Resolver repo|