A normative requirement that required fields in field maps must be qb64 encoded should be added (at least for certain serializations)
Opened this issue · 4 comments
All the event examples contain the required fields for those event types in field maps, notably JSON as already noted in the spec.
However, is there a normative requirement that the required fields contain qb64 encoded CESR primitives or are other encodings supported? To me it seems like we should add this normative requirement for clarities sake. For example all the fun ways to encode binary data in JSON (which does not support a primitive that maps directly to binary data) seems like it would add more ambiguity and worse, provide for differing digests for the same data (leading to different AIDs at inception for example).
As I couldn't find it, we should add a normative requirement that all fields that contain qb64 primitives that aren't raw CESR types in field maps should be encoded in urlsafe qb64.
EDIT: Also the phrase fully qualified should be defined. We link to the whitepaper supposing that term is defined there but really its just defined as "a primitive with a prepended derivation code" in that doc and not as anything substantial. As a savvy CESR user my first thought is to ask, why can't I put a fully qualified qb2 representation (in whatever flavor the serialization will allow) and claim I meet the spec. Obviously this would hurt interoperability so we should define it explicitly.
qb64 means CESR as in Qualified Base 64 vs Base 64. So there is no allowance for anything but CESR as that is what qb64 means. The Q in QB64 means qualified, i.e. has a CESR code that qualifies it.
Totally, then the fix for this issue would be to make that clear in the spec because there's also a "fully qualified" binary in CESR too right? I will push a PR though with a definition if that's okay.
Totally, then the fix for this issue would be to make that clear in the spec because there's also a "fully qualified" binary in CESR too right? I will push a PR though with a definition if that's okay.
Yes that looks like an oversight, because the KERI white paper carefully defines qb64 for qualified base64 and qb2 for qualfied base2 but those definitions preceeded the use of the term CESR so we need definitions of qb64 and qb2 in the terms section of the specs that differentiate the formats i.e. a CESR primitive may be either qb64 or qb2 but field values inside JSON, CBOR, and MGPK field maps MUST be qb64 not qb2.
.
Cryptographic primitives are too large for most encoding binary formats, so they universally use strings but because any 8 bit value it possible the strings have to be encoded specially like UTF-8, which in JSON means that some characters may be escaped etc. Which gets messy very quickly and potentially much more verbose then Base64 encoding. So qualified base64 qb64 is just short hand for CESR Text Domain. And qb2 is just short hand for CESR binary domain. But before we had CESR as a spec we had the three domains raw, qb64, qb2