Entity Attestation Token (EAT) Media Types
RFC 9782
Laurence Lundblade
Security Theory LLC
lgl@securitytheory.com
Henk Birkholz
Fraunhofer Institute for Secure Information Technology
Rheinstrasse 75
Darmstadt
64295
Germany
henk.birkholz@ietf.contact
Thomas Fossati
Linaro
thomas.fossati@linaro.org
May 2025
SEC
rats
EAT
media type
The payloads used in Remote ATtestation procedureS (RATS) may require an associated media type for their conveyance, for example, when the payloads are used in RESTful APIs.
This memo defines media types to be used for Entity Attestation Tokens (EATs).
Introduction
Payloads used in Remote ATtestation procedureS (RATS) [RFC9334] may require an associated media type for their conveyance, for example, when used in RESTful APIs (Figure 1).
Conveying RATS Conceptual Messages in REST APIs Using EATs

Relying

Party

Attester

Verifier

POST

/verify

EAT(Evidence)

200

OK

EAT(Attestation

Results)

POST

/auth

EAT(Attestation

Results)

201

Created

.---------------.         .----------.             .----------.
| Relying Party |         | Attester |             | Verifier |
'-+-------------'         '----+-----'             '--------+-'
  |                            | POST /verify               |
  |                            | EAT(Evidence)              |
  |                            +--------------------------->|
  |                            |                     200 OK |
  |                            |   EAT(Attestation Results) |
  |                            |<---------------------------+
  |                 POST /auth |                            |
  |   EAT(Attestation Results) |                            |
  |<---------------------------+                            |
  | 201 Created                |                            |
  +--------------------------->|                            |
  |                            |                            |
  |                            |                            |

This memo defines media types to be used for EAT payloads [RFC9711] independently of the RATS Conceptual Message in which they manifest themselves. The objective is to give protocol, API, and application designers a number of readily available and reusable media types for integrating EAT-based messages in their flows, e.g., when using HTTP [BCP56] or the Constrained Application Protocol (CoAP) [I-D.irtf-t2trg-rest-iot].
Terminology
This document uses the terms and concepts defined in [RFC9334].
EAT Types
Figure 2 illustrates the six EAT wire formats and how they relate to each other. [RFC9711] defines four of them (CBOR Web Token (CWT), JSON Web Token (JWT), and the detached EAT bundle in its JSON and CBOR flavours), while [RFC9781] defines the Unprotected CWT Claims Set (UCCS) and Unprotected JWT Claims Sets (UJCS).
EAT Types

UJCS

UCCS

JWT

Crypto

CWT

Claims-Set

BUN-J

Bundle

Digest

BUN-C

submod

Nested-Token

Legend:

Process

Wire

Fmt

CDDL

               .-----.
         .----+ UJCS |<-------------------------.
        |     '-----'                            |
        |                                        |
        |      .-----.                           |
        +-----+ UCCS |<-----------------------.  |
        |     '-----'                          | |
        |                                      | |
        |      .------.                        | |
        +-----+  JWT  |<------.                | |
        |     '------'      .--+---.           | |
        |                  | Crypto |<------.  | |
        |      .------.     '--+---'         | | |
        +-----+  CWT  |<------'              | | |
        |     '------'                   .---+-+-+----.
        |                                | Claims-Set +--.
        |      .------.                  '---+---+----'   |
        +-----+ BUN-J |<------.              | ^ |        v
        |     '------'      .--+---.         | | |     .------.
        |                  | Bundle |<------'  | |    | Digest |
        |      .------.     '--+---'           | v     '--+---'
        +-----+ BUN-C |<------'  ^         .---+----.     |
        |     '------'           |         | submod |<---'
        |                        |         '--------'
        v                        |             ^
.--------------.                 |             |
| Nested-Token +-----------------+------------'
'--------------'

                .-------.     .---------.   .------.
     Legend:   | Process |   | Wire Fmt |   | CDDL |
                '-------'    '---------'    '------'

