notes
139 rows
This data as json, CSV (advanced)
| path ▼ | title | type | status | classification | words | body |
|---|---|---|---|---|---|---|
| INDEX | KERISuite Knowledge Base: the index | index | generated 2026-11-04 by scripts/build_resource_index.py from data/resources.yaml | partner | 91514 | |
| decisions/0004-2026-10-21-licenses-and-no-lock-in | ADR 0004: Apache 2.0 for the code, CC BY 4.0 for the content, and no lock-in | adr | amended 2026-11-03: decision 3 is replaced by ADR 0005 (a source's text is shown where its license allows it, with the credit it asks for; otherwise linked and summarized); was: consent recorded 2026-10-29: Henk van Cann's answer names Apache 2 for KERISSE's code and CC for its content and consents to the fetch of the dataset for open-source use, which this record satisfies (the content license's version still to be named; see kerisse-alignment-2026-10.md); was: proposed 2026-10-21 on Mark's word after Henk van Cann's reply; adopted when the pull request that carries it is merged; the content license is re-read against ToIP's own name for it once Henk has checked | partner | 1142 | # ADR 0004: Apache 2.0 for the code, CC BY 4.0 for the content, and no lock-in > **ADR 0004.** *Status:* proposed 2026-10-21. *Decision:* everything KSKB (the KERISuite Knowledge Base) publishes is open: its code under the Apache License 2.0, its own content under the Creative Commons Attribution 4.0 license (CC BY 4.0), the content license Trust over IP (ToIP) uses; the sources it indexes keep their own licenses and are never copied; and the whole of it is plain files in open formats on open-source tools, so that nothing in KSKB can lock the KERI community, or Mark, into a vendor, a host or a service. **Context.** On 21 October 2026 Henk van Cann answered the proposal sent to him and Kor Dwarshuis that evening ([[300-Research/310-KERISuite/docs/curator/kerisse-note-draft-2026-10|kerisse-note-draft-2026-10.md]]): the KERI Foundation and WebOfTrust use the fully open-source Apache 2.0 license and a ToIP content license, whose details he was still to check, and as long as nothing locks them into other things or into a vendor they would most likely be good to go. He will discuss it with Kor and Samuel Smith and propose a half-hour call. Mark's word the same evening: factor the two licenses into KSKB and the mockup website. What the community's own repositories say, read on 21 October 2026: - **Apache 2.0** on keripy (`WebOfTrust/keripy`), KERISSE (`WebOfTrust/kerisse`), WOT-terms (`WebOfTrust/WOT-terms`, whose LICENSE.md opens "All software and documentation in this repository are Copyright 2021 KERI Contributors" and licenses them under Apache 2.0) and KERIDoc (`WebOfTrust/keridoc`). Official, from each repository's license file or sidebar. - **The Open Web Foundation Final Specification Agreement 1.0 (OWFa 1.0)** on the KERI specification (`trustoverip/kswg-keri-specification`, LICENSE.md: "All software and documentation in this repository are Copyright 2023 KERI Contributors and all contributions to this repository are Licensed under the OWFa 1.0"). Official. That is ToIP's patent and copyright mode for a sp… |
| decisions/0005-2026-11-03-what-kskb-shows-of-a-source | ADR 0005: what KSKB shows of a source follows the source's license | adr | proposed 2026-11-03 on Mark's word; adopted when the pull request that carries it is merged; the shared text database goes live at kskb.dev after that merge; the KERI Foundation's own content stays at abstract until Henk van Cann names the Creative Commons version | partner | 1591 | # ADR 0005: what KSKB shows of a source follows the source's license > **ADR 0005.** *Status:* proposed 2026-11-03. *Decision:* what KSKB (the KERISuite Knowledge Base) shows of a source, on kskb.dev and in its shared copies, is set by that source's own license, read and recorded source by source, and by the kind of document. Where the license allows reproduction and the document is prose, the text is shown in full beside KSKB's abstract, with the credit and the notices the license asks for. Where no license is found, KSKB shows metadata, its own abstract, a link and at most a short marked quotation. Conversation (the Slack archive, repository issues and pull-request threads) is indexed and never republished. The local corpus stays a gitignored working copy. This replaces the blanket rule of ADR 0002 that the text is never shared, and decision 3 of ADR 0004 that KSKB republishes no one's text. **Context.** On 21 October 2026 the proposal to Henk van Cann and Kor Dwarshuis ([[300-Research/310-KERISuite/docs/curator/kerisse-note-draft-2026-10|kerisse-note-draft-2026-10.md]]) promised that the text of the KERISSE dataset (KERISSE is the KERI Suite Search Engine) would stay on Mark's machine and that nothing of theirs would be republished; [[300-Research/310-KERISuite/decisions/0002-2026-10-15-database-corpus-roles-reader|ADR 0002]] and [[300-Research/310-KERISuite/decisions/0004-2026-10-21-licenses-and-no-lock-in|ADR 0004]] said the same, and ADR 0002's amendment of 2 November restated it for a cloud working copy. Henk's answers of 29 October consented to the fetch for open-source use, named KERISSE's own terms as Apache 2 for the code and CC for the content, and asked for a normal acknowledgment; the README of the KERISSE repository (read on GitHub on 3 November 2026 and filed verbatim in the fetch runbook's record) says the whole dataset is uploaded so that it "stays available as a whole (e.g. for AI training)". None of that required the promise; it was KSKB's own, and nothing in the consent asked for it. On 3 … |
| development/repositories | development/ resources: generated | index | generated 2026-11-04 by scripts/build_resource_index.py from data/resources.yaml | partner | 1214 | |
| docs/contributor/contributing | Contributing to KSKB: proposals, corrections, comments, attribution | reference | v0.1.1 — 2026-10-21: the licenses set (ADR 0004); was: v0.1 — the path as designed; opens to outside contributors when the curator decides (phase 6) | partner | 533 | # Contributing to KSKB > Contributor set. KSKB is one person's curated record of the KERI Suite and its community, and it improves fastest when the people who build the suite correct it. This page is the whole agreement: what a contribution is, how it travels, and how it is credited. ## What is welcome - A correction: a version, a date, a name, an attribution, a quotation that is not exact. - A missing resource: a site, repository, paper, course, or event that belongs in the register. - A note on a specification, an implementation, a meeting, or an event, written in the community's terms with its evidence labeled. - A comment on a note: what is wrong, what is missing, what has changed. What is not: marketing copy, a company's description of itself as fact, anything about a person beyond their public role, and anything Mark cannot verify against a source you name. ## How it travels 1. **Open an issue or a pull request on the export repository** (`kerisuite-kb`, the shared repository for the core group, once it is shared with you; `ks-corpus` is the private export that ADE's tools read). A pull request may touch only `inbound/`; a guard blocks anything else, because the repository is rebuilt from the vault and an edit elsewhere would be destroyed on the next sync. 2. **Name the file in `inbound/<your-name>/YYYY-MM-DD-<what>.md`** with a header: target (the file it corrects or the folder it adds to), change (one sentence), sources (URLs or documents), and what you could not verify. 3. **Mark reviews it against the governing documents** (the specifications, the synthesis, the register) and applies what survives to the vault, with a dated line saying what changed and who proposed it. A merge on the export repository means received, not adopted. 4. **The next sync carries the result.** Your inbound file stays in the repository as the record of the proposal. ## Attribution A contribution that lands is credited in the note it changed ("corrected 2026-10-02 on a proposal by <name>") and in the register's note fie… |
| docs/contributor/outbrief-contributor | Help improve the KERISuite Knowledge Base: for contributors | outbrief | v0.1 — 2026-09-27; the path opens to outside contributors with the phase 6 decision (by mid-2027); before then, by invitation | partner | 596 | |
| docs/partner/core-group-readme | KERISuite Knowledge Base: a preview for reviewers | front-page | v0.2.2, 2026-11-03: the per-source license rule (ADR 0005); was: v0.2.1 — 2026-10-21: the licenses stated (ADR 0004); was: v0.2 — 2026-10-15: written in full by Claude for Mark's review (release plan §7, Wednesday); counts as of 15 October; not yet read by Mark | partner | 784 | # The KERISuite Knowledge Base: a preview This repository is an index of the KERI Suite. It covers the specifications, papers and talks, implementations and infrastructure, meetings, deployments, and the policy around them. Each item links to the original and carries a short abstract; the main papers and talks also have a longer summary. It links and summarizes, and copies nothing that someone else published. I am Mark Scott, the curator. I keep this as a reader and writer in the KERI community, not as one of its builders. I'm sharing it with a few of the people whose work it describes before Mini KERIConf on 2 November, so that it can be corrected before anyone else relies on it. One disclosure up front: I also founded Authentic Data Enterprises, which builds on the suite. That work lives in a separate place and nothing here presents it as the community's. ## What is in it - **About 500 items.** The figure covers: - Every link on keri.one, and every paper and deck in Samuel Smith's Papers repository. - Daniel Hardman's papers that bear on the suite. - The specifications and their versions, and the repositories, with language, license, latest release and what each depends on. - The KERIConf 2026 talks, and the policy documents. - **The meeting record.** Every meeting page the Trust over IP wiki holds, each with an abstract and the decisions its minutes record: - the KERI Suite Working Group from its first meeting in November 2024; - the ACDC Task Force from 2021 to 2024; - the did:webs Task Force from 2023; - the 2022–2023 KERI Dev Focus Calls, from Kent Bull's notes. - **Labels on every item:** its level (intro, practitioner, implementer, normative) and the kind of evidence it carries. A specification is normative, and a project's account of itself is presenter-reported or vendor-reported. ## Where to start - **[[300-Research/310-KERISuite/INDEX|INDEX]]** lists everything by topic, in reading order, in seventeen parts from "start here" to "the state of the suite". A coverage line at the to… |
| docs/partner/kerisse-grouping-2026-11/README | KERISSE documents regrouped: the grouping for Kor Dwarshuis and Henk van Cann | dataset | partner | 3401 | # KERISSE documents regrouped KSKB, the KERISuite Knowledge Base, read the dataset that KERISSE (the KERI Suite Search Engine) publishes and regrouped its records into documents: a document is the records that share one url, so a page's headings, paragraphs and list items become one page again, and a repository's file or issue stays one item. This folder gives the regrouping back, as metadata only: titles, urls, dates, counts and a proposed reading level per document, grouped by category and then by source. No source text is in it, and the Slack archive is left out. Generated 2026-11-03 by `scripts/corpus_kerisse.py grouping` from KSKB's tracked catalog. KERISuite Knowledge Base (KSKB), Mark Scott, curator; CC BY 4.0. Found through KERISSE, the KERI Suite Search Engine of Kor Dwarshuis and Henk van Cann; the dataset is published at https://keri.foundation/kerisse/dataset/. ## How to load it Each JSON file (JavaScript Object Notation) holds one category (the Repository category is split by GitHub owner, to keep each file under about 1 MB): a `header` (the date, the counts, the credit and the acknowledgment) and a list of `sources`, each with its `items`. In Python, `json.load(open('blogs.json'))['sources']` gives the sources, and `[i for s in data['sources'] for i in s['items']]` flattens them to one row per document; `jq '.sources[].items[]'` does the same from a shell. Every item carries the `id` KSKB uses (`<source>/<n>`), the `url` that joins it back to KERISSE's own records, and `level_proposed`, one of intro, practitioner, implementer or normative, which could fill the dataset's knowledgeLevel field once reviewed. `kskb_cards` on a source names its card in the KSKB register. `kind` on an item says what the url is (a web page, a PDF, a glossary term, a specification file, a repository prose file, a subtitle file, an issue or pull request, a code or configuration file, a build artifact or binary), which separates the reading material from the source trees and the build output the scrape also holds. `licen… | |
| docs/partner/outbrief-partner | Working with the KERISuite Knowledge Base: for partner organizations and resources | outbrief | v0.1 — 2026-09-27; for organizations, working groups and other knowledge resources in the KERI community; most of what it proposes begins with publication (phase 6, by mid-2027) | partner | 574 | |
| docs/public/outbrief-public | The KERISuite Knowledge Base: for readers | outbrief | v0.1 — 2026-09-27; written for the day KSKB is published (phase 6, a decision due by mid-2027); until then it describes a private system | public | 604 | |
| docs/public/user-guide | KSKB user guide: how the KERISuite Knowledge Base is laid out and how to use it | reference | v0.1.3, 2026-11-03: the per-source license rule (ADR 0005); was: v0.1.2 — 2026-10-23: a section on what KSKB is, a knowledge base as distinct from a knowledge system; was: v0.1.1 — 2026-10-21: the licenses (ADR 0004); was: v0.1 | public | 725 | # KSKB user guide > For readers. KSKB is a curated record of the KERI Suite (KERI, ACDC, CESR, TSP, and the ecosystem built on them): what the specifications say, where to learn, what is implemented, who is building on it, what the working group decided, what happened at the conferences, and where governments have taken an interest. It is maintained by Mark Scott, a reader and writer in the KERI community, and it cites the community's own sources rather than replacing them. ## If you have an hour 1. Read the reading path at the top of [[../../learning/kerisuite-learning-resources|Where to learn the KERI Suite]] and follow its first two steps: the *Hitchhiker's Guide to KERI* and the *KERI for Muggles* deck. 2. Keep the KERI Suite glossary open: https://trustoverip.github.io/kerisuite-glossary/. 3. Skim [[../../research/KERI_Reference_skinny|the two-page reference]]. ## If you have a day Work through GLEIF's vLEI training notebooks 101 (the KLI, identifiers, rotation, witnesses, credentials), then read the KERI specification's introduction and the matching sections of [[300-Research/310-KERISuite/research/KERI_Reference_skinny|the two-page reference]] that match what you just did. The learning-resources note lists everything with who maintains it and how current it is. ## If you are building Start at [[300-Research/310-KERISuite/development/README|development/]] for the implementation notes and the two device analyses, then GLEIF's notebooks 102 (KERIA and Signify) and the Veridian getting-started pages, then Kent Bull's configuration and key-derivation posts. The [[300-Research/310-KERISuite/standards/README|standards/]] folder holds the working group's monthly minutes, where implementation questions get settled. ## How the folders are laid out | Folder | Ask it for | |---|---| | [[300-Research/310-KERISuite/research/README\|research/]] | the syntheses: the two-page reference, the full synthesis, the cryptography note | | [[300-Research/310-KERISuite/specifications/README\|specifications/]] | notes on e… |
| docs/supporter/outbrief-supporter | Supporting the KERISuite Knowledge Base — for sponsors | outbrief | v0.1 — 2026-09-27, DRAFT; whether KSKB accepts sponsorship at all is the curator's decision, taken with publication (phase 6, by mid-2027); until then nothing here is an offer | partner | 551 | |
| ecosystem/resources | ecosystem/ resources: generated | index | generated 2026-11-04 by scripts/build_resource_index.py from data/resources.yaml | partner | 1606 | |
| events/README | events/ | partner | 220 | # events/ Conferences and sessions on the suite. - **[[300-Research/310-KERISuite/events/kericonf-2026/README|kericonf-2026/]]**: the first KERIConf, Lehi, 21–23 April 2026: a note per session (29), curated transcripts with timestamps, and fourteen speaker decks as PDFs. Start at its README. - **Mini KERIConf, 2 November 2026** (Mountain View, the day before IIW 43): invited speakers only, program full as of 9 October. **KERIConf 2027** is planned for two days in April. - **[[300-Research/310-KERISuite/events/KERIConf26Recordings|KERIConf26Recordings.md]]**: the recordings note; the Foundation's video page is a register entry, and access is to be confirmed before it is cited as public. - **[[300-Research/310-KERISuite/events/iiw-sessions|iiw-sessions.md]]**: the index of IIW sessions on the suite, 135 sessions in fourteen workshops from IIW 29 (October 2019) to IIW 42 (April 2026), read from the Books of Proceedings on 21 October 2026, each with its convener, its page in the proceedings and the archived wiki notes where they survive; one card per session and per workshop in the register (`via: iiw-NN`, `series: iiw`); the IIW 43 plans and the capture rule. - **[[sedi-summits]]**: the SEDI Workshop and Summits, Utah S.B. 275 (2026), and the 2026 Summit; the policy texts are in [[300-Research/310-KERISuite/events/../policy/README|../policy/]]. - **[[300-Research/310-KERISuite/events/resources|resources.md]]**: generated from the register: events and recordings. After each event: one row in the index per session attended, a note only for a session the vault will cite, the program registered. | ||
| events/iiw-sessions | KERI at the Internet Identity Workshop: every session on the suite, 2019 to 2026 | index | v0.2 — 2026-10-21: the proceedings walked (the Books of Proceedings of IIW 28 to 42 from the workshop's site, and the wiki's session pages through the Internet Archive, since iiw.idcommons.net no longer resolves): 135 sessions on the suite in fourteen workshops, one card each in the register, listed here by workshop with convener and notes link; was: v0.1 — 2026-09-17; the skeleton and what the vault already records | partner | 3899 | |
| events/resources | events/ resources: generated | index | generated 2026-11-04 by scripts/build_resource_index.py from data/resources.yaml | partner | 7470 | |
| events/talks/README | events/talks/ | partner | 63 | # events/talks/ Summary notes for webinars, keynotes, podcasts and other recorded talks that are not part of a conference folder: one note per item, linked from its card's `summary` field in [[300-Research/310-KERISuite/data/resources.yaml|resources.yaml]]. The KERIConf 2026 talks have their summary notes here too (`kericonf26-*`), drafted from the curated transcripts; the conference folder ([[300-Research/310-KERISuite/events/kericonf-2026/README|kericonf-2026/]]) keeps the curator's own working notes and the transcripts. Template: [[300-Research/310-KERISuite/docs/developer/note-template|note-template.md]]. | ||
| events/talks/kericonf26-01-bull-keria-tutorial | Kent Bull: KERIA Tutorial (KERIConf 2026) | summary | v0.1 — 2026-10-15: drafted by Claude from the curated transcript; unread by Mark; marked partner on Mark's word 2026-10-21, paraphrase only, no quotation | partner | 765 | # Kent Bull: KERIA Tutorial (KERIConf 2026) **Abstract.** Kent Bull gave a developer-focused tutorial on KERIA (the KERI agent server, where KERI is Key Event Receipt Infrastructure) and the Signify edge-signing clients that work with it. He explained the signing-at-the-edge architecture, walked through a demo wallet, and covered the configuration details and common mistakes developers meet. The session is for developers who plan to build on or operate KERIA. ## Summary Bull opened by framing the session as hands-on and developer-oriented. He noted that the Signify and KERIA architecture is used in production by several qualified vLEI issuers (vLEI is the verifiable Legal Entity Identifier) in the GLEIF (Global Legal Entity Identifier Foundation) ecosystem, naming Provenant, Finema, CFCA and Certizen, and that the Veridian wallet is built on it. He stressed that the wallet in his demo is a developer demo, not any issuer's product. In answer to an audience question about whether the client is a web app, mobile app or extension, he explained that the client runs anywhere TypeScript and the browser build of Libsodium can run: a browser, Ionic Capacitor or React Native. He then offered his own terminology for two kinds of wallet. A lightweight wallet (Signify with KERIA) keeps only an edge signing client in the user's hands, holding keys unencrypted in memory and minimal state. A heavyweight wallet, with Locksmith from healthKERI (Philip Feairheller's project) as his example, keeps keys, credentials and state together locally with no server agent. He described the agent as the server side of the lightweight model: a mailbox (a store-and-forward service so messages reach an offline phone), a delegation communication proxy, and the primary data store for ACDCs (Authentic Chained Data Containers), contacts, OOBIs (Out-Of-Band Introductions) and key event logs. Key seeds are stored at the agent only in encrypted form, encrypted with a key derived from a passcode that never leaves the edge. Provisioning is a two-ste… |
| events/talks/kericonf26-02-argoud-kram | Ari Argoud: KRAM IT! with Ari (KERIConf 2026) | summary | v0.1 — 2026-10-15: drafted by Claude from the curated transcript; unread by Mark; marked partner on Mark's word 2026-10-21, paraphrase only, no quotation | partner | 791 | # Ari Argoud: KRAM IT! with Ari (KERIConf 2026) **Abstract.** Ari Argoud presented KRAM, the KERI (Key Event Receipt Infrastructure) Request Authentication Mechanism, which protects non-key-event messages against replay by checking that each message is both authentic and timely. The talk walked through the authentication types, the timeliness windows, the attacks that arise when those windows change, and the configuration for incremental adoption. It is aimed at implementers and operators of KERI v2 systems. ## Summary Argoud opened by defining KRAM as the authentication mechanism for every message in the KERI protocol that is not a key event: ESSR (encrypt sender, sign receiver) messages for secure APIs, which he described as a replacement for shared-secret account management, exchange messages for negotiating contracts, and credential presentations. The problem it solves is making sure a message is timely and authentic, so that an attacker who intercepts a valid signed message cannot replay it later. Each message carries a datetime stamp, and the receiver checks it against a window relative to its own clock; messages already seen or outside the window are dropped. KRAM sits at the top of the non-key-event processing pipeline, right after basic allow and deny filtering. It is designed for KERI v2, and it replaces an earlier approach of escrowing messages whose authentication data was missing with dropping them and notifying, so the sender's KEL (Key Event Log) can be fetched by a separate mechanism. After a short review of terms (AIDs, or autonomic identifiers; KELs; key state; SAIDs, or self-addressing identifiers, as digests of a message; and seals as cryptographic commitments anchored in a KEL), he described three authentication types: an anchoring seal reference, where the sender pre-authenticates a message by anchoring its digest in its own KEL; a single-key signature; and a multi-key signature. The type is resolved from key-list cardinality, and checks are ordered cheapest first to limit amplification… |
| events/talks/kericonf26-03-jeffery-fhir-and-cms | Jared Jeffery: FHIR and CMS (KERIConf 2026) | summary | v0.1 — 2026-10-15: drafted by Claude from the curated transcript; unread by Mark; marked partner on Mark's word 2026-10-21, paraphrase only, no quotation | partner | 810 | # Jared Jeffery: FHIR and CMS (KERIConf 2026) **Abstract.** Jared Jeffery, chief executive and founder of healthKERI, gave a primer on US healthcare interoperability for the KERI (Key Event Receipt Infrastructure) community: why healthcare is the most attacked industry, how the Centers for Medicare and Medicaid Services (CMS) turns industry standards into mandates, what FHIR (Fast Healthcare Interoperability Resources) is, and what the CMS-0057-F rule requires. He closed with the VITAL (Verifiable Identity and Trust Automation Layer) initiative, which proposes the vLEI (verifiable Legal Entity Identifier) as the trust layer for FHIR connections. The talk is for KERI practitioners coming up to speed on healthcare as an application domain. ## Summary Jeffery introduced healthKERI as a startup working on what he called the missing trust layer for healthcare, built on open protocols. He gave his background in healthcare information technology and research, and explained that his motivation is personal: as a brain cancer patient he depended on a single treatment machine, and ransomware that shuts down a hospital diverts ambulances and puts patients at risk. He described healthcare as the most targeted industry for a decade running. A patient record is worth far more than a credit card on the black market because its contents (identity numbers, birth date, diagnoses) cannot be rotated. Stolen data feeds fraud, such as fake clinics billing CMS, and extortion, which he said AI (artificial intelligence) has made cheap enough to aim at individual patients. A typical health system or payer has around 1,500 vendor connections, each an attack surface; attackers move through trusted, encrypted channels by stealing shared secrets such as passwords and bearer tokens. His proposal is to remove shared secrets altogether. He reported a penetration test of a KERI-based system carrying FHIR traffic in which testers found no serious flaws, and said healthKERI regards KERI-based connectivity as a replacement for TLS (Transport Lay… |
| events/talks/kericonf26-04-davis-contract-credentials | Cole Davis: Contract Credentials and Verifiable Identity (KERIConf 2026) | summary | v0.1 — 2026-10-15: drafted by Claude from the curated transcript; unread by Mark; marked partner on Mark's word 2026-10-21, paraphrase only, no quotation | partner | 834 | # Cole Davis: Contract Credentials and Verifiable Identity (KERIConf 2026) **Abstract.** Cole Davis, founder of Switchchord, a legal technology and digital identity company in the music industry, presented the idea of a contract credential: a verifiable credential derived directly from a legal contract, so that a party can prove what it has the contractual authority to do. He walked through a commercial lease example built on KERI (Key Event Receipt Infrastructure) identifiers and ACDCs (Authentic Chained Data Containers), showed a simulated demonstration, and took questions. The talk suits readers interested in authority, delegation and legal workflows. ## Summary Davis opened by describing his background as a corporate and entertainment lawyer running Switchchord, a brand under an IP (intellectual property) holding company, Steamroller Systems, that applies machine learning and decentralized identity to legal workflows. For years he had wanted a dual root of trust for contractual authority: a legal root and a cryptographic root, bound together. He looked first at blockchains and then at W3C (World Wide Web Consortium) DIDs (decentralized identifiers) and VCs (verifiable credentials), and found KERI in 2021, chiefly because it needs no underlying ledger. He observed that credentials usually prove who someone is, rarely what they are authorized to do under a contract. He described a contract credential as one that shows, for example, that an officer may sign documents above a set amount by board authority, or that an employee may enter a building because the employer holds a lease. Today the contract and the operational authority it confers live in separate systems; he proposed collapsing them so the contract is the credential. He tied this to Ronald Coase's idea of transaction costs. His route to KERI came from modeling a copyright co-owned by four music companies. A ledger-based DID method would have required every owner to interact with a blockchain to rotate keys; KERI lets each party manage its own key… |
| events/talks/kericonf26-05-feairheller-infrastructure-for-security | Philip Feairheller: Infrastructure for Security (KERIConf 2026) | summary | v0.1 — 2026-10-15: drafted by Claude from the curated transcript; unread by Mark; marked partner on Mark's word 2026-10-21, paraphrase only, no quotation | partner | 756 | # Philip Feairheller: Infrastructure for Security (KERIConf 2026) **Abstract.** Philip Feairheller, chief technology officer and co-founder of healthKERI, presented the layers of security in KERI (Key Event Receipt Infrastructure) and the infrastructure healthKERI has built for them: the Locksmith wallet, witnesses offered as a service, and a global watcher network. Most of the session was a live demo. It is for developers and operators deciding how to run wallets, witnesses and watchers. ## Summary Feairheller began with the teaching slide he uses for newcomers, a stack of security layers. At the bottom are self-certifying identifiers and CESR (Composable Event Streaming Representation), which he described as solving the two hard problems of PKI (public key infrastructure): binding an identifier to its first keys and binding it through every rotation. Above that come pre-rotation and key event logs, then delegation and distributed group multisignature, and at the fourth layer witnesses and watchers. The first three layers live in the wallet; the fourth is the infrastructure healthKERI has donated to the KERI Foundation as open source. He introduced Locksmith, which began as his own alternative to the KERIpy command line and grew into a production wallet. Its open-source core covers local key state, vaults (his name for what KERIpy calls habery environments), identifiers, delegation, multisignature groups, rotation, schemas, credential issuance and the IPEX (Issuance and Presentation Exchange) protocol, with no server required and an export of key event logs as CESR. Integration with healthKERI's software-as-a-service platform was wrapped as a plugin interface so others can add their own services, and a further plugin manages multisignature coordination for vLEI (verifiable Legal Entity Identifier) issuance across an enterprise. KERI messages also feed a notification system. The demo created a vault and an identifier with a single step, showed the advanced options (keychain, salt or random keys, M-of-N thre… |
| events/talks/kericonf26-06-oconnor-signify-security-architecture | Fergal O'Connor: Signify Security Architecture (KERIConf 2026) | summary | v0.1 — 2026-10-15: drafted by Claude from the curated transcript; unread by Mark; marked partner on Mark's word 2026-10-21, paraphrase only, no quotation | partner | 850 | # Fergal O'Connor: Signify Security Architecture (KERIConf 2026) **Abstract.** Fergal O'Connor, identity solutions lead architect at the Cardano Foundation and a builder of the Veridian wallet, explained the security architecture of KERIA, the cloud agent for KERI (Key Event Receipt Infrastructure), and Signify, its edge client library. He covered the service layout, the trust relationship between client and agent, and how managed identifiers reach the rest of the network. The talk was on the advanced track, for developers who already know KERI. ## Summary O'Connor introduced Veridian, the Cardano Foundation's open-source identity wallet, which he described as the first production mobile wallet in the KERI and ACDC (Authentic Chained Data Container) ecosystem, built on KERIA and Signify-ts and audited and penetration-tested. His tagline was agent in the cloud, controller at the edge: using a cloud agent does not mean giving up control of keys. Drawing on the five controller functions in the KERI specification, he showed how they can be split so that the edge generates keys and signs events while the cloud agent stores encrypted key material and performs validation, keeping edge applications light. KERIA is a multi-agent Python service built on KERIPy, with an isolated database per agent and one Signify client per agent. Signify is stateless apart from the key material it is given, and all signing happens at the edge. Implementations include Signify-ts, SignifyPy and a full Java implementation built at the Cardano Foundation. KERIA exposes three ports: a boot port for provisioning agents, which Veridian blocks from public access and opens through one-time boot links; an authenticated admin API; and an external CESR (Composable Event Streaming Representation) port, whose message router hands inbound streams to the right agent. For the trust relationship, Signify takes a 21-character passcode, a salt stretched with Argon2id along a derivation path, to produce Ed25519 signing and rotation keys for a client AID … |
| events/talks/kericonf26-07-smith-digital-identity-tradespace | Samuel M. Smith: The Digital Identity Tradespace (KERIConf 2026) | summary | v0.1 — 2026-10-15: drafted by Claude from the curated transcript; unread by Mark; marked partner on Mark's word 2026-10-21, paraphrase only, no quotation | partner | 777 | # Samuel M. Smith: The Digital Identity Tradespace (KERIConf 2026) **Abstract.** Samuel M. Smith explained the design trades behind KERI (Key Event Receipt Infrastructure) and ACDC (Authentic Chained Data Containers), and in particular why the suite addresses privacy through bulk issuance and blinded state registries rather than through other mechanisms. The talk was a detailed, technical session for people already familiar with the suite's basics. The transcript ends partway through the section on identity assurance. ## Summary Smith opened with the suite's policy of security first: when a design choice would trade weaker security for a gain elsewhere, the trade is declined, because over time every weakened security trade becomes a bad one. The question is then how well the other problems can be solved under that constraint. In KERI each AID (autonomic identifier) controller is its own identity provider, with keys at the edge and no third-party identity providers or trusted intermediaries. Picking up from his plenary, he named RAPC3 (Reputable Autonomic Pseudonymity and Control over Confidential Contexts) and said privacy is addressed through control over confidential contexts, which bulk issuance gives the user. He stressed that all shared information is correlatable to some degree, and that unlinkability differs from uncorrelatability. He described an ACDC as a graph fragment whose edges are part of what is authenticated, so fragments from different sources compose securely into a labeled property graph. This supports delegable, attenuable, aggregable, revocable and transferable authority, and lets credentials model real-world authority structures, organizational or parental, instead of fitting them to session-based models such as OAuth and OIDC (OpenID Connect). ACDCs aim at perpetually verifiable issuances, the harder problem, while ephemeral uses remain possible. He listed the suite's disclosure mechanisms: graduated, compact, metadata, partial, nested partial, full and selective disclosure, bulk-issu… |
| events/talks/kericonf26-08-hansen-witnesses-watchers | Ryan Hansen: Witnesses and Watchers (KERIConf 2026) | summary | v0.1 — 2026-10-15: drafted by Claude from the curated transcript; unread by Mark; marked partner on Mark's word 2026-10-21, paraphrase only, no quotation | partner | 778 | # Ryan Hansen: Witnesses and Watchers (KERIConf 2026) **Abstract.** Ryan Hansen, a member of the KERI Foundation development team, gave a walkthrough of deploying KERI (Key Event Receipt Infrastructure) witnesses, watchers and a boot service from the code that healthKERI open sourced. He summarized the core concepts, stepped through the setup guide in the KERI Foundation's boot repository, and demonstrated a wallet provisioning witnesses against the KERI Foundation's demonstration host. The session is for people who want to stand up this infrastructure themselves. ## Summary Hansen introduced himself as part of a new KERI Foundation development team and framed the session around three components: the boot service, witnesses and watchers, plus deployment to the web in general. He pointed the audience to the setup guide in the KF boot repository under the KERI Foundation GitHub organization and said he would summarize it rather than run it live. He recalled the core concepts: KERI is about keys, of two kinds, signing keys and rotation keys; key events, which he grouped into single-signature and multi-signature events; and the KEL (key event log) that records them. Everything else supports that core. For the roles of the ecosystem's components he recommended Samuel Smith's white paper and slides, linked from keri.one. He gave three disclaimers. The guide is opinionated, one of many ways to deploy. The services are Falcon applications, plain Python over HTTP, and still work in progress; the witness and watcher code is in production use at healthKERI, while the boot service is newer. And the guide is a demonstration that runs several witnesses on one host, which is not a production setup. For production he sketched witness and watcher providers spread across cloud regions and availability zones, with a wallet able to choose among one or several providers to widen its witness pool. The steps followed: an Ubuntu 24.04 base with libsodium, Nginx for TLS (Transport Layer Security) termination and reverse proxying, … |
| events/talks/kericonf26-09-elliot-open-keri-infrastructure | Jay Alexander Elliot: Open KERI Infrastructure (KERIConf 2026) | summary | v0.1 — 2026-10-15: drafted by Claude from the curated transcript; unread by Mark; marked partner on Mark's word 2026-10-21, paraphrase only, no quotation | partner | 708 | # Jay Alexander Elliot: Open KERI Infrastructure (KERIConf 2026) **Abstract.** Jay Alexander Elliot presented the open-source, debranded version of the Locksmith desktop wallet for KERI (Key Event Receipt Infrastructure) that healthKERI donated, and argued that the controller-side wallet must stay separate from any single provider's services. The short talk was followed by a demo and an open question period. It is for builders who want to run or extend an open KERI wallet. ## Summary Elliot introduced Locksmith as the desktop wallet for KERI and pointed the room to a public demo repository with setup instructions. His theme was the controller side of the system, where keys stay local and the user manages identifiers. In KERI, he explained, the controller is what actually controls the AID (autonomic identifier) by managing its keys through the key event life cycle. If the user-facing wallet is absorbed into one vertically integrated stack, the system can look open on paper but become less open in practice. For KERI to remain open, the wallet has to remain separate, and that separation has to be real and verifiable. He placed Locksmith in the stack as the controller-side wallet layer. Witnesses and watchers stay outside it, and providers (witness and watcher operators, credential services, workflow services and other integrations) connect to it through a plugin boundary without becoming the wallet. The first thing Locksmith demonstrates is local state: multiple local vaults and controller-owned state on disk, with portability to come later. The architecture flow he described has the user signing and storing locally, the wallet talking to providers through the plugin boundary, events going to witnesses and watchers with receipts coming back, and verifiers kept out of that path. He drew a line between what exists now and what is next. Available now are the desktop identity vault, local identifier workflows, the plugin boundary in code and a repeatable setup. Still to come are the KERI Foundation's own provider … |
| events/talks/kericonf26-10-smith-state-of-the-keri-suite | Samuel M. Smith: State of the KERI Suite (KERIConf 2026) | summary | v0.1 — 2026-10-15: drafted by Claude from the curated transcript; unread by Mark; marked partner on Mark's word 2026-10-21, paraphrase only, no quotation | partner | 862 | # Samuel M. Smith: State of the KERI Suite (KERIConf 2026) **Abstract.** Samuel M. Smith opened the first KERI Conference with a talk on the state of the KERI (Key Event Receipt Infrastructure) suite and its path to adoption. He set out why he expects adoption to reach a tipping point, traced the history of the ideas behind the suite, and described the KERI Foundation's open infrastructure work and two new infrastructure components. The talk is for anyone who wants the context and direction of the suite. ## Summary Smith thanked Henk van Cann, then listed what 2026 had already brought: the suite released as Linux Foundation open standards, a Utah grant to build a digital identity utility for SEDI (state-endorsed digital identity) on KERI, telecom proofs of concept with the verifiable voice protocol, Utah's law funding SEDI, healthcare work with the vLEI (verifiable Legal Entity Identifier) and the SEDI policy summit. He framed adoption with the three rules of Malcolm Gladwell's book The Tipping Point. For the law of the few, he named three adoption vectors (telecom, healthcare and state entitlements), two bootstrap vectors (GLEIF's organizational root of trust and a new personal root of trust from Utah) and a scale vector of open standards, source and infrastructure. For stickiness, he pointed to fraud, regulatory pressure, a public sense of digital exploitation and growing familiarity with key management. For context, he argued that AI-driven impersonation and surveillance make the timing right, and that Utah's duty of data loyalty, a fiduciary standard rather than a harm standard, gives people a way to act against self-dealing with their data. He added that the narrow solution space means any working answer will resemble KERI, and predicted the tipping point before the end of 2027. The history ran from RAET (Reliable Asynchronous Event Transport), which left key management unsolved; through early papers on reputation and self-sovereign identity; the Sovrin Foundation and the ledger wars; the 2018 paper th… |
| events/talks/kericonf26-11-mcewan-landscape-of-sedi | George McEwan: The Landscape of SEDI (KERIConf 2026) | summary | v0.1 — 2026-10-15: drafted by Claude from the curated transcript; unread by Mark; marked partner on Mark's word 2026-10-21, paraphrase only, no quotation | partner | 794 | # George McEwan: The Landscape of SEDI (KERIConf 2026) **Abstract.** George McEwan, privacy architect for the State of Utah, walked through the presentation the state gives non-technical audiences on SEDI (State-Endorsed Digital Identity), with emphasis on healthcare and rural care. He set out SEDI's principles, the boundaries of what the state will and will not do, and the problems he expects SEDI and KERI (Key Event Receipt Infrastructure) to address. The talk is for KERI practitioners who want to see how a state frames the program and where it leaves room for the private sector. ## Summary McEwan began from his time as information technology director at the state health department during the COVID-19 pandemic, when public backlash to government-offered technology taught the state to set frameworks and regulation while leaving some roles to the private sector and the individual. He described the program's framing, which he credited to Chris Bramwell, of grounding digital identity in constitutional rights rather than vendor needs. Whoever holds the data holds control; today institutions own people's identity data and grant it back with limited rights, and errors in that data harm real people, as in his example of a Medicaid eligibility outage leaving a patient without medication. Under SEDI, identity belongs to the individual and the state endorses it for legal purposes after vetting. He contrasted this with mobile driver's licenses: a SEDI is meant to be perpetual, so records associated with it survive a move to another state, while state-specific privileges such as a driving endorsement are replaced. He described the risks of government aggregation of health data, such as all-payer claims databases. He then went through the program's principles, inviting the audience to note which KERI solves or enhances. Privacy and autonomy: no monitoring by government or third parties, no cross-context correlation, selective disclosure, and personas that bundle common disclosures. Delegation and guardianship: parent a… |
| events/talks/kericonf26-12-hardman-open-verifiable-communications | Daniel Hardman: Open Verifiable Communications (KERIConf 2026) | summary | v0.1 — 2026-10-15: drafted by Claude from the curated transcript; unread by Mark; marked partner on Mark's word 2026-10-21, paraphrase only, no quotation | partner | 807 | # Daniel Hardman: Open Verifiable Communications (KERIConf 2026) **Abstract.** Daniel Hardman, CTO (chief technology officer) of Provenant, presented OVC (Open Verifiable Communications), a GSMA (the mobile industry association) Foundry project that attaches verifiable evidence to phone calls so that a recipient, network or regulator can check who is calling and on whose authority. He played the project's demonstration, explained the Verifiable Voice Protocol and the dossier of credentials behind it, and described the follow-on work. The talk is for readers interested in a large-scale application of KERI (Key Event Receipt Infrastructure) and ACDCs (Authentic Chained Data Containers) in telecommunications. ## Summary Hardman began with the scale of phone and text scams: advice to stop answering the phone amounts to an existential threat for businesses that depend on calls. In his Microsoft example, customers ignore genuine support callbacks, and Ofcom, the UK communications regulator, will not let a call from an offshore contact center present a UK number unless the caller can prove it is Microsoft. He then played a demonstration first shown at Mobile World Congress. Credentials issued to Microsoft prove its right to the displayed telephone number, its legal identity through an LEI (Legal Entity Identifier), and its right to the brand; a fourth credential delegates signing to a platform such as Infobip, Twilio or Vonage. A call from a US number to a prepaid Spanish SIM displayed the verified name, number and brand. The governance model runs from a governance authority to policy administrators per jurisdiction, to vetting agents, to enterprises, all chained so that any link can be revoked with a cascading effect. A second call, after one credential was revoked, was rejected by the transit operator, and an evidence record showed which credential failed and who had vetted the enterprise. The call flow uses a signing service, a passport carried over the PSTN (public switched telephone network), verification by a… |
| events/talks/kericonf26-13-panel-provenanting-medical-records | Scott Stuewe, Mark Scrimshire, Jared Jeffery: Provenancing Patients' Medical Records (panel) (KERIConf 2026) | summary | v0.1 — 2026-10-15: drafted by Claude from the curated transcript; unread by Mark; marked partner on Mark's word 2026-10-21, paraphrase only, no quotation | partner | 787 | # Scott Stuewe, Mark Scrimshire, Jared Jeffery: Provenancing Patients' Medical Records (panel) (KERIConf 2026) **Abstract.** Three panelists, Mark Scrimshire (chief interoperability officer at ONYX), Scott Stuewe (president and chief executive of DirectTrust) and Jared Jeffery (founder and chief executive of healthKERI), described how the vLEI (verifiable Legal Entity Identifier) could identify organizations and their authority in United States healthcare data exchange. They framed the problem, the regulatory deadline driving it and a proposed payer-to-payer pilot. The session is for anyone interested in applying KERI (Key Event Receipt Infrastructure) credentials to healthcare interoperability. No moderator is named in the transcript; the panelists hand off to one another. ## Summary **Who spoke.** Scrimshire described his background building the Blue Button 2.0 API at CMS (the Centers for Medicare and Medicaid Services) and writing HL7 implementation guides. Stuewe described DirectTrust as a nonprofit trade association supporting trust in healthcare, whose members operate a PKI (public key infrastructure) framework. Jeffery described healthKERI's aim to bring KERI into healthcare data exchange. **The problem.** The panelists described a vast, diffuse ecosystem in which protected health information must move securely among many kinds of organizations. Individual providers are enumerated in the federal NPPES database, but organizations are poorly identified and payers not at all, and onboarding is light. In the national networks, Carequality and TEFCA (the Trusted Exchange Framework and Common Agreement, operated through QHINs, qualified health information networks), messages pass through several hops, so receivers often cannot tell who sent them. Digital certificates show control of a domain but say little about the organization. Scrimshire stressed that individual identity is not enough: what matters is the organizational context a person is acting in. **The deadline.** The CMS-0057 rule expands patient a… |
| events/talks/kericonf26-14-panel-public-private-partnerships | George McEwan: How KERI Enables Better Private-Public Partnerships (KERIConf 2026) | summary | v0.1 — 2026-10-15: drafted by Claude from the curated transcript; unread by Mark; marked partner on Mark's word 2026-10-21, paraphrase only, no quotation | partner | 842 | # George McEwan: How KERI Enables Better Private-Public Partnerships (KERIConf 2026) **Abstract.** George McEwan moderated the closing panel of the first day, on how KERI (Key Event Receipt Infrastructure) can support partnerships between government and industry, with a focus on healthcare. Panelists from Utah state government, DirectTrust, GLEIF (the Global Legal Entity Identifier Foundation), healthKERI and a former CMS (Centers for Medicare and Medicaid Services) role discussed how they came to identity work, what KERI could solve in healthcare within five years, the barriers to adoption and the one regulatory change each would make. It is for anyone working on policy, healthcare or public-sector adoption. ## Summary The transcript names the panelists by first name. Following the vault's event record, they are Chris Bramwell (Utah's chief privacy officer), Scott Stuewe (DirectTrust), Mark Scrimshire (formerly of CMS), Karla McKenna (GLEIF) and Jared Jeffery (healthKERI). **How each came to identity.** The DirectTrust panelist traced his interest to patient-matching projects in which records could only be matched probabilistically and duplication stayed high for decades, and he argued that the first transaction, when someone is enrolled, decides everything after it. The former CMS panelist described trying to automate registration of third-party health apps, which needed a way to confirm an organization's identity and led him toward KERI. Karla McKenna described her path from financial-services identifiers through the LEI (Legal Entity Identifier) to the vLEI (verifiable LEI). Jared Jeffery said that his generation grew up without a line between physical and digital identity. Chris Bramwell described calls from people who had lost control of their data and his conclusion that government needs individual identity as its anchor of trust. **Public-private partnership.** Bramwell recounted how Utah's engagement began when Samuel Smith and colleagues presented KERI to state officials, who were skeptical but ke… |
| events/talks/kericonf26-d2-01-smith-the-future-of-keri | Samuel M. Smith: The Future of KERI (KERIConf 2026) | summary | v0.1 — 2026-10-15: drafted by Claude from the curated transcript; unread by Mark; marked partner on Mark's word 2026-10-21, paraphrase only, no quotation | partner | 827 | # Samuel M. Smith: The Future of KERI (KERIConf 2026) **Abstract.** In the Day 2 opening plenary, Samuel M. Smith described where he sees KERI (Key Event Receipt Infrastructure) and ACDC (Authentic Chained Data Containers) going next: bridging trust domains, using ACDCs as general authorizations, handling revoked delegation chains through reversion and transfer of registry control, applying the same mechanisms to AI agents, and building accountable digital refuges with TSP (Trust Spanning Protocol). Parts of the talk are proposals for the next ACDC specification version. It is for implementers and specification readers. ## Summary Smith framed his work as an effort to fix the internet, which he came to see required solving identity. He reviewed ACDCs as graph fragments that each authenticate separately, giving perpetually verifiable issuances and delegable, attenuable, aggregable, revocable and transferable authority. With these, ACDCs can carry trust between trust domains without loss, a property he described using Daniel Hardman's phrase lossless trust transfer. Systems that cannot bridge trust domains instead enlarge a single domain, which in his account produces recursive privilege escalation attacks. He then introduced EVAC (Edge Verifiable Access Control): a resource controller grants access to another edge through an ACDC, and mutual authentication at every edge prevents impersonation, unlike a VPN (virtual private network) relying on a shared secret. His proposal, not yet published as a white paper, adds a resource map to the ACDC attribute section, listing routes and capabilities in the manner of object capabilities. He pointed to an issuee registry field already in the specification: if the holder anchors each presentation in a registry it controls, a verifier checks both the issuer and the presenter registries, and the holder can detect theft of its signing keys. The next problem was delegation chains in which a delegate's authority is revoked after it has issued credentials, such as purchase ord… |
| events/talks/kericonf26-d2-02-feairheller-acdcs-for-authorization | Philip Feairheller: ACDCs for Authorization (KERIConf 2026) | summary | v0.1 — 2026-10-15: drafted by Claude from the curated transcript; unread by Mark; marked partner on Mark's word 2026-10-21, paraphrase only, no quotation | partner | 780 | # Philip Feairheller: ACDCs for Authorization (KERIConf 2026) **Abstract.** Philip Feairheller, CTO (chief technology officer) and co-founder of healthKERI, showed how healthKERI extended OAuth 2.0 so that ACDCs (Authentic Chained Data Containers), beginning with the vLEI (verifiable Legal Entity Identifier), can register clients, authenticate users and protect data disclosure in healthcare data exchange. He opened with a recorded demonstration and then walked through the protocol changes and the supporting infrastructure. The talk suits implementers working where KERI (Key Event Receipt Infrastructure) meets existing identity standards. ## Summary Feairheller started with a demonstration first prepared for the SEDI (State-Endorsed Digital Identity) conference. A Locksmith wallet held a vLEI credential and a sample Utah SEDI health identification credential. On a sample healthcare portal, the user created an account and logged in with the credential instead of typing details. Before sharing any data, the user made an offer and required the site to return a signed receipt agreeing to the user's terms. The aim was to make credential login as easy as a passkey; because it rests on a KERI identifier, one key rotation reaches every site that uses that AID (autonomic identifier). He then explained how healthKERI arrived there. HL7 FHIR (Fast Healthcare Interoperability Resources) is a REST (representational state transfer) API (application programming interface) standard for healthcare, written into federal regulation, that exchanges discrete sections of records rather than whole documents. The CMS-0057-F final rule requires Medicare Advantage, Medicaid and CHIP (Children's Health Insurance Program) plans to implement FHIR-based APIs, with payer-to-payer exchange due by January 2027; healthKERI chose that narrow case for pilots, aiming at authorization scoped to a specific purpose of use. He described a lesson from an earlier product, RACK (Routing Authenticity and Confidentiality with KERI), an API gateway that s… |
| events/talks/kericonf26-d2-03-mayfield-5ws | Thomas A. Mayfield: KERI Infrastructure and the 5 Ws (KERIConf 2026) | summary | v0.1 — 2026-10-15: drafted by Claude from the curated transcript; unread by Mark; marked partner on Mark's word 2026-10-21, paraphrase only, no quotation | partner | 799 | # Thomas A. Mayfield: KERI Infrastructure and the 5 Ws (KERIConf 2026) **Abstract.** Thomas A. Mayfield of the Cardano Foundation gave an educational overview of KERI (Key Event Receipt Infrastructure) infrastructure organized around five roles beginning with W: wallet, witness, watcher, web and wizard. He then covered pre-rotation, multisignature control, ACDCs and delegation, and described how the foundation's Veridian project builds each role in open source. The talk is aimed at newcomers and online viewers as much as at the room. ## Summary Mayfield opened with the problem he sees in digital identity today: identity is borrowed. An issuer, registry or platform owns it, and if that party fails or revokes access, the person's identity goes with it. KERI, in his account, roots identity in keys the person controls, with no registry or platform dependency. He set out three core ideas: self-certifying identifiers derived from keys, critical actions signed and chained into a tamper-evident log, and verification by anyone replaying that log without phoning home to an authority. He called the identifier an AID (autonomic identifier) and its log a KEL (key event log), recording inception, rotation and interaction events, each signed and chained so that any alteration is detectable. He then walked through the five Ws, which he credited Samuel Smith with naming. The wallet is the holder's home: it generates and rotates keys, stores credentials, signs, and draws on device security; it is the only component the holder directly controls. Witnesses receive, sign and republish key events, acting like notaries that keep the log available and produce receipts, and the controller chooses them. Watchers are independent observers that detect duplicity, meaning conflicting versions of the same log, which he likened to the double-spend problem in blockchains. He thanked healthKERI for releasing its watcher and wallet code. The web is discovery and transport, through OOBIs (Out-Of-Band Introductions) that work like shareable lin… |
| events/talks/kericonf26-d2-04-davies-acdcs-for-enterprises | Alan Davies: ACDCs for Enterprises (KERIConf 2026) | summary | v0.1 — 2026-10-15: drafted by Claude from the curated transcript; unread by Mark; marked partner on Mark's word 2026-10-21, paraphrase only, no quotation | partner | 758 | # Alan Davies: ACDCs for Enterprises (KERIConf 2026) **Abstract.** Alan Davies of Digital Trust Foundry described how enterprises can begin using ACDCs (Authentic Chained Data Containers) and KERI (Key Event Receipt Infrastructure) without rebuilding their systems. He set a long-term vision of signed intent against a near-term approach he calls execution trust, applied first to high-value transactions, and described his company's platform. The talk is for business and product audiences weighing adoption. ## Summary Davies opened by saying the world needs simpler messages about what KERI and ACDCs can deliver, building on Thomas Mayfield's earlier overview. He traced trust from face-to-face reputation, where fraud was limited in scale, to remote transactions over the telephone, fax and the internet. The internet's answer was usernames, passwords and session tokens, and the result, in his view, has been widespread online fraud that detection alone keeps losing against. His long-term vision is a signed-intent world, perhaps four or five years out. A person asks an AI agent on their device to do something, such as moving money between accounts; the agent wraps the request in an ACDC and signs it after biometric authentication, adds further signatures such as a parent's where needed, and attaches relevant credentials such as a SEDI (state-endorsed digital identity) credential. The bank verifies the request, executes it and records it, without a login. He expects passwords and two-factor codes to linger but become less necessary. Getting there means every online service rearchitecting to accept signed requests from customers who act as their own identity providers, and he expects resistance from federated identity providers and data harvesters. Because that will not happen within a year, he argued for starting smaller. Today, autonomous agents act more and more, and logs record only what an account did, not who did it. He defined trustability as the ability to make a sound trust decision about information arrivin… |
| events/talks/kericonf26-d2-05-rayback-did-webs | Jonathan Rayback: KERI Bridge to the DID World (KERIConf 2026) | summary | v0.1 — 2026-10-15: drafted by Claude from the curated transcript; unread by Mark; marked partner on Mark's word 2026-10-21, paraphrase only, no quotation | partner | 759 | # Jonathan Rayback: KERI Bridge to the DID World (KERIConf 2026) **Abstract.** Jonathan Rayback, co-chair of the did:webs task force in the KERI Stack Working Group at Trust over IP and chair of the DID Methods Working Group at the Decentralized Identity Foundation (DIF), explained the did:webs method, which brings KERI (Key Event Receipt Infrastructure) into the family of web-based DID (decentralized identifier) methods. He covered DIDs in general, did:keri, did:web, what did:webs adds, its specification status, and a short demonstration. The talk assumed familiarity with KERI but not with DIDs. ## Summary Rayback introduced himself and his co-chair Kent Bull, then described DIDs as a W3C (World Wide Web Consortium) recommendation: a URI (uniform resource identifier) that resolves to a DID document listing keys, verification methods and services. Each DID method defines its own identifier format and how to create, resolve, update and deactivate DIDs; there are hundreds of methods, many tied to blockchains and a few to the web. He noted that did:keri exists but its specification is an early, largely unfilled draft from before OOBIs (out-of-band introductions), and says nothing about how to discover the KEL (Key Event Log), which limits its practical use. did:web, an unofficial W3C draft used in production, resolves by turning the identifier into a web address (URL, uniform resource locator) and fetching a did.json file. It has no key history and is exposed to web attacks such as DNS (Domain Name System) hijacking. An audience member who co-created did:web said it was meant as training wheels and that proposals to add key history were declined. did:webs separates discovery from verification: the web is used to find the DID document, and verification comes from a KERI event stream served alongside it as a keri.cesr file in CESR (Composable Event Streaming Representation). The identifier looks like a did:web with the controller's AID (autonomic identifier) as its last segment, and the stream must begin with th… |
| events/talks/kericonf26-d2-06-asawaka-mobile-wallet | Evan Asakawa: Mobile Wallet (KERIConf 2026) | summary | v0.1 — 2026-10-15: drafted by Claude from the curated transcript; unread by Mark; marked partner on Mark's word 2026-10-21, paraphrase only, no quotation | partner | 775 | # Evan Asakawa: Mobile Wallet (KERIConf 2026) **Abstract.** Evan Asakawa of the KERI Foundation development team described a web wallet for KERI (Key Event Receipt Infrastructure) that runs KERIpy entirely in the browser, with keys created and stored on the device, and the mobile wallet that reuses the same code. He demonstrated the web wallet and a plugin model in the Locksmith desktop wallet that lets several providers supply witnesses and watchers. Questions from the floor covered mailboxes, witness counts and KERIpy's coverage of the specifications. The talk suits developers building KERI clients. ## Summary Asakawa explained that the goal, set by Samuel Smith, was a fully web-native wallet to complement the Locksmith desktop application: running entirely in the browser with no KERIpy server behind it, keys created and stored locally, persistent across reloads, and deployable by anyone who serves the files. He then described the obstacles and how they were handled. Python normally runs on CPython, a C interpreter, so the team used Pyodide, the Python interpreter compiled to WebAssembly, and PyScript as the bridge to browser web workers and storage. KERIpy's dependencies had to work in WebAssembly: libsodium was compiled to WebAssembly and pysodium adapted to load it, under the name pychloride; BLAKE3, written in Rust, was also compiled; and pyoqs, a post-quantum cryptography library, was made compatible for future use. Inside KERIpy, LMDB (Lightning Memory-Mapped Database) depends on memory mapping, which WebAssembly lacks, so a second database class, webdber, mirrors the LMDB interface over the browser's IndexedDB, and imports were changed so LMDB is not loaded. Samuel Smith added an asynchronous interface to HIO, the KERI community's input-output library, to make persistence possible. In answer to questions, he said the changes are on a KERIpy branch and that a matching web keeper encrypts keys before storage. The architecture is a thin JavaScript interface launching PyScript workers that call KERIpy a… |
| events/talks/kericonf26-d2-07-windley-legal-foundation | Phil Windley: Digital Identity Needs a Legal Foundation (KERIConf 2026) | summary | v0.1 — 2026-10-15: drafted by Claude from the curated transcript; unread by Mark; marked partner on Mark's word 2026-10-21, paraphrase only, no quotation | partner | 811 | # Phil Windley: Digital Identity Needs a Legal Foundation (KERIConf 2026) **Abstract.** Phil Windley argued that the hardest remaining problems in digital identity are legal and institutional rather than technical, and that Utah's SEDI (State-Endorsed Digital Identity) statute supplies a legal foundation on which trust frameworks can rest. He covered the proof gap, the scaling and economic problems of trust, the rights in the statute, and two ways of building reputation. The talk is for builders and policy people working on decentralized identity adoption. ## Summary Windley began by noting that the technical foundations, decentralized key management, chained credentials, serialization formats and open-source implementations, are largely in place, though not finished. Adoption depends on removing blockers that are legal and institutional. He cited Sankarshan Mukhopadhyay's paper on the proof gap: people still rely on centralized institutions to prove facts about themselves, cannot easily present that proof digitally, and must go back to each institution when proof is lost. He framed two problems. The first is scaling trust. Using credit cards as his example, he described a trust framework as the combination of technology, rules, processes and legal agreements that lets many parties work together. With thousands of credential types, each in its own private framework, verifiers would face an unmanageable sea of islands, and coalitions that hope to grow large enough to cover everyone will never absorb their rivals. Something underneath that connects them is needed. The second problem is economic. In the 1990s, proofed certificates for people were costly because issuers took on liability, users would not pay, and the web settled on passwords. SEDI, he argued, helps with both. It is not a universal trust framework but a firm legal base beneath trust frameworks, and the state already proofs identity, for example for REAL ID driver's licenses. Under SEDI the person creates their own identifier, the state proofs at… |
| events/talks/kericonf26-d2-08-bull-keripy-async-architecture | Kent Bull: KERIpy Async Architecture (KERIConf 2026) | summary | v0.1 — 2026-10-15: drafted by Claude from the curated transcript; unread by Mark; marked partner on Mark's word 2026-10-21, paraphrase only, no quotation | partner | 796 | # Kent Bull: KERIpy Async Architecture (KERIConf 2026) **Abstract.** Kent Bull gave a developer-focused walk through the execution model of KERIpy, the Python reference implementation of KERI (Key Event Receipt Infrastructure), which runs on the HIO structured concurrency library. He explained what structured concurrency is, why it suits the code base, and how HIO's scheduler and tasks work, using KERIpy commands as examples. It is for developers who want to read, extend or contribute to KERIpy. ## Summary Bull set out to give developers a mental model of how KERIpy runs, enough to read the source, contribute, or guide an AI coding assistant. After polling the room, he defined the basic unit of structured concurrency as a cooperative, non-blocking coroutine, which HIO calls a Doer. Nothing should block: network and file input and output are handled in small chunks, and a coroutine that has to wait reschedules itself for the next cycle. He traced the idea to Edsger Dijkstra's 1968 letter on the goto statement and to Nathaniel J. Smith's essays on structured concurrency, which argue that promises, callbacks, go statements and async/await are forms of goto that break abstractions. He noted that Samuel Smith's HIO and Charles Lowell's JavaScript library Effection both cite those essays, and recommended the companion essays on timeouts, cancellation and interrupts. HIO has three main concepts: the Doist, the root scheduler; the DoDoer, which aggregates child tasks and is also a task; and the Doer, the basic task. The central guarantee is that program flow follows lexical scope: tasks started in a scope finish or are canceled before the scope returns, children cannot outlive parents, and failures, cancellations and exceptions propagate up the task tree to be handled at any level. He compared HIO with Trio, Curio and Java's approach, called HIO the most intuitive Python library of its kind though not the most polished, and argued that adding async/await to Python was a missed chance to adopt structured concurrency… |
| events/talks/kericonf26-d2-09-ned-smith-secure-asset-transfer-protocol | Ned Smith: Secure Asset Transfer Protocol (KERIConf 2026) | summary | v0.1 — 2026-10-15: drafted by Claude from the curated transcript; unread by Mark; marked partner on Mark's word 2026-10-21, paraphrase only, no quotation | partner | 830 | # Ned Smith: Secure Asset Transfer Protocol (KERIConf 2026) **Abstract.** Ned Smith, a security engineer and participant in the IETF (Internet Engineering Task Force), gave an overview of SATP (Secure Asset Transfer Protocol), developed by the IETF Secure Asset Transfer working group, and of where KERI (Key Event Receipt Infrastructure), ACDC (Authentic Chained Data Containers) and the vLEI (verifiable Legal Entity Identifier) could fit into it. He covered the protocol's entities and stages, its current standards status, the rechartering to define stage 0, and hardware attestation. The talk is for KERI practitioners interested in contributing to the standard while its open parts are still being defined. ## Summary Smith introduced himself as a long-time security engineer, formerly at Intel, and placed the Secure Asset Transfer working group in the IETF's Applications and Real-Time area. He walked through the working group's canonical use case, built around an asset reference token: an issuer declares an asset to an artifacts registry, mints a token with an on-chain value part and off-chain context data, and a gateway reads the token, validates the context data, and transfers the asset to another network. The protocol's entities are the originator and beneficiary, the gateways that form the protocol's endpoints, asset networks or oracles, the orchestrating user application, a host owner he named to capture legal responsibility, and the artifacts registry, which keeps transfer context and the audit trail. The architecture aims at an atomic two-phase commit with no shared trusted third party and requires versioning, rollback and provenance for tokenized and non-tokenized assets. He observed that the drafts implicitly assume X.509 certificates, although no normative text requires them, which makes integrating KERI an uphill effort. He sketched how vLEI roles could map onto the architecture: GLEIF (the Global Legal Entity Identifier Foundation), QVIs (Qualified vLEI Issuers) and LOUs (Local Operating Units), wit… |
| events/talks/kericonf26-d2-10-racz-investigating-the-game-of-trust | Nicholas Racz: Investigating the Game of Trust (KERIConf 2026) | summary | v0.1 — 2026-10-15: drafted by Claude from the curated transcript; unread by Mark; marked partner on Mark's word 2026-10-21, paraphrase only, no quotation | partner | 802 | # Nicholas Racz: Investigating the Game of Trust (KERIConf 2026) **Abstract.** Nicholas Racz of Key State Capital gave a field report on six years of investing in companies built on KERI (Key Event Receipt Infrastructure): the firm's investment criteria, its three chosen roots of trust, the stories of Provenant and healthKERI, and the lessons the firm drew. The session was conversational, with frequent contributions from the floor, including Jared Jeffery of healthKERI. It is for readers interested in how the KERI ecosystem has been funded and where investors see gaps. ## Summary Racz opened with the idea that capital brings a believed-in future into the present, and said Key State found Samuel Smith's work after the setbacks of the earlier self-sovereign identity wave. He placed KERI in a sequence of internet protocol layers after TCP/IP, HTTP and TLS (Transport Layer Security), describing it as a public-service protocol for portable, rotatable, self-certifying identifiers. At the start there was a white paper but no infrastructure. Timothy Ruff introduced the firm to Provenant, conceived by Randy Warshaw to bring verifiable communications to SMS (short message service), RCS (rich communication services), calling and voice over IP. He set out three investment tests: an industry vertical a company can own, technical features only KERI makes possible, and the right people. Lacking any one of them, he argued, leads to theory without application, partnerships without shipped integrations, or a good idea that fails. The firm's strategy centers on three roots of trust: the GSMA (the mobile industry association) in telecommunications, DirectTrust and the Vital Initiative in healthcare through healthKERI, and SEDI (State-Endorsed Digital Identity) in Utah, which with the vLEI (verifiable Legal Entity Identifier) covers both organizational and personal identity. He wants portfolio companies that share learnings without competing. On Provenant, he said the firm had expected a quick exit, following the precedent of C… |
| events/talks/kericonf26-d2-11-hardman-general-evidence-problems | Daniel Hardman: Applying KERI to General Evidence Problems (KERIConf 2026) | summary | v0.1 — 2026-10-15: drafted by Claude from the curated transcript; unread by Mark; marked partner on Mark's word 2026-10-21, paraphrase only, no quotation | partner | 769 | # Daniel Hardman: Applying KERI to General Evidence Problems (KERIConf 2026) **Abstract.** Daniel Hardman presented the dossier, a form of ACDC (Authentic Chained Data Container) for assembling rich, durable collections of evidence, drawing on his work in telecommunications but arguing the idea applies far more widely. He covered why simple credential presentations fall short, how a dossier is structured and referenced, how it differs from a verifiable presentation, and features in the draft dossier specification such as joint issuance. The talk is for specification writers and implementers interested in ACDC beyond single-credential use. ## Summary Hardman opened by saying that dossiers are a topic on which the KERI (Key Event Receipt Infrastructure) community could lead. He recalled Samuel Smith describing ACDCs around 2019 as a verifiable data graph, a phrase he has come to see as profound. He described the problem as he met it in telecommunications. Verifiable credentials assume a holder in direct, two-way interaction with a verifier. His use cases needed one-way verification by several parties along a path, with no return channel, and verification out of band later by an auditor or regulator. He also needed a richer evidence model. Most credential demonstrations involve one credential, yet real processes such as applications, research, investigations and documentation call for large collections of evidence that accrete over time. He stressed two overlooked points. Evidence has lifespans, and a collection is only as durable as its shortest-lived piece. Pieces of evidence also serve different purposes under different rules. A mortgage file, his example, combines consecutive recent pay stubs, recent proof of employment and a credit report, each with its own issuer and governance, all evaluated at funding and kept afterward so one can later ask whether the borrower qualified at the time. He called such a curated collection a dossier. Because it is a verifiable data graph, it has a SAID (self-addressing id… |
| events/talks/kericonf26-d2-12-pahio-keri-development-deployment | Keanu Pahio: KERI Development and Deployment (KERIConf 2026) | summary | v0.1 — 2026-10-15: drafted by Claude from the curated transcript; unread by Mark; marked partner on Mark's word 2026-10-21, paraphrase only, no quotation | partner | 735 | # Keanu Pahio: KERI Development and Deployment (KERIConf 2026) **Abstract.** Keanu Pahio of the KERI Foundation showed how to deploy the Foundation's KERI (Key Event Receipt Infrastructure) stack locally: the Locksmith wallet, a boot server, witnesses and watchers. He explained the role of each part, demonstrated running them, and pointed to where developers can extend the stack through wallet plugins and the witness and watcher APIs. It is a hands-on talk for developers starting to build on the Foundation's open-source infrastructure. ## Summary Pahio set out the objectives: understand the deployment architecture and the role of each part, deploy witnesses, watchers and a wallet locally, and know where to start developing, for example by writing a Locksmith plugin or extending the witness and watcher APIs. The only requirements are Python, with version 3.13 recommended because 3.14 caused problems in some repositories, and Libsodium, the cryptographic library KERI uses. Locksmith, the wallet, generates AIDs (autonomic identifiers), signs with them, keeps key pairs secure, stores and verifies KELs (Key Event Logs) and handles OOBIs (out-of-band introductions). He used the KERI Foundation branch of the public Locksmith repository, which carries the Foundation's plugin, and pointed to the developer guide for setting up the environment and regenerating the Qt resources. In the demo he created a vault, which an audience member confirmed corresponds to a Habery in KERIpy, the container for AIDs and their keys. The Foundation plugin exists because of the boot server. Witness and watcher services each run two servers: a private boot API that creates and deletes witnesses or watchers, and a public server that anyone can reach once they exist. Because the private API is not reachable from outside, the Foundation's boot server, kf-boot, calls it on the wallet's behalf, and the plugin bridges Locksmith to the boot server. The plugin currently handles onboarding, witness registration, watcher resolution and authenticat… |
| events/talks/kericonf26-d2-13-smith-spac-tsp | Samuel M. Smith: SPAC and TSP (KERIConf 2026) | summary | v0.1 — 2026-10-15: drafted by Claude from the curated transcript; unread by Mark; marked partner on Mark's word 2026-10-21, paraphrase only, no quotation | partner | 757 | # Samuel M. Smith: SPAC and TSP (KERIConf 2026) **Abstract.** In his Day 2 breakout, Samuel M. Smith explained the design of SPAC (Secure Privacy, Authenticity and Confidentiality), the protocol from his white paper, and its relation to TSP (Trust Spanning Protocol), the Trust over IP generalization of it. He set out how the protocol separates privacy from confidentiality, why accountability within a context is a goal, and how a triple tunnel through two intermediaries protects metadata. The talk is for readers of the protocol specifications; the transcript begins after the opening minutes. ## Summary The transcript picks up as Smith restates the argument from his plenary: anyone a person interacts with repeatedly can eventually correlate them, so privacy depends on holding second parties accountable through economic, contractual, legal, regulatory or criminal means. The aim is relationships protected from third-party surveillance in which second parties answer for what is shared with them and for their own conduct, which he described as what a refuge or sanctuary provides. His model takes the first party's view. Third parties observe metadata, and because internet routing metadata is public and, in US law, unprotected, content can be encrypted but metadata cannot. Tunnels turn one layer's metadata into another layer's content. He defined privacy as third parties not knowing who is sharing, and confidentiality as third parties not knowing what was shared. SPAC seeks the best privacy possible without compromising authenticity or confidentiality, because weakening those two leads to fraud and identity theft, harms he considers larger for most people. He described relationships as pairs of AIDs (autonomic identifiers). AIDs are cryptonyms with high entropy and carry no correlating information on their own; correlation comes from the context in which identifiers are used. Partitions are sets of contexts whose relationships are mutually disjoint. Within a context, perfect correlation of an AID is desirable becau… |
| events/talks/kericonf26-d2-14-oconnor-path-to-production | Fergal O'Connor: KERIA and Signify, the Path to Production (KERIConf 2026) | summary | v0.1 — 2026-10-15: drafted by Claude from the curated transcript; unread by Mark; marked partner on Mark's word 2026-10-21, paraphrase only, no quotation | partner | 785 | # Fergal O'Connor: KERIA and Signify, the Path to Production (KERIConf 2026) **Abstract.** Fergal O'Connor, identity solutions lead architect at the Cardano Foundation and architect of its Veridian wallet, set out the maturity gaps he sees in KERIA (the KERI cloud agent service) and Signify (its edge client libraries), grouped as developer experience, operational resilience and scalability. The session included a running technical discussion with members of the audience. It is for developers and operators building on KERI (Key Event Receipt Infrastructure) agents in production. ## Summary O'Connor introduced the Veridian wallet, launched to public app stores over a year earlier as, in his account, the first KERI and ACDC (Authentic Chained Data Containers) mobile wallet in production, built on KERIA and Signify. Building it led his team to contribute many changes back. He said the implementation maturity of KERIA and Signify lags behind KERIpy, and that the gaps are ordinary software engineering matters, not protocol or security flaws: the stack works in production but gives too little feedback. He recapped the model from his talk the day before: agent in the cloud, controller at the edge. KERIA, a Python service built on KERIpy, runs isolated agents in the cloud that perform verification of KERI, ACDC and CESR (Composable Event Streaming Representation) and talk to witnesses, watchers, issuers and verifiers. Each agent has one Signify client at the edge that signs events and credentials. Asked about several clients per agent, he said clients sharing a passcode derive the same keys and would work, though differences in local state could cause inconsistencies. Signify, he agreed with a questioner, means any edge client library of KERIA. On developer experience, his team has been strongly typing the edge libraries by generating types for Signify-ts and Signify Java from KERIA's OpenAPI documentation, which is itself generated from KERIpy's data structures, so the definitions stay in sync. He argued that Signi… |
| events/talks/kericonf26-d2-15-panel-what-keri-allows | Ryan Hansen (moderator): What KERI Allows Us to Do That We Couldn't Before (panel) (KERIConf 2026) | summary | v0.1 — 2026-10-15: drafted by Claude from the curated transcript; unread by Mark; marked partner on Mark's word 2026-10-21, paraphrase only, no quotation | partner | 838 | # Ryan Hansen (moderator): What KERI Allows Us to Do That We Couldn't Before (panel) (KERIConf 2026) **Abstract.** The closing panel of KERIConf 2026, moderated by Ryan Hansen of the KERI Foundation, asked what KERI (Key Event Receipt Infrastructure) makes possible that was not possible before. The transcript names the panelists by first name: Alan (also spelled Allan), Thomas, Nico and Daniel. They discussed how each came to KERI, failed earlier approaches, partial implementations, takeaways from the conference and what still needs to be built. The session is for anyone wanting a broad view of where the community sees KERI heading. ## Summary **How the panelists arrived.** Hansen asked each panelist for their path to KERI. Alan said he believes everyone should be their own identity provider and sees no way to do that without KERI or something like it. Thomas, coming from blockchain, said his realization was that KERI offers what people value in blockchains without the drawbacks. Nico traced his path through the failure of Sovrin and the idea of microledgers, recalled recognizing Samuel Smith's white paper as the way to create identity at scale in a decentralized way, and said Key State Capital was founded for that reason. Daniel said that large telecommunications investments in complying with the STIR/SHAKEN caller authentication rules have barely improved the problem, and that he sees KERI as the way to solve it. **What has failed.** Nico described his earlier work on blockchain consensus systems; Thomas countered that KERI needs not consensus but convergence on the truth, since one honest watcher is enough to expose a liar. Thomas said attempts to treat identity like a token, locked into one chain, leave identity siloed and dependent on that network. Daniel criticized the European Union business wallet initiative for treating an organization as an opaque unit, and argued, in line with the vLEI (verifiable Legal Entity Identifier) model, that authority inside an organization must be traceable through deleg… |
| events/talks/kerione-ssi-meetup-webinar-on-keri | Key Event Receipt Infrastructure (KERI): A secure identifier overlay for the internet – Sam Smith – Webinar 58 | summary | v0.1 — 2026-10-14: drafted by Claude from the SSIMeetup page (not the video); unread by Mark; marked partner on Mark's word 2026-10-21, paraphrase only | partner | 468 | # Key Event Receipt Infrastructure (KERI): A secure identifier overlay for the internet – Sam Smith – Webinar 58 **Abstract.** SSIMeetup webinar 58, in which Samuel M. Smith presents KERI as a ledgerless decentralized key management infrastructure and a secure identifier overlay for the internet. The page carries an embedded YouTube video and links to the slides, under a Creative Commons BY-SA 4.0 license, and suits newcomers who want the 2020 introduction from the author. ## Summary This item is a recorded webinar, number 58 in the SSIMeetup series, posted on 19 May 2020. The summary below rests only on the event page; the video itself was not watched, so it describes what the page says the talk covers rather than the talk. The page introduces the presenter, Samuel M. Smith, as an entrepreneur and strategic consultant at the intersection of artificial intelligence, blockchain and decentralized computing, formerly a full professor at Florida Atlantic University. It describes KERI (Key Event Receipt Infrastructure) as a ledger-less approach to identity that provides a decentralized key management infrastructure. According to the page, KERI rests on two roots of trust: self-certifying identifiers, which are bound at issuance to cryptographic key pairs, and end-verifiable key event receipt logs (KERLs), which record changes of control. The page presents KERI as a candidate to replace the Domain Name System and certificate authority system (DNS-CA) as a trust spanning layer for the internet, describes its identifiers as portable and self-sovereign, and says it is the basis for a proposed universal DID (decentralized identifier) method named "DID:uni". At the time, the page notes, KERI was an open-source project within the Decentralized Identity Foundation (DIF). The page links slides on SlideShare and Google Slides and embeds the YouTube recording, and it releases the content under a Creative Commons Attribution-ShareAlike 4.0 license crediting SSIMeetup and the guest. The talk's title matches the title of the… |
| learning/by-date | KERISuite resources by date: the timeline | index | generated 2026-11-04 by scripts/build_resource_index.py from data/resources.yaml | partner | 47031 | |
| learning/by-level | KERISuite resources by level | index | generated 2026-11-04 by scripts/build_resource_index.py from data/resources.yaml | partner | 37140 | |
| learning/by-source | KERISuite resources by source page | index | generated 2026-11-04 by scripts/build_resource_index.py from data/resources.yaml | partner | 55029 | |
| learning/kerisuite-learning-resources | KERISuite learning resources: the documentation, tutorial, and paper sites, verified | reference | v0.1 — 2026-09-16; every entry checked against the live site or repository that day unless marked search-only; prepared for the core-group release 2026-10-15 (markers, ADE references and join links removed) | partner | 2845 | # KERISuite learning resources > Where to learn KERI, ACDC, CESR, and the rest of the KERI Suite: the documentation hubs, tutorial series, papers, specifications, training material, community channels, and code, with who maintains each and how current it is. Compiled 2026-09-16 (the same question was also put to Gemini; its answer and its errors are in §9). Every URL was fetched or its repository metadata read that day unless the entry says *search-only*. Companions in this folder: [[KERI_Reference_skinny]] (the two-page summary), [[KERI_Synthesis]] (the full synthesis), [[KERI_Cryptography]]. ## 1. Start here: a reading path 1. **Orientation, one hour.** Nuttawut Kongsuwan's *Hitchhiker's Guide to KERI*, parts 1 to 3 (§7), then the KERI white paper's slide deck (§4); *KERI for Muggles*, which keri.one links as a Google deck needing a sign-in, is readable as a PDF in Smith's Papers repository (IIW 31, 20 October 2020). 2. **Vocabulary.** The KERI Suite glossary (§2) open in a tab; the Kerific browser extension (§3) turns any page's terms into glossary lookups. 3. **Hands on the command line.** GLEIF's vLEI training notebooks 101 (§5), or Kent Bull's *Sign and Verify with Heartnet* and *Treasure Hunting in Abydos* (§4). 4. **Hands on the edge-and-cloud architecture.** Notebooks 102 (KERIA and Signify), the Veridian getting-started pages (§7), and Kent Bull's KERIConf 2026 KERIA tutorial, of which this vault holds notes and a transcript. 5. **The specifications**, once the vocabulary is familiar (§2), with the search engine (§3) for anything the specifications assume. 6. **The papers**, for why the design is what it is (§4). 7. **The first public presentations**, for how the suite was introduced and argued over: the IIW sessions since October 2019, indexed in [[300-Research/310-KERISuite/events/iiw-sessions|iiw-sessions.md]] with a link to each session's page in the proceedings. The nine places most readers start (keri.one, KERISSE, KERIConf, IIW, Tutorials, Code, ToIP, vLEI and Products) each have a page in t… |
| learning/reading-path-developer | Reading path for a developer: the KLI, then KERIA and Signify | reference | v0.1 — 2026-09-17; every stop is a register entry (data/resources.yaml) or a note in this system | public | 416 | # Reading path for a developer > For someone who will build on the suite. The order is the community's own: learn with the command-line interface, then move to the edge-and-cloud pair that production uses. Register ids in brackets point at [[300-Research/310-KERISuite/data/resources.yaml|resources.yaml]]. ## Before code (an hour) 1. Parts 1 to 3 of the Hitchhiker's Guide [hitchhikers-guide]; part 3 is the one that maps tools to purposes. 2. The two-page reference [[../research/KERI_Reference_skinny]] and the glossary [kerisuite-glossary] in a tab. 3. The version matrix [[../specifications/version-matrix]], so that your code targets the approved text and you know what "v2" means in the community's speech. ## The command line (a day or two) 4. **GLEIF's vLEI training, notebooks 101** [vlei-trainings]: run locally in Docker; the KLI, controllers and identifiers, keystores, signatures, rotation, modes and OOBIs, witnesses, connecting controllers, delegation, multisig, then ACDC: schemas, saidifying, issuance, presentation and revocation, edges and rules, chained credentials. This is the most complete course there is and it is free. 5. **Kent Bull's Heartnet and Abydos tutorials** [kentbull-heartnet], [kentbull-abydos] with the companion repository [abydos-tutorial-repo] and video [abydos-video]: the same ground with a story, witnesses configured by hand, and a webhook. 6. **Understanding SAIDs** [kentbull-said], because every artifact you will make is self-addressed. ## The edge and the cloud (a week) 7. **Notebooks 102** [vlei-trainings]: KERIA and Signify, basic operations, connecting clients, rotation, issuance, presentation and revocation, third-party tools. 8. **Veridian's getting-started pages** [veridian-docs]: booting a Signify client, key management, connecting; then its developer guide on identifiers, ACDCs, delegation, OOBIs, async operations, notifications. 9. **Finema's Signify and KERIA tutorial** [finema-signify-tutorial] for a second, independent walkthrough. 10. **Kent Bull's KERIA tutorial f… |
| learning/reading-path-reader | Reading path for a reader: an hour, a day, a week | reference | v0.1 — 2026-09-17; every stop is a register entry (data/resources.yaml) or a note in this system | public | 428 | # Reading path for a reader > For someone who wants to understand the KERI Suite without building on it: what to read, in what order, and what each stop gives you. Register ids in brackets point at [[300-Research/310-KERISuite/data/resources.yaml|resources.yaml]], where the URL and the last-checked date live. ## An hour 1. **The Hitchhiker's Guide to KERI, part 1: why adopt it** [hitchhikers-guide]. The case, in plain language, from a practitioner outside the core team. 2. **The KERI white paper's slide deck**, *Key Event Receipt Infrastructure: A Secure Identifier Overlay for the Internet* [kerione-keri-white-paper-slide-deck]. Samuel Smith's overview of the white paper; the vocabulary in pictures. *KERI for Muggles*, the gentler deck keri.one lists, needs a Google sign-in there [kerione-keri-for-muggles]; a readable PDF of it, from the IIW 31 session of 20 October 2020, is in Smith's Papers repository [papers-keri-for-muggles]. The PDF names no author; a secondary source credits it to Smith and Drummond Reed. 3. **The two-page reference** [[../research/KERI_Reference_skinny]]. Mark's summary of the primitives; keep it open. 4. **The glossary** [kerisuite-glossary]. Not to read, but to have in a tab; the Kerific extension [kerific] turns every term on any page into a lookup. ## A day 5. Parts 2 and 3 of the Hitchhiker's Guide [hitchhikers-guide]: what KERI is, and how it is used, including why the command-line tool is for learning and the edge-and-cloud pair is for production. 6. **KERI jargon in a nutshell** [keri-jargon]: AIDs, KELs, OOBIs, witnesses, watchers. 7. **The KERI white paper** [kerione-keri-white-paper], sections on identifiers, key events, pre-rotation, witnesses and watchers; then the ACDC white paper [kerione-acdc-white-paper]. 8. **The version matrix** [[../specifications/version-matrix]]: which specification is approved and how to cite it, so that nothing you repeat is a draft dressed as a standard. ## A week 9. **The KERI specification's introduction and conceptual sections** [keri-sp… |
| learning/resources-index | KERISuite resources, indexed: generated | index | generated 2026-11-04 by scripts/build_resource_index.py from data/resources.yaml | partner | 20698 | |
| policy/README | Utah statutes: local copies | reference | 2026-09-13; prepared for the core-group release 2026-10-15 (markers, ADE references and join links removed) | partner | 260 | # Utah statutes: local copies Primary sources for the SEDI work, kept here because **they were hard to retrieve and will be needed again.** Utah's code pages at `le.utah.gov/xcode/` render client-side, so a fetch returns the navigation shell rather than the statute, and the Justia mirror returns 403. The enrolled bill PDFs are static and do extract. | File | What it is | Retrieved | |---|---|---| | [[300-Research/310-KERISuite/policy/SB0275-enrolled-2026.txt\|SB0275-enrolled-2026.txt]] | **S.B. 275, 2026 General Session**: *State-Endorsed Digital Identity Program Amendments*. Enrolled copy, `pdftotext -layout` of `le.utah.gov/~2026/bills/sbillenr/SB0275.pdf` | 2026-09-13 | ## The sections most cited | Section | What it says | |---|---| | **63A-20-801** | *Complaints and enforcement.* Individual → data privacy ombudsperson → attorney general. **Both intermediate steps are discretionary** (*may* review, *may* refer). The attorney general may issue civil investigative demands and bring a civil action for injunctive and declaratory relief, damages, restitution and disgorgement *"on behalf of an individual injured."* Courts may award actual damages, costs and attorney fees. **No private right of action** | | **63A-20-802** | *Auditing.* Legislative Auditor General audit of the program **beginning 1 January 2028** | | **63A-19-501** | The data privacy ombudsperson's own section; (6) carries the authority to refer SEDI complaints to the attorney general | | **63A-20-401** | State-endorsed digital identity requirements, including the holder-controlled secure log at (1)(f) and digital-guardian presentation at (1)(h) | | **63A-20-701** | Duty of loyalty | Cite the statute, not this file. This is a convenience copy of a public document, kept so the next question does not require re-solving the retrieval problem. |
| policy/resources | policy/ resources: generated | index | generated 2026-11-04 by scripts/build_resource_index.py from data/resources.yaml | partner | 551 | |
| research/KERI_Reference_skinny | KERI Reference (skinny) | 2026-10-15: prepared for the core-group release (the private-project section, the stub lines and one unsourced claim removed); content last updated 2026-03-31 | partner | 2270 | # KERI Reference (skinny) Last updated: 2026-03-31 A two-page summary of the KERI Suite's essential concepts, by the curator, drawn from the v1.0 specifications. Where it and a specification disagree, the specification wins. --- ## What KERI Is KERI (Key Event Receipt Infrastructure) is an identity system that provides end-to-end verifiable control of cryptographic identifiers without requiring a blockchain or certificate authority. Approved as v1.0 by ToIP Steering Committee in January 2026. Created by Samuel M. Smith. **Core thesis:** Identity has no double-spend problem, so it does not need distributed consensus. Without consensus, KERI escapes the blockchain trilemma (decentralization/security/scalability) by not entering it. --- ## Foundational Concepts ### Self-Certifying Identifiers and AIDs A self-certifying identifier (SCI) encodes a cryptographic public key so that possession of the private key proves control. No certificate authority needed. KERI extends this with Autonomic Identifiers (AIDs): identifiers that persist through key rotation via an append-only Key Event Log (KEL). **AID properties:** (1) self-contained cryptographic root of trust, (2) decentralized control via private key management, (3) universal uniqueness. "Autonomic" = self-rule: the identifier is self-managing for rotation, delegation, and recovery. ### Key Event Log (KEL) An append-only, cryptographically chained history of all key management events (inception, rotation, delegation). Bidirectionally linked: each event hashes the previous (backward chaining), and each establishment event commits to the next rotation keys (forward chaining). To verify who controls an AID, replay the KEL from inception forward. The log is the authority. **End-verifiable:** Anyone, anywhere, at any time can verify key state given access to the KEL. No registry or CA query needed. **Incremental verification:** Verifiers cache last verified state; only process new events since last check (O(delta-n), not O(n)). ### Pre-Rotation KERI's co… | |
| research/README | research/ | partner | 209 | # research/ The curator's syntheses across the suite, and two dated reference pages Claude drafted for the core-group release. These govern on the suite as a whole inside the vault; the specifications govern on the protocol. - **[[300-Research/310-KERISuite/research/KERI_Reference_skinny|KERI_Reference_skinny.md]]**: the two-page summary; the default load when KERI knowledge is needed. - **[[300-Research/310-KERISuite/research/KERI_Synthesis|KERI_Synthesis.md]]**: the full synthesis (~28k words) across KERI, ACDC, CESR, and TSP, verified against the v1.0 specifications; for reasoning across primitives, trade-offs against PKI, OIDC, and DID, and technical writing. Subsumes the skinny version. - **[[300-Research/310-KERISuite/research/KERI_Cryptography|KERI_Cryptography.md]]**: algorithm-level detail and Samuel M. Smith's design philosophy: the algorithm set, the signature, digest, and seal trichotomy, the pre-rotation proof, ESSR, trust versus privacy. Companion to [[300-Research/330-Cryptography/Security_Architecture_Reasoning|Security_Architecture_Reasoning.md]]. - **[[300-Research/310-KERISuite/research/cipher-suites|cipher-suites.md]]**: the CESR code tables against keripy's, primitive by primitive, with the differences and the post-quantum state (October 2026; drafted by Claude, not yet reviewed by the curator). - **[[300-Research/310-KERISuite/research/state-of-the-suite-2026-10|state-of-the-suite-2026-10.md]]**: what is approved, in flight, implemented where, and open, dated and sourced (drafted by Claude, not yet reviewed by the curator; refreshed after each implementers' call). - **[[300-Research/310-KERISuite/research/hardman-grand-unified-theory-2023|hardman-grand-unified-theory-2023.md]]**: notes on Daniel Hardman's 2023 unified-theory paper. - **[[300-Research/310-KERISuite/research/IPEX-draft-ssmith-2023|IPEX-draft-ssmith-2023.md]]**: notes on the 2023 IPEX draft. Rule of thumb for a session: read the skinny version first; escalate to the synthesis only when the skinny version is insufficient. | ||
| research/cipher-suites | KERI Suite cipher suites: what the code tables carry | reference | v0.1 — 2026-10-15: drafted by Claude from the CESR specification and keripy's code tables; unread by Mark; marked partner on Mark's word 2026-10-21, paraphrase only | partner | 3125 | # KERI Suite cipher suites: what the code tables carry This note lists the cryptographic primitives that the Composable Event Streaming Representation (CESR) code tables carry for the Key Event Receipt Infrastructure (KERI) and Authentic Chained Data Container (ACDC) protocol stack, genus/version `-_AAACAA` (version 2.00), and checks each code against keripy, the Python reference implementation. It is part 3, "Cryptography and cipher suites", of the KERI Suite knowledge system (KSKB). Every code below was copied from the files read on 2026-10-15, not from memory. Sources: the CESR specification in `trustoverip/kswg-cesr-specification` at the `v1.0` tag (commit `037129608b9e6960858b752019ac273d40d7386c`, 2026-03-05), at `main` (commit `bad6edd84f928fe1e77a722edbdd829e0878377f`, 2026-08-28), and at the `v1.1` branch (commit `65fd7518b6fa318ef3fc700a824b18112b8392e2`, 2026-08-26), file `spec/spec-body.md`, Annex A "Master code table" and "Indexed code table"; keripy in `WebOfTrust/keripy` at `main` (commit `c102367ea0b8416ffb3c01403d18b3fd4a6a38bf`, 2026-10-14), files `src/keri/core/coring.py`, `src/keri/core/indexing.py`, `src/keri/core/signing.py` and `src/keri/app/keeping.py`; and the KERI specification in `trustoverip/kswg-keri-specification` at `main` (commit `fbdd4a6155e48248873cccd5cf6f79b6b631a021`), file `spec/spec-body.md`, compared against its `v1.0.1` tag (commit `71cb54ebb445dd9d8cb33cd29a5f50894fafc569`), which differs only in two typo fixes. On CESR `main`, `spec/spec-body.md` is byte-identical to the `v1.0` tag (same Git blob, `66d6e0b2`), so in this note "v1.0" covers both the release and the editor's draft on `main`. The `v1.1` branch is the working draft for the next version and is the only place the post-quantum codes appear. Line numbers below refer to the files at those commits. **Post-quantum pull requests, state as of 2026-10-15 (GitHub API).** CESR PR #165, "Add post-quantum signature primitives (FN-DSA, ML-DSA, SLH-DSA)", opened 2026-03-18 by dhh1128, was merged on 2026-08-25 into the `v… |
| research/papers/README | research/papers/ | partner | 70 | # research/papers/ Summary notes for papers, white papers and slide decks: one note per item, named for it, each linked from its card in [[300-Research/310-KERISuite/data/resources.yaml|resources.yaml]] by the card's `summary` field. The template and the fields are in [[300-Research/310-KERISuite/docs/developer/note-template|note-template.md]]. A note starts `internal` and unread; it becomes `partner`, and is linked from [[300-Research/310-KERISuite/INDEX|INDEX]], once the curator has read it. The curator's syntheses across the suite stay one level up, in [[300-Research/310-KERISuite/research/README|research/]]. | ||
| research/papers/acdc-for-wizards | Authentic Chained Data Containers (ACDC): Verifiable Credentials with Stuff | summary | v0.1 — 2026-10-14: drafted by Claude from the slides (PDF, 95 slides); unread by Mark; marked partner on Mark's word 2026-10-21, paraphrase only | partner | 492 | # Authentic Chained Data Containers (ACDC): Verifiable Credentials with Stuff **Abstract.** A 95-slide deck by Samuel M. Smith, linked on keri.one as 'ACDC for Wizards', presenting ACDC (Authentic Chained Data Containers) features and field labels and the reasoning behind them: graduated disclosure, contractually protected disclosure, the PAC (privacy, authenticity, confidentiality) theorem, issuance models and KERI-based registries, and a long background section on OOBIs, BADA policy and discovery. For implementers who want the design rationale in detail. ## Summary The deck opens with resources (the ACDC specification repository, the 'ACDC for Muggles' deck, keri.one and the KERI white paper) and a list of basic ACDC (Authentic Chained Data Container) features: ACDCs are built on KERI (Key Event Receipt Infrastructure), use SAIDs (self-addressing identifiers), make schemas SAIDified and immutable, chain as a property graph, and support graduated disclosure (compact, partial, private, selective), contractually protected disclosure and protection against exploitation, including statistical correlation. Slides 4 to 12 walk through an ACDC's structure: the normative field labels (version string, SAID, issuer AID, UUID salt, registry identifier, schema, attributes, attribute aggregate, edges, rules, and the node, operator and weight labels of edges), public and private attribute sections, and nested edge sections with operators. Slides 13 to 22 cover disclosure and privacy: the principle of least disclosure and its mechanisms (compact, blinded, unbundled and bulk-issued content), a three-party exploitation model, contractually protected disclosure drawing on Ricardian contracts and chain-link confidentiality, a contractual exchange of offer, accept and disclosure, and the PAC theorem: a conversation may be private, authentic and confidential, but not all three to the same degree. Slides 23 to 46 argue for solving secure attribution, contrast non-repudiable and repudiable authenticity, discuss correlation econ… |
| research/papers/acdc-slides | Authentic Chained Data Containers | summary | v0.1 — 2026-10-14: drafted by Claude from the slides (PDF, 40 slides); unread by Mark; marked partner on Mark's word 2026-10-21, paraphrase only | partner | 443 | # Authentic Chained Data Containers **Abstract.** A 40-slide deck by Samuel M. Smith for the Trust Over IP Technical Working Group ACDC Task Force, version 1.05 of July 2021. It sketches an authentic data container as an attestation with source references, provenance chaining rules, issues with Linked Data, authenticity verification models and authorization properties. Early design material from the task force's start. ## Summary The title slide places the deck in the Trust Over IP (ToIP) Technical Working Group's ACDC (Authentic Chained Data Container) Task Force, with links to its wiki, Slack channel, a GitHub repository and the ACDC white paper. The early slides treat an authentic data container as an attestation: an attestation identifier in the namespace of the testator (the controller who signs it), references to source attestations, data payload correlation identifiers, a payload and attached signatures, with a JSON example. Provenance chaining is sketched as a structure of prior sources, each with rules and weights, leading to a destination (issuer) and a sink (issuee). A slide on issues with Linked Data lists concerns: a signed container as a single shared subject, the need for interoperable schemas (JSON Schema preferred over JSON-LD contexts), the security of imported contexts, the context normalization problem, uncertainty in knowledge representation, and decision architecture layering. Following slides present decision-making as arbiters and aggregators over criteria, a block graph of decentralized autonomic data items passing between entities, and the statement that it is all about automated reasoning. The middle of the deck defines authentic as provenanced or securely attributed, sets out terminology and model properties for authenticity verification, and diagrams issuer-holder-verifier models (with verification at a verifiable data registry or at the issuer), joint and split delegator-service models, and closed and open loop models. The closing slides cover object capabilities against VC (Ve… |
| research/papers/acdc-white-paper | Authentic Chained Data Containers (ACDC) | summary | v0.1 — 2026-10-14: drafted by Claude from the PDF (23 pages); unread by Mark; marked partner on Mark's word 2026-10-21, paraphrase only | partner | 496 | # Authentic Chained Data Containers (ACDC) **Abstract.** Samuel M. Smith's 2021 white paper defining authentic chained data containers (ACDCs) as authentic data containers carrying authentic provenance chains, for data supply chains and rich authorization. It evaluates whether the W3C Verifiable Credential standard could be extended to serve as the concrete implementation and how ZCAP-LD compares, and works through a purchasing-authorization use case. Background on the origins of ACDC rather than the current specification. ## Summary The paper argues for standardized semantics for an authentic chained data container (ACDC), built from an authentic data container (ADC) that carries an authentic provenance chain (APC). Section 1 separates verifiable authenticity, a cryptographic proof of who committed to data, from verifiable veracity, whether the data is true; a signature proves only the former. It compares an ADC to a standardized shipping container that enables interoperable data supply chains, defines an APC as proof of attribution across each transformation, aggregation and transfer of custody, extends chains into trees and graphs, and links all this to automated decision making and rich authorization, of which delegated authorization is a kind. Section 2, the Verifiable Credential hypothesis, proposes leveraging the W3C Verifiable Credential (VC) standard as a nascent ADC standard, notes that VCs lack standard chaining semantics, and points to Hyperledger Aries RFC 0104 (Chained Credentials) as a starting point. It argues that authorizations should be entrained with the data supply chain and discusses whether to use ZCAP-LD (Authorization Capabilities for Linked Data) instead. Section 3 compares properties of authorization models: open and closed loop, persistent and ephemeral, chained, attenuable, aggregative, weighted, and implicit or explicit. Section 4 gives a use case: a seller must verify that a buyer at a large company is authorized to place an order, which requires walking a tree of credentials … |
| research/papers/cesr-proof-signatures | CESR Proof Signatures: Partial Digital Signatures with KERI and ACDC | summary | v0.1 — 2026-10-14: drafted by Claude from the slides (Google Slides exported to PDF, 24 slides); unread by Mark; marked partner on Mark's word 2026-10-21, paraphrase only | partner | 500 | # CESR Proof Signatures: Partial Digital Signatures with KERI and ACDC **Abstract.** A 24-slide Google Slides deck introducing CESR Proof Signatures, a specification for attaching digital signatures to nested portions of self-addressing data, with signatures that can be transposed across envelope boundaries. It recaps KERI, ACDC and CESR, then explains SAD path signature groups, transposition, the SAD Path Language and new code-table entries, and lists uses in KERI, ACDC and the vLEI. For implementers. ## Summary The deck sets out the background first. KERI (Key Event Receipt Infrastructure) is described as a framework for decentralized identifier systems whose key innovations are pre-rotation and threshold structures (multisignature, delegation, witnesses). ACDC (Authentic Chained Data Containers) is described as signed containers chained to dependent credentials, with compact schemas, provenance chaining and a rules section. CESR (Composable Event Streaming Representation) is described as a composable text and binary streaming encoding with table-based codes. CESR Proof Signatures are then defined as a specification for applying digital signatures to multiple nested portions of serialized name/value data. The slides list its properties: compatibility with KERI, ACDC and therefore the vLEI (verifiable Legal Entity Identifier); signing any self-addressing data (SAD) in JSON, CBOR, MessagePack or XML; multiple nested partial signatures; signatures transposable across envelope boundaries; and publication as an IETF draft in the ACDC specification family. The "How does it work" slides step through an ACDC example: start with self-addressing data, attach signatures, sign partial content by path, and nest signatures. A detour introduces KERI exchange messages. The transposition slides show how a signature attached to an inner payload is moved outward when that payload is embedded in an envelope, keeping it attributable. New attachment types are SAD path signature groups (several signatures on one path, either tr… |
| research/papers/hardman-a-primer-on-keri-acdcs-and-cesr | A Primer on KERI, ACDCs, and CESR | summary | v0.1 — 2026-10-15: drafted by Claude from the web page (version 1.2); unread by Mark; marked partner on Mark's word 2026-10-21, paraphrase only | partner | 596 | # A Primer on KERI, ACDCs, and CESR **Abstract.** An introductory paper by Daniel Hardman that explains the three layers of the KERI suite: Key Event Receipt Infrastructure (KERI) for identifiers and key state, Authentic Chained Data Containers (ACDCs) for verifiable data, and Composable Event Streaming Representation (CESR) for encoding. It starts from the weaknesses of administrative public key infrastructure (PKI) and walks through each layer's mechanisms with worked examples. Written for engineers and technically literate readers new to the suite. ## Summary The paper opens with what it calls administrative trust failure. In the X.509 model the binding between an identifier and a key is an assertion signed by a certificate authority (CA), so the root of trust lies outside the identifier. It cites CA compromises and distrust events, the limits of certificate revocation lists and the Online Certificate Status Protocol, the centralizing effect of certificate transparency (CT), and the loss of continuity when certificates expire or keys rotate. From this it derives requirements for a new stack: the identifier as root of trust, auditable history, identity that survives key rotation, safe revocation, and self-service recovery. The KERI section explains key event logs (KELs) as per-identifier microledgers rather than a global consensus ledger; autonomic identifiers (AIDs) as self-certifying identifiers in basic and transferable forms; the inception, rotation and interaction events; pre-rotation, where the next key is committed by its digest; fractionally weighted multisig thresholds, with a corporate board and a break-glass recovery example; quantum resistance through hidden next keys and hybrid thresholds; and witnesses and watchers, which detect duplicity rather than attest to identity. The ACDC section covers issuance by agents with anchoring in the issuer's KEL or a transaction event log (TEL) and transport over the Issuance and Presentation Exchange (IPEX) protocol; self-addressing identifiers (SAIDs); an… |
| research/papers/hardman-acdcs-and-w3c-vcs-lossless-vs-lossy | ACDCs and W3C VCs: Lossless vs. Lossy | summary | v0.1 — 2026-10-15: drafted by Claude from the web page (version 1.1); unread by Mark; marked partner on Mark's word 2026-10-21, paraphrase only | partner | 510 | # ACDCs and W3C VCs: Lossless vs. Lossy **Abstract.** An article by Daniel Hardman comparing Authentic Chained Data Containers (ACDCs) with the W3C Verifiable Credentials (VC) data model through an analogy to lossless and lossy media formats. It names six kinds of information it says VCs discard and ACDCs keep, describes where lossy formats fit, and cites the vLEI system and the Verifiable Voice Protocol as production uses. For architects choosing a credential format. ## Summary The article opens with RAW versus JPEG and FLAC versus MP3: lossless formats serve as the source of truth, lossy ones for distribution, and the conversion runs one way. It applies this to credentials, calling the W3C VC data model lossy (and SD-JWT and ISO mDL as well, deferred to another paper) and ACDCs lossless. Six losses follow. The trust chain: a VC references only its proximate issuer, so wider context needs external trust registries, while ACDCs link credentials by self-addressing identifiers (SAIDs) back to a root such as the Global Legal Entity Identifier Foundation (GLEIF). Time: VCs are verifiable mainly in the present, while the Key Event Receipt Infrastructure (KERI) key event log (KEL) lets a verifier judge validity at a past date. Edge weights and conditional logic: the Resource Description Framework (RDF) needs reification to put properties on relationships, while ACDC edges carry weight, operator and schema natively. Use cases beyond credentials: affidavits, sensor readings and journalists' source graphs have no holder, which ACDCs handle as attestations. Key management transparency: KERI anchors issuance to key state, uses witnesses and watchers to detect compromise, and supports pre-rotation, which VCs lack normatively. Schema stability: JSON-LD `@context` links can rot or change meaning, while ACDCs reference schemas by SAID. The article then says VCs suit low-stakes, short-lived uses within a consistent decentralized identifier (DID) ecosystem. As real-world validation it cites the GLEIF verifiable Legal Entity… |
| research/papers/hardman-analysis-of-did-cel-heartbeat-relevance-to-keri | Analysis of did:cel Heartbeat: Relevance to KERI | summary | v0.1 — 2026-10-15: drafted by Claude from the HTML page (version 1.1); unread by Mark; marked partner on Mark's word 2026-10-21, paraphrase only | partner | 374 | # Analysis of did:cel Heartbeat: Relevance to KERI **Abstract.** A short 2025 analysis by Daniel Hardman of the heartbeat mechanism in the did:cel decentralized identifier (DID) method, which defends against retrograde (history-rewriting) attacks, and of whether KERI (Key Event Receipt Infrastructure) needs one. It concludes that pre-rotation and witness-based duplicity detection already cover the threat, and is for readers comparing DID methods with KERI. ## Summary The analysis first describes the did:cel heartbeat: a periodic, timestamped signature from the identifier's controller. In a retrograde attack, someone holding a key that was valid in the past forges a history branching from that point; the heartbeat narrows the window, since a verifier facing competing histories rejects the one without a continuous stream of recent heartbeats. It then describes KERI's different approach. Pre-rotation commits each establishment event to a digest of the next key, so a compromised past key cannot produce a valid continuation. Witnesses hold replicas of the Key Event Log (KEL) and refuse conflicting events at the same sequence number; watchers query witnesses, and any fork is treated as duplicity, proof that the controller is compromised or dishonest, rather than a contest to pick a winner. A section on operations argues that a heartbeat makes identity infrastructure "hot", requiring keys online periodically, whereas KERI separates safety from liveness and supports cold identifiers whose pre-rotated keys can stay air-gapped for years. The conclusion states that a heartbeat would add complexity and operational risk to KERI without additional security. ## Key terms did:cel, heartbeat, retrograde attack, pre-rotation, witness, watcher, duplicity, Key Event Log (KEL), liveness, cold identifier ## Claims and their evidence - did:cel's heartbeat narrows the window for a successful fork to the most recent heartbeat interval. [informative] - KERI pre-rotation prevents extending a forged chain from a past point of com… |
| research/papers/hardman-bytewise-and-externalized-saids | Bytewise and Externalized SAIDs | summary | v0.1 — 2026-10-15: drafted by Claude from the HTML page (version 1.6); unread by Mark; marked partner on Mark's word 2026-10-21, paraphrase only | partner | 485 | # Bytewise and Externalized SAIDs **Abstract.** A 2024 paper by Daniel Hardman defining two algorithms that extend CESR (Composable Event Streaming Representation) self-addressing identifiers (SAIDs) from canonically serializable data to arbitrary files treated as byte streams: one embeds the SAID in the file at a delimited insertion point, the other places it in a constrained file name. It gives syntax, a threat model and a pointer to a reference implementation, and is for implementers who want documents and media in authenticated data graphs. ## Summary Section 1 recalls how CESR defines self-addressing data (SAD): space for the SAID is reserved with a placeholder, the structure is canonicalized and hashed, and the encoded digest replaces the placeholder. A SAID makes data tamper-evident and lets SAIDs embedded in other data build authenticated graphs. Section 2 explains the gap: many formats (documents, media, proprietary files) are "opaquely structured", reached through libraries that hide fields, with canonicalization rules that are undefined or proprietary. Content-addressed systems such as IPFS are noted as container-oriented and doing more than this problem needs. Section 3 gives the solution. The bytewise algorithm treats a file as bytes before, SAID, bytes after; it finds an insertion point, the five-byte delimiter "SAID:" followed by a template (a CESR digest code and number signs) or a SAID, hashes the whole stream with the placeholder in template form, and writes the SAID in. The paper gives ABNF and a regular expression, and recommends placing insertion points in format metadata (HTML meta tags, XMP, Exif) or, failing that, in a comment. For compressed, encrypted or offset-sensitive files such as .docx and PDF, the externalized algorithm puts the SAID in the file name and embeds an exsertion instruction, a regular expression constraining the name, so a wrong rename is detectable. Bytewise echoes let a SAID appear in several places, and the two algorithms can combine. A threat model states that… |
| research/papers/hardman-comparison-acdcs-and-merkle-tree-certificates | Comparison: ACDCs and Merkle Tree Certificates | summary | v0.1 — 2026-10-15: drafted by Claude from the web page (version 1.1); unread by Mark; marked partner on Mark's word 2026-10-21, paraphrase only | partner | 535 | # Comparison: ACDCs and Merkle Tree Certificates **Abstract.** A paper by Daniel Hardman comparing Authentic Chained Data Containers (ACDCs), with the Key Event Receipt Infrastructure (KERI), and Merkle Tree Certificates (MTCs), a proposed evolution of the web public key infrastructure (WebPKI). It is organized by function: what each commits to and proves, freshness and revocation, operational cost, post-quantum readiness and standardization. It states that it is not a bake-off and is written for readers fluent in one of the two worlds. ## Summary The introduction places KERI and ACDCs in identity and credential systems uneasy with static identifiers, brittle revocation and over-disclosure, and MTCs in the WebPKI, where certificate transparency (CT), unreliable revocation and post-quantum signature sizes strain the system. Both use hash commitments in Merkle-like structures, which invites comparison and misreading. A comparative table maps the two across twelve axes. Section 3 argues that the shared primitive works at different layers: in ACDCs a self-addressing identifier (SAID) commits to the meaning and structure of a claim; in MTCs a Merkle root or landmark commits to the position of a certificate in an append-only issuance log. Section 4 contrasts the proof obligations: ACDC graduated disclosure proves that a partial view corresponds to a specific claim, motivated by privacy and correlation; an MTC inclusion proof shows that a certificate belongs to a committed set, motivated by efficiency. Section 5 treats freshness: KERI emphasizes continuity of key state and permits offline verification, with revocation reconciled as events, while MTCs depend on relying parties having current landmarks and keep X.509 revocation semantics. KERI places its cost on reasoning about history; MTCs on distribution and synchronization. Section 6 says MTCs address post-quantum size pressure, and KERI and ACDCs address continuity across algorithm transitions through pre-rotation. Section 7 lists adoption paths: ISO 17442-3 fo… |
| research/papers/hardman-opaque-identifier-aliases | Opaque Identifier Aliases | summary | v0.1 — 2026-10-15: drafted by Claude from the HTML page (version 0.10); unread by Mark; marked partner on Mark's word 2026-10-21, paraphrase only | partner | 474 | # Opaque Identifier Aliases **Abstract.** A 2026 primer by Daniel Hardman on aliases, the private, friendly labels people attach to opaque cryptographic identifiers such as keys, DIDs (decentralized identifiers) and KERI (Key Event Receipt Infrastructure) autonomic identifiers (AIDs). It explains the properties an alias must have, why a shared naming convention (COIA, Conventions for Opaque Identifier Aliases) helps, and why a name that is proved must never be confused with one that is guessed. It is for designers of wallets and identity software. ## Summary The primer presents itself as the companion promised at the end of the author's parable on Zooko's Triangle, explaining the reasons behind the COIA convention rather than restating it. A person acting through many facets, each with its own identifier, ends up with many unreadable strings; the alias keeps that manageable. An alias, older literature's petname, is a private nickname, not an identifier. It is local, not unique, changeable, and must never be parsed for meaning by anyone but its creator. Treating it as an identifier, caching it as stable or reading meaning from a stranger's alias each produce bugs or attack surface. A convention teaches by example: well-formed names lead people to record who the party is, in what role and in what scope, the same facts software needs. The central security point is the difference between proved and guessed. An alias for a remote party asserts a binding that may only have arrived with the identifier; COIA marks such an alias with a leading 0 meaning "unconfirmed" until the parties compare identifiers over a trusted channel. Because people compare long strings poorly, the primer points to entviz, a picture of an identifier that a substituted key would visibly change. Software can usually choose the right identifier from context and should ask only when an act is valid in more than one capacity. Connections are made to facets, not people. Introductions can be automated; the final human judgment that evidence suf… |
| research/papers/hardman-progressive-assurance-flexible-organizational | Progressive Assurance: Flexible Organizational Identity in the Digital Economy | summary | v0.1 — 2026-10-15: drafted by Claude from the HTML page (version 0.9); unread by Mark; marked partner on Mark's word 2026-10-21, paraphrase only | partner | 534 | # Progressive Assurance: Flexible Organizational Identity in the Digital Economy **Abstract.** A 2026 paper by Daniel Hardman proposing a Progressive Assurance Model for organizational identity: four levels of control assurance built on one KERI (Key Event Receipt Infrastructure) identifier and one ACDC (Authentic Chained Data Container) credential schema, filling the gap between X.509 certificates and the verifiable Legal Entity Identifier (vLEI). It compares the model with X.509, platform verification badges and STIR/SHAKEN, and is for people designing or buying organizational identity. ## Summary Section 1 frames the organizational identity gap: digital systems rarely tell a brand from a specific legal entity, and organizations must choose between low-friction X.509 certificates and the higher-friction vLEI issued under the Global Legal Entity Identifier Foundation (GLEIF) governance framework. The paper lists X.509's mismatches for this use: short and shrinking lifespans, governance that bottoms out in certificate authorities and browser root programs, revocation checks that phone home and soft-fail, and a thin audit trail across key rotation. Section 2 separates identifier scope, reference assurance (how well an identifier is tied to a legal entity and its reference data, drawing on Legal Entity Identifier (LEI) validation and lapse status) and control assurance, which it develops in four levels. LoA 0 is an unambiguous reference affidavit with no proof of control. LoA 1 binds the entity, a cryptographic identifier and a controlled asset such as a domain or phone number. LoA 2 adds human identity proofing and verifiable delegation, through vLEI role credentials or a Generalized Cooperative Delegation credential. LoA 3 is the Legal Entity vLEI under an audited governance framework, with weighted multisignature, witnesses and pre-rotation. Section 3 names three properties: an open ecosystem rather than walled gardens, independent verification rather than phoning home, and a durable audit trail. Section 4… |
| research/papers/hardman-sentries-confessionals-vaults-and-envelopes | Sentries, Confessionals, Vaults, and Envelopes | summary | v0.1 — 2026-10-15: drafted by Claude from the web page (version 1.0); unread by Mark; marked partner on Mark's word 2026-10-21, paraphrase only | partner | 460 | # Sentries, Confessionals, Vaults, and Envelopes **Abstract.** A 2023 primer by Daniel Hardman that uses a medieval metaphor to distinguish four decentralized identity technologies often treated as rivals: OpenID Connect (OIDC), the Credential Handler API (CHAPI), Decentralized Web Nodes (DWNs) and DIDComm. It argues that they solve different problems and that interoperability work should draw boundaries between them rather than unify them. For people working in self-sovereign identity (SSI) and adjacent standards. ## Summary The paper begins from what it calls persistent misunderstandings in the decentralized identity and SSI space about how OIDC, CHAPI, DWNs (and similar secure storage) and DIDComm overlap. Two caveats come first: metaphors can be applied too literally, and the author states that he is one of the architects of DIDComm and so is not an unbiased source. The metaphor sets queen Alice and king Bob in medieval kingdoms. Sentries at a gate stand for OIDC: real-time, session-oriented, credential-based gatekeeping, with Self-Issued OpenID Providers (SIOP) changing who employs the sentries but not the picture. Confessionals stand for CHAPI: a sandboxed, protocol-driven, real-time space inside the browser for sharing credentials with a website, though the author notes CHAPI is more active and sentry-like than a confessional. Vaults stand for DWNs, Solid pods and encrypted data vaults: server-based, policy-governed bulk storage run by a specialist guild, which decouples the owner's timing from the accessor's. Envelopes, seals and couriers stand for DIDComm: asynchronous, transport-agnostic messaging whose security derives from control of a decentralized identifier (DID), with mediators as couriers. The paper separates DIDComm from credential exchange protocols built on it. In "Stepping Back" the author argues that each tool has legitimate uses, a mature ecosystem will have all of them, and some overlap is normal. He distinguishes auto-interop, agreement among parties that share goals (a standards-bo… |
| research/papers/hardman-the-shape-of-delegated-authority | The Shape of Delegated Authority | summary | v0.1 — 2026-10-15: drafted by Claude from the HTML page (version 1.2); unread by Mark; marked partner on Mark's word 2026-10-21, paraphrase only | partner | 587 | # The Shape of Delegated Authority **Abstract.** A 2026 paper by Daniel Hardman proposing a model of delegated authority that makes the category of a delegate's act machine-checkable and lets a stranger verify authority without consulting its issuer. It argues that access control, action taxonomies and decentralized identity each keep only part of what the law of agency long held together, and it draws on KERI (Key Event Receipt Infrastructure) and ACDC (Authentic Chained Data Container) mechanisms for the identity and verification side. It is for architects of authorization for human and AI agents. ## Summary The paper opens with the contrast between handing a delegate a bounded key and handing over a signet ring, and argues that digital systems, through API keys and bearer tokens, mostly hand out rings. Agentic AI makes the gap urgent: authenticating an agent says who is at the door, not what it may do or for whom. Section 2 argues that three research literatures each reduced the old practice of agency: formal access control and capability tokens (rigorous on acts, silent on the relationship), taxonomies of action (rich on acts, single-actor), and the self-sovereign identity work on delegation and guardianship (rich on the relationship, ad hoc on acts). Section 3 explains why an intent grammar such as the author's Syntelos taxonomy is one axis but not enough, since it excludes acts on tools and is two-party. Section 4 gives the act a shape: telos (purpose), effect (observe, create, modify, preserve, destroy) and a named kind of state (information, record, commitment, authority, resource, relationship), modulated by the target's stakes and composed as vectors. The authorization gate and its owner are derived from these coordinates. Section 5 adds a relationship facet: principal, relationship type (delegation, guardianship, controllership, stewardship), liable party, presented identity, duties and revocation, and separates authority to act from authority to authorize. Section 6 makes identity facet-granular… |
| research/papers/hardman-three-dimensions-of-identity | Three Dimensions of Identity | summary | v0.1 — 2026-10-15: drafted by Claude from the web page (version 1.0); unread by Mark; marked partner on Mark's word 2026-10-21, paraphrase only | partner | 439 | # Three Dimensions of Identity **Abstract.** A 2019 article by Daniel Hardman and Jason Law that models digital identity along three dimensions: relationships, attributes and agents. It examines the planes formed by each pair and argues that identity systems should model all three and then automate away what a context does not need. It predates KERI and draws its examples from self-sovereign identity (SSI), Sovrin and Hyperledger Indy. ## Summary The article argues that common views of identity (as authentication, as accounts and credentials, or as personal data) each simplify too much, and that a complete model needs three dimensions. Relationships: people present themselves differently to coworkers, family, doctors and governments. Systems such as LDAP (Lightweight Directory Access Protocol) and social login collapse these into one universal identifier, which enables correlation and surveillance; the article cites Sovrin's partitioning of identity per relationship as a response. Attributes: facts about a person, shared overtly or leaked subtly, are what make identity useful, and the General Data Protection Regulation (GDPR) purpose limitation requires granular control over them. Agents: devices, software and human fiduciaries act on a person's behalf; trustworthy identity needs trustworthy agents, and agents should hold keys distinct from their principals rather than a third party holding the owner's keys. Each pair forms a plane. The relationship and attribute plane answers "who knows what about me?" and calls for unlinkable, selective disclosure, which the article says Hyperledger Indy provides. The relationship and agent plane answers which proxy represents a person in which context, and calls for granular key management with keys at the edge. The agent and attribute plane answers which proxy can share what, illustrated by a chemist giving two recruiters different resumes and by setting different spending limits on a phone and a desktop. The closing section says real choices occur anywhere in the thre… |
| research/papers/hardman-what-does-telco-need-requirements-for-organizational | What Does Telco Need? Requirements for Organizational Identity Evidence | summary | v0.1 — 2026-10-15: drafted by Claude from the web page (version 1.0); unread by Mark; marked partner on Mark's word 2026-10-21, paraphrase only | partner | 497 | # What Does Telco Need? Requirements for Organizational Identity Evidence **Abstract.** A 2026 position paper by Daniel Hardman setting out requirements for an evidence layer for organizational identity, authority and accountability in telecommunications. It proposes five essential properties and an appendix of detailed requirements, non-goals and evaluation questions, as a fair test for candidate architectures rather than a comparison of them. For standards participants, operators and regulators evaluating proposals. ## Summary The paper opens with an engineering analogy: agree on what a bridge must carry before choosing materials. It applies this to organizational identity in telecommunications and states that its aim is to set a fair test, not to pick winners. The problem section lists questions verifiers (operators, regulators, end users) must answer: which accountable party stands behind a communication, whether it has the right to the number or channel, whether it may assert a brand or role, whether an intermediary is authorized, and what evidence supported these conclusions at the time. The answers must hold up under key rotation, compromise, algorithm migration, partial connectivity and long audit horizons. Five properties follow. Evidence over keys: portable, inspectable evidence of relationships, authority and rights, not only present-tense key validation. Historical provability: the ability to show what was valid at a past moment, with identity stable across key changes. Complex delegation: authority as a graph with constraints on purpose, region, time and spend, cooperative delegation in which the delegator stays informed, and control of sub-delegation. Jurisdictional diversity: verifiers anywhere must evaluate evidence without one national root of trust, citing the limited spread of STIR/SHAKEN beyond North America, and the system must deploy incrementally. Cryptographic agility: key rotation, recovery and post-quantum migration without a global flag day, given "harvest now, decrypt later" risk… |
| research/papers/hardman-who-is-signing | Who Is Signing? | summary | v0.1 — 2026-10-15: drafted by Claude from the HTML page (version 1.0); unread by Mark; marked partner on Mark's word 2026-10-21, paraphrase only | partner | 449 | # Who Is Signing? **Abstract.** A short 2026 analysis by Daniel Hardman arguing that "who is signing?" rarely has one answer, because signatures sit where keys, delegation, intent, governance and accountability meet. It offers a lifecycle view of signing and a richer set of questions for verifiers, and is for anyone reasoning about signatures in decentralized identity, PKI (public key infrastructure), credentials and agentic AI. ## Summary The analysis begins with an analogy: a pilot hands the controls to a trainee on a plane owned by one airline subsidiary and marketed by another, so who is flying depends on whether a lawyer, a regulator, a passenger or an insurer is asking. Signing, it argues, has the same dynamic. The naive model holds that a signature proves control of a private key, so the signer is whoever controls it. That is a useful first step but breaks down for organizations, which act through employees, contractors, automation and keys held in hardware modules behind policy engines. A signature can mean authorship, witnessing, assertion, endorsement, authorization or acting for someone else. The article sets out a lifecycle: issuers sign credentials asserting facts, subjects sign collections of evidence they stand behind, and delegated signers sign live artifacts under delegated authority. Delegation is described as normal, with opacity as the risk. Multisignature identifiers, citing the KERI (Key Event Receipt Infrastructure) specification, can make thresholds and role separation visible, while most common tools hide governance behind a single key, so a governed process and a leaked secret look the same from outside. The same concern applies to agentic AI. Signatures sit at intent boundaries, where outsiders infer purpose from action. It closes with five questions to ask instead: who controlled the key, in what role, whose intent is represented, what authority links the signer to an accountable principal, and which of these are inspectable. ## Key terms signer, key control, delegation, evid… |
| research/papers/how-sd-jwt-and-acdc-are-similar-and-different | How SD-JWT and ACDC are similar and different | summary | v0.1 — 2026-10-14: drafted by Claude from the web page (full text); unread by Mark; marked partner on Mark's word 2026-10-21, paraphrase only | partner | 463 | # How SD-JWT and ACDC are similar and different **Abstract.** A comparison by Daniel Hardman of SD-JWT (Selective Disclosure for JSON Web Tokens) and ACDC (Authentic Chained Data Containers): what they share, then how they differ in scope, identifiers, signing, chaining, serialization, origins and standards path. The author states that he is not a neutral source. For practitioners choosing a credential format. ## Summary The paper compares SD-JWT (Selective Disclosure for JSON Web Tokens) and ACDC (Authentic Chained Data Containers). Under Similarities it notes that both are signed, serialized structures readable by a JSON-literate programmer, both came from the decentralized identity community, and both use salted hashes to hide parts of a credential. The author prefers ACDC's term graduated disclosure to selective disclosure, which he calls a loaded regulatory term. He states his own involvement with both camps. The Differences section has seven parts. Scope: both can express entitlement credentials, which is where SD-JWT practice centers; ACDCs may fit other evidence such as citations. Identifiers: SD-JWTs allow DIDs, URLs and other schemes, while ACDCs are stricter, requiring every issuer to be identified by an AID (section Identifiers), an autonomic identifier from KERI (Key Event Receipt Infrastructure). Signing mechanism: SD-JWTs rely on issuer keys and self-asserted timestamps; ACDCs are signed by identifiers whose key event logs (KELs) and transaction event logs (TELs) support rotation, multisignature, revocation and witnessed timing. Chaining: SD-JWTs are standalone, so verifiers rely on issuer registries; ACDCs chain to one another by SAID (self-addressing identifier), qualifying issuers the same way as holders. Serialization: SD-JWT uses compact base64url JSON with mature tooling; ACDCs use CESR (Composable Event Streaming Representation), with text and binary forms and less mature libraries. Intellectual and business roots: SD-JWT from the JWT authors, Microsoft and Ping Identity, close to OAuth… |
| research/papers/kerione-a-did-for-everything | A DID for Everything | summary | v0.1 — 2026-10-14: drafted by Claude from the PDF; unread by Mark; marked partner on Mark's word 2026-10-21, paraphrase only | partner | 563 | # A DID for Everything **Abstract.** A Rebooting the Web of Trust VII (RWOT VII) white paper by Shaun Conway, Andrew Hughes, Moses Ma, Jack Poole, Martin Riedel, Samuel M. Smith and Carsten Stöcker (version 1.0, January 2019), subtitled "Attribution, Verification and Provenance for Entities and Data Items". It extends decentralized identifiers (DIDs) from people to any entity, including machines, locations, events and data items, and proposes chaining signed decentralized autonomic data (DAD) items to prove the provenance of a data flow. Written for architects of decentralized identity, Internet of Things (IoT) and data-provenance systems. ## Summary The paper describes the DID as a globally unique, portable identifier that depends on no central authority, and argues that it can identify everything: people, physical objects, IoT devices, locations, events, agents and pure data objects. It builds on the earlier RWOT paper on Decentralized Autonomic Data. "Why this matters" sets out the problem: identities sit in many centralized or federated systems, each its own root of trust, so a new actor in a value chain cannot independently verify a person's credentials or an object's or data item's provenance, which adds hidden trust costs. It then considers why this matters for people, businesses, objects and machines, and the world. The "comprehensive solution" section recalls three concepts from the DAD paper (DAD items, derived DIDs or dDIDs, and self-contained verification of data governance and integrity) and adds a fourth: data flows can be provenanced through a self-referential chain of signed DAD items, each including the identifier and signature of the previous one. The authors distinguish custody of data from ownership, since data can be copied, and tie data-flow provenance to a zero-trust, or "diffuse-trust", perimeterless security model for decentralized applications. Technical subsections define DID and dDID syntax, a minimal DAD, change detection, dDIDs generated on the fly or unique to the data, publi… |
| research/papers/kerione-cesr-overview-deck | CESR: Composable Event Streaming Representation | summary | v0.1 — 2026-10-14: drafted by Claude from the PDF (22 slides); unread by Mark; marked partner on Mark's word 2026-10-21, paraphrase only | partner | 470 | # CESR: Composable Event Streaming Representation **Abstract.** A 22-slide deck introducing CESR (Composable Event Streaming Representation), the dual text and binary encoding for cryptographic primitives and groups used across the KERI suite. It covers the three domains (raw, compact binary, text), code tables, tritet parsing, the master code table, stream parsing rules, and uses in archiving, legal signatures and audit trails, for implementers. ## Summary The deck, dated 26 April 2022, introduces CESR (Composable Event Streaming Representation), which its title slide describes as composable cryptographic primitives and groups for a streaming protocol that works in text and binary alike. Slide 2 points to the CESR and ACDC (Authentic Chained Data Containers) drafts and the WebOfTrust community. It places CESR among protocol formats: binary internet protocols, text protocols, self-describing maps such as JSON, CBOR and MessagePack, and cryptographic protocols, and calls CESR an inflection point because it gives a dual representation. It weighs binary against text formats and presents CESR as a hybrid of concatenated compact Base64 text and binary. Slides 6 and 7 define three native domains: the raw domain (code and raw bytes, as crypto libraries use them), the compact domain (fully qualified binary for streaming) and the namespace or text domain (fully qualified text, usable in identifiers, documents and verifiable credentials), with round-trip conversion between them, where fully qualified means a prepended derivation code. Slides 8 to 16 give the three classes of codes (basic primitives, indexed codes, group count codes), tritet parsing (the first three bits select the serialization), code table schemes, size tables, special context tables and the master table. Slides 17 and 18 show an annotated signature group example and stream parsing rules. The last slides argue for composability ("Verifiable Text Stream = Verifiable Binary Stream") and describe uses: archival preservation under ISO 14641:2018, legal… |
| research/papers/kerione-decentralized-autonomic-data-dad-and-the-three-rs | Decentralized Autonomic Data (DAD) and the three R's of Key Management | summary | v0.1 — 2026-10-14: drafted by Claude from the PDF; unread by Mark; marked partner on Mark's word 2026-10-21, paraphrase only | partner | 568 | # Decentralized Autonomic Data (DAD) and the three R's of Key Management **Abstract.** A Rebooting the Web of Trust VI (RWOT VI) white paper by Samuel M. Smith with Vishal Gupta (dated April 2018) that proposes decentralized autonomic data (DAD), self-identifying, self-certifying and self-securing data items tied to decentralized identifiers (DIDs), and sets out minimally sufficient methods for the three R's of key management: reproduction, rotation and recovery. Its basic pre-rotation scheme is an early form of the pre-rotation later used in Key Event Receipt Infrastructure (KERI). Written for implementers of identity and streaming-data systems. ## Summary The paper defines DAD as data whose governance may not sit with a single party and which manages itself cryptographically, so that trust in its provenance is diffuse. Key management therefore becomes a first-order property of the data. The motivating use is provenance for streaming data, such as measurements from distributed web or Internet of Things (IoT) applications, and self-sovereign reputation systems, where performance demands call for minimally sufficient mechanisms. The overview explains that a DID is self-certifying because it contains a public key or its fingerprint, and that a DID with its DID document (DDO) is a poor fit for streaming data if every item needs its own pair. The paper instead derives identifiers (derived DIDs, DDIDs) for each DAD from one root DID, so the items carry their own metadata. It gives the DID syntax used (a "dad" method with a Base64 encoded Ed25519 key) and a minimal DAD. The key management section names the three operations. Reproduction covers privacy and confidentiality, hierarchical deterministic key generation, change detection and on-the-fly DDIDs. Rotation introduces basic pre-rotation: the next signing key is declared at inception, and each rotation event propagates a new current key and pre-rotated key. It extends this to listed rotation key structures, multi-signature pre-rotation, collective signatures, … |
| research/papers/kerione-decentralized-identity-as-a-meta-platform-how | Decentralized Identity as a Meta-platform: How Cooperation Beats Aggregation | summary | v0.1 — 2026-10-14: drafted by Claude from the PDF; unread by Mark; marked partner on Mark's word 2026-10-21, paraphrase only | partner | 564 | # Decentralized Identity as a Meta-platform: How Cooperation Beats Aggregation **Abstract.** A Rebooting the Web of Trust IX (RWOT IX) white paper by Michael Shea, Samuel M. Smith and Carsten Stöcker, edited by Juan Caballero with Matt G. Condon (version 1.6, November 2019), arguing that an open decentralized identity framework can act as a meta-platform whose cooperating networks gain more value than competing, aggregating platforms. It covers network scaling laws, trust as a transaction cost, competition at the edge of a meta-platform, and identity for things in a circular economy. It is an economic argument for business and policy readers and does not discuss KERI by name. ## Summary The paper defines a meta-platform as a platform that enables participant-controlled value transfer across and among other platforms, and so produces a "network of network effects". It names an open, interoperable, portable, decentralized identity framework, built on the W3C decentralized identifier (DID) and verifiable credential (VC) standards, as a prime candidate. Its stated purpose is awareness of the economic benefits of cooperation. The introduction contrasts this with the "winner takes all" platform game, in which a few centralized platforms grow as large as possible and can exploit their participants. The first main section applies Metcalfe's law: when two networks of size N1 and N2 become interoperable, each gains value proportional to N1 times N2, and the combined value equals that of a single network of size N1 plus N2. The authors note that cooperation between competitors depends on relative network size and market saturation, and discuss it in the calculus of business strategy. The section on trust treats business value as the reduction of transaction costs, grouped as triangulation, transfer and trust, and describes a "trust tax" paid through certifications, audits and brand premiums along supply chains. Identity and reputation systems are described as trust brokerages: if participants held the credentials plat… |
| research/papers/kerione-gleif-vlei-architecture | GLEIF vLEI Architecture | summary | v0.1 — 2026-10-14: drafted by Claude from the slides (PDF); unread by Mark; marked partner on Mark's word 2026-10-21, paraphrase only | partner | 556 | # GLEIF vLEI Architecture **Abstract.** A slide deck by Samuel M. Smith (version 1.2, 5 January 2021), linked on keri.one as "GLEIF vLEI KERI Implementation", giving an early overview of the cryptographic infrastructure the Global Legal Entity Identifier Foundation (GLEIF) chose for the verifiable Legal Entity Identifier (vLEI). It explains why GLEIF chose Key Event Receipt Infrastructure (KERI) based identifiers over shared-ledger registries, how key event logs control credential registries, and how delegation from a single GLEIF root identifier structures the ecosystem. For readers who want the architectural reasoning behind the vLEI as it stood in early 2021. ## Summary The deck opens by defining a vLEI as a digitally signed document making assertions about a legal entity, such as its Legal Entity Identifier (LEI) code, official name and registered address. It separates two senses of "verifiable": the veracity of the assertions, assured by GLEIF and its issuing organizations through their processes and policy, and the authenticity of the document, assured cryptographically. At that point the vLEI format was described as based on the W3C verifiable credential (VC) and decentralized identifier (DID) standards. It then presents the issuer, holder and verifier model, and adds a verifiable data registry (VDR) through which verifiers establish control authority over a DID. Most DID methods use a shared ledger as their VDR; the deck states that GLEIF chose KERI-based DID methods instead, because they are ledger independent and do not force all participants onto one ledger. In KERI, each identifier has its own key event log (KEL), a hash-chained record of inception, rotation and interaction events that proves the current authoritative keys. Such identifiers are called autonomic identifiers (AIDs). A KEL can control a transaction event log (TEL) through anchoring seals; for the vLEI, TELs hold issuance and revocation state, and each credential can have its own separable TEL keyed by its content digest. Later sli… |
| research/papers/kerione-identity-system-essentials | Identity System Essentials | summary | v0.1 — 2026-10-14: drafted by Claude from the PDF; unread by Mark; marked partner on Mark's word 2026-10-21, paraphrase only | partner | 543 | # Identity System Essentials **Abstract.** A white paper by Samuel M. Smith and Dmitry Khovratovich of Evernym, dated 29 March 2016, describing the essential characteristics of an identity system that provides sovereignty, security and privacy, and defining identity from what such a system provides. It covers attribute exchange, least disclosure, cryptonymous identifiers, identity graphs, sovereignty, Byzantine fault tolerant (BFT) ledgers and degrees of transaction privacy. It predates the Key Event Receipt Infrastructure (KERI) work and is useful as background on the ideas it grew from. ## Summary The paper does not define identity in advance. It describes an identity system and then defines identity within it, and argues that high degrees of sovereignty, security and privacy together are best obtained through an open platform using distributed consensus protocols and modern cryptography. It names Open Reputation among the proposed systems that influenced it. The identity system is described as transactional: it enables entities (people, groups, organizations or computational agents) to exchange the identifiers and attributes each needs about the other before a social, financial or legal transaction proceeds. The guiding principle is least disclosure, revealing the minimum needed and no more. Identifiers are strings associated with subsets of attributes. An identity is defined as at least one cryptonymous identifier (a cryptonym) plus a subset of attributes, with one primary identifier; a reused cryptonym acts as a pseudonym and a one-time cryptonym gives anonymity. Human-meaningful aliases may be added. An entity's identities and the links between them form an identity graph, and hierarchical deterministic keychains address the resulting number of private keys. Sovereignty means an entity controls its own identity graph, including the creation, modification, storage, disclosure and destruction of its identifiers and attributes. The paper discusses the disadvantages of a personal data store and of identi… |
| research/papers/kerione-keri-white-paper | Key Event Receipt Infrastructure (KERI) Design | summary | v0.1 — 2026-10-14: drafted by Claude from the PDF (v2.63); unread by Mark; marked partner on Mark's word 2026-10-21, paraphrase only | partner | 547 | # Key Event Receipt Infrastructure (KERI) Design **Abstract.** The founding white paper for KERI (Key Event Receipt Infrastructure), now at version 2.63, presenting self-certifying autonomic identifiers, key pre-rotation, key event logs and witnessed receipts as a decentralized key management infrastructure and candidate trust spanning layer for the internet. It covers the theory, event semantics, operational modes, witness agreement, derivation codes and serialization in 142 pages, for readers who want the full design rationale. ## Summary The paper (KERI here stands for Key Event Receipt Infrastructure) starts from the observation that the Internet Protocol (IP) has no security layer, so authenticity must be added as an identity (identifier) system security overlay that binds controllers, identifiers and key pairs. It argues that administrative trust bases, such as the Domain Name System (DNS) and certificate authorities, make that binding only as strong as the administrator, and proposes instead a cryptographic root of trust in self-certifying identifiers. Sections 2 to 5 develop autonomic identifiers (AIDs), autonomic namespaces and the autonomic identity system, compare trust bases, and present KERI as a candidate trust spanning layer. Section 6 treats key management, naming rotation as the primary operation. Section 7 defines the components: qualified cryptographic material, events (inception, rotation, interaction, delegated forms), seals, key event logs (KELs), receipts and key event receipt logs (KERLs), and the roles of controller, witness, watcher, juror, judge and resolver. Section 9 explains pre-rotation: each establishment event commits to the digest of the next key set, so a compromise of exposed keys cannot undo the forward commitment; hashing the next keys is also presented as the basis of post-quantum protection (section 9.2). Sections 10 and 11 describe the direct (one-to-one) and indirect (one-to-any) replay modes and the witness agreement algorithm, named KAWA (KERI's Algorithm for Witn… |
| research/papers/kerione-keri-white-paper-slide-deck | Key Event Receipt Infrastructure: A Secure Identifier Overlay for the Internet | summary | v0.1 — 2026-10-14: drafted by Claude from the PDF (208 slides); unread by Mark; marked partner on Mark's word 2026-10-21, paraphrase only | partner | 460 | # Key Event Receipt Infrastructure: A Secure Identifier Overlay for the Internet **Abstract.** A 208-slide overview deck (version 2.60) that accompanies the KERI white paper, covering the secure attribution problem, self-certifying identifiers, trust bases, delegation, verifiable data registries, event formats, witness agreement, security considerations and CESR encoding. It suits readers who want the white paper's argument in diagrams before reading the full paper. ## Summary The deck opens with the secure attribution problem: replacing a human basis of trust ("in person") with a cryptographic root of trust based on verifiable digital signatures. It describes KERI (Key Event Receipt Infrastructure) as "the Platypus of the identity space" (slide 7), a combination of features drawn from DNS/CA (Domain Name System and certificate authorities), PGP and blockchains, and lists its properties in "KERI for Short" (slide 11): open source under Apache 2, self-certifying identifiers, end-verifiable authenticity, pre-rotation, multi-signature and weighted multi-signature, delegated identifiers, and support for GDPR and e-signature compliance. The first block covers self-certifying identifier (SCID) derivations (basic, self-addressing, multi-signature, delegated, self-signing), inconsistency versus duplicity and the duplicity game, autonomic identifiers (AIDs) and namespaces, and three trust bases (administrative, algorithmic, autonomic). It then covers Zooko's trilemma, the unified identifier model with the AID|LID couplet, the KERI stack, decentralized key management infrastructure (DKMI) with univalent, bivalent and multivalent delegation, and verifiable credential registries built on transaction event logs (TELs). Middle slides cover the internet hourglass, platform-locked trust, issuer-holder-verifier models, key event messages, chaining, establishment and non-establishment events, seals, pre-rotation, ledger attack vectors, the direct and indirect replay modes, live and dead exploits, witnessing rules, and KA2CE … |
| research/papers/kerione-keridemlia-a-discovery-mechanism-for-keri | Keridemlia: A Discovery Mechanism for KERI | summary | v0.1 — 2026-10-14: drafted by Claude from the PDF (page images); unread by Mark; marked partner on Mark's word 2026-10-21, paraphrase only | partner | 610 | # Keridemlia: A Discovery Mechanism for KERI **Abstract.** A paper by Ryan W. West and Samuel M. Smith describing Keridemlia, a prototype discovery service for Key Event Receipt Infrastructure (KERI) that maps autonomic identifiers (AIDs) to their witnesses' identifiers and witness identifiers to IP addresses, using the Kademlia distributed hash table (DHT). It covers the design, the data structures considered, a four-endpoint HTTP API, verification of published data, and planned optimizations. For developers interested in how KERI identifiers could be located when KERI is used in indirect mode. ## Summary The abstract presents KERI as a decentralized, end-to-end verifiable identity system in which each identifier is bound to a separately stored key event log (KEL), held by always-available witness servers. To verify who controls an identifier, a user must retrieve its KEL, which requires knowing a witness's IP address. Keridemlia is described as a service similar to the Domain Name System (DNS) that stores this mapping and accepts only signed, verified data. The background section recounts the Internet's insecure origins and the later addition of HTTPS with certificate authorities and of DNS Security Extensions (DNSSEC), and contrasts these with KERI, whose self-certifying, self-managing AIDs rely on cryptographic proof rather than certificate authorities. KERI can run in direct mode, where controllers exchange IP addresses, or indirect mode through witnesses, which needs a discovery mechanism. Keridemlia acts like a DNS server that can map names to other names (like a CNAME record) and names to addresses (like an A record), and the authors suggest it may serve as an end-verifiable replacement for DNS. The design wraps a Python Kademlia implementation in an API, chosen after comparing ways to build distributed systems; the DHT stores controller AIDs mapped to their key event state (KES), which lists current witnesses, and witness AIDs mapped to IP addresses. The paper explains KELs, inception, rotation wit… |
| research/papers/kerione-keris-strategy-for-post-quantum-security | KERI's Strategy for Post-Quantum Security | summary | v0.1 — 2026-10-14: drafted by Claude from the PDF (10 pages); unread by Mark; marked partner on Mark's word 2026-10-21, paraphrase only | partner | 495 | # KERI's Strategy for Post-Quantum Security **Abstract.** A ten-page white paper explaining how KERI addresses two quantum threats: a surprise quantum attack on signing keys, met by pre-rotation behind hash digests, and harvest-now-decrypt-later attacks on confidentiality, left to the application layer through out-of-band key exchange or hybrid key encapsulation. It places this within NIST's post-quantum timeline and argues for crypto-agility, for decision makers and practitioners. ## Summary The paper opens with "Harvest Now, Decrypt Later" (HNDL): adversaries storing encrypted data today to decrypt once a cryptographically relevant quantum computer exists. It cites NIST's August 2024 post-quantum cryptography (PQC) standards (FIPS 203, 204 and 205), the planned deprecation of RSA and elliptic curve cryptography by 2030 and their disallowance after 2035, and national programs in the US, Europe, India and South Korea. It frames a two-front problem: a "surprise quantum attack" on signing keys (control and authenticity) and HNDL on key exchange (confidentiality). It then introduces KERI (Key Event Receipt Infrastructure) as a ledgerless decentralized key management infrastructure (DKMI) built on autonomic identifiers (AIDs) and key event logs (KELs), whose end-verifiability lets trust be carried by any "ambient infrastructure." For control, the paper explains pre-rotation with a royal succession analogy: the controller commits to the digest of the next rotation keys without revealing them, and a 256-bit hash is described as giving about 128 bits of post-quantum security. If a current signing key is broken, the controller detects forged events through a watcher and rotates, revealing and signing with the pre-committed key, which can be a post-quantum algorithm. For confidentiality, the paper treats encryption as outside KERI's scope and names two application-layer options: an out-of-band shared secret, and hybrid key encapsulation combining X25519 with a PQC mechanism such as ML-KEM, citing OpenSSH's hybrid d… |
| research/papers/kerione-manning-ssi-book-chapter-10 | 10 Decentralized key management | summary | v0.1 — 2026-10-14: drafted by Claude from the PDF (38 pages); unread by Mark; marked partner on Mark's word 2026-10-21, paraphrase only | partner | 481 | # 10 Decentralized key management **Abstract.** Chapter 10, 'Decentralized key management', from a Manning book on self-sovereign identity (SSI), written by Sam Smith and posted as a 38-page pre-production manuscript. It covers why key management is hard, conventional standards, roots of trust, decentralized key management, ledger-based and peer DID methods, and closes with a section summarizing KERI's architecture, for readers new to the subject. ## Summary The chapter belongs to a Manning book on self-sovereign identity (SSI) and follows a chapter on digital wallets and agents. An editors' introduction presents Dr. Sam Smith as the chapter's author and the inventor of KERI (Key Event Receipt Infrastructure), covered in the final section. It first explains why digital key management is hard: digital keys can be stolen remotely, their theft may go unnoticed, and their loss can be irreversible. It then reviews conventional standards and practice, naming NIST publications and OASIS's Key Management Interoperability Protocol (KMIP). The core of the chapter is roots of trust. It contrasts administrative roots of trust with algorithmic (ledger) and self-certifying ones, summarized in a table of the three types, and describes the move to decentralized key management as a migration away from administrative roots. It sets out requirements for a decentralized key management system (DKMS): vendor neutral, open to new cipher suites, portable across wallets, and with built-in recovery, and notes an initial DKMS design developed by Evernym for the U.S. Department of Homeland Security. It then describes the tools that verifiable credentials (VCs), decentralized identifiers (DIDs) and SSI bring, such as separating key verification from identity verification, automated rotation, backup and recovery, and guardianship. It reviews ledger-based DID methods, which it says make up most DID methods and are "ledger-locked", and peer DIDs, which use a simple self-certifying identifier (SCID) shared peer to peer. The final section… |
| research/papers/kerione-open-reputation-framework | Open Reputation Framework | summary | v0.1 — 2026-10-15: drafted by Claude from the PDF in the Papers repository; unread by Mark; marked partner on Mark's word 2026-10-21, paraphrase only | partner | 507 | # Open Reputation Framework **Abstract.** The low-level white paper for Open Reputation (Draft Revision 1.2, 2015/05/13) by Samuel M. Smith of The World Table: a notional architecture and partial formal specification for generating, evaluating and disseminating reputation in a trustworthy way. It defines reputes (reputational events), identities, cryptonyms and aliases, compares distributed consensus algorithms, and covers secure transmission, storage, privacy and repute composition. It predates KERI and includes an early discussion of self-certifying identifiers. ## Summary The abstract states that existing reputation approaches are narrow, and that Open Reputation aims to provide a general foundation for collecting, storing, authenticating, aggregating, evaluating and disseminating reputational events. Reputation is an indicator built up from reputes; trustworthiness comes from performing each processing step through a transparent, publicly verifiable method such as distributed consensus, which Open Reputation extends from a ledger to a public database. Section 1 defines reputation as past behavior used to predict future behavior in context, and sets out the terminology: reputee, identity, identifiers (primary, secondary, tertiary), descriptors, cryptonyms ("nyms"), aliases, repute, reputer and reputery. It describes an identity-cryptonym registry governed by a consensus ledger, identity disclosure and validation, an identity graph, JSON serialization, date-time stamps, and signing and encryption. Section 2, "Trustworthy Reputations", describes diffused trust through consensus pools, compares proof-of-work, proof-of-stake and Byzantine agreement, and introduces "Chainmail", which uses the image of a knitting that can unravel to describe majority-collusion attacks on a ledger and ways to bind it. It also covers an identity ledger and self-certifying identifiers, in which a public key embedded in the identifier lets a requester verify a signed response. Later sections propose Cred coupons to pay host nodes… |
| research/papers/kerione-open-reputation-the-decentralized-reputation-platfor | Open Reputation: The Decentralized Reputation Platform | summary | v0.1 — 2026-10-15: drafted by Claude from the PDF in the Papers repository; unread by Mark; marked partner on Mark's word 2026-10-21, paraphrase only | partner | 524 | # Open Reputation: The Decentralized Reputation Platform **Abstract.** The high-level white paper for Open Reputation (Draft Revision 1.1, 13 May 2015), written by Lincoln Cannon of The World Table, describing an open-source, decentralized platform that maps identity and reputation onto the Internet of Things. It introduces entities, agents, identities, reputes, virtues and relations, a decentralized database anchored to a blockchain, and a privacy model in which identities are public and reputations private. It predates KERI and is of historical interest. ## Summary The introduction argues that growth in the number and diversity of connected machines will make relationships too complex to manage by hand, and that a "reputation web" built on open-source code and decentralized systems will be needed, in which everyone and everything has at least a public pseudonymous identity and may have an encrypted, shareable reputation. It lists expected applications across software, electronics, finance, biotechnology and government, and proposes Open Reputation. The platform is open source under the Apache License 2.0. Its topology consists of entities (anything an agent assigns an identity to) and agents (entities that interact). An identity consists of identifiers and descriptors: primary identifiers are cryptographic public keys, and secondary identifiers are unique symbols kept by outside authorities, such as domain names or email addresses. Agents may delegate to trusted agents called reputeries. Reputation consists of reputes attributed according to virtues. Virtues range from simple constraints (for example "helpful" between -1 and 1) to algorithms that combine other virtues. A repute always joins the reputer's direct reputation, and joins the reputee's only if the reputee is not an agent or recognizes it; reputes can be retracted by the reputer or rejected by the reputee. Relations, such as "authored by" or "friend", begin with recognized reputes and end with retracted or rejected ones. Data persist in a decen… |
| research/papers/kerione-quantum-secure-dids | Quantum Secure DIDs | summary | v0.1 — 2026-10-14: drafted by Claude from the PDF; unread by Mark; marked partner on Mark's word 2026-10-21, paraphrase only | partner | 589 | # Quantum Secure DIDs **Abstract.** A Rebooting the Web of Trust (RWOT) community paper by Carsten Stöcker, Samuel M. Smith and Juan Caballero (version 1.0, July 2020) on how to make a decentralized identifier (DID) method resistant to quantum attack using existing signing and hashing primitives. It proposes publishing only hashes of public keys and rotating keys after every signing operation, and points to the pre-rotation in Key Event Receipt Infrastructure (KERI) as one way to do so. Written for designers of DID methods and decentralized identity systems. ## Summary The paper starts from the risk that quantum computers may break the signature schemes on which decentralized identity relies (elliptic-curve and RSA-based schemes), with no warning of when. Its objective is a mechanism, independent of any one DID method, for protecting DIDs during the transition to quantum-resistant signing ciphers, using today's ciphers. Its prior-art section rests on Daniel J. Bernstein's cost analysis: quantum computers are expected to be far more effective at factorization than at finding hash collisions. The authors conclude that existing signing primitives should be treated as vulnerable while hash functions can be treated as resilient. The paper takes its inspiration from Bitcoin's pay-to-public-key-hash addresses, where the public key is hidden behind a hash until first use. It notes that did:ethr and did:sov use similar hash-based blinding, but that the public key is exposed once a DID document is configured or a verifiable credential is signed. The proposed measures are to register one-way hashes of public keys rather than the keys themselves as authorization attributes, and to deactivate or rotate a key every time it is exposed by signing. Because rotating on a blockchain after every signature would be costly, the authors suggest moving key-state maintenance to a lighter parallel system such as KERI, whose verifiable logs of key events do not depend on block confirmation times. A "recipe" follows as three user jo… |
| research/papers/kerione-secure-privacy-authenticity-and-confidentiality-spac | Secure Privacy, Authenticity, and Confidentiality (SPAC) | summary | v0.1 — 2026-10-14: drafted by Claude from the Markdown file (version 0.5.3); unread by Mark; marked partner on Mark's word 2026-10-21, paraphrase only | partner | 489 | # Secure Privacy, Authenticity, and Confidentiality (SPAC) **Abstract.** A white paper, in Markdown on GitHub, that sets out the PAC (privacy, authenticity, confidentiality) trilemma and designs messaging protocols that give the best privacy possible given the strongest authenticity and confidentiality, using KERI autonomic identifiers and a modified ESSR (Encrypt Sender, Sign Receiver) construction. It covers threat models, relationship formation, intermediaries, interaction contexts and a CESR encoding, and is aimed at protocol designers. ## Summary The paper begins with the PAC theorem or trilemma: "One can have any two of the three (privacy, authenticity, confidentiality) at the highest level but not all three." Following the Trust Over IP (ToIP) design goals, it ranks authenticity first, confidentiality second and privacy third, while noting that the order of layered mechanisms inside a protocol need not follow that ranking; the "security overlay spiral" illustrates this. Privacy is framed as control over who took part in a conversation (correlatable non-content metadata), and the paper narrows the goal to "effective privacy": protection against exploitation through correlation rather than against correlation itself. It introduces a three-party exploitation model (first party sender, second party intended receiver, third party anyone else), reviews exploiters and threats such as identity theft and aggregation, and argues that VPN-like trusted intermediaries and contractual protection address different aggregators. The technical part replaces long-term public keys with unbounded-term KERI autonomic identifiers (AIDs), whose current keys are looked up from key event logs (KELs). It pairs end-verifiability (for authenticity) with "end-only-viewability" (for confidentiality), restricts itself to widely available libsodium primitives ("dumb crypto"), and builds on ESSR (Encrypt Sender's key, Sign Receiver's key) to protect against key compromise impersonation, with sourceless and destinationless variants. L… |
| research/papers/kerione-spac-presentation | SPAC (Secure Privacy, Authenticity, and Confidentiality) | summary | v0.1 — 2026-10-14: drafted by Claude from the PDF (79 slides); unread by Mark; marked partner on Mark's word 2026-10-21, paraphrase only | partner | 428 | # SPAC (Secure Privacy, Authenticity, and Confidentiality) **Abstract.** A 79-slide deck, subtitled 'Privacy Given Strongest Authenticity and Confidentiality', that presents the SPAC white paper: the PAC theorem, the three-party exploitation model, ESSR-based authenticated encryption, relationship and intermediary protocols, sustainable privacy and threat mitigations. It is for readers who want the SPAC argument in slides before the long paper. ## Summary The deck follows the SPAC (Secure Privacy, Authenticity, and Confidentiality) white paper and links to it on slide 2. It opens with the PAC theorem (any two of privacy, authenticity and confidentiality at the highest level, not all three) and the Trust Over IP (ToIP) design goals, then separates privacy from confidentiality, including legal definitions and surveillance law, and states the "surveillance privacy problem": strong authenticity and confidentiality are achievable, while privacy of addresses is weaker. Slides 11 to 17 define privacy protection as protection from exploitation of correlatable identifiers, introduce the three-party exploitation model, autonomic identifiers (AIDs) as unbounded-term identifiers, and the dual properties of end verifiability and end-only viewability. Slides 18 to 27 set the cryptographic baseline: SUF-CMA (strong unforgeability under chosen message attack) signatures with Ed25519, IND-CCA2 (indistinguishability under adaptive chosen ciphertext attack) encryption via ECIES or HPKE and the libsodium sealed box, why HPKE alone does not give authenticity, and ESSR (Encrypt Sender, Sign Receiver). Slides 28 to 45 cover relationships and relationship graphs, cryptonyms, out-of-band setup, the multiple overlay spiral, protocol syntax, the direct protocol, relationship formation, and shared and non-shared intermediaries. Slides 48 to 62 cover identity theft, sustainable privacy and the time value of information, clandestine versus covert mechanisms, re-identification, exploiters, aggregator threats and mitigations, and risk ran… |
| research/papers/kerione-state-endorsed-digital-identity-protecting-liberty | State-Endorsed Digital Identity: Protecting Liberty in the Digital Age | summary | v0.1 — 2026-10-14: drafted by Claude from the PDF (all six pages); unread by Mark; marked partner on Mark's word 2026-10-21, paraphrase only | partner | 647 | # State-Endorsed Digital Identity: Protecting Liberty in the Digital Age **Abstract.** A six-page paper (version 1.0, 17 October 2025) from the Utah Department of Government Operations that sets out State-Endorsed Digital Identity (SEDI), a model in which the individual controls a cryptographic identifier and the state endorses, rather than creates, that identity. It lists the model's basic requirements (legal framework, individual control, privacy, parental rights and delegation, security, backward compatibility) and invites other states to join a SEDI Consortium. It is for policy makers and readers following state adoption of decentralized identity. ## Summary The paper opens with a summary that calls SEDI a constitutionally based, "rights-first" framework for digital identity, resting on the view that identity is innate to the individual and not created by governments or corporations. It says many digital identity systems in the United States lack a comprehensive governance framework, and that public distrust grows when systems allow tracking, surveillance, profiling and scoring. "The Challenge" section describes the loss of trust online: physical signals of identity disappear, identity is fragmented across accounts yet unified by trackable profiles, and generative AI (artificial intelligence) lowers the cost of deepfakes and impersonation. "Why SEDI Is Needed" names existing technologies, among them the mobile driver's license standard ISO/IEC 18013-5/-7, OpenID Connect, OAuth 2.0, KERI (Key Event Receipt Infrastructure), SAML and W3C Verifiable Credentials, and says adopters have not addressed individual rights, governance and constitutional safeguards. "A Constitutional Foundation" states the core principle: "SEDI begins with a foundational principle: identity belongs to the person, not the government." (page 3). The state acts as a trusted endorser that verifies an asserted identity and issues a credential bound to an identifier the individual alone controls. A hierarchy of values puts individual rig… |
| research/papers/kerione-sustainable-privacy | Sustainable Privacy | summary | v0.1 — 2026-10-14: drafted by Claude from the PDF (v1.2.8); unread by Mark; marked partner on Mark's word 2026-10-21, paraphrase only | partner | 476 | # Sustainable Privacy **Abstract.** A 15-page white paper arguing that privacy over time needs economic, legal, regulatory and technical protections together, since K-anonymity de-identification and selective disclosure are defeated by re-identification attacks. It describes a contextual linkability re-identification attack on selective disclosure and proposes chain-link confidentiality and data loyalty, for readers concerned with privacy design and policy. ## Summary The paper defines sustainable privacy as the maintenance of personal data privacy over time, from two sides: how a person keeps their data private, and how a holder of someone else's data respects that privacy. Because any system that gathers, uses and shares information leaks, privacy erodes over time. Section 1 sets out the three-party exploitation model (first party source, second party intended recipient, third party anyone else), in which any unintended use of first-party data is exploitative, and refers to the SPAC (Secure Privacy, Authenticity, and Confidentiality) paper for third-party metadata correlation. It reviews privacy by design and by default and argues that K-anonymity de-identification is easy to defeat and should no longer count as best practice, while differential privacy and synthetic data are, so far, considered infeasible to defeat. Section 2 covers re-identification: linkage attacks and, as a new attack, contextual linkability. A verifier can shape the context of a presentation so that auxiliary data gathered at disclosure, combined with selectively disclosed attributes, re-identifies the discloser, defeating selective disclosure including zero-knowledge proof (ZKP) methods. The paper also discusses a security vulnerability of unlinkable disclosure. Section 3 covers protection of aggregated and non-aggregated first-party data and managing the time value of information. Section 4 turns to law and regulation: de-identification as a safe harbor is described as outdated; chain-link confidentiality attaches contractual "str… |
| research/papers/kerione-the-duplicity-game | The Duplicity Game: or why you can trust KERI | summary | v0.1 — 2026-10-14: drafted by Claude from the PDF (72 slides); unread by Mark; marked partner on Mark's word 2026-10-21, paraphrase only | partner | 480 | # The Duplicity Game: or why you can trust KERI **Abstract.** A 72-slide deck presented at Internet Identity Workshop (IIW) Spring 2020 that steps through a game between a controller and validators to show how inconsistency and duplicity in key event logs can or cannot go undetected under local and global consistency guarantees. It closes on key event based provenance and certificate transparency, for readers who want the intuition behind KERI's duplicity detection. ## Summary The deck was given at the Internet Identity Workshop (IIW) in spring 2020 (28 to 30 April) and points to the KERI (Key Event Receipt Infrastructure) white paper and implementation notes. It is built as a sequence of animation steps on a few diagrams. It first separates two ideas, using dictionary definitions: inconsistency ("lacking agreement") and duplicity ("acting in two different ways to different people concerning the same matter"). An internally inconsistent key event log is not verifiable, and verification from the self-certifying root of trust protects against it. An externally inconsistent log, where two copies are each verifiable but differ, is duplicitous, and duplicity detection protects against that. The game itself has a controller, Cate, and validators. In the first round Cate promises a consistent pair-wise log, a local consistency guarantee suited to private one-to-one interactions, and the slides ask how Cate could be duplicitous without being caught. In the second, a service or agent controlled by Cate promises a consistent log to anyone, adding high availability. In the third, the service promises the same log to everyone, a global consistency guarantee for public one-to-any interactions; here the slides note that breaking global consistency is a provable liability, that global consistency may only matter once parties need to interact, and introduce ambient duplicity detection. The closing slides describe key event based provenance: KERLs (key event receipt logs) as end-verifiable proofs that anyone may verify, su… |
| research/papers/kerione-universal-identifier-theory | Universal Identifier Theory | summary | v0.1 — 2026-10-14: drafted by Claude from the PDF (v1.40); unread by Mark; marked partner on Mark's word 2026-10-21, paraphrase only | partner | 501 | # Universal Identifier Theory **Abstract.** A 40-page white paper presenting a unified model of identifiers in which cryptographic autonomic identifiers (AIDs) provide trust domains that legitimize human-meaningful identifiers (LIDs), expressed as the aid|lid couplet. It covers trust bases, separable roots of trust, key rotation versus statement revocation, multi-valent key management, promulgation, verifiable credential issuance and verifiable algorithms for LID issuance, for identifier system designers. ## Summary The paper proposes a theory for designing identifier systems that are secure, trustable and universal. It uses "identifier system" rather than "identity system" and defines a digital identity as an identifier plus attributes. Starting from Zooko's trilemma (human-meaningful, secure, decentralized: any two but not all three), it argues that solutions which register insecure human-meaningful names on a ledger show that a single-identifier model is incomplete. The unified model joins two kinds of identifier. Autonomic identifiers (AIDs), provided by KERI (Key Event Receipt Infrastructure), are based on a self-certifying identifier (SCID) prefix: not human-meaningful, but cryptographically strong, with their own trust basis and trust domain. Any other identifier, including a human-meaningful one, can be secured in that trust domain through an end-verifiable authorization that makes it a legitimized identifier (LID). The result is the couplet aid|lid. Section 1 also covers identifier control and trust bases, reputational trust and examples of LIDs. Section 2 treats separable roots of trust, roots of trust for validators, separated control, assumptions about verifiers and zero-trust computing. Section 3 summarizes security as a function of each participant's own infrastructure. Section 4 distinguishes key rotation from statement revocation and covers authorization models. Sections 5 to 8 apply the model: multi-valent key management with a root AID and delegations, promulgation infrastructure, a verifi… |
| research/papers/kerione-utah-pro-human-ai-executive-order-2026-08 | Establishing Utah's Pro-Human Approach to Artificial Intelligence in State Government (Executive Order 2026-08) | summary | v0.1 — 2026-10-14: drafted by Claude from the PDF (all four pages); unread by Mark; marked partner on Mark's word 2026-10-21, paraphrase only | partner | 626 | # Establishing Utah's Pro-Human Approach to Artificial Intelligence in State Government (Executive Order 2026-08) **Abstract.** Utah Executive Order 2026-08, signed by Governor Spencer J. Cox on 6 October 2026, sets rules for the use of artificial intelligence (AI) by state executive-branch agencies under the Pro-Human AI Initiative. It assigns duties to the Department of Government Operations, the Division of Technology Services and each agency, and directs that the State-Endorsed Digital Identity (SEDI) Framework be developed and used, where applicable, as the state's trust infrastructure for AI. It is for readers following state-level adoption of verifiable identity and credentials. ## Summary The order opens with recitals. They describe AI as an opportunity for Utah residents, acknowledge public concern about AI in government, reject a choice between innovation and safety, and refer to the Pro-Human AI Initiative the governor established in December 2025. One recital says the advance of AI calls for privacy-preserving ways to verify the authenticity of individuals, organizations, AI agents and digital information. Another describes the SEDI Framework as providing privacy-preserving, individually controlled, cryptographically verifiable digital identity and credentials that guard against identity fraud, impersonation, unauthorized AI agent activity and fraudulent digital content. The operative sections are numbered 1 to 7. Section 1 states five purposes: evaluate AI tools by the initiative's principles, let the Department of Government Operations (DGO) lead AI-driven process improvement, train the state workforce, give agencies a framework for citizen-facing tools with safeguards for state data, and set agency responsibilities. Section 2 defines "agency" as executive-branch bodies, excluding higher education, the education boards, independent entities, the Attorney General, Auditor and Treasurer, and the legislative and judicial branches. Section 3 sets two foundational principles, Human-Guided and Human-… |
| research/papers/papers-acdc-affordances-confidential-data-protection | ACDC Affordances for Confidential (Sensitive) Data Protection and Management | summary | v0.1 — 2026-10-15: drafted by Claude from the markdown file in the Papers repository; unread by Mark; marked partner on Mark's word 2026-10-21, paraphrase only | partner | 550 | # ACDC Affordances for Confidential (Sensitive) Data Protection and Management **Abstract.** A short working paper in Samuel M. Smith's Papers repository arguing that data shared over the internet should be managed under the established practices for confidential data rather than under the label of privacy, and that the graduated disclosure mechanisms of Authentic Chained Data Containers (ACDCs) support those practices. It sets out a three-party model of data sharing and ends with draft notes on bulk issuance. For readers working on data governance and credential design. ## Summary The paper opens by distinguishing "confidential" from "private" data. It argues that, for data shared over the internet, the difference is in name only, and that the established best practices for confidential, sensitive or classified data are more mature than newer practices for private data. In the author's view the word "private" carries an emotional appeal that implies a protection the data does not have, and some private-data disclosure mechanisms work against confidential-data best practice. It then sets out a three-party model. The first party is the source of the data, the second party the intended recipient, and a third party any recipient who was not intended. Once data reaches a second party, no technology by itself can restrict what that party does with it. The only protections are economic, legal and regulatory: non-disclosure agreements, regulations imposing a duty of loyalty on the recipient, the risk of enforcement, and loss of reputation. The model extends to downstream parties through chain-link confidentiality or chain-link data loyalty agreements, which make permitted downstream recipients effectively second parties. The paper says this framing exposes de-identification of shared data as a way of escaping those obligations. A section on best practices treats confidential data protection as risk management for both first and second parties, since leaks may come from mismanagement or from a breach, and some shar… |
| research/papers/papers-acdc-ipex-negotiation | ACDC IPEX Negotiation | summary | v0.1 — 2026-10-15: drafted by Claude from the PDF in the Papers repository; unread by Mark; marked partner on Mark's word 2026-10-21, paraphrase only | partner | 600 | # ACDC IPEX Negotiation **Abstract.** Working design notes on how parties negotiate graduated disclosure of Authentic Chained Data Containers (ACDCs) under the Issuance and Presentation Exchange (IPEX) protocol, using a composed schema identifier as the credential type and lists of attribute paths to request disclosure. It also clarifies where the issuee identifier sits in aggregate (selectively disclosable) ACDCs and raises open questions on presentation registries in the context of SEDI (State Endorsed Digital Identity). For implementers of ACDC and IPEX. ## Summary The notes compare mechanisms for negotiating graduated disclosure: attribute path lists, aggregate block label lists, metadata ACDCs, schemas and schema decompositions. Negotiating with schema decompositions is judged complicated because attributes appear disjoint in a schema, while in a metadata ACDC attribute paths are not disjoint and can be named with a path string. The proposal is that negotiation use the composed schema as the type: only the schema's Self-Addressing Identifier (SAID) is given, the full schema is assumed cached or attached, attribute paths request the level of partial disclosure, and metadata ACDCs negotiate terms before disclosure. Requesting a simple field discloses all simple fields in its block, with nested blocks disclosed only as their SAIDs; requesting a block discloses the whole subtree. A worked example on a student record shows paths such as `/a/grades/gpa`. The IPEX flow is described as apply, offer (which may imply the same path list and carries a metadata ACDC), agree, and grant, which delivers the uncompacted ACDC at the agreed disclosure level. For chains of ACDCs, a dictionary keyed by schema SAID maps each to its path list; paths may also reach edge and rule sections. Path delimiters could follow CESR (Composable Event Streaming Representation) pathing. A clarifications section states that the issuee field `i` is optional, that an ACDC is either attributive (`a` section) or aggregative (`A` section), that… |
Advanced export
JSON shape: default, array, newline-delimited, object
CREATE TABLE notes (path TEXT PRIMARY KEY, title TEXT, type TEXT, status TEXT, classification TEXT, words INTEGER, body TEXT);