Transaction Event Logs / Public VC Registry

[pfeairheller]

Transaction Event Logs / Public VC Registry

Introduction

The Transaction Event Log (TEL) is a hash linked data structure of transactions that can be used to track state. A Public Verifiable Credential Registry can be represented in several TELs to establish issuance or revocation state of a Verifiable Credential (VC). The KEL is used to establish control authority over the keys used to commit to the events of the TEL and sign the VC. The events of the TEL are used to establish the issuance or revocation state of the VCs issued by the controller of the identifier represented by the KEL. This document specifies a design for public VCs only. The use of a hash digest of the VC contents as the identifier of that VC or an attribute in a TEL event allows for correlation of uses of the VC.

Transaction Event Log

A KERI KEL can control a TEL by anchoring the TEL to key events of the KEL with the following:

1. Create the inception event for the TEL with the TEL specific unique identifier.
2. Generate a hash digest of the serialized content of the TEL inception event.
3. Attach anchoring seals from the KEL events to the TEL events they are authorizing.
4. Sign the KEL event as usual to commit to the digest of the serialized TEL event.

Any validator can cryptographically verify the authoritative state by validating the signatures of the referenced KEL. The TEL events do not have to be signed as the commitment to the event is in the form of the digest in the seal in the anchoring KEL event and the signatures on that event. Like KEL events, all TEL events have the fields i, s, and t. However, the s or sequence number field in TEL events represents the "clock" for that transaction set. Each transaction set can have its own "clock" (e.g. bitcoin block height, wall clock, etc) and is independent of the sequence number of the KEL events. In the case of the Verifiable Credential Registry, the s field is simply a monotonically increasing integer.

The events are anchored back to the KEL using Event Seals whose JSON representation is as follows.

{
 "i": "EJJR2nmwyYAfSVPzhzS6b5CMZAoTNZH3ULvaU6Z-i0d8",
 "s": "3",
 "d": "ELvaU6Z-i0d8JJR2nmwyYAZAoTNZH3UfSVPzhzS6b5CM"
}

For TEL events, this seal back to the KEL will be delivered as an attachment of event seal quadlets in triple of (i, s, d).

-eAB
EJJR2nmwyYAfSVPzhzS6b5CMZAoTNZH3ULvaU6Z-i0d8
0AAAAAAAAAAAAAAAAAAAAAAw
ELvaU6Z-i0d8JJR2nmwyYAZAoTNZH3UfSVPzhzS6b5CM

Event seal attachment example (line feeds added for readability)

Verifiable Credential Registry

A Public Verifiable Credential Registry (Registry) is a form of a Verifiable Data Registry that tracks the issuance/revocation state of credentials issued by the controller of the KEL. Two types of TELs will be used for this purpose. The first type of TEL is the management TEL and will signal the creation of the Registry and track the list of Registrars that will act as Backers for the individual TELs for each VC. The second type of TEL is the VC TEL which will track the issued or revoked state of each VC and will contain a reference to it's corresponding management TEL.

The following events will be used to create and maintain the TELs for the Registry.

Ilk	TEL	Name	Description
vcp	Management	Registry Inception Event	Inception statement for the Registry
vrt	Management	Registry Rotation Event	Rotation event for updating Backers
iss	VC	Simple Credential Issuance Event	Issue credential with no Backers
rev	VC	Simple Credential Revocation Event	Revoke previously issued credential with no Backers
bis	VC	Credential Issuance Event	Issue credential
brv	VC	Credential Revocation Event	Revoke previously issued credential
iis	VC	Simple Credential Issuance Event with VC Hash	Issue credential with no Backers, VC Hash as separate field
irv	VC	Simple Credential Revocation Event with VC Hash	Revoke previously issued credential with no Backers, VC Hash as separate field
ibs	VC	Credential Issuance Event with VC Hash	Issue credential, VC Hash as separate field
ibr	VC	Credential Revocation Event with VC Hash	Revoke previously issued credential, VC Hash as separate field

Management TEL

