Entity Attestation Token (EAT) Media Types
Extracted elements (16)
The 'eat_profile' media type parameter is placed at the API layer so that routers can dispatch payloads to profile-specific processors without inspecting request bodies. This provides a finer-grained, scalable type system matching EAT's inherent extensibility, where each EAT profile automatically derives a media type from the base type by populating 'eat_profile'.
When using a parameterized EAT media type in HTTP headers and the eat_profile value is an absolute URI, the quoted-string encoding MUST be used (e.g., eat_profile="tag:evidence.example,2022"). When the profile is an OID, the token encoding without quotes is used (e.g., eat_profile=2.999.1.).
Fragment identifier syntax and semantics for the +cwt structured syntax suffix SHOULD be as specified for application/cwt. At the time of publication, no fragment identification syntax is defined for application/cwt.
An optional 'eat_profile' media type parameter is defined for all EAT media types. Its value mirrors the 'eat_profile' claim inside the EAT payload and is either an OID in dotted-decimal notation or a URI; the parameter value is case insensitive.
Six EAT wire formats are defined: CWT (CBOR Web Token), JWT (JSON Web Token), detached EAT bundle in CBOR (BUN-C) and JSON (BUN-J) flavors, Unprotected CWT Claims Set (UCCS), and Unprotected JWT Claims Set (UJCS). CWT and JWT are cryptographically protected; UCCS and UJCS rely on a secure channel instead.
IANA has registered six CoAP Content-Format numbers in the 'CoAP Content-Formats' registry: application/eat+cwt (ID 263), application/eat+jwt (264), application/eat-bun+cbor (265), application/eat-bun+json (266), application/eat-ucs+cbor (267), and application/eat-ucs+json (268).
IANA has registered six new media types in the 'Media Types' registry: application/eat+cwt, application/eat+jwt, application/eat-bun+cbor, application/eat-bun+json, application/eat-ucs+cbor, and application/eat-ucs+json, all defined in RFC 9782.
IANA has registered the '+cwt' structured syntax suffix in the 'Structured Syntax Suffixes' registry, indicating that the media type is encoded as a CBOR Web Token (CWT). Encoding is binary; security considerations reference RFC 8392 Section 8.
Media types only provide clues to the processing application. The application MUST verify that the received data matches the expected format regardless of the advertised media type, and MUST stop further processing on failure. Failing to do so could expose the user to privilege escalation and cross-protocol attacks.
When using application/eat-ucs+cbor or application/eat-ucs+json (unprotected formats), implementors must review RFC 9781 Section 3, which contains a detailed discussion about the characteristics of a 'Secure Channel' required for conveyance of such messages.
application/eat-bun+cbor: binary encoding for detached EAT bundles in CBOR format. No required parameters; optional 'eat_profile' parameter. Intended for Attesters, Verifiers, Endorsers, Reference-Value providers, and Relying Parties.
application/eat-bun+json: encoding follows RFC 8259 JSON for detached EAT bundles in JSON format. No required parameters; optional 'eat_profile' parameter.
application/eat+cwt: binary encoding for CWT-format EATs. No required parameters; optional 'eat_profile' parameter (OID in dotted-decimal or URI string, case insensitive). Intended for HTTP(S), CoAP(S), and other transports.
application/eat+jwt: 8-bit encoding for JWT-format EATs. No required parameters; optional 'eat_profile' parameter (OID in dotted-decimal or URI string, case insensitive). Security considerations reference EAT Section 9 and BCP 225 (JWT best practices).
application/eat-ucs+cbor: binary encoding for Unprotected CWT Claims Sets (UCCS). No required parameters; optional 'eat_profile' parameter. Security considerations refer to Sections 3 and 7 of RFC 9781 (UCCS secure channel requirements).
application/eat-ucs+json: encoding follows RFC 8259 JSON for Unprotected JWT Claims Sets (UJCS). No required parameters; optional 'eat_profile' parameter. Security considerations refer to Sections 3 and 7 of RFC 9781.