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.
In this example 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
- 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 credential, and outputs the resulting newly-issued verifiable credential on standard output, which we save to a file.
- We pass the newly-issued verifiable credential back to didkit for verification using the given verification method and proof purpose.
- DIDKit outputs the verification result as JSON.
- 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.
- 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.
- Pass the verifiable presentation back to didkit for verification.
- Examine the verification result JSON.
Also available on Github as /cli/tests/example.sh