Closed nedmsmith closed 9 months ago
Given a use case for an attestation results or other message that conveys other CMs that are relevant to a particular attestation result. Does it make sense to continue following the convention of using tagged cbor - as in:
tagged-cmw-record = #6.4711(bytes .cbor cmw-array)
A possible triple record structure that treats other CMs as triple objects might be:
ar-triple-record = [ attester: stateful-environment-map, ar-claims: [ + $ar-claims-type-choice ] ] $ar-claims-type-choice /= tagged-cmw-record
The argument against is that cmw-array already has tagged values and the little bit of CDDL inside of
ar-claims:
isn't enough to warrant needing a CBOR tag. The argument for is that all$ar-claims-type-choice
possibilities are expected to betagged-xxx
values that can be dispatched by a parser dispatcher following a consistent convention.
In the context of a triple's object type choice, I think it makes total sense to add the extra tag.
Did this issue get resolved?
Did this issue get resolved?
The question is who should be responsible for registering the tag:
(For the record, I am fine either way.)
I think it would be convenient for this I-D to allocate a CBOR tag for tagged-cmw-record
.
E.g.: tagged-cmw-record = #6.TBA(cmw-record)
quick note: this tag is to be used only for the CBOR array- and CBOR tag-based serialisations.
Fixed in #33
Given a use case for an attestation results or other message that conveys other CMs that are relevant to a particular attestation result. Does it make sense to continue following the convention of using tagged cbor - as in:
A possible triple record structure that treats other CMs as triple objects might be:
The argument against is that cmw-array already has tagged values and the little bit of CDDL inside of
ar-claims:
isn't enough to warrant needing a CBOR tag. The argument for is that all$ar-claims-type-choice
possibilities are expected to betagged-xxx
values that can be dispatched by a parser dispatcher following a consistent convention.