The state tracked by the Management TEL will be the list of Registrar identifiers that serve as backers for each TEL under its provenance. This list of Registrars can be rotated with events specific to this type of TEL. In this way, Registrar lists are analogous to Backer lists in KERI KELs. Additional metadata can be tracked in this TEL, for example references to Schema. The Management TEL will have two events: vcp for Registry inception and vrt for rotation of the list or Registrars. The events will reference the controlling identifier in the ii field and be anchored to the KEL with an event seal triple attachment.

The Registry specific identifier will be self-certifying, self-addressing using its inception data for its derivation. This requires a commitment to the anchor in the controlling KEL and necessitates the event location seal be included in the event. The derived identifier is then set in the i field of the events in the management TEL.

Though it is possible for a given identifier KEL to issue multiple types of credentials, it is anticipated that there will be relatively few (usually one) Management TELs anchored to a given KEL. A more scalable approach to issuing multiple credential types from a single identifier would be to use delegated identifiers for the different types of credentials to be issued.

Label	Description	Notes
v	version string
i	namespaced identifier of Registry
s	sequence number of event
t	message type of event
p	prior event digest
c	list of Configuration Traits/Modes	allows for config of no backer registry
ii	issuer identifier
vi	hash digest of VC contents
b	list of backer identifiers for credentials associated with this registry
bt	backer threshold
ba	list of backers to add (ordered backer set)
br	list of backers to remove (ordered backer set)

Configuration

The simplest (and most common) case for Registries relies on the witnesses of the controlling KEL instead of Registry specific backers. To accommodate this case, the c element is added to the management TEL inception event with the configuration option NB to specify that the Registry will never have backers configured in the management TEL. In this case, there will only be one event in the management TEL for this Registry and the simple events iss and rev will be used for "simple issue" and "simple revoke" respectively in the VC specific TELs. For these events, the ri field will be the simple identifier referencing the management TEL.

Option	Description	Notes
NB	No Backers	No registry specific backers will be configured for this Registry

Registry Inception Event

{
 "v" : "KERI10JSON00011c_",
 "i" : "ELh3eYC2W_Su1izlvm0xxw01n3XK8bdV2Zb09IqlXB7A",
 "ii": "EJJR2nmwyYAfSVPzhzS6b5CMZAoTNZH3ULvaU6Z-i0d8",
 "s" : "0",
 "t" : "vcp",
 "b" : ["BbIg_3-11d3PYxSInLN-Q9_T2axD6kkXd3XRgbGZTm6s"],
 "c" : []
}-eABEJJR2nmwyYAfSVPzhzS6b5CMZAoTNZH3ULvaU6Z-i0d80AAAAAAAAAAAAAAAAAAAAABwEOWdT7a7fZwRz0jiZ0DJxZEM3vsNbLDPEUk-ODnif3O0

Registry inception event for establishing the list of Backers

{
 "v" : "KERI10JSON00011c_",
 "i" : "ELh3eYC2W_Su1izlvm0xxw01n3XK8bdV2Zb09IqlXB7A",
 "ii": "EJJR2nmwyYAfSVPzhzS6b5CMZAoTNZH3ULvaU6Z-i0d8",
 "s" : "0",
 "t" : "vcp",
 "b" : [],
 "c" : ["NB"]
}-eABEJJR2nmwyYAfSVPzhzS6b5CMZAoTNZH3ULvaU6Z-i0d80AAAAAAAAAAAAAAAAAAAAABwEOWdT7a7fZwRz0jiZ0DJxZEM3vsNbLDPEUk-ODnif3O0

Registry inception event for "backer-less" configuration

Registry Rotation Event

