KERI - Key Event Receipt Infrastructure
Main
- KERI One - HomePage From: WebofTrust Type:
- KERI Q&A basic introduction From: Blockchain Bird Type: Presentation Date: 2021 Event: IIW32
- Key Event Receipt Infrastructure: A Secure Identifier Overlay for the Internet From: personal By: Samuel Smith Type: Presentation Date: 2021-03-23
- KEY EVENT RECEIPT INFRASTRUCTURE (KERI) DESIGN By: Samuel Smith Type: Date: 2020-10-22
- Decentralized key management By: Samuel Smith Related: Manning Type: Date: 2020-10-19
- UNIVERSAL IDENTIFIER THEORY By: Samuel Smith Type: Date: 2020-10-23
- KERI Whitepaper From: DIF Type: Date: 2021-01-11
It has lots of relevant links in it to start your journey in KERI.
What is KERI?
* Key Event Receipt Infrastructure
* Intends to repair the Internet
* KERI = CT with decentralized CA
* NOT a coin, token…
Why KERI? (and not something else)
* Strong autonomous identifiers
* Abiding to privacy (laws and good habits)
* Portability, delegation, rotatable keys
* Direct & Indirect method
* <there’s more>
Secure attribution of any communication to its source
Authentic communication
Authentic interactions based an secure attribution of all statements by participants
Verifiable authenticity of data
Data Provenance
Authentic data economy
An identity system based secure overlay for the Internet is presented. This includes a primary root-of-trust in self-certifying identifiers. It presents a formalism for Autonomic Identifiers (AIDs) and Autonomic Namespaces (ANs). They are part of an Autonomic Identity System (AIS). This system uses the design principle of minimally sufficient means to provide a candidate trust spanning layer for the internet. Associated with this system is a decentralized key management infrastructure (DKMI). The primary root-of-trust are self-certifying identifiers that are strongly bound at issuance to a cryptographic signing (public, private) key-pair. These are self-contained until/unless control needs to be transferred to a new key-pair. In that event an append only chained key-event log of signed transfer statements provides end verifiable control provenance. This makes intervening operational infrastructure replaceable because the event logs may be therefore be served up by ambient infrastructure. End verifiable logs on ambient infrastructure enables ambient verifiability (verifiable by anyone, anywhere, at anytime). The primary key management operation is key rotation (transference) via a novel key pre-rotation scheme. Two primary trust modalities motivated the design, these are a direct (one-to-one) mode and an indirect (one-to-any) mode. In the direct mode, the identity controller establishes control via verified signatures of the controlling key-pair. The indirect mode extends that trust basis with witnessed key event receipt logs (KERLs) for validating events. The security and accountability guarantees of indirect mode are provided by KERIs Agreement Algorithm for Control Establishment (KACE) among a set of witnesses.
● Why any form of digital key management is hard
● Standardsand best practices for conventional key management
● The starting point for key management architectures: roots-of-trust
● The special challenges of decentralizedkey management
● The new tools that verifiable credentials (VCs), decentralized identifiers (DIDs), and self-sovereign identity (SSI) bring to decentralized key management
● Key management for ledger-based DID methods
● Key management for peer-based DID methods
● Fully autonomous decentralized key management with Key Event Receipt Infrastructure (KERI)
Abstract—A universal theory for identifiers is presented. This theory is based on a unified model of identifiers that include cryptographic autonomic identifiers (AIDs) and legitimized (authorized) human meaningful identifiers (LIDs). This model provides truly decentralized trust bases each derived from the cryptographic root-of-trust of a given AID. An AID is based on a self-certifying identifier (SCID) prefix. Self certifying identifiers are not human meaningful but have strong cryptographic properties. The associated self-certifying trust basis gives rise to a trust do- main for associated cryptographically verifiable non-repudiable statements. Every other type of identifier including human meaningful identifiers may then be secured in this resultant trust do- main via an end-verifiable authorization. This authorization legitimizes that human meaningful identifier as an LID though its association with an AID. The result is a secured trust domain specific identifier couplet of aid|lid. AIDs are provided by the open standard key event receipt infrastructure (KERI). This unified model provides a systematic methodology for the design and implementation of secure decentralized identifier systems that underpin decentralized trust bases and their associated ecosystems of interactions.
About
- KERI: For every DID, a microledger From: DIF Type: Post Date: 2020-10-19
- KERI Composable Event Streaming Representation From: personal By: Samuel Smith Type: Presentation Date: 2021-03-04
- On KERI: a way not to reveal more personal info than you need to From: Harvard By: Doc Searls Type: Post Date: 2020-10-22
- How KERI tackles the problem of trust From: Jolocom Related: Jolocom Type: Post Date: 2020-10-15
- Tim talks with Sam Smith, creator of KERI From: Definitely Identity Related: Samuel Smith Type: Episode Date: 2020-10-08
- Thinking of DID? KERI On From: Human Colossus Foundation Type: Post Date: 2021-01-27
The world of digital identifiers (DIDs) and verifiable credentials (VCs) is evolving quickly, giving much cause for optimism. Standards are starting to connect and move towards functional interoperability, governed by testable protocols. Most of this work is happening on the level of VCs. However, DIDs and their infrastructure are also starting to converge and mature as an extensible-yet-interoperable technology.
The Three KERI Security Sessions presented at IIW32 have the same set of Slides, it takes 3 hours to get through them.
This session is slides #190 through #208
Here in civilization we typically reveal information about ourselves to others on a need-to-know basis: “I’m over 18.” “I’m a citizen of Canada.” “Here’s my Costco card.” “Hi, I’m Jane.” We may or may not present credentials in these encounters. And in most we don’t say our names. “Michael” being a common name, a guy called “Mike” may tell a barista his name is “Clive” if the guy in front of him just said his name is “Mike.” (My given name is David, a name so common that another David re-branded me Doc. Later I learned that his middle name was David and his first name was Paul. True story.)
In contrast to blockchain or central registry-based trust systems, KERI is based on a hash-chain data structure called a ‘key event receipt log’ (KERL). Conceptually, it’s similar in some ways to the Peer DID Method specification, except that its data model is a KERL rather than a DID document. And while KERI can be used as a DID method, it is fundamentally not reliant on any of the DID specifications and can be used in many other contexts as well. In particular, it is also useful for Internet of Things (IoT) networks and other security-conscious, low-resource use cases.
In this episode, we explore the Key Event Receipt Infrastructure (KERI)and how it relates to decentralized identity. We also touch topics in the white paper: trust domains, self-certifying identifiers, architectural implications, and more.
The current generation of DIDs has introduced an innovative approach to digital identifiers, which has triggered the SSI movement. However, the inclusion of the method space in the DID syntax has led to fragmentation and weak security properties of the identifier type. These known method-space issues give the community impetus to redress them. In light of these innovative developments, now is the time to embrace KERI as an improved interoperable and secure solution for digital identity.
Organization
- LEI Digital Strategy From: GLEIF Type: Post Date: 2022-06-08
- GLEIF vLEI with KERI From: IDCommons Related: GLEIF Type: Session notes Date: 2021-05-07 Event: IIW
- ACDC (Authentic Chained Data Container) Task Force From: TOIP Type: Page Date: 2021-01-19
- Trusted Computing Group Type: Site
- What is DICE architecture? From: Micro Controller Tips By: Maria Guerra Type: Faq Date: 2018-07-27
The Global LEI System (GLEIS) has a unique opportunity to solve the problem of trust for legal entities on a global scale. It can enable digital transformation in a way that is interoperable, independent and autonomous. As a regulatory endorsed system overseen by the Regulatory Oversight Committee (ROC), the GLEIS is the only system that establishes a recognized, monitored and standardized global identity for legal entities that, whenever possible, is linked to the national ID system in that jurisdiction. The system is underpinned by open data, meaning any person or company can access the LEI and its associated reference data. The GLEIS also bridges traditional and online processes by serving as a tool to identify the counterparty in any transaction and can aggregate data on legal entities held in repositories.
GLEIF’s digital strategy for the LEI centers on two methods for cryptographically binding the LEI to its organization – digital certificates and Verifiable Credentials.
The Global Legal Entity Identifier Foundation (GLEIF) proposes that the Legal Enitity Identifier (LEI) can be used to establish a chain of trust for organizational identity.
In this session, GLEIF shares plans and progress regarding its development program to create an ecosystem and credential governance framework, together with a technical supporting infrastructure, for a verifiable LEI (vLEI), a digitally verifiable credential containing the LEI.
The purpose of the Authentic Chained Data Container (ACDC) Task Force is to help draft and incubate a family of IETF-focused specifications that defines the standard requirements for the semantics of Authentic Chained Data Containers. The semantics of ACDCs include both source provenance and authorization provenance or delegation. The hypothesis is that the W3C Verifiable Credential standard may be expanded to serve as an Authentic Data Container (ADC) with authentic provenance chains (APC) as a super semantic. This may be further expanded to support both a source provenance sub-semantic and a delegated authorization sub-semantic. These are all encapsulated into the semantics with supporting syntax of an ACDC.
The Trusted Computing Group (TCG) is a not-for-profit organization formed to develop, define and promote open, vendor-neutral, global industry specifications and standards, supportive of a hardware-based root of trust, for interoperable trusted computing platforms.TCG’s core technologies include specifications and standards for the Trusted Platform Module (TPM), Trusted Network Communications (TNC) and network security and self-encrypting drives. TCG also has work groups to extend core concepts of trust into cloud security, virtualization and other platforms and computing services from the enterprise to the Internet of Things.
DICE stands for Device Identifier Composition Engine, and it is a security standard created by the Trusted Computing Group (TCG) which has been addressing security issues for years. TCG announced the establishment of DICE Architecture, or DICE Architecture Work Group to address the need for increased security in the Internet of Things (IoT) therefore targeting products such as MCUs and systems on a chip (SoCs).
Presentations
- Key Event Receipt Infrastructure (KERI): A secure identifier overlay for the internet – Sam Smith – Webinar 58 From: SSI-Meetup Type: Date: 2020-05-19
- KERI Overview By: Samuel Smith Type: Date: 2020-10-22
- The Duplicity Game: or why you can trust KERI By: Samuel Smith Type: Date: 2020-05-09
- Key Event Receipt Infrastructure (KERI) Model for a Universal DKMI By: Samuel Smith Type: Date: 2019-12
- KERI for Muggles IIW #31 Day 1 - Session #220 October 2020 By: Samuel Smith Type: Date: 2020-10-21
- Verifiable Trust Bases By: Samuel Smith Type: Date: 2020-10-20
- KERI enables cryptographic proof-of-control-authority (provenance) for each identifier.
* A proof is in the form of an identifier’s key event receipt log (KERL).
* KERLs are End Verifiable:
* End user alone may verify. Zero trust in intervening infrastructure.
* KERLs may be Ambient Verifiable:
* Anyone may verify anylog, anywhere, at anytime.
* KERI = self-cert root-of-trust + certificate transparency + KA2CE + recoverable + post-quantum.
Separation of Control Shared (permissioned) ledger = shared control over shared data.
* Shared data = good, shared control = bad.
* Shared control between controller and validator may be problematic for governance, scalability, and performance.KERI = separated control over shared data.
* Separated control between controller and validator may provide better decentralization, more flexibility, better scalability, lower cost, higher performance, and more privacy at comparable security.
Inconsistency vs. Duplicity
- inconsistency: lacking agreement, as two or more things in relation to each other
- duplicity: acting in two different ways to different people concerning the same matter
Internal vs. External Inconsistency
- Internally inconsistent log = not verifiable.
- Log verification from self-certifying root-of-trust protects against internal inconsistency.
Externally inconsistent log with a purported copy of log but both verifiable = duplicitous.
Duplicity detection protects against external inconsistency.
KERI Nomenclature
* self-certifying identifier: includes public key
* digital signature: unique non-repudiable (cypher suite known)
* digest: collision resistant hash of content
* signed digest: commitment to content
* controller: controlling entity of identifier
* message: serialized data structure event: actionable message
* key event: key management operation
* inception event: unique self-signed event that creates identifier and controlling key(s)
* rotation event: self-signed uniquely ordered event from a sequence that changes the set of controlling keys
* verifier: cryptographically verifies signature(s) on an event message.
* witness: entity that may receive, verify, and store key events for an identifier. Each witness controls its own identifier used to sign key event messages, controller is a special case of witness.
* receipt: event message or reference with one or more witness signatures
* key event log: ordered record of all self-signed key event messages key event
* receipt log: ordered record of all key event receipts for a given set of witnesses
* validator: determines current authoritative key set for identifier from at least one key event (receipt) log.
* judge: determines current authoritative key set for identifier from the key event receipt logs from a set of witnesses.
* pre-rotation: commitment to next rotated key set in previous rotation or inception event
KERI is a new approach to decentralized identifiers and decentralized key management that promises significant benefits for SSI (self-sovereign identity) and ToIP (Trust over IP) infrastructure
Self-Certifying Identifiers
- Self-certifiepublic keys From: Springer By: Girault, M. Type: Date: 1991 Event: EUROCRYPT 1991
- SFS-HTTP: Securing the Web with Self-Certifying URLs From: MIT By: Kaminsky M., Banks E. Type: Date: 1999
- Escaping the Evils of Centralized Control with self-certifying pathnames From: Sigops By: Mazieres D., Kaashoek M. F. Related: MIT Type: Date: 2000
- Self-certifying File System From: CSAIL By: Mazieres D. Type: Date: 2000-06-01
- Implicit Identity Based Device Attestation From: Trusted Computing Group Type: Date: 2018-03-05
Autonomic Identifiers
- Open Reputation Framework By: Samuel Smith Type: Date: 2015-05-13
- Identity System Essentials By: Samuel Smith, Khovratovich D. Type: Date: 2016-03-29
- Decentralized Autonomic Data (DAD) and the three R’s of Key Management By: Samuel Smith Type: Date: 2018-05-23
- Key Event Receipt Infrastructure (KERI) Design and Build From: arXiv By: Samuel Smith Type: Date: 2019-07-03
- A DID for Everything By: Conway S, Hughes A Type: Date: 2018-09-26 Event: RWOT 7
- Quantum Secure DIDs From: WeboftrustInfo By: Stocker C, Samuel Smith, Juan Caballero Type: Date: 2020-07-09 Event: RWOT10
Rebooting the Web of Trust RWOT 6, Spring 2018
Certificate Transparency
- Certificate Transparency: Public, verifiable, append-only log From: ACMQueue By: Ben Laurie Type: Date: 2014-09-08
- Revocation Transparency From: Links By: Ben Laurie, Emilia Kasper Type: Date: 2015
Assorted
- Non Conformist Innovation Summit Closing Keynote #2 - Sam Smith By: Steve Tout Type: Date: 2020-07-23
- Supply chain – ACDC and KERI + DEMO From: IDCommons By: Robert Mitwicki Type: Session notes Date: 2021-05-07 Event: IIW
- KERI: Facilitating secure data flows in an auditable supply chain From: personal By: Robert Mitwicki Type: Presentation Date: 2020-10-10
The Economics of Its & Bits - Digital Identity - Freedom Privacy Control Security
Authentic Chain Data Containers (ACDC) - is a technology which allows to secure and chain data in a generic way. It aims to improve the way we do VC and how we think about authentic data.
After explanation of ACDC, a demo was performed where it was shown how KERI can enable authentic data flow within the supply chain without the need of having any blockchain nor one single network.
Supply Chain and why you need Blockchain
- Time-stamping, tracking, and automating transactions, so that events can be audited in real time
- Minimizing the involvement of intermediaries such as bankers, insurers, and brokers
- Setting up a wide range of self-executing contracts to automate repetitive processes such as billing and shipping
- Establishing proof of quality, provenance, payment, and performance to minimize counterfeiting and fraud
- Making it easier, faster, and cheaper to onboard new vendors and partners by assigning digital IDs
Supply Chain and why you DON’T want Blockchain
- Lack of Interoperability - my ledger vs someone else ledger, how to bridge it and navigate
- Problem with Governance Framework - who decided who can join?
- Scaling
- Privacy