Difference between revisions of "KERI"

Revision as of 13:07, 24 October 2025

Full Title or Meme

Jolocom team] Current status of did:keri, and adding it as a work item to the ID WG. Information and contextual documents: https://hackmd.io/@RYgJMHAGSlaLMaQzwYjvsQ/ByAYibtdF Current did:keri method specification: https://identity.foundation/keri/did_methods/ 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 counterparty (direct mode), exchange via witnesses (indirect mode). The controller can select what witnesses they like, witnesses can also be rotated. This adds an abstraction layer, witnesses can be anything (ledger, or personal server, etc.) Current status of did:keri

• Previously there was did:un, some features were not yet supported. Jolocom had an implementation of direct mode, the intention was to use it on mobile wallets.

Then the intention was to switch from did:un to a more robust implementation of did:keri, using some good learnings from the initial experimentation work.

• Some work is split across different environments, so besides a documentation effort there also needs to be some alignment.

The goal is to continue and further expand the work on the DID method specification, to figure out how all the KERI building blocks can be utilized together in a method spec. In the future, the roadmap also includes globally resolvable (anywise) identifiers. Some questions are still open, e.g.: How is a did:keri globally resolvable? How do I know what are the witnesses? How exactly do you contact the witness? How are different key purposes mapped to a key event log? How can additional metadata be associated with a DID?

https://www.linkedin.com/company/healthkeri/

Experiments

If you are using KERI, ACDCs, or CESR in a product or project, or you know of someone who is, please comment here or send me a DM about it if you prefer to share it privately.

This information will help the standards process. Thanks.

Alexandre Kech Stephan Wolf Randy Warshaw Jared Jeffery, MBA, FACHDM Michael MacFarland Judith Fleenor Nuttawut Kongsuwan Kent Bull Henk van Cann Andre Kudra André Röder likecelebratesupport

Paul Knowles Stem Cell at The Human Colossus Foundation The Human Colossus Foundation leverages KERI to support decentralised authentication across all our projects.

Comment on Paul Knowles’ comment

Carly Huitema Manager, Agri-food Data Strategy, University of Guelph 1d

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 Venture builder and consultant in decentralised identity, privacy & AI Commenting because I would like to follow this list - I have been planning to compile my own 📋

Timothy Ruff Not my project, not my call… it’ll be public soon.

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.

Alexandre Kech We are at GLEIF with the vLEI and have incorporated it into the ISO 17442 LEI standard.

1 Comment on Alexandre Kech’s comment

Timothy Ruff 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!

Lance Byrd Identity Developer and Co-Founder - Secure Organizational Identity, vLEI, KERI, Open Source, Open Standards 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/

Jared Jeffery, MBA, FACHDM Founder | Cancer Survivor | Zero Trust Data for Healthcare I've heard rumors healthKERI might be on this list. <== See above

Jared Jeffery, MBA, FACHDM Founder | Cancer Survivor | Zero Trust Data for Healthcare We're waiting on Snopes to confirm.

Fergal O'Connor Senior Dev @ Cardano Foundation To add to our wallet that Jaime Caso Onzain pointed out from the Cardano Foundation, we’ve recently began working with companies such as GuildOne Inc. and Landano International Ltd. to integrate the KERI suite into their use cases. Have more coming!

Kent Bull Code Artist | KERI Evangelist | Aspiring FreeMan I have used KERI in multiple projects, personal, and at multiple companies I worked for and currently work for.

Jaime Caso Onzain Cardano Wallet Developer

Cardano Foundation in the identity mobile wallet

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!

Commentary

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

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.

KERI’s approach:

An identifier is the digest of its own key material — a self-certifying identifier (SCID). No external assertion is needed.

Nostr’s equivalent:

A Nostr npub already serves as a self-certifying identifier: it’s derived from a public key. To go further, a user can publish a root public key (an xpub) inside their kind-0 event, making that xpub the governing identity from which all active keys are deterministically derived.

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

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.

KERI’s approach:

KERI uses pre-rotation. Controllers pre-commit to the next key by publishing its digest ahead of time. When rotation happens, the previous key’s log entry already references the next, creating an immutable chain.

Nostr’s equivalent:

With BIP-32 hierarchical key derivation, we don’t need pre-rotation.

