KERI - Revision history

Tom: /* References */

2025-10-24T21:09:02Z

‎References

Tom: /* Commentary */

2025-10-24T21:07:05Z

‎Commentary

Tom: /* References */

2025-10-24T21:04:13Z

‎References

Tom: /* Experiments */

2025-10-24T21:00:35Z

‎Experiments

Show changes

Tom: /* Experiments */

2025-09-08T18:50:54Z

‎Experiments

Tom: /* Experiments */

2025-09-08T18:43:32Z

‎Experiments

Show changes

Tom: /* Experiments */

2024-11-08T05:29:46Z

‎Experiments

Tom: /* References */

2024-11-08T05:28:00Z

‎References

Show changes

Tom: /* References */

2022-04-08T16:23:57Z

‎References

Tom: /* Full Title or Meme */

2021-11-23T20:56:31Z

‎Full Title or Meme

← Older revision		Revision as of 21:09, 24 October 2025
Line 212:		Line 212:
	[[Category: Glossary]]		[[Category: Glossary]]
	[[Category: Cryptography]]		[[Category: Cryptography]]
		+	[[Category: Identity Management]]

@@ Line 99: / Line 99: @@
 Oct 24, 2025
-Digital identity has always suffered from a foundational flaw: our confidence in “who controls this key” depends on trusted intermediaries, not on cryptographic evidence.
+Digital identity has always suffered from a foundational flaw: our confidence in “who controls this key” depends on trusted intermediaries, not on cryptographic evidence. The Key Event Receipt Infrastructure (KERI) project set out to solve that. It replaces certificate authorities and registries with self-certifying identifiers and tamper-evident key event logs.
-The Key Event Receipt Infrastructure (KERI) project set out to solve that. It replaces certificate authorities and registries with self-certifying identifiers and tamper-evident key event logs.
+But what’s fascinating is that Nostr, with only signed events and hierarchical key derivation (BIP-32), can reach many of the same guarantees by very different means. Let’s unpack the flaws KERI was built to fix, and how a Nostr-based model could solve them with different cryptographic machinery.
-But what’s fascinating is that Nostr, with only signed events and hierarchical key derivation (BIP-32), can reach many of the same guarantees by very different means.
+===First Flaw to Fix: Weak binding between identifiers and keys===
 In traditional PKI, a certificate authority asserts that an identifier (like example.com) belongs to a certain public key. The binding exists because a trusted third party said so, not because it’s provable.
@@ Line 120: / Line 116: @@
 This simple step formalizes what KERI calls inception: your root key defines your identifier, not a third-party registry.
-Second Flaw to Fix: Unverifiable key rotation
+===Second Flaw to Fix: Unverifiable key rotation===
 When keys change due to compromise, expiration, or policy, most systems can’t prove continuity between the old and new keys. Revocation lists and new certificates express intent, not verifiable linkage.
@@ Line 137: / Line 133: @@
 The result is the same cryptographic continuity: verifiers can reconstruct the entire key lineage from the xpub and verify that each transition was authorized by the prior key.
-Third Flaw to Fix: No tamper-evident history of key state
+===Third Flaw to Fix: No tamper-evident history of key state===
 Traditional PKI has no native mechanism to prove which key was valid at any given time. Certificate expiration and revocation signals are operational, not cryptographic.
@@ Line 152: / Line 148: @@
 Nostr becomes, effectively, a decentralized KEL carried by relays instead of a dedicated KERI infrastructure.
-Fourth Flaw to Fix: Reliance on trusted infrastructure
+===Fourth Flaw to Fix: Reliance on trusted infrastructure===
 PKI depends on certificate authorities, revocation servers, and DNS registries which can be single points of failure and control.
@@ Line 165: / Line 161: @@
 This yields the same property: ambient verifiability. Anyone, anywhere, can check the authenticity of data without contacting a specific registry.
-Fifth Flaw to Fix: Undetectable duplicity
+===Fifth Flaw to Fix: Undetectable duplicity===
 If two conflicting key states exist, traditional systems offer no built-in way to expose the conflict.
@@ Line 176: / Line 172: @@
 Because all key-state events are public, any double-signing or divergent chain is visible. Multiple relays can act as watchers, and other witnesses can publish an event that attests when they first saw each event. If two conflicting updates exist, events from different witnesses can demonstrate which appeared first, a distributed equivalent to KERI’s “first-seen” policy.
-Putting it all together
+===Putting it all together===
 Both KERI and Nostr aim to make control over identifiers cryptographically verifiable rather than institutionally trusted, but they take very different routes to get there.
@@ Line 191: / Line 187: @@
 In essence, KERI provides a formalized, specification-driven trust framework, while Nostr achieves many of the same assurance properties through emergent, minimal design. Both converge on the same foundational principle: that trust on the internet should be derived from what can be verified, not what must be believed.