A Media Type Parameter for EAT Profiles
EAT is an open and flexible format. To improve interoperability, Section 6 of [RFC9711] defines the concept of EAT profiles. Profiles are used to constrain the parameters that producers and consumers of a specific EAT profile need to understand in order to interoperate, e.g., the number and type of claims, which serialisation format, the supported signature schemes, etc. EATs carry an in-band profile identifier using the "eat_profile" claim (see Section 4.3.2 of [RFC9711]). The value of the "eat_profile" claim is either an OID or a URI.
The media types defined in this document include an optional "eat_profile" parameter that can be used to mirror the "eat_profile" claim of the transported EAT. Exposing the EAT profile at the API layer allows API routers to dispatch payloads directly to the profile-specific processor without having to snoop into the request bodies. This design also provides a finer-grained and scalable type system that matches the inherent extensibility of EAT. The expectation being that a certain EAT profile automatically obtains a media type derived from the base (e.g., application/eat+cwt) by populating the "eat_profile" parameter with the corresponding OID or URL.
When the parameterised version of the EAT media type is used in HTTP (for example, with the "Content-Type" and "Accept" headers) and the value is an absolute URI (Section 4.3 of [RFC3986]), the parameter-value (Appendix A of [RFC9110]) uses the quoted-string encoding, for example:
application/eat+jwt; eat_profile="tag:evidence.example,2022"
Instead, when the EAT profile is an OID, the token encoding (i.e., without quotes) can be used. For example:
application/eat+cwt; eat_profile=2.999.1.
Examples
The example in Figure 3 illustrates the usage of EAT media types for transporting attestation evidence as well as negotiating the acceptable format of the attestation result.
Example REST Verification API (request)

NOTE: '\' line wrapping per RFC 8792

POST /challenge-response/v1/session/1234567890 HTTP/1.1
Host: verifier.example
Accept: application/eat+cwt; eat_profile="tag:ar4si.example,2021"
Content-Type: application/eat+cwt; \
              eat_profile="tag:evidence.example,2022"

[ CBOR-encoded EAT w/ eat_profile="tag:evidence.example,2022" ]

The example in Figure 4 illustrates the usage of EAT media types for transporting attestation results.
Example REST Verification API (response)

NOTE: '\' line wrapping per RFC 8792

HTTP/1.1 200 OK
Content-Type: application/eat+cwt; \
              eat_profile="tag:ar4si.example,2021"

[ CBOR-encoded EAT w/ eat_profile="tag:ar4si.example,2021" ]

