/Verifiable

A .NET implementation of decentralized identifiers and verifiable credentials, some associated protocols and cryptographic routines.

Primary LanguageC#Apache License 2.0Apache-2.0

Verifiable project logo: A shield in blue hues with a rounded top that narrows downwards in a 'V' like shape. In the center there is the tip of white 'V' that elongates across the left corner of the shield to white background. Undernath the lower side of 'V' there is a stylistic key handle also elongating over the edge of the shield.

Decentralized identifiers, verifiable credentials, associated protocols and key management with hardware security elements.

Main build workflow

Mutation testing badge

Features

  • Decentralized identifiers (DID).
  • Verifiable credentials (VC).
  • Various related protocols to DIDs and VCs.
  • Key and secrets management.
  • A simple .NET tool, Verifiable, to use the libraries.
Library NuGet
Verifiable NuGet
Verifiable.NSec NuGet
Verifiable.Core NuGet
Verifiable.BouncyCastle NuGet
Verifiable.Tpm NuGet
Verifiable.Sidetree NuGet
Verifiable.Microsoft NuGet
Verifiable.Jwt NuGet
Verifiable.Security.DataStorage NuGet

Quickly about practicalities

Please, open an issue if you have a suggestion, improvement (e.g. even fixing a typo) or something in mind that could be useful and worth considering.

Pressing . on keyboard on this repository page or when viewing any file to open this codebase in VS Code web editor is also a good way to get a feel of the code. See more great tips at 10 Fun Things You Can Do With GitHub.dev by @lostintangent.

Otherwise the usual things about forking and sending pull requests work too. :)

This is an early version under development. All will be breaking.

This repository contains projects that implement .NET libraries for W3C decentralized identifier specification (DID), Verifiable Credentials and related technologies from Decentralized Identity Foundation (DIF).

In simple terms these libraries implement a specification for documents that have distinquishing identifier, can be signed, linked, timestamped, managed and combined into representations without the necessity of a central, governing party but can also function well with such parties (eIDAS may be one).

Since this technology and its likely applications rely on cryptography, these libraries include basic implementation for management of secrets such as the created documents and their material. Technologies include trusted platform modules (TPM), hardware security modules (HSM) and other potential technology such secure enclaves.

Quick links

The design principles

  • Agnostic to serialization and deserialization library. The design principles for DIDs and VCs and other data elements do not rely on specific deserialization and serialization (e.g. no library specific attributes on types) libraries. Current implementation uses System.Text.Json converters. CBOR could be interesting.
  • Data oriented programming. Or leaning towards it. The code is structured around the idea of parameters going in functions and results from return values. Or in more length: code is separate from (immutable) data, leaning generic data structures and general-purpose functions (extenstions methods and static methods).
  • Sensitive memory is ring-fenced using types. The goal is to recognize sensitive key material and handle it appropriately (noting security practices and regulations). Currently public, private and other key material is ring-fenced to types. The types are wrappes that know how to point to and and unwrap material to operations. The material can be allocated using MemoryPool<T> and so a custom allocator can be provided (e.g. for mlocked memory regions).
  • Agnostic to underlying cryptographic implementation. The design should allow using external, special libraries. Currently BouncyCastle, NSec.Cryptography and .NET standard cryptography are included (TPM is in progress).
  • Hardware security elements. It should be possible to use hardware security elements, such as trusted platform modules.
  • Developer experience. Writing against an evolving specification or some specific specifications can be difficult. It takes time to learn. So code shoud link in comments to W3C and RFCs where appropriate (see code for examples).
  • Tests and tests that use real data. There should be as much tests as possible. Also thests that use as test vectors data from other implementations to cross-check.

Vulnerability disclosure

If you find a vulnerability in this project please let us know as soon as possibly. For secure disclosure, please see the security policy.

Contributing

Please, read contribution guidelines for technicalities.

For development, the code and project should run on Windows, Linux and MacOS. Some hardware specific elements may work on only some operating systems.

Community at TPM.DEV for TPM related study materials and discussions could be great, they have also.

Taking something from contribution guide and adding specific ideas.

The usual things :)

👀 Please, do write issues.

🙌 By all means, do create pull requests (see contribution guidelines).

⭐ Stars are always nice. :)

The code things

✅ Adding tests is really good, of course.

💻 adding TPM functionality (signing, encryption, permissions) – and tests.

💭 Issue templates and other improvements to project.

🚀 improve continuous integration automation is always good!

🔐 Add more cryptographic and security capabilities.

🔑 As a corollary, add X509 related functionality.

📘 Support for more protocols (see at https://identity.foundation/).

The things writing code

📝 Threat and privacy modelling diagrams and explanations would be cool! LINDDUN is a great one! But not the only one! A nice compilation to choose from is SEI: Threat Modeling: 12 Available Methods. These really need to be written down at some point.

📖 Draft plans, add documents and eIDAS data objects and some algorithms.

Repository visualization

Visualization of this repo