{
 "v" : "KERI10JSON00011c_",
 "i" : "ELh3eYC2W_Su1izlvm0xxw01n3XK8bdV2Zb09IqlXB7A",
 "p" : "EY2L3ycqK9645aEeQKP941xojSiuiHsw4Y6yTW-PmsBg",
 "s" : "1",
 "t" : "vrt",
 "ba" : ["BXhpfP_H41hw8f-LluTidLfXxmC4EPwaENHI6CuruE6g"],
 "br" : ["BbIg_3-11d3PYxSInLN-Q9_T2axD6kkXd3XRgbGZTm6s"]
}-eABEJJR2nmwyYAfSVPzhzS6b5CMZAoTNZH3ULvaU6Z-i0d80AAAAAAAAAAAAAAAAAAAAACQEOWdT7a7fZwRz0jiZ0DJxZEM3vsNbLDPEUk-ODnif3O0

Registrar rotation event updates the list of Backers

Verifiable Credential TELs

The binary state (issued or revoked) of each verifiable credential (VC) will be tracked in individual TELs associated with each VC. The state changes will be represented by 4 sets of 2 events: iss for simple VC issuance and rev for simple revocation, bis for the issuance of the VCs with backers and brv for revocation of the VCs with backers and corresponding events iis, irv and ibs, ibr to be used when the identifier of the VC is not hashed from the contents of the VC and that hash digest must be included is the separate vi field in the event. The events will be anchored to the KEL with an event seal triple attachment signified by the grouping counter -e##.

There are two options for including a cryptographic commitment to the VC in the TEL VC events. The identifier of the VC can self-addressing using the same technique KERI uses for self-addressing identifiers. The VC identifier can be created by padding the VC id field and taking a hash digest of the serialized contents of the VC. This form of self-addressing identifier can be used as the i field in the TEL iss, rev, bis and brv events and no other reference to the VC is required. When the identifier of the VC is derived from some other method, the TEL events iis, irv, ibs and ibr are used, and a hash digest of the contents of the VC is placed in the vi field.

The VC identifier can be namespaced using DID syntax. In this case, the VC identifier in the TEL events would be the method specific identifier of the full DID. For informational purposes, the fully qualified DID can be included as an attachment to the TEL events.

The list of backers needed to sign each VC TEL event is maintained by the management TEL. Since that list can change over time with the rot management events listed above, the non-simple VC events (bis, brv) must be anchored to the event in the management TEL at the point when the VC event is published with the ra field. This way, the backer signatures can be indexed into the proper list of backers at the time of issuance or revocation.

Credential Issuance/Revocation TEL

Label	Description	Notes
v	version string
i	namespaced identifier of VC
s	sequence number of event
t	message type of event
p	prior event digest
ri	registry identifier from management TEL
ra	registry anchor to management TEL

Simple Credential Issuance Event

{
 "v" : "KERI10JSON00011c_",
 "i" : "Ezpq06UecHwzy-K9FpNoRxCJp2wIGM9u2Edk-PLMZ1H4",
 "s" : "0",
 "t" : "iss",
 "ri": "ELh3eYC2W_Su1izlvm0xxw01n3XK8bdV2Zb09IqlXB7A"
}-eABEJJR2nmwyYAfSVPzhzS6b5CMZAoTNZH3ULvaU6Z-i0d80AAAAAAAAAAAAAAAAAAAAAAwELvaU6Z-i0d8JJR2nmwyYAZAoTNZH3UfSVPzhzS6b5CM

Simple Credential Revocation Event

{
 "v" : "KERI10JSON00011c_",
 "i" : "Ezpq06UecHwzy-K9FpNoRxCJp2wIGM9u2Edk-PLMZ1H4",
 "s" : "1",
 "t" : "rev",
 "p" : "EY2L3ycqK9645aEeQKP941xojSiuiHsw4Y6yTW-PmsBg"
}-eABEJJR2nmwyYAfSVPzhzS6b5CMZAoTNZH3ULvaU6Z-i0d80AAAAAAAAAAAAAAAAAAAAABAELvaU6Z-i0d8JJR2nmwyYAZAoTNZH3UfSVPzhzS6b5CM

Credential Issuance Event

