Transaction Event Logs / Public VC Registry #133
Comments
|
Missing the details of the inception and rotation events for the TEL creation. |
|
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. |
|
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 |
|
Added |
|
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 |
|
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 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 |
|
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 |
|
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 Following this rule I suggested {
"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 |
|
@phil (this was me thinking in my sleep) =) |
|
Good suggestions for the new field labels, those three ( 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 |
|
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. |
|
As we discussed yesterday regarding "backer-less" VC events been the most common use case. Do we want to keep those as |
That seems reasonable |
|
I think we can adapt the security consideratons language from this issue for KERI delegation for TELs. decentralized-identity/keri#146 |
|
Added |
|
The registry inception and rotation events need a backer threshold |
|
@SmithSamuelM should the rotation events then also include |
|
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 |
|
both Namespaced and non-namespaces support for VC identifiers in events. Current examples show only non-namespaced need to setup Prefixer to support namespace derivation. (i.e. specify namespace to insert method specific ID) |
pfeairheller
changed the title
|
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. |
|
Add the definition of Self Addressing IdentifiersThe 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 ProcessThis process is as follows:
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 TELii 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 |
|
The contents of this issue have been moved to tel.me and changes will be tracked there with PRs to its contents. |
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:
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, andt. However, thesor sequence number field in TEL events represents the "clock" for that transaction set. Eachtransaction 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
sfield is simply a monotonicallyincreasing integer.
The events are anchored back to the KEL using Event Seals whose JSON representation is as follows.
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).
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.
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:
vcpfor Registry inception andvrtfor rotation of the list or Registrars. The events will reference the controlling identifier in the
iifield and beanchored 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
ifield 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.
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
celement is added to the management TEL inception event with theconfiguration option
NBto specify that the Registry will never have backers configured in the management TEL. Inthis case, there will only be one event in the management TEL for this Registry and the simple events
issand
revwill be used for "simple issue" and "simple revoke" respectively in the VC specific TELs. For these events,the
rifield will be the simple identifier referencing the management TEL.Registry Inception Event
Registry inception event for establishing the list of Backers
Registry inception event for "backer-less" configuration
Registry Rotation Event
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:
issfor simple VC issuance andrevfor simple revocation,
bisfor the issuance of the VCs with backers andbrvfor revocation of the VCs with backersand corresponding events
iis,irvandibs,ibrto be used when the identifier of the VC is not hashed from thecontents of the VC and that hash digest must be included is the separate
vifield in the event. The events will beanchored 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
idfield and taking a hash digest of the serialized contents of the VC. This form of self-addressingidentifier can be used as the
ifield in the TELiss,rev,bisandbrvevents and no other reference to the VCis required. When the identifier of the VC is derived from some other method, the TEL events
iis,irv,ibsandibrare used, and a hash digest of the contents of the VC is placed in thevifield.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
rotmanagement events listed above, the non-simple VC events (bis,brv) must be anchored to theevent in the management TEL at the point when the VC event is published with the
rafield. This way, the backersignatures can be indexed into the proper list of backers at the time of issuance or revocation.
Credential Issuance/Revocation TEL
Simple Credential Issuance Event
Simple Credential Revocation Event
Credential Issuance Event
Credential Revocation Event
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:
embedded in the VC identifier
to use to retrieve the VC TEL.
issevent is anchored, verify the signature on the VC.Security Considerations
associated with, TEL events need to be placed in escrow until an anchoring KEL event is seen for the TEL identifier.
The text was updated successfully, but these errors were encountered: