rfc9782v1.txt		rfc9782.txt
	skipping to change at line 14 ¶		skipping to change at line 14 ¶
	Category: Standards Track H. Birkholz		Category: Standards Track H. Birkholz
	ISSN: 2070-1721 Fraunhofer SIT		ISSN: 2070-1721 Fraunhofer SIT
	T. Fossati		T. Fossati
	Linaro		Linaro
	April 2025		April 2025
	Entity Attestation Token (EAT) Media Types		Entity Attestation Token (EAT) Media Types
	Abstract		Abstract
	Payloads used in Remote ATtestation procedureS (RATS) 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 (EATs).		Tokens (EATs).
	Status of This Memo		Status of This Memo
	This is an Internet Standards Track document.		This is an Internet Standards Track document.
	This document is a product of the Internet Engineering Task Force		This document is a product of the Internet Engineering Task Force
	(IETF). It represents the consensus of the IETF community. It has		(IETF). It represents the consensus of the IETF community. It has
	skipping to change at line 116 ¶		skipping to change at line 116 ¶
	[REST-IoT].		[REST-IoT].
	1.1. Terminology		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 (CBOR Web Token (CWT), JSON		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		Web Token (JWT) [JWT], and the detached EAT bundle in its JSON and
	flavours), while [UCCS] defines the Unprotected CWT Claims Set (UCCS)		CBOR flavours), while [UCCS] defines the Unprotected CWT Claims Set
	and Unprotected JWT Claims Sets (UJCS).		(UCCS) and Unprotected JWT Claims Sets (UJCS).
	.-----.		.-----.
	.----+ UJCS |<-------------------------.		.----+ UJCS |<-------------------------.
	| '-----' |		| '-----' |
	| |		| |
	| .-----. |		| .-----. |
	+-----+ UCCS |<-----------------------. |		+-----+ UCCS |<-----------------------. |
	| '-----' | |		| '-----' | |
	| | |		| | |
	| .------. | |		| .------. | |
	skipping to change at line 163 ¶		skipping to change at line 163 ¶
	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,
	e.g., the number and type of claims, which serialisation format, the		e.g., the number and type of claims, which serialisation format, the
	supported signature schemes, etc. EATs carry an in-band profile		supported signature schemes, etc. EATs carry an in-band profile
	identifier using the eat_profile claim (see Section 4.3.2 of [EAT]).		identifier using the "eat_profile" claim (see Section 4.3.2 of
	The value of the eat_profile claim is either an OID or a URI.		[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		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, for example:		(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.,
	skipping to change at line 638 ¶		skipping to change at line 639 ¶
	<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/info/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/info/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
End of changes. 6 change blocks.
	13 lines changed or deleted		14 lines changed or added
This html diff was produced by rfcdiff 1.48.