{
 "v" : "KERI10JSON00011c_",
 "i" : "Ezpq06UecHwzy-K9FpNoRxCJp2wIGM9u2Edk-PLMZ1H4",
 "s" : "0",
 "t" : "bis",
 "ra": {
    "i": "ELh3eYC2W_Su1izlvm0xxw01n3XK8bdV2Zb09IqlXB7A",
    "s": "2",
    "d": "Ezpq06UecHwzy-K9FpNoRxCJp2wIGM9u2Edk-PLMZ1H4"
  }
}-eABEJJR2nmwyYAfSVPzhzS6b5CMZAoTNZH3ULvaU6Z-i0d80AAAAAAAAAAAAAAAAAAAAAAwELvaU6Z-i0d8JJR2nmwyYAZAoTNZH3UfSVPzhzS6b5CM

Credential Revocation Event

{
 "v" : "KERI10JSON00011c_",
 "i" : "Ezpq06UecHwzy-K9FpNoRxCJp2wIGM9u2Edk-PLMZ1H4",
 "s" : "1",
 "t" : "brv",
 "p" : "EY2L3ycqK9645aEeQKP941xojSiuiHsw4Y6yTW-PmsBg",
 "ra": {
    "i": "ELh3eYC2W_Su1izlvm0xxw01n3XK8bdV2Zb09IqlXB7A",
    "s": "4",
    "d": "Ezpq06UecHwzy-K9FpNoRxCJp2wIGM9u2Edk-PLMZ1H4"
  }
}-eABEJJR2nmwyYAfSVPzhzS6b5CMZAoTNZH3ULvaU6Z-i0d80AAAAAAAAAAAAAAAAAAAAABAELvaU6Z-i0d8JJR2nmwyYAZAoTNZH3UfSVPzhzS6b5CM

Use Case

The Verifiable Legal Entity Identifier (vLEI) provides a lightweight, easy to understand use case for a Transaction Event Log as a Verifiable Credential Registry. Issuing a VC has been described above. Verification of a VC will start with the presentation of a vLEI VC as proof (all vLEI VCs are public and therefore proof presentation will include the entire vLEI VC). The verifier will extract the DID of the issuer from the VC, and calculate the hash digest of the serialized contents of the VC. By parsing the namespaced identifier of the VC, the verifier will perform the following steps:

1. Retrieve the key state from the KERI did method (or appropriate DID method tunnel) using the controller identifier embedded in the VC identifier
2. Retrieve and verify the KEL against the key state of the issuer
3. Retrieve the management TEL using the Registry identifier embedded in the VC identifier and determine the Registrars to use to retrieve the VC TEL.
4. Retrieve the VC TEL and calculate the issuance/revocation state of the VC from the events in the TEL.
5. Using the keys from the KERI event to which the iss event is anchored, verify the signature on the VC.

Security Considerations

1. To avoid DDoS attack by flooding an Endorser with TEL events that are not associated with any identifiers they are associated with, TEL events need to be placed in escrow until an anchoring KEL event is seen for the TEL identifier.

[SmithSamuelM]

Missing the details of the inception and rotation events for the TEL creation.

[SmithSamuelM]

We discussed two ideas for TEL events. In one the message is like a receipt for disjoint async transmission. In this case the message itself references the anchoring event and the attachment is the TEL event.

What it appears above is that the message is the TEL event and the attachment is the reference to the anchoring event. In either case the example is incomplete without the attachments.

[pfeairheller]

Updated the contents of the issue to address the issues listed.

Fixed the nomenclature. A Registry is created by a controller who wishes to issue credentials. A Registry consists of one management TEL (with its own set of events) and verifiable credential TELs (with a set of events for this transaction set) for each verifiable credential.

The identifier of the Registry is placed in the namespace of the controller and the verifiable credential is placed in the namespace of the Registry

The event location seal is included with each event, linking back to the anchoring KEL and is included as an attachment. Examples have been updated.

Removed the vr field from the VC TEL events because it is duplicated in the identifier of the VC.

[pfeairheller]

Added vr back into the VC events and changed it to an event seal. In order to determine the proper set of backers for a given VC event, the location in the management TEL is needed when the VC event was published.

[SmithSamuelM]

Lets talk about this in our meeting this afternoon at 3 pm MT or sooner if you like. I am free after 12 MT

