This marks the first donation of a Rust “crate” (package) to the group
Over the years, the Identifiers and Discovery WG at the DIF has received many donations that form a vital resource for developers of DID-based systems: recently, a flotilla of complementary secret recovery mechanisms, a command-line tool for handling Verifiable Credentials that was the foundation for years of JWT work in the Ethereum community, the .well-known specification, and the /did-common-{language}/ series of basic libraries and tooling in various popular languages, to say nothing of the donations of drivers for the open-ended Universal Resolver project.
The newest donation to the I&D WG archive is an implementation of did:key built in the Rust language by long-time active DIF members, Trinsic. In addition to being great news for the I&D WG itself, it is also great news for the “target audience” of the WG: developers trying to smoothly and efficiently extend the domain of DID-based systems to new programming languages, use cases, and contexts.
Don’t all DIDs contain keys?
DID:Key, originally specified in the W3C Credentials Community Group (CCG), is a DID “pseudo-method” that allows static, pre-existing, and/or pre-published public keys to function like traditional DIDs — they can be queried, stored, issued against, and resolved to return valid DID documents. These DID documents, or “pseudo-documents” if you prefer, are generated deterministically from their public keys, allowing the integration of complex key management systems involving cold storage, hardware security modules, etc.
This “masquerade” of wrapping external or pre-existing keypairs in the form of a valid DID is crucial to many kinds of interoperability, legacy integration, and testing. It can be a life-saver in both the early days and the home-stretch of moving to production in the messy real world of legacy systems and interoperability stress-testing.
Like the /did-common-{language}/ series, a plug-and-play library that handles all the transformations between different kinds of key and their “DID-ification” is a huge time-saver for people working in new contexts, or contexts where prior art has not yet been open-sourced. In addition to these advantages, the unique design of did:key has also been valuable in demonstrating the flexibility and universality of the DID concept itself — and that DIDs can seamlessly interoperate with systems that do require a blockchain or similar technologies.
Rust and DIF
Rust has earned a reputation among contemporary blockchain and web developer communities, in large part because it is so performant, controllable, and versatile across in-browser, server-side, and cloud environments. It plays nicely with widely different programming languages as well.
In particular, it has also been designed to be smoothly integrated into JavaScript systems, for decades the most common language in most kinds of web development. In fact, many of today’s JS developers consume Rust/WASM libraries without even knowing they’re doing so. The libraries from Hyperledger Aries, for instance, use Rust cryptographic libraries packaged and managed by the Hyperledger Ursa project.
One crucial distinction, however, between Rust and Javascript is that the former has a drastically different way of managing dependencies and packages. In addition to being very resource-conscious in their assembly, “crates” (as the packages are called in Rust’s native “cargo” package management system) can be imported and compiled selectively, using only what each project needs “at build”. For in-browser, edge-device, and other resource-constrained environments, this makes a world of difference compared to traditional JS frameworks like Node or Angular.
While the authoritative branch of the source code is being donated to DIF where it will stay open to new issues and pull requests from the DIF community, the “crate” is already available at crates.io, and can be used directly in your project’s Cargo.toml file:
did-key = “*”
Extending the library
Like all code donations to DIF, there are many ways in which this library can be extended. GitHub issues and pull requests are open! So far, the key formats currently supported are:
- BLS12381 (G1 & G2 derivations)
- Ed25519
- X25519
- NIST P256
- Secp256k1
If you find this project useful in your own development, whether for compliance-testing, for supporting new verifiable credential formats like BBS+, or for extending your interoperability and compatibility reach, please leave an issue describing future features you might find useful. Better still, if you have experience with Rust/WASM, please consider getting involved and contributing features, leaving constructive feedback, or extending the specification’s documentation and implementation guidance notes.
We also welcome you to join and participate in the I&D Working Group, regarding any questions or contributions to the Rust did:key implementation or one of the other work items!