Summary

  • RFC 9782 registers six EAT media types, a +cwt structured suffix and CoAP Content-Format identifiers, while an optional eat_profile parameter lets an API route a payload without inspecting its body.
  • The RFC calls media types clues to the processing application: receivers still have to prove that the bytes match the declaration, validate protection or channel scope, compare profile identity, check freshness and appraise claims.
  • A relying party needs its own decision record after the verifier's result. “Recognized and routed” is useful evidence, but it is never the same assertion as “trusted and authorized.”

The cleanest log can describe only the first metre

Remote attestation systems are built around handoffs. An attester sends Evidence. A verifier evaluates it against appraisal policy and produces Attestation Results. A relying party uses those results, plus a separate policy, to decide whether a machine, workload or transaction receives an application-specific privilege. Every handoff benefits from a stable way to say what kind of representation is moving.

RFC 9782 supplies that vocabulary. It registers application/eat+cwt and application/eat+jwt for protected EATs in the two familiar token families. It registers JSON and CBOR types for detached EAT bundles, where claims sets travel separately but are bound through digests to a protected main token. It also registers JSON and CBOR types for UJCS and UCCS, unprotected claims sets whose assurance must come from an appropriate secure channel and the receiving system's handling. For constrained deployments, the same six distinctions receive CoAP Content-Format numbers 263 through 268.

This is not merely clerical work. Before RFC 9782, an API could still carry these objects, but local identifiers and generic token labels made dispatch harder to reason about. A stable type lets a gateway reject an unsupported representation, negotiate an acceptable response with Accept, and select a narrower parser. The newly registered +cwt structured suffix also tells generic tooling that the underlying syntax is a CWT.

Yet this is a type system for representations, not a portable verdict. +cwt does not say which claims are present, who signed the token, which algorithm is permitted, where the verification key came from, how freshness was established or whether the recipient is allowed to act. The six names distinguish wire forms. They do not merge the security properties of those forms.

That difference matters most for the unprotected variants. RFC 9781 requires a receiver of UCCS in RATS use to authenticate the sender as part of establishing a secure channel and to receive integrity protection. Confidentiality requires authentication of the receiver as well. Once the claims set emerges from that channel, the channel no longer protects it. A process that stores the decoded claims and later forwards them has crossed a trust boundary even if every hop continues to call the object an EAT.

A fully formed CWT carried inside the same channel follows another rule: the channel does not endorse it. Its COSE envelope, key path and verification result remain the relevant evidence. The outer transport can authenticate its peer without authenticating the attester named or implied by the inner token. One Content-Type can therefore lead to very different protection receipts.

The profile parameter is a selector before it is a fact

EAT deliberately leaves many choices open. A use case must decide whether it accepts CBOR, JSON or both; which COSE or JOSE structures and algorithms it uses; how keys are identified; whether detached bundles are permitted; which claims are required; and how freshness is proved. RFC 9711 calls the document that narrows those choices a profile.

Each EAT can carry an eat_profile claim in-band. RFC 9782 adds an optional media-type parameter with the same name so an API can expose that profile before parsing the body. A URI parameter is quoted in HTTP; an OID can be represented as a token. A router can therefore send one EAT to a processor for one profile and another EAT to a different processor without “snooping” inside either payload.

That is a genuine control-plane improvement. It reduces the temptation to send every token to a universal parser and decide later what it might mean. It makes unsupported profiles visible at the edge. It can also bind content negotiation to a profile-specific form of Attestation Results.

But the external parameter is still a declaration supplied with the message. After safe decoding, the receiver has to compare it with the in-band claim. An absent parameter, where the interface allows one, is not the same state as an exact match. A mismatch is not a formatting nuisance to normalize away; it can indicate a wrong route, a stale intermediary, a confused client or an attempted substitution. The useful receipt records both values and the outcome of the comparison.

Nor does a matching identifier prove conformance. RFC 9711 says the eat_profile claim must not identify a partial profile. A full profile must be complete enough that a conforming receiver can decode, verify and check freshness for every EAT a conforming sender creates. The word “conforming” performs real work. A sender can insert a correct URI while choosing a forbidden algorithm, omitting a required claim or using the wrong nonce rule. A receiver can recognize the URI while failing to implement one of the allowed encodings. The label selects the checklist; only execution completes it.

First prove the bytes, then the envelope, then the claims

RFC 9782 states the boundary unusually plainly: media types provide only clues to the processing application. The application must verify that received data matches the expected format regardless of the advertised type, and it must stop on failure. Otherwise, privilege escalation and cross-protocol attacks can follow.

The requirement prevents a dangerous convenience: send the body to whichever decoder seems willing to accept it. Permissive sniffing may turn a wrong Content-Type into an ambiguous success. RFC 9110 warns about the same class of HTTP failure, and JWT best current practice recommends explicit typing plus mutually exclusive validation rules when one kind of JWT could be confused with another.

A defensible receiver therefore keeps several results apart. The dispatch result says which handler the header selected. The format result says whether the exact byte sequence matched that handler's grammar. The protection result says whether a COSE or JOSE envelope verified under an allowed algorithm and an accepted key, or whether an unprotected claims set remained inside the authenticated channel scope. For a detached bundle, another result binds every detached claims set to the digest carried by the protected main token.

Only then are there claims to interpret. Cryptographic validity establishes attribution and integrity within a defined key model; it does not establish that a sensor measured faithfully or that an implementation resists tampering. RFC 9711 explicitly separates claim semantics from implementation security. A receiver judges trustworthiness by understanding the attester implementation and the verifier's checks—not by reading a claim name from a valid envelope.

Freshness is another independent test. RFC 9711 requires every EAT use to provide a freshness mechanism. A nonce is one option, and a profile should state which mechanisms are acceptable. A perfectly signed token can be an authentic replay. The signature receipt and the freshness receipt must therefore carry different timestamps, inputs and failure states.

Appraisal is not the action it informs

The final compression error happens after verification. Under the RATS architecture, a verifier appraises Evidence using policy, reference values and endorsements, then produces Attestation Results. The relying party consumes those results under its own policy to perform an application-specific action. Those roles can run in one product, but their assertions remain different.

A verifier might accurately report that a measurement matches a reference value and that evidence is fresh. A relying party can still deny access because the request concerns a different resource, a risk window has closed, a jurisdictional rule applies or the result lacks a claim required for that transaction. Conversely, an operational policy might allow a constrained action despite an indeterminate result, with reduced privileges and a short expiry. RFC 9782 does not choose between those outcomes. It helps the messages arrive at the right processors.

This is where a modest registration acquires strategic value. It provides a minimum common layer without pretending that every organization should share one final policy. Heng Lu's distinction between symbolic and executable reality is useful here. The RFC and IANA registry make identifiers real in the symbolic layer. Interoperability becomes operational only when sender and receiver implementations exercise the same profile, reject the same invalid bytes, verify the required protection, pass freshness tests and preserve the result. The registry entry cannot run those steps.

The complete chain is therefore: declared media type and external profile; exact byte hash; selected handler and parser; envelope verification or channel scope; in-band profile and claims; full-profile and freshness checks; verifier appraisal; and relying-party action. Each stage should produce a receipt that names its input and policy version. Later success must not overwrite earlier uncertainty.

Sources