The event location can be provided with an attachment group. The same way that we are proposing to use an attachment group to a 'rct' so that we can drop the 'vrc'. The essential difference between an rct and vrc is the event seal of the validator in order to determine the proper set of keys. Now it may well be that we would rather include the event seal in the VC events but not because we don't have any other way of attaching that information. Its confusing I know. We have to think about other reasons that we want the seal in the event itself. Leaving it out simplifies the issuers code. It doesn't have to lock its processing while it issues VC events because it can wait until after it puts the digest in an anchor in its KEL before it creates the attachment not the other way around. But there may be a security or other reason why we want it in the event. I don't think so but its worth exploring to make sure.

[pfeairheller]

Updated issue.

Introduced Registries that will not have TEL specific backers but instead rely on the witnesses of the controlling TEL. Added a config option c to the management TEL inception event and simple events sis and srv for backer-less VC events.

The management TEL events require the seal to the controlling KEL to ensure each Registry is uniquely linked to one KEL. The seal was moved back into the event in the new field ia for issuer anchor.

[SmithSamuelM]

After our discussion and thinking about it some more I think we should modify the Registry Inception and Rotation as modified above. The Registry inception event and Rotation event now include a location seal to the event in the Issuer's KEL that has an anchoring seal to the event. We did this for convenience. As we discussed all that we need for security is the id of the Issuer in the body of the Reg Inception and Reg Rotation. We can put the other elements of the location seal in an attachment. They were include in the event for convenience. But actually putting the other elements of the location seals in the event makes the verification code less convenient. A location seal does not have the digest of the anchoring event because its a cross anchor and the anchoring event has to put its seal in place before its own digest may be created. So the location seal has the digest of the previous event and the event type to ensure that the lookup points to the correct event (a recovery may change the event type). This makes the validation code more verbose. Also the Issuers code must block on the issuance while its creating a Registry event because otherwise the location seal would be wrong. But with an attachment it doesn't have to create the attachment to the Registry event until its already anchored it. Thus is could use concurrent processing to do issuances in parallel. This is a scalability convenience/inconvenience. Moreover if all we put in the body of the Registry Inception and Rotation is the ID prefix of the Issuer then the attachment may be an event seal not a location seal because it may include the actual digest of the anchoring event. This simplifies the lookup and validation code. So my suggestion is we only put the issuers identifier prefix in the body of the Inception and rotation event and put the sn and digest of the issuing event in an attachment.

{
 "v" : "KERI10JSON00011c_",
 "i" : "ELh3eYC2W_Su1izlvm0xxw01n3XK8bdV2Zb09IqlXB7A",
 "ii": "EJJR2nmwyYAfSVPzhzS6b5CMZAoTNZH3ULvaU6Z-i0d8",
 "s" : "0",
 "t" : "vcp",
 "b" : ["EpDA1n-WiBA0A8YOqnKrB-wWQYYC49i5zY_qrIZIicQg"],
 "c" : ["NB"],
}

Attached s and d (not p) of anchoring event in issuing KEL

[SmithSamuelM]

As we have done elsewhere in KERI, the rule appears to be that when we use a double letter label that the first letter is a grouping modifier and the second letter is the type of the value wt kt da di etc

Following this rule I suggested ii for issuer identifier in the Registry Inception and Revocation where issuer is the modifier first and identifier is the type second . I think therefore to be consistent with this rule that the identifier for the registry should be ri in the simple credential events and the anchoring seal should be ra in the complex events.

{
 "v" : "KERI10JSON00011c_",
 "i" : "Ezpq06UecHwzy-K9FpNoRxCJp2wIGM9u2Edk-PLMZ1H4",
 "s" : "0",
 "t" : "sis",
 "ri": "ELh3eYC2W_Su1izlvm0xxw01n3XK8bdV2Zb09IqlXB7A"
}-lABEJJR2nmwyYAfSVPzhzS6b5CMZAoTNZH3ULvaU6Z-i0d80AAAAAAAAAAAAAAAAAAAAAAwixnELvaU6Z-i0d8JJR2nmwyYAZAoTNZH3UfSVPzhzS6b5CM

