Merge remote-tracking branch 'upstream/main'

docs/08_annotated-copies/WebOfTrust-ietf-acdc-main-draft-ssmith-acdc.md

@@ -4,11 +4,11 @@
 <div className="accordion-item" data-level="1">
                         
 
-<h2 className="accordion-header" id="header396002438621">
+<h2 className="accordion-header" id="header1230496122444">
                         
 
-<button className="accordion-button collapsed" type="button" data-bs-toggle="collapse" data-bs-target="#accordeon-396002438621" aria-expanded="false" aria-controls="accordeon-396002438621">
-                            396002438621, level 1
+<button className="accordion-button collapsed" type="button" data-bs-toggle="collapse" data-bs-target="#accordeon-1230496122444" aria-expanded="false" aria-controls="accordeon-1230496122444">
+                            1230496122444, level 1
                         
 
 </button>
@@ -17,7 +17,7 @@
 </h2>
                         
 
-<div id="accordeon-396002438621" className="accordion-collapse collapse">
+<div id="accordeon-1230496122444" className="accordion-collapse collapse">
                         
 
 <div className="accordion-body">

docs/08_annotated-copies/WebOfTrust-ietf-cesr-proof-main-draft-pfeairheller-cesr-proof.md

@@ -4,11 +4,11 @@
 <div className="accordion-item" data-level="1">
                         
 
-<h2 className="accordion-header" id="header8285328508211">
+<h2 className="accordion-header" id="header3126766338566">
                         
 
-<button className="accordion-button collapsed" type="button" data-bs-toggle="collapse" data-bs-target="#accordeon-8285328508211" aria-expanded="false" aria-controls="accordeon-8285328508211">
-                            8285328508211, level 1
+<button className="accordion-button collapsed" type="button" data-bs-toggle="collapse" data-bs-target="#accordeon-3126766338566" aria-expanded="false" aria-controls="accordeon-3126766338566">
+                            3126766338566, level 1
                         
 
 </button>
@@ -17,7 +17,7 @@
 </h2>
                         
 
-<div id="accordeon-8285328508211" className="accordion-collapse collapse">
+<div id="accordeon-3126766338566" className="accordion-collapse collapse">
                         
 
 <div className="accordion-body">

docs/08_annotated-copies/WebOfTrust-ietf-ipex-main-draft-ssmith-ipex.md

@@ -4,11 +4,11 @@
 <div className="accordion-item" data-level="1">
                         
 
-<h2 className="accordion-header" id="header1957913862050">
+<h2 className="accordion-header" id="header7255226775928">
                         
 
-<button className="accordion-button collapsed" type="button" data-bs-toggle="collapse" data-bs-target="#accordeon-1957913862050" aria-expanded="false" aria-controls="accordeon-1957913862050">
-                            1957913862050, level 1
+<button className="accordion-button collapsed" type="button" data-bs-toggle="collapse" data-bs-target="#accordeon-7255226775928" aria-expanded="false" aria-controls="accordeon-7255226775928">
+                            7255226775928, level 1
                         
 
 </button>
@@ -17,7 +17,7 @@
 </h2>
                         
 
-<div id="accordeon-1957913862050" className="accordion-collapse collapse">
+<div id="accordeon-7255226775928" className="accordion-collapse collapse">
                         
 
 <div className="accordion-body">

static/json/external-glosseries/glossaries/terms-definitions-nist.json

