did-toolkit: a toolkit for Decentralized Identity Documents in rust-lang
DID is a relatively new spec for decentralized
identity. This toolkit aims to support as much of the spec as it can, allowing
you to build services and other tools that are compliant with the
specification.
The toolkit makes a sincere best-effort to maximize compliance with did-core,
and eventually the did-method-web spec. Decentralized Identity Foundation specs
such as DWN and
other specs I hope will follow.
Currently Supported Features
- DID (identifier-only) syntax
- Parsing from strings
- Generation from pre-populated struct
- Construction of DID URLs from DIDs when provided additional URL properties
- DID URL (different from DID)
- Parsing absolute URLs, and mapping relative URLs from absolute ones
- Generation from pre-populated struct
- Decomposition into the DID that the URL is made from
- DID Document serialization and de-serialization
- Preliminary support for registry-supported types
- Types with "issues" were elided for implementation safety's sake
- Capable of generating JWK ECDSA keys with the P256 curve. More coming here.
- Preliminary, basic, in-memory Registry. Provides:
- mapping of documents to DIDs
- cross-referencing of alsoKnownAs in complimentary DIDs as equivalent
- controller verification
- Lookup of verification method
- Optional caching of remote documents on-demand
- Loading of documents from JSON or CBOR
- Command-line tool
did-toolkit
generates documents for fuzz testing your registry or DID-compliant implementation:
- Generation of documents that are inter-linked via the
alsoKnownAs
and controller
properties
- Generates verification methods for every attribute that takes them
- For attributes that also take a DID URL in place of a verification method, occasionally generates attribute properties which are simply links into other verification methods
- It also generates ASCII percent-encoded DIDs that are non-compliant with UTF-8
- Should break some implementations that use UTF-8 strings to parse these
- Optional generation to CBOR (JSON is the default)
Planned Features
Regarding support in general:
- Consumption of formats:
- JSON-LD support is not planned due to the existing JSON-LD parser
implementations requiring non-standard JSON libraries that don't
integrate with anything else, including reqwest, which is used to locate
remote documents. If someone designs a JSON-LD implementation I can
simply consume I will bother. I have some personal and pointed feelings
about this standard as a former, scar-riddled consumer of XML standards
that insist I do not attempt to implement this myself.
Author
Erik Hollensbe erik+github@hollensbe.org
License
MIT