{
 "v" : "KERI10JSON00011c_",
 "i" : "Ezpq06UecHwzy-K9FpNoRxCJp2wIGM9u2Edk-PLMZ1H4",
 "s" : "0",
 "t" : "iss",
 "ra": {
    "i": "ELh3eYC2W_Su1izlvm0xxw01n3XK8bdV2Zb09IqlXB7A",
    "s": "2",
    "d": "Ezpq06UecHwzy-K9FpNoRxCJp2wIGM9u2Edk-PLMZ1H4"
  }
}-lABEJJR2nmwyYAfSVPzhzS6b5CMZAoTNZH3ULvaU6Z-i0d80AAAAAAAAAAAAAAAAAAAAAAwixnELvaU6Z-i0d8JJR2nmwyYAZAoTNZH3UfSVPzhzS6b5CM

[SmithSamuelM]

@phil (this was me thinking in my sleep) =)

[pfeairheller]

Good suggestions for the new field labels, those three (ii, ri, ra) fit very nicely here.

We went back and forth on the exactly how to anchor the management TEL and the trade off you describe here makes sense. The duplication of the issuer identifier in the ii field and the attachment seal is a low price to pay for the simplification of the events and the performance optimization, as well as using an event seal instead of the event location seal.

[SmithSamuelM]

Now that I think about it. For the same reasons I believe we can apply this same simplification to the KERI delegated identifier events. As you may recall the protocol for creating delegated inception and rotation involves multiple back and forth steps. I always knew this was a performance problem. Imagine a rest interface where a delegated identifier node wants to do a rotation. It has to submit to the delegator node a request for a rotation.The delegator responds with the event sn and type of the new event which will anchor the delegation. The delegator now has to block its processing, it can't create any new events until it completes the delegation. It has to wait for the delegate to respond with the finished delegated event so the delegator can digest it and then put an anchor in it event. IF any of these steps timeout due to network problems then it becomes a performance issue for the delegator. I never liked that but I didn't see away around it at the time. But now that we have complex attachments we can similar simplify the KER delegated events. and remove the location seals and only have the delegator's id in the delegated event and attach the delegating event s and d to the delegated event. This removes this handshake. Delegated identifiers may be created asynchronously by the Delegator. The delegate can create the full delegated event send it to the delegator who anchors it and sends back an attachment in its reply with the sn and dig that points to the delegating event.

From a security perspective it doesn't matter if there is more than one delegating event. Anyone is sufficient to authorize the delegation. The ordering doesn't matter as long as there is one. The first seen rule of the delegate's KEL means it won't see an event if it hasn't been anchored and it can look it up. There is an odd corner case where the delegated event anchors do not appear in the same order in the delegator's KEL as they appear in the delegate's KEL. I don't think this matters. The ordering that is authoritative is the delegates KEL not the delegators. A delegator can't predict a future rotation event because it doesn't know the delegate's perorated keys. So the corner case would only happen if the delegate created event requests close together and the delegator processed them asynchronously.
This is good we simplified KERI!

[m00sey]

As we discussed yesterday regarding "backer-less" VC events been the most common use case. Do we want to keep those as iss and rev and have a special case for "backed" VC events (bis brv).

[SmithSamuelM]

@m00sey

As we discussed yesterday regarding "backer-less" VC events been the most common use case. Do we want to keep those as iss and rev and have a special case for "backed" VC events (bis brv).

That seems reasonable

[SmithSamuelM]

I think we can adapt the security consideratons language from this issue for KERI delegation for TELs. https://github.com/decentralized-identity/keri/issues/146 This biggest difference is that in a TEL there is only one set of keys so there is only one party that makes a verifiable committment. But what is the same is that the first seen rule of any verifier of the TEL event ordering is authoritative for that verifier. So a malicious issuer could create issuing seals in its KEL to authorize issued TEL events in different orders but those alternate TEL events would be detectable as duplicitous. Only the first seen order matters and a latter key compromise won't change that. So we don't need cross anchors to the KEL but we still need a commitment in the issuance./revokation events to the Registry backer set which is provided by the event seal as shown above.

