Skip to content
This repository has been archived by the owner on Apr 21, 2023. It is now read-only.

Latest commit

 

History

History
764 lines (561 loc) · 70.1 KB

Q-and-A-Security.md

File metadata and controls

764 lines (561 loc) · 70.1 KB

Q&A about KERI's Security model and Guarantees

--- KERI logo --- --- --- --- --- --- --- --- --- ---

This document is part two of Q-and-A. Both files shares a common Glossary that has:

  • an alphabethically ordered list of abbreviations
  • an alphabethically ordered list of definitions

The questions are of a varied level: basic and detailed. The answers are mostly directed towards generally interested people and newbies.
*Q = one star question. Novice to KERI, advanced in DIDs
**Q = two star question. Proficient in DIDs and advanced in KERI
***Q = three star question. Expert in DIDs and proficient in KERI

Why should you read or step through the Q&A? To get a different angle to the same topic: KERI.

{TBW} means: to be written
{TBW prio 1} means to be written with the highest priority, 
3 = no urgency, 2 = intermediate

Inspired by presentation given and questions asked on the SSI webinar May 2020, but also issues raised and the progress made, here on Github (Turn on 'Watch' if you want to be notified of conversations).

Beware: A Q&A is always work in progress. Tips & help welcome.

Disclaimer

None of the respondents in the open repo and presentations have been explicitly named as a source, except for Samuel M. Smith Ph.D. and @henkvancann. If there is no reference added to the answers, then it's Samuel M. Smith who answered the question. Most of the editing is done by @henkvancann, which might have introduced ommission, errors, language glitches and such. Sorry for that, feel free to correct by submitting a pull request (PR).
For practical reasons educational images uploaded by Github members have been downloaded. We de-personalised them by giving images a new name. Under these new names these images have been uploaded to github and used in the Q&A to clarify the questions and answers.

Keri's content is licensed under the CC by SA 4.0. license. Parts of the video offered on SSI Meetup webinar 58 have been captured and uploaded to Github to support the answers to general questions about digital identity and more in depth answers to question about Keri.

We've done our best to protect the privacy of the Github by investigating the images we used. We haven't come across personal identifiable information (pii). However, should we have made a mistake after all, please let us know and we'll correct this immediately.

List of questions and definitions

Table of contents generated with markdown-toc

Knowledge you should be confidently applying

  • The definitions in the glossary
  • The Knowledge you should be confidently applying from part one of the Q-and-A
  • Bitcoin Improvement Protocols: BIP32, BIP39, BIP44, BIP47, BIP49, BIP84, BIP174
  • hierarchical deterministic derivation paths
  • Base58
  • Eliptic curves
  • W3C DIDs thoroughly

Actions you should be comfortable with

  • The Actions you should be comfortable with from part one of the Q-and-A
  • Amend knowledge and keep existing knowledge up to date

Jump table to categories

PART TWO SECURITY

PART ONE

Q&A section KERI security considerations

**Q: As an SSI expert I totally can get stuck in the semantics of KERI. How to overcome this?

If we could sit down with every expert and walk through his concerns, it would change. Our biggest problem is that when we write technical stuff, we are writing for an imagined technical audience that cares about the same things at the same technical level that we care about.

In other words our default audience is ourselves (in the KERI team). It reminds us what we thought at the time of writing. Even if we are writing for a known audience, we can't adapt in real time, because its not interactive so we usually only get it half right, just half convincing, which is as good as nothing in internet security.

But when we talk to people one-on-one we can adapt what we say to match their level of understanding and what they care about. In real time. We can go as deep as needed but no deeper or a broad as needed but no broader.

**Q: Why is KERI so confusing, even for SSI experts?

KERI is confusing because it is new and can' be assumed. Whole books exists and hundreds of papers on "eventual consistency" algorithms (which CouchDB uses) but they are just assumed away. Because KERI is new, I can't just assume it away. But KERI is not magic or scary or anywhere as near as difficult as BFT BA which is assumed away or PoW which is also assumed away. Conversely, most people make assumptions about the security guarantees of DLT that are false. There are many papers on all the known active compromises to Bitcoin that happen on a regular basis yet they assume that they can't happen.

Q&A section KERI operational security

*Q: What is the main component of KERI's security?

Key management is the main component, because every attack on KERI starts with key compromise. There are no other attacks possible because KERI has consistent logs that are cryptographical verfiable to the root-of-trust, also know as the public private key pair used to create the identifier.
(@henkvancann)

**Q: How does KERI guarantee the consistency and security of its logs?

KERI's Key event log (KEL) is a cryptographically verifiable hash chained non-repudiably signed data structure.
(SamMSmith)

**Q: How can it be one solution, fit for all SSI problems?

KERI uses plain old digital signatures from PKI, intentionally, so that it may be truly universally applied. KERI solves that hard problem of PKI, that is, key rotation in a standard way. Without a standard way of addressing key rotation, there is no interoperability between systems, they break when you rotate keys because no one knows how to verify the key rotation was done properly. KERI solves that problem.
(SamMSmith)

*Q: Where would you need something quite different than KERI?

KERI does one thing, it establishes control authority using verifiable portable proofs that are KELs.\

Liveliness

If you need liveliness of fungible trust, like cryptocurrencies, you can't use KERI for this.\ In KERI we have compact security for the sake of liveliness, whick means there is no public ledger with total ordering of state. In KERI after duplicity is detected, you don't trust that identifier anymore. That means in KERI you don't have fungible trust. And that is a good thing for trust. (SamMSmith)

*Q: Does KERI protect a controller against stupid mistakes?

If a controller of a public identifier has a KEL published and with the same authorotative keypair produces another KEL and does not check it's inconstent with the first one? No, KERI does not protect against that level of stupidity. By comparison, public ledger based identity systems do protect against this stupidity. (SamMSmith)

***Q: KERI is inventing its own key representation and signature format. Why did you do that?

(@OR13) argues the following:
In order to share code / we would need shared building blocks. Sidetree is built on JWS / JWK. KERI is inventing its own key representation and signature format. These are the lowest level building blocks, so them being different will prevent a lot of potential code reuse.

In brief these are the reasons:

  • the desire to control the entire stack, and not use anyone else's tooling
  • DID and VC layers are the appopriate layers for interopability
  • The performance/security goals of KERI drive its design which makes incompatible with Linked Data tooling

***Q: Why did KERI WG decide to reinvent multicodec?

