<?xml version='1.0'encoding='utf-8'?>encoding='UTF-8'?> <!DOCTYPE rfc [ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]><?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.20 (Ruby 3.3.3) --><rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-rats-eat-media-type-12" number="9782" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true"version="3">version="3" xml:lang="en" updates="" obsoletes=""> <!--xml2rfc v2v3 conversion 3.24.0[rfced] We have updated the title of the document to expand "EAT" per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review. Original: EAT Media Types Current: Entity Attestation Token (EAT) Media Types --> <front> <title abbrev="EAT MediaTypes">EATTypes">Entity Attestation Token (EAT) Media Types</title> <seriesInfoname="Internet-Draft" value="draft-ietf-rats-eat-media-type-12"/>name="RFC" value="9782"/> <author initials="L." surname="Lundblade" fullname="Laurence Lundblade"> <organization>Security Theory LLC</organization> <address> <email>lgl@securitytheory.com</email> </address> </author> <author initials="H." surname="Birkholz" fullname="Henk Birkholz"> <organization abbrev="Fraunhofer SIT">Fraunhofer Institute for Secure Information Technology</organization> <address> <postal> <street>Rheinstrasse 75</street> <city>Darmstadt</city> <code>64295</code> <country>Germany</country> </postal> <email>henk.birkholz@ietf.contact</email> </address> </author> <author initials="T." surname="Fossati" fullname="Thomas Fossati"> <organization>Linaro</organization> <address> <email>thomas.fossati@linaro.org</email> </address> </author> <dateyear="2024" month="November" day="03"/> <area>Security</area> <workgroup>Remote ATtestation ProcedureS</workgroup> <keyword>EAT, mediayear="2025" month="April"/> <area>SEC</area> <workgroup>rats</workgroup> <keyword>EAT</keyword> <keyword>media type</keyword> <abstract><?line 56?> <t>Payloads<!-- [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? Original: Payloads used in Remote Attestation Procedures may require an associated media type for their conveyance, for example when used in RESTful APIs. 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(EAT).</t>(EATs).</t> </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> <middle><?line 63?><section anchor="introduction"> <name>Introduction</name> <t>Payloads used in RemoteAttestation ProceduresATtestation procedureS (RATS) <xreftarget="RATS-Arch"/>target="RFC9334"/> may require an associated media type for their conveyance, forexampleexample, when used in RESTful APIs (<xref target="fig-api-sd"/>).</t> <figure anchor="fig-api-sd"> <name>Conveying RATSconceptual messagesConceptual Messages in REST APIsusing EAT</name>Using EATs</name> <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"> <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 136,32 L 136,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 304,32 L 304,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 504,32 L 504,64" fill="none" stroke="black"/> <path d="M 8,32 L 136,32" fill="none" stroke="black"/> <path d="M 216,32 L 304,32" fill="none" stroke="black"/> <path d="M 416,32 L 504,32" fill="none" stroke="black"/> <path d="M 8,64 L 136,64" fill="none" stroke="black"/> <path d="M 216,64 L 304,64" fill="none" stroke="black"/> <path d="M 416,64 L 504,64" fill="none" stroke="black"/> <path d="M 256,112 L 480,112" fill="none" stroke="black"/> <path d="M 264,160 L 488,160" fill="none" stroke="black"/> <path d="M 32,208 L 256,208" fill="none" stroke="black"/> <path d="M 24,240 L 248,240" fill="none" stroke="black"/> <polygon class="arrowhead" points="488,112 476,106.4 476,117.6" fill="black" transform="rotate(0,480,112)"/> <polygon class="arrowhead" points="272,160 260,154.4 260,165.6" fill="black" transform="rotate(180,264,160)"/> <polygon class="arrowhead" points="256,240 244,234.4 244,245.6" fill="black" transform="rotate(0,248,240)"/> <polygon class="arrowhead" points="40,208 28,202.4 28,213.6" fill="black" transform="rotate(180,32,208)"/> <g class="text"> <text x="48" y="52">Relying</text> <text x="104" y="52">Party</text> <text x="260" y="52">Attester</text> <text x="460" y="52">Verifier</text> <text x="284" y="84">POST</text> <text x="336" y="84">/verify</text> <text x="320" y="100">EAT(Evidence)</text> <text x="440" y="132">200</text> <text x="468" y="132">OK</text> <text x="344" y="148">EAT(Attestation</text> <text x="444" y="148">Results)</text> <text x="180" y="180">POST</text> <text x="224" y="180">/auth</text> <text x="112" y="196">EAT(Attestation</text> <text x="212" y="196">Results)</text> <text x="48" y="228">201</text> <text x="96" y="228">Created</text> </g> </svg> </artwork> <artwork type="ascii-art" align="center"><![CDATA[ .---------------. .----------. .----------. | Relying Party | | Attester | | Verifier | '-+-------------' '----+-----' '--------+-' | | POST /verify | | | EAT(Evidence) | | +--------------------------->| | | 200 OK | | | EAT(Attestation Results) | | |<---------------------------+ | POST /auth | | | EAT(Attestation Results) | | |<---------------------------+ | | 201 Created | | +--------------------------->| | | | | | | | ]]></artwork> </artset> </figure> <t>This memo defines media types to be used forEntity Attestation Token (EAT) <xref target="EAT"/>EAT payloads <xref target="RFC9711"/> independently of the RATS Conceptual Message in which they manifest themselves. The objective is to give protocol,APIAPI, and application designers a number of readily available and reusable media types for integrating EAT-based messages in their flows,for examplee.g., when using HTTP <xreftarget="BUILD-W-HTTP"/>target="BCP56"/> orCoAPthe Constrained Application Protocol (CoAP) <xreftarget="REST-IoT"/>.</t>target="I-D.irtf-t2trg-rest-iot"/>.</t> <!-- [rfced] FYI - We have updated the title of Section 1.1 to "Terminology" from "Requirements Language" in order to avoid confusion regarding the 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. --> <sectionanchor="requirements-language"> <name>Requirements Language</name>anchor="terminology"> <name>Terminology</name> <t>This document uses the terms and concepts defined in <xreftarget="RATS-Arch"/>.</t>target="RFC9334"/>.</t> </section> </section> <section anchor="eat-types"> <name>EAT Types</name> <t><xref target="fig-eat-types"/> illustrates the six EAT wire formats and how they relate to each other. <xreftarget="EAT"/>target="RFC9711"/> defines four of them(CWT, JWT(CBOR Web Token (CWT), JSON Web Token (JWT), andDetachedthe detached EATBundlebundle in its JSON and CBOR flavours),whilstwhile <xreftarget="UCCS"/>target="RFC9781"/> definesUCCSthe Unprotected CWT Claims Set (UCCS) andUJCS.</t>Unprotected JWT Claims Sets (UJCS).</t> <!-- [rfced] Figure 2: Note that we have changed "Legenda" to "Legend" for clarity. Legeneda appears in some dictionaries without being defined as a key or explantion for a map or chart. --> <figure anchor="fig-eat-types"> <name>EAT Types</name> <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"> <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 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,176 L 120,192" fill="none" stroke="black"/> <path d="M 120,240 L 120,256" fill="none" stroke="black"/> <path d="M 120,304 L 120,320" fill="none" stroke="black"/> <path d="M 120,368 L 120,384" fill="none" stroke="black"/> <path d="M 128,432 L 128,464" fill="none" stroke="black"/> <path d="M 176,32 L 176,48" fill="none" stroke="black"/> <path d="M 176,96 L 176,112" fill="none" stroke="black"/> <path d="M 184,160 L 184,176" fill="none" stroke="black"/> <path d="M 184,224 L 184,240" fill="none" stroke="black"/> <path d="M 184,288 L 184,304" fill="none" stroke="black"/> <path d="M 184,352 L 184,368" fill="none" stroke="black"/> <path d="M 240,512 L 240,528" fill="none" stroke="black"/> <path d="M 272,360 L 272,448" fill="none" stroke="black"/> <path d="M 328,496 L 328,512" fill="none" stroke="black"/> <path d="M 336,256 L 336,288" fill="none" stroke="black"/> <path d="M 352,368 L 352,400" fill="none" stroke="black"/> <path d="M 360,496 L 360,528" fill="none" stroke="black"/> <path d="M 368,224 L 368,256" fill="none" stroke="black"/> <path d="M 368,288 L 368,320" fill="none" stroke="black"/> <path d="M 384,128 L 384,256" fill="none" stroke="black"/> <path d="M 384,296 L 384,368" fill="none" stroke="black"/> <path d="M 384,408 L 384,432" fill="none" stroke="black"/> <path d="M 400,64 L 400,256" fill="none" stroke="black"/> <path d="M 400,288 L 400,360" fill="none" stroke="black"/> <path d="M 416,496 L 416,528" fill="none" stroke="black"/> <path d="M 424,368 L 424,400" fill="none" stroke="black"/> <path d="M 440,256 L 440,288" fill="none" stroke="black"/> <path d="M 472,288 L 472,312" fill="none" stroke="black"/> <path d="M 472,352 L 472,368" fill="none" stroke="black"/> <path d="M 136,32 L 176,32" fill="none" stroke="black"/> <path d="M 88,48 L 120,48" fill="none" stroke="black"/> <path d="M 184,48 L 384,48" fill="none" stroke="black"/> <path d="M 120,64 L 160,64" fill="none" stroke="black"/> <path d="M 136,96 L 176,96" fill="none" stroke="black"/> <path d="M 72,112 L 120,112" fill="none" stroke="black"/> <path d="M 184,112 L 368,112" fill="none" stroke="black"/> <path d="M 120,128 L 160,128" fill="none" stroke="black"/> <path d="M 136,160 L 184,160" fill="none" stroke="black"/> <path d="M 72,176 L 120,176" fill="none" stroke="black"/> <path d="M 192,176 L 240,176" fill="none" stroke="black"/> <path d="M 120,192 L 168,192" fill="none" stroke="black"/> <path d="M 240,192 L 280,192" fill="none" stroke="black"/> <path d="M 304,208 L 352,208" fill="none" stroke="black"/> <path d="M 136,224 L 184,224" fill="none" stroke="black"/> <path d="M 240,224 L 280,224" fill="none" stroke="black"/> <path d="M 72,240 L 120,240" fill="none" stroke="black"/> <path d="M 192,240 L 240,240" fill="none" stroke="black"/> <path d="M 120,256 L 168,256" fill="none" stroke="black"/> <path d="M 336,256 L 440,256" fill="none" stroke="black"/> <path d="M 440,272 L 456,272" fill="none" stroke="black"/> <path d="M 136,288 L 184,288" fill="none" stroke="black"/> <path d="M 336,288 L 440,288" fill="none" stroke="black"/> <path d="M 72,304 L 120,304" fill="none" stroke="black"/> <path d="M 192,304 L 240,304" fill="none" stroke="black"/> <path d="M 120,320 L 168,320" fill="none" stroke="black"/> <path d="M 240,320 L 280,320" fill="none" stroke="black"/> <path d="M 456,320 L 496,320" fill="none" stroke="black"/> <path d="M 304,336 L 352,336" fill="none" stroke="black"/> <path d="M 136,352 L 184,352" fill="none" stroke="black"/> <path d="M 240,352 L 280,352" fill="none" stroke="black"/> <path d="M 456,352 L 496,352" fill="none" stroke="black"/> <path d="M 72,368 L 120,368" fill="none" stroke="black"/> <path d="M 192,368 L 240,368" fill="none" stroke="black"/> <path d="M 352,368 L 424,368" fill="none" stroke="black"/> <path d="M 120,384 L 168,384" fill="none" stroke="black"/> <path d="M 432,384 L 456,384" fill="none" stroke="black"/> <path d="M 352,400 L 424,400" fill="none" stroke="black"/> <path d="M 8,432 L 128,432" fill="none" stroke="black"/> <path d="M 128,448 L 368,448" fill="none" stroke="black"/> <path d="M 8,464 L 128,464" fill="none" stroke="black"/> <path d="M 144,496 L 192,496" fill="none" stroke="black"/> <path d="M 256,496 L 328,496" fill="none" stroke="black"/> <path d="M 360,496 L 416,496" fill="none" stroke="black"/> <path d="M 144,528 L 192,528" fill="none" stroke="black"/> <path d="M 240,528 L 312,528" fill="none" stroke="black"/> <path d="M 360,528 L 416,528" fill="none" stroke="black"/> <path d="M 136,32 C 127.16936,32 120,39.16936 120,48" fill="none" stroke="black"/> <path d="M 88,48 C 79.16936,48 72,55.16936 72,64" fill="none" stroke="black"/> <path d="M 384,48 C 392.83064,48 400,55.16936 400,64" fill="none" stroke="black"/> <path d="M 160,64 C 168.83064,64 176,56.83064 176,48" fill="none" stroke="black"/> <path d="M 136,96 C 127.16936,96 120,103.16936 120,112" fill="none" stroke="black"/> <path d="M 368,112 C 376.83064,112 384,119.16936 384,128" fill="none" stroke="black"/> <path d="M 160,128 C 168.83064,128 176,120.83064 176,112" fill="none" stroke="black"/> <path d="M 136,160 C 127.16936,160 120,167.16936 120,176" fill="none" stroke="black"/> <path d="M 240,176 C 248.83064,176 256,183.16936 256,192" fill="none" stroke="black"/> <path d="M 168,192 C 176.83064,192 184,184.83064 184,176" fill="none" stroke="black"/> <path d="M 240,192 C 231.16936,192 224,199.16936 224,208" fill="none" stroke="black"/> <path d="M 280,192 C 288.83064,192 296,199.16936 296,208" fill="none" stroke="black"/> <path d="M 352,208 C 360.83064,208 368,215.16936 368,224" fill="none" stroke="black"/> <path d="M 136,224 C 127.16936,224 120,231.16936 120,240" fill="none" stroke="black"/> <path d="M 240,224 C 231.16936,224 224,216.83064 224,208" fill="none" stroke="black"/> <path d="M 280,224 C 288.83064,224 296,216.83064 296,208" fill="none" stroke="black"/> <path d="M 240,240 C 248.83064,240 256,232.83064 256,224" fill="none" stroke="black"/> <path d="M 168,256 C 176.83064,256 184,248.83064 184,240" fill="none" stroke="black"/> <path d="M 456,272 C 464.83064,272 472,279.16936 472,288" fill="none" stroke="black"/> <path d="M 136,288 C 127.16936,288 120,295.16936 120,304" fill="none" stroke="black"/> <path d="M 240,304 C 248.83064,304 256,311.16936 256,320" fill="none" stroke="black"/> <path d="M 168,320 C 176.83064,320 184,312.83064 184,304" fill="none" stroke="black"/> <path d="M 240,320 C 231.16936,320 224,327.16936 224,336" fill="none" stroke="black"/> <path d="M 280,320 C 288.83064,320 296,327.16936 296,336" fill="none" stroke="black"/> <path d="M 456,320 C 447.16936,320 440,327.16936 440,336" fill="none" stroke="black"/> <path d="M 496,320 C 504.83064,320 512,327.16936 512,336" fill="none" stroke="black"/> <path d="M 352,336 C 360.83064,336 368,328.83064 368,320" fill="none" stroke="black"/> <path d="M 136,352 C 127.16936,352 120,359.16936 120,368" fill="none" stroke="black"/> <path d="M 240,352 C 231.16936,352 224,344.83064 224,336" fill="none" stroke="black"/> <path d="M 280,352 C 288.83064,352 296,344.83064 296,336" fill="none" stroke="black"/> <path d="M 456,352 C 447.16936,352 440,344.83064 440,336" fill="none" stroke="black"/> <path d="M 496,352 C 504.83064,352 512,344.83064 512,336" fill="none" stroke="black"/> <path d="M 240,368 C 248.83064,368 256,360.83064 256,352" fill="none" stroke="black"/> <path d="M 168,384 C 176.83064,384 184,376.83064 184,368" fill="none" stroke="black"/> <path d="M 456,384 C 464.83064,384 472,376.83064 472,368" fill="none" stroke="black"/> <path d="M 368,448 C 376.83064,448 384,440.83064 384,432" fill="none" stroke="black"/> <path d="M 144,496 C 135.16936,496 128,503.16936 128,512" fill="none" stroke="black"/> <path d="M 192,496 C 200.83064,496 208,503.16936 208,512" fill="none" stroke="black"/> <path d="M 256,496 C 247.16936,496 240,503.16936 240,512" fill="none" stroke="black"/> <path d="M 144,528 C 135.16936,528 128,520.83064 128,512" fill="none" stroke="black"/> <path d="M 192,528 C 200.83064,528 208,520.83064 208,512" fill="none" stroke="black"/> <path d="M 312,528 C 320.83064,528 328,520.83064 328,512" fill="none" stroke="black"/> <polygon class="arrowhead" points="480,312 468,306.4 468,317.6" fill="black" transform="rotate(90,472,312)"/> <polygon class="arrowhead" points="440,384 428,378.4 428,389.6" fill="black" transform="rotate(180,432,384)"/> <polygon class="arrowhead" points="408,360 396,354.4 396,365.6" fill="black" transform="rotate(90,400,360)"/> <polygon class="arrowhead" points="392,408 380,402.4 380,413.6" fill="black" transform="rotate(270,384,408)"/> <polygon class="arrowhead" points="392,296 380,290.4 380,301.6" fill="black" transform="rotate(270,384,296)"/> <polygon class="arrowhead" points="312,336 300,330.4 300,341.6" fill="black" transform="rotate(180,304,336)"/> <polygon class="arrowhead" points="312,208 300,202.4 300,213.6" fill="black" transform="rotate(180,304,208)"/> <polygon class="arrowhead" points="280,360 268,354.4 268,365.6" fill="black" transform="rotate(270,272,360)"/> <polygon class="arrowhead" points="200,368 188,362.4 188,373.6" fill="black" transform="rotate(180,192,368)"/> <polygon class="arrowhead" points="200,304 188,298.4 188,309.6" fill="black" transform="rotate(180,192,304)"/> <polygon class="arrowhead" points="200,240 188,234.4 188,245.6" fill="black" transform="rotate(180,192,240)"/> <polygon class="arrowhead" points="200,176 188,170.4 188,181.6" fill="black" transform="rotate(180,192,176)"/> <polygon class="arrowhead" points="192,112 180,106.4 180,117.6" fill="black" transform="rotate(180,184,112)"/> <polygon class="arrowhead" points="192,48 180,42.4 180,53.6" fill="black" transform="rotate(180,184,48)"/> <polygon class="arrowhead" points="80,424 68,418.4 68,429.6" fill="black" transform="rotate(90,72,424)"/> <g class="text"> <text x="148" y="52">UJCS</text> <text x="148" y="116">UCCS</text> <text x="152" y="180">JWT</text> <text x="260" y="212">Crypto</text> <text x="152" y="244">CWT</text> <text x="388" y="276">Claims-Set</text> <text x="152" y="308">BUN-J</text> <text x="260" y="340">Bundle</text> <text x="476" y="340">Digest</text> <text x="152" y="372">BUN-C</text> <text x="388" y="388">submod</text> <text x="68" y="452">Nested-Token</text> <text x="76"y="516">Legenda:</text>y="516">Legend:</text> <text x="168" y="516">Process</text> <text x="268" y="516">Wire</text> <text x="304" y="516">Fmt</text> <text x="388" y="516">CDDL</text> </g> </svg> </artwork> <artwork type="ascii-art" align="center"><![CDATA[ .-----. .----+ UJCS |<-------------------------. | '-----' | | | | .-----. | +-----+ UCCS |<-----------------------. | | '-----' | | | | | | .------. | | +-----+ JWT |<------. | | | '------' .--+---. | | | | Crypto |<------. | | | .------. '--+---' | | | +-----+ CWT |<------' | | | | '------' .---+-+-+----. | | Claims-Set +--. | .------. '---+---+----' | +-----+ BUN-J |<------. | ^ | v | '------' .--+---. | | | .------. | | Bundle |<------' | | | Digest | | .------. '--+---' | v '--+---' +-----+ BUN-C |<------' ^ .---+----. | | '------' | | submod |<---' | | '--------' v | ^ .--------------. | | | Nested-Token +-----------------+------------' '--------------' .-------. .---------. .------.Legenda:Legend: | Process | | Wire Fmt | | CDDL | '-------' '---------' '------' ]]></artwork> </artset> </figure> </section> <section anchor="a-media-type-parameter-for-eat-profiles"> <name>A Media Type Parameter for EAT Profiles</name> <!-- [rfced] RFC-to-be 9711 <draft-ietf-rats-eat> seems to double quotes for Claim names, while this document seems to use <tt>. Should this document use double 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="EAT"/>target="RFC9711"/> 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 tointeroperate. For example:interoperate, e.g., the number and type of claims, which serialisation format, the supported signature schemes, etc. EATs carry an in-band profile identifier using the <tt>eat_profile</tt> claim (see <xref section="4.3.2" sectionFormat="of"target="EAT"/>).target="RFC9711"/>). The value of the <tt>eat_profile</tt> claim is either an OID or a URI.</t> <t>The media types defined in this document include an optional <tt>eat_profile</tt> parameter that can be used to mirror the <tt>eat_profile</tt> 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.,<tt>application/eat+cwt)</tt><tt>application/eat+cwt</tt>) by populating the <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 (for example, with the "Content-Type" and "Accept"headers),headers) and the value is an absolute URI (<xref section="4.3" sectionFormat="of"target="URI"/>),target="RFC3986"/>), the <tt>parameter-value</tt> (<xref section="A" sectionFormat="of"target="HTTP"/>)target="RFC9110"/>) uses the <tt>quoted-string</tt> encoding,e.g.:</t> <ul empty="true"> <li> <t><tt>application/eat+jwt;for example:</t> <t indent="5"><tt>application/eat+jwt; eat_profile="tag:evidence.example,2022"</tt></t></li> </ul><t>Instead, when the EAT profile is an OID, the <tt>token</tt> encoding (i.e., without quotes) can beused, e.g.:</t> <ul empty="true"> <li> <t><tt>application/eat+cwt;used. For example:</t> <t indent="5"><tt>application/eat+cwt; eat_profile=2.999.1</tt>.</t></li> </ul></section> <section anchor="examples"> <name>Examples</name> <t>The example in <xref target="fig-rest-req"/> illustrates the usage of EAT media types for transporting attestation evidence as well as negotiating the acceptable format 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 symbols 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"> <name>Example REST Verification API (request)</name> <sourcecode type="http-message"><![CDATA[#NOTE: '\' line wrapping per RFC 8792 POST /challenge-response/v1/session/1234567890 HTTP/1.1 Host: verifier.example Accept: application/eat+cwt; eat_profile="tag:ar4si.example,2021" Content-Type: application/eat+cwt; \ eat_profile="tag:evidence.example,2022" [ CBOR-encoded EAT w/ eat_profile="tag:evidence.example,2022" ] ]]></sourcecode> </figure> <t>The example in <xref target="fig-rest-rsp"/> illustrates the usage of EAT media types for transporting attestation results.</t> <figure anchor="fig-rest-rsp"> <name>Example REST Verification API (response)</name> <sourcecode type="http-message"><![CDATA[#NOTE: '\' line wrapping per RFC 8792 HTTP/1.1 200 OK Content-Type: application/eat+cwt; \ eat_profile="tag:ar4si.example,2021" [ CBOR-encoded EAT w/ eat_profile="tag:ar4si.example,2021" ] ]]></sourcecode> </figure> <t>In both cases, a tag URI <xreftarget="TAG"/>target="RFC4151"/> identifying the profile is carried as an explicit parameter.</t> </section> <section anchor="seccons"> <name>Security Considerations</name> <t>Media types only provide clues to the processing application. The application must verify that the received data matches the expected format, regardless of 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 and cross-protocol attacks.</t> <t>The securityconsiderationconsiderations of <xreftarget="EAT"/>target="RFC9711"/> and <xreftarget="UCCS"/>target="RFC9781"/> apply in full.</t><t>In particular, when<t>When using <tt>application/eat-ucs+json</tt> and <tt>application/eat-ucs+cbor</tt> in particular, the reader should review <xref section="3" sectionFormat="of"target="UCCS"/>,target="RFC9781"/>, which contains a detailed discussion about the characteristics of a "Secure Channel" for conveyance of such messages.</t> </section> <section anchor="iana-considerations"> <name>IANA Considerations</name><t><cref anchor="to-be-removed">RFC Editor: please replace RFCthis with this RFC number and remove this note.</cref></t><section anchor="cwt-structured-syntax-suffix"> <name><tt>+cwt</tt> Structured Syntax Suffix</name> <t>IANAis requested to register thehas registered <tt>+cwt</tt>structured syntax suffixin the "Structured Syntax Suffixes" registry <xreftarget="IANA.media-type-structured-suffix"/>target="STRUCT-SYNTAX"/> in the manner described in <xreftarget="MediaTypes"/>, whichtarget="RFC6838"/>. <tt>+cwt</tt> can be used to indicate that the media type is encoded as a CWT.</t> <section anchor="registry-contents"> <name>Registry Contents</name> <dlspacing="compact">spacing="normal" newline="false"> <dt>Name:</dt> <dd> <t>CBOR Web Token (CWT)</t> </dd> <dt>+suffix:</dt> <dd> <t>+cwt</t> </dd> <dt>References:</dt> <dd> <t><xreftarget="CWT"/></t>target="RFC8392"/></t> </dd> <dt>Encoding Considerations:</dt> <dd> <t>binary</t> </dd> <dt>Interoperability Considerations:</dt> <dd> <t>N/A</t> </dd> <dt>Fragment Identifier Considerations:</dt> <dd> <t>The syntax and semantics of fragment identifiers specified for +cwt SHOULD be as specified for <tt>application/cwt</tt>. (Atpublicationthe time ofthis document,publication, there is no fragment identification syntax defined for <tt>application/cwt</tt>.)</t> </dd> <dt>Security Considerations:</dt> <dd> <t>See <xref section="8" sectionFormat="of"target="CWT"/></t>target="RFC8392"/></t> </dd> <dt>Contact:</dt> <dd> <t>RATS WG mailing list (rats@ietf.org), or IETF Security Area (saag@ietf.org)</t> </dd> <dt>Author/Change Controller:</dt> <dd> <t>Remote ATtestation ProcedureS (RATS) Working Group. The IETF has change control over this registration.</t> </dd> </dl> </section> </section> <section anchor="media-type"> <name>Media Types</name> <t>IANAis requested to addhas registered the following media typestoin the "Media Types" registry <xreftarget="IANA.media-types"/>.</t>target="MEDIA-TYPES"/>.</t> <tablealign="left"align="center" anchor="new-media-type"> <name>New Media Types</name> <thead> <tr> <th align="left">Name</th> <th align="left">Template</th> <th align="left">Reference</th> </tr> </thead> <tbody> <tr> <td align="left">EAT CWT</td> <td align="left">application/eat+cwt</td> <tdalign="left">RFCthis,align="left">RFC 9782, <xref target="media-type-eat-cwt"/></td> </tr> <tr> <td align="left">EAT JWT</td> <td align="left">application/eat+jwt</td> <tdalign="left">RFCthis,align="left">RFC 9782, <xref target="media-type-eat-jwt"/></td> </tr> <tr> <td align="left">Detached EAT Bundle CBOR</td> <td align="left">application/eat-bun+cbor</td> <tdalign="left">RFCthis,align="left">RFC 9782, <xref target="media-type-deb-cbor"/></td> </tr> <tr> <td align="left">Detached EAT Bundle JSON</td> <td align="left">application/eat-bun+json</td> <tdalign="left">RFCthis,align="left">RFC 9782, <xref target="media-type-deb-json"/></td> </tr> <tr> <td align="left">EAT UCCS</td> <td align="left">application/eat-ucs+cbor</td> <tdalign="left">RFCthis,align="left">RFC 9782, <xref target="media-type-ucs-cbor"/></td> </tr> <tr> <td align="left">EAT UJCS</td> <td align="left">application/eat-ucs+json</td> <tdalign="left">RFCthis,align="left">RFC 9782, <xref target="media-type-ucs-json"/></td> </tr> </tbody> </table> </section> <section anchor="media-type-eat-cwt"> <name>application/eat+cwt Registration</name> <dlspacing="compact">spacing="normal" newline="false"> <dt>Type name:</dt> <dd> <t>application</t> </dd> <dt>Subtype name:</dt> <dd> <t>eat+cwt</t> </dd> <dt>Required parameters:</dt> <dd> <t>n/a</t> </dd> <dt>Optional parameters:</dt> <dd> <t>"eat_profile" (EAT profile in string format. OIDs must use the dotted-decimal notation. The parameter value iscase-insensitive.)</t>case insensitive.)</t> </dd> <dt>Encoding considerations:</dt> <dd> <t>binary</t> </dd> <dt>Security considerations:</dt> <dd> <t><xref section="9" sectionFormat="of"target="EAT"/></t>target="RFC9711"/></t> </dd> <dt>Interoperability considerations:</dt> <dd> <t>n/a</t> </dd> <dt>Published specification:</dt> <dd><t>RFCthis</t><t>RFC 9782</t> </dd> <dt>Applications that use this media type:</dt> <dd> <t>Attesters, Verifiers, Endorsers and Reference-Value providers, and Relying Parties that need to transfer EAT payloads over HTTP(S), CoAP(S), and other transports.</t> </dd> <dt>Fragment identifier considerations:</dt> <dd> <t>n/a</t> </dd> <dt>Person & email address to contact for further information:</dt> <dd> <t>RATS WG mailing list (rats@ietf.org)</t> </dd> <dt>Intended usage:</dt> <dd> <t>COMMON</t> </dd> <dt>Restrictions on usage:</dt> <dd> <t>none</t> </dd> <dt>Author/Change controller:</dt> <dd> <t>IETF</t> </dd> <dt>Provisional registration:</dt> <dd> <t>no</t> </dd> </dl> </section> <section anchor="media-type-eat-jwt"> <name>application/eat+jwt Registration</name> <dlspacing="compact">spacing="normal" newline="false"> <dt>Type name:</dt> <dd> <t>application</t> </dd> <dt>Subtype name:</dt> <dd> <t>eat+jwt</t> </dd> <dt>Required parameters:</dt> <dd> <t>n/a</t> </dd> <dt>Optional parameters:</dt> <dd> <t>"eat_profile" (EAT profile in string format. OIDs must use the dotted-decimal notation. The parameter value iscase-insensitive.)</t>case insensitive.)</t> </dd> <dt>Encoding considerations:</dt> <dd> <t>8bit</t> </dd> <dt>Security considerations:</dt> <dd> <t><xref section="9" sectionFormat="of"target="EAT"/>target="RFC9711"/> and <xref target="BCP225"/></t> </dd> <dt>Interoperability considerations:</dt> <dd> <t>n/a</t> </dd> <dt>Published specification:</dt> <dd><t>RFCthis</t><t>RFC 9782</t> </dd> <dt>Applications that use this mediatype</dt>type:</dt> <dd> <t>Attesters, Verifiers, Endorsers and Reference-Value providers, and Relying Parties that need to transfer EAT payloads over HTTP(S), CoAP(S), and other transports.</t> </dd> <dt>Fragment identifier considerations:</dt> <dd> <t>n/a</t> </dd> <dt>Person & email address to contact for further information:</dt> <dd> <t>RATS WG mailing list (rats@ietf.org)</t> </dd> <dt>Intended usage:</dt> <dd> <t>COMMON</t> </dd> <dt>Restrictions on usage:</dt> <dd> <t>none</t> </dd> <dt>Author/Change controller:</dt> <dd> <t>IETF</t> </dd> <dt>Provisional registration:</dt> <dd> <t>no</t> </dd> </dl> </section> <section anchor="media-type-deb-cbor"> <name>application/eat-bun+cbor Registration</name> <dlspacing="compact">spacing="normal" newline="false"> <dt>Type name:</dt> <dd> <t>application</t> </dd> <dt>Subtype name:</dt> <dd> <t>eat-bun+cbor</t> </dd> <dt>Required parameters:</dt> <dd> <t>n/a</t> </dd> <dt>Optional parameters:</dt> <dd> <t>"eat_profile" (EAT profile in string format. OIDs must use the dotted-decimal notation. The parameter value iscase-insensitive.)</t>case insensitive.)</t> </dd> <dt>Encoding considerations:</dt> <dd> <t>binary</t> </dd> <dt>Security considerations:</dt> <dd> <t><xref section="9" sectionFormat="of"target="EAT"/></t>target="RFC9711"/></t> </dd> <dt>Interoperability considerations:</dt> <dd> <t>n/a</t> </dd> <dt>Published specification:</dt> <dd><t>RFCthis</t><t>RFC 9782</t> </dd> <dt>Applications that use this media type:</dt> <dd> <t>Attesters, Verifiers, Endorsers and Reference-Value providers, and Relying Parties that need to transfer EAT payloads over HTTP(S), CoAP(S), and other transports.</t> </dd> <dt>Fragment identifier considerations:</dt> <dd> <t>n/a</t> </dd> <dt>Person & email address to contact for further information:</dt> <dd> <t>RATS WG mailing list (rats@ietf.org)</t> </dd> <dt>Intended usage:</dt> <dd> <t>COMMON</t> </dd> <dt>Restrictions on usage:</dt> <dd> <t>none</t> </dd> <dt>Author/Change controller:</dt> <dd> <t>IETF</t> </dd> <dt>Provisional registration:</dt> <dd> <t>no</t> </dd> </dl> </section> <section anchor="media-type-deb-json"> <name>application/eat-bun+json Registration</name> <dlspacing="compact">spacing="normal" newline="false"> <dt>Type name:</dt> <dd> <t>application</t> </dd> <dt>Subtype name:</dt> <dd> <t>eat-bun+json</t> </dd> <dt>Required parameters:</dt> <dd> <t>n/a</t> </dd> <dt>Optional parameters:</dt> <dd> <t>"eat_profile" (EAT profile in string format. OIDs must use the dotted-decimal notation. The parameter value iscase-insensitive.)</t>case insensitive.)</t> </dd> <dt>Encoding considerations:</dt> <dd> <t>Same as <xreftarget="JSON"/></t>target="RFC8259"/></t> </dd> <dt>Security considerations:</dt> <dd> <t><xref section="9" sectionFormat="of"target="EAT"/></t>target="RFC9711"/></t> </dd> <dt>Interoperability considerations:</dt> <dd> <t>n/a</t> </dd> <dt>Published specification:</dt> <dd><t>RFCthis</t><t>RFC 9782</t> </dd> <dt>Applications that use this mediatype</dt>type:</dt> <dd> <t>Attesters, Verifiers, Endorsers and Reference-Value providers, and Relying Parties that need to transfer EAT payloads over HTTP(S), CoAP(S), and other transports.</t> </dd> <dt>Fragment identifier considerations:</dt> <dd> <t>n/a</t> </dd> <dt>Person & email address to contact for further information:</dt> <dd> <t>RATS WG mailing list (rats@ietf.org)</t> </dd> <dt>Intended usage:</dt> <dd> <t>COMMON</t> </dd> <dt>Restrictions on usage:</dt> <dd> <t>none</t> </dd> <dt>Author/Change controller:</dt> <dd> <t>IETF</t> </dd> <dt>Provisional registration:</dt> <dd> <t>no</t> </dd> </dl> </section> <section anchor="media-type-ucs-cbor"> <name>application/eat-ucs+cbor Registration</name> <dlspacing="compact">spacing="normal" newline="false"> <dt>Type name:</dt> <dd> <t>application</t> </dd> <dt>Subtype name:</dt> <dd> <t>eat-ucs+cbor</t> </dd> <dt>Required parameters:</dt> <dd> <t>n/a</t> </dd> <dt>Optional parameters:</dt> <dd> <t>"eat_profile" (EAT profile in string format. OIDs must use the dotted-decimal notation. The parameter value iscase-insensitive.)</t>case insensitive.)</t> </dd> <dt>Encoding considerations:</dt> <dd> <t>binary</t> </dd> <dt>Security considerations:</dt> <dd> <t>Sections <xreftarget="UCCS"target="RFC9781" section="3" sectionFormat="bare"/> and <xreftarget="UCCS"target="RFC9781" section="7" sectionFormat="bare"/> of <xreftarget="UCCS"/></t>target="RFC9781"/></t> </dd> <dt>Interoperability considerations:</dt> <dd> <t>n/a</t> </dd> <dt>Published specification:</dt> <dd><t>RFCthis</t><t>RFC 9782</t> </dd> <dt>Applications that use this media type:</dt> <dd> <t>Attesters, Verifiers, Endorsers and Reference-Value providers, and Relying Parties that need to transfer EAT payloads over HTTP(S), CoAP(S), and other transports.</t> </dd> <dt>Fragment identifier considerations:</dt> <dd> <t>n/a</t> </dd> <dt>Person & email address to contact for further information:</dt> <dd> <t>RATS WG mailing list (rats@ietf.org)</t> </dd> <dt>Intended usage:</dt> <dd> <t>COMMON</t> </dd> <dt>Restrictions on usage:</dt> <dd> <t>none</t> </dd> <dt>Author/Change controller:</dt> <dd> <t>IETF</t> </dd> <dt>Provisional registration:</dt> <dd> <t>no</t> </dd> </dl> </section> <section anchor="media-type-ucs-json"> <name>application/eat-ucs+json Registration</name> <dlspacing="compact">spacing="normal" newline="false"> <dt>Type name:</dt> <dd> <t>application</t> </dd> <dt>Subtype name:</dt> <dd> <t>eat-ucs+json</t> </dd> <dt>Required parameters:</dt> <dd> <t>n/a</t> </dd> <dt>Optional parameters:</dt> <dd> <t>"eat_profile" (EAT profile in string format. OIDs must use the dotted-decimal notation. The parameter value iscase-insensitive.)</t>case insensitive.)</t> </dd> <dt>Encoding considerations:</dt> <dd> <t>Same as <xreftarget="JSON"/></t>target="RFC8259"/></t> </dd> <dt>Security considerations:</dt> <dd> <t>Sections <xreftarget="UCCS"target="RFC9781" section="3" sectionFormat="bare"/> and <xreftarget="UCCS"target="RFC9781" section="7" sectionFormat="bare"/> of <xreftarget="UCCS"/></t>target="RFC9781"/></t> </dd> <dt>Interoperability considerations:</dt> <dd> <t>n/a</t> </dd> <dt>Published specification:</dt> <dd><t>RFCthis</t><t>RFC 9782</t> </dd> <dt>Applications that use this mediatype</dt>type:</dt> <dd> <t>Attesters, Verifiers, Endorsers and Reference-Value providers, and Relying Parties that need to transfer EAT payloads over HTTP(S), CoAP(S), and other transports.</t> </dd> <dt>Fragment identifier considerations:</dt> <dd> <t>n/a</t> </dd> <dt>Person & email address to contact for further information:</dt> <dd> <t>RATS WG mailing list (rats@ietf.org)</t> </dd> <dt>Intended usage:</dt> <dd> <t>COMMON</t> </dd> <dt>Restrictions on usage:</dt> <dd> <t>none</t> </dd> <dt>Author/Change controller:</dt> <dd> <t>IETF</t> </dd> <dt>Provisional registration:</dt> <dd> <t>no</t> </dd> </dl> </section> <section anchor="coap-content-format-registrations"> <name>CoAP Content-Format Registrations</name> <t>IANAis requested to registerhas registered the following Content-Format numbers in the "CoAP Content-Formats"sub-registry,registry, within the "Constrained RESTful Environments (CoRE) Parameters"Registryregistry group <xreftarget="IANA.core-parameters"/>:</t>target="CORE-PARAMS"/>:</t> <tablealign="left">align="center"> <name>New Content-Formats</name> <thead> <tr> <thalign="left">Content-Type</th>align="left">Content Type</th> <th align="left">Content Coding</th> <th align="left">ID</th> <th align="left">Reference</th> </tr> </thead> <tbody> <tr> <td align="left">application/eat+cwt</td> <td align="left">-</td> <tdalign="left">TBD1</td>align="left">263</td> <tdalign="left">RFCthis</td>align="left">RFC 9782</td> </tr> <tr> <td align="left">application/eat+jwt</td> <td align="left">-</td> <tdalign="left">TBD2</td>align="left">264</td> <tdalign="left">RFCthis</td>align="left">RFC 9782</td> </tr> <tr> <td align="left">application/eat-bun+cbor</td> <td align="left">-</td> <tdalign="left">TBD3</td>align="left">265</td> <tdalign="left">RFCthis</td>align="left">RFC 9782</td> </tr> <tr> <td align="left">application/eat-bun+json</td> <td align="left">-</td> <tdalign="left">TBD4</td>align="left">266</td> <tdalign="left">RFCthis</td>align="left">RFC 9782</td> </tr> <tr> <td align="left">application/eat-ucs+cbor</td> <td align="left">-</td> <tdalign="left">TBD5</td>align="left">267</td> <tdalign="left">RFCthis</td>align="left">RFC 9781</td> </tr> <tr> <td align="left">application/eat-ucs+json</td> <td align="left">-</td> <tdalign="left">TBD6</td>align="left">268</td> <tdalign="left">RFCthis</td>align="left">RFC 9782</td> </tr> </tbody> </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 with EAT (<eref target="https://github.com/ietf-rats-wg/draft-eat-mt/issues/4">Issue#4</eref>)</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</eref>)</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</eref>, <eref target="https://github.com/ietf-rats-wg/draft-eat-mt/issues/9">Issue#9</eref>)</t> </li> </ul></section> </section> </middle> <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"> <name>References</name> <references anchor="sec-normative-references"> <name>Normative References</name> <!-- Updated following REF entry to RFC9711 (AUTH48). Note that the original cite tag for this reference is [EAT]. --> <referenceanchor="EAT">anchor="RFC9711" target="https://www.rfc-editor.org/info/rfc9711"> <front> <title>The Entity Attestation Token (EAT)</title> <author fullname="Laurence Lundblade" initials="L." surname="Lundblade"> <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'Donoghue"><organization>Qualcomm Technologies Inc.</organization></author> <author fullname="Carl Wallace" initials="C." surname="Wallace"> <organization>Red Hound Software, Inc.</organization> </author> <dateday="6" month="September" year="2024"/> <abstract> <t> An Entity Attestation Token (EAT) provides an attested claims 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 attestation-oriented claims. </t> </abstract> </front> <seriesInfo name="Internet-Draft" value="draft-ietf-rats-eat-31"/> </reference> <reference anchor="JWT"> <front> <title>JSON Web Token (JWT)</title> <author fullname="M. Jones" initials="M." surname="Jones"/> <author fullname="J. Bradley" initials="J." surname="Bradley"/> <author fullname="N. Sakimura" initials="N." surname="Sakimura"/> <date month="May" year="2015"/> <abstract> <t>JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted.</t> </abstract>month="April" year="2025"/> </front> <seriesInfo name="RFC"value="7519"/>value="9711"/> <seriesInfo name="DOI"value="10.17487/RFC7519"/>value="10.17487/RFC9711"/> </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)<!-- [rfced] We note that RFC 7519 isa compact means of representing claims to be transferred between two parties. The claimsnot cited anywhere ina CWT are encodedthis document. Please let us know if there is an appropriate place in theConcise Binary Object Representation (CBOR), and CBOR Object Signing and Encryption (COSE) is usedtext to reference this RFC. Otherwise, we will remove it from the Normative References section. --> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7519.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8392.xml"/> <!-- [UCCS] [RFC9781] (draft-ietf-rats-uccs) Note that the original cite tag foradded application-layer security protection. A claim is a piece of information asserted about a subject and is represented as a name/value pair consisting of a claim name and a claim value. CWTthis reference isderived 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>[UCCS]. --> <referenceanchor="UCCS">anchor="RFC9781" target="https://www.rfc-editor.org/info/rfc9781"> <front> <title>ACBORConcise Binary Object Representation (CBOR) Tag for UnprotectedCWTCBOR Web Token ClaimsSets</title>Sets (UCCS) </title> <author fullname="Henk Birkholz" initials="H." surname="Birkholz"> <organization>Fraunhofer SIT</organization> </author> <author fullname="Jeremy O'Donoghue" initials="J." surname="O'Donoghue"> <organization>Qualcomm Technologies Inc.</organization> </author> <author fullname="Nancy Cam-Winget" initials="N." surname="Cam-Winget"> <organization>Cisco Systems</organization> </author> <author fullname="Carsten Bormann" initials="C." surname="Bormann"> <organization>Universität Bremen TZI</organization> </author> <dateday="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 // present revision (–12) contains remaining document changes based // on feedback from the IESG evaluation and has been submitted as // input to IETF 121. </t> </abstract> </front> <seriesInfo name="Internet-Draft" value="draft-ietf-rats-uccs-12"/> </reference> <reference anchor="MediaTypes"> <front> <title>Media Type Specifications and Registration Procedures</title> <author fullname="N. Freed" initials="N." surname="Freed"/> <author fullname="J. Klensin" initials="J." surname="Klensin"/> <author fullname="T. Hansen" initials="T." surname="Hansen"/> <date month="January" year="2013"/> <abstract> <t>This document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols. This memo documents an Internet Best Current Practice.</t> </abstract> </front> <seriesInfo name="BCP" value="13"/> <seriesInfo name="RFC" value="6838"/> <seriesInfo name="DOI" value="10.17487/RFC6838"/> </reference> <reference anchor="URI"> <front> <title>Uniform Resource Identifier (URI): Generic Syntax</title> <author fullname="T. Berners-Lee" initials="T." surname="Berners-Lee"/> <author fullname="R. Fielding" initials="R." surname="Fielding"/> <author fullname="L. Masinter" initials="L." surname="Masinter"/> <date month="January" year="2005"/> <abstract> <t>A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; 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="Reschke"/> <date month="June" year="2022"/> <abstract> <t>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, 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, 7232, 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 ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data.</t> <t>This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance.</t> </abstract>month="April" year="2025"/> </front> <seriesInfoname="STD" value="90"/> <seriesInfoname="RFC"value="8259"/>value="9781"/> <seriesInfo name="DOI"value="10.17487/RFC8259"/>value="10.17487/RFC9781"/> </reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6838.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3986.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9110.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8259.xml"/> <referenceanchor="IANA.media-type-structured-suffix"anchor="STRUCT-SYNTAX" target="https://www.iana.org/assignments/media-type-structured-suffix"> <front> <title>Structured Syntax Suffixes</title> <author> <organization>IANA</organization> </author> </front> </reference> <referenceanchor="IANA.media-types"anchor="MEDIA-TYPES" target="https://www.iana.org/assignments/media-types"> <front> <title>Media Types</title> <author> <organization>IANA</organization> </author> </front> </reference><referencegroup anchor="BCP225" target="https://www.rfc-editor.org/info/bcp225"> <reference anchor="RFC8725" target="https://www.rfc-editor.org/info/rfc8725"> <front> <title>JSON Web Token Best Current Practices</title> <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 numerous protocols and applications, both in the area of digital identity and in other application areas. This Best Current Practices document updates RFC 7519 to 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><xi:include href="https://bib.ietf.org/public/rfc/bibxml9/reference.BCP.0225.xml"/> <referenceanchor="IANA.core-parameters"anchor="CORE-PARAMS" target="https://www.iana.org/assignments/core-parameters"> <front><title>Constrained RESTful Environments (CoRE) Parameters</title><title>CoAP Content-Formats</title> <author> <organization>IANA</organization> </author> </front> </reference> </references> <references anchor="sec-informative-references"> <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 of a communication to know whether the other end is in an intended operating state. This document provides an architectural overview of the entities involved that make such tests possible through the process<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9334.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml9/reference.BCP.056.xml"/> <!-- [REST-IoT] draft-irtf-t2trg-rest-iot-15: I-D Exists as ofgenerating, conveying,1/8/25 --> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.irtf-t2trg-rest-iot.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4151.xml"/> </references> </references> <section numbered="false" anchor="acknowledgments"> <name>Acknowledgments</name> <t>Thank you <contact fullname="Carl Wallace"/>, <contact fullname="Carsten Bormann"/>, <contact fullname="Dave Thaler"/>, <contact fullname="Deb Cooley"/>, <contact fullname="Éric Vyncke"/>, <contact fullname="Francesca Palombini"/>, <contact fullname="Jouni Korhonen"/>, <contact fullname="Kathleen Moriarty"/>, <contact fullname="Michael Richardson"/>, <contact fullname="Murray Kucherawy"/>, <contact fullname="Orie Steele"/>, <contact fullname="Paul Howard"/>, <contact fullname="Roman Danyliw"/>, and <contact fullname="Tim Hollebeek"/> for your comments andevaluating evidentiary Claims. It provides a model that is neutral toward processor architectures,suggestions.</t> </section> </back> <!-- [rfced] We have thecontent 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/rfc9205"> <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-based APIs. This document specifies best practicesfollowing queries regarding abbreviations and expansions. a) FYI - We have added expansions forwriting specifications thatabbreviations upon first useHTTPper Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each expansion in the document carefully todefine new application protocols. Itensure correctness. b) FYI - When the abbreviation "EAT" iswritten primarily to guide IETF effortsused in plural form, we have updated todefine application protocols using HTTP for deployment on the Internet but might be applicableuse "EATs". We note this expansion inother 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</title> <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 Things (IoT) systemsparticular since there are multiple occurences thatfollowhave been updated. Please let us know any objections. --> <!-- [rfced] Please review theprinciples"Inclusive Language" portion of theRepresentational State Transfer (REST) architectural style. This document is a product of the IRTF Thing-to-Thing Research Group (T2TRG). </t> </abstract> </front> <seriesInfo name="Internet-Draft" value="draft-irtf-t2trg-rest-iot-15"/> </reference> <reference anchor="TAG"> <front> <title>The 'tag' URI Scheme</title> <author fullname="T. Kindberg" initials="T." surname="Kindberg"/> <author fullname="S. Hawke" initials="S." surname="Hawke"/> <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 spaceonline Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> andtime while being tractable to humans. Theylet us know if any changes aredistinct from most other URIsneeded. Updates of this nature typically result in more precise language, which is helpful for readers. Note thatthey have no authoritative resolution mechanism. A tag mayour script did not flag any words in particular, but this should still beused purely as an entity identifier. Furthermore, using tags has some advantages over the common practice of using "http" URIsreviewed asidentifiers 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> <?line 646?> <section numbered="false" anchor="acknowledgments"> <name>Acknowledgments</name> <t>Thank you Carl Wallace, Carsten Bormann, Dave Thaler, Deb Cooley, Éric Vyncke, Francesca Palombini, Jouni Korhonen, Kathleen Moriarty, Michael Richardson, Murray Kucherawy, Orie Steele, Paul Howard, Roman Danyliw and Tim Hollebeek for your comments and suggestions.</t> </section> </back> <!-- ##markdown-source: H4sIAAAAAAAAA+1c63IbN5b+j6fA0FUjKWJTluSbuJupyLrEcmRLJdLxj0wy ArtBsq1mgwN0S+ZIyv99i32WmRfb7wDoG0VdbGd2NykrVZGaDRwcnOt3DkAH QcDOu3yTsSzOEtnle9t9/kZGseD92VQaJgYDLc9vfh6pMBUTTIi0GGZBLLNh oEVmAimyYEIDgwwDg/UNZvLBJDYmVilN7fKDvf4+C0UmR0rPutxkEWPxVHd5 pnOTbTx+vPV4gwktRZe3ejLMdZzNWuxC6bORVvkUn57Iicok3+5n0mQiA2V+ rFUoo1zLXoudyRlGR5bpNrfMcGKGMYxOo7+JRKXgY4ZtTOMu/ylTYZsbpTMt hwZ/zSb0x8+MiTwbK91lPOBxarr8sMMP8zQaJCKSjHPuJHAosGwayuY7pUci jf9huevyYh+8P5bYNT883KFBciLipMuTUfKd8SMyO6ATqkm57KsOfxnrs7FK /lGt+kqmZ42PsWCX72uRp2M1lJofpAY6zSGnodKOAYkP8TBxIuvLcJyqRI1m NL1QdI1C76BfY3KMBTsDv+B3pHAwmWYizGiQgfBk1uUnYwmeMy2Mkfz5U3oV qgj8Lj17srH1dMl+gG12+a7QE+gjytyYPM3IGr6XYC+dlXvvd/i+MgYcV1vv j9VEmPrnTWEfxqnQqsZ6Zid0hm7Cd4l938EkxlInjnMJLZO9wDyD3U7DnPHi 9Xu8ONnfef50fQuPO/7xxebWBh7f7ez05uflYWjwyrqM9Rg74dmLzRc04eTA Pm5uvXiGx1f9/rF93lpff0yr9Y7eOvobT7fgG4XOHJMn2/1esK3DsZuyufkE H758d3C4G7wPHKmXO8dPifDJXq8fHKhiUxrMZRuZHgUafhPEirbW3/7eEnqy /nSdMZlmpBx83ts73CdX29/JxrFpMRYEAYyEVAuNs2MxS5SIDM+NjKAqXvhk tsAnDZ+IGdfy73kMGxQph3WoMEYIiJx7MnJPa6cw/1jDHNJzORNwqrb9VH4U k2ki+QWMsFoRuxvmCd8+PjAdxvpgE9QmikdyGKe0aOn5hmeKD6SbSgT37D4b 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=a best practice. --> </rfc>