Each rotation is a deterministic step forward in the derivation path.

A signed event announces the move from child key i to child key i+1, and the newly rotated child key can sign that announcement. Also, the beauty of BIP-32 is that anyone can derive the valid child public keys (child npubs) from the xpub created at the publicly available inception event and prove for themselves that they are related to the root npub.

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

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.

KERI’s approach:

The Key Event Log (KEL): a signed, append-only, hash-chained record of every key event: inception, rotation, and interaction.

Nostr’s equivalent:

Each key rotation can be published as a signed Nostr event referencing the previous one. Together, these events form a hash-chained log distributed across relays.

A verifier can walk the chain backward from the current event to genesis, confirming every link and signature.

Nostr becomes, effectively, a decentralized KEL carried by relays instead of a dedicated KERI 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.

KERI’s approach:

End-verifiability: anyone can verify the cryptographic truth of an identifier’s state without querying an authority. Witnesses and receipts provide distributed confirmation.

Nostr’s equivalent:

Nostr relays are untrusted but redundant witnesses. Every event is signed and broadcast to many independent relays. Verification doesn’t depend on which relay delivers it, only on the signature chain and hash links.

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

If two conflicting key states exist, traditional systems offer no built-in way to expose the conflict.

KERI’s approach:

Duplicity-evident logs: conflicting events for the same sequence number can be cryptographically compared and proven inconsistent.

Nostr’s equivalent:

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

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.

In KERI, every identity is established through a self-certifying identifier. The identifier itself is derived from the cryptographic keys that control it. Nostr achieves the same outcome more simply: every npub is inherently self-certifying, and when tied to a published root public key (xpub), it serves as the foundation from which all derived keys are deterministically generated.

Where KERI maintains a formal Key Event Log (KEL), a structured, append-only record of key events. Nostr accomplishes a similar function through a sequence of signed key-update events. Each update references the previous one, forming a verifiable chain of custody distributed across relays. In both systems, a verifier can reconstruct the entire history of key control, confirming continuity from inception to the current state.

KERI’s concept of pre-rotation, where future keys are pre-committed to ensure seamless and provable rotations, finds a practical analogue in Nostr’s use of hierarchical key derivation (BIP-32). Instead of pre-publishing future keys, Nostr identities derive each new key from the same master key in a deterministic sequence. The previous key signs the rotation event, ensuring the same cryptographic continuity without the need for pre-commitment.

Similarly, with KERI’s witnesses and receipts, where independent entities that attest to key events and their order have a natural parallel in Nostr’s relays and watchers. Each relay independently stores and timestamps signed events, providing redundant, cross-verifiable records of when a key update occurred. This makes authenticity “ambient” where anyone, anywhere, can verify the cryptographic truth without relying on a central authority or registry.

Finally, both architectures address the issue of duplicity, the existence conflicting claims over key state. KERI explicitly defines duplicity-evident logs, allowing inconsistencies to be proven. In Nostr, any attempt at double-signing or publishing divergent chains would immediately surface in the public relay ecosystem. Multiple relays can serve as independent witnesses, issuing receipts that expose which event appeared first.

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

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?”

Why this all matters As we move toward decentralized communication, credentials, and signing protocols, both KERI and Nostr illuminate the same design philosophy:

Trust emerges from verifiability, not authority.

KERI formalizes that principle through specification and governance.

Nostr demonstrates it through minimalism and composability.

Different toolkits yet same cryptographic truth:

Identity should be something you can verify, not something you have to trust.

Author’s Note In addition to reviewing the KERI specification, I’ve been actively experimenting with Nostr as a lightweight environment for exploring similar trust mechanisms. Initial prototype code based on BIP-32 hierarchical key derivation has been developed to test how key-state continuity, rotation, and verification could function natively within Nostr’s event model without introducing external dependencies or registries.

This post emerged from that experimentation. Its purpose is not to critique KERI, but to use KERI’s design principles as a reference framework for exploring new requirements and design patterns for digital trust infrastructure. By comparing a formalized specification (KERI) with an emergent protocol (Nostr), the goal is to illuminate how cryptographic verifiability can manifest across very different architectural layers and to advance the broader conversation about what a truly self-verifying Internet might look like

References