8E/ KERI and/or Ledger?

KERI and/or Ledger (Part 2)

Session Convener: Richard Esplin

Notes-taker(s): Richard Esplin

Tags / links to resources / technology discussed, related to this session:

Continuation of the discussion in Session 5 Breakout K.

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

Intro

I need to advise my clients on when, if ever, they should use a distributed ledger. And I need to advise my clients on when, if ever, they should use DID:KERI or other ledgerless DID method.

In our discussion yesterday, we listed some reasons to prefer a ledger to alternatives such as KERI and Orb. These reasons each leverage the fact that ledgers contain a publicly auditable history.

We continued the discussion at dinner yesterday, and we learned that the KERI event log is sufficient to meet many of these use cases. So I’m back to wondering how to advise my clients.

What is a blockchain? KERI uses a BFT consensus mechanism to ensure that witnesses and watchers have a common understanding of the current state of the event log. But each collection of witnesses store their own chain of events. The Key Event Log (KEL) for each DID is like a blockchain which only allows a single author. The witness pool is a set of nodes that manages multiple KELs.

The relevant characteristic for this conversation is that blockchains have shared data and shared governance.

Conclusion

It doesn’t have to be an either / or. Often customers will use KERI to store DIDs on a ledger.

Customers should use KERI when they are concerned about ledger independence.

• did:keri lets you store DIDs on any ledger or no ledger, and you can migrate DIDs between ledgers without having to reissue credentials.
• did:keri is a protocol, and not a storage format. It might be easier to get an ecosystem to standardize on a protocol, and you don’t have to argue about which blockchain is the best.

You get these benefits with an increase in complexity that is largely encapsulated within open source libraries such as those provided by GLIEF.

Customers should prefer KERI when they are suspicious about ledgers.

• KERI witnesses can be hosted in cloud infrastructure, and not require any ledger. This avoids the conversation about web3, ledgers, tokens, and regulatory concerns.

Customers should use a ledger (maybe with did:keri) if they don’t want to setup their own witnesses or watchers.

• Or they could use a public watcher network (once one exists).

Customers should use a ledger (maybe with did:keri) when they need to leverage other ledger capabilities beyond DID Docs, Revocation Registries, and Service Endpoints.

• Smart contracts (often for automated ecosystem governance)
• Token incentivizes
• Payments

If your ecosystem has already settled on a ledger, then KERI might not be worth using.

Other findings

KERI and Orb were both created to solve “the ledger adoption problem”. Many organizations are hesitant to adopt a ledger, and those that are willing need to agree on which of the many options they will use.

KERI solves this problem by creating a protocol that has many of the aspects of a ledger. But as a protocol, it is more flexible. Each protocol instance can have its own governance framework.

• KERI consensus can be simpler because the DID controller is the only writer.

However, KERI does introduce some of the complexity that a blockchain already addresses.

• Our community needs more cryptographers and security people to help audit protocols and how we use ledgers.

KERI is vulnerable to “eclipse attacks” where the attacker prevents the client from seeing part of the network when making a query. But so are ledgers.

It is expected that people will create networks of watchers (super watchers) who publicly monitor as many KELs as possible in order to detect duplicity.

• This would be similar to services like the SSL Certificate Transparency Project currently run by Cloud Flare, Google, and others.
• KELs have state proofs, so can provide assurances to clients who are not running their own nodes.

KERI does not allow anchoring an issuer DID on multiple ledgers at a time (that would fork the event tree), but the KEL can be updated to change DIDs from one ledger to another in a serial manner.