2E/ KERI for Muggles

KERI for Muggles

Tuesday 2E

Convener: Drummond Reed

Notes-taker(s): Ajay Jadhav,

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

LINK TO THE “KERI FOR MUGGLES” SLIDES SHOWN IN THIS SESSION - https://docs.google.com/presentation/d/1lpzYcPrIox9V4hERtn4Kcf7uq01OVU9u3PuVm1aYzR0/edit?usp=sharing (Note: these are publicly available Google Slides)

KERI:

Self-certifying identifier

No Blockchain needed.

Sam: Binding = derivation

Nuttawut: Is KERI considered a type of decentralized PKI ?

Drummond: Yes, KERI is an entire architecture for decentralized PKI

Binding = There is a secret relationship between the public key and the SCID, and you can prove the relationship only with the knowledge of the private key

The self-certifying identifier is ED25519 like digital signatures and not an hash.

https://jolocom.io/blog/how-keri-tackles-the-problem-of-trust/

KERI uses key event logs like blockchain.

Timothy: It is not a double-spend proof and cannot support a cryptocurrency. It is purely a system for SSI, Identifiers, VCs, etc.

You can prove you control a KERI identifier without needing a to rely on ANYONE outside your control

KERI writes a new digitally-signed message to a log file so you can prove you made the change.

A single KERI identifier may be derived from a set of key-pair so it supports multi-sig

KERI operates in

Direct mode - pair-wise interaction

Indirect mode

David Huseby: Do you consider access control for key event logs?

Not exactly, but In case of privacy, you can encrypt the key event logs and share to only those whom you want to.

KERI is about authenticity - if you want privacy you need to layer it on top of it.

Benefit #2: Each time you change your key KERI writes a digitally-signed message to an “event log” which is a simple type of log file

1.Step:

Self-certifying identifier

can prove to be the one and only identifier tied to public key using cryptography alone (no blockchain needed)

Benefit 1: You can prove you control a KERI identifier without needing a to rely on ANYONE outside your control

2.Step:

Self-Certifying Key Event Logs

Each time you change ("rotate") your public/private key pair, KERI write a new digitally-signed message to a log file so you can prove you made the change

Benefit 2: Each time you change your keys, you can prove you control to

3.Step:

Witnesses Key Event Log

all key events signed by Controller and Witness

Benefit 3: Although witnesses are not required, they provide additional evidence that you control your current public key(s) and are not cheating

4.Step:

Prerotation as simple, safe, scaleable (generate key pairs in wallet, digitally sign a proof of the next public key – write that proof and signature to the event log)

KERI can't prevent theft of your current private key - but it has an ingenious solution for hiding your next private key that makes

recovery control authority through key rotation (ist like a backup – you an identifier having persistent value -> you want to protect and control of the identifier over time)

Benefit 4: You can safely "lock away" your next private key so it can't be stolen from your current device – and protect yourself if your current private key is ever compromised (this key protection post quantum proof)

5.Step:

System independent validation

Because KERI identifiers and event logs are self-certifying, they can be witnessed by any system anywhere that can store and return data – and you use all of them as witnesses

Benefit 5: KERI identifiers and keys are not "ledger-locked" – they are fully portable and can be validated using any ledger, distributed database, or other verifiable data registry

6.Step:

Delegated self certifying identifiers enables enterprise-class key management

KERI identifiers can be "delegated", meaning one identifier can create another one that can prove its relationship with its parent – so you can create any hierarchy of identifiers & keys

Benefit 6: With KERI identifier and key delegation, enterprises can scale and manage delegation hierarchies of any size and complexity

7.Step:

Compatibility with the GDPR "right to be forgotten"

When decentralized identifier for a person is written to an immutable ledger, it can creates a privacy issue because it cannot be erased – but KERI identifiers can use witnesses that permit erasure

Benefit 7: KERI infrastructure can be GDPR-compliant because it does not require the use of immutable ledgers – KERI event logs can be deleted without compromising security