Key Event Receipt Infrastructure - the spec and implementation of the KERI protocol
Back to table of contents |Link|Commentary|Section |—|—|—| |0000|X|Glossary, overview, how to use| |0001|X|Prefixes, Derivation and derivation reference tables| |0002|X|Data model (field & event concepts and semantics)| |0003|X|Serialization| |0004|X|Key Configuration (Signing threshold & key set)| |0005|X|Next Key Commitment (Pre-Rotation)| |0006|X|Seals| |0007|X|Delegation (pending PR by Sam)| |0008|X|Key-Event State Machine| |0009|X|Indirect Mode & Witnesses| |0010||Recovery/consensus Algorithm (KAACE)| |0010||Database & Storage Considerations| |0097|n/a|Non-Normative Implementation Guidance| |0098|n/a|Use Cases| |0099|n/a|Test Vectors and Normative Statement Index|
A statement that includes the inception data with attached signature made with the private key comprises a cryptographic commitment to the derivation and configuration of the identifier that may be cryptographically verified by any entity that receives it.
No additional infrastructure is needed or more importantly must be trusted in order to verify the derivation and initial configuration (inception) of the identifier. It is completely self-contained. The initial trust basis for the identifier is the signed inception statement. A diagram of a basic inception statement is shown below:
Minor points
Inception, self-certfying identifiers, derivation code,
Practical use of a self-certifying identifier may (will?) require some initial configuration data (inception data).
The inception data is formally represented in a signed inception statement.
Inception data MUST include:
Identifier derivation MAY be represented by the derivation code (see: Derivation Code)
and MAY include: