DIF KERI

What we build instead

From peer DIDs to KERI

The DIF community has recognized that public DIDs only represent a specific requirement. Peer DIDs probably cover a majority of use cases, and doesn't rely on a blockchain. As a generalization of that idea, DIF KERI is now working on a foundational layer below DIDs, to establish cryptographic trust.

Interesting use cases for KERI beyond medIAM include GLEIF's vLEI and IDNUM.

DIF KERI

KERI starts by providing a generation utility for self certified identifiers (SCID), based on local randomness and public key cryptography. We assume that the machine is able to generate sufficient entropy. The derivation code explains how the key was derived.

In its simplest form, a unique prefix is therefore generated as such:

The choice of one-way hash functions, such as 256 bit (32 byte) Blake2, Blake3 and SHA3, with 128 bits of pre-quantum strength maintain that strength post-quantum. More advanced generation methods may include configuration information or multi-signatures. Then methods exist to rotate the keys. Therefore KERI acts as a decentralized key management system, which can optionally publish information to a ledger.

Consensus (case 1-to-any IDs)

DIF KERI also builds on the realization that while a public ledger can be useful to anchor verifiable public keys, the underlying consensus mechanism doesn't need to protect against double spends, as is the case for cryptocurrencies and therefore most blockchain projects. Here, KERI trades off liveness for safety and portability.

A more advanced discussion was held on that topic: https://github.com/decentralized-identity/keri/issues/94 (which would require a more formal analysis, but that's beyond the medIAM project). It should be noted that the implementation of the consensus layer still needs to be done (out of scope of this project).

Example uses

DIF KERI is used to manage keys in the bootloader prototype, and in the GNAP protocol.

Last updated