-The future of verifiable identity
+===The future of verifiable identity===
 What both KERI and Nostr ultimately reveal is that the evolution of digital identity is shifting from trusting institutions to trusting mathematics. Instead of delegating authority to certificate authorities, registries, or platforms, we’re learning how to embed verifiability directly into protocols themselves. KERI demonstrates that this can be done through formal governance and explicit event logs; Nostr shows that it can also emerge from minimalist primitives using just signatures, derivation paths, and public propagation. Together, they point to a future where identity is not something that must be issued or approved, but something that can be proven — cryptographically, transparently, and independently of intermediaries. In that world, the question “Who can we trust?” quietly gives way to a better one: “What can we verify?”

← Older revision		Revision as of 21:04, 24 October 2025
Line 215:		Line 215:

	[[Category: Glossary]]		[[Category: Glossary]]
		+	[[Category: Cryptography]]

@@ Line 43: / Line 43: @@
 Comment on Paul Knowles’ comment
-Carly Huitema
+Carly Huitema Manager, Agri-food Data Strategy, University of Guelph
 d
 The https://www.semanticengine.org at the University of Guelph in Canada implements OCA from the Human Colossus Foundation which had elements of CESR.
-James Monaghan
+James Monaghan Venture builder and consultant in decentralised identity, privacy & AI
 d
@@ Line 69: / Line 60: @@
 Not my project, not my call… it’ll be public soon.
-Like
+James Monaghan  Venture builder and consultant in decentralised identity, privacy & AI
 Sure, just wondering if you knew the rationale. I'll look forward to seeing the output.
@@ Line 92: / Line 78: @@
 Author
 Chief Strategy Officer, Digital Trust Venture Partners. Co-founder: Evernym, Provenant, healthKERI and Credential Master. Co-Inventor, Sovrin.
-Huge congrats to you and GLEIF for that accomplishment!! 💪💪
+Huge congrats to you and GLEIF for that accomplishment!!
 Fernando Marino  Gerente de Produtos CPQD iD & CPQD Trace
 Hi Timothy, we’re working on an R&D project here in Brazil where we intend to study and explore the use of KERI, ACDCs, and CESR standards. We believe these protocols can play a key role in advancing our decentralized identity solutions and are excited to contribute insights from our experience. Thank you for promoting this effort to enhance standards!
@@ Line 104: / Line 88: @@
 Author
 Chief Strategy Officer, Digital Trust Venture Partners. Co-founder: Evernym, Provenant, healthKERI and Credential Master. Co-Inventor, Sovrin.
 Fernando Marino Awesome... go Brazil!!
@@ Line 116: / Line 99: @@
 Reply
-Jared Jeffery, MBA, FACHDM
+Jared Jeffery, MBA, FACHDM Founder | Cancer Survivor | Zero Trust Data for Healthcare
-Like
+I've heard rumors healthKERI might be on this list.  <==  See above
@@ Line 131: / Line 107: @@
 h
-We're waiting on Snopes to confirm. 😂
+We're waiting on Snopes to confirm.
 Fergal O'Connor Senior Dev @ Cardano Foundation
@@ Line 161: / Line 133: @@
 Asad Khan Building quietly with the worlds leading identity standard...
 Makpar Corporation is working on several internal and client-facing initiatives with the whole KERI stack!

@@ Line 166: / Line 166: @@
 d
-RootsID has several projects using the Global Legal Entity Identifier Foundation (GLEIF) vLEI which uses KERI, ACDCs, and CESR. Our passion project is DoulaID led by Annie Byrd which extends the vLEI credential chain and EGF to improve Maternal Mortality rates in the US. We are also leveraging the KERI protocols to implement cross-border, cross-platform, cross-chain identity into the Cardano blockchain ecosystem, along with Cardano Foundation Sebastian Bode Thomas A. Mayfield Fergal O'Connor Jaime Caso Onzain and Cardano community.
+RootsID has several projects using the Global Legal Entity Identifier Foundation (GLEIF) vLEI which uses KERI, ACDCs, and CESR. Our passion project is DoulaID led by Annie Byrd which extends the vLEI credential chain and EGF to improve Maternal Mortality rates in the US. We are also leveraging the KERI protocols to implement cross-border, cross-platform, cross-chain identity into the Cardano blockchain ecosystem, along with Cardano Foundation Sebastian Bode Thomas A. Mayfield Fergal O'Connor Jaime Caso Onzain and Cardano community. https://www.linkedin.com/company/cardano-foundation/
 Like
@@ Line 256: / Line 257: @@
 Load more comments
 ==References==
 [[Category: Glossary]]

← Older revision		Revision as of 16:23, 8 April 2022
Line 19:		Line 19:
	==References==		==References==

−	[[Category: ~~Glosary~~]]	+	[[Category: Glossary]]

@@ Line 6: / Line 6: @@
 Quick intro to KERI
 KERI defines a number of events (e.g. inception, rotation, delegated inception, etc.), and also data structures and rules for processing them. Processing events leads to the current state of the identifier.
-There are different types of identifiers, and different ways how events can get exchanged, e.g. ephemeral mode, exchange with
+There are different types of identifiers, and different ways how events can get exchanged,
 ==References==
 [[Category: Glosary]]