DIDKit v0.1 is Live

SpruceID -

DIDKit v0.1 pushed to GitHub with its core features, documentation, and interfaces intact.

DIDKit is a lightweight set of Rust libraries containing a command-line interface and an HTTP interface. Both interfaces expose the core Verifiable Credential-handling capabilities of Spruce’s ssi library. Both ssi and didkit are being open-sourced this week to allow “early access” to the core source code, for review and consideration in advance of a substantial third-party audit.

But what exactly are “VC capabilities,” or for that matter, “DID capabilities”? Why is it so hard to find pluggable libraries that bring them to your project?

What is novel about DIDKit

Ambitious end-to-end DID/VC systems like the “agent frameworks” of the Hyperledger Aries project invite developers to build out a whole new kind of cloud architecture rather than integrating to today’s clouds, browsers, and enterprise ecosystems. This has channeled the energies of countless early adopters and experimenters and created a fascinating ecosystem, but it does not provide developers new to the space with architecturally un-opinionated, readily pluggable libraries.

Most other options are subtly locked to a specific blockchain and its particularities, which a self-sovereign identity (SSI) novice is unlikely to notice until months into a project based on it. A few open-source libraries exist to sidestep this infrastructural lock-in, but these are more like primitives for assembling an SSI toolkit than ready-to-go, developer-friendly libraries. DIDKit, on the other hand, is ready to start processing real-world VCs with non-repudiable signatures right out the box. It’s licensed under Apache 2.0, and we will soon accept contributions under CLA.

Like most SSI systems that strive to be developer-friendly and performant above all else, we are tuning our projects to function optimally with one specific DID method: did:tz, which we are finalizing in parallel within the Tezos core developer ecosystem. We pride ourselves, however, on having built our module system in the most infrastructure-agnostic way possible, strictly conformant to the letter and the spirit of the DID core specifications.

DIDKit’s unique superpowers

DIDKit, importantly, was designed to be modular and un-opinionated about anchoring and smart-contract-level concerns, at an arm’s remove from the did:tz design process. The core LD-Proof signing and verification engine that DIDKit wraps was designed from the beginning to work as securely and performantly as possible, regardless of which DID method drivers are compiled along with it or what kinds of DIDs and VCs it is consuming.

Our goal is for DIDKit to be a general-purpose, white-label engine at the core of almost any credential-handling data flow. We want it to be lightweight and flexible and performant enough for the widest possible range of contexts and topographies. This means that shell scripts, sysadmins, cross-application automations, and even web servers can start issuing verifiable W3C-conforming JSON-LD credentials to log events, store data, and send and receive signed, trustworthy messages.

Who needs this (and doesn’t know it)

If you’re new to SSI, and want to see close up how all the parts work, there’s no better way to get up to speed than building a prototype around DIDKit. DIDKit can be the server or command-line tool at the heart of your prototype, but you can also write a batch generation script in under a minute that gives you a huge corpus of dummy-data credentials to help you test or benchmark that prototype. And after you’re done building a working prototype, pop the hood and take a look at the inner workings, even if you’re new to cryptography and protocol-level work. (Don’t be scared off by it being written in Rust — anyone proficient in JavaScript should be able to parse it well enough, with a few pointers.)

If it’s not a prototype you’re wrangling but a live, mission-critical legacy system, you are likely to prioritize flexibility. DIDKit, integrated via a Java or C foreign function interface, could be used to bring legacy systems and their data into the 21st century, seamlessly and reliably emitting VCs from deep in the racks of an on-premise mainframe or a server farm you need a security-clearance to patch.

More agile webs of “API businesses” and VC-powered marketplaces for services and cloud-native widgets have their own integration needs and dependency policies. DIDKit is lightweight enough to run on an IoT device, or in a microservice architecture, or in any number of next-generation API-to-API business contexts. Indeed, trustworthy and encrypted verifiable credentials might just be the quantum leap that enables a whole new level of cloud-native businesses, that can securely and confidentially process sensitive data in a zero-trust architecture.

Core Feature-set in v0.1

DIDKit’s core feature-set is expanding steadily over time and we are committed to doing this development in the open, so feel free to engage with the repository directly on github. Currently, DIDKit supports the following features:

  1. Generating unique keys
  2. Wrapping keys in a did:key document
  3. Issuing W3C specification-conforming, JSON-LD verifiable credentials, signed by a local and/or passed key
  4. Verifying W3C specification-conforming, JSON-LD verifiable credentials

DID Methods supported so far:

  • did:tz (anchored to the Tezos mainnet 1, using Ed25519 keys natively)
  • did:key wrapping keys generated locally, including keys stored in on-device secure enclaves when compiled inside the Credible Wallet
  • did:web, which allows a subject to host its own DID document via web domain, to be resolved by a straightforward HTTPS request like a webpage

Proof types supported so far:

Cryptographic libraries selectable at compile time so far:

  • ring, v0.16: default for hashes, ed25519 functions, RSA, and randomness. The ed25519 functions here cannot currently compile to WASM.
  • rsa, v0.3: optionally for RSA.
  • ed25519-dalek, v1: optionally for ed25519. Compiles to WASM.
  • rand, v0.7: optionally for randomness.
  • sha2, v0.9: optionally for sha256 hashes.

SDKs embedding all of the above functionality for the following development platforms:

Test suites passing:

Coming soon

The following features have been tentatively roadmapped for the next major release:

  1. Exposing interfaces for JWT-based Verifiable Credential workflows
  2. Editor interface for building conformant JSON-LD contexts
  3. Registration of several new LD signature suites and support for new cryptography
  4. Further DID method support: did-tezos (tz2/tz3 and resolution layers 2 and 3), did-btcr, did-onion
  5. SDKs for PHP, Python, Ruby/Rails, Go, C#, C++
  6. BBS+ signatures
  7. DIDComm v2 messaging protocol support
  8. Presentation Exchange support
  9. Aries interoperability profile support
  10. SDK for JavaScript/ES6 (distributed via npm)
  11. Thoroughly documented WASM cross-compilations

Follow us on Twitter

Follow us on LinkedIn