(@OR13) argues the following:
There was a potential for KERI to align with Ceramic / IPFS / IPLD, but that door closed when the KERI WG decided to reinvent multicodec.

The desire to control the entire stack, and not use anyone else's tooling

Have a look at the Kid0001Comment Summary for why we needed to divert from multicodec. Multicodec may not be such a stable standard to be breaking or abandoning.

Multicodec is a draft standard, a rather chaotic mix of binary and text-based entries in a crowd-sourced registry/table. Most implementers are doing a subset of the Multicodec chart anyways, making it even more unstable for interoperability purposes.

To go in further detail why multicodec can't do for KERI: the length of item not included in encoding table - incompatible structure (Multicodec assumes enveloped data structure) Moreover we need KERI's composability (via concatenation) for framing events.

DID and VC layers are the appopriate layers for interoperability

  • streaming support > interop at signature layer?

The performance/security goals of KERI drive its design which makes incompatible with Linked Data tooling

KERI can't use enveloped data formats:

  • enveloped data format -> signatures have to put on/outside the payload
  • MsgPack and CBOR-> work with block-delimited structures
  • JWS/JWK - also enveloped, also incompatable with streaming
  • framing events = better streaming support (@by_caballero and @henkvancann)

*Q: Will KERI be interoperable with DID:peer and Sidetree?

You can implement did;peer and Sidetree with KERI but we can’t implement KERI with Sidetree or did:peer.
Because KERI operates on a lower level.
If we were to do that, we have to tunnel KERI identifiers to create corresponding Ledger-entries.
(SamMSmith)

***Q: Will KERI be interoperable with DID:peer and Sidetree?

(@OR13) argues the following:
Afaik this ship sailed when KERI decided to define its own event format. I don't think KERI shares any commonality with sidetree or did peer, and it's no longer possible to align them, so while you can start with the same key material, doing similar operations will very quickly result in totally different event structures.

I don't see a way for KERI events to be used by anything but KERI for now, certainly not Sidetree. In the future did:peer might use KERI events directly, but then did:peer would not be Sidetree compatible

...

The upside is that KERI could be much better than things built on JOSE. The down side is KERI won't be possible to implement with off the shelf JOSE crypto. Having spent a lot of time with linked data, It looks like KERI is setup to feel all the same kind of pain, regarding reinventing the wheel instead of starting with compatibility with JOSE.

...

I predict a few years from now we will have:

A. JOSE / JWS / JWK / jose based DIDs
B. Multicodec / IPFS / IPLD / DAG_CBOR / JWS / JWK / ipld based DIDs
C. Linked Data / JSON-LD / CBOR-LD / linked data based DIDs
D. KERI / KERI keys / KERI signatures / keri event log based DIDs

There will be some overlap, for example KERI based DID Documents will likely support JWKs if they want to be useful with any legacy system, but internally KERI will use a different key representation. Similarly sidetree based dids will likely support linked data proofs but will only rely on JWS / JWK for internal operations.

As far as I know, the KERI design has specifically chosen not to build on JOSE, IPLD. or JSON-LD / CBOR-LD. So there won't be any opportunity for interop with KERI below the DID Document layer. Which is true of many other systems, including Ethereum, Bitcoin, Hyperledger based DIDs. Many of which don't share event log interopability.

Imo, if KERI used IPLD / JSON-LD / CBOR-LD, it would be better. Because not using them means reinventing the parts of them that are needed... which comes with the potential for better performance at the cost of inventing a faster wheel, and failing to pull developers / tooling from those established communities. However I can understand the desire to control the entire stack, and not use anyone else's tooling.

From an engineering management and interopability perspective, I would have decided to break compatibility after the whole system was built and working, and only in the areas where JWS / JWK or IPLD performance, documentation or library support was so bad it was justified.

... We should target interop between KERI and Sidetree at the DID Core and VC Data Model layer.
End of (@OR13)'s plea.

The DID and VC layers are the appopriate layers for interopability. The performance/security goals of KERI drive its design which makes incompatible with Linked Data tooling.
(SamMSmith)

**Q: How does KERI keep identifiers secure?

By the mechanism of availability, consistency, and duplicity.
We have to handle race conditions too, just like any other distributed database or blockchain.
(SamMSmith)

**Q: How does KERI scale safely without comprising the security model

Safe scaling: is everything more secure as more witnesses and more watchers are added?

Watchers and witnesses have two separate effects;

  1. Ambient verifiable requires even distribution (and total coverage) of watchers to detect duplicity; the more, the better
  2. Enough watchers allow a lower threshold of witnesses that need to stay honest - each controller sets a ratio of witnesses that need to confirm an event, if each of the witnesses is watched enough, the security model is the same (and not improved by more witnesses total) (SamMSmith)

These two effects have distinctive security characteristic because for 2. the added benefit of an extra witness decrements with every next witness. On the other hand adding watchers in 1. will create a fixed marginal security improvement with every extra watcher.
(@henkvancann)

Controllers' security increased by more witnesses; validator's assurance is increased by more watchers.
Controllers needs to do an eclipse attack to fool a validator, which is impossibly expensive with enough watchers (SamMSmith)

Put another way, first few witnesses are exponentially more secure than n-1, but after a few witnesses, each additional witness's security gain approaches zero asymptotically.
(@Chunningham)

**Q: Is the KERL technically a blockchain/hashed data log, rather than a ledger that implies a balance?

Yes a KEL/KERL is a hash chained data structure. But not merely hash chained but also signed, so it's also a cryptographic proof of key state.
It's not tracking balance, it's tracking key state. (SamMSmith)

**Q: According to the SSI Book KERI will never be able to substitute the internet conventional PKI infra. Right?

SSI Book: "As powerful as this (read KERI-like) solution appears, completely self-certifying identifiers have one major Achilles heel: the controller’s identifier needs to change every time the public key is rotated. As we will explain further in Chapter 10 on decentralized key management, key rotation—switching from one public/private key pair to a different one—is a fundamental security best practice in all types of PKI. Thus the inability for self-certifying identifiers alone to support key rotation has effectively prevented their adoption as an alternative to conventional PKI.\

{TBW prio 1}

**Q: How are KERI witnesses and watchers incentivized to spread KELs and KERLs and make them available?

DNS and other infrastructure generally not billed to end-user; relative cost per end-user substantially lower than traditional/first-gen DLTs and blockchains.
An assumption we make: Watchers will be comparatively cheap and small communities, networks, and services will likely stand one up as a "loss leader".
Controllers are incentivized to spin up witnesses. Controllers will likely buy/lease at least 1 witness if they want their AID publishized/diseminated. This is cloud-scale infra (2 orders of magnitude lower than DLT infra). (SamMSmith)

