veikkoeeva / verifiable

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

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

---

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.

---

Features

• Decentralized identifiers (DID).
• Verifiable credentials (VC).
• Various related protocols to DIDs and VCs.
• Key and secrets management.

---

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 approprite (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.

.NET 5 is needed (soon .NET 6). 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 also help.

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