Summary

  • RFC 9597 registers a CWT Claims map in COSE header parameter 15 so selected claims can be visible before decryption, with detached content or beside a non-CWT payload.
  • A visible issuer, audience or identifier is not yet an authenticated fact; any routing, lookup or parser choice made before cryptographic validation is tentative and must be confirmed afterward.
  • Duplicate claims in a CWT payload and header normally have to match, while privacy, type interpretation, key authority, local authorization and observed effect remain separate controls.

A gateway receives an encrypted COSE object. Its payload cannot yet be read, but a CWT Claims header exposes an issuer. The gateway uses that value to choose a key-discovery service. The lookup returns a key, the object decrypts and the signature verifies. A dashboard records “trusted issuer.”

That last sentence may still be wrong.

The issuer value could have come from an unprotected header. A protected value could have been interpreted under an unprotected type hint. The key discovery service might have returned a technically valid key that was not authorized for this object class. The decrypted payload could repeat a different issuer. The audience could exclude this endpoint. The object might be authentic and still not authorize the requested operation.

RFC 9597 standardizes a useful bridge for exactly the first part of that chain. It defines how CWT claims can appear in a COSE header, including when an encrypted payload must remain opaque, a signature uses detached content, or the payload is not a CWT Claims Set and may not even be CBOR. The standard makes early inspection interoperable. It does not turn early inspection into final trust.

One container prevents a namespace collision

CWT claim keys and COSE header labels both use compact integers. Placing each CWT claim directly in the COSE header would create collisions between the two registries. RFC 9597 therefore registers one COSE parameter, “CWT Claims,” with label 15. Its value is a map keyed by CWT claim labels.

The map can carry familiar claims from RFC 8392: issuer, subject, audience, expiration, not-before, issued-at and token identifier, as well as claims registered later in the IANA CWT registry. The IANA COSE registry coordinates the outer label. RFC 8610 supplies the CDDL notation used to describe the map.

These registries solve identification. They do not decide which claims an endpoint requires, what a claim means in a particular protocol, which issuer may assert it or what action follows. The common layer names the container. The application still owns the consequences.

The parameter may be used with any COSE object that has headers. It is not limited to CWT payloads. An image, firmware object or another binary structure can be signed while an issuer claim is exposed for key discovery. That flexibility is operationally valuable, but it removes a tempting inference: seeing CWT claims does not prove that the payload is a CWT.

Protected placement narrows malleability, not authority

RFC 9052 separates protected and unprotected COSE header maps. RFC 9597 recommends placing CWT Claims in the protected map because an unprotected value is malleable. It also permits the parameter only once across the two maps.

“Recommended” matters. An implementation cannot assume that every received CWT Claims map is protected merely because a sensible producer would protect it. The acceptance profile must say whether unprotected placement is rejected, preserved only as an untrusted hint or allowed for a sharply bounded purpose.

Even protected placement proves less than many dashboards imply. Cryptographic protection binds the claim bytes within a particular COSE security operation. It does not establish that the signer was competent to assert that issuer, that the audience includes this service, that the claim is fresh, that a key-discovery response was authorized, or that the requested business action is permitted.

The protection of interpretation matters too. RFC 9597 says the intended meaning must be unambiguous and recommends the typ parameter from RFC 9596 when the application has no natural alternative. If the claims are protected but the type or context selecting their meaning is not, the decision chain has a weak joint. Integrity must cover both the assertion and the rule that says what the assertion is.

Early work must remain provisional

The RFC's sharpest operational sentence is in its security considerations: processing claims before their integrity is cryptographically secure can be risky, and tentative decisions made from unverified information must be confirmed after cryptographic processing.

Key discovery is the obvious case. A receiver may need an issuer or key identifier before it knows which key can verify an object. This circularity cannot be wished away. The safe design does not prohibit every early lookup; it limits what the lookup is allowed to cause.

An unverified issuer may choose a lookup namespace, but it should not grant a tenant context. It may select candidate keys, but it should not approve an operation. It may choose a decoder budget, but it should not open an unlimited parser. It may route work to an isolation queue, but it should not commit irreversible state.

The receipt chain should record the exact received bytes, whether label 15 was protected, the early claim value, the provisional branch, the key-discovery request, the returned candidate, the cryptographic result, the interpretation source, the payload comparison, the application policy and the final action. If validation fails, the provisional state must be revoked or quarantined, not left behind as a cached identity fact.

This is where running code outranks reassuring vocabulary. A design document can say “verified later.” Only execution logs, negative tests and observed rollback show that later verification actually controls the earlier branch.

Two copies require a comparison rule

RFC 7519 established a similar mechanism for selected JWT claims in JOSE headers. RFC 9597 brings the capability to CWT and adds a direct consistency rule: when a CWT claim appears in both the payload and the header, the receiving application must verify that the values are identical unless it defines another specific processing rule.

The comparison closes an important confusion path. A gateway cannot route on header issuer A while a downstream service authorizes payload issuer B and then describe both as processing the same token.

But equality is not validation. Two identical expiration values can both be stale. Two identical audiences can both exclude the receiver. Two identical issuer values can both come from an unauthorized signer. The equality receipt answers “did the copies diverge?” It does not answer “is the claim true?” or “may this operation proceed?”

An application that deliberately permits different copies needs a precise rule: which component consumes which copy, why divergence is safe, what protection covers each value and how the decision is audited. “The profile allows it” is not enough without the profile version and executed branch.

Visibility can defeat encryption's privacy promise

The reason to move a claim into a header is often that somebody must see it before decrypting the payload. That means the claim is outside encryption. RFC 9597 warns that registered CWT claims can contain privacy-sensitive information and that COSE objects carrying them should be visible only to appropriate parties.

An issuer can reveal an organization. A subject can identify a device or person. An audience can disclose the intended service. A token identifier can support correlation. A deployment that copies all claims “for observability” can turn an encrypted token into a tracking envelope.

The privacy decision must therefore precede serialization. Which minimal claim is needed for the early task? Who can observe it on the transport, in queues, logs, caches and error reports? How long is it retained? Can a coarse routing realm replace a stable subject? Cryptographic correctness does not authorize disclosure.

Detached content extends the evidence chain

COSE can protect detached content, but RFC 9052 leaves the application responsible for transporting those bytes without change. A header issuer and a valid COSE structure do not prove that the verifier fetched, hashed and processed the intended detached payload.

The system must preserve the payload locator or retrieval context, the exact bytes or digest, the association with the COSE object and the validation result. Otherwise an early claim can successfully choose a key while the later payload belongs to another transaction.

The final statement should be narrow: this header claim was visible; this exact value and interpretation were protected by this validated object; any duplicate payload copy matched under this rule; this local policy accepted the result; this action was attempted; this effect was observed. No earlier receipt should impersonate a later one.

Sources