In both cases, a tag URI [RFC4151] identifying the profile is carried as an explicit parameter.
Security Considerations
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 stop further processing on failure. Failing to do so could expose the user to security risks, such as privilege escalation and cross-protocol attacks.
The security considerations of [RFC9711] and [RFC9781] apply in full.
When using application/eat-ucs+json and application/eat-ucs+cbor in particular, the reader should review Section 3 of [RFC9781], which contains a detailed discussion about the characteristics of a "Secure Channel" for conveyance of such messages.
IANA Considerations
+cwt Structured Syntax Suffix
IANA has registered +cwt in the "Structured Syntax Suffixes" registry [STRUCT-SYNTAX] in the manner described in [RFC6838]. +cwt can be used to indicate that the media type is encoded as a CWT.
Registry Contents
Name:
CBOR Web Token (CWT)
+suffix:
+cwt
References:
[RFC8392]
Encoding Considerations:
binary
Interoperability Considerations:
N/A
Fragment Identifier Considerations:
The syntax and semantics of fragment identifiers specified for +cwt SHOULD be as specified for application/cwt. (At the time of publication, there is no fragment identification syntax defined for application/cwt.)
Security Considerations:
See Section 8 of [RFC8392]
Contact:
RATS WG mailing list (rats@ietf.org), or IETF Security Area (saag@ietf.org)
Author/Change Controller:
Remote ATtestation ProcedureS (RATS) Working Group. The IETF has change control over this registration.
Media Types
IANA has registered the following media types in the "Media Types" registry [MEDIA-TYPES].
New Media Types
Name | Template | Reference
EAT CWT | application/eat+cwt | RFC 9782, Section 6.3
EAT JWT | application/eat+jwt | RFC 9782, Section 6.4
Detached EAT Bundle CBOR | application/eat-bun+cbor | RFC 9782, Section 6.5
Detached EAT Bundle JSON | application/eat-bun+json | RFC 9782, Section 6.6
EAT UCCS | application/eat-ucs+cbor | RFC 9782, Section 6.7
EAT UJCS | application/eat-ucs+json | RFC 9782, Section 6.8
application/eat+cwt Registration
Type name:
application
Subtype name:
eat+cwt
Required parameters:
N/A
Optional parameters:
"eat_profile" (EAT profile in string format. OIDs must use the dotted-decimal notation. The parameter value is case insensitive.)
Encoding considerations:
binary
Security considerations:
Section 9 of [RFC9711]
Interoperability considerations:
N/A
Published specification:
RFC 9782
Applications that use this media type:
Attesters, Verifiers, Endorsers and Reference-Value providers, and Relying Parties that need to transfer EAT payloads over HTTP(S), CoAP(S), and other transports.
Fragment identifier considerations:
N/A
Person & email address to contact for further information:
RATS WG mailing list (rats@ietf.org)
Intended usage:
COMMON
Restrictions on usage:
none
Author/Change controller:
IETF
Provisional registration:
no
application/eat+jwt Registration
Type name:
application
Subtype name:
eat+jwt
Required parameters:
N/A
Optional parameters:
"eat_profile" (EAT profile in string format. OIDs must use the dotted-decimal notation. The parameter value is case insensitive.)
Encoding considerations:
8bit
Security considerations:
Section 9 of [RFC9711] and [BCP225]
Interoperability considerations:
N/A
Published specification:
RFC 9782
Applications that use this media type:
Attesters, Verifiers, Endorsers and Reference-Value providers, and Relying Parties that need to transfer EAT payloads over HTTP(S), CoAP(S), and other transports.
Fragment identifier considerations:
N/A
Person & email address to contact for further information:
RATS WG mailing list (rats@ietf.org)
Intended usage:
COMMON
Restrictions on usage:
none
Author/Change controller:
IETF
Provisional registration:
no
application/eat-bun+cbor Registration
Type name:
application
Subtype name:
eat-bun+cbor
Required parameters:
N/A
Optional parameters:
"eat_profile" (EAT profile in string format. OIDs must use the dotted-decimal notation. The parameter value is case insensitive.)
Encoding considerations:
binary
Security considerations:
Section 9 of [RFC9711]
Interoperability considerations:
N/A
Published specification:
RFC 9782
Applications that use this media type:
Attesters, Verifiers, Endorsers and Reference-Value providers, and Relying Parties that need to transfer EAT payloads over HTTP(S), CoAP(S), and other transports.
Fragment identifier considerations:
N/A
Person & email address to contact for further information:
RATS WG mailing list (rats@ietf.org)
Intended usage:
COMMON
Restrictions on usage:
none
Author/Change controller:
IETF
Provisional registration:
no
application/eat-bun+json Registration
Type name:
application
Subtype name:
eat-bun+json
Required parameters:
N/A
Optional parameters:
"eat_profile" (EAT profile in string format. OIDs must use the dotted-decimal notation. The parameter value is case insensitive.)
Encoding considerations:
Same as [RFC8259]
Security considerations:
Section 9 of [RFC9711]
Interoperability considerations:
N/A
Published specification:
RFC 9782
Applications that use this media type:
Attesters, Verifiers, Endorsers and Reference-Value providers, and Relying Parties that need to transfer EAT payloads over HTTP(S), CoAP(S), and other transports.
Fragment identifier considerations:
N/A
Person & email address to contact for further information:
RATS WG mailing list (rats@ietf.org)
Intended usage:
COMMON
Restrictions on usage:
none
Author/Change controller:
IETF
Provisional registration:
no
application/eat-ucs+cbor Registration
Type name:
application
Subtype name:
eat-ucs+cbor
Required parameters:
N/A
Optional parameters:
"eat_profile" (EAT profile in string format. OIDs must use the dotted-decimal notation. The parameter value is case insensitive.)
Encoding considerations:
binary
Security considerations:
Sections 3 and 7 of [RFC9781]
Interoperability considerations:
N/A
Published specification:
RFC 9782
Applications that use this media type:
Attesters, Verifiers, Endorsers and Reference-Value providers, and Relying Parties that need to transfer EAT payloads over HTTP(S), CoAP(S), and other transports.
Fragment identifier considerations:
N/A
Person & email address to contact for further information:
RATS WG mailing list (rats@ietf.org)
Intended usage:
COMMON
Restrictions on usage:
none
Author/Change controller:
IETF
Provisional registration:
no
application/eat-ucs+json Registration
Type name:
application
Subtype name:
eat-ucs+json
Required parameters:
N/A
Optional parameters:
"eat_profile" (EAT profile in string format. OIDs must use the dotted-decimal notation. The parameter value is case insensitive.)
Encoding considerations:
Same as [RFC8259]
Security considerations:
Sections 3 and 7 of [RFC9781]
Interoperability considerations:
N/A
Published specification:
RFC 9782
Applications that use this media type:
Attesters, Verifiers, Endorsers and Reference-Value providers, and Relying Parties that need to transfer EAT payloads over HTTP(S), CoAP(S), and other transports.
Fragment identifier considerations:
N/A
Person & email address to contact for further information:
RATS WG mailing list (rats@ietf.org)
Intended usage:
COMMON
Restrictions on usage:
none
Author/Change controller:
IETF
Provisional registration:
no
CoAP Content-Format Registrations
IANA has registered the following Content-Format numbers in the "CoAP Content-Formats" registry, within the "Constrained RESTful Environments (CoRE) Parameters" registry group [CORE-PARAMS]:
New Content-Formats
Content Type | Content Coding | ID | Reference
application/eat+cwt | - | 263 | RFC 9782
application/eat+jwt | - | 264 | RFC 9782
application/eat-bun+cbor | - | 265 | RFC 9782
application/eat-bun+json | - | 266 | RFC 9782
application/eat-ucs+cbor | - | 267 | RFC 9781
application/eat-ucs+json | - | 268 | RFC 9782
References
Normative References
[RFC9711]

