Transfer Registry

[SmithSamuelM]

Cooperative Transfer
transferring control between two KELs
Issue an ACDC, transfer registry for tracking control of ability to chain to the ACDC
Move the control of the ability to append only one entity can append to the chain

As we discussed given that we can use a chained set of ACDCs to be a self-contained transfer registry, we don't need to use key rotation. We simply use a chained set of ACDCs. If you think about it KERI key rotation is just a purpose built set of events (like ACDCs) called key events that are chained together. ACDCs are instead, general purpose "event" containers that are chained together. So we are better off to use the general purpose mechanism (ACDC ) to implement a transfer of singular (exclusive) control registry.

Issuer to Issuee which issuee in turn becomes the next Issuer. This forms a chain of transfers
from one AID (Issuer) to the Next AID (Issuee) in a given instrument. Then an appendix to that instrument chaines back to the original instrument but the appendix is now Issued by the Issuee of the original instrument. The issuee of the appendix is the next designated controller.

syntax. lower case are ACDC (container) SAID identifiers. upper case are AID identifiers (controllers). Square bracket is ACDC, parenthsis is a link or chain to another ACDC given by the parenthesized SAID. A -> B, means A issued to B (A is controller i.e. Issuer and B is next controller i.e. Issuee).

Here is a chain of 3 documents with SAIDs, a, b, c, the original instrument and 2 amendements. The controllers are A, B, C

[a, A -> B]
[b, B -> C, (a)]
[c, C-> D, (b)]

The binding relationship is hierarchical not direct.

An AID is derived from the public key of key pairs and potentially other information.
An AID can anchor any other information it wants too in its KEL (key event log)
So for example the inception event for an AID could include the hash (digest, SAID) of an EBL. This makes the AID not only derived from the public keys but also the SAID of the EBL.

The problem is that anyone can take a copy of that EBL’s hash (SAID) and create an AID with their own public keys and create a new AID that is derived from that EBL. So this sort of scheme does not work. We have to take a different approach.

So the problem is that the origination of an EBL has to be linked to the Originator in a unique way.

Lets suppose that inside the EBL is a field that designates the Originator of the EBL. The value of this Originator field is the well known AID a given entity. The SAID of that EBL will now be derived from the originating entity’s AID which is derived from the public keys controlled by that entity which that originating entity can singularly prove control. The SAID (hash) of the EBL itself is thereby cryptographically committing itself to a given originating entity. And that originating entity can singularly prove that they are the originator by signing a presentation of the EBL. No other entity can prove they are the originator.

An EBL that that has a different value (aid) in its originator field will have a different SAID. The identifier of the EBL will therefore be different, hence it MUST be a different EBL. All the fields in the EBL can be the same except the value of the Originator field. Changing the originator field changes the EBL’s own identifier which its SAID which makes it by definition a different EBL.

So now no matter how many copies of the EBL with a given SAID exist, the only entity that can prove they are the originator or any or all copies is the controller of the keys that control the AID of the originator so designated in the EBL.

Changing even one bit in the EBL changes its SAID therefore making it by definition a different EBL. Its not a copy.

Transfer Registry

Now to have a transfer registry, the EBL itself needs to make a commitment to the identifier of the registry where transfer will be recorded. This way the originator can “pre-transfer” control to a different AID given that an event is logged in the transfer registry event log and anchored in the originator’s own key event log. This starts to sound complicated but its just rinse and repeat of making forward commitments that change the identifier of the committing instrument so that any difference in the forward commitment changes the identifier of the committing instrument thereby making it a different instrument, not a copy.

So instead of the current Issue with SAID of ACDC and then a revoke. You would have an ISSUE then either a revoke or another issue/rotate to a new SAID which automatically revokes the old one and replaces it with the new one i.e. rotate. So you then have a transfer registry that can be abandoned by revoking or maintained indefinately by rotating. This would have use for more than just did:webs so the effort would be amortized on other applications besides just did:webs which is all you get if you create a bespoke TEL that only works for did:webs domain transfers. Just a thought.

The semantics of the “transfer” is then conveyed by the ACDC itself and not by the TEL. The TEL semantics are generic you can rotate from one ACDC to another or abandon the TEL by revoking the last ACDC in the transfer registry. Whatever is being transfered is embedded in the ACDC itself and benefits from the Schema properties of ACDCs etc etc.