**Q: KERI versus Lightning/BTC Layer2: could witnesses and watchers form tiers or "layers"? Will there be cheap secondary/lightning-node witnesses and heavy-duty, enterprise-scale witnesses?

Communities and networks will pool resources and security and service models will evolve, we assume. (SamMSmith)

Freer market closer to blockchain market model or pay-as-you-go clouds; no real moats or lock-ins in the spec as written... Implementation guide should maybe go into how to firewall different clients (like virtual machines on a cloud server) or other security-model eccentricities. (@Chunningham)

**Q: Can a conformance test enforce publication of records or logs to judge them fairly as service providers? (@bumblefudge)

Maybe but that's layers above the current spec. This spec gives anchors for that kind of tracking, at least? //credit scoring based on opaque algos and unknown data stores and local identifiers - nothing portable to audit, proprietary turtles all the way down.

Decentralizing REPUTATION was a core driver of decentralized identity in its early days (and core ideological thread in IIW); we could be dogfooding our own decentralized infrastructure reputation; pagerank and star-ranking systems are opaque and difficult to audit; publishing algos should still be our goal, and auditable algos is everything. (SamMSmith)

**Q: Could a KEL or KERL be pruned or charded?

Compared to blockchains KEL and KERL are lean and mean data structures. So pruning or charding might not be necessary. KEL and KERL are charded by nature: as soon as delegation comes in or key rotation.
Every KEL is already shardable because each root identifier could be split, combined, moved whenever (@Chunningham)

Sharding = recombinatory P2P replication (@bumblefudge)

**Q How big is KEL in the worst case scenario or corner case?

You could chunk or prune huge KERLs; that's overkill unless it's really huge You can archive the old state and just keep genesis and last year's updates, for ex.

WCS: high-volume millions of SIGNING events per hour is realistic corner case to worry about, however. If each transaction is sealed as a distinct event, that would make for a pretty big KEL.

That might be kind of an anti-pattern though; implementation guide should probably recommend a merkle every minute in super high-volume signing infrastructures, for example:

  • WCS KELs are 500bytes per event
  • 10-30K txns per second = "visa scale"; load balancing may be needed; horizontal scalability achieved by delegation trees; delegations allow segmentation of storage (i.e. pre-sharding); if audit logs are anchored to delegated events in a pre-sharded log, you achieve very good scalability

**Q: Why does KERI demand signing and digesting the full over-the-wire serialization of a message?

The discussion of KERIs approach to serializing messages and signing and digesting the full over-the-wire serialization is inconvenient for implementers. The motivation for this approach I am calling Zero Message Malleability as a property of KERI. This is a "best practices" security first approach that prevents semantic leakage over time that becomes a transaction malleability vulnerability. Indeed KERI approach trades off some inconvenience in serialization for better security and reduces the inconvenience of needed to have tightly specified semantics to prevent transaction malleability.
(SamMSmith)

**Q: If the KERI resolver "relies on a distributed hash table (DHT) algorithm .. such as IPFS or GNUnet", isn't that a huge contradiction in terms?!

If KERI has this built-in reliance, then doesn't that contradict and defeat the whole purpose of KERI?

KERI resolver - due to the KERI architecture we get rid of the "magic box" in a way that I don't have to trust any infrastructure component. DHT is just example how this can be done in decentralized fashion.
But the point is that I don't have to trust any node or network that the statement is correct. I can cryptographically verify that everytime with KERI. Compare to current DID infrastructure where I have to trust resolution process in each DID-method because as soon as would get DID Document, I can't verify that this is the correct one. Think of it like DID:peer where I can always be 100% sure that the DDO which I have belongs to that DID. Not every DID method has this kind of properties. And I think this characteristic is crucial for adoption of DIDs. (RobertMitwicki)

**Q: Delegations in many systems are unilateral. KERI has cooperative delegation. What is that and why is it better?

In many system unilateral delegation is a single point of failure. if a delegated key's delegator gets compromised, you have no way to recover.
Keys are in different infrastructures in KERI. Both the delegator and the delegatee have keys they manage. If one of them get compromised or lost, we still can recover. Each level of delegation allows delegation of the level above. (@henkvancann)

Q&A section Identifiers

**Q: How is a KERI identifier different than a regular identifier in DID methods?

A self-sovereign identifier that is not self-certifying is dependent of infrastructure and is not fully autonomous and not fully porteable. KERI uses autonomic identifiers, fully cryptographically derivable and portable. (@henkvancann)

*Q: Is my KERI identifier public?

In the direct mode (peer to peer) KERI can be used to keep identifiers private to the peers or group involved. In the indirect mode all identifiers are public. The privacy of the individual, group or object described by the identifier is weak because anyone can bind and indentifier to a subject anytime and anywhere. Fortunately, this binding is weak too, As soon as controllers and verfiers sign statements / events related to an identifier, that's when the binding gets strong and subjects publicly exposed.
(@henkvancann)

**Q: Is a KERI identifier GDPR proof?

KERI enables support for protection against liability that could stem from gdpr’s right to be forgotten (passive approach) and the right of erasure (active approach). There are two exceptions to the general rule that you have to remove an identifier from your database, if a subject and / or controller requests so:

  1. As long as you're a party in a transaction involving the identifier that has been revoked, then you can keep that identifier in your log.
  2. For archival integrity - given that KERI’s whole reason for existence is keep track of duplicity in identity events it is important to know that an identifier has been erased before, because we don't lose that notion. Because somebody could come up with the same identitifier in the future and we wouldn't know that it existed before.

Within the assumption of both exceptions KERI complies with the GDPR rules:

  1. block-list of “deleted” KELs: a reciept of a request for erasure must naturally hold some PII, a two-party interaction might allow this to be recorded.
  2. a need to maintain system integrity/archival purposes can be a reason for maintaining some info right of erasure versus right to be forgotten. This active and passive approach reflects two slightly different interpretations of the same article (which one people use is a hint of their school of thought).

KERI GDPR compliance

Beware that most of GDPR rules are there to protect you from being exploited. So you're not being prossecuted or being labelled as a criminal activity. It might only be illegal and somebody could hold you liable for that. (@henkvancann)

*Q: What do I need a self-certifying identifier for?

It is a cryptographically derived, strong binding between a controller, a keypair and an identifier. No weak bindings introduced by administration present. (@henkvancann)

