Difference in semantics of message fields in events vs receipts

[stevetodd]

The identifier prefix has different semantics among message types. In events, the identifier prefix identifies the generator and signer of the message. In receipts, the identifier prefix relates to the event being receipted. The current structure does allow the system to work, though it was counter-intuitive when I first encountered it.

To be more intuitive, I would propose the following structure for receipts:

{
  "v" : "KERI10JSON00011c_",
  "i" : "AYAfSVPzhzS6b5CMaU6JR2nmwyZ-i0d8JZAoTNZH3ULv", 
  "s" : "4", 
  "t" : "rct",
  "d" : "DZ-i0d8JZAoTNZH3ULvaU6JR2nmwyYAfSVPzhzS6b5CM",
  "a" : 
        [
          {
            "i" : "AaU6JR2nmwyZ-i0d8JZAoTNZH3ULvYAfSVPzhzS6b5CM",
            "s" : "1",
            "d" : "DZ-i0d8JZAoTNZH3ULvaU6JR2nmwyYAfSVPzhzS6b5CM"
          }
        ]
}
(signature count)(signature)

The structure appears the same as a receipt by a transferrable identifier, but the root (i,s,d) coordinates are swapped with the "anchor" (i,s,d) coordinates. This is more verbose, for sure, but it also follows more in parallel with events that anchor data.

One nice thing this does is makes it work and appear similar to interaction events. Indeed, they are very parallel: the anchored data/seals in receipts, interaction events, and rotation events are attestations by the identifier identified at the root level of the message about the anchored data.

[stevetodd]

Described using a diff from the model in #88:

- Receipt(...Message, ...EventCoordinatesWithDigest, a:EventCoordinatesWithDigest) 
- // ^^^^ a:EventCoordinatesWithDigest must point to establishment event 
- //         (root) EventCoordinatesWithDigest point to receipted event
+ Receipt(...Message, ...EventCoordinatesWithDigest, a:[EventCoordinatesWithDigest]) 
+ // ^^^^ a:[EventCoordinatesWithDigest] points to receipted events
+ //         (root) EventCoordinatesWithDigest must point to establishment event


---

- Message(v:Version, t:MessageType, s:[Signature])
+ Message(v:Version, t:MessageType, ...KeyCoordinates, s:[Signature])
+ KeyCoordinates = EventCoordinatesWithDigest | EventCoordinatesWithPreviousDigest

[SmithSamuelM]

Doesn't work for multiple attached signatures because in this case the attached signatures are a couple of the identifier prefix and the signature. This allows any number of receipts to be conveyed by one message. Although your logic makes sense it makes a big sacrifice. Its not the only logic. A receipt is really just a signature we need to know what is being receipt and the signature couplet tells us who the signature is from. The nontransferable receipt needs the seal because its keys may be rotated so we need more information to figure out where the signature came from. the proposed change would require an array of signers verses merely a string of couplets as it is now. Its a big sacrifice

See the text from the KID 3

This receipt message may be generated by entities whose identifier prefix uses a non-transferable derivation code, i.e. ephemeral. This allows verification of the signature merely from the identifier prefix in the attached receipt couplet. This type of receipt may be used by witnesses, watchers who by design have non-transferable prefixes and by validators with non-transferable prefixes. Validators with transferable prefixes must use a different receipt message kind (see transferable receipt below ). Because each item of fully qualified cryptographic material in KERI is self-framing we may provide the receipt signatures as attached couplets. This is most compatible with streaming transport like the other KERI events. In this case we simply attach, after the receipt statement, a sequence of couplets where each couplet consists of the concatenation of the fully qualified Base64 representations of a given witness identifier prefix and the associated witness signature. In the case where the full message plus attached couplets are not framed into a packet (i.e. TCP), then a counter code (CryCounter) may be inserted after the event but before the first receipt couplet to indicate the number of attached couplets.

[chunningham]

IMO the current way is consistent if the identifier prefix is thought of not as an indicator of who created a message, but as the ID for the KEL to which the message belongs. In the proposed scheme, transmitting a KEL for a particular prefix would include messages which carry a different ID prefix to the one which the KEL belongs to. A few thoughts:

• A key difference between receipts and events like interaction events is that receipts do not have to appear in the KEL of the receipt creator, only the receipt receiver.
• Merging the two (by including a sequence number and so requiring the receipts in a KEL) the KEL of a receipt creator will get artificially long as all receipts must be included for KEL validation.
• Non-transferrable identifiers used as witnesses dont need KEL validation for asserting control authority, so there's no real need to include anything in their KEL

[SmithSamuelM]

Witnesses need to efficiently communicate receipts to each other in the set. Because they use (on purpose for this reason) non-transferable identifiers they may communicate the receipt merely with their prefix and signature. All that is needed is an indication of which event is being signed. So one witness sends one message with 20 signature and has fully sent all the receipts. This is by design.

[SmithSamuelM]

+1 @chunningham "but as the ID for the KEL to which the message belongs" Receipts are acknowledgements of events in a KEL

[stevetodd]

Ok, thanks, this is helpful.

So the main confusion is how I conceptually thought of Message, Events, and Key Events. In my mind, I had combined all three. Though I think now after a closer reading, it is saying that there are Message/Events and Key Events. Further, as you have both clarified, the identifier (field i) in messages is really the subject of the event and not the subject and the signer. Said differently, I read messages as being composed of the composer's identifier, the contents, and the composer's signature. In the case of Key Events (which up until this point was all I had implemented), the composer's identifier and the signer's identity were the same. For Receipts, the signers are witnesses.

So the receipt event is really just the mechanism of conveyance of receipts, which is really just the attached signatures of the witnesses on the message. My understanding is that these receipt event messages (e.g. JSON + signatures) don't get appended to the log as an event—the witness prefix + signature tuple is appended to an event, which is what I think I read in the keripy source.

It seems to me that receipt messages really belong in the communication/API layer. The distinction being that the key event log itself only concerns itself with the witness prefix + signature tuple and doesn't store the rest of the message. That's not to say it shouldn't be defined, but the functioning and verification of the log itself doesn't rely on the entire receipt messages, just the tuple that is conveyed by it.

[stevetodd]

Or at the very least, it seems silly to encode the receipt signatures outside of the message since the signatures aren't signing the receipt itself.

[SmithSamuelM]

May I close this issue?