The Entity Attestation Token (EAT)
Laurence Lundblade
Security Theory LLC
Giridhar Mandyam
Mediatek USA
Jeremy O'Donoghue
Carl Wallace
Red Hound Software, Inc.
April 2025
RFC 9711
DOI 10.17487/RFC9711
[RFC9781]

A Concise Binary Object Representation (CBOR) Tag for Unprotected CBOR Web Token Claims Sets (UCCS)
Henk Birkholz
Fraunhofer SIT
Jeremy O'Donoghue
Qualcomm Technologies Inc.
Nancy Cam-Winget
Cisco Systems
Carsten Bormann
Universität Bremen TZI
April 2025
RFC 9781
DOI 10.17487/RFC9781
[STRUCT-SYNTAX]

Structured Syntax Suffixes
IANA
[MEDIA-TYPES]

Media Types
IANA
[CORE-PARAMS]

CoAP Content-Formats
IANA
Informative References
[RFC9334]
[BCP56]
[I-D.irtf-t2trg-rest-iot]
[RFC3986]
[RFC9110]
[RFC4151]
[RFC6838]
[RFC8392]
[BCP225]
[RFC8259]
Acknowledgments
Thank you Carl Wallace, Carsten Bormann, Dave Thaler, Deb Cooley, Éric Vyncke, Francesca Palombini, Jouni Korhonen, Kathleen Moriarty, Michael Richardson, Murray Kucherawy, Orie Steele, Paul Howard, Roman Danyliw, and Tim Hollebeek for your comments and suggestions.