Command Line Interface
- 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.
The HTTP server is containerised and available under
ghcr.io/spruceid/didkit-cli
.You can use the Docker image as a CLI:
docker run ghcr.io/spruceid/didkit-cli:latest --help
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_JWK
ordocker run didkit-http --jwk $MY_JWK
.
Each command is called in the form:
didkit help
, didkit generate-ed25519-key
, etc.Output help about
didkit
and its subcommands.-k, --key-path <file>
(required, conflicts with jwk): Filename of JWK file-j, --jwk <jwk>
(required, conflicts with key-path): JWK.
Issue a verifiable credential. Reads credential on stdin, constructs a linked data proof to add to the credential, and outputs the resulting verifiable credential.
The proof type is set automatically based on the key file provided. JWK parameters besides the cryptographic components, such as kid (Key ID), are ignored currently. For an RSA key, the alg (Algorithm) parameter is ignored and
RS256
is used for it, for RsaSignature2018.Options besides
--key-path
correspond to linked data proof options as specified in ld-proofs and vc-http-api.-c, --created <created>
- created property of the proof. ISO8601 datetime. Defaults to the current time.-k, --key-path <key>
(required, conflicts with jwk): Filename of JWK for signing.-j, --jwk <jwk>
(required, conflicts with key-path): JWK for signing.-v, --verification-method <verification-method>
verificationMethod property of the proof. URI for proof verification information, e.g. a public key identifier.
RSA
OKP
(curve
:Ed25519
)
Verify a verifiable credential. Reads verifiable credentials on standard input, and outputs verification result. Returns exit status zero if credential successfully verified, or non-zero if errors were encountered.
Options are linked data proof options as specified in ld-proofs and vc-http-api. If there is more than one proof present, at least one must pass all the requirements passed in the options.
-c, --created <created>
- The created property of the proof must be on or after the given ISO8601 datetime. Defaults to the current time.-v, --verification-method <verification-method>
- The verificationMethod property of the proof must equal this value.
{"checks": [],"warnings": [],"errors": []}
Verification result properties:
checks
- Array of strings indicating checks completed on the credential.warnings
- Array of warnings encountered during validation or verification.errors
- Array of strings indicating errors encountered during validation or verification. Iferrors
is empty, the credential is verified.
Issue a verifiable presentation. Reads presentation on stdin, generates proof to add to it, and outputs the resulting verifiable presentation.
Verify a verifiable presentation. Reads verifiable presentation on stdin, and outputs verification result. Returns exit status zero if presentation successfully verified, or non-zero if errors were encountered.
You can set the environment variable
HTTP_PROXY
to have DIDKit use a proxy. Both HTTP and SOCKS protocols are supported. See the "proxies" section of the DIDKit docs for more details.Tool | Example |
---|---|
Core CLI syntax | |
Batching, Automation |
Last modified 1yr ago