[CAIP-196] UCANs with header entries

[chunningham]

CAIP-196 defines a straightforward way of transforming back to UCAN serialisation which works almost all the time, however it does not account for header entries apart from alg and typ. While UCAN headers MUST contain these fields, they may also contain any other JWT-specified or unspecified headers (at least, there's nothing in the UCAN spec proscribing this). In principle it seems like they could not be stored in the fct field, as a UCAN can have any fcts and they can conflict. How could a non-alg or typ header field be stored in a CACAO? Should CACAO restrict the set of headers acceptable in UCANs (similar to requiring the UCAN be signed in canonical form in order to be verifiable)?

[oed]

My thought here is that there might be a need for a JWT varsig encoding that stores all additional headers in the varsig bytes. However, this wouldn't work for UCAN because there's a ucv field in the header that should go into the version field of the CACAO. This means that UCAN likely need a custom varsig encoding anyway.

[chunningham]

makes sense, every header except ucv, alg and typ encoded together as dag-json or dag-cbor? An adjacent question about varsig, if we're encoding a self-describing/framed data structure, is it necessary to prefix with length?

[oed]

if we're encoding a self-describing/framed data structure, is it necessary to prefix with length

I don't think we need to add a length prefix if we can tell when the data ends in other ways.