**Q: How does self addressing work for the identifier?

Using a content digest not only binds the inception statement to the identifier but also makes it easy to use the identifier prefix to retrieve the inception statement from a content addressable database.

Mechanism:
**inception statement -> hashing -> #**

# points to a record in a database:
**# -> inception statement -> hashing -> # (proof of "address")**

This requires that the database store the signature with the inception data, so that a reader may cryptographically verify that the inception data is authoritative. Without the signa- ture the digest is repudiable by the controller. This approach also enables content or document specific but self-certifying identifiers.

inception statement -> sig + derivation + public key + extra data
Check sig with public key -> 
non-repudiable unique attribution to the content by whoever controls the private key

*Q: What do I need a self-addressing identifier for?

In brief:

  1. commitment: nonrepudiable unique attribution to the content creator as controller
  2. confidentiality: a decryption key must be obtained from the controller

Self-addressing identifiers provide a mechanism for a content addressable database to enforce nonrepudiable unique attribution to the content creator as controller. This binds the content to the creator in the content address. Different creator means different address. This makes confidential (encrypted) content more usable as the content address is bound to the controller from whom a decryption key must be obtained.

***Q How can I prevent a direct mode interaction being published and breach a controller's privacy?

The assumption is that direct mode is meant to be private communication.

  1. There is understanding when you use direct mode that it needs to stay private
  2. There is a possibility to impose a liability, under consent at the time of issuance
  3. There is no way to enforce the KEL from being kept private

**Q: What is tombstoning and could it help to preserve privacy of identifiers in KERI?

Tombstoning in Self Sov Identity and DIDs has a very different meaning than in everyday's language (where it means 'the act of jumping in a straight, upright vertical posture into the sea or other body of water from a high jumping platform, such as a cliff, bridge or harbour edge.')

It stems from the development of ledger-based identities like Sovrin. Tombstoning means "Burry the transactions" Because Sovrin is a permissioned ledger, the steward lets you read it - or won't let you read the transactions, depending of the situation whether the subject of the personal information has requested to be forgotten. A steward could say 'see, I've not published the personal information, so I am good.'. For other reasons, tombstoning has never been accepted as a viable solution to get rid of the liability issue.

Tombstoning does not apply to KERI because in indirect mode KEL and KERLs will be ambient available and in direct mode their are only to parties involved. If a third party would be involved in direct mode, somebody would breach the understanding that it's private communication by design. (@henkvancann)

*Q: What do I need a multi-sig self-addressing identifier for?

To get even more security in terms of your signing scheme.
(SamMSmith)

**Q: What do I need a delegated self-adressing identifier for?

To be able to horizontally scale your identifier system, that consists of a root identifier that manages a bunch of other delegated identifier. Created with a cryptographically derived strong binding, all the way through your infrastructure. Not dependent on any administration at all.
(SamMSmith)

*Q: What do I need a self-signing identifier for?

Often it is an efficiecy measure where the identifier includes the signature as your content-addressable hash.
(SamMSmith)

**Q: What do I need a non-transferable identifier for, as KERI supports transferable identifiers?

Its use is different. Many applications of self-certifying identifiers only require temporary use after which the identifier is abandoned. These are called ephemeral identifiers. Other applications may only attach a limited amount of value to the identifier such that replacing the identifier is not onerous.
Because a non-transferable (ephemeral) identifier is not recoverable in the event of compromise, the only recourse is to replace the identifier with another identifier. In some applications this may be preferable, given the comparable simplicity of maintaining key state.
In either of these cases a non-transferable self-certifying identifier is sufficient.

**Q: Could you give an example of solely a cryptographically verifiable inception statement

This is a basic self certifyin identifier (SCI). The identifier itself is derived from a public key that is in the identifier. Nothing is connecting that binding of the identifier to the inception statement. Someone could create an different inception statement with other fields, the only thing that need to be the same is the key list. Everything else in the inception statement could be different.
So that means the only way to know which inception statement is the right one is duplicity detection. So First seen becomes the only means you have to check which inception steatement is the authortiative for that identifier, in case you need an inception statement.

**Q: Could you give an example of strongly binding the inception statement to the identifier

This a self-addressing self-certifying identifier (SASCI) In this case the identifier itself is derived from the inception statement. Now there can only be one inception statement for this identifier. If you'd change just a single bit, other than the identifier field itself, and it's different identifier. You can't have duplicitious inception statements. It's not possible. It locks down at least the inception part and that help in duplicity detection. There can only be one inception statement to start a duplicity log with. From that point on you can have duplicitous next events, but not before. But it still means the effort it takes has to engage in CreatING duplicity, becomes much harder because for example if you include witnesses in the inception statement then any duplicitous event has to publish through the witnesses, and that adds a barrier. Basically it locks down at least the inception part, You can't change it.
In some cases it would be useful to be able to strongly bind the inception statement to the identifier and not merely rely on a cryptographically verifiable inception statement for the associated identifier.

**Q: Why ever go for a basic self-certifying identifier (SCI) when KERI offers self addressing SCI (SASCI) with a better security guarantee?

Because there are many applications where you don't want to have to depend on a KEL because a basic SCI is self-certifying without a KEL. It's more light-weight. For example the non-transferable version of a SCI you can still have an inception event so that basically any tracking anybody does there is still a nominal KEL for that identifier so you can look it up that way, discovering everything, there is always a legitimate version of an inception event for every identifier.

In many cases you want identifiers that are ephemeral, that you know the only event that could be would be is the inception event. You don't need to see the inception event, if you're using it in an ephemeral context.
E.g. witnesses use ephemeral SCIs so I don't need a key event log for a witness to verify a signature by a witness. You can do that with watchers as well. In applications like IOT where you need light-weight identifiers, you will mostly use SCI (1.). So you would use the basic version.

Want you don't need to do with the basic identifiers is you dont have to say 'I got an identifier but I can't verify the keys before I get the KEL so I dont know the key state'. For the witness there is no key state. There is only ever one key. If the witness is ever compromised, then you get rid of the witness. You can rotate keys or rotate identifiers.
Rotating an identifier is allowing us to change the keys for an ephemeral identifier.
In an ephemeral context rotating the keys is the equivalent to rotating the identifier.\

Example BTC and ETH they are ephemeral public keys, you can't rotate keys in BTC without changing the identifier. You have to move all your funds.

In KERI the closest to 1. is DID:Key. Instead of having multiple DID methods, KERI unifies them all into one protocol.

