Specifications and Dependencies

t Spruce, we consider it essential to be very explicit and up-front about our definition of standards compliance, our evidence to back that up, and the open-source dependencies and libraries which power our security and trust guarantees. To this end, we maintain both lists here, and think that both are as important as our changelogs.

Specifications and Test Suites

To demonstrate our commitment to standards and interoperability, we have ensured that our implementation conforms to the following specifications and aspire to pass their test suites where applicable:

• W3C Verifiable CredentialsTest Suite (passing, instructions)

• W3C Decentralized Identifiers (test suite pending CR, syntax support)

• VC HTTP API Test Suite v0.0.1 (passing, instructions)

• RDF Dataset Normalization Test Cases (passing)

• JSON-LD to RDF Transformation Test Cases (440/450 passing)

• Linked Data Proofs 1.0

• DID Resolution

• IETF: JWT, JWS, JWK, JWA, CFRG ECDH and Signatures in JOSE

Cryptography Backends

We strongly prefer tried and tested implementations of cryptographic functions and believe that it's most responsible to list them out in a forthcoming manner to any potential users.

DIDKit is engineered so that the target platform and compile-time flags may be used to specify different cryptographic backends, such as to leverage native hardware capabilities, cross-compile to e.g. WASM, or to give advanced users the option to only use libraries that they trust.

• 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.

• native-tls (openssl, security_framework, or schannel; via hyper-tls): optionally for HTTPS.

If you have constructive opinions about the set of cryptographic libraries that should be supported, please open an issue.