@@ -701,7 +701,7 @@
   },
   {
     "term": "verifier",
-    "definition": "An entity that verifies the claimants identity by verifying the claimants possession and control of a token using an authentication protocol. To do this, the Verifier may also need to validate credentials that link the token and identity and check their status.",
+    "definition": "The entity that verifies the authenticity of a digital signature using the public key of the signatory.",
     "organisation": "Nist",
     "url": "https://csrc.nist.gov/glossary/term/verifier",
     "anchor": "verifier"

static/json/external-glosseries/glossaries/terms-definitions-tswg-cesr.json

@@ -3,7 +3,7 @@
     "organisation": "TSWG (CESR)",
     "url": "https://trustoverip.github.io/tswg-cesr-specification/index.html",
     "term": "Autonomic Identifier (AID)",
-    "definition": "a self-managing cryptonymous identifier that must be self-certifying (self-authenticating) and must be encoded in CESR as a qualified Cryptographic Primitive.",
+    "definition": "a self-managing cryptonymous identifier that shall be self-certifying (self-authenticating) and shall be encoded in CESR as a qualified Cryptographic Primitive.",
     "anchor": "AutonomicIdentifier(AID)"
   },
   {
@@ -66,7 +66,7 @@
     "organisation": "TSWG (CESR)",
     "url": "https://trustoverip.github.io/tswg-cesr-specification/index.html",
     "term": "Primitive",
-    "definition": "a serialization of a unitary value.  All Primitives in KERI must be expressed in CESR.",
+    "definition": "a serialization of a unitary value.  All Primitives in KERI shall be expressed in CESR.",
     "anchor": "Primitive"
   },
   {

static/json/external-glosseries/glossaries/terms-definitions-wotterms.json

@@ -1,4 +1,11 @@
 [
+  {
+    "organisation": "WebOfTrust",
+    "term": "abandoned identifier",
+    "url": "https://kerisse.org",
+    "anchor": "abandoned-identifier",
+    "definition": "<h1>abandoned identifier</h1><h4>Definition</h4><p>An <a href=\"AID\">AID</a> is abandoned when either the <a href=\"inception-event\">Inception</a> or a subsequent <a href=\"rotation-event\">Rotation event</a> rotates to an empty next key digest list (which means the next threshold must also be 0).</p><p>When an AID is abandoned, <code>ndigers</code> is zero (empty next key digest list ), so any event after the event that made it nontransferable is not accepted.</p><p>So more on the <a href=\"https://github.com/WebOfTrust/keripy/discussions/821\">Keripy github discussion page</a></p>"
+  },
   {
     "organisation": "WebOfTrust",
     "term": "access controlled interaction",
@@ -363,6 +370,13 @@
     "anchor": "byzantine-fault-tolerance",
     "definition": "<h1>byzantine fault tolerance</h1><h4>Definition</h4><p>A Byzantine fault (also interactive consistency, source congruency, error avalanche, <a href=\"byzantine-agreement\">Byzantine agreement</a> problem, Byzantine generals problem, and Byzantine failure) is a condition of a computer system, particularly distributed computing systems, where components may fail and there is imperfect information on whether a component has failed. The term takes its name from an allegory, the &quot;Byzantine Generals Problem&quot;, developed to describe a situation in which, in order to avoid catastrophic failure of the system, the system&#39;s actors must agree on a concerted strategy, but some of these actors are unreliable.In a Byzantine fault, a component such as a server can inconsistently appear both failed and functioning to failure-detection systems, presenting different symptoms to different observers. It is difficult for the other components to declare it failed and shut it out of the network, because they need to first reach a consensus regarding which component has failed in the first place.Byzantine fault tolerance (BFT) is the dependability of a fault-tolerant computer system to such conditions.</p><h4>Consensus two third</h4><p>A system has Byzantine Fault Tolerance (BFT) when it can keep functioning correctly as long as two-thirds of the network agree or reaches consensus. BFT is a property or characteristic of a system that can resist up to one-third of the nodes failing or acting maliciously.</p><p>The pBFT model primarily focuses on providing a practical Byzantine state machine replication that tolerates Byzantine faults (malicious nodes) through an assumption that there are independent node failures and manipulated messages propagated by specific, independent nodes.The algorithm is designed to work in asynchronous systems and is optimized to be high-performance with an impressive overhead runtime and only a slight increase in latency. More on wikipedia about</p><h4>More on Wikipedia</h4><ul><li><a href=\"https://en.wikipedia.org/wiki/Byzantine_fault\">Byzantine Fault</a></li><li><a href=\"https://en.bitcoinwiki.org/wiki/PBFT\">pBFT</a> : An article that explains practical BFT. </li><li><a href=\"https://blockonomi.com/practical-byzantine-fault-tolerance/\">Here</a>&#39;s a complete beginners guide.</li></ul>"
   },
+  {
+    "organisation": "WebOfTrust",
+    "term": "canonicalization",
+    "url": "https://kerisse.org",
+    "anchor": "canonicalization",
+    "definition": "<h1>canonicalization</h1><h4>Definition</h4><p>In computer science, canonicalization (sometimes standardization or <a href=\"https://en.wikipedia.org/wiki/Normalization_(statistics)\">normalization</a>) is a process for converting data that has more than one possible representation into a &quot;standard,&quot; &quot;normal,&quot; or <a href=\"https://en.wikipedia.org/wiki/Canonical_form\">canonical form</a>.<br>This can be done to compare different representations for equivalence, to count the number of distinct data structures, to improve the efficiency of various algorithms by eliminating repeated calculations, or to make it possible to impose a meaningful sorting order.</p><p>More on source <a href=\"https://en.wikipedia.org/wiki/Canonicalization\">Wikipedia</a></p>"
+  },
   {
     "organisation": "WebOfTrust",
     "term": "CBOR",
@@ -545,6 +559,13 @@
     "anchor": "configuration-files",
     "definition": "<h1>configuration files</h1><h4>Definition</h4><p>In <a href=\"https://en.wikipedia.org/wiki/Computing\">computing</a>, configuration files (commonly known simply as config files) are <a href=\"https://en.wikipedia.org/wiki/Computer_file\">files</a> used to configure the <a href=\"https://en.wikipedia.org/wiki/Parameter_(computer_programming)\">parameters</a> and <a href=\"https://en.wikipedia.org/wiki/Initialization_(programming)\">initial settings</a> for some <a href=\"https://en.wikipedia.org/wiki/Computer_program\">computer programs</a>. They are used for user <a href=\"https://en.wikipedia.org/wiki/Application_software\">applications</a>, <a href=\"https://en.wikipedia.org/wiki/Server_(computing)\">server processes</a> and <a href=\"https://en.wikipedia.org/wiki/Operating_system\">operating system</a> settings.</p><p>More on source <a href=\"https://en.wikipedia.org/wiki/Configuration_file\">Wikipedia</a></p>"
   },
+  {
+    "organisation": "WebOfTrust",
+    "term": "configuration traits",
+    "url": "https://kerisse.org",
+    "anchor": "configuration-traits",
+    "definition": "<h1>configuration traits</h1><h4>Definition</h4><p>A list of specially defined strings representing a configuration of a <a href=\"key-event-log\">KEL</a>.</p>"
+  },
   {
     "organisation": "WebOfTrust",
     "term": "consensus mechanism",
@@ -2953,12 +2974,19 @@
     "anchor": "self-addressing-identifier",
     "definition": "<h1>self addressing identifier</h1><h4>Definition</h4><p>An identifier that is deterministically generated from and embedded in the content it identifies, making it and its data mutually tamper-evident.</p><h5>To generate a SAID</h5><ol><li>Fully populate the data that the SAID will identify, leaving a placeholder for the value of the SAID itself.</li><li>Canonicalize the data, if needed. The result is called the SAID&#39;s <strong>identifiable basis</strong>.</li><li>Hash the <em>identifiable basis</em>. The result is the value of the SAID.</li><li>Replace the placeholder in <em>identifiable basis</em> the with the newly generated identifier, so the SAID is embedded in the data it identifies. The result is called the <strong>saidified data.</strong></li></ol><h5>To verify that a SAID truly identifies a specific chunk of data</h5><ol><li>Canonicalize the data, if needed. The result is <strong>claimed saidified data</strong>.</li><li>In the <em>claimed saidified data</em>, replace the SAID value with a placeholder. The result is the <strong>identifiable basis</strong> for the SAID.</li><li>Hash the <em>identifiable basis</em>.</li><li>Compare the hash value to the SAID. If they are equal, then the SAID identifies the <em>claimed saidified data</em>.</li></ol><h5>Differences in SAID algorthms manifest in the following choices</h5><ul><li>how data is canonicalized</li><li>which hash algorithm is used</li><li>which placeholder is used</li><li>how the bytes produced by the hash algorithm are encoded</li><li>how the SAID value is formatted</li></ul><h5>Notation</h5><p>A terse way to describe a SAID and its data is to write an expression that consists of the token <code>SAID</code> followed by a token with field names in canonical order, where the field containing the SAID itsef is marked by the suffix <code>=said</code>. For example, the saidification of a simple <code>ContactInfo</code> data structure might be given as <code>SAID(name, address, phone, email, id=said)</code>.</p>"
   },
+  {
+    "organisation": "WebOfTrust",
+    "term": "self authenticating",
+    "url": "https://kerisse.org",
+    "anchor": "self-authenticating",
+    "definition": "<h1>self authenticating</h1><h4>See</h4><p><a href=\"self-certifying-identifier\">self-certifying</a></p>"
+  },
   {
     "organisation": "WebOfTrust",
     "term": "self certifying identifier",
     "url": "https://kerisse.org",
     "anchor": "self-certifying-identifier",
-    "definition": "<h1>self certifying identifier</h1><h4>Definition</h4><p>A Self-Certifying Identifier (SCID) cryptographically binds an identifier to a public and private key pair. It is an identifier that can be proven to be the one and only identifier tied to a public key using cryptography alone.</p><h4>Signing</h4><p>A <a href=\"controller\">controller</a> issues an own Identifier by binding a generated public private key pair to an identifier. After this a controller is able to sign the identifier and create a certificate. Also called a <em>cryptonym</em>. The simplest form of a self-certifying identifier includes either the public key or a unique fingerprint of the public key as a <a href=\"prefix\">prefix</a> in the identifier.</p><h4>Important SCID properties:</h4><ul><li>Self-contained secure cryptographic <a href=\"root-of-trust\">root-of-trust</a></li><li>Decentralized control via <a href=\"PKI\">private key management</a></li><li>Universally unique identifiers</li></ul><h4>Related to KERI</h4><p>A self-certifying identifier (SCID) is a type of <a href=\"cryptonym\">cryptonym</a> that is uniquely cryptographically derived from the public key of an asymmetric non-repudiable signing keypair, (public, private).<br>It is self-certifying or more precisely <strong>self-authenticating</strong> because it does not rely on a trusted entity. The <a href=\"authenticity\">authenticity</a> of a non-repudiable signature made with the private key may be verified by extracting the public key from either the identifier itself or incepting information uniquely associated with the cryptographic derivation process for the identifier. In a <em>basic SCID</em>, the mapping between an identifier and its controlling public key is self-contained in the identifier itself. A basic SCID is <a href=\"ephemeral\">ephemeral</a> i.e. it does not support <a href=\"rotation\">rotation</a> of its keypairs in the event of key weakness or compromise and therefore must be abandoned once the controlling private key becomes weakened or compromised from exposure.</p>"
+    "definition": "<h1>self certifying identifier</h1><h4>Definition</h4><p>A Self-Certifying Identifier (SCID) cryptographically binds an identifier to one or more public/private key pairs. It is an identifier that can be proven to be the one and only identifier tied to a public key using cryptography alone.</p><h4>Signing</h4><p>A <a href=\"controller\">controller</a> issues an own Identifier by binding a generated public private key pair to an identifier. After this a controller is able to sign the identifier and create a certificate. Also called a <em>cryptonym</em>. The simplest form of a self-certifying identifier includes either the public key or a unique fingerprint of the public key as a <a href=\"prefix\">prefix</a> in the identifier.</p><h4>Important SCID properties:</h4><ul><li>Self-contained secure cryptographic <a href=\"root-of-trust\">root-of-trust</a></li><li>Decentralized control via <a href=\"PKI\">private key management</a></li><li>Universally unique identifiers</li></ul><h4>Related to KERI</h4><p>A self-certifying identifier (SCID) is a type of <a href=\"cryptonym\">cryptonym</a> that is uniquely cryptographically derived from the public key of an asymmetric non-repudiable signing keypair, (public, private).<br>It is self-certifying or more precisely <strong>self-authenticating</strong> because it does not rely on a trusted entity. The <a href=\"authenticity\">authenticity</a> of a non-repudiable signature made with the private key may be verified by extracting the public key from either the identifier itself or incepting information uniquely associated with the cryptographic derivation process for the identifier. In a <em>basic SCID</em>, the mapping between an identifier and its controlling public key is self-contained in the identifier itself. A basic SCID is <a href=\"ephemeral\">ephemeral</a> i.e. it does not support <a href=\"rotation\">rotation</a> of its keypairs in the event of key weakness or compromise and therefore must be abandoned once the controlling private key becomes weakened or compromised from exposure.</p>"
   },
   {
     "organisation": "WebOfTrust",
@@ -3149,6 +3177,13 @@
     "anchor": "stale-key",
     "definition": "<h1>stale key</h1><h4>Definition</h4><p>A stale key is an outdated or expired encryption key that should no longer be used for securing data</p><h4>Also see</h4><p><a href=\"stale-event\">Stale (key) event</a></p>"
   },
+  {
+    "organisation": "WebOfTrust",
+    "term": "streamer",
+    "url": "https://kerisse.org",
+    "anchor": "streamer",
+    "definition": "<h1>streamer</h1><h4>Definition</h4><p> A convenience class for supporting stream parsing, including nested (tunneled, encrypted) CESR streams. Streams can be a mixture/combination of different primitives, including other streams. A stream is a concatenation of primitives.</p><p>It is akin to a cryptographic primitive yet is not a cryptographic primitive itself. </p><p>It supports <a href=\"ESSR\">ESSR</a> by making it easier to handle tunneled streams.<br>Source: Kent Bull in chat Zoom meeting KERI Aug 6, 2024.</p>"
+  },
   {
     "organisation": "WebOfTrust",
     "term": "strip parameter",