add keri
This commit is contained in:
⧉ infominer
parent
eca6906fcb
commit
73eaa73a33
|
|
@ -0,0 +1,138 @@
|
|||
---
|
||||
date: 2020-11-22
|
||||
title: KERI - Key Event Receipt Infrastructure
|
||||
description: The first truly fully decentralized identity system.
|
||||
excerpt: >
|
||||
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).
|
||||
layout: single
|
||||
permalink: organizations/identity-foundation/keri/
|
||||
canonical_url: 'https://decentralized-id.com/organizations/identity-foundation/keri/'
|
||||
categories: ["Identity Foudation"]
|
||||
tags: ["DIF","KERI","DKMI"]
|
||||
header:
|
||||
image: /images/keri-header.webp
|
||||
teaser: /images/keri-teaser.webp
|
||||
last_modified_at: 2020-11-22
|
||||
---
|
||||
|
||||
[Website](https://keri.one) - [Resources](https://keri.one/keri-resources/) - [GitHub](https://github.com/decentralized-identity/keri) - [Identifiers & Discovery WG](https://identity.foundation/working-groups/identifiers-discovery.html)
|
||||
|
||||
* [KEY EVENT RECEIPT INFRASTRUCTURE (KERI) DESIGN](https://raw.githubusercontent.com/SmithSamuelM/Papers/master/whitepapers/KERI_WP_2.x.web.pdf) Samuel M. Smith Ph.D. v2.54 2020/10/22, v1.60 2019/07/03 [[arXiv](https://arxiv.org/abs/1907.02143)]
|
||||
> 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.
|
||||
* [Decentralized key management](https://raw.githubusercontent.com/SmithSamuelM/Papers/master/whitepapers/10-ssi-key-management.pdf) Sam Smith (Manning)
|
||||
> ● 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)
|
||||
* [UNIVERSAL IDENTIFIER THEORY](https://raw.githubusercontent.com/SmithSamuelM/Papers/master/whitepapers/IdentifierTheory_web.pdf)
|
||||
> 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 (autho- rized) 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-cer- tifying 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 spe- cific identifier couplet of aid|lid. AIDs are provided by the open standard key event receipt infra- structure (KERI) [42]. 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.
|
||||
* [Key Event Receipt Infrastructure (KERI): A secure identifier overlay for the internet – Sam Smith – Webinar 58](https://ssimeetup.org/key-event-receipt-infrastructure-keri-secure-identifier-overlay-internet-sam-smith-webinar-58/) SSI-Meetup
|
||||
|
||||
{% include video id="izNZ20XSXR0" provider="youtube" %}
|
||||
|
||||
## Presentations
|
||||
|
||||
* [KERI Overview](https://raw.githubusercontent.com/SmithSamuelM/Papers/master/presentations/KERI2_Overview.web.pdf) Key Event Receipt Infrastructure Samuel M. Smith Ph.D. sam@keri.one https://keri.oneversion 2.54 2020/10/22
|
||||
> **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.
|
||||
* [The Duplicity Game: or why you can trust KERI](https://raw.githubusercontent.com/SmithSamuelM/Papers/master/presentations/DuplicityGame_IIW_2020_A.pdf)
|
||||
> **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.
|
||||
* [Key Event Receipt Infrastructure (KERI) Model for a Universal DKMI](https://raw.githubusercontent.com/SmithSamuelM/Papers/master/presentations/KERI_Overview.pdf) - December 2019
|
||||
> **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 for Muggles IIW #31 Day 1 - Session #220 October 2020](https://raw.githubusercontent.com/SmithSamuelM/Papers/master/presentations/KERI_for_Muggles.pdf)
|
||||
> 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
|
||||
* [Verifiable Trust Bases](https://raw.githubusercontent.com/SmithSamuelM/Papers/master/presentations/KERIVerifiableTrustBases.web.pdf) Samuel M. Smith Ph.D. sam@keri.one https://keri.one version 2.53 2020/10/20 - Renewing the Web of Trust
|
||||
> * 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.
|
||||
|
||||
## GitHub
|
||||
- [decentralized-identity/keri](https://github.com/decentralized-identity/keri) - Key Event Receipt Infrastructure - the spec and implementation of the KERI protocol
|
||||
- [KERI Whitepaper](https://raw.githubusercontent.com/decentralized-identity/keri/master/kids/KERI_WP.pdf)
|
||||
- [Implementation Notes for KERI](https://github.com/decentralized-identity/keri/blob/master/implementation.md) [[HackMD](https://hackmd.io/orhyiJkLT721v4PCPkvQiA?both)]
|
||||
> The interpretation of the data associated with the digest or hash tree root in the seal is independent of KERI. This allows KERI to be agnostic about anchored data semantics. Another way of saying this is that seals are data agnostic; they don’t care about the semantics of its associated data. This better preserves privacy because the seal itself does not leak any information about the purpose or specific content of the associated data. Furthermore, because digests are a type of content address, they are self-discoverable. This means there is no need to provide any sort of context or content specific tag or label for the digests. Applications that use KERI may provide discovery of a digest via a hash table (mapping) whose indexes (hash keys) are the digests and the values in the table are the location of the digest in a specific event. To restate, the semantics of the digested data are not needed for discovery of the digest within a key event sequence.
|
||||
- [decentralized-identity/keriox](https://github.com/decentralized-identity/keriox) - Rust Implementation of the KERI Core Library
|
||||
- [decentralized-identity/keripy](https://github.com/decentralized-identity/keripy) - Python Implementation of the KERI Core Libraries
|
||||
- [decentralized-identity/kerigo](https://github.com/decentralized-identity/kerigo) - Go implementation of KERI (Key Event Receipt Infrastructure)
|
||||
- [decentralized-identity/kerijs](https://github.com/decentralized-identity/kerijs) - JavaScript (nodes) Implementation of the KERI core library.
|
||||
|
||||
## Background
|
||||
|
||||
* [Resources](https://keri.one/keri-resources/)
|
||||
- [SmithSamuelM/Papers](https://github.com/SmithSamuelM/Papers/)
|
||||
* [Whitepapers](https://github.com/SmithSamuelM/Papers/tree/master/whitepapers)
|
||||
* [Presentations](https://github.com/SmithSamuelM/Papers/tree/master/presentations)
|
||||
|
||||
**Self-Certifying Identifiers**
|
||||
* Girault, M., “[Self-certifiepublic keys](https://link.springer.com/content/pdf/11007%2F3-540-46416-6_42.pdf),” EUROCRYPT 1991: Advances in Cryptology, pp. 490-497, 1991
|
||||
* Kaminsky, M. and Banks, E., “[SFS-HTTP: Securing the Web with Self-Certifying URLs](https://pdos.csail.mit.edu/~kaminsky/sfs-http.ps),” MIT, 1999
|
||||
* Mazieres, D. and Kaashoek, M. F., “[Escaping the Evils of Centralized Control with self-certifying pathnames](http://www.sigops.org/ew-history/1998/papers/mazieres.ps),” MIT Laboratory for Computer Science, 2000
|
||||
* Mazieres, D., “[Self-certifying File System](https://pdos.csail.mit.edu/~ericp/doc/sfs-thesis.ps),” MIT Ph.D. Dissertation, 2000/06/01
|
||||
* TCG, “[Implicit Identity Based Device Attestation](https://trustedcomputinggroup.org/wp-content/uploads/TCG-DICE-Arch-Implicit-Identity-Based-Device-Attestation-v1-rev93.pdf),” Trusted Computing Group, vol. Version 1.0, 2018/03/05
|
||||
|
||||
**Autonomic Identifiers**
|
||||
|
||||
Smith, S. M., “[Open Reputation Framework](https://github.com/SmithSamuelM/Paperblob/master/whitepapers/open-reputation-low-level-whitepaper.pdf),” vol. Version 1.2, 2015/05/13
|
||||
Smith, S. M. and Khovratovich, D., “[Identity System Essentials](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/Identity-System-Essentials.pdf),” 2016/03/29
|
||||
* Smith, S. M., “[Decentralized Autonomic Data (DAD) and the three R’s of Key Management](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/DecentralizedAutonomicData.pdf),” Rebooting the Web of Trust RWOT 6, Spring 2018
|
||||
* Smith, S. M., “[Key Event Receipt Infrastructure (KERI) Design and Build](https://arxiv.org/abs/1907.02143),” arXiv, 2019/07/03
|
||||
* Conway, S., Hughes, A., Ma, M. et al., “[A DID for Everything](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/A_DID_for_everything.pdf),” Rebooting the Web of Trust RWOT 7, 2018/09/26
|
||||
* Stocker, C., Smith, S. and Caballero, J., “[Quantum Secure DIDs](https://github.com/WebOfTrustInfo/rwot10-buenosaires/blob/master/final-documents/quantum-secure-dids.pdf),” RWOT10, 2020/07/09
|
||||
|
||||
**Certificate Transparency**
|
||||
|
||||
Laurie, B., “[Certificate Transparency: Public, verifiable, append-only log(https://queue.acm.org/detail.cfm?id=2668154),” ACMQueue, vol. Vol 12, Issue 9, 2014/09/08
|
||||
* Google, “[Certificate Transparency](http://www.certificate-transparency.org/home),”
|
||||
* Laurie, B. and Kasper, E., “[Revocation Transparency](https://www.links.org/files/RevocationTransparency.pdf),”
|
||||
|
||||
### Related
|
||||
|
||||
* [W3C DID Security Concerns](https://github.com/SmithSamuelM/Papers/blob/master/presentations/W3C_DID_Security_Concerns.pdf) 2020/01/14
|
||||
> **Certificate Transparency Solution**
|
||||
> - Public end-verifiable append-only event log with consistency and inclusion proofs
|
||||
> - End-verifiable duplicity detection = ambient verifiability of duplicity
|
||||
> - Event log is third party infrastructure but it is not trusted because logs are verifiable.
|
||||
> - Sparse Merkle trees for revocation of certificates
|
||||
> - (related EFF SSL Observatory)
|
||||
|
||||
**Non Conformist Innovation Summit Closing Keynote #2 - Sam Smith**
|
||||
|
||||
The Economics of Its & Bits - Digital Identity - Freedom Privacy Control Security
|
||||
|
||||
{% include video id="L82O9nqHjRE" provider="youtube" %}
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 4.8 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 1.9 KiB |
Loading…
Reference in New Issue