Adding rotation and transfer semantics to credential TEL

[pfeairheller]

Adding semantics to PTEL for rotation and transfer.

• Two additional semantics
  • Rotation (non-cooperative transfer)
    • Control stays within the same KEL and the same TEL

      • Use case: as a did:webs controller, AID is associated with domain names in an ACDC, to transfer to a new list, rotate the TEL to point to a new ACDC with a new list. The Issuer of the new ACDC is the same Issuer. The new ACDC can have an edge pointing back to the old ACDC to enable walking backwards between ACDCs.

      • Synonymous with duplicity detection in the KEL.

        • Watchers could watch both KELs and TELs.
        • If a KEL is analogous to a shared ledger a TEL for that KEL is analogous to a rollup on a shared ledger.

      • Currently TELs only have iss/rev

      • ISSUE: rotating to a blank list could be considered a revocation

        • ISSUE: not using rev and rot in the same TEL
        • ISSUE: possible config option for (dnr do not rotate, like dnd do not delegate in KEL)
  • 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.).

[pfeairheller]

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.).

[pfeairheller]

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

[pfeairheller]

All of the text in this original issue and subsequent comments above are the result of direct dictation from @SmithSamuelM

[SmithSamuelM]

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

[pfeairheller]

Trying to capture this in a few credentials and TEL events as an example:

Originator ACDC Bill Of Lading Credential

{
  "v": "ACDC10JSON000197_",
  "d": "EIO9uC3K6MvyjFD-RB3RYW3dfL49kCyz3OPqv3gi1dek",
  "i": "EIqTaQiZw73plMOq8pqHTi9BDgDrrE7iE9v2XfN2Izze",
  "ri": "EACehJRd0wfteUAJgaTTJjMSaQqWvzeeHqAMMqxuqxU4",
  "s": "EFgnk_c08WmZGgv9_mpldibRuqFMTQN-rAgtD-TCOwbs",
  "a": {
    "d": "EGJZo3pDwzIQHw7nZuuJ2dMCigwnVaosVFBDH4JiQy3e",
    "dt": "2021-06-27T21:26:21.233257+00:00",
    "i": "EHgwVwQT15OJvilVvW57HE4w0-GPs_Stj2OFoAHZSysY",
    "billOfLadingItems": ["Sandwich"]
  }
}

Originator TEL Credential Registry Inception Event:

{
  "v": "KERI10JSON000113_",
  "t": "vcp",
  "d": "EACehJRd0wfteUAJgaTTJjMSaQqWvzeeHqAMMqxuqxU4",
  "i": "EACehJRd0wfteUAJgaTTJjMSaQqWvzeeHqAMMqxuqxU4",
  "ii": "EIqTaQiZw73plMOq8pqHTi9BDgDrrE7iE9v2XfN2Izze",
  "s": "0",
  "c": [
    "NB"
  ],
  "bt": "0",
  "b": [],
  "n": "AGu8jwfkyvVXQ2nqEb5yVigEtR31KSytcpe2U2f7NArr"
}

Originator TEL Issuance Event for Bill Of Lading ACDC

{
  "v": "KERI10JSON0000ed_",
  "t": "iss",
  "d": "EBVaw6pCqfMIiZGkA6qevzRUGsxTRuZXxl6YG1neeCGF",
  "i": "EIO9uC3K6MvyjFD-RB3RYW3dfL49kCyz3OPqv3gi1dek",
  "s": "0",
  "ri": "EACehJRd0wfteUAJgaTTJjMSaQqWvzeeHqAMMqxuqxU4",
  "dt": "2021-06-27T21:26:21.233257+00:00"
}

Shipping Manifest ACDC

{
  "v": "ACDC10JSON0001a5_",
  "d": "EGdkfXyEtbiicBJ5LPMq0pje3QbxFKWvoYaGdjzBaFRO",
  "i": "EJvTV8bMQcQi28DfbRP4UIgYN0MfX6OB9vKlrJmT8bIl",
  "ri": "EJZBT1DJyZiiiQq6F037_LCvh-ghAk51O4K26jkl-BFh",
  "s": "ENTAoj2oNBFpaniRswwPcca9W1ElEeH2V7ahw68HV4G5",
  "a": {
    "d": "EJCNcfe0h8c896z8Gqu_d-87iaSyrCrmLZ_Y5p4K-HBm",
    "dt": "2021-06-27T21:26:21.233257+00:00",
    "i": "EHgwVwQT15OJvilVvW57HE4w0-GPs_Stj2OFoAHZSysY",
    "shipName": "The Titanic"
  }
  "e": {
    "d": "EIl3MORH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZA",
    "billOfLading": {
      "n": "EIO9uC3K6MvyjFD-RB3RYW3dfL49kCyz3OPqv3gi1dek",
      "s": "EFgnk_c08WmZGgv9_mpldibRuqFMTQN-rAgtD-TCOwbs"
    }
  }
}

Shipping TEL Credential Registry Inception Event:

{
  "v": "KERI10JSON000113_",
  "t": "vcp",
  "d": "EJZBT1DJyZiiiQq6F037_LCvh-ghAk51O4K26jkl-BFh",
  "i": "EJZBT1DJyZiiiQq6F037_LCvh-ghAk51O4K26jkl-BFh",
  "ii": "EJvTV8bMQcQi28DfbRP4UIgYN0MfX6OB9vKlrJmT8bIl",
  "s": "0",
  "c": [
    "NB"
  ],
  "bt": "0",
  "b": [],
  "n": "Ax4ZZwfkyvVXQ2nqEb5yVigEtR31KSytcpe2U2f7NArr"
}

Shipping TEL Issuance Event for Shipping Manifest ACDC

{
  "v": "KERI10JSON0000ed_",
  "t": "iss",
  "d": "EI1gJ2RoaSE87_F4_uZRVBSidSEdywT613fUGHM2Hby9",
  "i": "EGdkfXyEtbiicBJ5LPMq0pje3QbxFKWvoYaGdjzBaFRO",
  "s": "0",
  "ri": "EJZBT1DJyZiiiQq6F037_LCvh-ghAk51O4K26jkl-BFh",
  "dt": "2021-06-27T21:26:21.233257+00:00"
}

Originator Transfer Event from Bill of Lading to Shipping Manifest

{
  "v": "KERI10JSON0000ed_",
  "t": "txr",
  "d": "EJZBT1DJyZiiiQq6F037_LCvh-ghAk51O4K26jkl-BFh",
  "i": "EIO9uC3K6MvyjFD-RB3RYW3dfL49kCyz3OPqv3gi1dek",
  "s": "1",
  "ri": "EACehJRd0wfteUAJgaTTJjMSaQqWvzeeHqAMMqxuqxU4",
  "dt": "2021-06-27T21:26:21.233257+00:00"
  "a": [
    {
      "i": "EGdkfXyEtbiicBJ5LPMq0pje3QbxFKWvoYaGdjzBaFRO",
      "ri": "EJZBT1DJyZiiiQq6F037_LCvh-ghAk51O4K26jkl-BFh"
    }
  ]
}

[SmithSamuelM]

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.

[SmithSamuelM]

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.

[SmithSamuelM]

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.