Restore external content seals (anchors) to inception and delegated inception events. NFT use case example.

[SmithSamuelM]

Restore External Content Anchoring to Inception Event

Inadvertently Dropped Support for External Content Anchoring from Inception Event

When we revised the KERI events to use compact labels we overlooked important use cases that depend on external content seals (anchors) in the inception events (icp anddip`, henceforth will just refer to inception event to include all types of inceptions events).

Originally the inception event included a data field list that could store both configuration traits and seals. This later was changed to a cnfg field list but still had the intention of storing both configuration traits. However we further sampled the configuration traits to be strings when we created the compact labels. algorithm and in the process overlooked the use cases for having seals in the inception event.

Currently the compact c field is only a list of configuration trait strings and does not allow for seals. Given the naming convention and semantics for compact labels this provided clarity of purpose but also excluded those seminal use cases. Some of this language (for seals in inception events) was also lost when we replaced the algorithm for deriving self-addressing self-certifying identifier prefixes using extracted data with using the eventing serialization but with a dummy prefix i field.

It is true that in general one can include external content anchors in an ixn event that immediately follows the icp without requiring the friction of a rotation event which rotates keys. However there are seminal use cases where the identifier wants to be strongly bound to the external content which requires a cryptographic commitment to that external content via a digest in the inception event itself (in a Seal). In this case the identifier prefix must self-addressing or self-signing. As a result the identifier derivation itself will be cryptographically bound to the external content. To restate, strong binding of external content to the identifier prefix, i field with self-addressing derivation code, requires that the external content or at least a cryptographic commitment to the content via a digest be included in the inception event itself. It was an unfortunate oversight that this functionality was dropped and needs to be restored.

The KERI white paper clearly assumes this capability for example:

This approach also enables content or document specific but self-certifying identifiers. This provides a mechanism for a content addressable database to enforce non-repudiable 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.

Add a field to Inception Event

Given the semantic cleanliness of separating config traits that may only appear in the inception event with seals to anchor external content, it does not make sense to overload the existing c field in the inception event to restore this functionality but instead add an a field as a list of anchors (seals) to external content. This is consistent with the other events that have an a field.

Revised Inception with content seals:

The proposed revised icp event with restored content anchoring derivation support is shown below:

{
    "v" : "KERI10JSON00011c_",
    "i" : "EZAoTNZH3ULvaU6Z-i0d8JJR2nmwyYAfSVPzhzS6b5CM",
    "s" : "0",
    "t" :  "icp",
    "kt":  "1",
    "k" :  ["DaU6JR2nmwyZ-i0d8JZAoTNZH3ULvYAfSVPzhzS6b5CM"],
    "n" :  "EZ-i0d8JZAoTNZH3ULvaU6JR2nmwyYAfSVPzhzS6b5CM",
    "wt":  "1",
    "w" : ["DTNZH3ULvaU6JR2nmwyYAfSVPzhzS6bZ-i0d8JZAo5CM"],
    "c" :  ["EO"],
    "a" :
            [
               {
                   "i": "EJJR2nmwyYAfSVPzhzS6b5CMZAoTNZH3ULvaU6Z-i0d8",
                   "s": "0",
                   "d": "ELvaU6Z-i0d8JJR2nmwyYAZAoTNZH3UfSVPzhzS6b5CM"
               }
            ]
}

As per convention used throughout, then there are no external seals the a field value is an empty list.

{
    "v" : "KERI10JSON00011c_",
    "i" : "EZAoTNZH3ULvaU6Z-i0d8JJR2nmwyYAfSVPzhzS6b5CM",
    "s" : "0",
    "t" :  "icp",
    "kt":  "1",
    "k" :  ["DaU6JR2nmwyZ-i0d8JZAoTNZH3ULvYAfSVPzhzS6b5CM"],
    "n" :  "EZ-i0d8JZAoTNZH3ULvaU6JR2nmwyYAfSVPzhzS6b5CM",
    "wt":  "1",
    "w" : ["DTNZH3ULvaU6JR2nmwyYAfSVPzhzS6bZ-i0d8JZAo5CM"],
    "c" :  ["EO"],
    "a" : []
}

Likewise the revised delegated inception, dip is shown below:

{
    "v" : "KERI10JSON00011c_",
    "i" :  "EJJR2nmwyYAfSVPzhzS6b5CMZAoTNZH3ULvaU6Z-i0d8",
    "s" : "0",
    "t" :  "dip",
    "kt":  "1",
    "k" :  ["DaU6JR2nmwyZ-i0d8JZAoTNZH3ULvYAfSVPzhzS6b5CM"],
    "n" :  "EZ-i0d8JZAoTNZH3ULvaU6JR2nmwyYAfSVPzhzS6b5CM",
    "wt":  "1",
    "w" : ["DTNZH3ULvaU6JR2nmwyYAfSVPzhzS6bZ-i0d8JZAo5CM"],
    "c" :  ["DND"],
    "a" :
            [
               {
                   "i": "EJJR2nmwyYAfSVPzhzS6b5CMZAoTNZH3ULvaU6Z-i0d8",
                   "s": "0",
                   "d": "ELvaU6Z-i0d8JJR2nmwyYAZAoTNZH3UfSVPzhzS6b5CM"
               }
            ],
    "da" :
           {
             "i":  "EZAoTNZH3ULvaU6Z-i0d8JJR2nmwyYAfSVPzhzS6b5CM",
             "s": "1",
             "t": "rot",
             "p": "E8JZAoTNZH3ULZ-i0dvaU6JR2nmwyYAfSVPzhzS6b5CM"
           }
}

Without any external content anchoring seals,

{
    "v" : "KERI10JSON00011c_",
    "i" :  "EJJR2nmwyYAfSVPzhzS6b5CMZAoTNZH3ULvaU6Z-i0d8",
    "s" : "0",
    "t" :  "dip",
    "kt":  "1",
    "k" :  ["DaU6JR2nmwyZ-i0d8JZAoTNZH3ULvYAfSVPzhzS6b5CM"],
    "n" :  "EZ-i0d8JZAoTNZH3ULvaU6JR2nmwyYAfSVPzhzS6b5CM",
    "wt":  "1",
    "w" : ["DTNZH3ULvaU6JR2nmwyYAfSVPzhzS6bZ-i0d8JZAo5CM"],
    "c" :  ["DND"],
    "a" : [],
    "da" :
           {
             "i":  "EZAoTNZH3ULvaU6Z-i0d8JJR2nmwyYAfSVPzhzS6b5CM",
             "s": "1",
             "t": "rot",
             "p": "E8JZAoTNZH3ULZ-i0dvaU6JR2nmwyYAfSVPzhzS6b5CM"
           }
}

Implications

The proposed revisions will not require many changes to actual code but will break many test vectors and as a result should be staged appropriately.

Seminal Use Cases

An important use case for disseminating and using digital or electronic content is to provenance the origin and chain-of-custody of that content. Cryptographically the primary mechanism for provenancing the origin and chain-of-custody is to make non-repudiable attestations about that data. Most commonly these non-repudiable attestation are comprised of a cryptographic commitment to that data that is in turn signed with a non-repudiable digital signature. The problem is that one needs to secure that attestation which requires some form of identifier system, such as KERI. With KERI the way to make the originating attestation as secure as possible is to bind the content to the identifier's derivation. These means using the self-addressing derivation which also binds the identifier (and content) to the incepting set of key pairs. Now any reference to that identifier is uniquely also a reference to that content and those key pairs. With KERI the highest level of security over key state is obtained when only establishment events are allowed in the KEL, i.e. no interaction events. This makes the pre-roated keys from each rotation event one-time use only.

This highest degree of security is important when one wants to establish a chain-of-custody over valuable content. With KERI control of that content via its identifier with the external content seal in the inception event is established via its KEL. The KEL establishes control authority for key pairs. Whoever controls the private keys controls the key state.

KERI via rotation allows transfer of control over an identifier from one set of keys to another. The controlling entities of subsequent keys sets do not have to be the same. Thus one entity can transfer control of the identifier and hence the anchored content to another entity by rotating to a set of keys controlled by that other entity. All the first entity needs is a list of public keys designated by the second entity which it uses to derive the next key digest in a new rotation. These public keys, correspond to the private keys held by the second entity. To clarify, the first entity does a rotation where the next digest is the digest of this next set of public keys. If the inception event specifies in its config that only establishment events are allowed via the config trait EO then upon publication of that rotation the effective control of the KEL is now in the hands of the second entity.

NFT (Non Fungible Tokens)

More recently NFTs or non-fungible tokens have become popular as distributed shared ledger mechanisms for asserting and transferring ownership of unique digital content. Often NFTs are strongly tied to the crypto-currency associated with a given ledger. As a result most of these NFTs are not portable between shared ledgers or that portability requires some significant additional support via another protocol and/or, atomic swap, or tunneling wrapper in order to move them to a different ledger.

In this context I use the term ledger to mean a Byzantine fault tolerant algorithm involving a pool of nodes with some form or shared governance that provides total ordering of all transactions from an any number of clients to a cryptographically verifiable data structure called a ledger or blockchain. To be clear there are several main types of ledger algorithms with these properties, such as, Proof-of-Work (PoW), Proof-of-Stake (PoS), Byzantine Agreement (BA), and Verifiable Random Function (VRA). Extant ledger algorithms include many variants of each type and many hybrids of the four types. The important properties all ledgers share are liveness, safety, and double spend proofing.

KERI has a flexible witness designation feature. A KERI witness may be a ledger oracle. Thus when appropriate a KERI identifier may leverage all the properties of ledger such as liveness, safety, and double spend proofing by declaring its witness to be a ledger oracle. KERI also has the concept of watchers. In this case any watchers would also be oracles of the same ledger..

The KERI protocol also support modes of operation, namely, direct and indirect, where the witnesses and watchers may not be ledger oracles. In these modes KERI does not guarantee double spend proofing or liveness but does guarantee safety. A guarantee of safety is sufficient for solving the problem of secure attribution which is the primary problem an identifier system needs to solve. So when used in the majority use case, KERI does not incur the performance, latency, throughput, scalability, and governance costs of ledgers, but may leverage cloud infrastructure which has a cost floor that is usually several orders of magnitude lower than a ledger's cost floor.

However an NFT token requires in addition to safety both liveness and double spend proof properties. Thus to use KERI for an NFT means designating a ledger oracle as its witness. However because witnesses may be rotated in KERI via a rotation event, KERI thereby provides easy portability of its NFTs from one ledger to another. Thus KERI NFTs may have much lower friction for portability.

But in order to enable the securest form of NFTs on KERI, the inception event needs to include a content seal (anchor) to the digital content that is the target of the NFT.

[chunningham]

Support for restoring this field in the ICP event to the KIDs is unopposed, a PR should on the way to do so.