[pfeairheller]

Added p field for prior event digest, needed for all non-inception TEL events. Remove ii an ri from non-inception events as the commitment to the inception event with the p field includes a commitment to those immutable values established in the inception events.

[SmithSamuelM]

The registry inception and rotation events need a backer threshold bt field so we know how many backers must be in agreement.

[pfeairheller]

@SmithSamuelM should the rotation events then also include ba and br for adds and removes like the KEL rotation events?

[mitfik]

Should we elaborate a bit more about the privacy of such verifiable credential registry to show what would be the different between public registry (e.g. GLEIF) vs private one where just a correlation information could cause problems (knowing the fact that someone have the VC could be problematical). E.g. how it would work just with revocation list - no issued state just revoke.

[SmithSamuelM]

both Namespaced and non-namespaces support for VC identifiers in events. Current examples show only non-namespaced DID is a namespace.

need to setup Prefixer to support namespace derivation. (i.e. specify namespace to insert method specific ID)

[pfeairheller]

Updated title and introductory text to clearly specify that this defines a reference implementation for Public VCs.

Added 4 more events in support of VCs that do not use self-addressing identifiers.

Added mention of including attachment for VCs that use DID syntax for their IDs.

[SmithSamuelM]

Add the definition of self-addressing identifier from https://github.com/WebOfTrust/vLEI/issues/2 and then use the term self-addressing identifier to refer to the specific type of hash digest used for VC identifiers in the TEL (and registrars etc)

Self Addressing Identifiers

The advantage of a content addressable identifier is that it is cryptographically bound to the contents. It provides a secure root-of-trust. Any cryptographic commitment to a content addressable identifier is functionally equivalent (given comparable cryptographic strength) to a cryptographic commitment to the content itself.

A self-addressing identifier is a special class content-addressable identifier that is also self-referential. The special class is distinguished by a special derivation method or process to generate the self-addressing identifier. This derivation method is determined by the combination of both a derivation code prefix included in the identifier and the context in which the identifier appears. The reason for a special derivation method is that a naive cryptographic content addressable identifier must not be self-referential, i.e. the identifier must not appear within the contents that it is identifying. This is because the naive cryptographic derivation process of a content addressable identifier is a cryptographic digest of the serialized content. Changing one bit of the serialization content will result in a different digest. A special derivation method or process is required.

Derivation Process

This process is as follows:

• replace the value of the id field in the content that will hold the self-addressing identifier with a dummy string of the same length as the eventually derived self-addressing identifier
• compute the digest of the content with the dummy value for the id field
• prepend the derivation code to the digest and encode appropriately to create the final derived self-addressing identifier replace the dummy value with the self-addressing identifier

As long as any verifier recognizes the derivation method, the 'self-addressing` identifier is a cryptographically secure commitment to the contents in which it is embedded. It is a cryptographically verifiable self-referential content addressable identifier.

Because a self-addressing identifier is both self-referential and cryptographically bound to the contents it identifies, anyone can validate this binding if they follow the binding protocol outlined above.

To elaborate, this approach of deriving self-referential identifiers from the contents they identify, we call self-addressing. It allows a verifier to verify or re-derive the self-referential identifier given the contents it identifies. To clarify, a self-addressing identifier is different from a standard content address or content addressable identifier in that a standard content addressable identifier may not be included inside the contents it addresses. The standard content addressable identifier is computed on the finished immutable contents and therefore is not self-referential.

Self-Addressing Identifiers in a TEL

ii issuer identifier is the controller prefix is self-certifying and may be also self-addressing (but may not be) wrt to its inception event (For GLEIF TELS the issuer identifier must be self-addressing)

ri, i registry identifier is self-addressing wrt the registry inception event i VC identifier is self-addressing wrt to the VC itself

[pfeairheller]

The contents of this issue have been moved to tel.me and changes will be tracked there with PRs to its contents.