RFC 9782
Entity Attestation Token (EAT) Media Types
RFC 9782 💖 Entity Attestation Token (EAT) Media Types
okay bestie, this is RFC 9782 (part 1 of 3) and it's giving serious spec energy ✨ It's a Standards Track document from the IETF, published in May 2025. The authors are L. Lundblade (Security Theory LLC), H. Birkholz (Fraunhofer SIT), and T. Fossati (Linaro). It's ISSN 2070-1721. Its title block doesn't list anything it obsoletes or updates, so it isn't replacing or patching any older RFC 🌸
Abstract ✨
so the payloads used in Remote ATtestation procedureS (RATS) might need a media type when they get conveyed, like when they're flying around inside RESTful APIs 🦋
this memo defines the media types you use for Entity Attestation Tokens (EATs). periodt 💅
Status of This Memo
this is an Internet Standards Track document 🎀
it's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). if you want more info on Internet Standards, check out Section 2 of RFC 7841 📚
for the current status, any errata, and how to give feedback, go to https://www.rfc-editor.org/info/rfc9782 🌈
Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. 🔒
this document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date. please read those carefully, because they spell out your rights and restrictions for this document 🧾
any Code Components pulled out of this document have to include the Revised BSD License text described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Revised BSD License says. ⚠️
Table of Contents 🗂️
1. Introduction
1.1. Terminology
2. EAT Types
3. A Media Type Parameter for EAT Profiles
4. Examples
5. Security Considerations
6. IANA Considerations
6.1. +cwt Structured Syntax Suffix
6.1.1. Registry Contents
6.2. Media Types
6.3. application/eat+cwt Registration
6.4. application/eat+jwt Registration
6.5. application/eat-bun+cbor Registration
6.6. application/eat-bun+json Registration
6.7. application/eat-ucs+cbor Registration
6.8. application/eat-ucs+json Registration
6.9. CoAP Content-Format Registrations
7. References
7.1. Normative References
7.2. Informative References
Acknowledgments
Authors' Addresses1. Introduction 🌷
so payloads used in Remote ATtestation procedureS (RATS) [RATS-ARCH] might need an associated media type for conveying them, like when they're used in RESTful APIs. Figure 1 shows what that looks like 👀
.---------------. .----------. .----------.
| Relying Party | | Attester | | Verifier |
'-+-------------' '----+-----' '--------+-'
| | POST /verify |
| | EAT(Evidence) |
| +--------------------------->|
| | 200 OK |
| | EAT(Attestation Results) |
| |<---------------------------+
| POST /auth | |
| EAT(Attestation Results) | |
|<---------------------------+ |
| 201 Created | |
+--------------------------->| |
| | |
| | |Figure 1: Conveying RATS Conceptual Messages in REST APIs Using EATs
this memo defines media types for EAT payloads [EAT] no matter which RATS Conceptual Message they show up in. the goal is to give protocol, API, and app designers a bunch of ready-made, reusable media types for slotting EAT-based messages into their flows, like when using HTTP [BUILD-W-HTTP] or the Constrained Application Protocol (CoAP) [REST-IoT] 🦋
1.1. Terminology 📖
this document uses the terms and concepts defined in [RATS-ARCH] 💜
2. EAT Types 🧩
Figure 2 shows the six EAT wire formats and how they relate to each other 🕸️ [EAT] defines four of them (CBOR Web Token (CWT), JSON Web Token (JWT), and the detached EAT bundle in its JSON and CBOR flavours). [UCCS] defines the Unprotected CWT Claims Set (UCCS) and Unprotected JWT Claims Sets (UJCS).
.-----.
.----+ UJCS |<-------------------------.
| '-----' |
| |
| .-----. |
+-----+ UCCS |<-----------------------. |
| '-----' | |
| | |
| .------. | |
+-----+ JWT |<------. | |
| '------' .--+---. | |
| | Crypto |<------. | |
| .------. '--+---' | | |
+-----+ CWT |<------' | | |
| '------' .---+-+-+----.
| | Claims-Set +--.
| .------. '---+---+----' |
+-----+ BUN-J |<------. | ^ | v
| '------' .--+---. | | | .------.
| | Bundle |<------' | | | Digest |
| .------. '--+---' | v '--+---'
+-----+ BUN-C |<------' ^ .---+----. |
| '------' | | submod |<---'
| | '--------'
v | ^
.--------------. | |
| Nested-Token +-----------------+------------'
'--------------'
.-------. .---------. .------.
Legend: | Process | | Wire Fmt | | CDDL |
'-------' '---------' '------'
Figure 2: EAT Types3. A Media Type Parameter for EAT Profiles 🎀
EAT is an open and flexible format, which is super cute but also means it needs some structure 💅 To make interop better, Section 6 of [EAT] defines the concept of EAT profiles. Profiles constrain the parameters that producers and consumers of a specific EAT profile need to understand to interoperate, like the number and type of claims, which serialisation format is used, the supported signature schemes, and so on. EATs carry an in-band profile identifier in the "eat_profile" claim (see Section 4.3.2 of [EAT]). The value of the "eat_profile" claim is either an OID or a URI.
the media types in this document include an optional "eat_profile" parameter that mirrors the "eat_profile" claim of the transported EAT ✨ Exposing the profile at the API layer means API routers can send payloads straight to the profile-specific processor without snooping into request bodies, which is so efficient 🧚 It also gives you a finer-grained, scalable type system that matches how extensible EAT is. The idea is that a given EAT profile automatically gets a media type derived from the base (for example, application/eat+cwt) by filling in the "eat_profile" parameter with the matching OID or URL.
when the parameterised version of the EAT media type is used in HTTP (for example, in the "Content-Type" and "Accept" headers) and the value is an absolute URI (Section 4.3 of [URI]), the parameter-value (Appendix A of [HTTP]) uses quoted-string encoding, like this:
application/eat+jwt; eat_profile="tag:evidence.example,2022"but when the EAT profile is an OID, you can use the token encoding (so no quotes) instead. For example:
application/eat+cwt; eat_profile=2.999.1.4. Examples 🍓
Figure 3 shows how EAT media types carry attestation evidence, and how they negotiate the acceptable format for the attestation result 🫶
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" ]Figure 3: Example REST Verification API (request)
Figure 4 shows how EAT media types carry attestation results 📜
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" ]Figure 4: Example REST Verification API (response)
in both cases, a tag URI [TAG] identifying the profile is carried as an explicit parameter 🏷️
5. Security Considerations 🔐
okay this part is SERIOUS, bestie, so read it carefully 😭
media types only give the processing app clues about what it's getting. the app needs to verify that the received data matches the expected format, whatever media type got advertised, and it needs to stop further processing if that check fails. skipping this could expose the user to security risks like privilege escalation and cross-protocol attacks 💀
the security considerations of [EAT] and [UCCS] apply in full 🛡️
when you're using application/eat-ucs+json or application/eat-ucs+cbor specifically, definitely give Section 3 of [UCCS] a read. it goes deep on what makes a "Secure Channel" for conveying these messages, and you'll want to know that 🦋
that's the end of part 1! part 2 is coming up next with the IANA Considerations and the rest 🌈💜
6.2. Media Types ✨
okay so IANA has registered these media types in the "Media Types" registry [MEDIA-TYPES] 💅 bestie, look at this table, it's giving organized 🎀
+==============+=====================+=======================+
| 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 | application/eat- | RFC 9782, Section 6.5 |
| Bundle CBOR | bun+cbor | |
+--------------+---------------------+-----------------------+
| Detached EAT | application/eat- | RFC 9782, Section 6.6 |
| Bundle JSON | bun+json | |
+--------------+---------------------+-----------------------+
| EAT UCCS | application/eat- | RFC 9782, Section 6.7 |
| | ucs+cbor | |
+--------------+---------------------+-----------------------+
| EAT UJCS | application/eat- | RFC 9782, Section 6.8 |
| | ucs+json | |
+--------------+---------------------+-----------------------+Table 1: New Media Types 🌸
6.3. 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 [EAT]
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: no6.4. 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 [EAT] 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: no6.5. 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 [EAT]
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: no6.6. 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 [JSON]
Security considerations: Section 9 of [EAT]
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: no6.7. 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 [UCCS]
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: no6.8. 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 [JSON]
Security considerations: Sections 3 and 7 of [UCCS]
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: no6.9. 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] 🦋
+==========================+================+=====+===========+
| 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 |
+--------------------------+----------------+-----+-----------+Table 2: New Content-Formats 🌸
7. References 📚
7.1. Normative References 💜
[BCP225] Best Current Practice 225,
<https://www.rfc-editor.org/info/bcp225>.
At the time of writing, this BCP comprises the following:
Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best
Current Practices", BCP 225, RFC 8725,
DOI 10.17487/RFC8725, February 2020,
<https://www.rfc-editor.org/info/rfc8725>.
[CORE-PARAMS]
IANA, "CoAP Content-Formats",
<https://www.iana.org/assignments/core-parameters>.
[CWT] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
"CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
May 2018, <https://www.rfc-editor.org/info/rfc8392>.
[EAT] Lundblade, L., Mandyam, G., O'Donoghue, J., and C.
Wallace, "The Entity Attestation Token (EAT)", RFC 9711,
DOI 10.17487/RFC9711, April 2025,
<https://www.rfc-editor.org/info/rfc9711>.
[HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/info/rfc9110>.
[JSON] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/info/rfc8259>.
[MEDIA-TYPES]
IANA, "Media Types",
<https://www.iana.org/assignments/media-types>.
[MEDIATYPES]
Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13,
RFC 6838, DOI 10.17487/RFC6838, January 2013,
<https://www.rfc-editor.org/info/rfc6838>.
[STRUCT-SYNTAX]
IANA, "Structured Syntax Suffixes",
<https://www.iana.org/assignments/media-type-structured-
suffix>.
[UCCS] Birkholz, H., O'Donoghue, J., Cam-Winget, N., and C.
Bormann, "A Concise Binary Object Representation (CBOR)
Tag for Unprotected CBOR Web Token Claims Sets (UCCS)",
RFC 9781, DOI 10.17487/RFC9781, April 2025,
<https://www.rfc-editor.org/info/rfc9781>.
[URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>.7.2. Informative References 📚
Okay, this part is the bibliography, bestie, so it's the sources the spec leans on for background (not the must-follow stuff 💅). Here they are, with all their details:
[BUILD-W-HTTP] 🧱 This one points at Best Current Practice 56, which you can find at <https://www.rfc-editor.org/info/bcp56>. At the time of writing, this BCP comprises the following: Nottingham, M., "Building Protocols with HTTP", BCP 56, RFC 9205, DOI 10.17487/RFC9205, June 2022, <https://www.rfc-editor.org/info/rfc9205>.
[RATS-ARCH] 🔐 Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, DOI 10.17487/RFC9334, January 2023, <https://www.rfc-editor.org/info/rfc9334>.
[REST-IoT] 🌐 Keränen, A., Kovatsch, M., and K. Hartke, "Guidance on RESTful Design for Internet of Things Systems", Work in Progress, Internet-Draft, draft-irtf-t2trg-rest-iot-16, 23 April 2025, <https://datatracker.ietf.org/doc/html/draft-irtf-t2trg-rest-iot-16>. (It's still a draft, so keep that in mind 🙈)
[TAG] 🏷️ Kindberg, T. and S. Hawke, "The 'tag' URI Scheme", RFC 4151, DOI 10.17487/RFC4151, October 2005, <https://www.rfc-editor.org/info/rfc4151>.
Acknowledgments 🫶
Huge thank you to 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. You all really made this better, periodt ✨
Authors' Addresses 💌
Here's where to find the authors, all in one place:
Laurence Lundblade
Security Theory LLC
Email: lgl@securitytheory.com
Henk Birkholz
Fraunhofer Institute for Secure Information Technology
Rheinstrasse 75
64295 Darmstadt
Germany
Email: henk.birkholz@ietf.contact
Thomas Fossati
Linaro
Email: thomas.fossati@linaro.org📦 where this page comes from
- ietf: rfc9782 2025-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms