rfc9782.original.xml		rfc9782.xml
	<?xml version='1.0' encoding='utf-8'?>		<?xml version='1.0' encoding='UTF-8'?>
	<!DOCTYPE rfc [		<!DOCTYPE rfc [
	<!ENTITY nbsp "&#160;">		<!ENTITY nbsp "&#160;">
	<!ENTITY zwsp "&#8203;">		<!ENTITY zwsp "&#8203;">
	<!ENTITY nbhy "&#8209;">		<!ENTITY nbhy "&#8209;">
	<!ENTITY wj "&#8288;">		<!ENTITY wj "&#8288;">
	]>		]>
	<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
	<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.20 (Ruby 3.3.		<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
	3) -->		-ietf-rats-eat-media-type-12" number="9782" category="std" consensus="true" subm
	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft		issionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3" x
	-ietf-rats-eat-media-type-12" category="std" consensus="true" submissionType="IE		ml:lang="en" updates="" obsoletes="">
	TF" tocInclude="true" sortRefs="true" symRefs="true" version="3">		<!-- [rfced] We have updated the title of the document to expand "EAT" per
	<!-- xml2rfc v2v3 conversion 3.24.0 -->		Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review.
	<front>
	<title abbrev="EAT Media Types">EAT Media Types</title>		Original:
	<seriesInfo name="Internet-Draft" value="draft-ietf-rats-eat-media-type-12"/		EAT Media Types
	>
			Current:
			Entity Attestation Token (EAT) Media Types
			-->
			<front>
			<title abbrev="EAT Media Types">Entity Attestation
			Token (EAT) Media Types</title>
			<seriesInfo name="RFC" value="9782"/>
	<author initials="L." surname="Lundblade" fullname="Laurence Lundblade">		<author initials="L." surname="Lundblade" fullname="Laurence Lundblade">
	<organization>Security Theory LLC</organization>		<organization>Security Theory LLC</organization>
	<address>		<address>
	<email>lgl@securitytheory.com</email>		<email>lgl@securitytheory.com</email>
	</address>		</address>
	</author>		</author>
	<author initials="H." surname="Birkholz" fullname="Henk Birkholz">		<author initials="H." surname="Birkholz" fullname="Henk Birkholz">
	<organization abbrev="Fraunhofer SIT">Fraunhofer Institute for Secure Info rmation Technology</organization>		<organization abbrev="Fraunhofer SIT">Fraunhofer Institute for Secure Info rmation Technology</organization>
	<address>		<address>
	<postal>		<postal>
	skipping to change at line 39 ¶		skipping to change at line 48 ¶
	</postal>		</postal>
	<email>henk.birkholz@ietf.contact</email>		<email>henk.birkholz@ietf.contact</email>
	</address>		</address>
	</author>		</author>
	<author initials="T." surname="Fossati" fullname="Thomas Fossati">		<author initials="T." surname="Fossati" fullname="Thomas Fossati">
	<organization>Linaro</organization>		<organization>Linaro</organization>
	<address>		<address>
	<email>thomas.fossati@linaro.org</email>		<email>thomas.fossati@linaro.org</email>
	</address>		</address>
	</author>		</author>
	<date year="2024" month="November" day="03"/>		<date year="2025" month="April"/>
	<area>Security</area>		<area>SEC</area>
	<workgroup>Remote ATtestation ProcedureS</workgroup>		<workgroup>rats</workgroup>
	<keyword>EAT, media type</keyword>		<keyword>EAT</keyword>
			<keyword>media type</keyword>
	<abstract>		<abstract>
	<?line 56?>		<!-- [rfced] Abstract and Section 1: Note that we have updated the expansion of RATS per RFC 9334. In addition, may we rephrase the text as follows to clarify the object being used in RESTful APIs?
	<t>Payloads used in Remote Attestation Procedures may require an associated medi		Original:
	a		Payloads used in Remote Attestation Procedures may require an
	type for their conveyance, for example when used in RESTful APIs.</t>		associated media type for their conveyance, for example when used in
	<t>This memo defines media types to be used for Entity Attestation Tokens		RESTful APIs.
	(EAT).</t>
			Perhaps:
			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.
			-->
			<t>Payloads used in Remote ATtestation procedureS (RATS) may require an
			associated media type for their conveyance, for example, when used in
			RESTful APIs.</t>
			<t>This memo defines media types to be used for Entity Attestation Tokens
			(EATs).</t>
	</abstract>		</abstract>
	<note removeInRFC="true">
	<name>Discussion Venues</name>
	<t>Discussion of this document takes place on the
	Remote ATtestation ProcedureS Working Group mailing list (rats@ietf.org),
	which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/
	rats/"/>.</t>
	<t>Source for this draft and an issue tracker can be found at
	<eref target="https://github.com/thomas-fossati/draft-eat-mt"/>.</t>
	</note>
	</front>		</front>
	<middle>		<middle>
	<?line 63?>
	<section anchor="introduction">		<section anchor="introduction">
	<name>Introduction</name>		<name>Introduction</name>
	<t>Payloads used in Remote Attestation Procedures <xref target="RATS-Arch"		<t>Payloads used in Remote ATtestation procedureS (RATS) <xref target="RFC
	/> may require an		9334"/> may require an
	associated media type for their conveyance, for example when used in RESTful		associated media type for their conveyance, for example, when used in RESTful
	APIs (<xref target="fig-api-sd"/>).</t>		APIs (<xref target="fig-api-sd"/>).</t>
	<figure anchor="fig-api-sd">		<figure anchor="fig-api-sd">
	<name>Conveying RATS conceptual messages in REST APIs using EAT</name>		<name>Conveying RATS Conceptual Messages in REST APIs Using EATs</name>
	<artset>		<artset>
	<artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2000/ svg" version="1.1" height="288" width="512" viewBox="0 0 512 288" class="diagram " text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap=" round">		<artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2000/ svg" version="1.1" height="288" width="512" viewBox="0 0 512 288" class="diagram " text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap=" round">
	<path d="M 8,32 L 8,64" fill="none" stroke="black"/>		<path d="M 8,32 L 8,64" fill="none" stroke="black"/>
	<path d="M 24,64 L 24,272" fill="none" stroke="black"/>		<path d="M 24,64 L 24,272" fill="none" stroke="black"/>
	<path d="M 136,32 L 136,64" fill="none" stroke="black"/>		<path d="M 136,32 L 136,64" fill="none" stroke="black"/>
	<path d="M 216,32 L 216,64" fill="none" stroke="black"/>		<path d="M 216,32 L 216,64" fill="none" stroke="black"/>
	<path d="M 256,64 L 256,272" fill="none" stroke="black"/>		<path d="M 256,64 L 256,272" fill="none" stroke="black"/>
	<path d="M 304,32 L 304,64" fill="none" stroke="black"/>		<path d="M 304,32 L 304,64" fill="none" stroke="black"/>
	<path d="M 416,32 L 416,64" fill="none" stroke="black"/>		<path d="M 416,32 L 416,64" fill="none" stroke="black"/>
	<path d="M 488,64 L 488,272" fill="none" stroke="black"/>		<path d="M 488,64 L 488,272" fill="none" stroke="black"/>
	skipping to change at line 135 ¶		skipping to change at line 147 ¶
	| POST /auth | |		| POST /auth | |
	| EAT(Attestation Results) | |		| EAT(Attestation Results) | |
	|<---------------------------+ |		|<---------------------------+ |
	| 201 Created | |		| 201 Created | |
	+--------------------------->| |		+--------------------------->| |
	| | |		| | |
	| | |		| | |
	]]></artwork>		]]></artwork>
	</artset>		</artset>
	</figure>		</figure>
	<t>This memo defines media types to be used for Entity Attestation Token (		<t>This memo defines media types to be used for EAT
	EAT)		payloads <xref target="RFC9711"/> independently of the RATS Conceptual Message i
	<xref target="EAT"/> payloads independently of the RATS Conceptual Message in wh		n which they
	ich they		manifest themselves. The objective is to give protocol, API, and application
	manifest themselves. The objective is to give protocol, API and application
	designers a number of readily available and reusable media types for		designers a number of readily available and reusable media types for
	integrating EAT-based messages in their flows, for example when using HTTP		integrating EAT-based messages in their flows, e.g., when using HTTP
	<xref target="BUILD-W-HTTP"/> or CoAP <xref target="REST-IoT"/>.</t>		<xref target="BCP56"/> or the Constrained Application Protocol (CoAP) <xref targ
	<section anchor="requirements-language">		et="I-D.irtf-t2trg-rest-iot"/>.</t>
	<name>Requirements Language</name>		<!-- [rfced] FYI - We have updated the title of Section 1.1 to "Terminology"
	<t>This document uses the terms and concepts defined in <xref target="RA		from "Requirements Language" in order to avoid confusion regarding the
	TS-Arch"/>.</t>		use of "Requirements Language" in RFCs 2119 and 8174 (see
			https://www.rfc-editor.org/rfc/rfc7322.html#section-4.8.2). Please let us
			know any objections.
			-->
			<section anchor="terminology">
			<name>Terminology</name>
			<t>This document uses the terms and concepts defined in <xref target="RF
			C9334"/>.</t>
	</section>		</section>
	</section>		</section>
	<section anchor="eat-types">		<section anchor="eat-types">
	<name>EAT Types</name>		<name>EAT Types</name>
	<t><xref target="fig-eat-types"/> illustrates the six EAT wire formats and how they relate to		<t><xref target="fig-eat-types"/> illustrates the six EAT wire formats and how they relate to
	each other. <xref target="EAT"/> defines four of them (CWT, JWT and Detached EA		each other. <xref target="RFC9711"/> defines four of them (CBOR Web Token (CWT)
	T Bundle in		, JSON Web Token (JWT), and the detached EAT bundle in
	its JSON and CBOR flavours), whilst <xref target="UCCS"/> defines UCCS and UJCS.		its JSON and CBOR flavours), while <xref target="RFC9781"/> defines the Unprotec
	</t>		ted CWT Claims Set (UCCS) and Unprotected JWT Claims Sets (UJCS).</t>
			<!-- [rfced] Figure 2: Note that we have changed "Legenda" to "Legend" for clari
			ty. Legeneda appears in some dictionaries without being defined as a key or exp
			lantion for a map or chart.
			-->
	<figure anchor="fig-eat-types">		<figure anchor="fig-eat-types">
	<name>EAT Types</name>		<name>EAT Types</name>
	<artset>		<artset>
	<artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2000/ svg" version="1.1" height="544" width="520" viewBox="0 0 520 544" class="diagram " text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap=" round">		<artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2000/ svg" version="1.1" height="544" width="520" viewBox="0 0 520 544" class="diagram " text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap=" round">
	<path d="M 8,432 L 8,464" fill="none" stroke="black"/>		<path d="M 8,432 L 8,464" fill="none" stroke="black"/>
	<path d="M 72,64 L 72,424" fill="none" stroke="black"/>		<path d="M 72,64 L 72,424" fill="none" stroke="black"/>
	<path d="M 120,48 L 120,64" fill="none" stroke="black"/>		<path d="M 120,48 L 120,64" fill="none" stroke="black"/>
	<path d="M 120,112 L 120,128" fill="none" stroke="black"/>		<path d="M 120,112 L 120,128" fill="none" stroke="black"/>
	<path d="M 120,176 L 120,192" fill="none" stroke="black"/>		<path d="M 120,176 L 120,192" fill="none" stroke="black"/>
	<path d="M 120,240 L 120,256" fill="none" stroke="black"/>		<path d="M 120,240 L 120,256" fill="none" stroke="black"/>
	skipping to change at line 305 ¶		skipping to change at line 325 ¶
	<text x="152" y="180">JWT</text>		<text x="152" y="180">JWT</text>
	<text x="260" y="212">Crypto</text>		<text x="260" y="212">Crypto</text>
	<text x="152" y="244">CWT</text>		<text x="152" y="244">CWT</text>
	<text x="388" y="276">Claims-Set</text>		<text x="388" y="276">Claims-Set</text>
	<text x="152" y="308">BUN-J</text>		<text x="152" y="308">BUN-J</text>
	<text x="260" y="340">Bundle</text>		<text x="260" y="340">Bundle</text>
	<text x="476" y="340">Digest</text>		<text x="476" y="340">Digest</text>
	<text x="152" y="372">BUN-C</text>		<text x="152" y="372">BUN-C</text>
	<text x="388" y="388">submod</text>		<text x="388" y="388">submod</text>
	<text x="68" y="452">Nested-Token</text>		<text x="68" y="452">Nested-Token</text>
	<text x="76" y="516">Legenda:</text>		<text x="76" y="516">Legend:</text>
	<text x="168" y="516">Process</text>		<text x="168" y="516">Process</text>
	<text x="268" y="516">Wire</text>		<text x="268" y="516">Wire</text>
	<text x="304" y="516">Fmt</text>		<text x="304" y="516">Fmt</text>
	<text x="388" y="516">CDDL</text>		<text x="388" y="516">CDDL</text>
	</g>		</g>
	</svg>		</svg>
	</artwork>		</artwork>
	<artwork type="ascii-art" align="center"><![CDATA[		<artwork type="ascii-art" align="center"><![CDATA[
	.-----.		.-----.
	.----+ UJCS |<-------------------------.		.----+ UJCS |<-------------------------.
	skipping to change at line 344 ¶		skipping to change at line 364 ¶
	| .------. '--+---' | v '--+---'		| .------. '--+---' | v '--+---'
	+-----+ BUN-C |<------' ^ .---+----. |		+-----+ BUN-C |<------' ^ .---+----. |
	| '------' | | submod |<---'		| '------' | | submod |<---'
	| | '--------'		| | '--------'
	v | ^		v | ^
	.--------------. | |		.--------------. | |
	| Nested-Token +-----------------+------------'		| Nested-Token +-----------------+------------'
	'--------------'		'--------------'
	.-------. .---------. .------.		.-------. .---------. .------.
	Legenda: | Process | | Wire Fmt | | CDDL |		Legend: | Process | | Wire Fmt | | CDDL |
	'-------' '---------' '------'		'-------' '---------' '------'
	]]></artwork>		]]></artwork>
	</artset>		</artset>
	</figure>		</figure>
	</section>		</section>
	<section anchor="a-media-type-parameter-for-eat-profiles">		<section anchor="a-media-type-parameter-for-eat-profiles">
	<name>A Media Type Parameter for EAT Profiles</name>		<name>A Media Type Parameter for EAT Profiles</name>
	<t>EAT is an open and flexible format. To improve interoperability, <xref		<!-- [rfced] RFC-to-be 9711 <draft-ietf-rats-eat> seems to double quotes for Cla
	section="6" sectionFormat="of" target="EAT"/> defines the concept of EAT profil		im names, while this document seems to use <tt>. Should this document use doubl
	es. Profiles are used to constrain		e quotes to align with RFC 9711?
			Example from 9711:
			The "eat_profile" claim identifies ...
			From section 3 of this document:
			... identifier using the eat_profile claim ...
			In addition, please review the use of <tt> to ensure use is as desired
			and consistent. The pattern of use is unclear to us. We see the
			following instances of <tt>:
			<tt>eat_profile</tt> claim
			<tt>eat_profile</tt> parameter
			<tt>application/eat+cwt</tt>
			<tt>parameter-value</tt>
			<tt>quoted-string</tt> encoding
			<tt>application/eat+jwt; eat_profile="tag:evidence.example,2022"</tt>
			<tt>token</tt> encoding
			<tt>application/eat+cwt; eat_profile=2.999.1</tt>
			<tt>application/eat-ucs+json</tt> and <tt>application/eat-ucs+cbor</tt>
			<tt>+cwt</tt> Structured Syntax Suffix
			<tt>+cwt</tt>
			<tt>application/cwt</tt>
			Double quotes are used in the registration templates:
			Optional parameters: "eat_profile"
			application/eat* (sans <tt> in table)
			+cwt (sans <tt> in the IANA template)
			-->
			<t>EAT is an open and flexible format. To improve interoperability, <xref
			section="6" sectionFormat="of" target="RFC9711"/> defines the concept of EAT pr
			ofiles. Profiles are used to constrain
	the parameters that producers and consumers of a specific EAT profile need to		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		understand in order to interoperate, e.g., the number and type of
	claims, which serialisation format, the supported signature schemes, etc. EATs		claims, which serialisation format, the supported signature schemes, etc. EATs
	carry an in-band profile identifier using the <tt>eat_profile</tt> claim (see		carry an in-band profile identifier using the <tt>eat_profile</tt> claim (see
	<xref section="4.3.2" sectionFormat="of" target="EAT"/>). The value of the <tt> eat_profile</tt> claim is either an		<xref section="4.3.2" sectionFormat="of" target="RFC9711"/>). The value of the <tt>eat_profile</tt> claim is either an
	OID or a URI.</t>		OID or a URI.</t>
	<t>The media types defined in this document include an optional <tt>eat_pr ofile</tt>		<t>The media types defined in this document include an optional <tt>eat_pr ofile</tt>
	parameter that can be used to mirror the <tt>eat_profile</tt> claim of the trans ported		parameter that can be used to mirror the <tt>eat_profile</tt> claim of the trans ported
	EAT. Exposing the EAT profile at the API layer allows API routers to dispatch		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		payloads directly to the profile-specific processor without having to snoop
	into the request bodies. This design also provides a finer-grained and		into the request bodies. This design also provides a finer-grained and
	scalable type system that matches the inherent extensibility of EAT. The		scalable type system that matches the inherent extensibility of EAT. The
	expectation being that a certain EAT profile automatically obtains a media type		expectation being that a certain EAT profile automatically obtains a media type
	derived from the base (e.g., <tt>application/eat+cwt)</tt> by populating the		derived from the base (e.g., <tt>application/eat+cwt</tt>) by populating the
	<tt>eat_profile</tt> parameter with the corresponding OID or URL.</t>		<tt>eat_profile</tt> parameter with the corresponding OID or URL.</t>
	<t>When the parameterised version of the EAT media type is used in HTTP (f or		<t>When the parameterised version of the EAT media type is used in HTTP (f or
	example, with the "Content-Type" and "Accept" headers), and the value is an		example, with the "Content-Type" and "Accept" headers) and the value is an
	absolute URI (<xref section="4.3" sectionFormat="of" target="URI"/>), the <tt>pa		absolute URI (<xref section="4.3" sectionFormat="of" target="RFC3986"/>), the <t
	rameter-value</tt> (<xref section="A" sectionFormat="of" target="HTTP"/>) uses t		t>parameter-value</tt> (<xref section="A" sectionFormat="of" target="RFC9110"/>)
	he <tt>quoted-string</tt> encoding, e.g.:</t>		uses the <tt>quoted-string</tt> encoding, for example:</t>
	<ul empty="true">		<t indent="5"><tt>application/eat+jwt; eat_profile="tag:evidence.example,2
	<li>		022"</tt></t>
	<t><tt>application/eat+jwt; eat_profile="tag:evidence.example,2022"</t		<t>Instead, when the EAT profile is an OID, the <tt>token</tt> encoding
	t></t>		(i.e., without quotes) can be used. For example:</t>
	</li>		<t indent="5"><tt>application/eat+cwt; eat_profile=2.999.1</tt>.</t>
	</ul>
	<t>Instead, when the EAT profile is an OID, the <tt>token</tt> encoding (i
	.e., without
	quotes) can be used, e.g.:</t>
	<ul empty="true">
	<li>
	<t><tt>application/eat+cwt; eat_profile=2.999.1</tt>.</t>
	</li>
	</ul>
	</section>		</section>
	<section anchor="examples">		<section anchor="examples">
	<name>Examples</name>		<name>Examples</name>
	<t>The example in <xref target="fig-rest-req"/> illustrates the usage of E AT media types for		<t>The example in <xref target="fig-rest-req"/> illustrates the usage of E AT media types for
	transporting attestation evidence as well as negotiating the acceptable format		transporting attestation evidence as well as negotiating the acceptable format
	of the attestation result.</t>		of the attestation result.</t>
			<!-- [rfced] Note that we have updated the "NOTE" in Figures 3 and 4 to
			reflect what appears in Section 7.1.1 in RFC 8792
			(https://www.rfc-editor.org/rfc/rfc8792.html#name-header). Are the pound symbol
			s important (e.g., do they indicate comments)?
			Original:
			# NOTE: '\' line wrapping per RFC 8792
			Updated:
			NOTE: '\' line wrapping per RFC 8792
			-->
	<figure anchor="fig-rest-req">		<figure anchor="fig-rest-req">
	<name>Example REST Verification API (request)</name>		<name>Example REST Verification API (request)</name>
	<sourcecode type="http-message"><![CDATA[		<sourcecode type="http-message"><![CDATA[
	# 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" ]
	]]></sourcecode>		]]></sourcecode>
	</figure>		</figure>
	<t>The example in <xref target="fig-rest-rsp"/> illustrates the usage of E AT media types for		<t>The example in <xref target="fig-rest-rsp"/> illustrates the usage of E AT media types for
	transporting attestation results.</t>		transporting attestation results.</t>
	<figure anchor="fig-rest-rsp">		<figure anchor="fig-rest-rsp">
	<name>Example REST Verification API (response)</name>		<name>Example REST Verification API (response)</name>
	<sourcecode type="http-message"><![CDATA[		<sourcecode type="http-message"><![CDATA[
	# 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" ]
	]]></sourcecode>		]]></sourcecode>
	</figure>		</figure>
	<t>In both cases, a tag URI <xref target="TAG"/> identifying the profile i s carried as an		<t>In both cases, a tag URI <xref target="RFC4151"/> identifying the profi le is carried as an
	explicit parameter.</t>		explicit parameter.</t>
	</section>		</section>
	<section anchor="seccons">		<section anchor="seccons">
	<name>Security Considerations</name>		<name>Security Considerations</name>
	<t>Media types only provide clues to the processing application. The appli cation		<t>Media types only provide clues to the processing application. The appli cation
	must verify that the received data matches the expected format, regardless of		must verify that the received data matches the expected format, regardless of
	the advertised media type, and stop further processing on failure. Failing to		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		do so could expose the user to security risks, such as privilege escalation
	and cross-protocol attacks.</t>		and cross-protocol attacks.</t>
	<t>The security consideration of <xref target="EAT"/> and <xref target="UC		<t>The security considerations of <xref target="RFC9711"/> and <xref targe
	CS"/> apply in full.</t>		t="RFC9781"/> apply in full.</t>
	<t>In particular, when using <tt>application/eat-ucs+json</tt> and <tt>app		<t>When using <tt>application/eat-ucs+json</tt> and <tt>application/eat-uc
	lication/eat-ucs+cbor</tt> the reader should review <xref section="3" sectionFor		s+cbor</tt> in particular, the reader should review <xref section="3" sectionFor
	mat="of" target="UCCS"/>, which contains a detailed discussion about the charact		mat="of" target="RFC9781"/>, which contains a detailed discussion about the char
	eristics of a "Secure Channel" for conveyance of such messages.</t>		acteristics of a "Secure Channel" for conveyance of such messages.</t>
	</section>		</section>
	<section anchor="iana-considerations">		<section anchor="iana-considerations">
	<name>IANA Considerations</name>		<name>IANA Considerations</name>
	<t><cref anchor="to-be-removed">RFC Editor: please replace RFCthis with th is RFC number and remove this note.</cref></t>
	<section anchor="cwt-structured-syntax-suffix">		<section anchor="cwt-structured-syntax-suffix">
	<name><tt>+cwt</tt> Structured Syntax Suffix</name>		<name><tt>+cwt</tt> Structured Syntax Suffix</name>
	<t>IANA is requested to register the <tt>+cwt</tt> structured syntax suf		<t>IANA has registered <tt>+cwt</tt> in the
	fix in the		"Structured Syntax Suffixes" registry <xref target="STRUCT-SYNTAX"/> in
	"Structured Syntax Suffixes" registry <xref target="IANA.media-type-structured-s		the manner described in <xref target="RFC6838"/>. <tt>+cwt</tt> can be used to
	uffix"/> in		indicate that the
	the manner described in <xref target="MediaTypes"/>, which can be used to indica
	te that the
	media type is encoded as a CWT.</t>		media type is encoded as a CWT.</t>
	<section anchor="registry-contents">		<section anchor="registry-contents">
	<name>Registry Contents</name>		<name>Registry Contents</name>
	<dl spacing="compact">		<dl spacing="normal" newline="false">
	<dt>Name:</dt>		<dt>Name:</dt>
	<dd>		<dd>
	<t>CBOR Web Token (CWT)</t>		<t>CBOR Web Token (CWT)</t>
	</dd>		</dd>
	<dt>+suffix:</dt>		<dt>+suffix:</dt>
	<dd>		<dd>
	<t>+cwt</t>		<t>+cwt</t>
	</dd>		</dd>
	<dt>References:</dt>		<dt>References:</dt>
	<dd>		<dd>
	<t><xref target="CWT"/></t>		<t><xref target="RFC8392"/></t>
	</dd>		</dd>
	<dt>Encoding Considerations:</dt>		<dt>Encoding Considerations:</dt>
	<dd>		<dd>
	<t>binary</t>		<t>binary</t>
	</dd>		</dd>
	<dt>Interoperability Considerations:</dt>		<dt>Interoperability Considerations:</dt>
	<dd>		<dd>
	<t>N/A</t>		<t>N/A</t>
	</dd>		</dd>
	<dt>Fragment Identifier Considerations:</dt>		<dt>Fragment Identifier Considerations:</dt>
	<dd>		<dd>
	<t>The syntax and semantics of fragment identifiers specified for +cwt SHOULD be		<t>The syntax and semantics of fragment identifiers specified for +cwt SHOULD be
	as specified for <tt>application/cwt</tt>. (At publication of this document, th ere		as specified for <tt>application/cwt</tt>. (At the time of publication, there
	is no fragment identification syntax defined for <tt>application/cwt</tt>.)</t>		is no fragment identification syntax defined for <tt>application/cwt</tt>.)</t>
	</dd>		</dd>
	<dt>Security Considerations:</dt>		<dt>Security Considerations:</dt>
	<dd>		<dd>
	<t>See <xref section="8" sectionFormat="of" target="CWT"/></t>		<t>See <xref section="8" sectionFormat="of" target="RFC8392"/></t>
	</dd>		</dd>
	<dt>Contact:</dt>		<dt>Contact:</dt>
	<dd>		<dd>
	<t>RATS WG mailing list (rats@ietf.org), or IETF Security Area (sa ag@ietf.org)</t>		<t>RATS WG mailing list (rats@ietf.org), or IETF Security Area (sa ag@ietf.org)</t>
	</dd>		</dd>
	<dt>Author/Change Controller:</dt>		<dt>Author/Change Controller:</dt>
	<dd>		<dd>
	<t>Remote ATtestation ProcedureS (RATS) Working Group.		<t>Remote ATtestation ProcedureS (RATS) Working Group.
	The IETF has change control over this registration.</t>		The IETF has change control over this registration.</t>
	</dd>		</dd>
	</dl>		</dl>
	</section>		</section>
	</section>		</section>
	<section anchor="media-type">		<section anchor="media-type">
	<name>Media Types</name>		<name>Media Types</name>
	<t>IANA is requested to add the following media types to the		<t>IANA has registered the following media types in the
	"Media Types" registry <xref target="IANA.media-types"/>.</t>		"Media Types" registry <xref target="MEDIA-TYPES"/>.</t>
	<table align="left" anchor="new-media-type">		<table align="center" anchor="new-media-type">
	<name>New Media Types</name>		<name>New Media Types</name>
	<thead>		<thead>
	<tr>		<tr>
	<th align="left">Name</th>		<th align="left">Name</th>
	<th align="left">Template</th>		<th align="left">Template</th>
	<th align="left">Reference</th>		<th align="left">Reference</th>
	</tr>		</tr>
	</thead>		</thead>
	<tbody>		<tbody>
	<tr>		<tr>
	<td align="left">EAT CWT</td>		<td align="left">EAT CWT</td>
	<td align="left">application/eat+cwt</td>		<td align="left">application/eat+cwt</td>
	<td align="left">RFCthis, <xref target="media-type-eat-cwt"/></td>		<td align="left">RFC 9782, <xref target="media-type-eat-cwt"/></td >
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">EAT JWT</td>		<td align="left">EAT JWT</td>
	<td align="left">application/eat+jwt</td>		<td align="left">application/eat+jwt</td>
	<td align="left">RFCthis, <xref target="media-type-eat-jwt"/></td>		<td align="left">RFC 9782, <xref target="media-type-eat-jwt"/></td >
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">Detached EAT Bundle CBOR</td>		<td align="left">Detached EAT Bundle CBOR</td>
	<td align="left">application/eat-bun+cbor</td>		<td align="left">application/eat-bun+cbor</td>
	<td align="left">RFCthis, <xref target="media-type-deb-cbor"/></td >		<td align="left">RFC 9782, <xref target="media-type-deb-cbor"/></t d>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">Detached EAT Bundle JSON</td>		<td align="left">Detached EAT Bundle JSON</td>
	<td align="left">application/eat-bun+json</td>		<td align="left">application/eat-bun+json</td>
	<td align="left">RFCthis, <xref target="media-type-deb-json"/></td >		<td align="left">RFC 9782, <xref target="media-type-deb-json"/></t d>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">EAT UCCS</td>		<td align="left">EAT UCCS</td>
	<td align="left">application/eat-ucs+cbor</td>		<td align="left">application/eat-ucs+cbor</td>
	<td align="left">RFCthis, <xref target="media-type-ucs-cbor"/></td >		<td align="left">RFC 9782, <xref target="media-type-ucs-cbor"/></t d>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">EAT UJCS</td>		<td align="left">EAT UJCS</td>
	<td align="left">application/eat-ucs+json</td>		<td align="left">application/eat-ucs+json</td>
	<td align="left">RFCthis, <xref target="media-type-ucs-json"/></td >		<td align="left">RFC 9782, <xref target="media-type-ucs-json"/></t d>
	</tr>		</tr>
	</tbody>		</tbody>
	</table>		</table>
	</section>		</section>
	<section anchor="media-type-eat-cwt">		<section anchor="media-type-eat-cwt">
	<name>application/eat+cwt Registration</name>		<name>application/eat+cwt Registration</name>
	<dl spacing="compact">		<dl spacing="normal" newline="false">
	<dt>Type name:</dt>		<dt>Type name:</dt>
	<dd>		<dd>
	<t>application</t>		<t>application</t>
	</dd>		</dd>
	<dt>Subtype name:</dt>		<dt>Subtype name:</dt>
	<dd>		<dd>
	<t>eat+cwt</t>		<t>eat+cwt</t>
	</dd>		</dd>
	<dt>Required parameters:</dt>		<dt>Required parameters:</dt>
	<dd>		<dd>
	<t>n/a</t>		<t>n/a</t>
	</dd>		</dd>
	<dt>Optional parameters:</dt>		<dt>Optional parameters:</dt>
	<dd>		<dd>
	<t>"eat_profile" (EAT profile in string format. OIDs must use the		<t>"eat_profile" (EAT profile in string format. OIDs must use the
	dotted-decimal notation. The parameter value is case-insensitive.)</t>		dotted-decimal notation. The parameter value is case insensitive.)</t>
	</dd>		</dd>
	<dt>Encoding considerations:</dt>		<dt>Encoding considerations:</dt>
	<dd>		<dd>
	<t>binary</t>		<t>binary</t>
	</dd>		</dd>
	<dt>Security considerations:</dt>		<dt>Security considerations:</dt>
	<dd>		<dd>
	<t><xref section="9" sectionFormat="of" target="EAT"/></t>		<t><xref section="9" sectionFormat="of" target="RFC9711"/></t>
	</dd>		</dd>
	<dt>Interoperability considerations:</dt>		<dt>Interoperability considerations:</dt>
	<dd>		<dd>
	<t>n/a</t>		<t>n/a</t>
	</dd>		</dd>
	<dt>Published specification:</dt>		<dt>Published specification:</dt>
	<dd>		<dd>
	<t>RFCthis</t>		<t>RFC 9782</t>
	</dd>		</dd>
	<dt>Applications that use this media type:</dt>		<dt>Applications that use this media type:</dt>
	<dd>		<dd>
	<t>Attesters, Verifiers, Endorsers and Reference-Value providers, Re lying		<t>Attesters, Verifiers, Endorsers and Reference-Value providers, an d Relying
	Parties that need to transfer EAT payloads over HTTP(S), CoAP(S), and other		Parties that need to transfer EAT payloads over HTTP(S), CoAP(S), and other
	transports.</t>		transports.</t>
	</dd>		</dd>
	<dt>Fragment identifier considerations:</dt>		<dt>Fragment identifier considerations:</dt>
	<dd>		<dd>
	<t>n/a</t>		<t>n/a</t>
	</dd>		</dd>
	<dt>Person &amp; email address to contact for further information:</dt >		<dt>Person &amp; email address to contact for further information:</dt >
	<dd>		<dd>
	<t>RATS WG mailing list (rats@ietf.org)</t>		<t>RATS WG mailing list (rats@ietf.org)</t>
	skipping to change at line 601 ¶		skipping to change at line 654 ¶
	<t>IETF</t>		<t>IETF</t>
	</dd>		</dd>
	<dt>Provisional registration:</dt>		<dt>Provisional registration:</dt>
	<dd>		<dd>
	<t>no</t>		<t>no</t>
	</dd>		</dd>
	</dl>		</dl>
	</section>		</section>
	<section anchor="media-type-eat-jwt">		<section anchor="media-type-eat-jwt">
	<name>application/eat+jwt Registration</name>		<name>application/eat+jwt Registration</name>
	<dl spacing="compact">		<dl spacing="normal" newline="false">
	<dt>Type name:</dt>		<dt>Type name:</dt>
	<dd>		<dd>
	<t>application</t>		<t>application</t>
	</dd>		</dd>
	<dt>Subtype name:</dt>		<dt>Subtype name:</dt>
	<dd>		<dd>
	<t>eat+jwt</t>		<t>eat+jwt</t>
	</dd>		</dd>
	<dt>Required parameters:</dt>		<dt>Required parameters:</dt>
	<dd>		<dd>
	<t>n/a</t>		<t>n/a</t>
	</dd>		</dd>
	<dt>Optional parameters:</dt>		<dt>Optional parameters:</dt>
	<dd>		<dd>
	<t>"eat_profile" (EAT profile in string format. OIDs must use the		<t>"eat_profile" (EAT profile in string format. OIDs must use the
	dotted-decimal notation. The parameter value is case-insensitive.)</t>		dotted-decimal notation. The parameter value is case insensitive.)</t>
	</dd>		</dd>
	<dt>Encoding considerations:</dt>		<dt>Encoding considerations:</dt>
	<dd>		<dd>
	<t>8bit</t>		<t>8bit</t>
	</dd>		</dd>
	<dt>Security considerations:</dt>		<dt>Security considerations:</dt>
	<dd>		<dd>
	<t><xref section="9" sectionFormat="of" target="EAT"/> and <xref tar get="BCP225"/></t>		<t><xref section="9" sectionFormat="of" target="RFC9711"/> and <xref target="BCP225"/></t>
	</dd>		</dd>
	<dt>Interoperability considerations:</dt>		<dt>Interoperability considerations:</dt>
	<dd>		<dd>
	<t>n/a</t>		<t>n/a</t>
	</dd>		</dd>
	<dt>Published specification:</dt>		<dt>Published specification:</dt>
	<dd>		<dd>
	<t>RFCthis</t>		<t>RFC 9782</t>
	</dd>		</dd>
	<dt>Applications that use this media type</dt>		<dt>Applications that use this media type:</dt>
	<dd>		<dd>
	<t>Attesters, Verifiers, Endorsers and Reference-Value providers, Re lying		<t>Attesters, Verifiers, Endorsers and Reference-Value providers, an d Relying
	Parties that need to transfer EAT payloads over HTTP(S), CoAP(S), and other		Parties that need to transfer EAT payloads over HTTP(S), CoAP(S), and other
	transports.</t>		transports.</t>
	</dd>		</dd>
	<dt>Fragment identifier considerations:</dt>		<dt>Fragment identifier considerations:</dt>
	<dd>		<dd>
	<t>n/a</t>		<t>n/a</t>
	</dd>		</dd>
	<dt>Person &amp; email address to contact for further information:</dt >		<dt>Person &amp; email address to contact for further information:</dt >
	<dd>		<dd>
	<t>RATS WG mailing list (rats@ietf.org)</t>		<t>RATS WG mailing list (rats@ietf.org)</t>
	skipping to change at line 669 ¶		skipping to change at line 722 ¶
	<t>IETF</t>		<t>IETF</t>
	</dd>		</dd>
	<dt>Provisional registration:</dt>		<dt>Provisional registration:</dt>
	<dd>		<dd>
	<t>no</t>		<t>no</t>
	</dd>		</dd>
	</dl>		</dl>
	</section>		</section>
	<section anchor="media-type-deb-cbor">		<section anchor="media-type-deb-cbor">
	<name>application/eat-bun+cbor Registration</name>		<name>application/eat-bun+cbor Registration</name>
	<dl spacing="compact">		<dl spacing="normal" newline="false">
	<dt>Type name:</dt>		<dt>Type name:</dt>
	<dd>		<dd>
	<t>application</t>		<t>application</t>
	</dd>		</dd>
	<dt>Subtype name:</dt>		<dt>Subtype name:</dt>
	<dd>		<dd>
	<t>eat-bun+cbor</t>		<t>eat-bun+cbor</t>
	</dd>		</dd>
	<dt>Required parameters:</dt>		<dt>Required parameters:</dt>
	<dd>		<dd>
	<t>n/a</t>		<t>n/a</t>
	</dd>		</dd>
	<dt>Optional parameters:</dt>		<dt>Optional parameters:</dt>
	<dd>		<dd>
	<t>"eat_profile" (EAT profile in string format. OIDs must use the		<t>"eat_profile" (EAT profile in string format. OIDs must use the
	dotted-decimal notation. The parameter value is case-insensitive.)</t>		dotted-decimal notation. The parameter value is case insensitive.)</t>
	</dd>		</dd>
	<dt>Encoding considerations:</dt>		<dt>Encoding considerations:</dt>
	<dd>		<dd>
	<t>binary</t>		<t>binary</t>
	</dd>		</dd>
	<dt>Security considerations:</dt>		<dt>Security considerations:</dt>
	<dd>		<dd>
	<t><xref section="9" sectionFormat="of" target="EAT"/></t>		<t><xref section="9" sectionFormat="of" target="RFC9711"/></t>
	</dd>		</dd>
	<dt>Interoperability considerations:</dt>		<dt>Interoperability considerations:</dt>
	<dd>		<dd>
	<t>n/a</t>		<t>n/a</t>
	</dd>		</dd>
	<dt>Published specification:</dt>		<dt>Published specification:</dt>
	<dd>		<dd>
	<t>RFCthis</t>		<t>RFC 9782</t>
	</dd>		</dd>
	<dt>Applications that use this media type:</dt>		<dt>Applications that use this media type:</dt>
	<dd>		<dd>
	<t>Attesters, Verifiers, Endorsers and Reference-Value providers, Re lying		<t>Attesters, Verifiers, Endorsers and Reference-Value providers, an d Relying
	Parties that need to transfer EAT payloads over HTTP(S), CoAP(S), and other		Parties that need to transfer EAT payloads over HTTP(S), CoAP(S), and other
	transports.</t>		transports.</t>
	</dd>		</dd>
	<dt>Fragment identifier considerations:</dt>		<dt>Fragment identifier considerations:</dt>
	<dd>		<dd>
	<t>n/a</t>		<t>n/a</t>
	</dd>		</dd>
	<dt>Person &amp; email address to contact for further information:</dt >		<dt>Person &amp; email address to contact for further information:</dt >
	<dd>		<dd>
	<t>RATS WG mailing list (rats@ietf.org)</t>		<t>RATS WG mailing list (rats@ietf.org)</t>
	skipping to change at line 737 ¶		skipping to change at line 790 ¶
	<t>IETF</t>		<t>IETF</t>
	</dd>		</dd>
	<dt>Provisional registration:</dt>		<dt>Provisional registration:</dt>
	<dd>		<dd>
	<t>no</t>		<t>no</t>
	</dd>		</dd>
	</dl>		</dl>
	</section>		</section>
	<section anchor="media-type-deb-json">		<section anchor="media-type-deb-json">
	<name>application/eat-bun+json Registration</name>		<name>application/eat-bun+json Registration</name>
	<dl spacing="compact">		<dl spacing="normal" newline="false">
	<dt>Type name:</dt>		<dt>Type name:</dt>
	<dd>		<dd>
	<t>application</t>		<t>application</t>
	</dd>		</dd>
	<dt>Subtype name:</dt>		<dt>Subtype name:</dt>
	<dd>		<dd>
	<t>eat-bun+json</t>		<t>eat-bun+json</t>
	</dd>		</dd>
	<dt>Required parameters:</dt>		<dt>Required parameters:</dt>
	<dd>		<dd>
	<t>n/a</t>		<t>n/a</t>
	</dd>		</dd>
	<dt>Optional parameters:</dt>		<dt>Optional parameters:</dt>
	<dd>		<dd>
	<t>"eat_profile" (EAT profile in string format. OIDs must use the		<t>"eat_profile" (EAT profile in string format. OIDs must use the
	dotted-decimal notation. The parameter value is case-insensitive.)</t>		dotted-decimal notation. The parameter value is case insensitive.)</t>
	</dd>		</dd>
	<dt>Encoding considerations:</dt>		<dt>Encoding considerations:</dt>
	<dd>		<dd>
	<t>Same as <xref target="JSON"/></t>		<t>Same as <xref target="RFC8259"/></t>
	</dd>		</dd>
	<dt>Security considerations:</dt>		<dt>Security considerations:</dt>
	<dd>		<dd>
	<t><xref section="9" sectionFormat="of" target="EAT"/></t>		<t><xref section="9" sectionFormat="of" target="RFC9711"/></t>
	</dd>		</dd>
	<dt>Interoperability considerations:</dt>		<dt>Interoperability considerations:</dt>
	<dd>		<dd>
	<t>n/a</t>		<t>n/a</t>
	</dd>		</dd>
	<dt>Published specification:</dt>		<dt>Published specification:</dt>
	<dd>		<dd>
	<t>RFCthis</t>		<t>RFC 9782</t>
	</dd>		</dd>
	<dt>Applications that use this media type</dt>		<dt>Applications that use this media type:</dt>
	<dd>		<dd>
	<t>Attesters, Verifiers, Endorsers and Reference-Value providers, Re lying		<t>Attesters, Verifiers, Endorsers and Reference-Value providers, an d Relying
	Parties that need to transfer EAT payloads over HTTP(S), CoAP(S), and other		Parties that need to transfer EAT payloads over HTTP(S), CoAP(S), and other
	transports.</t>		transports.</t>
	</dd>		</dd>
	<dt>Fragment identifier considerations:</dt>		<dt>Fragment identifier considerations:</dt>
	<dd>		<dd>
	<t>n/a</t>		<t>n/a</t>
	</dd>		</dd>
	<dt>Person &amp; email address to contact for further information:</dt >		<dt>Person &amp; email address to contact for further information:</dt >
	<dd>		<dd>
	<t>RATS WG mailing list (rats@ietf.org)</t>		<t>RATS WG mailing list (rats@ietf.org)</t>
	skipping to change at line 805 ¶		skipping to change at line 858 ¶
	<t>IETF</t>		<t>IETF</t>
	</dd>		</dd>
	<dt>Provisional registration:</dt>		<dt>Provisional registration:</dt>
	<dd>		<dd>
	<t>no</t>		<t>no</t>
	</dd>		</dd>
	</dl>		</dl>
	</section>		</section>
	<section anchor="media-type-ucs-cbor">		<section anchor="media-type-ucs-cbor">
	<name>application/eat-ucs+cbor Registration</name>		<name>application/eat-ucs+cbor Registration</name>
	<dl spacing="compact">		<dl spacing="normal" newline="false">
	<dt>Type name:</dt>		<dt>Type name:</dt>
	<dd>		<dd>
	<t>application</t>		<t>application</t>
	</dd>		</dd>
	<dt>Subtype name:</dt>		<dt>Subtype name:</dt>
	<dd>		<dd>
	<t>eat-ucs+cbor</t>		<t>eat-ucs+cbor</t>
	</dd>		</dd>
	<dt>Required parameters:</dt>		<dt>Required parameters:</dt>
	<dd>		<dd>
	<t>n/a</t>		<t>n/a</t>
	</dd>		</dd>
	<dt>Optional parameters:</dt>		<dt>Optional parameters:</dt>
	<dd>		<dd>
	<t>"eat_profile" (EAT profile in string format. OIDs must use the		<t>"eat_profile" (EAT profile in string format. OIDs must use the
	dotted-decimal notation. The parameter value is case-insensitive.)</t>		dotted-decimal notation. The parameter value is case insensitive.)</t>
	</dd>		</dd>
	<dt>Encoding considerations:</dt>		<dt>Encoding considerations:</dt>
	<dd>		<dd>
	<t>binary</t>		<t>binary</t>
	</dd>		</dd>
	<dt>Security considerations:</dt>		<dt>Security considerations:</dt>
	<dd>		<dd>
	<t>Sections <xref target="UCCS" section="3" sectionFormat="bare"/> a nd <xref target="UCCS" section="7" sectionFormat="bare"/> of <xref target="UCCS" /></t>		<t>Sections <xref target="RFC9781" section="3" sectionFormat="bare"/ > and <xref target="RFC9781" section="7" sectionFormat="bare"/> of <xref target= "RFC9781"/></t>
	</dd>		</dd>
	<dt>Interoperability considerations:</dt>		<dt>Interoperability considerations:</dt>
	<dd>		<dd>
	<t>n/a</t>		<t>n/a</t>
	</dd>		</dd>
	<dt>Published specification:</dt>		<dt>Published specification:</dt>
	<dd>		<dd>
	<t>RFCthis</t>		<t>RFC 9782</t>
	</dd>		</dd>
	<dt>Applications that use this media type:</dt>		<dt>Applications that use this media type:</dt>
	<dd>		<dd>
	<t>Attesters, Verifiers, Endorsers and Reference-Value providers, Re lying		<t>Attesters, Verifiers, Endorsers and Reference-Value providers, an d Relying
	Parties that need to transfer EAT payloads over HTTP(S), CoAP(S), and other		Parties that need to transfer EAT payloads over HTTP(S), CoAP(S), and other
	transports.</t>		transports.</t>
	</dd>		</dd>
	<dt>Fragment identifier considerations:</dt>		<dt>Fragment identifier considerations:</dt>
	<dd>		<dd>
	<t>n/a</t>		<t>n/a</t>
	</dd>		</dd>
	<dt>Person &amp; email address to contact for further information:</dt >		<dt>Person &amp; email address to contact for further information:</dt >
	<dd>		<dd>
	<t>RATS WG mailing list (rats@ietf.org)</t>		<t>RATS WG mailing list (rats@ietf.org)</t>
	skipping to change at line 873 ¶		skipping to change at line 926 ¶
	<t>IETF</t>		<t>IETF</t>
	</dd>		</dd>
	<dt>Provisional registration:</dt>		<dt>Provisional registration:</dt>
	<dd>		<dd>
	<t>no</t>		<t>no</t>
	</dd>		</dd>
	</dl>		</dl>
	</section>		</section>
	<section anchor="media-type-ucs-json">		<section anchor="media-type-ucs-json">
	<name>application/eat-ucs+json Registration</name>		<name>application/eat-ucs+json Registration</name>
	<dl spacing="compact">		<dl spacing="normal" newline="false">
	<dt>Type name:</dt>		<dt>Type name:</dt>
	<dd>		<dd>
	<t>application</t>		<t>application</t>
	</dd>		</dd>
	<dt>Subtype name:</dt>		<dt>Subtype name:</dt>
	<dd>		<dd>
	<t>eat-ucs+json</t>		<t>eat-ucs+json</t>
	</dd>		</dd>
	<dt>Required parameters:</dt>		<dt>Required parameters:</dt>
	<dd>		<dd>
	<t>n/a</t>		<t>n/a</t>
	</dd>		</dd>
	<dt>Optional parameters:</dt>		<dt>Optional parameters:</dt>
	<dd>		<dd>
	<t>"eat_profile" (EAT profile in string format. OIDs must use the		<t>"eat_profile" (EAT profile in string format. OIDs must use the
	dotted-decimal notation. The parameter value is case-insensitive.)</t>		dotted-decimal notation. The parameter value is case insensitive.)</t>
	</dd>		</dd>
	<dt>Encoding considerations:</dt>		<dt>Encoding considerations:</dt>
	<dd>		<dd>
	<t>Same as <xref target="JSON"/></t>		<t>Same as <xref target="RFC8259"/></t>
	</dd>		</dd>
	<dt>Security considerations:</dt>		<dt>Security considerations:</dt>
	<dd>		<dd>
	<t>Sections <xref target="UCCS" section="3" sectionFormat="bare"/> a nd <xref target="UCCS" section="7" sectionFormat="bare"/> of <xref target="UCCS" /></t>		<t>Sections <xref target="RFC9781" section="3" sectionFormat="bare"/ > and <xref target="RFC9781" section="7" sectionFormat="bare"/> of <xref target= "RFC9781"/></t>
	</dd>		</dd>
	<dt>Interoperability considerations:</dt>		<dt>Interoperability considerations:</dt>
	<dd>		<dd>
	<t>n/a</t>		<t>n/a</t>
	</dd>		</dd>
	<dt>Published specification:</dt>		<dt>Published specification:</dt>
	<dd>		<dd>
	<t>RFCthis</t>		<t>RFC 9782</t>
	</dd>		</dd>
	<dt>Applications that use this media type</dt>		<dt>Applications that use this media type:</dt>
	<dd>		<dd>
	<t>Attesters, Verifiers, Endorsers and Reference-Value providers, Re lying		<t>Attesters, Verifiers, Endorsers and Reference-Value providers, an d Relying
	Parties that need to transfer EAT payloads over HTTP(S), CoAP(S), and other		Parties that need to transfer EAT payloads over HTTP(S), CoAP(S), and other
	transports.</t>		transports.</t>
	</dd>		</dd>
	<dt>Fragment identifier considerations:</dt>		<dt>Fragment identifier considerations:</dt>
	<dd>		<dd>
	<t>n/a</t>		<t>n/a</t>
	</dd>		</dd>
	<dt>Person &amp; email address to contact for further information:</dt >		<dt>Person &amp; email address to contact for further information:</dt >
	<dd>		<dd>
	<t>RATS WG mailing list (rats@ietf.org)</t>		<t>RATS WG mailing list (rats@ietf.org)</t>
	skipping to change at line 941 ¶		skipping to change at line 994 ¶
	<t>IETF</t>		<t>IETF</t>
	</dd>		</dd>
	<dt>Provisional registration:</dt>		<dt>Provisional registration:</dt>
	<dd>		<dd>
	<t>no</t>		<t>no</t>
	</dd>		</dd>
	</dl>		</dl>
	</section>		</section>
	<section anchor="coap-content-format-registrations">		<section anchor="coap-content-format-registrations">
	<name>CoAP Content-Format Registrations</name>		<name>CoAP Content-Format Registrations</name>
	<t>IANA is requested to register the following Content-Format numbers in		<t>IANA has registered the following Content-Format numbers in the "CoAP
	the "CoAP		Content-Formats" registry, within the "Constrained RESTful Environments
	Content-Formats" sub-registry, within the "Constrained RESTful Environments		(CoRE) Parameters" registry group <xref target="CORE-PARAMS"/>:</t>
	(CoRE) Parameters" Registry <xref target="IANA.core-parameters"/>:</t>		<table align="center">
	<table align="left">
	<name>New Content-Formats</name>		<name>New Content-Formats</name>
	<thead>		<thead>
	<tr>		<tr>
	<th align="left">Content-Type</th>		<th align="left">Content Type</th>
	<th align="left">Content Coding</th>		<th align="left">Content Coding</th>
	<th align="left">ID</th>		<th align="left">ID</th>
	<th align="left">Reference</th>		<th align="left">Reference</th>
	</tr>		</tr>
	</thead>		</thead>
	<tbody>		<tbody>
	<tr>		<tr>
	<td align="left">application/eat+cwt</td>		<td align="left">application/eat+cwt</td>
	<td align="left">-</td>		<td align="left">-</td>
	<td align="left">TBD1</td>		<td align="left">263</td>
	<td align="left">RFCthis</td>		<td align="left">RFC 9782</td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">application/eat+jwt</td>		<td align="left">application/eat+jwt</td>
	<td align="left">-</td>		<td align="left">-</td>
	<td align="left">TBD2</td>		<td align="left">264</td>
	<td align="left">RFCthis</td>		<td align="left">RFC 9782</td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">application/eat-bun+cbor</td>		<td align="left">application/eat-bun+cbor</td>
	<td align="left">-</td>		<td align="left">-</td>
	<td align="left">TBD3</td>		<td align="left">265</td>
	<td align="left">RFCthis</td>		<td align="left">RFC 9782</td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">application/eat-bun+json</td>		<td align="left">application/eat-bun+json</td>
	<td align="left">-</td>		<td align="left">-</td>
	<td align="left">TBD4</td>		<td align="left">266</td>
	<td align="left">RFCthis</td>		<td align="left">RFC 9782</td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">application/eat-ucs+cbor</td>		<td align="left">application/eat-ucs+cbor</td>
	<td align="left">-</td>		<td align="left">-</td>
	<td align="left">TBD5</td>		<td align="left">267</td>
	<td align="left">RFCthis</td>		<td align="left">RFC 9781</td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">application/eat-ucs+json</td>		<td align="left">application/eat-ucs+json</td>
	<td align="left">-</td>		<td align="left">-</td>
	<td align="left">TBD6</td>		<td align="left">268</td>
	<td align="left">RFCthis</td>		<td align="left">RFC 9782</td>
	</tr>		</tr>
	</tbody>		</tbody>
	</table>		</table>
	<t>TBD1..6 are to be assigned from the space 256..9999.</t>
	</section>
	</section>
	<section anchor="changelog">
	<name>Changelog</name>
	<t><cref anchor="remove-sec">RFC editor: please remove this section</cref>
	</t>
	<section anchor="cl-04">
	<name> -04</name>
	<ul spacing="normal">
	<li>
	<t>Early IANA review</t>
	</li>
	</ul>
	</section>
	<section anchor="cl-03">
	<name> -03</name>
	<ul spacing="normal">
	<li>
	<t>Update references</t>
	</li>
	</ul>
	</section>
	<section anchor="cl-02">
	<name> -02</name>
	<ul spacing="normal">
	<li>
	<t>Update references</t>
	</li>
	<li>
	<t>Register +cwt SSS
	(<eref target="https://github.com/ietf-rats-wg/draft-eat-mt/issues/14">Issue#14<
	/eref>)</t>
	</li>
	<li>
	<t>Move from eat-jwt to eat+jwt
	(<eref target="https://github.com/ietf-rats-wg/draft-eat-mt/issues/14">Issue#14<
	/eref>)</t>
	</li>
	<li>
	<t>Move from eat-cwt to eat+cwt
	(<eref target="https://github.com/ietf-rats-wg/draft-eat-mt/issues/14">Issue#14<
	/eref>)</t>
	</li>
	</ul>
	</section>
	<section anchor="cl-01">
	<name> -01</name>
	<ul spacing="normal">
	<li>
	<t>Rename <tt>profile</tt> to <tt>eat_profile</tt> for consistency w
	ith EAT
	(<eref target="https://github.com/ietf-rats-wg/draft-eat-mt/issues/4">Issue#4</e
	ref>)</t>
	</li>
	<li>
	<t>The DEB acronym is gone: shorthand is now "bun" from bundle
	(<eref target="https://github.com/ietf-rats-wg/draft-eat-mt/issues/8">Issue#8</e
	ref>)</t>
	</li>
	<li>
	<t>Incorporate editorial suggestions from Carl and Dave
	(<eref target="https://github.com/ietf-rats-wg/draft-eat-mt/issues/7">Issue#7</e
	ref>,
	<eref target="https://github.com/ietf-rats-wg/draft-eat-mt/issues/9">Issue#9</er
	ef>)</t>
	</li>
	</ul>
	</section>		</section>
	</section>		</section>
	</middle>		</middle>
	<back>		<back>
			<displayreference target="RFC9711" to="EAT"/>
			<!-- [UCCS] is 9781 (draft-ietf-rats-eat-media-type) -->
			<displayreference target="RFC9781" to="UCCS"/>
			<displayreference target="I-D.irtf-t2trg-rest-iot" to="REST-IoT"/>
			<displayreference target="RFC3986" to="URI"/>
			<displayreference target="RFC4151" to="TAG"/>
			<displayreference target="RFC6838" to="MEDIATYPES"/>
			<displayreference target="RFC7519" to="JWT"/>
			<displayreference target="RFC8259" to="JSON"/>
			<displayreference target="RFC8392" to="CWT"/>
			<displayreference target="RFC9110" to="HTTP"/>
			<displayreference target="RFC9334" to="RATS-ARCH"/>
			<displayreference target="BCP56" to="BUILD-W-HTTP"/>
	<references anchor="sec-combined-references">		<references anchor="sec-combined-references">
	<name>References</name>		<name>References</name>
	<references anchor="sec-normative-references">		<references anchor="sec-normative-references">
	<name>Normative References</name>		<name>Normative References</name>
	<reference anchor="EAT">
	<front>
	<title>The Entity Attestation Token (EAT)</title>
	<author fullname="Laurence Lundblade" initials="L." surname="Lundbla
	de">
	<organization>Security Theory LLC</organization>
	</author>
	<author fullname="Giridhar Mandyam" initials="G." surname="Mandyam">
	<organization>Mediatek USA</organization>
	</author>
	<author fullname="Jeremy O'Donoghue" initials="J." surname="O'Donogh
	ue">
	<organization>Qualcomm Technologies Inc.</organization>
	</author>
	<author fullname="Carl Wallace" initials="C." surname="Wallace">
	<organization>Red Hound Software, Inc.</organization>
	</author>
	<date day="6" month="September" year="2024"/>
	<abstract>
	<t> An Entity Attestation Token (EAT) provides an attested claim
	s set
	that describes state and characteristics of an entity, a device like
	a smartphone, IoT device, network equipment or such. This claims set
	is used by a relying party, server or service to determine the type
	and degree of trust placed in the entity.
	An EAT is either a CBOR Web Token (CWT) or JSON Web Token (JWT) with		<!-- Updated following REF entry to RFC9711 (AUTH48).
	attestation-oriented claims.		Note that the original cite tag for this reference is [EAT]. -->
	</t>		<reference anchor="RFC9711" target="https://www.rfc-editor.org/info/rfc9711">
	</abstract>		<front>
	</front>		<title>The Entity Attestation Token (EAT)</title>
	<seriesInfo name="Internet-Draft" value="draft-ietf-rats-eat-31"/>		<author fullname="Laurence Lundblade" initials="L." surname="Lundblade">
	</reference>		<organization>Security Theory LLC</organization>
	<reference anchor="JWT">		</author>
	<front>		<author fullname="Giridhar Mandyam" initials="G." surname="Mandyam">
	<title>JSON Web Token (JWT)</title>		<organization>Mediatek USA</organization>
	<author fullname="M. Jones" initials="M." surname="Jones"/>		</author>
	<author fullname="J. Bradley" initials="J." surname="Bradley"/>		<author fullname="Jeremy O'Donoghue" initials="J." surname="O'Donoghue">
	<author fullname="N. Sakimura" initials="N." surname="Sakimura"/>		</author>
	<date month="May" year="2015"/>		<author fullname="Carl Wallace" initials="C." surname="Wallace">
	<abstract>		<organization>Red Hound Software, Inc.</organization>
	<t>JSON Web Token (JWT) is a compact, URL-safe means of representi		</author>
	ng claims to be transferred between two parties. The claims in a JWT are encoded		<date month="April" year="2025"/>
	as a JSON object that is used as the payload of a JSON Web Signature (JWS) stru		</front>
	cture or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the		<seriesInfo name="RFC" value="9711"/>
	claims to be digitally signed or integrity protected with a Message Authenticat		<seriesInfo name="DOI" value="10.17487/RFC9711"/>
	ion Code (MAC) and/or encrypted.</t>		</reference>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="7519"/>
	<seriesInfo name="DOI" value="10.17487/RFC7519"/>
	</reference>
	<reference anchor="CWT">
	<front>
	<title>CBOR Web Token (CWT)</title>
	<author fullname="M. Jones" initials="M." surname="Jones"/>
	<author fullname="E. Wahlstroem" initials="E." surname="Wahlstroem"/
	>
	<author fullname="S. Erdtman" initials="S." surname="Erdtman"/>
	<author fullname="H. Tschofenig" initials="H." surname="Tschofenig"/
	>
	<date month="May" year="2018"/>
	<abstract>
	<t>CBOR Web Token (CWT) is a compact means of representing claims
	to be transferred between two parties. The claims in a CWT are encoded in the Co
	ncise Binary Object Representation (CBOR), and CBOR Object Signing and Encryptio
	n (COSE) is used for added application-layer security protection. A claim is a p
	iece of information asserted about a subject and is represented as a name/value
	pair consisting of a claim name and a claim value. CWT is derived from JSON Web
	Token (JWT) but uses CBOR rather than JSON.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="8392"/>
	<seriesInfo name="DOI" value="10.17487/RFC8392"/>
	</reference>
	<reference anchor="UCCS">
	<front>
	<title>A CBOR Tag for Unprotected CWT Claims Sets</title>
	<author fullname="Henk Birkholz" initials="H." surname="Birkholz">
	<organization>Fraunhofer SIT</organization>
	</author>
	<author fullname="Jeremy O'Donoghue" initials="J." surname="O'Donogh
	ue">
	<organization>Qualcomm Technologies Inc.</organization>
	</author>
	<author fullname="Nancy Cam-Winget" initials="N." surname="Cam-Winge
	t">
	<organization>Cisco Systems</organization>
	</author>
	<author fullname="Carsten Bormann" initials="C." surname="Bormann">
	<organization>Universität Bremen TZI</organization>
	</author>
	<date day="3" month="November" year="2024"/>
	<abstract>
	<t> This document defines the Unprotected CWT Claims Set (UCCS),
	a data
	format for representing a CBOR Web Token (CWT) Claims Set without
	protecting it by a signature, message authentication code (MAC), or
	encryption. UCCS enables the use of CWT claims in environments where
	protection is provided by other means, such as secure communication
	channels or trusted execution environments. This specification
	defines a CBOR tag for UCCS and describes the UCCS format, its
	encoding, and processing considerations, and discusses security
	implications of using unprotected claims sets.
	// (This editors' note will be removed by the RFC editor:) The		<!-- [rfced] We note that RFC 7519 is not cited anywhere in this
	// present revision (–12) contains remaining document changes based		document. Please let us know if there is an appropriate place in the text
	// on feedback from the IESG evaluation and has been submitted as		to reference this RFC. Otherwise, we will remove it from the Normative
	// input to IETF 121.		References section.
			-->
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.75
			19.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.83
			92.xml"/>
	</t>		<!-- [UCCS] [RFC9781] (draft-ietf-rats-uccs)
	</abstract>		Note that the original cite tag for this reference is [UCCS].
	</front>		-->
	<seriesInfo name="Internet-Draft" value="draft-ietf-rats-uccs-12"/>
	</reference>		<reference anchor="RFC9781" target="https://www.rfc-editor.org/info/rfc9781">
	<reference anchor="MediaTypes">		<front>
	<front>		<title>A Concise Binary Object Representation (CBOR) Tag for Unprotected CBO
	<title>Media Type Specifications and Registration Procedures</title>		R Web Token Claims Sets (UCCS)
	<author fullname="N. Freed" initials="N." surname="Freed"/>		</title>
	<author fullname="J. Klensin" initials="J." surname="Klensin"/>		<author fullname="Henk Birkholz" initials="H." surname="Birkholz">
	<author fullname="T. Hansen" initials="T." surname="Hansen"/>		<organization>Fraunhofer SIT</organization>
	<date month="January" year="2013"/>		</author>
	<abstract>		<author fullname="Jeremy O'Donoghue" initials="J." surname="O'Donoghue">
	<t>This document defines procedures for the specification and regi		<organization>Qualcomm Technologies Inc.</organization>
	stration of media types for use in HTTP, MIME, and other Internet protocols. Thi		</author>
	s memo documents an Internet Best Current Practice.</t>		<author fullname="Nancy Cam-Winget" initials="N." surname="Cam-Winget">
	</abstract>		<organization>Cisco Systems</organization>
	</front>		</author>
	<seriesInfo name="BCP" value="13"/>		<author fullname="Carsten Bormann" initials="C." surname="Bormann">
	<seriesInfo name="RFC" value="6838"/>		<organization>Universität Bremen TZI</organization>
	<seriesInfo name="DOI" value="10.17487/RFC6838"/>		</author>
	</reference>		<date month="April" year="2025"/>
	<reference anchor="URI">		</front>
	<front>		<seriesInfo name="RFC" value="9781"/>
	<title>Uniform Resource Identifier (URI): Generic Syntax</title>		<seriesInfo name="DOI" value="10.17487/RFC9781"/>
	<author fullname="T. Berners-Lee" initials="T." surname="Berners-Lee		</reference>
	"/>
	<author fullname="R. Fielding" initials="R." surname="Fielding"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.68
	<author fullname="L. Masinter" initials="L." surname="Masinter"/>		38.xml"/>
	<date month="January" year="2005"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.39
	<abstract>		86.xml"/>
	<t>A Uniform Resource Identifier (URI) is a compact sequence of ch		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.91
	aracters that identifies an abstract or physical resource. This specification de		10.xml"/>
	fines the generic URI syntax and a process for resolving URI references that mig		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.82
	ht be in relative form, along with guidelines and security considerations for th		59.xml"/>
	e use of URIs on the Internet. The URI syntax defines a grammar that is a supers
	et of all valid URIs, allowing an implementation to parse the common components		<reference anchor="STRUCT-SYNTAX" target="https://www.iana.org/assignmen
	of a URI reference without knowing the scheme-specific requirements of every pos		ts/media-type-structured-suffix">
	sible identifier. This specification does not define a generative grammar for UR
	Is; that task is performed by the individual specifications of each URI scheme.
	[STANDARDS-TRACK]</t>
	</abstract>
	</front>
	<seriesInfo name="STD" value="66"/>
	<seriesInfo name="RFC" value="3986"/>
	<seriesInfo name="DOI" value="10.17487/RFC3986"/>
	</reference>
	<reference anchor="HTTP">
	<front>
	<title>HTTP Semantics</title>
	<author fullname="R. Fielding" initials="R." role="editor" surname="
	Fielding"/>
	<author fullname="M. Nottingham" initials="M." role="editor" surname
	="Nottingham"/>
	<author fullname="J. Reschke" initials="J." role="editor" surname="R
	eschke"/>
	<date month="June" year="2022"/>
	<abstract>
	<t>The Hypertext Transfer Protocol (HTTP) is a stateless applicati
	on-level protocol for distributed, collaborative, hypertext information systems.
	This document describes the overall architecture of HTTP, establishes common te
	rminology, and defines aspects of the protocol that are shared by all versions.
	In this definition are core protocol elements, extensibility mechanisms, and the
	"http" and "https" Uniform Resource Identifier (URI) schemes.</t>
	<t>This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7
	232, 7233, 7235, 7538, 7615, 7694, and portions of 7230.</t>
	</abstract>
	</front>
	<seriesInfo name="STD" value="97"/>
	<seriesInfo name="RFC" value="9110"/>
	<seriesInfo name="DOI" value="10.17487/RFC9110"/>
	</reference>
	<reference anchor="JSON">
	<front>
	<title>The JavaScript Object Notation (JSON) Data Interchange Format
	</title>
	<author fullname="T. Bray" initials="T." role="editor" surname="Bray
	"/>
	<date month="December" year="2017"/>
	<abstract>
	<t>JavaScript Object Notation (JSON) is a lightweight, text-based,
	language-independent data interchange format. It was derived from the ECMAScrip
	t Programming Language Standard. JSON defines a small set of formatting rules fo
	r the portable representation of structured data.</t>
	<t>This document removes inconsistencies with other specifications
	of JSON, repairs specification errors, and offers experience-based interoperabi
	lity guidance.</t>
	</abstract>
	</front>
	<seriesInfo name="STD" value="90"/>
	<seriesInfo name="RFC" value="8259"/>
	<seriesInfo name="DOI" value="10.17487/RFC8259"/>
	</reference>
	<reference anchor="IANA.media-type-structured-suffix" target="https://ww
	w.iana.org/assignments/media-type-structured-suffix">
	<front>		<front>
	<title>Structured Syntax Suffixes</title>		<title>Structured Syntax Suffixes</title>
	<author>		<author>
	<organization>IANA</organization>		<organization>IANA</organization>
	</author>		</author>
	</front>		</front>
	</reference>		</reference>
	<reference anchor="IANA.media-types" target="https://www.iana.org/assign
	ments/media-types">		<reference anchor="MEDIA-TYPES" target="https://www.iana.org/assignments
			/media-types">
	<front>		<front>
	<title>Media Types</title>		<title>Media Types</title>
	<author>		<author>
	<organization>IANA</organization>		<organization>IANA</organization>
	</author>		</author>
	</front>		</front>
	</reference>		</reference>
	<referencegroup anchor="BCP225" target="https://www.rfc-editor.org/info/
	bcp225">		<xi:include href="https://bib.ietf.org/public/rfc/bibxml9/reference.BCP.0
	<reference anchor="RFC8725" target="https://www.rfc-editor.org/info/rf		225.xml"/>
	c8725">
	<front>		<reference anchor="CORE-PARAMS" target="https://www.iana.org/assignments
	<title>JSON Web Token Best Current Practices</title>		/core-parameters">
	<author fullname="Y. Sheffer" initials="Y." surname="Sheffer"/>
	<author fullname="D. Hardt" initials="D." surname="Hardt"/>
	<author fullname="M. Jones" initials="M." surname="Jones"/>
	<date month="February" year="2020"/>
	<abstract>
	<t>JSON Web Tokens, also known as JWTs, are URL-safe JSON-based
	security tokens that contain a set of claims that can be signed and/or encrypted
	. JWTs are being widely used and deployed as a simple security token format in n
	umerous protocols and applications, both in the area of digital identity and in
	other application areas. This Best Current Practices document updates RFC 7519 t
	o provide actionable guidance leading to secure implementation and deployment of
	JWTs.</t>
	</abstract>
	</front>
	<seriesInfo name="BCP" value="225"/>
	<seriesInfo name="RFC" value="8725"/>
	<seriesInfo name="DOI" value="10.17487/RFC8725"/>
	</reference>
	</referencegroup>
	<reference anchor="IANA.core-parameters" target="https://www.iana.org/as
	signments/core-parameters">
	<front>		<front>
	<title>Constrained RESTful Environments (CoRE) Parameters</title>		<title>CoAP Content-Formats</title>
	<author>		<author>
	<organization>IANA</organization>		<organization>IANA</organization>
	</author>		</author>
	</front>		</front>
	</reference>		</reference>
	</references>		</references>
	<references anchor="sec-informative-references">		<references anchor="sec-informative-references">
	<name>Informative References</name>		<name>Informative References</name>
	<reference anchor="RATS-Arch">
	<front>
	<title>Remote ATtestation procedureS (RATS) Architecture</title>
	<author fullname="H. Birkholz" initials="H." surname="Birkholz"/>
	<author fullname="D. Thaler" initials="D." surname="Thaler"/>
	<author fullname="M. Richardson" initials="M." surname="Richardson"/
	>
	<author fullname="N. Smith" initials="N." surname="Smith"/>
	<author fullname="W. Pan" initials="W." surname="Pan"/>
	<date month="January" year="2023"/>
	<abstract>
	<t>In network protocol exchanges, it is often useful for one end o
	f a communication to know whether the other end is in an intended operating stat
	e. This document provides an architectural overview of the entities involved tha
	t make such tests possible through the process of generating, conveying, and eva
	luating evidentiary Claims. It provides a model that is neutral toward processor
	architectures, the content of Claims, and protocols.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="9334"/>
	<seriesInfo name="DOI" value="10.17487/RFC9334"/>
	</reference>
	<referencegroup anchor="BUILD-W-HTTP" target="https://www.rfc-editor.org
	/info/bcp56">
	<reference anchor="RFC9205" target="https://www.rfc-editor.org/info/rf
	c9205">
	<front>
	<title>Building Protocols with HTTP</title>
	<author fullname="M. Nottingham" initials="M." surname="Nottingham
	"/>
	<date month="June" year="2022"/>
	<abstract>
	<t>Applications often use HTTP as a substrate to create HTTP-bas
	ed APIs. This document specifies best practices for writing specifications that
	use HTTP to define new application protocols. It is written primarily to guide I
	ETF efforts to define application protocols using HTTP for deployment on the Int
	ernet but might be applicable in other situations.</t>
	<t>This document obsoletes RFC 3205.</t>
	</abstract>
	</front>
	<seriesInfo name="BCP" value="56"/>
	<seriesInfo name="RFC" value="9205"/>
	<seriesInfo name="DOI" value="10.17487/RFC9205"/>
	</reference>
	</referencegroup>
	<reference anchor="REST-IoT">
	<front>
	<title>Guidance on RESTful Design for Internet of Things Systems</ti
	tle>
	<author fullname="Ari Keränen" initials="A." surname="Keränen">
	<organization>Ericsson</organization>
	</author>
	<author fullname="Matthias Kovatsch" initials="M." surname="Kovatsch
	">
	<organization>Siemens</organization>
	</author>
	<author fullname="Klaus Hartke" initials="K." surname="Hartke">
	</author>
	<date day="21" month="October" year="2024"/>
	<abstract>
	<t> This document gives guidance for designing Internet of Thing
	s (IoT)
	systems that follow the principles of the Representational State
	Transfer (REST) architectural style. This document is a product of
	the IRTF Thing-to-Thing Research Group (T2TRG).
	</t>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.93
	</abstract>		34.xml"/>
	</front>
	<seriesInfo name="Internet-Draft" value="draft-irtf-t2trg-rest-iot-15"		<xi:include href="https://bib.ietf.org/public/rfc/bibxml9/reference.BCP.0
	/>		56.xml"/>
	</reference>
	<reference anchor="TAG">		<!-- [REST-IoT] draft-irtf-t2trg-rest-iot-15: I-D Exists as of 1/8/25 -->
	<front>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.i
	<title>The 'tag' URI Scheme</title>		rtf-t2trg-rest-iot.xml"/>
	<author fullname="T. Kindberg" initials="T." surname="Kindberg"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.41
	<author fullname="S. Hawke" initials="S." surname="Hawke"/>		51.xml"/>
	<date month="October" year="2005"/>
	<abstract>
	<t>This document describes the "tag" Uniform Resource Identifier (
	URI) scheme. Tag URIs (also known as "tags") are designed to be unique across sp
	ace and time while being tractable to humans. They are distinct from most other
	URIs in that they have no authoritative resolution mechanism. A tag may be used
	purely as an entity identifier. Furthermore, using tags has some advantages over
	the common practice of using "http" URIs as identifiers for non-HTTP-accessible
	resources. This memo provides information for the Internet community.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="4151"/>
	<seriesInfo name="DOI" value="10.17487/RFC4151"/>
	</reference>
	</references>		</references>
	</references>		</references>
	<?line 646?>
	<section numbered="false" anchor="acknowledgments">		<section numbered="false" anchor="acknowledgments">
	<name>Acknowledgments</name>		<name>Acknowledgments</name>
	<t>Thank you		<t>Thank you <contact fullname="Carl Wallace"/>, <contact
	Carl Wallace,		fullname="Carsten Bormann"/>, <contact fullname="Dave Thaler"/>,
	Carsten Bormann,		<contact fullname="Deb Cooley"/>, <contact fullname="Éric Vyncke"/>,
	Dave Thaler,		<contact fullname="Francesca Palombini"/>, <contact fullname="Jouni
	Deb Cooley,		Korhonen"/>, <contact fullname="Kathleen Moriarty"/>, <contact
	Éric Vyncke,		fullname="Michael Richardson"/>, <contact fullname="Murray Kucherawy"/>,
	Francesca Palombini,		<contact fullname="Orie Steele"/>, <contact fullname="Paul Howard"/>,
	Jouni Korhonen,		<contact fullname="Roman Danyliw"/>, and <contact fullname="Tim
	Kathleen Moriarty,		Hollebeek"/> for your comments and suggestions.</t>
	Michael Richardson,
	Murray Kucherawy,
	Orie Steele,
	Paul Howard,
	Roman Danyliw
	and
	Tim Hollebeek
	for your comments and suggestions.</t>
	</section>		</section>
	</back>		</back>
	<!-- ##markdown-source:		<!-- [rfced] We have the following queries regarding abbreviations and expansion
	H4sIAAAAAAAAA+1c63IbN5b+j6fA0FUjKWJTluSbuJupyLrEcmRLJdLxj0wy		s.
	ArtBsq1mgwN0S+ZIyv99i32WmRfb7wDoG0VdbGd2NykrVZGaDRwcnOt3DkAH
	QcDOu3yTsSzOEtnle9t9/kZGseD92VQaJgYDLc9vfh6pMBUTTIi0GGZBLLNh		a) FYI - We have added expansions for abbreviations upon first use per Section
	oEVmAimyYEIDgwwDg/UNZvLBJDYmVilN7fKDvf4+C0UmR0rPutxkEWPxVHd5		3.6 of RFC 7322 ("RFC Style Guide"). Please review each expansion in the
	pnOTbTx+vPV4gwktRZe3ejLMdZzNWuxC6bORVvkUn57Iicok3+5n0mQiA2V+		document carefully to ensure correctness.
	rFUoo1zLXoudyRlGR5bpNrfMcGKGMYxOo7+JRKXgY4ZtTOMu/ylTYZsbpTMt
	hwZ/zSb0x8+MiTwbK91lPOBxarr8sMMP8zQaJCKSjHPuJHAosGwayuY7pUci		b) FYI - When the abbreviation "EAT" is used in plural form, we have updated
	jf9huevyYh+8P5bYNT883KFBciLipMuTUfKd8SMyO6ATqkm57KsOfxnrs7FK		to use "EATs". We note this expansion in particular since there are multiple
	/lGt+kqmZ42PsWCX72uRp2M1lJofpAY6zSGnodKOAYkP8TBxIuvLcJyqRI1m		occurences that have been updated. Please let us know any objections.
	NL1QdI1C76BfY3KMBTsDv+B3pHAwmWYizGiQgfBk1uUnYwmeMy2Mkfz5U3oV		-->
	qgj8Lj17srH1dMl+gG12+a7QE+gjytyYPM3IGr6XYC+dlXvvd/i+MgYcV1vv
	j9VEmPrnTWEfxqnQqsZ6Zid0hm7Cd4l938EkxlInjnMJLZO9wDyD3U7DnPHi		<!-- [rfced] Please review the "Inclusive Language" portion of the online
	9Xu8ONnfef50fQuPO/7xxebWBh7f7ez05uflYWjwyrqM9Rg74dmLzRc04eTA		Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
	Pm5uvXiGx1f9/rF93lpff0yr9Y7eOvobT7fgG4XOHJMn2/1esK3DsZuyufkE		and let us know if any changes are needed. Updates of this nature typically
	H758d3C4G7wPHKmXO8dPifDJXq8fHKhiUxrMZRuZHgUafhPEirbW3/7eEnqy		result in more precise language, which is helpful for readers.
	/nSdMZlmpBx83ts73CdX29/JxrFpMRYEAYyEVAuNs2MxS5SIDM+NjKAqXvhk
	tsAnDZ+IGdfy73kMGxQph3WoMEYIiJx7MnJPa6cw/1jDHNJzORNwqrb9VH4U		Note that our script did not flag any words in particular, but this should
	k2ki+QWMsFoRuxvmCd8+PjAdxvpgE9QmikdyGKe0aOn5hmeKD6SbSgT37D4b		still be reviewed as a best practice.
	3PbVmUwNX4YRrHTcdidxFCUIG4/gN5lWUR7SyE/e/OVlqbPr6zlRsHlR8C8Q
	BSNR8OXLy2E8CsQ0Dkx0fU2b+fXXX7kQ5nzEOkHzp8OLn86iD+dfsCvsNZnF
	6YgfCw0JXpXDrvz2ETiuGvOv+I9Sx8OYXrClYLWx/lI5bIkeV+c+LF+4lxQ+
	msTnfq748VGvz9fOacXZ/Mv7Z0P5y3vncUTxfOUTZzc31vz5ywPWXvSDbMiP
	fngI5zZ6Ldct8ESaPMnMygNm/+cdrK8unO3ETAnyHtLsPubunX0nc/evvfF4
	ne8ATZCHzQ+4b/bdKn3Ivm8f8O+cDX9nl13+qIoDHN5KECoQSTxKv22FiPRS
	tyhJWuT3bWvHBhrybIpWFHdCOc1ykSAuIW+OEMh8pLERF7GHxkKvrevfKPi6
	2MsuL/ELgXJaRNk4jeRU4n9plsy4GlJkdEzuVEy+cUwSjxfjOBzToBkDloiH
	WIWeJkYm59IguAGEcTX4IEPKqTy2DI7oz6lWAIMqadMWEZ0htuk0iUPLJIuk
	geykNlzwNJ8MENDADEwrisGXOAfWEINE2nla5sY+1OWAzSObA/gCInjhBQNh
	bOivROzi/jBRF2ZhyKeZlOchqHrah8QwdkdtH1PC8Zn/+hrR/9EjuJtNOBOI
	0ACwpqMcq3m1Acrn9IIUZKxsYRkTY7fhrcB4tdpk00hnRN4WB64sYC73UBFg
	twym4iTJCTVknriJP9oJF5QAHbJxa43VhVUaZJdgNJTCpIAiFT7U0FphF4WF
	DVWuvTVM+DIwWZtwmiW1K4FLx2CXFnoJWJ6QYbAYKxG4smN2Xh6dQMriHGTM
	SpusJoGhXF4SnKstQ492wrvXO71GLp1zu45Pkc0PVu28u6JYNcN5tct3S/yO
	n6u5KQ/4uTHFs/ugKas+2FpZ3LqVzs1V7t3L1afvZcGUTnD3Zq4W7MUaS7mZ
	G1NvruJxyFK55OrcvHv2coU0NJsi1NTWvG8vS26VpRqRhXvZqe9lTtxX9+6l
	8UPrr9r/FtjmHT/YXiLiiQl6MiPGbky9XUlLgdvmasHTzR2+fPc2eH2btq74
	LxV/55+mNiudBn9369BHk5qs/fwrvhuPKNV8okZp2Hnj1cLN79SX/KWc2ynE
	5qg/QM91xE6tGRU5ykv3q7p6UWLyatb5/bPo55f5EuSmPcyVD6g53lJdEQUO
	JdwEZY1PlthS8+0Sm4/UZUnTaTy556YZHMoRkIfo2tKCSjpjLH9X/D3lr/1J
	5h93dncPa+KfF9RSQ2qNx6UGXCtT5/2IrUy7hMAe8e1ag46qMzGRVIxZxIWR
	4H4YJ5Sj6SmmnMsVYJXNbcNEfowJrriETBhJ8XgCPEQAiRbGUC0GcQLk1kaS
	7ElbC/NnDBm4mZcpyXvcwN1LwlV2bdAt2MD2PCRERMRwgghI0TR5WvBOtERG
	s1F6W9zlIIkBXsETiAtupjJEcRnW1+GptHQZfBUDqelHwEVpPNFy1YYyCZb2
	K4zVtdx7cEfTbDWuhiy0sa3tsaVBeQm1GAdenczaDt3k06nSVGsQVhQZNd0M
	oAgAXpvLLOzYUsiwUGg9IxXEKSAgFipYp9ozc9Wyg3pE9RRW8Tc/4pRbXviy
	kZJVinjS2exs8EIZKx7lnosklwVkXkQFdiBjAljUizg62CUMKahBZTsqTfha
	w4BZAzjGaZjkkXQWRdwAjzcWY6VKnUZDjBxU6p/EWruGx0IePfswkNQ44ZIJ
	kyQ/TlUpo7r+hQX8FsQnYkabSwhO2w+0yp1poVaJzVRk4ZiVpUYEpw6pysBb
	a4qOYFBa2dTFAHB7AbGBFB+Lc8uC4iZVakoA382lJg/lg4GKYl92kNBsEQGG
	jCJi1GugeoIkq4MR+QBkAoNgJhSunLAmaGaIgBMnvQnx7B0tTqE70oH8mMnU
	xM5DvR04I2DyI7j3hdZAOnmBjODwqQwLNkWXZ4qajVidiq0BDSAGa210eBGK
	JQQNrSaWCaph+LLsjDptflqrmNagzNXwIls55YMZn6ppnrjCB5NYU9OVgZBc
	fQzRWkLhaURTvG2+OzmEZb6nSqgRKmIypXPolTbpDYa2VeupxVW/juolvkzl
	mPf7drUsFcIQZRZQHG3ZINDaDimatfgYtZ601YKNDaWD2WjKxMCohBrucB/q
	wtVck1jCp3BMFyZOS8YDS+GUxm9PqcpFebRNEcfVdCtVVXb691xRFkSkhEBO
	uUxDRaJBXIHku4z95abwP1xk/8Frgv62lYlRV/oOV6fY/cbjjY3WKWN0ZoAt
	tl2pOe9VLmdAEX4PGaXjig++HHdkp104BrPsmpW6s9/FajjP6kZna2urs37q
	SkzHqXFRqaiIbTVKWdM2tOFwC+rN3LYFfCKar8bLmEL8i1pDohARF4ZfyCSh
	36kcqSwuLZgLaxWiSpvMG16dkLaNLl83jrNsGvhaH5t6e9Tf6/Klvy7xBG7P
	LzRkQsSRmaglz18839pgzLXawjEcUqYjGTinMHLtfH0NtkEWv7a+sfnk6bPn
	L7YeW9teW++ss1fKZF1+7nuvha6Zs+Uuv1f+1lSEfmLiup2st1jdQW6h89c5
	IPRAE2TsJ1uXB9amfP1+sfbQ6fznBpQqjKLES95qbA/L9aQd3zYvLPt4veL6
	WbcamZn+ZkbmbMN8iXEU2vad4t9EN4t0/lDFLJi7UCtm+mCtOGu3ajlAJFGI
	0yESDvAUhCxGNtpeXva3vye9OPQ0K1y0FroIccWUW22sRk6EZOKsyiA2zJTn
	tJCjATFtOTH88pGRISFPMPGmpl6VIkn6NA60krtmp1+ZgIJVeaWFjkVl9abi
	BHbE/XGFTcsOOoTSpthIZKKR710ud41UCzq1HAmNitQQHrbwWUQgl8WmcaLk
	MpbJ1JQPc20BX41DArEiTgBWO3wffzhAwyJgGgLneRLRwgpZ3hm7g9HFkTVH
	9j2jg/Mc0BjinQIeQOhwCGlBjN2nhe5aGRMUTVZyBRGeGY80S2phXfTkU0Xj
	j0iU7TmS4Yx8c5gnSceaBlQJ3AKModv1Xul8pgny0Kx+MAqpiygufB0OlD71
	qqCUz83YSkEj8MiLWv3jMrtlqSgO7Km4A02RxF8J6TE2YW5DNRcDQo0W4IwF
	HaYSeAHfvp5p+ZP6nbFIU5m0bP1WHQLSICvnomNszfZg++32nMnCY3/JVDCg
	fDFBFRf9fPMTe/DL96I4U7rL4YSE47ScJgILXV7+mc6AIWoPjeBDNLxWHDk6
	7lWKZO96zacUZk55L9N5SPVPxHszSOQj7+XDYfwRqiJuMcUHXFcDwI5j4woE
	WZAwFQnjSBhLwnfJWeu2NVASe4Iosi4v/0Qrdmq3UirCgaNIocMVnxMSuyaY
	Hup4UHS8q3P8mp6bRUwM6BbavrX3YtbEnkXkpPhD/TorLOrMezZ95KYeejdU
	kyks45q9pQsPrOua1e/loDgowfwVxlYd8zSABMbYiRxKexfF0GeXlxh2jYi1
	VyC0ponQmAHdhZiR+zRr/AVD365tM7avxcjWfAdVnXpzqPVnpxAbdiSkWpj4
	sKBQVbqmqOL9ARFthvdeHb073IWEka7E/IiG05KtoNRZ3kY0zwfFx64KqJWp
	FrVqImfN9SYjfp5nvKh2Fy8H6d+SK2j/PSlrMeIFseJVseOuzNAge4L1/ns+
	8QE3gR0g34nMuNs1So9QLWB1ujBVZaZtRCQU/0KMqmGMbdurSmsUNRB3aRWt
	gBe1Xeiu61J8mfhY4e+VPiMuvqc7VtT8Ih3alceQfujoho4uh9drJ1zvZS65
	Wfev3RJD2qyc7voWxxeRq6SGimp0YmHu6NB6eo3qna5t7JHUFSfH4Ve8L4Et
	yCnp3oL3DdtRJPxCTfOrRRgJn5bRj5pdtchBCQIjEC8KKq8XUvlwL5UPJZVF
	p1XW4W+QDQZ5anPTHbQjOQhoyB3E7RnYYuKUF+8hTkNq+3dnQjeIFVn0DmIY
	UufUEnt9K7F7OCNiJWeENVN5UbuIyH0XNZFD1PEeer5FKq8b1rU14EUGcVIz
	84ZVlwbRCNu2BZv62F1He6yXD7L6S78AhW57QhvVup/0Pl0TjB0VTbXmu1YN
	fbfs4XmFd1Pu2gRVQxd1u+EWbeYOx8HHI5VRRyFCaJ2APHK4R6nW+6ueTNnl
	IOAdANtQq4kOzykOltklvDW79BZiO5+kijC5VXYvF6SjmxOtZI4p3hsy76JD
	5+4AWsLeUBAcKw34lrITQVy/pkBzihtMALPFnSX8uZdGSpui/1zGkeBHKxWP
	/mmgvxoFwdLlqFj6xXw32jUw6WKl1VTRcrSxlMq45R7CPZ3f2z9oKXvyDWpl
	AUlob/9m/rxVOuAKgv2zuwdJkVZTneAa7pSGbHIr6oG4uhv60PTkFJUSrLEV
	sIUqR2/eHL0lgyYLDJ3QVVoNSFUq5xNW2EhY9oYwOybBGmf49TTjaCx01Q/3
	uuqHL3PVD39YV30xiLNPdlRfkv3p5c7xxsbT/yPH/eq3v3e/rWDN7c5bwprP
	995ymT+oC3/Ntl+99n/bay0qv9trLSr/Qq8lGn9Qr+1RpSroWwJUlpED/R78
	96v7/u7dt6zQb3ffskL/AvctlvmDuu+nJF3DN62pPq8ODb4m36/e+9nee0/y
	LVtiX+i9X5Pv/1M//urGvzs3tt/PKS5p7FvuGx5sHnI8Wh2VzFFyZ7PFt4jo
	Ktv2MWuOMS269R0URyjuulY13t/DxaLF12v30vNYq9R+dYgt76iTvZXqdjGo
	ncwfxoRKy6AKBNfXXTqQqV9M4eUjflvPvOIHuzfOaBafzAR0rPNyd71+FrBw
	+If68I37htePVvyczQfN8ecSfs6Te+fUDkb8nKcPmtNc59ncnMvurScc8/qn
	602QX6fzzN7Bdl/OE8Z+t612qdNM6RbAxtNnHbqHt2XvGTjbT9SI7hK40//A
	yPDnuUd3r0DO3yuoLgsY6b9J/ejRP/87ePwEeStM8BusfcP3hE5m7kqDu25R
	DNv0wzbtsHfTiA72dHnkXQzb8MM2bhn2jTdZWRw093qIWMs/HRiTy0frT35e
	pptYpru2NoJr5AP6txjWqm/2X4zW3L95Yf+li2wtpmlmbf3JygpIv6E9Whn6
	bjPJt+gc/5tWCatVwt9uFS/NdS/NdSvNE0nggJ+W93axbvMir7+uYkjAaThz
	l0eQPmpsfSZXlqlvbOLf3XvJRYioNLM32Ef23/MwiM7IXnTXn873L3gL7tly
	YhrYg88aDy8+j4cXjocDIAqN9EaW5cw8Rsg3+Yi+AGTTh111B5bsvo8ozuuL
	P/+8xZ+vtEHE09j6PBpbtIEgCPhAhGf2WyPhGWSVyGjkIvxlN09dGpGRvQgp
	0jM+Uzmzm3kvEroc1KYnUjB/SUElTduMtgjdCCREPMgBwo5K5KzN/vVfyKn8
	x1kanmEesAA5YSiQQxI1QfUUt9lrlacx/0HpMRQJWj+IbJxIUH9DgtUZqLyJ
	w7GQCT+h3zpCLMRnudZixn/IQ4ABcYFRRzqWvJdJmWCpY4Hs9UpdYHibnSiw
	CT2ksyS+oMtorB9P8BYJfCDlGSOzndEXSiFF9y1Ze3Gl0ijiH/sf4IUahS5H
	AAA=
	-->		-->
	</rfc>		</rfc>
End of changes. 96 change blocks.
	680 lines changed or deleted		344 lines changed or added
This html diff was produced by rfcdiff 1.48.