Re: [Anima] [media-types] Thoughts on suffixes, single and multiple

[Esko Dijk <[e-mail]>]

> The utility to the community is that if a dissector (debug tool) can see it's
> a signature, then it can, even without verifying the signature, dig down into
> the payload to show a developer what's what.   It seems reasonable to common
> tools will evolve to decode JWS and COSE, but not necessarily know what a
> voucher is.

I fully agree with this! A generic +jws or +cose or +cbor or +json viewer with syntax and 
component highlighting  would be super useful -- just like we have generic .txt / .json / .c  file viewers today. 
For +cose for example, the viewer can immediately extract the signed payload part without necessarily 
knowing how to validate the signature, or knowing what key it needs for that.

> Or maybe I should reverse this: in order for common tools to evolve, we need
> clear signals about the encoding of the signature blob.

Agree even more here :-)   

For the cBRSKI draft I looked at multiple suffixes, but saw it as getting too complex for us / the 
target population to understand and correctly apply. Without much benefit.  A single +name prefix is
useful however.

> I think that application/voucher-cms+json in RFC8366 was in the wrong.
> It should have been application/voucher-json+cms

Yes, I also saw this a while back - the +cms at the end would have been the right thing. 
A generic +cms viewer could for example extract, or highlight the payload and also separately
show the signing certificates even without necessarily being able to validate the CMS.
The CMS structure itself can also contain a number indicating the payload type, in eContentType.
The viewer can optionally use this to render the payload better.