lumoin / verifiable Goto Github PK

• 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
Verifiable.NSec
Verifiable.Core
Verifiable.BouncyCastle
Verifiable.Tpm
Verifiable.Sidetree
Verifiable.Microsoft
Verifiable.Jwt
Verifiable.Security.DataStorage

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

• Decentralized Identifiers data model
• Decentralized Identifiers conformance and test suite
• Verifiable Credentials data model
• Verifiable Credentials conformance and test suite
• Trusted Platform Module (TPM 2.0) specifications

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

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

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.

👀 Please, do write issues.

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

⭐ Stars are always nice. :)

✅ 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/).

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