This is an example shell script using all the core functions of DIDKit-CLI: key generation, credential/presentation issuance and verification.
Note: This script is meant to be in a DIDKit-CLI source directory. See the complete script below for setup details.
DIDKit can generate a unique ed25119 keypair from entropy. Alternately, you can provide a static key locally.
This document gets wrapped around the keypair generated (or passed) in the previous step. For more context on the DID:key method, see the specification.
This is used to identify the key in linked data proofs. Verifiers of such proofs query a DID found in a credential based on what [registered] proof type (i.e., what kind of signatures) it needs key material to verify.
Here, we'll issue an example credential (unsigned) and save it to a file. In this credential, the issuance date, id, and credential subject id are arbitrary, but in real-world usage these are diverse and critical properties. For more info about what these properties mean, see the Verifiable Credentials Data Model specification. Note that SUBJECTDID and ISSUERDID fields need to be URIs, so if you are using non-DID identifiers such as certificates or UUIDs, they need to be prefixed with the approriate URN prefix, i.e., "urn:uuid:", etc.
We ask DIDKit to issue a verifiable credential using the given keypair file, verification method, and proof purpose, passing the unsigned credential on standard input.
DIDKit creates a linked data proof to add to the unsigned credential, and outputs the resulting newly-issued (signed) verifiable credential on standard output, which we save to a file.
We pass the newly-issued signed verifiable credential back to didkit for verification using the given verification method and proof purpose.
DIDKit then outputs the verification result as JSON and saves it. If verification is successful, the command completes successfully (returns exit code 0).
Prepare to present the verifiable credential by wrapping it in a verifiable presentation (VP).
The id here is an arbitrary URL for example purposes; VPs are often but not always uniquely identified, whether by identifiers, URLs, or URIs.
- Pass the unsigned verifiable presentation to DIDKit to be issued as a verifiable presentation. * DIDKit signs the presentation with a linked data proof, using the given keypair, verification method and proof type.
- We save the resulting newly created verifiable presentation to a file.
In most use-cases, the
holder field contains a DID or other identifier verifiably linked to the key material signing the presentation, which has some relationship to the credential(s) being presented. The classic example is a fresh and interactive proof of being the [human] subject identified by a credential, but there are many VP use-cases as well. This may be a manual, consented, unique and interactive identity assurance operation, but it can also be an assurance of the identity of a machine or a legal entity, operated by an API call or an automation carried out by a fiduciary/trusted piece of software, etc.
In these examples, the keys representing the two parties are stored in expressive filenames, 'issuer_key' and 'holder_key'. There are, however, no differences between these keys, and the JWK filenames were chosen simply to clarify the example; there are no restrictions on them.
- We pass the verifiable presentation we created back to DIDKit for verification, and save the results in a JSON.
Also available on Github as /cli/tests/example.sh