Draft: Align with draft-ietf-cose-hpke-15.

[dajiaji]

No description provided.

[codecov]

Codecov Report

❌ Patch coverage is 84.94624% with 14 lines in your changes missing coverage. Please review.
✅ Project coverage is 97.01%. Comparing base (40fe8e0) to head (2a2803c).
⚠️ Report is 35 commits behind head on main.

Files with missing lines	Patch %	Lines
cwt/cose.py	63.15%	7 Missing ⚠️
cwt/recipient_algs/hpke.py	87.80%	5 Missing ⚠️
cwt/utils.py	91.30%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #638      +/-   ##
==========================================
- Coverage   97.34%   97.01%   -0.33%     
==========================================
  Files          32       32              
  Lines        3352     3418      +66     
==========================================
+ Hits         3263     3316      +53     
- Misses         89      102      +13     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[achamayou]

I apologise in advance for offering unsolicited feedback here, which I hope will be useful still.

It is uncommon, and fairly recent, but one soon-to-be standard parameter may only have a tstr value: 260 (payload-location), requested in cose-hash-envelope.

A user passing a protected header {"payload-location": "http://..."} would have their payload-location converted to a bstr by line 191, which although practically harmless, could be rejected by a strict parser/verifier.

Since the code below applies per-key validation, it may be that having per-key conversion logic is desirable. Another edge case may be the use of not-yet supported values for 1 (alg) or 16 (typ), which allow tstr for that purpose. A user may want to pass {"alg": "NEWCRYPTOALGO"}, and a strict verifier may enforce int / tstr and reject a bstr-encoded b"NEWCRYPTOALGO".