Protocols

The KERI whitepaper  is over 140 pages long and has resulted in three separate specifications in Trust over IP: KERI , ACDC  and CESR . For now, we’ll just give a brief overview, and hope to expand these sections in the future.

These protocols have been developed from the ground up with a first principles approach, which can lead to being exposed to overwhelming, low level details. In actuality, these protocols are much less complex than meets the eye, and follow a minimally sufficient design approach.

It’s all about getting the right abstraction level — dApp developers in Cardano learn the eUTXO model, but they needn’t learn the inner complexities of the Ouroboros consensus algorithm.

Key Event Receipt Infrastructure

Many developers, particularly from blockchain backgrounds will be well accustomed to the concept of asymmetric cryptography and digital signatures. Given a public-private key pair and some data, a digital signature can be used to prove that the controller of the private key signed the data.

These attestations are very useful and form the basis of web and blockchain security. The identifier in this case is the public key. However, this is problematic when you consider that private keys can get compromised over time, and in general become more vulnerable the more they are used. In traditional systems, a key rotation results in a new identifier, and possibly clunky attempts to relate the old identifier to the new one.

KERI is a decentralized identifier protocol and infrastructure intended to solve the key management problem. It allows you to control an identifier which can be maintained as keys are rotated; no matter how many times you rotate keys, you keep your identifier. This simplifies application flows, improving UX and security — if a user is compromised, they can recover and your application or dApp needn’t do anything!

It provides enterprise grade security with post-quantum secure identifiers, weighted threshold multi-sig, delegation and more. As a protocol, KERI is concerned with securely maintaining your identifiers even in the face of compromise or attack. It’s very clever!

Authentic Chained Data Containers

While KERI provides a way to securely relate signatures to an identifier, ACDCs provide structure to the data being signed. Currently, the most prominent use of ACDCs is to represent Verifiable Credentials in the KERI ecosystem.

An ACDC is a data container that is issued by a KERI identifier. In KERI, there is a strong binding between which keys were used to issue which ACDCs, despite key rotations — more on that later. The lack of this binding in other ecosystems leads to complications such as a issuer key rotation effectively breaking the validation of all previously issued credentials.

The schema or format of the data container is referenced within the ACDC as a SAID , which prevents security issues prevalent in other Verifiable Credential protocols that rely on web-hosted JSON schema URLs.

ACDCs can be targeted or untargeted:

• Targeted ACDCs have an issuee (holder) field, and as such represent Verifiable Credentials.
• Untargeted ACDCs do not, so they can be viewed more as Verifiable Statements — to whom it may concern. An IoT device reporting on its sensor data would be a good example.

Finally, perhaps the most interesting aspect of ACDCs is that they can be chained together to represent complex relationships. An individual ACDC can effectively be a node in a property graph with well-defined edges, weights and rules on those edges — all defined in the schemas. This is incredibly powerful and allows us to represent trust chains and data provenance with extreme precision, safely protected by KERI.

Composable Event Streaming Representation

CESR is a serialization format for structured data that allows for both binary and textual representations interchangeably. Every serialization format tries to balance a set of trade-offs; CESR has been designed with efficiency in mind for cryptographically agile & heavy protocols, which we envision as the future where all data is signed at rest and in transport. It also solves many of the shortcomings of existing serialization formats, such as human-readable encodings being too verbose, or choosing how to represent a public key in the data.

In CESR:

• Unimportant whitespace differences do not impact the hash of the data.
• The textual representation can be presented to users and developers for human friendliness, and the binary representation can be sent over the wire for efficiency and terseness. The hash does not change.
• Cryptographic primitives such as keys and hashes are first class citizens which avoids issues like deciding on how to encode a public key.

Fields are insertion-ordered which avoids the need for insecure canonicalization schemes. The order of the fields should be defined in the data structure’s ecosystem — for example, KERI has a well-defined top-level field order for KERI events.

Finally, everything in KERI and ACDC is identified using SAIDs, whether it be identifiers, schemas, or credentials. This allows clients to securely cache data and greatly contributes to the system scalability.