Look for more info in the KERI slidedeck ["KERI for the DIDified"]({to do}).

***Q: Identifiers aren’t self-managing or self-certifying. That’s just not a thing?!

Identifiers are managed by systems and humans using systems. Identifiers are not actors. That sort of slippery language is the kind of meaningless hyperbole that borders on disingenuous.

KERI's creator is using semantics from several different disciplines and then making new semantics when there is not a good fit. So it all sound like new semantics. But only a few are truly new to KERI. But since we can't know what the set of new and not new is for any expert exactly, we can't know what to spend more effort on defining vs what to assume. That is why an adaptive discussion works much more efficiently.

Q&A section Event logs

*Q: What is a Key Event Log?

It's the basis of the source of truth for KERI identifiers. KERI enables cryptographic proof-of-control-authority (provenance) for each identifier. A proof is in the form of an identifier’s key event receipt log (KERL), after a validator verified the registered events, in the chain of events: the key event log (KEL).
(@henkvancann)

Why is a Key Event Log crucially important?

Without KELs, we wouldn't have a chain of registered and signed key events for an identifier. The availability and consistency of the KEL is crucial for next steps: verification of events and duplicity checks. Without verified KELs there will be no KERL for identifiers at hand.
(@henkvancann)

How do I create a KEL?

By a key inception event. A controller creates a key pair and binds this to his/her KERI identifier. There will be wallet software and an API available in the course of code development and also a DID scheme (DID:UN) that invokes calls to those APIs during resolution of the DID.
(@henkvancann)

How can I trust a KEL?

It is secured by a Distributed Hash Table, so internal inconsistencies are cryptographically provable. If they they are internal consistent the first level of trust is established. Furthermore a KERL is end-verifiable to the root-of-trust. You don't need the whole KERL at all times Read more why. Together with the external consistency (duplicity check) (@henkvancann)

Q&A section Inconsistency and duplicity

What kind of Inconsistencies do we have?

An internally inconsistent KEL, this simply won't verify. External inconsistency: two versions of the key event log (KEL).

How can it be garantueed than an identifier represents a certain identity and not another one?

KERI takes advantage of its cryptographic root of trust with strong bindings, to get an inviable guarantee, based on both internal consistency for the cryptographic root of trust and external consistency using ambient duplicity detection.

*Q: What is Duplicity?

See the definition. What it means is that we have a way to make judgements about trust in entities.
(@henkvancann)

**Q: What does duplicity look like?

Duplicity takes two forms. In the first form, a controller may be deemed duplicitous whenever it produces an event message that is inconsistent with another event message it previously produced. In the second form, a witness may be deemed duplicitous when it produces an event receipt that is in- consistent with another event receipt it previously produced.
(SamMSmith)

*Q: Why should we care about Duplicity?

Duplicity becomes a basis for distrust in a controller or its witnesses. (SamMSmith)

**Q: What is the main benefit we get from duplicity detection?

Duplicity detection buys validators protection without the need of anything more than a duplicity detection network.

Q&A section Key rotation

*Q: What is Key Rotation?

Changing the key, i.e., replacing it by a new key. The places that use the key or keys derived from it (e.g., authorized keys derived from an identity key, legitimate copies of the identity key, or certificates granted for a key) typically need to be correspondingly updated.

the main purpose of key rotation it to either prevent or recover from a successful compromise of one or more private keys by an exploiter.
Source.

**Q: Why bother about key rotation?

The primary purpose of rotating encryption keys is not to decrease the probability of a key being broken, but to reduce the amount of content encrypted with that key so that the amount of material leaked by a single key compromise is less.

However, for signing keys there is a concrete reason: say it takes X months of computation (expected value given your threat model) to crack a key, and you rotate your signing key every 𝑋−1 months and revoke the old one, then by the time an attacker has cracked the key, any new signatures produced by the attacker will either be A) rejected by clients because of key expiry, or B) back-dated to before the key revocation (which should also raise warning in clients).
Source.

**Q: Why does KERI solve interoperability with its key rotation scheme?

KERI uses plain old digital signatures from PKI, intentionally, so that it may be truly universally applied. KERI solves that hard problem of PKI, that is, key rotation in a standard way. Without a standard way of addressing key rotation, there is no interoperability between systems, they break when you rotate keys because no one knows how to verify the key rotation was done properly. KERI solves that problem.

**Q: What is Pre-rotation?

Pre-rotation is a cryptographical commitment (a hash) to the next private key in the rotation-scheme. (@henkvancann)
The pre-rotation scheme provides secure verifiable rotation that mitigates successful exploit of a given set of signing private keys from a set of (public, private) key-pairs when that exploit happens sometime after its creation and its first use to issue a self-certifying identifier. In other words, it assumes that the private keys remains private until after issuance of the associated identifier.
Source: chapter Pre-rotation in whitepaper

*Q: Why hasn't pre-rotation or forward chaining been done before?

I first wrote about in 2018, it's been public knowledge ever since. I guess people just don't read.
(SamMSmith)

*Q: What do I need to do step by step to rotate my keys?

key rotation steps 1 and 2key rotation steps 3 and 4 key rotation steps 5 and 6key rotation steps 7 and 8 key rotation steps 9 and 10

Q&A section KEL and KERL

**Q What is the difference between KEL and KERL?

The word 'Receipt' explains it all: the sender signs off the verification of the KEL done by the recipient. That Receipt is hosted in the KERL and is the root-of-trust for KERI.
Direct mode: kel and kerl difference charted The analogy is the difference between a two-way - and a three-way handshake: Did I, the recepient, only verify that the sender's message was valid (two-way using KEL, arrow left to right) or did the sender sign off the receipt of that verification by the recipient (three-way in KERL, arrow right to left) (@henkvancann)

Q&A section Witness

**Q: Once duplicity is detected for a certain identifier and controller, does the witness service, representing the controller, need to be replaced?

For example after a dead key attack

No. The service can be the same. KERI includes a cryptographic commitment to the identifiers of the nodes in the service. The compromised controller will have its own nodes and service but they are not the same as the original ones. As soon as you have a compromised controller than you also have a duplicitous service. For a validator to back up his choice of which service to choose is not hard, because it can be easily verified which service belongs to the original KEL.

**Q: Witnesses have no skin in the game, it’s a nothing at stake situation, no?

The KERI slide deck has a section called the Duplicity Game. I suggest reading through that first. Or see the part of the SSI Meetup webinar that tackles this.
(SamMSmith) {TBW prio 2}

