Quickstart
Getting started with DIDKit
This guide describes how to perform credential issuance and verification with DIDKit's CLI program.
Step 0: Install DIDKit
To install the DIDKit command line program on GNU/Linux, MacOS, or Windows+WSL, first install cargo. With build-essential
or equivalent tools also installed, run:
This will add the binary didkit
to your Cargo installation (typically ~/.cargo/bin
), which can be added to your system's PATH for ease of use.
You can also build DIDKit CLI from source or install via Docker.
Step 1: Issue and verify your first VC using a DID
W3C Verifiable Credentials are a standard data format for claims expressed in JSON, also known as digital attestations. They contain the claim being made, data schema references, and a digital signature to be verified and consumed by unknown future parties.
Generating a did-key
DID
did-key
DIDTo issue your first credential, you will need a signing key. We will use this key to generate a DID using the did-key
DID method. DIDKit can generate a signing key with the generate-ed25519-key
subcommand to create an Ed25519 private key in the JWK format. Existing JWKs can also be loaded via filepath.
With the signing key prepared and its representation as a did-key known, specify the JSON of the Verifiable Credential to be signed. For this tutorial, you can use the following example.
The @context
property flags this JSON object as a W3C Verifiable Credential, and can be optionally interpreted as JSON-LD, which is out of scope for this tutorial. The id
property is the identifier for the VC, which may be unique and ultimately depends on the system design. The type
property identifies this VC as a base data model, with no additions. The issuer
property contains a URI referring to the issuer of the VC (the did-key generated previously), with issuanceDate
denoting when the VC was issued (now, in UTC).
Finally, the credentialSubject
contains the claim itself, which for this dummy example, contains no information other than the data subject in credentialSubject.id
, which happens to be an example Decentralized Identifier. A full listing of the required or suggested properties for a VC can be found in the VC Data Model specification.
To sign the VC using DIDKit CLI with Decentralized Identifiers, input the path to the signing key, a verification method (-v
), a proof purpose (-p
), and the unsigned credential (stdin
). Verification methods describe how to interpret the signature and check for validity.
Proof purposes add the scope and intent of the signing, and in this example, we will use the proof purpose value of assertionMethod
, which asserts the authenticity of the credential. For more information verification methods and proof purposes, refer to the DID Core specification).
This produces a signed VC, which we will now verify.
You shouldn't see any failed checks, warnings, or errors. For good measure, try modifying the contents of signed-vc.json
and ensuring that it no longer verifies successfully.
Step 2: Verifying a did-web
issued VC
did-web
issued VCIn this example, we will verify a VC generated from Spruce's demo server.
example-vc.json
should resemble the following content:
To verify the VC, run:
You shouldn't see any failed checks, warnings, or errors. For good measure, try modifying the contents of example-vc.json
and ensuring that it no longer verifies successfully. Under the hood, DIDKit will resolve the did-web
DID into a DID Document containing public keys and supported verification methods.
You can resolve a did-web
DID directly by running the following:
Congratulations, you have issued a VC using a did-key
DID, verified it, and also verified a VC issued by a did-web
DID!
Last updated