rfc9782.original   rfc9782.txt 
Remote ATtestation ProcedureS L. Lundblade Internet Engineering Task Force (IETF) L. Lundblade
Internet-Draft Security Theory LLC Request for Comments: 9782 Security Theory LLC
Intended status: Standards Track H. Birkholz Category: Standards Track H. Birkholz
Expires: 7 May 2025 Fraunhofer SIT ISSN: 2070-1721 Fraunhofer SIT
T. Fossati T. Fossati
Linaro Linaro
3 November 2024 May 2025
EAT Media Types Entity Attestation Token (EAT) Media Types
draft-ietf-rats-eat-media-type-12
Abstract Abstract
Payloads used in Remote Attestation Procedures may require an The payloads used in Remote ATtestation procedureS (RATS) may require
associated media type for their conveyance, for example when used in an associated media type for their conveyance, for example, when the
RESTful APIs. payloads are used in RESTful APIs.
This memo defines media types to be used for Entity Attestation This memo defines media types to be used for Entity Attestation
Tokens (EAT). Tokens (EATs).
Discussion Venues
This note is to be removed before publishing as an RFC.
Discussion of this document takes place on the Remote ATtestation
ProcedureS Working Group mailing list (rats@ietf.org), which is
archived at https://mailarchive.ietf.org/arch/browse/rats/.
Source for this draft and an issue tracker can be found at
https://github.com/thomas-fossati/draft-eat-mt.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 7 May 2025. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9782.
Copyright Notice Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Terminology
2. EAT Types . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. EAT Types
3. A Media Type Parameter for EAT Profiles . . . . . . . . . . . 4 3. A Media Type Parameter for EAT Profiles
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Examples
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations
6.1. +cwt Structured Syntax Suffix . . . . . . . . . . . . . . 6 6.1. +cwt Structured Syntax Suffix
6.1.1. Registry Contents . . . . . . . . . . . . . . . . . . 6 6.1.1. Registry Contents
6.2. Media Types . . . . . . . . . . . . . . . . . . . . . . . 7 6.2. Media Types
6.3. application/eat+cwt Registration . . . . . . . . . . . . 7 6.3. application/eat+cwt Registration
6.4. application/eat+jwt Registration . . . . . . . . . . . . 8 6.4. application/eat+jwt Registration
6.5. application/eat-bun+cbor Registration . . . . . . . . . . 8 6.5. application/eat-bun+cbor Registration
6.6. application/eat-bun+json Registration . . . . . . . . . . 9 6.6. application/eat-bun+json Registration
6.7. application/eat-ucs+cbor Registration . . . . . . . . . . 9 6.7. application/eat-ucs+cbor Registration
6.8. application/eat-ucs+json Registration . . . . . . . . . . 10 6.8. application/eat-ucs+json Registration
6.9. CoAP Content-Format Registrations . . . . . . . . . . . . 10 6.9. CoAP Content-Format Registrations
7. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7. References
7.1. -04 . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.1. Normative References
7.2. -03 . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.2. Informative References
7.3. -02 . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Acknowledgments
7.4. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . 13
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
Payloads used in Remote Attestation Procedures [RATS-Arch] may Payloads used in Remote ATtestation procedureS (RATS) [RATS-ARCH] may
require an associated media type for their conveyance, for example require an associated media type for their conveyance, for example,
when used in RESTful APIs (Figure 1). when used in RESTful APIs (Figure 1).
.---------------. .----------. .----------. .---------------. .----------. .----------.
| Relying Party | | Attester | | Verifier | | Relying Party | | Attester | | Verifier |
'-+-------------' '----+-----' '--------+-' '-+-------------' '----+-----' '--------+-'
| | POST /verify | | | POST /verify |
| | EAT(Evidence) | | | EAT(Evidence) |
| +--------------------------->| | +--------------------------->|
| | 200 OK | | | 200 OK |
| | EAT(Attestation Results) | | | EAT(Attestation Results) |
| |<---------------------------+ | |<---------------------------+
| POST /auth | | | POST /auth | |
| EAT(Attestation Results) | | | EAT(Attestation Results) | |
|<---------------------------+ | |<---------------------------+ |
| 201 Created | | | 201 Created | |
+--------------------------->| | +--------------------------->| |
| | | | | |
| | | | | |
Figure 1: Conveying RATS conceptual messages in REST APIs using EAT Figure 1: Conveying RATS Conceptual Messages in REST APIs Using EATs
This memo defines media types to be used for Entity Attestation Token This memo defines media types to be used for EAT payloads [EAT]
(EAT) [EAT] payloads independently of the RATS Conceptual Message in independently of the RATS Conceptual Message in which they manifest
which they manifest themselves. The objective is to give protocol, themselves. The objective is to give protocol, API, and application
API and application designers a number of readily available and designers a number of readily available and reusable media types for
reusable media types for integrating EAT-based messages in their integrating EAT-based messages in their flows, e.g., when using HTTP
flows, for example when using HTTP [BUILD-W-HTTP] or CoAP [REST-IoT]. [BUILD-W-HTTP] or the Constrained Application Protocol (CoAP)
[REST-IoT].
1.1. Requirements Language 1.1. Terminology
This document uses the terms and concepts defined in [RATS-Arch]. This document uses the terms and concepts defined in [RATS-ARCH].
2. EAT Types 2. EAT Types
Figure 2 illustrates the six EAT wire formats and how they relate to Figure 2 illustrates the six EAT wire formats and how they relate to
each other. [EAT] defines four of them (CWT, JWT and Detached EAT each other. [EAT] defines four of them (CBOR Web Token (CWT), JSON
Bundle in its JSON and CBOR flavours), whilst [UCCS] defines UCCS and Web Token (JWT), and the detached EAT bundle in its JSON and CBOR
UJCS. flavours), while [UCCS] defines the Unprotected CWT Claims Set (UCCS)
and Unprotected JWT Claims Sets (UJCS).
.-----. .-----.
.----+ UJCS |<-------------------------. .----+ UJCS |<-------------------------.
| '-----' | | '-----' |
| | | |
| .-----. | | .-----. |
+-----+ UCCS |<-----------------------. | +-----+ UCCS |<-----------------------. |
| '-----' | | | '-----' | |
| | | | | |
| .------. | | | .------. | |
skipping to change at page 4, line 35 skipping to change at line 150
| .------. '--+---' | v '--+---' | .------. '--+---' | v '--+---'
+-----+ BUN-C |<------' ^ .---+----. | +-----+ BUN-C |<------' ^ .---+----. |
| '------' | | submod |<---' | '------' | | submod |<---'
| | '--------' | | '--------'
v | ^ v | ^
.--------------. | | .--------------. | |
| Nested-Token +-----------------+------------' | Nested-Token +-----------------+------------'
'--------------' '--------------'
.-------. .---------. .------. .-------. .---------. .------.
Legenda: | Process | | Wire Fmt | | CDDL | Legend: | Process | | Wire Fmt | | CDDL |
'-------' '---------' '------' '-------' '---------' '------'
Figure 2: EAT Types Figure 2: EAT Types
3. A Media Type Parameter for EAT Profiles 3. A Media Type Parameter for EAT Profiles
EAT is an open and flexible format. To improve interoperability, EAT is an open and flexible format. To improve interoperability,
Section 6 of [EAT] defines the concept of EAT profiles. Profiles are Section 6 of [EAT] defines the concept of EAT profiles. Profiles are
used to constrain the parameters that producers and consumers of a used to constrain the parameters that producers and consumers of a
specific EAT profile need to understand in order to interoperate. specific EAT profile need to understand in order to interoperate,
For example: the number and type of claims, which serialisation e.g., the number and type of claims, which serialisation format, the
format, the supported signature schemes, etc. EATs carry an in-band supported signature schemes, etc. EATs carry an in-band profile
profile identifier using the eat_profile claim (see Section 4.3.2 of identifier using the "eat_profile" claim (see Section 4.3.2 of
[EAT]). The value of the eat_profile claim is either an OID or a [EAT]). The value of the "eat_profile" claim is either an OID or a
URI. URI.
The media types defined in this document include an optional The media types defined in this document include an optional
eat_profile parameter that can be used to mirror the eat_profile "eat_profile" parameter that can be used to mirror the "eat_profile"
claim of the transported EAT. Exposing the EAT profile at the API claim of the transported EAT. Exposing the EAT profile at the API
layer allows API routers to dispatch payloads directly to the layer allows API routers to dispatch payloads directly to the
profile-specific processor without having to snoop into the request profile-specific processor without having to snoop into the request
bodies. This design also provides a finer-grained and scalable type bodies. This design also provides a finer-grained and scalable type
system that matches the inherent extensibility of EAT. The system that matches the inherent extensibility of EAT. The
expectation being that a certain EAT profile automatically obtains a expectation being that a certain EAT profile automatically obtains a
media type derived from the base (e.g., application/eat+cwt) by media type derived from the base (e.g., application/eat+cwt) by
populating the eat_profile parameter with the corresponding OID or populating the "eat_profile" parameter with the corresponding OID or
URL. URL.
When the parameterised version of the EAT media type is used in HTTP When the parameterised version of the EAT media type is used in HTTP
(for example, with the "Content-Type" and "Accept" headers), and the (for example, with the "Content-Type" and "Accept" headers) and the
value is an absolute URI (Section 4.3 of [URI]), the parameter-value value is an absolute URI (Section 4.3 of [URI]), the parameter-value
(Appendix A of [HTTP]) uses the quoted-string encoding, e.g.: (Appendix A of [HTTP]) uses the quoted-string encoding, for example:
application/eat+jwt; eat_profile="tag:evidence.example,2022" application/eat+jwt; eat_profile="tag:evidence.example,2022"
Instead, when the EAT profile is an OID, the token encoding (i.e., Instead, when the EAT profile is an OID, the token encoding (i.e.,
without quotes) can be used, e.g.: without quotes) can be used. For example:
application/eat+cwt; eat_profile=2.999.1. application/eat+cwt; eat_profile=2.999.1.
4. Examples 4. Examples
The example in Figure 3 illustrates the usage of EAT media types for The example in Figure 3 illustrates the usage of EAT media types for
transporting attestation evidence as well as negotiating the transporting attestation evidence as well as negotiating the
acceptable format of the attestation result. acceptable format of the attestation result.
# NOTE: '\' line wrapping per RFC 8792 NOTE: '\' line wrapping per RFC 8792
POST /challenge-response/v1/session/1234567890 HTTP/1.1 POST /challenge-response/v1/session/1234567890 HTTP/1.1
Host: verifier.example Host: verifier.example
Accept: application/eat+cwt; eat_profile="tag:ar4si.example,2021" Accept: application/eat+cwt; eat_profile="tag:ar4si.example,2021"
Content-Type: application/eat+cwt; \ Content-Type: application/eat+cwt; \
eat_profile="tag:evidence.example,2022" eat_profile="tag:evidence.example,2022"
[ CBOR-encoded EAT w/ eat_profile="tag:evidence.example,2022" ] [ CBOR-encoded EAT w/ eat_profile="tag:evidence.example,2022" ]
Figure 3: Example REST Verification API (request) Figure 3: Example REST Verification API (request)
The example in Figure 4 illustrates the usage of EAT media types for The example in Figure 4 illustrates the usage of EAT media types for
transporting attestation results. transporting attestation results.
# NOTE: '\' line wrapping per RFC 8792 NOTE: '\' line wrapping per RFC 8792
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Type: application/eat+cwt; \ Content-Type: application/eat+cwt; \
eat_profile="tag:ar4si.example,2021" eat_profile="tag:ar4si.example,2021"
[ CBOR-encoded EAT w/ eat_profile="tag:ar4si.example,2021" ] [ CBOR-encoded EAT w/ eat_profile="tag:ar4si.example,2021" ]
Figure 4: Example REST Verification API (response) Figure 4: Example REST Verification API (response)
In both cases, a tag URI [TAG] identifying the profile is carried as In both cases, a tag URI [TAG] identifying the profile is carried as
skipping to change at page 6, line 27 skipping to change at line 234
5. Security Considerations 5. Security Considerations
Media types only provide clues to the processing application. The Media types only provide clues to the processing application. The
application must verify that the received data matches the expected application must verify that the received data matches the expected
format, regardless of the advertised media type, and stop further format, regardless of the advertised media type, and stop further
processing on failure. Failing to do so could expose the user to processing on failure. Failing to do so could expose the user to
security risks, such as privilege escalation and cross-protocol security risks, such as privilege escalation and cross-protocol
attacks. attacks.
The security consideration of [EAT] and [UCCS] apply in full. The security considerations of [EAT] and [UCCS] apply in full.
In particular, when using application/eat-ucs+json and application/ When using application/eat-ucs+json and application/eat-ucs+cbor in
eat-ucs+cbor the reader should review Section 3 of [UCCS], which particular, the reader should review Section 3 of [UCCS], which
contains a detailed discussion about the characteristics of a "Secure contains a detailed discussion about the characteristics of a "Secure
Channel" for conveyance of such messages. Channel" for conveyance of such messages.
6. IANA Considerations 6. IANA Considerations
// RFC Editor: please replace RFCthis with this RFC number and remove
// this note.
6.1. +cwt Structured Syntax Suffix 6.1. +cwt Structured Syntax Suffix
IANA is requested to register the +cwt structured syntax suffix in IANA has registered +cwt in the "Structured Syntax Suffixes" registry
the "Structured Syntax Suffixes" registry [STRUCT-SYNTAX] in the manner described in [MEDIATYPES]. +cwt can be
[IANA.media-type-structured-suffix] in the manner described in used to indicate that the media type is encoded as a CWT.
[MediaTypes], which can be used to indicate that the media type is
encoded as a CWT.
6.1.1. Registry Contents 6.1.1. Registry Contents
Name: CBOR Web Token (CWT) Name: CBOR Web Token (CWT)
+suffix: +cwt +suffix: +cwt
References: [CWT] References: [CWT]
Encoding Considerations: binary Encoding Considerations: binary
Interoperability Considerations: N/A Interoperability Considerations: N/A
Fragment Identifier Considerations: The syntax and semantics of Fragment Identifier Considerations: The syntax and semantics of
fragment identifiers specified for +cwt SHOULD be as specified for fragment identifiers specified for +cwt SHOULD be as specified for
application/cwt. (At publication of this document, there is no application/cwt. (At the time of publication, there is no
fragment identification syntax defined for application/cwt.) fragment identification syntax defined for application/cwt.)
Security Considerations: See Section 8 of [CWT] Security Considerations: See Section 8 of [CWT]
Contact: RATS WG mailing list (rats@ietf.org), or IETF Security Area Contact: RATS WG mailing list (rats@ietf.org), or IETF Security Area
(saag@ietf.org) (saag@ietf.org)
Author/Change Controller: Remote ATtestation ProcedureS (RATS) Author/Change Controller: Remote ATtestation ProcedureS (RATS)
Working Group. The IETF has change control over this Working Group. The IETF has change control over this
registration. registration.
6.2. Media Types 6.2. Media Types
IANA is requested to add the following media types to the "Media IANA has registered the following media types in the "Media Types"
Types" registry [IANA.media-types]. registry [MEDIA-TYPES].
+==============+=====================+======================+ +==============+=====================+=======================+
| Name | Template | Reference | | Name | Template | Reference |
+==============+=====================+======================+ +==============+=====================+=======================+
| EAT CWT | application/eat+cwt | RFCthis, Section 6.3 | | EAT CWT | application/eat+cwt | RFC 9782, Section 6.3 |
+--------------+---------------------+----------------------+ +--------------+---------------------+-----------------------+
| EAT JWT | application/eat+jwt | RFCthis, Section 6.4 | | EAT JWT | application/eat+jwt | RFC 9782, Section 6.4 |
+--------------+---------------------+----------------------+ +--------------+---------------------+-----------------------+
| Detached EAT | application/eat- | RFCthis, Section 6.5 | | Detached EAT | application/eat- | RFC 9782, Section 6.5 |
| Bundle CBOR | bun+cbor | | | Bundle CBOR | bun+cbor | |
+--------------+---------------------+----------------------+ +--------------+---------------------+-----------------------+
| Detached EAT | application/eat- | RFCthis, Section 6.6 | | Detached EAT | application/eat- | RFC 9782, Section 6.6 |
| Bundle JSON | bun+json | | | Bundle JSON | bun+json | |
+--------------+---------------------+----------------------+ +--------------+---------------------+-----------------------+
| EAT UCCS | application/eat- | RFCthis, Section 6.7 | | EAT UCCS | application/eat- | RFC 9782, Section 6.7 |
| | ucs+cbor | | | | ucs+cbor | |
+--------------+---------------------+----------------------+ +--------------+---------------------+-----------------------+
| EAT UJCS | application/eat- | RFCthis, Section 6.8 | | EAT UJCS | application/eat- | RFC 9782, Section 6.8 |
| | ucs+json | | | | ucs+json | |
+--------------+---------------------+----------------------+ +--------------+---------------------+-----------------------+
Table 1: New Media Types Table 1: New Media Types
6.3. application/eat+cwt Registration 6.3. application/eat+cwt Registration
Type name: application Type name: application
Subtype name: eat+cwt Subtype name: eat+cwt
Required parameters: n/a Required parameters: n/a
Optional parameters: "eat_profile" (EAT profile in string format. Optional parameters: "eat_profile" (EAT profile in string format.
OIDs must use the dotted-decimal notation. The parameter value is OIDs must use the dotted-decimal notation. The parameter value is
case-insensitive.) case insensitive.)
Encoding considerations: binary Encoding considerations: binary
Security considerations: Section 9 of [EAT] Security considerations: Section 9 of [EAT]
Interoperability considerations: n/a Interoperability considerations: n/a
Published specification: RFCthis
Published specification: RFC 9782
Applications that use this media type: Attesters, Verifiers, Applications that use this media type: Attesters, Verifiers,
Endorsers and Reference-Value providers, Relying Parties that need Endorsers and Reference-Value providers, and Relying Parties that
to transfer EAT payloads over HTTP(S), CoAP(S), and other need to transfer EAT payloads over HTTP(S), CoAP(S), and other
transports. transports.
Fragment identifier considerations: n/a Fragment identifier considerations: n/a
Person & email address to contact for further information: RATS WG Person & email address to contact for further information: RATS WG
mailing list (rats@ietf.org) mailing list (rats@ietf.org)
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: none Restrictions on usage: none
Author/Change controller: IETF Author/Change controller: IETF
Provisional registration: no Provisional registration: no
6.4. application/eat+jwt Registration 6.4. application/eat+jwt Registration
Type name: application Type name: application
Subtype name: eat+jwt Subtype name: eat+jwt
Required parameters: n/a Required parameters: n/a
Optional parameters: "eat_profile" (EAT profile in string format. Optional parameters: "eat_profile" (EAT profile in string format.
OIDs must use the dotted-decimal notation. The parameter value is OIDs must use the dotted-decimal notation. The parameter value is
case-insensitive.) case insensitive.)
Encoding considerations: 8bit Encoding considerations: 8bit
Security considerations: Section 9 of [EAT] and [BCP225] Security considerations: Section 9 of [EAT] and [BCP225]
Interoperability considerations: n/a Interoperability considerations: n/a
Published specification: RFCthis
Applications that use this media type Attesters, Verifiers, Published specification: RFC 9782
Endorsers and Reference-Value providers, Relying Parties that need
to transfer EAT payloads over HTTP(S), CoAP(S), and other 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. transports.
Fragment identifier considerations: n/a Fragment identifier considerations: n/a
Person & email address to contact for further information: RATS WG Person & email address to contact for further information: RATS WG
mailing list (rats@ietf.org) mailing list (rats@ietf.org)
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: none Restrictions on usage: none
Author/Change controller: IETF Author/Change controller: IETF
Provisional registration: no Provisional registration: no
6.5. application/eat-bun+cbor Registration 6.5. application/eat-bun+cbor Registration
Type name: application Type name: application
Subtype name: eat-bun+cbor Subtype name: eat-bun+cbor
Required parameters: n/a Required parameters: n/a
Optional parameters: "eat_profile" (EAT profile in string format. Optional parameters: "eat_profile" (EAT profile in string format.
OIDs must use the dotted-decimal notation. The parameter value is OIDs must use the dotted-decimal notation. The parameter value is
case-insensitive.) case insensitive.)
Encoding considerations: binary Encoding considerations: binary
Security considerations: Section 9 of [EAT] Security considerations: Section 9 of [EAT]
Interoperability considerations: n/a Interoperability considerations: n/a
Published specification: RFCthis
Published specification: RFC 9782
Applications that use this media type: Attesters, Verifiers, Applications that use this media type: Attesters, Verifiers,
Endorsers and Reference-Value providers, Relying Parties that need Endorsers and Reference-Value providers, and Relying Parties that
to transfer EAT payloads over HTTP(S), CoAP(S), and other need to transfer EAT payloads over HTTP(S), CoAP(S), and other
transports. transports.
Fragment identifier considerations: n/a Fragment identifier considerations: n/a
Person & email address to contact for further information: RATS WG Person & email address to contact for further information: RATS WG
mailing list (rats@ietf.org) mailing list (rats@ietf.org)
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: none Restrictions on usage: none
Author/Change controller: IETF Author/Change controller: IETF
Provisional registration: no Provisional registration: no
6.6. application/eat-bun+json Registration 6.6. application/eat-bun+json Registration
Type name: application Type name: application
Subtype name: eat-bun+json Subtype name: eat-bun+json
Required parameters: n/a Required parameters: n/a
Optional parameters: "eat_profile" (EAT profile in string format. Optional parameters: "eat_profile" (EAT profile in string format.
OIDs must use the dotted-decimal notation. The parameter value is OIDs must use the dotted-decimal notation. The parameter value is
case-insensitive.) case insensitive.)
Encoding considerations: Same as [JSON] Encoding considerations: Same as [JSON]
Security considerations: Section 9 of [EAT] Security considerations: Section 9 of [EAT]
Interoperability considerations: n/a Interoperability considerations: n/a
Published specification: RFCthis
Applications that use this media type Attesters, Verifiers, Published specification: RFC 9782
Endorsers and Reference-Value providers, Relying Parties that need
to transfer EAT payloads over HTTP(S), CoAP(S), and other 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. transports.
Fragment identifier considerations: n/a Fragment identifier considerations: n/a
Person & email address to contact for further information: RATS WG Person & email address to contact for further information: RATS WG
mailing list (rats@ietf.org) mailing list (rats@ietf.org)
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: none Restrictions on usage: none
Author/Change controller: IETF Author/Change controller: IETF
Provisional registration: no Provisional registration: no
6.7. application/eat-ucs+cbor Registration 6.7. application/eat-ucs+cbor Registration
Type name: application Type name: application
Subtype name: eat-ucs+cbor Subtype name: eat-ucs+cbor
Required parameters: n/a Required parameters: n/a
Optional parameters: "eat_profile" (EAT profile in string format. Optional parameters: "eat_profile" (EAT profile in string format.
OIDs must use the dotted-decimal notation. The parameter value is OIDs must use the dotted-decimal notation. The parameter value is
case-insensitive.) case insensitive.)
Encoding considerations: binary Encoding considerations: binary
Security considerations: Sections 3 and 7 of [UCCS] Security considerations: Sections 3 and 7 of [UCCS]
Interoperability considerations: n/a Interoperability considerations: n/a
Published specification: RFCthis
Published specification: RFC 9782
Applications that use this media type: Attesters, Verifiers, Applications that use this media type: Attesters, Verifiers,
Endorsers and Reference-Value providers, Relying Parties that need Endorsers and Reference-Value providers, and Relying Parties that
to transfer EAT payloads over HTTP(S), CoAP(S), and other need to transfer EAT payloads over HTTP(S), CoAP(S), and other
transports. transports.
Fragment identifier considerations: n/a Fragment identifier considerations: n/a
Person & email address to contact for further information: RATS WG Person & email address to contact for further information: RATS WG
mailing list (rats@ietf.org) mailing list (rats@ietf.org)
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: none Restrictions on usage: none
Author/Change controller: IETF Author/Change controller: IETF
Provisional registration: no Provisional registration: no
6.8. application/eat-ucs+json Registration 6.8. application/eat-ucs+json Registration
Type name: application Type name: application
Subtype name: eat-ucs+json Subtype name: eat-ucs+json
Required parameters: n/a Required parameters: n/a
Optional parameters: "eat_profile" (EAT profile in string format. Optional parameters: "eat_profile" (EAT profile in string format.
OIDs must use the dotted-decimal notation. The parameter value is OIDs must use the dotted-decimal notation. The parameter value is
case-insensitive.) case insensitive.)
Encoding considerations: Same as [JSON] Encoding considerations: Same as [JSON]
Security considerations: Sections 3 and 7 of [UCCS] Security considerations: Sections 3 and 7 of [UCCS]
Interoperability considerations: n/a Interoperability considerations: n/a
Published specification: RFCthis
Applications that use this media type Attesters, Verifiers, Published specification: RFC 9782
Endorsers and Reference-Value providers, Relying Parties that need
to transfer EAT payloads over HTTP(S), CoAP(S), and other 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. transports.
Fragment identifier considerations: n/a Fragment identifier considerations: n/a
Person & email address to contact for further information: RATS WG Person & email address to contact for further information: RATS WG
mailing list (rats@ietf.org) mailing list (rats@ietf.org)
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: none Restrictions on usage: none
Author/Change controller: IETF Author/Change controller: IETF
Provisional registration: no Provisional registration: no
6.9. CoAP Content-Format Registrations 6.9. CoAP Content-Format Registrations
IANA is requested to register the following Content-Format numbers in IANA has registered the following Content-Format numbers in the "CoAP
the "CoAP Content-Formats" sub-registry, within the "Constrained Content-Formats" registry, within the "Constrained RESTful
RESTful Environments (CoRE) Parameters" Registry Environments (CoRE) Parameters" registry group [CORE-PARAMS]:
[IANA.core-parameters]:
+==========================+================+======+===========+
| Content-Type | Content Coding | ID | Reference |
+==========================+================+======+===========+
| application/eat+cwt | - | TBD1 | RFCthis |
+--------------------------+----------------+------+-----------+
| application/eat+jwt | - | TBD2 | RFCthis |
+--------------------------+----------------+------+-----------+
| application/eat-bun+cbor | - | TBD3 | RFCthis |
+--------------------------+----------------+------+-----------+
| application/eat-bun+json | - | TBD4 | RFCthis |
+--------------------------+----------------+------+-----------+
| application/eat-ucs+cbor | - | TBD5 | RFCthis |
+--------------------------+----------------+------+-----------+
| application/eat-ucs+json | - | TBD6 | RFCthis |
+--------------------------+----------------+------+-----------+
Table 2: New Content-Formats
TBD1..6 are to be assigned from the space 256..9999.
7. Changelog
// RFC editor: please remove this section
7.1. -04
* Early IANA review
7.2. -03
* Update references
7.3. -02
* Update references
* Register +cwt SSS (Issue#14 (https://github.com/ietf-rats-wg/
draft-eat-mt/issues/14))
* Move from eat-jwt to eat+jwt (Issue#14 (https://github.com/ietf-
rats-wg/draft-eat-mt/issues/14))
* Move from eat-cwt to eat+cwt (Issue#14 (https://github.com/ietf-
rats-wg/draft-eat-mt/issues/14))
7.4. -01
* Rename profile to eat_profile for consistency with EAT (Issue#4
(https://github.com/ietf-rats-wg/draft-eat-mt/issues/4))
* The DEB acronym is gone: shorthand is now "bun" from bundle +==========================+================+=====+===========+
(Issue#8 (https://github.com/ietf-rats-wg/draft-eat-mt/issues/8)) | 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 |
+--------------------------+----------------+-----+-----------+
* Incorporate editorial suggestions from Carl and Dave (Issue#7 Table 2: New Content-Formats
(https://github.com/ietf-rats-wg/draft-eat-mt/issues/7), Issue#9
(https://github.com/ietf-rats-wg/draft-eat-mt/issues/9))
8. References 7. References
8.1. Normative References 7.1. Normative References
[BCP225] Best Current Practice 225, [BCP225] Best Current Practice 225,
<https://www.rfc-editor.org/info/bcp225>. <https://www.rfc-editor.org/info/bcp225>.
At the time of writing, this BCP comprises the following: At the time of writing, this BCP comprises the following:
Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best
Current Practices", BCP 225, RFC 8725, Current Practices", BCP 225, RFC 8725,
DOI 10.17487/RFC8725, February 2020, DOI 10.17487/RFC8725, February 2020,
<https://www.rfc-editor.org/info/rfc8725>. <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, [CWT] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
"CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
May 2018, <https://www.rfc-editor.org/rfc/rfc8392>. May 2018, <https://www.rfc-editor.org/info/rfc8392>.
[EAT] Lundblade, L., Mandyam, G., O'Donoghue, J., and C. [EAT] Lundblade, L., Mandyam, G., O'Donoghue, J., and C.
Wallace, "The Entity Attestation Token (EAT)", Work in Wallace, "The Entity Attestation Token (EAT)", RFC 9711,
Progress, Internet-Draft, draft-ietf-rats-eat-31, 6 DOI 10.17487/RFC9711, April 2025,
September 2024, <https://datatracker.ietf.org/doc/html/ <https://www.rfc-editor.org/info/rfc9711>.
draft-ietf-rats-eat-31>.
[HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, [HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110, Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022, DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/rfc/rfc9110>. <https://www.rfc-editor.org/info/rfc9110>.
[IANA.core-parameters]
IANA, "Constrained RESTful Environments (CoRE)
Parameters",
<https://www.iana.org/assignments/core-parameters>.
[IANA.media-type-structured-suffix]
IANA, "Structured Syntax Suffixes",
<https://www.iana.org/assignments/media-type-structured-
suffix>.
[IANA.media-types]
IANA, "Media Types",
<https://www.iana.org/assignments/media-types>.
[JSON] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data [JSON] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259, Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017, DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/rfc/rfc8259>. <https://www.rfc-editor.org/info/rfc8259>.
[JWT] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token [MEDIA-TYPES]
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, IANA, "Media Types",
<https://www.rfc-editor.org/rfc/rfc7519>. <https://www.iana.org/assignments/media-types>.
[MediaTypes] [MEDIATYPES]
Freed, N., Klensin, J., and T. Hansen, "Media Type Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13, Specifications and Registration Procedures", BCP 13,
RFC 6838, DOI 10.17487/RFC6838, January 2013, RFC 6838, DOI 10.17487/RFC6838, January 2013,
<https://www.rfc-editor.org/rfc/rfc6838>. <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. [UCCS] Birkholz, H., O'Donoghue, J., Cam-Winget, N., and C.
Bormann, "A CBOR Tag for Unprotected CWT Claims Sets", Bormann, "A Concise Binary Object Representation (CBOR)
Work in Progress, Internet-Draft, draft-ietf-rats-uccs-12, Tag for Unprotected CBOR Web Token Claims Sets (UCCS)",
3 November 2024, <https://datatracker.ietf.org/doc/html/ RFC 9781, DOI 10.17487/RFC9781, April 2025,
draft-ietf-rats-uccs-12>. <https://www.rfc-editor.org/info/rfc9781>.
[URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/rfc/rfc3986>. <https://www.rfc-editor.org/info/rfc3986>.
8.2. Informative References 7.2. Informative References
[BUILD-W-HTTP] [BUILD-W-HTTP]
Best Current Practice 56, Best Current Practice 56,
<https://www.rfc-editor.org/info/bcp56>. <https://www.rfc-editor.org/info/bcp56>.
At the time of writing, this BCP comprises the following: At the time of writing, this BCP comprises the following:
Nottingham, M., "Building Protocols with HTTP", BCP 56, Nottingham, M., "Building Protocols with HTTP", BCP 56,
RFC 9205, DOI 10.17487/RFC9205, June 2022, RFC 9205, DOI 10.17487/RFC9205, June 2022,
<https://www.rfc-editor.org/info/rfc9205>. <https://www.rfc-editor.org/info/rfc9205>.
[RATS-Arch] [RATS-ARCH]
Birkholz, H., Thaler, D., Richardson, M., Smith, N., and Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
W. Pan, "Remote ATtestation procedureS (RATS) W. Pan, "Remote ATtestation procedureS (RATS)
Architecture", RFC 9334, DOI 10.17487/RFC9334, January Architecture", RFC 9334, DOI 10.17487/RFC9334, January
2023, <https://www.rfc-editor.org/rfc/rfc9334>. 2023, <https://www.rfc-editor.org/info/rfc9334>.
[REST-IoT] Keränen, A., Kovatsch, M., and K. Hartke, "Guidance on [REST-IoT] Keränen, A., Kovatsch, M., and K. Hartke, "Guidance on
RESTful Design for Internet of Things Systems", Work in RESTful Design for Internet of Things Systems", Work in
Progress, Internet-Draft, draft-irtf-t2trg-rest-iot-15, 21 Progress, Internet-Draft, draft-irtf-t2trg-rest-iot-16, 23
October 2024, <https://datatracker.ietf.org/doc/html/ April 2025, <https://datatracker.ietf.org/doc/html/draft-
draft-irtf-t2trg-rest-iot-15>. irtf-t2trg-rest-iot-16>.
[TAG] Kindberg, T. and S. Hawke, "The 'tag' URI Scheme", [TAG] Kindberg, T. and S. Hawke, "The 'tag' URI Scheme",
RFC 4151, DOI 10.17487/RFC4151, October 2005, RFC 4151, DOI 10.17487/RFC4151, October 2005,
<https://www.rfc-editor.org/rfc/rfc4151>. <https://www.rfc-editor.org/info/rfc4151>.
Acknowledgments Acknowledgments
Thank you Carl Wallace, Carsten Bormann, Dave Thaler, Deb Cooley, Thank you Carl Wallace, Carsten Bormann, Dave Thaler, Deb Cooley,
Éric Vyncke, Francesca Palombini, Jouni Korhonen, Kathleen Moriarty, Éric Vyncke, Francesca Palombini, Jouni Korhonen, Kathleen Moriarty,
Michael Richardson, Murray Kucherawy, Orie Steele, Paul Howard, Roman Michael Richardson, Murray Kucherawy, Orie Steele, Paul Howard, Roman
Danyliw and Tim Hollebeek for your comments and suggestions. Danyliw, and Tim Hollebeek for your comments and suggestions.
Authors' Addresses Authors' Addresses
Laurence Lundblade Laurence Lundblade
Security Theory LLC Security Theory LLC
Email: lgl@securitytheory.com Email: lgl@securitytheory.com
Henk Birkholz Henk Birkholz
Fraunhofer Institute for Secure Information Technology Fraunhofer Institute for Secure Information Technology
Rheinstrasse 75 Rheinstrasse 75
 End of changes. 146 change blocks. 
259 lines changed or deleted 280 lines changed or added

This html diff was produced by rfcdiff 1.48.