***Q: What is the difference between Key Event Receipt Infrastructure (KERI), and distributed hash tables (DHTs)?

{TBW prio 3}

**Q: As long as witnesses keep lying together no one will ever be able to prove them wrong?

Witnesses do not make any statement about the content of what is being proved. KERI does not enable someone to proof the veracity of a statement only the authenticity of the statement. {TBW}
(SamMSmith)

***Q: Why does the Witness run in restricted mode?

It’s not "first seen" until it’s fully seen by the whole set of witnesses needed (threshold). In the meanwhile the witness in this instance, has to add an escrow. And wait for the witness receipts coming in. And then accept the KEL. (@henkvancann)

***Q: The Round Robin in indirect mode is more efficient than gossiping?

Yes. It has _ complexity where as gossiping has the more "expensive" nlogn complexity. However, Round Robin has the characteristic of building up latency, which can be a burden in speed-sensitive usecases. A provison has been planned in KERI to offer best of both worlds.
(@henkvancann)

*Q: What does 'fully witnessed" mean?

It means that the threshold of the number of witnesses has been met, It doesn't mean that all witnesses have witnessed the event.

***Q: So what if a controller rotates 100% of the witnesses out?

{TBW, just soundbites from the meeting KERI WG April 6 2021 listed below} This is an extreme corner case. There is an additional requirement to add to the key state.

In this situation a validator can't find the witnesses. Then they have to bootstrap from a new set of witnesses.

The previous witness set needs to be able to (to have the add and remove list).

It's a bridge, it's a forwarding service and is a temporary provision, until all the validators have seen the more recent keystate. Witnesses witness an event that rotates them out. They don't sign the rotation event itself. It doesn't have to contribute to the first seen. It will be included in the key event log at the end of it.

The Witness will provide meta data for how long it will keep up the forwarding service if it will become rotated out. The pull of the event by the validator has to be more frequent than that given time per witness that it will keep the forwarding service up & running.

**Q: Which trade-off is there for the validator?

This is listed as an option in the white paper:

The validator can include what he/she considers first seen: the previous set of witness AND the current set of witnesses (after rotation) has to be fully signed. This makes it extremely difficult to perform a dead key attack (eclipse attack).

The backside of this is that more and more controllers will become duplicitious as the requirements on first seen are so strong.

*Q: What is KAACE?

The primary purpose of the KA2CE algorithm is to protect the controller’s ability to promulgate the authoritative copy of its key event history despite external attack. This includes maintaining a sufficient degree of availability such that any validator may obtain an authoritative copy on demand.

**Q: Each DLT has a strategy that has been vetted and tested, often with billions of dollars at stake. With KERI, the witness strategy seems disturbingly variable?

The witness strategy is variable by design. To which extend this disturbs depends on assertions.

KERI doesn't give similar guarantees then a DLT. For an identifier system you don't need all that a DLT gives, you can do an identifier system without a DLT. All you need is what KERI gives. And then we define what KERI gives both the similarities and the unsimilaries In excruciating detail. And it is not true that a witness structure must do what a DLT does. It's much much simpler, which has been explained here. (SamMSmith)

Q&A section Watchers

*Q: How can we detect duplicity? Suppose controller has power over witnesses.

In a Public setting duplicity detection protects the validator from any duplicity on the part of the controller and any resources such as witness that are controlled by the controller.

Since a given controller in a public setting may not know who all a given validator is using for duplicity detection (watchers etc), the controller can't ensure that they will not be detected. And once detected any value that their public identifier had is now imperiled because any entity with both copies can proof irrefutably to any other entity that the controller is duplicitous (i.e. not trustable).
(SamMSmith)

**Q: Do Witness/Validator systems introduce a trusted intermediary layer?

and introduce a centralized set of Location Providers, who you must trust to be nice and let you hop to another Location?

Your witnesses in KERI are not under the control of any intermediairy per definition. It’s a choice. And this choice is to be made by the controller. KERI is globally observable because its ambient availability. A validator gets the signal from duplicity detection. And then the controller could indicate what’s going on (if the controller is not maliicious of course).

This how a validator can reconcile with a fallback mechanism (eg. key rotation). KERI does not guarantee liveness of the keystate (example where you have liveliness of key compromise: a btc address and its authorotative key).

Instead, KERI is a key compromise discovery mechanism. And if there is a compromise, you can send a signal. KERI is all about end verifiability of digital signatures. Digital signatures are legal contracts and it's dependent on the ecosystem governance framework how to avoid liability of the controller for the right key state. KERI does not answer that question. The liable controller can add on several layers in / with KERI to reduce the risk of the controllers liability. The risk that succesfull attacks can occur, can be deminished because they can add extra protection mechanisms.

Q&A KERI and blockchain settled DIDs

***Q: Is it possible to create a KERI DID that is permanently locked to the "did:key" style / ephemeral?

It is. Sections 2.2.3 - 2.3.1 of the white paper explains transferrability and the "basic"-type identifier, which always represents a public key and may be either transferrable (can be updated) or non-transferrable (ephemeral/did:key style). section 14.2 actually details how these are encoded, basically check the first few chars of the identifier.
(CharlesCunningham)

***Q: DID data model supports verification methods which are not based on public keys or even any cryptography at all. KERI can't do this?

In many ways KERI is "better" than DIDs, especially when it comes to proof-of-control. But I think this is one thing that DIDs can do that KERI can't: verification methods which are not based on public keys or even any cryptography at all.

KERI can support them, with some special event type, they use it to store CRDT ops.
(@OR13b) The point of KERI is to maintain to control of key-derived identifiers. It's not intended to provide all the capabilities of DID.
(_@stevetodd_)

***Q: Is it fair to say that DID resolution in general is a security weakness and then push forward KERI in that name?

Although some DIDs have not kept up with design goals* of DIDs, e.g. did:web, it is too strong to state this in general. It simply depends on the DID method?
*decentralization, persistence, cryptographic verifiability.

In brief: we argue that the chain is as strong as its weakest ring.

Security is not build into the protocol but indeed as the eloborate question mentions, it depends on the DID method. Which overall is a huge risk for community as people needs to know the security level which each did method brings. From that perspective without unified security model brings us to the similar situation where, me having private email server in the basement to avoid spying by google, I send out my e-mail to you having it on gmail. I have high security and privacy but other side have just security without privacy. The outcome is that security model is applied in wrong place and KERI aims to fix it.
(RobertMitwicki)

