Extracting s from ACDC into CESR-based protocol

[blelump]

Hey Sam,

The digitalization of various industries is a direct consequence of vast data generation. Controllers responsible for reading the sensor data push it further to the cloud for further processing. Before the actual push, the Controller might digitally sign the data-to-be-pushed to add authenticity. Here we can employ CESR and attach the signature to the measurement effectively. When there are many measurements, it becomes more challenging because we can sign a bulk instead of signing each measurement.
Furthermore, measurements have schemas that define what is in the actual body of the measurement. In the credentials space, i.e., ACDC, you'd use s to provide the schema, but in the case of measurement, ACDC-like schema is debatable. To make it compact, I imagine something like this:

{measurement1}{measurement2}...{measurementN}CESRattachments.

where CESRattachments are about the whole bulk rather than each measurement. Furthermore, we can also distill the schema for all these measurements. Schema is like the digital signature: metadata. We could then define another protocol using CESR to add the capability to add the schema as a CESR attachment. Using Protocol Genus Version Codes, we can switch between protocols in one CESR stream.

There are issues with this approach:

• {measurement1}{measurement2}...{measurementN}CESRattachments stream format is not supported. Bulks can occur, for example, in unstable environments where internet access is, i.e., temporary. When the controller is offline, it aggregates all the measurements and will eventually push it further as soon as it becomes online again.
• a dedicated protocol to attach schemas via CESR attachment is fine but lacking authenticity. Assuming even a single measurement:

  {measurement1}CESRattachments
  

  where CESRattachments are --AAA<KERI protocol attachments>---AAB<schema protocol attachments>. The latter lacks authenticity because digital signature(s) are against whatever is in measurement1. Thus, the attachments in the schema protocol can be forged.

[SmithSamuelM]

Is there a question? or just wondering how one might use CESR to effeciently sign measurements?

[blelump]

Let me be more explicit:

• do you see potential in proposing another CESR-based protocol solely about the semantics of the message you're attaching it to? I am considering supporting all the cases where the underlying data structures require different streaming approaches to make it effective (by making it compact). A single measurement would then look like the following:

  {measurement1}
  ---AAA<KERI protocol attachments>
  ---AAB<semantics protocol attachments>
  

  With such a construct, I benefit from the CESR because I do not modify the message (measurement1) but attach metadata to it. I get authenticity with the AAA protocol, and with AAB protocol, I get the message schema. The underlying flaw of this proposal is that AAA and AAB are distinct, and I cannot include in the signature from AAA the content of AAB. By simply attaching metadata via CESR protocols, such layering enables the separation of data, schema, and signature. What do you think about this?
• how do you perceive effective streaming of measurements that are a) authentic, b) schema rich, and c) a collection rather than a single entity? Right now, CESR supports the following representation:

  {measurement1}CESRattachments{measurement2}CESRattachments...{measurementN}CESRattachments
  

  but what if we'd extend it to the following format:

  [{measurement1}{measurement2}...{measurementN}]CESRattachments
  

  where [ and ] encompasses the collection.

[SmithSamuelM]

but what if we'd extend it to the following format:
[{measurement1}{measurement2}...{measurementN}]CESRattachments

that works.

Or another alternative is as follows

Hash [{measurement1}{measurement2}...{measurementN}]
Hash[Verbose attachments}
CESRAttachments (transmitted)

then the measurements can be cached or transmitted out of band to the transmission of the Hash
or alternatively the attachments can be cashed and transmitted out of band to the hash.
This is expecially useful when the attachments include schema which tend to be verbose but do not change often. So one can performantly cashe schema and only transmit it once and then transmit the hash of the schema with the measurement.

This is how ACDCs do it. A compact ACDC is nothing but hashes and the attachments are nothing but a reference to a signature of the hashes. this way verbose schema which do not change across multiple ACDCs of the same type (recall that in ACDC type is schema) then never need to actually transmit schema just pre-provision schema as type and reference the measurement as belonging to a type given by the hash of the schema.

So yes, using the same artchitecture of ACDCs but without revocation support one can have more compact messaging of measurements. Because ACDCs are schema based they can have optional fields (unlike KERI events which have fixed fields at the type level). So one can simplify an ACDC to be

version
packet id (SAID)
Issuer AID
type as schema SAID
attributes as SAID
Attachments (signatures or reference to anchoring seal}

Currently ACDCs assume that they are anchored in KEL of issuer but for ephemeral (non-revocable) measurements one can relax that requirements and then only an attached signature is required.

Fpr example a ViRA ACDC payload is just a list of hashes.