| 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
- Floating-point math SHOULD never be used to calculate thresholds; standard fractional libraries recommended
- Thresholds SHOULD be represented in fractions to insure interop across implementations
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:
- the public key
- the identifier derived from the public key.
Identifier derivation MAY be represented by the derivation code (see: Derivation Code)
and MAY include:
- other configuration data.