***Q: Because the DID data model theoretically allows DID methods and verification methods that may NOT be based on cryptographic keys, KERI is capable of spanning all DIDs?

We would like to see some examples of verification methods that are not based on cryptographic keys and are in the scope of DID. The KERI community would like to learn more about these methods. It's true KERI is all about cryptographic commitment. But KERI can also support hashed based identifiers e.g. a fingerprint of the content as unique identifier, without the control part.

***Q: How do I find all the DIDs that stand for apps, code modules, public businesses, and other entities that benefit from being publicly discoverable on a decentralized deterministically iterable registry?

How might one build a decentralized deterministically iterable registry for such use cases where the entries are securely known to be from the matching Identifier?
The reason I am asking is to get people to think about the system they'd inevitably need to create to support the 95% of use cases (given 95% of identity interactions are between personas of people, places, and things that are discoverable)
Is it not a helpful exercise to game out the things required to support 95% of DID use cases with other DID system developers?

It's considered a privacy property of KERI, that you cannot enumerate all identitiess, in the same way that finding all minorities of certain religious preference might not be a feature.
(@OR13b)

Discovery is a layer on top of what KERI provides. KERI doesn't preclude DID, nor does it need to implement all of DID. KERI will participate in the DID ecosystem. (_@stevetodd_)
It doesn't need/want to solve/serve that slice of the use case pie.

**Q: Follow up question 1: Why does KERI rule out 95% of the DID-based use cases upfront, where we need public discoverability on a decentralized deterministically iterable registry?

The vast majority of users use apps and services that are exchanges between or about the well-known, 
publicly resolvable registered persona DIDs of people, places, or things? 
Let's list a few to see how much of human digital life it covers:
- All social media: Twitter, Facebook, Instagram, Telegram, Signal, etc.
- All public content creation: YouTube, SoundCloud, Spotify, etc.
-All current registries: NPM, all app stores, all things that use those registries 
    (basically every piece of software on the planet)
- All publicly registered objects: cars, boats, airplanes, etc.
Put it this way: very few use cases on this planet will not directly, or within them, 
rely on publicly iterable, globally registered persona DIDs. 
But that said, I'm interested in hearing other opinions or counter arguments to the contrary.
(_@csuwildcat_)

There is an implicit need for the registry to track its entries as DIDs. I guess those 95% use cases will have to get other types of DIDs for that?

It's possible to make a DID doc that represents a KERI identifier. If you want to resolve it, you can put it in any number of blockchains. That just publishes it. However, they don't have to be published to work.
(_@stevetodd_)

Or for example TOR hidden services, these are not designed to be discoverable. In fact, the whole point of tool is to provide anonymity. Anonymity is a property of set membership, and it's destroyed by making the sets small or enumerable. (@OR13b)

In many scenarii, what the elaborate question explains makes sense. I can understand a different design goal/priority for KERI, I think the rationale is quite clear in terms of where it stands in the DID space. (@fimbault)

**Q: Follow up question 2: That's not deterministic?!

You can't have Registry A magically just trust that a DID from Other System B, it would need to be native to it? Any registry with deterministically resolvable entries requires the entry controllers' IDs and resolutions be native to it. That's an empirical computer science wall type of requirement.
Imagine I want to register a DID in a decentralized deterministically iterable registry - something anyone can run and deterministically know all entries registered with it, wherein the registry has no central entities or authorities that determine the bindings between entries and those who control them...
Nowhere in any paper on this planet is this a solved problem, because it's basically NP hard

It depends on what you mean by resolve. The white paper explains the points brought up in this question. (_@stevetodd_)

{TBW prio 1}

**Q : Nowhere in any paper on this planet is this a solved problem, because it's basically NP hard

It's considered a privacy property of KERI, that you cannot enumerate all identities.
(@Or13)

Q&A Security Guarantees

**Q: What are the security risks of KERI with regard to the identity protocol?

Harm that can be done to the a controller: Unavailability, loss of control authority, externally forced duplicity
Harm that can be done to a validator: Inadvertent acceptance of verifiable - but forged or duplicitous events

Breaking the promise of global consistency by a controller is a provable liability. However, global consistency may only matter after members of that community need to interact, not before.
(SamMSmith)

*Q: How secure is the KERI infrastructure?

KERI changes the discussion about security. From a discussion about the security of infrastructure to a discussion about the security of your key management infrastructure. Most people when they think security, the think "oh, blockchain!": permissioned or permissionless, how hard is it to get 51% attack, etc.Non of that matters for KERI. KERI is all about "are your private keys private?!" And if yes, that drastically slims down the security discussion to brute force attacks to public keys. And because the next public keys are in fact protected by a hash, you have to brute force the hash algorithm, that is post-quantum secure. So that is a very high level of infrastructural security.

So private key management and protection is the root of your security in KERI.

**Q: Can I rotate keys with Tangem in KERI?

Suppose I'd trust a Tangem card for generating public private key pairs at will and the NFC communication allowing to interact with a wallet app.

One of the main concerns is that there is a theoretical link (a binding) between the cards and a user, via the card-ID (CID). However the CID is used only for checking the authenticity and integrity of the chip itself. Tangem publishes and anchors a list of CIDs with corresponding public addresses in a public blockchain. When checking authenticity, the verifier looks up the pub CID and corresponding pub address in the published list, and verifies that the chip controls the correct pub address by means of a challenge-response scheme. Even though for blockchain or SSI interactions, a completely new wallet with new pub/priv keypair is generated, the pub/priv key of the CID is used when the authenticity of the chip is checked by means of a challenge response scheme. Everything happens in the client app (2021: iOS or Android; and the client code is open source), where there is no communication with Tangem, so Tangem is not able to see any activity conducted by this CID in an authenticity check. The CID and corresponding key pairs are not used in any other interaction. A new wallet with new pub/private key pair is generated on chip, with these keys being used for any transactions, signing, etc.

Q: With the chip firmware being proprietary, how can we be sure that the newly generated private keys for new wallets are not still linked somehow to the cards CID? A: The firmware is audited by Kudelski and can be verified with a published hash. TBD: How can it be verified, when and by whom? If the firmware is not open source, then somebody has to draw a hash from it in an authorized situation. However, Tangem cards are EAL6+ and FIDO2 certified.

On the issue of Rotation: {TBW prio 2}

**Q: DHTs are not an immutable linear chronology oracle, which is the heart of the actual security problem. You claim KERI solves the security problem with DHTs?!

