Transaction event logs (TELs) -- how to tackle this?

[blelump]

Hi,

last KERI spec meeting covered the topic of how to address Verifiable Credentials (VC) verification in case the key pair has been rotated (so in KEL ). So the Transaction Event Logs (TEL) concept has been introduced by Sam.

As a reminder, this is the concept: With such a concept it should be basically possible to create as many TEL's as one would like to do so, where each TEL serves exactly one state machine. So far so good, but immidiately some questions appear. In particular, what kind of Seal is the seal pointed in the KEL in the above diagram, a Digest Seal that anchors the digest of signed document (ie. VC)? If so, that would make the KEL to include any digest of any signed document ever (so would make it big) to make such statement true, which I am not so sure about. I may also not understand correctly the purpose of Transaction here so an explanation in this area would be highly appreciated.

Apart from above questions, there are also more infrastructural concerns toward which I currently don't see a clear answer. The simplest is how to build this thing. :-)

Let's elaborate a bit:
Imagine that there is an institution that issues some licenses and third parties (verifiers) would like to be able to do two things:

• ensure that the license has been signed by that institution;
• the license hasn't been revoked.

For the sake of this disussion, assume whether it is Open Loop Split Model or Closed Loop Split Model (basically Direct or Non-direct mode) is irrelevant.

To the questions/doubts:

• how the verifier will be able to get the answer the first question so how to verify that the license has been signed by given issuer? Query KEL and look for digest of the VC (assuming the first paragraph of this Github issue stays valid)?
• who controls the TEL and basically what is the concept for TEL's from the organizational point of view? In particular, any issuer that issues anything should provide such TEL and any verifier should be able to reach it somehow? In such scenario, shall we care ie. about high availability or this is the issuer concern how he handles that? To put another way: any KERI controller should provide the query logic for any additional TEL it provides?

I believe these questions come from the feeling that TEL seems to add some complexity to the KERI ecosystem. Whether it is narrow or broad topic I will be hoping that we will clarify it in this topic.

[SmithSamuelM]

@blelump Good questions. Let me take them in turn.

The type of seal for any TEL transaction would either be a digest seal or a merkle tree root seal. A single KERI event can have a list of seals of any number. So one can batch TEL events by including a digest for each seal in the list for a given event issued per batch. The TEL transaction also includes a TEL transaction number, tn, version string etc. very much similar to a key event.

If the batches get large enough then one would want to use a merkle tree root seal for the whole batch and only include the digest of the root in a seal in the KEL event. The TEL would then also store that transaction block with the Merkle tree itself. The TEL becomes a TEBL for transaction event block log where each block is hash chained to the previous block and each event in each block is part of a Merkle tree of transactions. Thus instead of a hash chain you have a hash tree (Merkle tree). All we have done is anchored the transaction block to key state instead of the individual transaction. The transaction is anchored to the merkle tree of its block. This is how block chains work in general. But each transaction is still signed by the keys of the referenced key state.

Alternatively if one has a shared ledger that one prefers to use, one can just use it to create transactions and then create seals of those transactions and anchor them in their KEL.

The reason why one would want to create one's own TELs is if one wants to be in complete control over the TEL. With KERI each issuer can be the sole root of trust not only for its KEL but for any and all TELs it chooses to create. This has obvious advantages from a GDPR perspective but also from a governance perspective.

For infrastructure a TEL belonging to a given KEL can be hosted by the same set of witnesses that host the KEL. Or one could define a completely different set of witnesses for the TEL. One merely needs to define a new API for replaying the TEL. The KERI core protocol doesn't care how the TEL is structured its outside the KERI spec. That said however, now that KERI is a working group we could spin up another standard effort to define a KERI native TEL protocol.

Alternatively each VC could have its own Two event TEL. It has an issuance event and an optional revocation event. A witness of the set of VCs TELS for a KEL just stores these events as a couple indexed by the VC identifier. The VC itself includes a seal to the issuing event in the controlling KEL.

To avoid transaction malleability attacks the digest in the KEL should be of the whole TEL transaction not merely the VC. The TEL transaction includes a seal of the VC with the VCs identifier and digest. This is a new type of seal. A verifier of a VC can then look up the referenced TEL transaction via a seal in the VC itself, find the seal digest of the VC verify it and so on.

Indeed one might propose that the VC credential be structured so that it is the TEL issuance event itself. They are both mapped data structures so we could just include some extra fields in the VC to make it dual purpose so that the VC is identical to the TEL transaction event. Or we embed the VC in the TEL transaction via only its seal to make it be more palatable to the VC spec world.

• how to verify a license? Include in the license a reference to the authoritative TEL for that license. The TEL should have its own identifier and should have an analogous inception statement anchored with a seal in its controlling KEL that designate analogous TEL witnesses that host the TEL. Given the credential a similar discovery lookup by TEL identifier becomes possible. All credentials issued via the TEL would then verifiable by downloading the TEL from one of its witnesses.

• who controls the TEL. Recall that in the discussion I indicated that a TEL is for all intents and purposes analogous to a delegated KEL. One can create a tree hierarchy of KELs via delegation. Likewise a TEL's control authority and security guarantees may be also analogously determined. All we need is a set of TEL events to be defined that are analogous to the Delegated Inception and Delegated Rotation events for Delegated KELs.

For example

• Delegated TEL inception Defines the TELs identifier and any witnesses for the TEL
• Delegated TEL rotation event (rotates TEL witnesses not keys)
• Delegated TEL interaction events (include the transaction details in the event message)
• VC Issuance event
• VC revocation event

In general the transaction set for the TEL is determined by its interaction event set. The TEL inception and rotation events change the support infrastructure for the TEL such as designating witnesses but do not change key state that is done in the controlling KEL. But we can now use the TEL to control its own support infrastructure (witnesses) via analogous inception and rotation events and its transaction event state via analogous interaction events . And we could go fully meta here and have one TEL be used to control lower level TELs and so on.

The interaction events in a TEL do not need to be chained together because they are already hash chained to Key State. So we have the option of lightweight TELs or heavy weight TELs.

Unlike delegated KEL interaction events. A TEL interaction event (and all TEL events) include a location seal that points back the event holding the seal of the TEL event or merkel tree root for the block of TEL events to which the TEL event belongs. The TEL events are each signed by the keys that are given by the key state for the reference KEL event. Thus we can have very fine grained TELs and very course grained TELs all different types all verified and controlled via seals in the KEL.

There are numerous possibilities.

[SmithSamuelM]

But all the design principles of KERI that include separation of control of the promulgation of events from the control over the confirmation of events apply to TELs. We can use similar discovery mechanisms, similar duplicity detection mechanisms etc. All we are doing is adding additional lookup and verification steps but in the end it all rolls up into determining key state in order to verify signatures on statements. And if those statements have their own transaction state, then we use those signature verifications plus some additional verifiable data registry such as a TEL to verify transaction state. These statements may Verifiable Credential issuance and revocation transactions.

[blelump]

Hi @SmithSamuelM ,

once again thanks for your exhaustive answer. As you've mentioned several times, this is a broad topic so I'll close now this issue. Nevertheless we plan to continue work upon this, especially with your proposal from GLEIF presentation:

as this seems to be the most appropriate to what we currently would like to have. Basically we're building a showcase how KERI can be used instead of a shared ledger and having such a feature would be a nice addition to the showcase.