JWS protected 'typ' (application/didcomm-signed+json) is parsed but never validated on the verify path

[moisesja]

JwsParser decodes the protected header but never inspects typ, so a received signed envelope with absent, empty, or arbitrary typ verifies identically to one carrying the canonical media type.

Severity: Info
Category: spec-noncompliance

Affected code

• /Users/moises/Projects/didcomm-dotnet/src/DidComm.Core/Jose/Signing/JwsProtectedHeader.cs:25
• /Users/moises/Projects/didcomm-dotnet/src/DidComm.Core/Jose/Signing/JwsParser.cs:71

Details
JwsProtectedHeader declares a Typ property (JwsProtectedHeader.cs:25), and JwsBuilder sets it to application/didcomm-signed+json on emit (JwsBuilder.cs:86). But JwsParser.Parse decodes the protected header (JwsParser.cs:71) and validates crit, b64, alg, and the kid cross-check — yet never reads header.Typ (a grep for .Typ across the Jose tree finds only the builder's write). No other layer checks it: EnvelopeDetector.Detect classifies envelope kind purely structurally (ciphertext / signatures / signature+payload), media-type independent. Therefore a received signed envelope with absent/empty/arbitrary typ verifies identically and cannot cause envelope-kind confusion.

Non-compliance
No concrete attack exists: the envelope kind is determined structurally, not by typ, and RFC 7515 §4.1.9 treats typ as advisory only. FR-SIG-04 makes setting the signed typ a SHOULD on emit (and permits JWM in the construction header), with no MUST to validate typ on receive — so not enforcing it is within spec. Reported only as a hardening/observability note: the library does not assert that the envelope it verified actually claimed to be a DIDComm signed message.

Recommended fix
Optionally record header.Typ in the parse result for diagnostics, and (defense-in-depth) reject only clearly-wrong typ values while continuing to tolerate absent typ and JWM per FR-SIG-04. No functional change is required for spec compliance.

References
RFC 7515 §4.1.9 (typ advisory); DIDComm v2.1 §Message Signing; PRD FR-SIG-04 / FR-ENV-01

Filed from an automated multi-agent security & compliance review.

[moisesja]

Closing as spec-compliant — no in-repo change warranted (reviewed under the Batch D hardening pass, PR #41).

Why no code change:

1. The cited code was delegated. src/DidComm.Core/Jose/Signing/JwsParser.cs / JwsProtectedHeader.cs no longer exist — JWS verification is owned by the external DataProofsDotnet.Jose.JwsParser, whose JwsParseResult does not surface typ. An in-repo typ check isn't possible without an upstream API change.
2. It's advisory, with no MUST to validate on receive. RFC 7515 §4.1.9 treats typ as advisory; FR-SIG-04 makes setting the signed typ a SHOULD on emit (and permits JWM), with no requirement to validate it on receive. This issue itself states "no functional change required for spec compliance."
3. No confusion risk. EnvelopeDetector classifies envelope kind structurally (ciphertext / signatures / signature+payload), independent of typ — so an absent/arbitrary typ cannot cause envelope-kind confusion. Validating typ would risk a non-compliant over-tightening (rejecting absent/JWM).

If we want the diagnostic value later, the right move is an upstream enhancement to DataProofsDotnet.Jose to surface typ on JwsParseResult, then a lenient (absent/JWM-tolerant) record-only check here — tracked separately if desired. No spec-compliance gap remains.