One reason for a transfer registry is to add discovery property to a registry. The existing issue revoke semantics of a revocation only registry don’t provide discovery of a replacement issuance. When privacy is paramount, you may not want to have the correlatation that discovery property induces. But when you want discover then you are better served with a rotation (aka transfer) registry than merely a revocation registry. Also we are suffering from the bias that a cryptographic accumulator can’t provide transfer it can only provide set inclusion aka revocation. So all the use cases were built around at most a revocation only approach. But NFTs especially benefit from a transfer registry and many registry functions look like NFTs so having a generic transfer/rotation TEL for ACDCs has a lot of utility.

Discussion

• Transfer (Cooperative like delegation)
  - Transferring control between two KELs and two TELs
  - Chain of custody semantic of a data supply chain that consists of linked ACDCs
  - At any point in time, only one controller is authorized to append to the data supply chain.
  - Security comes from the ability for a validator to detect a duplicitous appendage to the data supply chain (via the i2i operator).
  - Issue an ACDC, transfer registry for tracking control of ability to chain to the ACDC
  - Move the control of the ability to append only one entity can append to the chain
  - (I'll review the recording and try summarize)
  - The originating ACDC that originates the data supply chain has an Issuer and Issuee. For example, the originating ACDC could be a bill of lading (or manifest for Griff).
  - Issuer is originator, the SAID of that ACDC is the identifier of the originating document.
  - SAID of the credential registry is the global identifier for that issuer to originate any number of supply chains.
  - The SAID of the TEL which is the SAID of the issuance event is the registry for a given supply chain.
  - This is the use case for shared backers for the credential registry. But could have non-shared backers for availability reasons because the issuance rate on this TEL might be much higher than the issuance rate on the KEL. The TEL witnesses become watchers of the KEL witnesses. Tiered availability architecture this way.
  - This architecture is amenable to scalability solutions that become TELs of TELs of ... KELs
  - The designated issuee is now the singular controller who is solely authorized to append to the data supply chain. The designated issue now creates a new ACDC in that ACDC, the issuer is the prior issuee of the originating ACDC, this new issuer designates the next issuer in that ACDC by declaring them the new issuee. The new ACDC has an edge with the i2i operator that points back to the originating ACDC. The semantics of the field labels in the schema for the edge indicate that this is part of a data supply chain not a delegation. This represents the "hand off of the goods"
  - Anyone in the chain can revoke their ACDC (hand off) in the chain and break the data supply chain, but the EGF of your ecosystem defines the rules around which anyone in the chain can revoke their credential if at all.
  - The issuer of the new ACDC in the chain issues it to a TEL that they control. The SAID of that TEL event is then provided to the originating Issuer.
  - The originating Issuer now issues a transfer event that references BOTH the SAID of the new credential registry and the SAID of the ACDC. (Look up of the TEL for the new ACDC is provided by an index of the TEL events in the registry by ACDC SAID.).

There are two features that cooperative discovery provides. One is duplicity detectability. A two way commitment to the each ACDC that is the newly appended data supply chain. And the second is that each stage in the data supply chain, the TEL that governs that stage provides forward discovery of the next stage. So the data supply chain of custody can be discovered either forward or backwards without having to maintain a central repository.

(This is why the transfer event should contain two SAIDs, credential registry SAID and the ACDC SAID. The TEL event SAID can be looked up because the credential registry MUST maintain an index of TEL events by their ACDC SAID.).

This structure means that, because TEL events are anchored in the issuers KELs there is no need for the Issuer to sign the ACDC.

An important property/feature of the requirement for the TEL host to maintain an index that maps each ACDC SAID to the TEL that the ACDC appears in, enables a given TEL to have multiple rotation or transfer events that can all be found from any one of the ACDCs in that TEL. This future proofs any given TEL with respect to discovery for any new types of TEL events that may be added in future versions of the PTEL specification

I think after some more thought, that we may need to include the TEL SAID (VCP) of the next TEL in the Transfer Event in the prior TEL. This means that a TEL registry that hosts TELs with transfer semantics would benefit from a database that directly indexes the TEL SAIDs so that a validator could query the TEL SAID as the duplicity resides in the TEL Transfer chain of events not merely in the ACDC.

Discussion:

Seals anchored in KELs are not searchable for the purpose of determining duplicity. By design anchors are meant to be information hiding. They are digests and those digest could be blinded in some way. For example, a digest could be anchored in a cryptographic accumulator such as Merkle tree and only the Merkle root digest appears in the KEL. Likewise a given digest could be blinded with a blinding factor (salty nonce). In either case the same data could be anchored multiple times in a given KEL in a way that no validator could discover that there were multiple anchors. A malicious controller of a KEL could thereby be undetectably duplicitous wrt to anchoring the same information. Therefore, an KEL anchor must not have a uniqueness semantic as it would be unenforceable by a validator (watcher, backer, or verifier).

Existing revocation registries do not have such a semantic and the use cases have counter incentives for the Issuer of an ACDC to create duplicitous TELS for a given ACDC. But for a transfer registry this may no longer be true. Therefore duplicity detection must be with respect to a specific TEL and therefore the TEL's SAID. Validator's must also be able to detect duplicity with respect to different events or versions of events in a given TEL. The same TEL as identified by its SAID must never have different events. Any validator (watcher, backer, or verifier) that sees different events for the same TEL would then have provable evidence of duplicity and therefore not trust. Therefore the commitment by the transfer event must also be to the next TEL SAID and not merely to to the ACDC in the issuance event in the next TEL SAID.

If the commitment is only to the ACDC then a given TEL issuer could hide the fact that it has multiple TELs for the same ACDC and therefore hide its duplicity. For example it could have a unique OOBI host for each TEL so that a query of the ACDC-to-TEL index on each host returns a different TEL. A validator would have to know about all those hosts to detect duplicity and could not infer that there were multiple hosts merely from following and validating any given TEL chain. So Watchers would have to watch not TELs but ACDCs. Given that the same ACDC could be referenced as an edge in any number of other ACDCs then merely finding an ACDC in another TEL host is not necessarily evidence of duplicity. There are non-duplicitous uses of ACDCs in multiple TELs. Consequently duplicity detection must be at the TEL level not the ACDC level.

This is analogous to KEL duplicity. The same key state could be used by multiple KELs. Duplicity is not reusing keys in multiple KELs but to have two versions of the KEL for the same AID. Likewise for TEL transfer, duplicity is to have two versions of the TEL for the same TEL SAID where in both case a differing version is detectable by a different set of events in any two versions of a KEL/TEL.

Conclusion the transfer event MUST include the SAID of the next TEL.

Given the next TEL's SAID given by its iss event SAID is derived from the next ACDC's SAID that appears in the iss event then there is not a requirement to include the ACDC SAID in the Transfer event.

ACDC tracking for duplicity is problematic. This is similar to the problem that the Certificate Transparency project has. A given CA DNS certificate is not required to be unique. Existence of multiple certificates for the same DNS is not provable evidence of duplicity but merely evidence of possible duplicity. More investigation is required to determine actual duplicity and a validator may not be able to ascertain duplicity on its own, thereby breaking end-verifiability. In DNS/CA a given DNS can have multiple valid Certs from different CAs with no duplicity. Likewise with ACDCs, a validator seeing the appearance of the same ACDC in multiple TELS, especially by reference may not be able to ascertain that this constitutes duplicity on the behalf of the issuer of that ACDC.

A transfer semantic on a TRansfer registry as a TEL Chain (Chain of Transfer TELS) muast have a special semantic that makes singularity (unique) control over the ability to append to the TEL Chain end verifiable.

Likewise that appearance of an ACDC in multiple TEL Registry Databases is not provable evidence of duplicity but merely possible. Whereas a different set of events for a given TEL transfer chain where the next TEL SAID is part of the event is provable evidence of duplicity.

One more thing. A forward link to the TEL identifier does not stop a malicious next TEL from inducing more than one Prior TEL from transfering to the same next TEL. Merely pointing back to the prior ACDC does not remove this ambiguity completely as the same ACDC may be referenced in multiple TELs. The ACDC itself only references the TEL registry not the TEL itself. This creates ambiguity that may be exploitable.

To remove this ambiguity the next TEL must include the SAID of the prior TEL either at the TEL event top level or via an extra property on the edge of the next tel that is pointing back to the prior ACDC.

One additional consideration is that a valid use case is a merge of more than one prior TEL into one Next TEL. Each merged TEL must be separately referenced so as to unequivocally indicate that it is a merger and not duplicity.

This means that if the prior TEL SAID is to be put at the top level of the next TEL event, it must be a list of TEL SAIDs not a single SAID value.

If instead the prior TEL SAID is an extra property on the ACDC Edge the points back to the ACDC in a prior tel it can be a single value because ACDCs already have a mechanism for having multiple edges.

I think to keep the ACDC validation logic simple, that adding a priors field whose value is a list of one or more TEL saids to the 'transferable issuance" event of a next TEL is the simplest from a logic perspective. It does however mean we have to have a new type of issance event for TELs. This is similar to the reason we have both and icp and dip events for KELs where the DIP is exclusive to delegated aids. And a new tis (transferable (into) issuance) events in tels. Or we could version PTEL and add the priors field to all Iss events and an empty priors list just means is was not transferable into.