Internet-Draft | EAT Media Types | September 2024 |
Lundblade, et al. | Expires 30 March 2025 | [Page] |
Payloads used in Remote Attestation Procedures may require an associated media type for their conveyance, for example when used in RESTful APIs.¶
This memo defines media types to be used for Entity Attestation Tokens (EAT).¶
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.¶
This Internet-Draft is submitted in full conformance with the 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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 30 March 2025.¶
Copyright (c) 2024 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) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Payloads used in Remote Attestation Procedures [RATS-Arch] may require an associated media type for their conveyance, for example when used in RESTful APIs (Figure 1).¶
This memo defines media types to be used for Entity Attestation Token (EAT) [EAT] payloads 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, for example when using HTTP [BUILD-W-HTTP] or CoAP [REST-IoT].¶
This document uses the terms and concepts defined in [RATS-Arch].¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
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 Bundle in its JSON and CBOR flavours), whilst [UCCS] defines UCCS, and we use the abbreviation "UJCS" to refer to unprotected JWT Claims Sets as defined in Section 2 of [JWT].¶
EAT is an open and flexible format. To improve interoperability, Section 6 of [EAT] 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. For example: 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 [EAT]). 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 [URI]), the parameter-value
(Appendix A of [HTTP]) MUST use the quoted-string
encoding, e.g.:¶
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, e.g.:¶
application/eat+cwt; eat_profile=2.999.1
.¶
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.¶
The example in Figure 4 illustrates the usage of EAT media types for transporting attestation results.¶
In both cases, a tag URI [TAG] identifying the profile is carried as an explicit parameter.¶
The security consideration of [EAT] and [UCCS] apply in full.¶
RFC Editor: please replace RFCthis with this RFC number and remove this note.¶
+cwt
Structured Syntax Suffix
IANA is requested to register the +cwt
structured syntax suffix in the
"Structured Syntax Suffixes" registry [IANA.media-type-structured-suffix] in
the manner described in [MediaTypes], which can be used to indicate that the
media type is encoded as a CWT.¶
CBOR Web Token (CWT)¶
+cwt¶
binary¶
N/A¶
The syntax and semantics of fragment identifiers specified for +cwt SHOULD be
as specified for application/cwt
. (At publication of this document, there
is no fragment identification syntax defined for application/cwt
.)¶
RATS WG mailing list (rats@ietf.org), or IETF Security Area (saag@ietf.org)¶
Remote ATtestation ProcedureS (RATS) Working Group. The IETF has change control over this registration.¶
IANA is requested to add the following media types to the "Media Types" registry [IANA.media-types].¶
Name | Template | Reference |
---|---|---|
EAT CWT | application/eat+cwt | RFCthis, Section 6.3 |
EAT JWT | application/eat+jwt | RFCthis, Section 6.4 |
Detached EAT Bundle CBOR | application/eat-bun+cbor | RFCthis, Section 6.5 |
Detached EAT Bundle JSON | application/eat-bun+json | RFCthis, Section 6.6 |
EAT UCCS | application/eat-ucs+cbor | RFCthis, Section 6.7 |
EAT UJCS | application/eat-ucs+json | RFCthis, Section 6.8 |
application¶
eat+cwt¶
n/a¶
"eat_profile" (EAT profile in string format. OIDs MUST use the dotted-decimal notation. The parameter value is case-insensitive.)¶
binary¶
n/a¶
Section 6.2 of RFCthis¶
Attesters, Verifiers, Endorsers and Reference-Value providers, Relying Parties that need to transfer EAT payloads over HTTP(S), CoAP(S), and other transports.¶
n/a¶
RATS WG mailing list (rats@ietf.org)¶
COMMON¶
none¶
IETF¶
no¶
application¶
eat+jwt¶
n/a¶
"eat_profile" (EAT profile in string format. OIDs MUST use the dotted-decimal notation. The parameter value is case-insensitive.)¶
8bit¶
n/a¶
Section 6.2 of RFCthis¶
Attesters, Verifiers, Endorsers and Reference-Value providers, Relying Parties that need to transfer EAT payloads over HTTP(S), CoAP(S), and other transports.¶
n/a¶
RATS WG mailing list (rats@ietf.org)¶
COMMON¶
none¶
IETF¶
no¶
application¶
eat-bun+cbor¶
n/a¶
"eat_profile" (EAT profile in string format. OIDs MUST use the dotted-decimal notation. The parameter value is case-insensitive.)¶
binary¶
n/a¶
Section 6.2 of RFCthis¶
Attesters, Verifiers, Endorsers and Reference-Value providers, Relying Parties that need to transfer EAT payloads over HTTP(S), CoAP(S), and other transports.¶
n/a¶
RATS WG mailing list (rats@ietf.org)¶
COMMON¶
none¶
IETF¶
no¶
application¶
eat-bun+json¶
n/a¶
"eat_profile" (EAT profile in string format. OIDs MUST use the dotted-decimal notation. The parameter value is case-insensitive.)¶
n/a¶
Section 6.2 of RFCthis¶
Attesters, Verifiers, Endorsers and Reference-Value providers, Relying Parties that need to transfer EAT payloads over HTTP(S), CoAP(S), and other transports.¶
n/a¶
RATS WG mailing list (rats@ietf.org)¶
COMMON¶
none¶
IETF¶
no¶
application¶
eat-ucs+cbor¶
n/a¶
"eat_profile" (EAT profile in string format. OIDs MUST use the dotted-decimal notation. The parameter value is case-insensitive.)¶
binary¶
n/a¶
Section 6.2 of RFCthis¶
Attesters, Verifiers, Endorsers and Reference-Value providers, Relying Parties that need to transfer EAT payloads over HTTP(S), CoAP(S), and other transports.¶
n/a¶
RATS WG mailing list (rats@ietf.org)¶
COMMON¶
none¶
IETF¶
no¶
application¶
eat-ucs+json¶
n/a¶
"eat_profile" (EAT profile in string format. OIDs MUST use the dotted-decimal notation. The parameter value is case-insensitive.)¶
n/a¶
Section 6.2 of RFCthis¶
Attesters, Verifiers, Endorsers and Reference-Value providers, Relying Parties that need to transfer EAT payloads over HTTP(S), CoAP(S), and other transports.¶
n/a¶
RATS WG mailing list (rats@ietf.org)¶
COMMON¶
none¶
IETF¶
no¶
IANA is requested to register the following Content-Format numbers in the "CoAP Content-Formats" sub-registry, within the "Constrained RESTful Environments (CoRE) Parameters" Registry [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 |
TBD1..6 are to be assigned from the space 256..999.¶
Thank you Carl Wallace, Carsten Bormann, Dave Thaler, Deb Cooley, Kathleen Moriarty, Michael Richardson, and Paul Howard for your comments and suggestions.¶