The immutable linear chronology is provided by the key event log (KEL) data structure itself. Getting a full copy is all you need. When retrieving a KEL over a network, then as you say a witness can prune some amount of the latest events, but every witness would have to be compromised for that to be undetectable.
If parties are so concerned, they could establish a large collectivised set of witnesses that sign and distribute all key events presented to this network (this would essentially be a Proof of Authority/federated blockchain but would require (configurable)% compromise for undetectable pruning of recent history. Only PoA/federated because the witness sets are designated by the controllers, so you could not just use arbitrary witnesses who join and leave the network at leisure (afaik).

The difference between the chain and the DHT is that not all DHT nodes act as witnesses for all KELs in the system (in the sense that they dont provide receipts for every KEL and arent referenced in the witness sets of every KEL), but they could all (or at least the ones holding the KEL you seek) still provide availability for KELs and thus would have to all be compromised in order to hide a recent-history-pruning, only one has to transmit the new/complete version to prove all the other versions as being old/incomplete.
(CharlesCunningham)

The point of KERI is to encapsulate all the guarantees within KELs nothing else is needed. DHT is just for resolution process to find a place from where I can get it. This place can change as you like I could even get it in p2p interaction from someone else. DHT seems to be the most reasonable way to build solid infrastructure for resolution process but none of the nodes can actually inject or tamper KELs so you don't have to trust them or get any guarantees from them. Since if the node will miss behave it is very easy to detect that.
(RobertMitwicki)

**Q: You are arguing KERI affords greater security than a decentralized linear event system like Bitcoin?

...you would be fundamentally arguing that you can record a singular, immutable linear event history more securely than Bitcoin, and I see nothing in KERI that would indicate that.

Read the answer to this first.

If you read Szabo's paper on threshold structures, you get security of the same type when ever you use a threshold structure, be it MFA, Multi-Sig, or Distributed consensus. They all are using a combination of multiple relatively weak attack surfaces that must be simulatenously compromised for a successful attack. So multiplying simulatneous weak surfaces = functional equivalent of a stronger attack surface. So when you look at KERI you see that the security is primarily due to cryptographic strength and the witnesses are not the primary source of security but merely secure one thing, that is the availability of the KEL for an identifier. Not the KEL itself. The KEL iteself is secured by signatures.
From a Validator perspective their security is due to duplicity detection. Successful attack against duplicity detection requires an eclipse attack. Ledgers such as bitcoin are also susceptible to eclipse attacks. So in an apples to apples (resistance to eclipse attack) a KERI watcher network of comparable reach (1000's of watchers) would have comparable resistance to an eclipse attack.

***Q: Differences between blockchain-based security and KERI security

  • Where KERI doesn't need total ordering in its logs, blockchain do need that. What KERI needs is watchers that construct string of event in the relative order of reception of the KEL {TBW please explain or improve this: what is this, why is it important?}
  • Another characteristic is that KERI identifiers are transferable and blockchain-based identifiers are not, they are bound to their ledger.

***Q: How does FIFO prevent effective DOS attacks in Out-of-order KAACE?

An escrow cache of unverified out-of-order event provides an opportunity for malicious attackers to send forged event that may fill up the cache as a type of denial of service attack. For this reason escrow caches are typically FIFO (first-in-first-out) where older events are flushed to make room for newer events. Paragraph 11.3.1 Question: how does FIFO prevent effective DOS attacks?

By loadbalancing the incoming messages. If you dont have any loadbalancing, the messages are going to be processed First In First Out. Only when an attacker has full bandwith available to overload the buffer, they could frustrate the process to get honest messages in. As soon as you’re able to balance the receipt of messages in the buffer, you’ll be able to get the right messages (from honest senders) through. (@henkvancann)

### ***Q: I don’t feel KERI is capable of delivering on all the promises made. It’s trivial to have a witness strategy that fails to meet those promises.

Which is not true for bitcoin. Nobody gets to alter the witness strategy of bitcoin without a HUGE amount of demonstrable proof, politicking, and advocacy. Most of my problems with innovative DLTs or other distributed systems are that I struggle to internalize how they actually guarantee anything.

If you are very familiar with PoW and therefore Bitcoin and Ethereum but not non-PoW Byzantine Agreement (BA), that where the cutting edge is for understanding the security model of KERI.\ Non-PoW Byzantine Agreement (BA) and therefore KAACE on KERI witnesses which are a simplified variant of BA and under the hood look nothing like proof of work. Actually KERI with witnesses and KAACE looks the most like Stellar an open permission-less Byzantine Agreement algorithm. If these concepts are unfamiliar to you, yu might as a result have no intuition about why KERI could work because you then have little familiarity with distributed consensus mechanisms that provide PoW like guarantees, but are not PoW.
Actually BA came years before PoW so its the other way around (PoW provides BA like guarantees) but thats a quibble. So anyone trying to grasp how KERI security is guaranteed should first learn how non-PoW BA works before he/she could begin to believe why KERI could even work at all. Once you see this, then the dominos will start to fall.

***Q: The guarantees stated about KERI are inappropriate without a particular witness structure?

...and then you have to evaluate the witness strategy, which means KERI on its own doesn’t have the guarantees that the KERI creator keeps claiming.

A KERI witness structure never needs to provide total ordering (where total ordering is precisely defined in the literature for distributed consensus algorithms as providing one ordering for the union of transactions from multiple sets of transactions from multiple sets of clients where each set of transactions is ordered independently by each client that generates it. I.e. all the transactions from all the clients are combined into one set with one ordering = one total ordering. Most people can't define this correctly whenever asked.

Byzantine fault tolerant total ordering is the hard problem of distributed consensus. Safe agreement which is all that KERI provides is much much simpler. So almost any witness structure is much simpler and will still work good enough. And its not the witness structure alone but the witness and watcher structure:

  • Witness for controllers
  • Watchers for validators Both are simpler consensus mechanisms compared to DLT algorithms. Distributed consensus describes a family of algorithms of which BFT Total Ordering distributed consensus is a subset. Pretty much all cloud databases that have redundant copies use some form of distributed consensus for synchronizing the copies of the database. They all use some form of authentication for securing that consensus but they are not in any real sense of the term using Byzantine Fault tolerant total ordering distributed consensus. Setting up witness pools and watcher pools in KERI is of comparable complexity to spinning up a redundant Postgres or CouchDB cluster. So KERI's guarantees come from nothing much more complicated than that. Nobody thinks that a CouchDB cluster is too complex to understand but few actually know the algorithmic details of its low level of distributed consensus.
    (SamMSmith)