TERI and TERIA

[SmithSamuelM]

Separation of Concerns between KERI and ACDC implementations

Currently the keripy repo provides support for both KERI which includes its infrastructure, witnesses, watchers etc and ACDCs which includes its infrastructure which includes transaction event log registries of ACDC state. This combination is an accident of history. It was just easier when rushing the vLEI to production to include all its support in the keripy libarary. It was always contemplated that at some time in the future this would need to be remedied by moving the ACDC stuff to its own library.

That time has come. I am proposing Two new libraries: Teri and Teria

TERI (Transaction Event Registry Infrastructure)

In general use of an ACDC requires that its state be registered. Historically the Issue-Hold-Verify model of a credential is enabled by a verifiable data registry (VDR) that holds the state of the credential as an issuance. Such state typically includes the issuance and revocation state. A more complex state might be a transferable issuance where the issuee can transfer the issuance to a different issuee, so the state could include not merely issuance and revocation but also transference.

Indeed, ACDCs may be used for many purposes not merely credentials but in most applications there is usually the need for "state" to be maintained with respect to the ACDC as an issuance.

The purpose of a TEL (transaction event log) is to maintain that state in a cryptographically verifiable way by using a hash-chained KEL sealed (bound or anchored) verifiable data structure (aka the TEL). A TEL may be used as a credential registry (VDR). The ACDC specification includes a section that defines Transaction Event Logs as ACDC State Registries. This defines the associated events.

It is anticipated that there are many applications of ACDCs that require a TEL with an associated application specific set of transaction events. If the applicaton is sufficiently generic then it may be desirable to support those events in the new TERI library. If not, then they would get their own application-specific library.

In the current keripy the vc and vdr packages are where most of the code for TERI and Teria currently exists. A new teri (or teripy) repo needs to be created.

Teria (Teri Agent)

In addition to the core TERI library, hosted agents for managing and reporting on TEL Registry events as well as the creation and managment of ACDCs may be beneficial. This would include ReST API endpoints etc. Teria provides a similar role to TERI as Keria provides to KERI . KERI for example splits out hosted agent web API functionality from keripy, Thus a Teria agent library will be needed with associated repo.

Wallets

A Signify Wallet could then have an interface to both a Keria Agent and a Teria Agent and the UX could hide that from the user. A services provider may choose to combine KERIA and TERIA functionality in the same hosted service.

KERI is more generic thant TERI so we don't want to impose constraints on KERI that limit its applicability to only ACDCs with transaction event log registries. ACDCs support many different privacy preserving mechanisms and so the APIs that support such would authorize the exposure of ACDC and ACDC state registry information to authenticated parties in applicatoin specific ways. Likewise, we don't want to impose constraints on TERI that limit its applicability to only public credentials like the vLEI. but we want TERI to support public credentials. This may be best differentiated in Teria, where the ReST API endpoints can be separately authenticated and authorized for the given ACDC type.

[dhh1128]

My reaction to this is that it makes sense, from a pure design point of view, but I'm not sure it makes sense politically. It exacerbates the perception that KERI is complex, and it creates two new codebases that need maintainers.

This is not a strong vote for any particular posture vis-a-vis the idea. I just want to think about this some more.

[VasiliyS]

I do believe that the right focus right now is to make sure that a clean, efficient and understandable "API" in regards to interaction with KERI/ACDC Infrastructure is available.

Why is that the case?

We need to drive adoption. Adoption at the "early adopters" stage of the market is driven by "innovators". I'm focused on vLEI ecosystem as it has, IMHO, the most potential to discover and facilitate productive use-cases. So the "innovators" in the vLEI context are enterprise devs (or startups focused on enterprise use-cases) and they need this "API" to be able to prototype and showcase these use-cases.

Currently, it's not trivial to understand how to build services that interact with the KERI/ACDC infrastructure that enables vLEIs. Adding yet another component will not make it easier, necessarily. Even though it's the right thing to do longer term.

Therefore, I'd suggest that we focus on improving the API around current "witnesses" so that enterprise services are easier to build build in whatever language of choice the developers have.

For example:

• adding more rest calls in addition to the qry 'mailbox' mechanics for both TELs and KELs.
• allowing to request KEL events from a certain sn up, etc.

I do believe that this will help to understand the use-cases and developer ergonomics of these APIs, which can be later separated into a dedicated service(s) (such as TERI/TERIA) later, if deemed appropriate.

Why polish "witness" APIs? Well, I feel that while KERIA is a useful tool for edge applications such as mobile apps. It's not always beneficial as an intermediary for building back-end services. For example, aid "resolvers" that stay in sync with the monitored KELs and TELs and enable integration with the other enterprise systems that need to accept and verify vLEIs and application specific, connected VCs.