Merge pull request #1 from the-human-colossus-foundation/update

Expand content about what DKMS is

docs/.vuepress/config.js

@@ -17,7 +17,9 @@ module.exports = {
         {
           text: 'Introduction',
           children: [
+            '/introduction/why.md',
             '/introduction.md',
+            '/introduction/architecture.md',
             '/introduction/glossary.md',
             '/introduction/concepts.md',
           ],
@@ -34,7 +36,9 @@ module.exports = {
         {
           text: 'Introduction',
           children: [
+            '/introduction/why.md',
             '/introduction.md',
+            '/introduction/architecture.md',
             '/introduction/glossary.md',
             '/introduction/concepts.md',
           ],

docs/introduction.md

@@ -1,26 +1,104 @@
 ---
 title: DKMS Introduction
-description: Official OCA specification
-
+description: Decentralized Key Management Syste
 ---
-# Decentralised Key Management System
 
-Key management refers to the management of cryptographic keys in a cryptosystem, dealing with the generation, exchange, storage, use, crypto-shredding and replacement of keys. It includes cryptographic protocol design, key servers, user procedures, and other relevant protocols.
+# Decentralised Key Management System
 
-Decentralised Key Management System (DKMS) provides the libraries necessary for Self-Sovereign Identity (SSI) developers to leverage Key Event Receipt Infrastructure (KERI), a fully decentralised identifier system to achieve network interoperability while securing the identifiers.
+Key management is crucial in safeguarding digital information and dealing with
+how cryptographic keys—essentials for securing data—are created, exchanged,
+stored, and eventually retired. It's about setting up and managing the systems
+that handle these keys, from their technical design to how users interact with
+them.
 
-The quest for decentralised authentication is how a decentralised key management infrastructure, providing Self-certifying Identifier (SCI) issuance underpinned by one-way cryptographic functions, can offer information uniqueness from captured entropy. Furthermore, a decentralised authentication system must be platform-agnostic, with its identifiers interoperable across ecosystems, platforms, and networks.
+Our Decentralized Key Management System (DKMS) offers all the necessary
+components to build any authentication system tailored to meet diverse security
+needs. At the heart of DKMS is our commitment to decentralized authentication.
+This means our system provides unique, self-certifying identifiers generated
+through secure, one-way cryptographic processes that ensure each piece of data
+is distinct and secure. Designed to work across different platforms and
+networks, DKMS ensures that identifiers are universal, making it easier and
+more secure for users everywhere.
 
 ## What is “Decentralised authentication”?
 
-Data provenance refers to tracing and recording the origin of data and its movement between locations. If digital data is tamper-proof (i.e. provable to have not been corrupted after its creation), it can be assumed authentic. Data authentication focuses on timestamping data inputs at index time, determining each event as factual. That definition also underpins the concept of decentralised authentication, the only difference being that the decentralised version is specific to distributed data ecosystems.
+Data provenance refers to tracing and recording the origin of data and its
+movement between locations. If digital data is tamper-proof (i.e. provable to
+have not been corrupted after its creation), it can be assumed authentic. Data
+authentication focuses on timestamping data inputs at index time, determining
+each event as factual. That definition also underpins the concept of
+decentralised authentication, the only difference being that the decentralised
+version is specific to distributed data ecosystems.
+
+## Comparing with ...
+
+In the landscape of digital security, key management systems can broadly be
+categorized into three types: centralized, federated, and decentralized like
+our DKMS. Each type offers unique advantages and caters to different security
+needs.
+
+- Centralized Key Management Systems operate under a single authority that
+  manages all cryptographic keys. This central control simplifies management
+  but also creates a single point of failure. If the central system is
+  compromised, so too are all the keys it manages. This model often struggles
+  with scalability and can become a bottleneck as the system grows.
+
+- Federated Key Management Systems spread control among multiple, cooperating
+  entities. While this reduces the risk of a single point of failure compared
+  to centralized systems, it still relies on the trust and cooperation between
+  these entities. The federated approach can be more flexible and scalable than
+  centralized systems but often involves complex trust relationships and
+  coordination challenges.
+
+- Decentralized Key Management Systems (DKMS), such as ours, distribute the
+  management of keys directly to the owners, eliminating single points of
+  failure and reducing reliance on any one entity. This enhances security and
+  resilience, as the compromise of one part does not jeopardize the entire
+  system. DKMS offers the basis to build truly interoperable solutions, with
+  mechanisms that ensure data integrity and authentication across various
+  platforms/networks without needing centralized oversight.
+
+By leveraging a decentralized approach, DKMS enables a more secure, scalable,
+and resilient authentication system, making it an ideal choice for environments
+demanding stringent data security and privacy without compromising on
+accessibility and interoperability.
+
+## How DKMS works?
+
+DKMS utilizes decentralized authentication, a key management approach that
+cryptographically binds an identifier to an associated log. This log records
+the history of all uses or changes to the public/private key pair, ensuring the
+verifiable provenance of the identifier throughout any ambient infrastructure.
+The immutable ordering of entries guarantees the factual authenticity of each
+recorded event, underpinning the integrity of systematic data inputs.
+Additionally, all system identifiers are designed to be network-agnostic,
+facilitating seamless interoperability within and across various distributed
+data ecosystems.
+
+Moreover, DKMS is built on the principle of end-verifiability, meaning that
+every element can be independently verified by the user to confirm its
+authenticity and integrity. This characteristic often manifests through the
+philosophy of "never trust, always verify," which is the foundational ideology
+of the zero-trust architecture.
 
-::: tip
-**Question**: How can a systems auditor examine adequacy and process to benchmark the performance and provenance of information exchange within a distributed data ecosystem?
+Decentralised authentication provides a powerful solution for identifier
+interoperability, data provenance, data-intensive event streaming, and
+event-sourcing applications.
 
-**Answer**: Decentralised authentication
-:::
+## What technology is behind DKMS?
 
-Decentralised authentication describes a key management methodology of cryptographically binding SCIs to an associated log that compiles the history of all uses or changes to the public/private key pair, ensuring verifiable identifier provenance throughout any ambient infrastructure. Immutable ordering guarantees the factual authenticity of the recorded event underpinning any systematic data input. Furthermore, all system identifiers must remain network-agnostic, enabling identifier interoperability within and across any distributed data ecosystem.
+At the heart of DKMS is the Key Event Receipt Infrastructure
+([KERI](https://keri.one/)), a protocol designed for decentralized key
+management without reliance on any network. KERI provides a highly secure
+framework by maintaining a self-certifying history of all cryptographic
+operations related to key events, such as creation, rotation, and revocation.
+This history is immutable and can be independently verified, ensuring the
+integrity and provenance of the cryptographic keys throughout their lifecycle.
 
-Decentralised authentication provides a powerful solution for identifier interoperability, data provenance, data-intensive event streaming, and event sourcing applications.
+KERI operates by generating event logs that are uniquely tied to each
+identifier, creating a verifiable trail of all actions taken with the
+associated keys. This system ensures that even if a key is compromised, the
+history and the specific compromised state can be identified and addressed
+without undermining the entire infrastructure. Thanks to KERI, DKMS supports
+robust, network-agnostic identifier interoperability across diverse data
+ecosystems.

docs/introduction/architecture.md

@@ -0,0 +1,54 @@
+---
+title: DKMS Architecture
+description: Architecture of DKMS and it's components
+---
+
+# Architecture
+
+DKMS is designed to streamline complex technological processes, functioning as
+a seamless "magic box" for all users. By abstracting the difficulty of key
+management, DKMS allows entities to concentrate on their specific applications
+and use cases rather than the underlying security mechanisms. It effectively
+tackles the challenging issues of discoverability and information propagation
+about the key state of the identifier, transactions, and more within any given
+ecosystem. This architecture not only simplifies integration but also enhances
+the efficiency and reliability of digital interactions across diverse platforms
+and networks. With DKMS, users gain access to a robust framework that supports
+secure communications and data management without the need for deep technical
+knowledge.
+
+On a very high level DKMS consists of two major components:
+
+- **Propagation Infrastructure**: allows entities to propagate
+  their key state into the network and is designated by the controller himself.
+- **Duplicity Infrastructure**: provides a mechanism for duplicity detection which
+  is designated by the governance of the ecosystem.
+
+::: tip IMPORTANT
+Governance of duplicity infrastructure and propagation infrastructure should be
+split as it is crucial for the security of the whole ecosystem!
+:::
+
+![DKMS Architecture](/dkms-arch-1.svg)
+
+Looking deeper into the components we can see internal responsibility of each
+component and how they propagate through ecosystem.
+
+![DKMS Architecture](/dkms-arch-2.svg)
+
+DKMS simplifies the integration process by providing a user-friendly interface
+that can be effortlessly incorporated into specific use cases.
+
+Leveraging **Propagation infrastructure** application can use its API to
+propagate key states to the network, at the same time witnessing the intention of
+the controller and protecting him from external exploitation of its identifier.
+
+Using an **Duplicity Infrastructure** application can monitor other identifiers to
+ensure uniqueness and prevent duplicity within the system. These capabilities
+ensure that even the smallest ecosystem can seamlessly integrate and operate
+within larger frameworks, reflecting a fractal architecture. This design allows
+DKMS to efficiently span across different governance and jurisdictional
+boundaries, facilitating broad scalability and adaptability. By abstracting
+complex key management tasks, DKMS enables entities to focus on leveraging its
+robust features for enhanced security and operational efficiency in their
+digital environments.

docs/introduction/concepts.md

@@ -1,7 +1,17 @@
 # Fundamental concepts
 
+## KERI
+
+DKMS is build upon Key Event Receipt Infrastructure (KERI) which is the first truly fully decentralized identity system.
+
+Website: [https://keri.one/](https://keri.one/)
+
+
+
 ## CESR protocol
 
+Specification: [https://datatracker.ietf.org/doc/draft-ssmith-cesr/](https://datatracker.ietf.org/doc/draft-ssmith-cesr/)
+
 Use cases built upon DKMS infrastructure may require mass scale information dissemination. To achieve maximum performance and throughput, new type of protocol was designed to fulfill these goals. The underlying assumptions to consider are as following:
 - compactness -- DKMS specific additions for information exchange, ie. attach event signature.
 - streaming -- ability to exchange information continuously between participants
@@ -14,6 +24,8 @@ Any information exchanged over the network between any actors in DKMS is sent in
 
 ## Discoverability mechanism through OOBI's
 
+Specification: [https://datatracker.ietf.org/doc/draft-ssmith-oobi/](https://datatracker.ietf.org/doc/draft-ssmith-oobi/)
+
 Two independent participants of the DKMS infrastructure must have a way to be able to resolve their Identifeir KEL's. Thus we make an underlying assumption that within the network *"everyone knows something, and no one knows everything"*. In other words there is no central point, where any participant would go and query for any other participant KEL. Instead it is enough for given participant to either be in a direct relationship with another one or have a "business card" of the other one. These two approaches, albeit not sufficient at first glance, are exhaustive discovery mechanism for any member of the network. The latter approach is interesting in particular as it enables the *Out-of-Band-Introduction protocol* (OOBI). The Out-of-Band means any approach that is suitable for transfer information can be considered. The simplest form of an OOBI might look like the following:
 ```
 ("http://8.8.5.6:8080/oobi", "EaU6JR2nmwyZ-i0d8JZAoTNZH3ULvYAfSVPzhzS6b5CM")

docs/introduction/glossary.md

@@ -1,11 +1,10 @@
 # Glossary
 
-- **Ambient Infrastructure**: Ensemble of components (e.g. Witnesses, Watchers,..) and services enabling a DKMS based cryptographically secured environement for decentralised authentication and peer-to-peer interactions
+- **Ambient Infrastructure**: Ensemble of components (e.g. Watchers, Judge) and services enabling a DKMS based cryptographically secured environement for decentralised authentication and peer-to-peer interactions. Acting as duplicity detection protection.
 - **DKMS** -- Decentralized Key Management System
-- **Gossip** -- A way of disseminating the information among participants in the network.
-- **Identifier** -- A sequence of characters used to refer to a digital and unique form of a label. In this project we focus on cryptographically derived identifier from the private/public key pair and anchored into its own KEL.(*see ref [2b]*) 
+- **Identifier** -- A sequence of characters used to refer to a digital and unique form of a label. In this project we focus on cryptographically derived identifier (Self-Certifing Identifier) from the private/public key pair and anchored into its own KEL.
 - **KEL** -- Key Event Log. An authentic provenance log that keeps all the changes of the Identifier in authentic and verifiable way.
 - **OOBI** -- Out of Band Introduction. A discoverability mechanism used in DKMS that is `out-of-band` (ie. via QR codes). In concert with Percolation Theory is founded upon the assumption that "everyone knows something and no one knows everything".
 - **Witness** -- collaborates with Controller, attestates that information has been seen at a point in time by a third party (the Witness)
-- **Watcher** -- collaborates with Controller and serves for its purposes mainly for the validation purposes. Kind-of J.A.R.V.I.S. from Marvel
+- **Watcher** -- collaborates with Controller and serves for its purposes mainly for the validation purposes.
 - **Receipt** -- Witness issued attestation that confirms that information has been seen at a point in time