probably another header param

https://mailarchive.ietf.org/arch/msg/cose/pN_fwn5ting_gBIGU-ngYoQu3Ss/

Provide guidance on headers when they appear in COSE_Encrypt, warn about metadata leaks

Pre-hash with domain binding.

Usage

{      
  / Algorithm                           /                        
  1: -35,                        
  / Key identifier                      /
  4: h'75726e3a...32636573',     
  / typ of the envelope                 /
  TBD 0: application/hashed+cose 
  / Hash algorithm of the payload       /
  TBD 1: sha-256                  
  / cty of the preimage of the payload  /
  TBD 2: application/jwk+json    
}

Add a single header for an instance or set of COSE_Hash_V, instead of multiple headers... as discussed in #7 (comment)

See if there is any aligning we can do, and add informative text relating the concepts

https://datatracker.ietf.org/doc/html/draft-ietf-cose-x509-08

label 3 content type is the type of the actual payload. This draft states the content type of the payload is a hash.
The TBD_2 pre-image content type (applicatoin/json) provides the formatting of the content of the un-hashed payload.
We also now have 16 typ (RFC9596, which would have something equivalent to application/hashed+cose
When using hash payload, what values should/must be populated:

{
  / alg : ES384 / 1: -35,
  / kid / 4: h'75726e3a...32636573',
  / typ / 16: application/hashed+cose
  / payload_preimage_content_type / TBD_2: application/jwk+json
  / content-type / 3: applicatoin/hashed+cose
  / payload_hash_alg sha-256 / TBD_1: 1
  / payload_location / TBD_3 : storage.example/244f...9c19
}

• Since 3/content-type is optional, should 3 not be specified, as it's essentially duplicated by 16 + TBD_1
• Should 3 be equal to /typ / 16: application/hashed+cose

The draft should specify the behavior, in the informative section at a minimum