12H/ KERI for Muggles - A basic intro to KERI IDs & key mgmt

From IIW

KERI for Muggles - A Basic Intro to KERI IDs & Key Management

Wednesday 12H

Convener: Drummond Reed & Sam Smith

Notes-taker(s): Trent Larson

Tags for the session - technology discussed/ideas considered:

KERI, identifier management, 101

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps

Presentation slides are here.

https://docs.google.com/presentation/d/1lpzYcPrIox9V4hERtn4Kcf7uq01OVU9u3PuVm1aYzR0/edit#slide=id.ga411be7e84_0_0

Aiming at 7 basic points in this talk. Go to KERI.one for everything. Summarized in one chapter from SSI Book https://www.manning.com/books/self-sovereign-identity

Sam developed this approach to fill in the trust layer of the internet, even between systems. White Paper

The python implementation of KERI can be found at https://github.com/WebOfTrust/keripy

... and the draft IETF spec will be published at https://github.com/WebOfTrust/keri

Point #1: It's based on public-private key pairs and self-certifying identifiers (SCIDs).

DID is a namespace. SCID is a type of DID. SAID is not a SCID, it's a content-addressable ID. (You could make a SCSAID.)

Benefit #1 - You can prove control of a KERI ID without relying on any external source (including blockchains)

Point #2: Self-Certifying Key Event Logs: keep a log of all keys, including rotated keys (which you might create ahead-of-time)

Benefit #2: You can again prove control of that key without relying on an external service.

Point #3: Witnesses for Key Event Logs: as you sign your key log events, you can have witnesses sign to record/attest those events.

Benefit #3: Witnesses provide additional evidence that the originator is consistent: both tamper- & duplicity- evident

Point #4: Pre-rotation as simple, safe, scalable protection against key compromise: KERI alone can't protect against compromised private keys, stolen by someone, but it allows for throwing away old keys.

- Log a whole series of public keys in your Key Event Log (KEL).

- Go into vault and get a private key & use it.

- Ack: someone stole it!

- Declare that key as compromised, go back into the vault and get the next private key (whose public key was already published in the Key Event Log) and use that from now on (either until the next compromise, or maybe you rotate on a regular basis).

Benefit #4: You can lock away your next private key, and have a provable path for use of the next keys

The key protection is post-quantum proof. A hash is published, not the actual public key.

Point #5: System-Independent Validation. There is no restriction on the number of logs.

Benefit #5: These IDs & keys are not ledger-locked, fully portable, and validated in multiple ways

Point #6: Delegated self-certifying identifiers, even for enterprise management. Keys can be delegated.

Benefit #6: Enterprises can scale and manage delegation hierarchies of any size & complexity

Point #7: KERI is compatible with GDPR "right to be forgotten"

When a DID is written to a public immutable ledger then that's a problem but KERI allows for erasure. Use witnesses that allow mutability.

Benefit #7: Doesn't require immutable ledgers.

---

The identity system on top of KERI has to manage things like whether you want the IDs to be private (not on blockchain!) or public.

Tim says that KERI helps with provable control... much like proof you own your email or phone with temporary links or Google Auth. We can now have provable control of our private keys.

There are two KERI sessions following this:

- Sam on "Privacy Authenticity Confidentiality Tradeoffs: KERI and Zero Trust Architecture"

- Phil on "Practical Intro to KERI: What can you do today?"