rfc9770.original.xml   rfc9770.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" ?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
<!-- generated by https://github.com/cabo/kramdown-rfc version (Ruby 3.2.3) --> -ietf-ace-revoked-token-notification-09" number="9770" category="std" updates=""
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft obsoletes="" consensus="true" submissionType="IETF" tocInclude="true" sortRefs=
-ietf-ace-revoked-token-notification-09" category="std" consensus="true" submiss "true" symRefs="true" version="3" xml:lang="en">
ionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.21.0 -->
<front> <front>
<title abbrev="Notification of Revoked Tokens in ACE">Notification of Revoke d Access Tokens in the Authentication and Authorization for Constrained Environm ents (ACE) Framework</title> <title abbrev="Notification of Revoked Tokens in ACE">Notification of Revoke d Access Tokens in the Authentication and Authorization for Constrained Environm ents (ACE) Framework</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-ace-revoked-token-notifi cation-09"/> <seriesInfo name="RFC" value="9770"/>
<author initials="M." surname="Tiloca" fullname="Marco Tiloca"> <author initials="M." surname="Tiloca" fullname="Marco Tiloca">
<organization>RISE AB</organization> <organization>RISE AB</organization>
<address> <address>
<postal> <postal>
<street>Isafjordsgatan 22</street> <street>Isafjordsgatan 22</street>
<city>Kista</city> <city>Kista</city>
<code>16440</code> <code>16440</code>
<country>Sweden</country> <country>Sweden</country>
</postal> </postal>
<email>marco.tiloca@ri.se</email> <email>marco.tiloca@ri.se</email>
skipping to change at line 44 skipping to change at line 43
<country>Sweden</country> <country>Sweden</country>
</postal> </postal>
<email>francesca.palombini@ericsson.com</email> <email>francesca.palombini@ericsson.com</email>
</address> </address>
</author> </author>
<author initials="S." surname="Echeverria" fullname="Sebastian Echeverria"> <author initials="S." surname="Echeverria" fullname="Sebastian Echeverria">
<organization>CMU SEI</organization> <organization>CMU SEI</organization>
<address> <address>
<postal> <postal>
<street>4500 Fifth Avenue</street> <street>4500 Fifth Avenue</street>
<city>Pittsburgh, PA</city> <city>Pittsburgh</city><region>PA</region>
<code>15213-2612</code> <code>15213-2612</code>
<country>United States of America</country> <country>United States of America</country>
</postal> </postal>
<email>secheverria@sei.cmu.edu</email> <email>secheverria@sei.cmu.edu</email>
</address> </address>
</author> </author>
<author initials="G." surname="Lewis" fullname="Grace Lewis"> <author initials="G." surname="Lewis" fullname="Grace Lewis">
<organization>CMU SEI</organization> <organization>CMU SEI</organization>
<address> <address>
<postal> <postal>
<street>4500 Fifth Avenue</street> <street>4500 Fifth Avenue</street>
<city>Pittsburgh, PA</city> <city>Pittsburgh</city><region>PA</region>
<code>15213-2612</code> <code>15213-2612</code>
<country>United States of America</country> <country>United States of America</country>
</postal> </postal>
<email>glewis@sei.cmu.edu</email> <email>glewis@sei.cmu.edu</email>
</address> </address>
</author> </author>
<date year="2024" month="September" day="22"/> <date year="2025" month="April"/>
<area>Security</area> <area>SEC</area>
<workgroup>ACE Working Group</workgroup> <workgroup>ace</workgroup>
<keyword>Internet-Draft</keyword>
<!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->
<keyword>example</keyword>
<abstract> <abstract>
<t>This document specifies a method of the Authentication and Authorizatio n for Constrained Environments (ACE) framework, which allows an authorization s erver to notify clients and resource servers (i.e., registered devices) about re voked access tokens. As specified in this document, the method allows clients an d resource servers to access a Token Revocation List on the authorization server by using the Constrained Application Protocol (CoAP), with the possible additio nal use of resource observation. Resulting (unsolicited) notifications of revoke d access tokens complement alternative approaches such as token introspection, w hile not requiring additional endpoints on clients and resource servers.</t> <t>This document specifies a method of the Authentication and Authorizatio n for Constrained Environments (ACE) framework, which allows an authorization s erver to notify clients and resource servers (i.e., registered devices) about re voked access tokens. As specified in this document, the method allows clients an d resource servers to access a Token Revocation List (TRL) on the authorization server by using the Constrained Application Protocol (CoAP), with the possible a dditional use of resource observation. Resulting (unsolicited) notifications of revoked access tokens complement alternative approaches such as token introspect ion, while not requiring additional endpoints on clients and resource servers.</ t>
</abstract> </abstract>
<note removeInRFC="true">
<name>Discussion Venues</name>
<t>Discussion of this document takes place on the
Authentication and Authorization for Constrained Environments Working Group
mailing list (ace@ietf.org),
which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/
ace/"/>.</t>
<t>Source for this draft and an issue tracker can be found at
<eref target="https://github.com/ace-wg/ace-revoked-token-notification"/>.</
t>
</note>
</front> </front>
<middle> <middle>
<section anchor="intro"> <section anchor="intro">
<name>Introduction</name> <name>Introduction</name>
<t>Authentication and Authorization for Constrained Environments (ACE) <xr <t>Authentication and Authorization for Constrained Environments (ACE) <xr
ef target="RFC9200"/> is a framework that enforces access control on IoT devices ef target="RFC9200"/> is a framework that enforces access control on Internet of
acting as resource servers (RSs). In order to use ACE, both clients and RSs hav Things (IoT) devices acting as Resource Servers (RSs). In order to use ACE, bot
e to register with an authorization server (AS) and become a registered device. h clients and RSs have to register with an Authorization Server (AS) and become
Once registered, a client can send a request to the AS, to obtain an access toke registered devices. Once registered, a client can send a request to the AS to ob
n for an RS. For a client to access the RS, the client must present the issued a tain an access token for an RS. For a client to access the RS, the client must p
ccess token at the RS, which then validates it before storing it (see <xref sect resent the issued access token at the RS, which then validates it before storing
ion="5.10.1.1" sectionFormat="of" target="RFC9200"/>).</t> it (see <xref section="5.10.1.1" sectionFormat="of" target="RFC9200"/>).</t>
<t>Even though access tokens have expiration times, there are circumstance
s by which an access token may need to be revoked before its expiration time, su <!--[rfced] Please review the use of "and" before list item 5: should
ch as: (1) a registered device has been compromised, or is suspected of being co this instead be "or"?
mpromised; (2) a registered device is decommissioned; (3) there has been a chang
e in the ACE profile for a registered device; (4) there has been a change in acc Original:
ess policies for a registered device; and (5) there has been a change in the out Even though access tokens have expiration times, there are
come of policy evaluation for a registered device (e.g., if policy assessment de circumstances by which an access token may need to be revoked before
pends on dynamic conditions in the execution environment, the user context, or t its expiration time, such as: (1) a registered device has been
he resource utilization).</t> compromised, or is suspected of being compromised; (2) a registered
<t>As discussed in <xref section="6.1" sectionFormat="of" target="RFC9200" device is decommissioned; (3) there has been a change in the ACE
/>, only client-initiated revocation is currently specified <xref target="RFC700 profile for a registered device; (4) there has been a change in
9"/> for OAuth 2.0 <xref target="RFC6749"/>, based on the assumption that access access policies for a registered device; and (5) there has been a
tokens in OAuth are issued with a relatively short lifetime. However, this is n change in the outcome of policy evaluation for a registered device
ot expected to be the case for constrained, intermittently connected devices, th (e.g., if policy assessment depends on dynamic conditions in the
at need access tokens with relatively long lifetimes.</t> execution environment, the user context, or the resource
<t>This document specifies a method for allowing registered devices to acc utilization).
ess and possibly subscribe to a Token Revocation List (TRL) on the AS, in order
to obtain updated information about pertaining access tokens that were revoked p -->
rior to their expiration. As specified in this document, the registered devices
use the Constrained Application Protocol (CoAP) <xref target="RFC7252"/> to comm <t>Even though access tokens have expiration times, there are circumstance
unicate with the AS and with one another, and can subscribe to the TRL on the AS s by which an access token may need to be revoked before its expiration time, su
by using resource observation for CoAP <xref target="RFC7641"/>. Other underlyi ch as when:</t>
ng protocols than CoAP are not prohibited from being supported in the future, if <ol spacing="normal" type="1">
they are defined to be used in the ACE framework for Authentication and Authori <li>a registered device has been compromised or is suspected of being com
zation.</t> promised;</li>
<t>Unlike in the case of token introspection (see <xref section="5.9" sect <li>a registered device is decommissioned;</li>
ionFormat="of" target="RFC9200"/>), a registered device does not provide an owne <li>there has been a change in the ACE profile for a registered device;</
d access token to the AS for inquiring about its current state. Instead, registe li>
red devices simply obtain updated information about pertaining access tokens tha <li>there has been a change in access policies for a registered device; a
t were revoked prior to their expiration, as efficiently identified by correspon nd</li>
ding hash values.</t> <li>there has been a change in the outcome of policy evaluation for a reg
<t>The benefits of this method are that it complements token introspection istered device (e.g., if policy assessment depends on dynamic conditions in the
, and it does not require the registered devices to support any additional endpo execution environment, the user context, or the resource utilization).</li>
ints (see <xref target="terminology"/>). The only additional requirements for re </ol>
gistered devices are a request/response interaction with the AS to access and po <t>As discussed in <xref section="6.1" sectionFormat="of" target="RFC9200"
ssibly subscribe to the TRL (see <xref target="sec-overview"/>), and the lightwe />, only client-initiated revocation is currently specified <xref target="RFC700
ight computation of hash values to use as access token identifiers (see <xref ta 9"/> for OAuth 2.0 <xref target="RFC6749"/>, based on the assumption that access
rget="sec-token-name"/>).</t> tokens in OAuth are issued with a relatively short lifetime. However, this is n
ot expected to be the case for constrained, intermittently connected devices tha
t need access tokens with relatively long lifetimes.</t>
<!--[rfced] Were we to expand this abbreviation, this text might be
redundant. Please let us know if/how to update.
Original:
...used in the ACE framework for Authentication and Authorization.
As expanded, this reads as:
...used in the Authentication and Authorization for Constrained
Environments framework for Authentication and Authorization.
Original:
... described in the ACE framework for Authentication and Authorization [RFC9200
]...
-->
<t>This document specifies a method for allowing registered devices to acc
ess and possibly subscribe to a Token Revocation List (TRL) on the AS in order t
o obtain updated information about pertaining access tokens that were revoked pr
ior to their expiration. As specified in this document, the registered devices u
se the Constrained Application Protocol (CoAP) <xref target="RFC7252"/> to commu
nicate with the AS and with one another and can subscribe to the TRL on the AS b
y using resource observation for CoAP <xref target="RFC7641"/>. Underlying proto
cols other than CoAP are not prohibited from being supported in the future, if t
hey are defined to be used in the ACE framework for Authentication and Authoriza
tion.</t>
<t>Unlike in the case of token introspection (see <xref section="5.9" sect
ionFormat="of" target="RFC9200"/>), a registered device does not provide an owne
d access token to the AS for inquiring about its current state. Instead, registe
red devices simply obtain updated information about pertaining access tokens tha
t were revoked prior to their expiration as efficiently identified by correspond
ing hash values.</t>
<t>The benefits of this method are that it complements token introspection
and does not require the registered devices to support any additional endpoints
(see <xref target="terminology"/>). The only additional requirements for regist
ered devices are a request/response interaction with the AS to access and possib
ly subscribe to the TRL (see <xref target="sec-overview"/>) and the lightweight
computation of hash values to use as access token identifiers (see <xref target=
"sec-token-name"/>).</t>
<!--[rfced] Please confirm that our suggested edit captures your
intent.
Original:
It is also out of scope the method by which the AS determines or is
notified of revoked access tokens, according to which the AS
consequently updates the TRL as specified in this document.
Perhaps:
The method by which the AS determines or is notified of revoked access
tokens, according to which the AS consequently updates the TRL as
specified in this document, is also out of scope.
-->
<t>The process by which access tokens are declared revoked is out of the s cope of this document. It is also out of scope the method by which the AS determ ines or is notified of revoked access tokens, according to which the AS conseque ntly updates the TRL as specified in this document.</t> <t>The process by which access tokens are declared revoked is out of the s cope of this document. It is also out of scope the method by which the AS determ ines or is notified of revoked access tokens, according to which the AS conseque ntly updates the TRL as specified in this document.</t>
<section anchor="terminology"> <section anchor="terminology">
<name>Terminology</name> <name>Terminology</name>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp 14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp 14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i nterpreted as "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i nterpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.</t> appear in all capitals, as shown here.</t>
<t>Readers are expected to be familiar with the terms and concepts descr ibed in the ACE framework for Authentication and Authorization <xref target="RFC 9200"/>, as well as with terms and concepts related to CBOR Web Tokens (CWTs) <x ref target="RFC8392"/> and JSON Web Tokens (JWTs) <xref target="RFC7519"/>.</t> <t>Readers are expected to be familiar with the terms and concepts descr ibed in the ACE framework for Authentication and Authorization <xref target="RFC 9200"/>, as well as with terms and concepts related to CBOR Web Tokens (CWTs) <x ref target="RFC8392"/> and JSON Web Tokens (JWTs) <xref target="RFC7519"/>.</t>
<t>The terminology for entities in the considered architecture is define d in OAuth 2.0 <xref target="RFC6749"/>. In particular, this includes client, re source server (RS), and authorization server (AS).</t> <t>The terminology for entities in the considered architecture is define d in OAuth 2.0 <xref target="RFC6749"/>. In particular, this includes client, re source server (RS), and authorization server (AS).</t>
<t>Readers are also expected to be familiar with the terms and concepts <t>Readers are also expected to be familiar with the terms and concepts
related to CDDL <xref target="RFC8610"/>, CBOR <xref target="RFC8949"/>, JSON <x related to the Concise Data Definition Language (CDDL) <xref target="RFC8610"/>,
ref target="RFC8259"/>, COSE <xref target="RFC9052"/>, CoAP <xref target="RFC725 Concise Binary Object Representation (CBOR) <xref target="RFC8949"/>, JSON <xre
2"/>, CoAP Observe <xref target="RFC7641"/>, and the use of hash functions to na f target="RFC8259"/>, CBOR Object Signing and Encryption (COSE) <xref target="RF
me objects as defined in <xref target="RFC6920"/>.</t> C9052"/>, CoAP <xref target="RFC7252"/>, CoAP Observe <xref target="RFC7641"/>,
and the use of hash functions to name objects as defined in <xref target="RFC692
0"/>.</t>
<!--[rfced] In the following, should a reference to RFC 7252 be added
for the direct quote? This is the first occurrence of this text
in an RFC.
Original:
This document does not use the CoAP definition of "endpoint", which is
"An entity participating in the CoAP protocol."
Perhaps:
This document does not use the CoAP definition of "endpoint", which is
defined in [RFC7252] as "An entity participating in the CoAP protocol."
-->
<t>Note that the term "endpoint" is used here following its OAuth defini tion <xref target="RFC6749"/>, aimed at denoting resources such as /token and /i ntrospect at the AS, and /authz-info at the RS. This document does not use the C oAP definition of "endpoint", which is "An entity participating in the CoAP prot ocol."</t> <t>Note that the term "endpoint" is used here following its OAuth defini tion <xref target="RFC6749"/>, aimed at denoting resources such as /token and /i ntrospect at the AS, and /authz-info at the RS. This document does not use the C oAP definition of "endpoint", which is "An entity participating in the CoAP prot ocol."</t>
<t>This specification also refers to the following terminology.</t> <t>This specification also uses the following terminology:</t>
<ul spacing="normal"> <dl spacing="normal">
<li> <dt>Token hash:</dt><dd>identifier of an access token, in binary
<t>Token hash: identifier of an access token, in binary format encod format encoding. The token hash has no relation to other access
ing. The token hash has no relation to other access token identifiers possibly u token identifiers possibly used, such as the 'cti' (CWT ID) claim
sed, such as the 'cti' (CWT ID) claim of CBOR Web Tokens (CWTs) <xref target="RF of CBOR Web Tokens (CWTs) <xref target="RFC8392"/>.</dd>
C8392"/>.</t>
</li> <dt>Token Revocation List (TRL):</dt><dd>a collection of token
<li> hashes such that the corresponding access tokens have been revoked
<t>Token Revocation List (TRL): a collection of token hashes such th but are not expired yet.</dd>
at the corresponding access tokens have been revoked but are not expired yet.</t
> <dt>TRL endpoint:</dt><dd>an endpoint at the AS with a TRL as its
</li> representation. The default name of the TRL endpoint in a url-path
<li> is '/revoke/trl'. Implementations are not required to use this
<t>TRL endpoint: an endpoint at the AS with a TRL as its representat name and can define their own instead.</dd>
ion. The default name of the TRL endpoint in a url-path is '/revoke/trl'. Implem
entations are not required to use this name, and can define their own instead.</ <dt>Registered device:</dt><dd>a device registered at the AS,
t> i.e., as a client, an RS, or both. A registered device acts as
</li> a requester towards the TRL endpoint.</dd>
<li>
<t>Registered device: a device registered at the AS, i.e., as a clie <dt>Administrator:</dt><dd><t>an entity that is authorized to get fu
nt, or an RS, or both. A registered device acts as a requester towards the TRL e ll access
ndpoint.</t> to the TRL at the AS and that acts as a requester towards the TRL
</li> endpoint. An administrator is not necessarily a registered device
<li> as defined above, i.e., a client requesting access tokens or an RS
<t>Administrator: entity authorized to get full access to the TRL at consuming access tokens. </t>
the AS, and acting as a requester towards the TRL endpoint. An administrator is <t>An administrator might also be authorized to perform further
not necessarily a registered device as defined above, i.e., a client requesting administrative operations at the AS, e.g., through a dedicated
access tokens or an RS consuming access tokens. </t> admin interface that is out of the scope of this document. By
<t> considering the token hashes retrieved from the TRL together with
An administrator might also be authorized to perform further administrative oper other information obtained from the AS, the administrator becomes
ations at the AS, e.g., through a dedicated admin interface that is out of the s able to derive additional information, e.g., the fact that
cope of this document. By considering the token hashes retrieved from the TRL to accesses have been revoked for specific registered devices.</t></dd>
gether with other information obtained from the AS, the administrator becomes ab
le to derive additional information, e.g., the fact that accesses have been revo <dt>Pertaining access token:</dt>
ked for specific registered devices.</t> <dd>
</li> <ul spacing="normal">
<li> <li><t>With reference to an administrator, an access token
<t>Pertaining access token: </t> issued by the AS.</t></li>
<ul spacing="normal"> <li><t>With reference to a registered device, an access token
<li> intended to be owned by that device. An access token pertains
<t>With reference to an administrator, an access token issued by to a client if the AS has issued the access token for that
the AS.</t> client following its request. An access token pertains to an
</li> RS if the AS has issued the access token to be consumed by
<li> that RS.</t>
<t>With reference to a registered device, an access token intend </li>
ed to be owned by that device. An access token pertains to a client if the AS ha </ul>
s issued the access token for that client following its request. An access token </dd>
pertains to an RS if the AS has issued the access token to be consumed by that
RS.</t> <dt>Token hash pertaining to a requester:</dt><dd>a token hash
</li> corresponding to an access token pertaining to that requester,
</ul> i.e., an administrator or a registered device.</dd>
</li>
<li> <dt>TRL update pertaining to a requester:</dt><dd>an update to the
<t>Token hash pertaining to a requester: a token hash corresponding TRL through which token hashes pertaining to that requester have
to an access token pertaining to that requester, i.e., an administrator or a reg been added to or removed from the TRL.</dd>
istered device.</t>
</li> <dt>Full query:</dt><dd>a type of query to the TRL where the AS
<li> returns the token hashes of the revoked access tokens currently in
<t>TRL update pertaining to a requester: an update to the TRL throug the TRL and pertaining to the requester. Further details are
h which token hashes pertaining to that requester have been added to the TRL or specified in Sections <xref target="sec-trl-endpoint" format="counte
removed from the TRL.</t> r"/> and <xref
</li> target="ssec-trl-full-query" format="counter"/>.</dd>
<li>
<t>Full query: a type of query to the TRL, where the AS returns the <dt>Diff query:</dt><dd>a type of query to the TRL where the AS
token hashes of the revoked access tokens currently in the TRL and pertaining to returns a list of diff entries, each related to one update
the requester. Further details are specified in <xref target="sec-trl-endpoint" to the TRL and containing a set of token hashes
/> and <xref target="ssec-trl-full-query"/>.</t> pertaining to the requester. Further details are specified in
</li> Sections <xref target="sec-trl-endpoint" format="counter"/> and <xre
<li> f
<t>Diff query: a type of query to the TRL, where the AS returns a li target="ssec-trl-diff-query" format="counter"/>.</dd>
st of diff entries, each related to one update occurred to the TRL and containin </dl>
g a set of token hashes pertaining to the requester. Further details are specifi
ed in <xref target="sec-trl-endpoint"/> and <xref target="ssec-trl-diff-query"/>
.</t>
</li>
</ul>
<t>Examples throughout this document are expressed in CBOR diagnostic no tation as defined in <xref section="8" sectionFormat="of" target="RFC8949"/> and <xref section="G" sectionFormat="of" target="RFC8610"/>. Diagnostic notation co mments are often used to provide a textual representation of the numeric paramet er names and values.</t> <t>Examples throughout this document are expressed in CBOR diagnostic no tation as defined in <xref section="8" sectionFormat="of" target="RFC8949"/> and <xref section="G" sectionFormat="of" target="RFC8610"/>. Diagnostic notation co mments are often used to provide a textual representation of the numeric paramet er names and values.</t>
<t>In the CBOR diagnostic notation used in this document, constructs of the form e'SOME_NAME' are replaced by the value assigned to SOME_NAME in the CDD L model shown in <xref target="fig-cddl-model"/> of <xref target="sec-cddl-model "/>. For example, {e'full_set': [], e'cursor': 3} stands for {0: [], 2: 3}.</t> <t>In the CBOR diagnostic notation used in this document, constructs of the form e'SOME_NAME' are replaced by the value assigned to SOME_NAME in the CDD L model shown in <xref target="fig-cddl-model"/> of <xref target="sec-cddl-model "/>. For example, {e'full_set': [], e'cursor': 3} stands for {0: [], 2: 3}.</t>
<t>Note to RFC Editor: Please delete the paragraph immediately preceding this note. Also, in the CBOR diagnostic notation used in this document, please replace the constructs of the form e'SOME_NAME' with the value assigned to SOME_ NAME in the CDDL model shown in <xref target="fig-cddl-model"/> of <xref target= "sec-cddl-model"/>. Finally, please delete this note.</t> <t>Note to RFC Editor: Please delete the paragraph immediately preceding this note. Also, in the CBOR diagnostic notation used in this document, please replace the constructs of the form e'SOME_NAME' with the value assigned to SOME_ NAME in the CDDL model shown in <xref target="fig-cddl-model"/> of <xref target= "sec-cddl-model"/>. Finally, please delete this note.</t>
</section> </section>
</section> </section>
<section anchor="sec-overview"> <section anchor="sec-overview">
<name>Protocol Overview</name> <name>Protocol Overview</name>
<t>This protocol defines how a CoAP-based authorization server informs cli ents and resource servers, i.e., registered devices, about pertaining revoked ac cess tokens. How the relationship between a registered device and the AS is esta blished is out of the scope of this specification.</t> <t>This protocol defines how a CoAP-based authorization server informs cli ents and resource servers, i.e., registered devices, about pertaining revoked ac cess tokens. How the relationship between a registered device and the AS is esta blished is out of the scope of this specification.</t>
<t>At a high level, the steps of this protocol are as follows.</t> <t>At a high level, the steps of this protocol are as follows:</t>
<ul spacing="normal"> <ol spacing="normal">
<li> <li>
<t>Upon startup, the AS creates a single TRL accessible through the TR L endpoint. At any point in time, the TRL represents the list of all revoked acc ess tokens issued by the AS that are not expired yet.</t> <t>Upon startup, the AS creates a single TRL accessible through the TR L endpoint. At any point in time, the TRL represents the list of all revoked acc ess tokens issued by the AS that are not expired yet.</t>
</li> </li>
<li> <li>
<t>When a device registers at the AS, it also receives the url-path to the TRL endpoint. </t> <t>When a device registers at the AS, it also receives the url-path to the TRL endpoint. </t>
<t> <t>
At any time after the registration procedure is finished, the registered device At any time after the registration procedure is finished, the registered device
can send a GET request to the TRL endpoint at the AS. When doing so, it can requ can send a GET request to the TRL endpoint at the AS. When doing so, it can requ
est for: the current list of pertaining revoked access tokens (see <xref target= est the following: the current list of pertaining revoked access tokens (see <xr
"ssec-trl-full-query"/>); or the most recent updates that occurred over the list ef target="ssec-trl-full-query"/>) or the most recent updates that occurred over
of pertaining revoked access tokens (see <xref target="ssec-trl-diff-query"/>). the list of pertaining revoked access tokens (see <xref target="ssec-trl-diff-q
</t> uery"/>). </t>
<t> <t>
<!--[rfced] Does the following rephrase capture your intended meaning?
Original:
By doing so, the registered device effectively subscribes to the TRL,
as interested in receiving notifications about its update.
Perhaps:
By doing so, the registered device effectively subscribes to the TRL,
as the device is interested in receiving notifications about the TRL's
update.
-->
In particular, the registered device can rely on Observation for CoAP <xref targ et="RFC7641"/>. In such a case, the GET request sent to the TRL endpoint include s the CoAP Observe Option set to 0 (register), i.e., it is an Observation Reques t. By doing so, the registered device effectively subscribes to the TRL, as inte rested in receiving notifications about its update. Upon receiving the Observati on Request, the AS adds the registered device to the list of observers of the TR L endpoint.</t> In particular, the registered device can rely on Observation for CoAP <xref targ et="RFC7641"/>. In such a case, the GET request sent to the TRL endpoint include s the CoAP Observe Option set to 0 (register), i.e., it is an Observation Reques t. By doing so, the registered device effectively subscribes to the TRL, as inte rested in receiving notifications about its update. Upon receiving the Observati on Request, the AS adds the registered device to the list of observers of the TR L endpoint.</t>
</li> </li>
<li> <li>
<t>When an access token is revoked, the AS adds the corresponding toke n hash to the TRL. Also, when a revoked access token eventually expires, the AS removes the corresponding token hash from the TRL. </t> <t>When an access token is revoked, the AS adds the corresponding toke n hash to the TRL. Also, when a revoked access token eventually expires, the AS removes the corresponding token hash from the TRL. </t>
<t> <t>
<!--[rfced] We are unable to parse "and to which the access token
pertains". Please rephrase.
Original:
That is, an Observe notification is sent to each registered device
subscribed to the TRL and to which the access token pertains.
-->
In either case, after updating the TRL, the AS sends Observe notifications as pe r <xref target="RFC7641"/>. That is, an Observe notification is sent to each reg istered device subscribed to the TRL and to which the access token pertains. </ t> In either case, after updating the TRL, the AS sends Observe notifications as pe r <xref target="RFC7641"/>. That is, an Observe notification is sent to each reg istered device subscribed to the TRL and to which the access token pertains. </ t>
<t>
<!--[rfced] Please review the addition of "either" and let us know if
this edit correctly captures your intent.
Original:
Depending on the specific subscription established through the
Observation Request, the notification provides the current
updated list of revoked access tokens in the subset of the TRL
pertaining to that device (see Section 7), or the most recent TRL
updates occurred over that list of pertaining revoked access
tokens (see Section 8).
Perhaps:
Depending on the specific subscription established through the
Observation Request, the notification provides either the current
updated list of revoked access tokens in the subset of the TRL
pertaining to that device (see Section 7) or the most recent TRL
updates that occurred over that list of pertaining revoked access
tokens (see Section 8).
-->
Depending on the specific subscription established through the Observation Reque
st, the notification provides the current updated list of revoked access tokens
in the subset of the TRL pertaining to that device (see <xref target="ssec-trl-f
ull-query"/>), or the most recent TRL updates that occurred over that list of pe
rtaining revoked access tokens (see <xref target="ssec-trl-diff-query"/>). </t>
<t> <t>
Depending on the specific subscription established through the Observation Reque Further Observe notifications may be sent, consistent with ongoing additional ob
st, the notification provides the current updated list of revoked access tokens servations of the TRL endpoint.</t>
in the subset of the TRL pertaining to that device (see <xref target="ssec-trl-f
ull-query"/>), or the most recent TRL updates occurred over that list of pertain
ing revoked access tokens (see <xref target="ssec-trl-diff-query"/>). </t>
<t>
Further Observe notifications may be sent, consistently with ongoing additional
observations of the TRL endpoint.</t>
</li> </li>
<li> <li>
<t>An administrator can access and subscribe to the TRL like a registe red device, while getting the content of the whole TRL (see <xref target="ssec-t rl-full-query"/>) or the most recent updates occurred to the whole TRL (see <xre f target="ssec-trl-diff-query"/>).</t> <t>An administrator can access and subscribe to the TRL like a registe red device while getting the content of the whole TRL (see <xref target="ssec-tr l-full-query"/>) or the most recent updates to the whole TRL (see <xref target=" ssec-trl-diff-query"/>).</t>
</li> </li>
</ul> </ol>
<t><xref target="fig-protocol-overview"/> shows a high-level overview of t <t><xref target="fig-protocol-overview"/> shows a high-level overview of t
he service provided by this protocol. For the sake of simplicity, the example sh he service provided by this protocol. For the sake of simplicity, the example sh
own in the figure considers the simultaneous revocation of the three access toke own in the figure considers the simultaneous revocation of the three access toke
ns t1, t2, and t3, whose corresponding token hashes are th1, th2, and th3, respe ns t1, t2, and t3 whose corresponding token hashes are th1, th2, and th3, respec
ctively. Consequently, the AS adds the three token hashes to the TRL at once, an tively. Consequently, the AS adds the three token hashes to the TRL at once and
d sends Observe notifications to one administrator and four registered devices. sends Observe notifications to one administrator and four registered devices. Ea
Each dotted line associated with a pair of registered devices indicates the acce ch dotted line associated with a pair of registered devices indicates the access
ss token that they both own.</t> token that they both own.</t>
<figure anchor="fig-protocol-overview"> <figure anchor="fig-protocol-overview">
<name>Protocol Overview</name> <name>Protocol Overview</name>
<artset> <artset>
<artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2000/ svg" version="1.1" height="320" width="560" viewBox="0 0 560 320" 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="320" width="560" viewBox="0 0 560 320" class="diagram " text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap=" round">
<path d="M 8,176 L 8,224" fill="none" stroke="black"/> <path d="M 8,176 L 8,224" fill="none" stroke="black"/>
<path d="M 16,112 L 16,168" fill="none" stroke="black"/> <path d="M 16,112 L 16,168" fill="none" stroke="black"/>
<path d="M 136,176 L 136,224" fill="none" stroke="black"/> <path d="M 136,176 L 136,224" fill="none" stroke="black"/>
<path d="M 152,176 L 152,224" fill="none" stroke="black"/> <path d="M 152,176 L 152,224" fill="none" stroke="black"/>
<path d="M 160,112 L 160,168" fill="none" stroke="black"/> <path d="M 160,112 L 160,168" fill="none" stroke="black"/>
<path d="M 168,32 L 168,64" fill="none" stroke="black"/> <path d="M 168,32 L 168,64" fill="none" stroke="black"/>
skipping to change at line 291 skipping to change at line 431
: :........: :............: : : :........: :............: :
: t2 : : t2 :
:...........................................: :...........................................:
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
<t><xref target="sec-RS-examples"/> provides examples of the protocol flow and message exchanges between the AS and a registered device.</t> <t><xref target="sec-RS-examples"/> provides examples of the protocol flow and message exchanges between the AS and a registered device.</t>
</section> </section>
<section anchor="sec-issuing-access-tokens-as"> <section anchor="sec-issuing-access-tokens-as">
<name>Issuing of Access Tokens at the AS</name> <name>Issuing of Access Tokens at the AS</name>
<t>An AS that supports the method defined in this document <bcp14>MUST</bc p14> adhere to the following rules when issuing an access token.</t> <t>An AS that supports the method defined in this document <bcp14>MUST</bc p14> adhere to the following rules when issuing an access token:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>All the intended header parameters in the access token <bcp14>MUST< /bcp14> be specified within integrity-protected fields.</t> <t>All the intended header parameters in the access token <bcp14>MUST< /bcp14> be specified within integrity-protected fields.</t>
</li> </li>
<li> <li>
<t>If the access token is a CWT, the following applies. </t> <t>If the access token is a CWT, the following applies: </t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Any "unprotected" field <bcp14>MUST</bcp14> be empty, i.e., its value <bcp14>MUST</bcp14> be encoded as the empty CBOR map (0xa0). This applies to: the top-level "unprotected" field of the COSE object used for the CWT; the "unprotected" field of each element of the "signatures" array; and the "unprotec ted" field of each element of any "recipients" array (see Sections <xref target= "RFC9052" section="2" sectionFormat="bare"/>, <xref target="RFC9052" section="3" sectionFormat="bare"/>, <xref target="RFC9052" section="4" sectionFormat="bare" />, <xref target="RFC9052" section="5" sectionFormat="bare"/>, and <xref target= "RFC9052" section="6" sectionFormat="bare"/> of <xref target="RFC9052"/>).</t> <t>Any "unprotected" field <bcp14>MUST</bcp14> be empty, i.e., its value <bcp14>MUST</bcp14> be encoded as the empty CBOR map (0xa0). This applies to the top-level "unprotected" field of the COSE object used for the CWT, the " unprotected" field of each element of the "signatures" array, and the "unprotect ed" field of each element of any "recipients" array (see Sections <xref target=" RFC9052" section="2" sectionFormat="bare"/>, <xref target="RFC9052" section="3" sectionFormat="bare"/>, <xref target="RFC9052" section="4" sectionFormat="bare"/ >, <xref target="RFC9052" section="5" sectionFormat="bare"/>, and <xref target=" RFC9052" section="6" sectionFormat="bare"/> of <xref target="RFC9052"/>).</t>
</li> </li>
<li> <li>
<!--[rfced] We noticed repetition of the word "tag" in the following
sentence. Does this rephrase correctly capture your intent?
Original:
In turn, the resulting tagged data item MUST be tagged by using
the CWT CBOR tag with tag number 61 (see Section 6 of
[RFC8392]).
Perhaps:
In turn, the resulting data item MUST be tagged using
CWT CBOR tag number 61 (see Section 6 of [RFC8392]).
-->
<t>Consistent with the specific COSE object used for the CWT, the corresponding tagged structure in the set COSE_Tagged_Message <bcp14>MUST</bcp14 > be used (see <xref section="2" sectionFormat="of" target="RFC9052"/>). That is , the CBOR array that encodes the CWT <bcp14>MUST</bcp14> be tagged by using the COSE CBOR tag corresponding to the used COSE object. Table 1 in <xref section=" 2" sectionFormat="of" target="RFC9052"/> specifies the tag numbers in question. </t> <t>Consistent with the specific COSE object used for the CWT, the corresponding tagged structure in the set COSE_Tagged_Message <bcp14>MUST</bcp14 > be used (see <xref section="2" sectionFormat="of" target="RFC9052"/>). That is , the CBOR array that encodes the CWT <bcp14>MUST</bcp14> be tagged by using the COSE CBOR tag corresponding to the used COSE object. Table 1 in <xref section=" 2" sectionFormat="of" target="RFC9052"/> specifies the tag numbers in question. </t>
<t> <t>
In turn, the resulting tagged data item <bcp14>MUST</bcp14> be tagged by using t he CWT CBOR tag with tag number 61 (see <xref section="6" sectionFormat="of" tar get="RFC8392"/>). After that, the resulting data item <bcp14>MUST NOT</bcp14> be further tagged. </t> In turn, the resulting tagged data item <bcp14>MUST</bcp14> be tagged by using t he CWT CBOR tag with tag number 61 (see <xref section="6" sectionFormat="of" tar get="RFC8392"/>). After that, the resulting data item <bcp14>MUST NOT</bcp14> be further tagged. </t>
<t> <t>
Encoding of the tag numbers <bcp14>MUST</bcp14> be done using definite lengths, and the length of the encoded tag numbers <bcp14>MUST</bcp14> be the minimum pos sible length. This means that the tag number 16 is encoded as 0xd0 and not as 0x d810. </t> Encoding of the tag numbers <bcp14>MUST</bcp14> be done using definite lengths, and the length of the encoded tag numbers <bcp14>MUST</bcp14> be the minimum pos sible length. This means that tag number 16 is encoded as 0xd0 and not as 0xd810 . </t>
<t> <t>
The example in <xref target="fig-cwt-cose-encrypt0"/> shows a CWT that uses the COSE object COSE_Encrypt0 (see <xref section="5.2" sectionFormat="of" target="RF C9052"/>).</t> The example in <xref target="fig-cwt-cose-encrypt0"/> shows a CWT that uses the COSE object COSE_Encrypt0 (see <xref section="5.2" sectionFormat="of" target="RF C9052"/>).</t>
</li> </li>
</ul> </ul>
</li> </li>
<li> <li>
<t>If, like for JWTs <xref target="RFC7519"/>, the access token relies on a JSON object for encoding its claims, the following applies. </t> <t>If, like for JWTs <xref target="RFC7519"/>, the access token relies on a JSON object for encoding its claims, the following applies: </t>
<t> <t>
Consistent with the ACE framework <xref target="RFC9200"/>, this document specif ically considers JWTs, which are always represented using the JWS Compact Serial ization from <xref target="RFC7515"/> or the JWE Compact Serialization from <xre f target="RFC7516"/>. Consequently, all the header parameters are specified with in integrity-protected fields. </t> Consistent with the ACE framework for Authentication and Authorization <xref tar get="RFC9200"/>, this document specifically considers JWTs, which are always rep resented using the JSON Web Signature (JWS) Compact Serialization from <xref ta rget="RFC7515"/> or the JSON Web Encryption (JWE) Compact Serialization from <xr ef target="RFC7516"/>. Consequently, all the header parameters are specified wit hin integrity-protected fields. </t>
<t> <t>
In case alternative access tokens were used, the following applies: </t> In case alternative access tokens were used, the following applies: </t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>If the access token uses the JWS JSON Serialization from <xref target="RFC7515"/>, it <bcp14>MUST NOT</bcp14> include the JWS Unprotected Heade r.</t> <t>If the access token uses the JWS Compact Serialization from <xr ef target="RFC7515"/>, it <bcp14>MUST NOT</bcp14> include the JWS Unprotected He ader.</t>
</li> </li>
<li> <li>
<t>If the access token uses the JWE JSON Serialization from <xref target="RFC7516"/>, it <bcp14>MUST NOT</bcp14> include the JWE Shared Unprotecte d Header and it <bcp14>MUST NOT</bcp14> include the "header" member in any of th e elements of the "recipients" array.</t> <t>If the access token uses the JWE Compact Serialization from <xr ef target="RFC7516"/>, it <bcp14>MUST NOT</bcp14> include the JWE Shared Unprote cted Header and it <bcp14>MUST NOT</bcp14> include the "header" member in any of the elements of the "recipients" array.</t>
</li> </li>
</ul> </ul>
</li> </li>
</ul> </ul>
<figure anchor="fig-cwt-cose-encrypt0"> <figure anchor="fig-cwt-cose-encrypt0">
<name>Example of CWT Using COSE_Encrypt0</name> <name>Example of CWT Using COSE_Encrypt0</name>
<artwork align="left"><![CDATA[ <sourcecode><![CDATA[
/ CWT CBOR tag / 61( / CWT CBOR tag / 61(
/ COSE_Encrypt0 CBOR tag / 16( / COSE_Encrypt0 CBOR tag / 16(
/ COSE_Encrypt0 object / [ / COSE_Encrypt0 object / [
/ protected / h'a3010a044c53796d6d65747269633132 / protected / h'a3010a044c53796d6d65747269633132
38054d99a0d7846e762c49ffe8a63e0b', 38054d99a0d7846e762c49ffe8a63e0b',
/ unprotected / {}, / unprotected / {},
/ ciphertext / h'b918a11fd81e438b7f973d9e2e119bcb / ciphertext / h'b918a11fd81e438b7f973d9e2e119bcb
22424ba0f38a80f27562f400ee1d0d6c 22424ba0f38a80f27562f400ee1d0d6c
0fdb559c02421fd384fc2ebe22d70713 0fdb559c02421fd384fc2ebe22d70713
78b0ea7428fff157444d45f7e6afcda1 78b0ea7428fff157444d45f7e6afcda1
aae5f6495830c58627087fc5b4974f31 aae5f6495830c58627087fc5b4974f31
9a8707a635dd643b' 9a8707a635dd643b'
] ]
) )
) )
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t><xref target="sec-seccons-token-manipulation"/> discusses how adhering to the rules above neutralizes an attack against the RS, where an active adversa ry can induce the RS to compute a token hash different from the correct one.</t> <t><xref target="sec-seccons-token-manipulation"/> discusses how adhering to the rules above neutralizes an attack against the RS where an active adversar y can induce the RS to compute a token hash different from the correct one.</t>
</section> </section>
<section anchor="sec-token-name"> <section anchor="sec-token-name">
<!--[rfced] Much of Section 4 describes terminology. Should a pointer
to this section be added to the Terminology section?
Perhaps:
See Section 4 for further terminology used throughout that section.
-->
<name>Token Hash</name> <name>Token Hash</name>
<t>This section specifies how token hashes are computed.</t> <t>This section specifies how token hashes are computed.</t>
<t>First, <xref target="sec-token-hash-input-motivation"/> provides the mo tivation for the used construction.</t> <t>First, <xref target="sec-token-hash-input-motivation"/> provides the mo tivation for the used construction.</t>
<t>Building on that, the value used as input to compute a token hash is de <t>Building on that, the value used as input to compute a token hash is de
fined in <xref target="sec-token-hash-input-c-as"/> for the client and the AS, a fined in <xref target="sec-token-hash-input-c-as"/> for the client and the AS an
nd in <xref target="sec-token-hash-input-rs"/> for the RS. Finally, <xref target d in <xref target="sec-token-hash-input-rs"/> for the RS. Finally, <xref target=
="sec-token-hash-output"/> defines how such an input is used for computing the t "sec-token-hash-output"/> defines how such an input is used for computing the to
oken hash.</t> ken hash.</t>
<t>The process outlined below refers to the base64url encoding and decodin <t>The process outlined below refers to the base64url encoding and decodin
g without padding (see <xref section="5" sectionFormat="of" target="RFC4648"/>), g without padding (see <xref section="5" sectionFormat="of" target="RFC4648"/>)
and denotes as "binary representation" of a text string the corresponding UTF-8 and denotes as "binary representation" of a text string the corresponding UTF-8
encoding <xref target="RFC3629"/>, which is the implied charset used in JSON (s encoding <xref target="RFC3629"/>, which is the implied charset used in JSON (se
ee <xref section="8.1" sectionFormat="of" target="RFC8259"/>).</t> e <xref section="8.1" sectionFormat="of" target="RFC8259"/>).</t>
<t>Consistent with <xref section="3.4" sectionFormat="of" target="RFC8949" />, the term "tag" is used for the entire CBOR data item consisting of both a ta g number and the tag content: the tag content is the CBOR data item that is bein g tagged.</t> <t>Consistent with <xref section="3.4" sectionFormat="of" target="RFC8949" />, the term "tag" is used for the entire CBOR data item consisting of both a ta g number and the tag content: the tag content is the CBOR data item that is bein g tagged.</t>
<t>Also, "tagged access token" is used to denote nested CBOR tags (possibl y a single one), with the innermost tag content being a CWT.</t> <t>Also, "tagged access token" is used to denote nested CBOR tags (possibl y a single one), with the innermost tag content being a CWT.</t>
<section anchor="sec-token-hash-input-motivation"> <section anchor="sec-token-hash-input-motivation">
<name>Motivation for the Used Construction</name> <name>Motivation for the Used Construction</name>
<t>An access token can have one among different formats. The most expect
ed formats are CWT <xref target="RFC8392"/> and JWT <xref target="RFC7519"/>, wi <!--[rfced] Does this rephrase capture your intended meaning?
th the former being the default format to use in the ACE framework (see <xref se
ction="3" sectionFormat="of" target="RFC9200"/>). While access tokens are opaque Original:
to clients, an RS is aware of whether access tokens that are issued for it to c An access token can have one among different formats.
onsume are either CWTs or JWTs.</t>
Perhaps:
There are different formats an access token can have.
-->
<t>An access token can have one among different formats. The most expect
ed formats are CWT <xref target="RFC8392"/> and JWT <xref target="RFC7519"/>, wi
th the former being the default format to use in the ACE framework for Authentic
ation and Authorization (see <xref section="3" sectionFormat="of" target="RFC920
0"/>). While access tokens are opaque to clients, an RS is aware of whether acce
ss tokens that are issued for it to consume are either CWTs or JWTs.</t>
<section anchor="issuing-of-the-access-token-to-the-client"> <section anchor="issuing-of-the-access-token-to-the-client">
<name>Issuing of the Access Token to the Client</name> <name>Issuing of the Access Token to the Client</name>
<t>There are two possible encodings that the AS can use for the AS-to- Client response (see <xref section="5.8.2" sectionFormat="of" target="RFC9200"/> ), where the issued access token is included and provided to the requester clien t. The RS may not be aware of which encoding is used for that response to that p articular requester client.</t> <t>There are two possible encodings that the AS can use for the AS-to- Client response (see <xref section="5.8.2" sectionFormat="of" target="RFC9200"/> ) where the issued access token is included and provided to the requester client . The RS may not be aware of which encoding is used for that response to that pa rticular requester client.</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>One way relies on CBOR, which is required if CoAP is used (see <!--[rfced] We note that the sub-bullets in Section 4.1.1 reverse
<xref section="5" sectionFormat="of" target="RFC9200"/>) and is recommended othe order (i.e., the first bullet has CWT and then JWT mentioned in
rwise (see <xref section="3" sectionFormat="of" target="RFC9200"/>). That is, th the sub-bullets and the second bullet lists JWT and then CWT in
e AS-to-Client response has media-type "application/ace+cbor". </t> the sub-bullets). Please confirm that this is intentional or let
us know if you'd like them to appear in the same order in both
places.-->
<t>One method of encoding relies on CBOR, which is required if CoA
P is used (see <xref section="5" sectionFormat="of" target="RFC9200"/>) and is r
ecommended otherwise (see <xref section="3" sectionFormat="of" target="RFC9200"/
>). That is, the AS-to-Client response has media-type "application/ace+cbor". <
/t>
<t> <t>
This implies that, within the CBOR map specified as message payload, the paramet er 'access_token' is a CBOR data item of type CBOR byte string and with value BY TES. In particular: </t> This implies that, within the CBOR map specified as message payload, the paramet er 'access_token' is a CBOR data item of type CBOR byte string and with a value of BYTES. In particular: </t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>If the access token is a CWT, then BYTES is the binary repr esentation of the CWT (i.e., of the CBOR array that encodes the untagged CWT) or of a tagged access token with the CWT as innermost tag content.</t> <t>If the access token is a CWT, then BYTES is the binary repr esentation of the CWT (i.e., of the CBOR array that encodes the untagged CWT) or of a tagged access token with the CWT as the innermost tag content.</t>
</li> </li>
<li> <li>
<t>If the access token is a JWT, then BYTES is the binary repr esentation of the JWT (i.e., of the text string that encodes the JWT).</t> <t>If the access token is a JWT, then BYTES is the binary repr esentation of the JWT (i.e., of the text string that encodes the JWT).</t>
</li> </li>
</ul> </ul>
</li> </li>
<li> <li>
<t>An alternative way relies on JSON. That is, the AS-to-Client re sponse has media-type "application/ace+json". </t> <t>An alternative method of encoding relies on JSON. That is, the AS-to-Client response has media-type "application/ace+json". </t>
<t> <t>
This implies that, within the JSON object specified as message payload, the para meter 'access_token' has as value a text string TEXT. In particular: </t> This implies that, within the JSON object specified as message payload, the para meter 'access_token' has as a value a text string TEXT. In particular: </t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>If the access token is a JWT, then TEXT is the text string that encodes the JWT.</t> <t>If the access token is a JWT, then TEXT is the text string that encodes the JWT.</t>
</li> </li>
<li> <li>
<t>If the access token is a CWT, then TEXT is the base64url-en coded text string of BYTES, which is the binary representation of the CWT (i.e., of the CBOR array that encodes the untagged CWT) or of a tagged access token wi th the CWT as innermost tag content.</t> <t>If the access token is a CWT, then TEXT is the base64url-en coded text string of BYTES, which is the binary representation of the CWT (i.e., of the CBOR array that encodes the untagged CWT) or of a tagged access token wi th the CWT as the innermost tag content.</t>
</li> </li>
</ul> </ul>
</li> </li>
</ul> </ul>
</section> </section>
<section anchor="sec-token-hash-input-motivation-rs"> <section anchor="sec-token-hash-input-motivation-rs">
<name>Provisioning of Access Tokens to the RS</name> <name>Provisioning of Access Tokens to the RS</name>
<t>In accordance with the used transport profile of ACE (e.g., <xref t arget="RFC9202"/>, <xref target="RFC9203"/>, <xref target="RFC9431"/>), the RS r eceives a piece of token-related information hereafter denoted as TOKEN_INFO.</t > <t>In accordance with the used transport profile of ACE (e.g., <xref t arget="RFC9202"/>, <xref target="RFC9203"/>, <xref target="RFC9431"/>), the RS r eceives a piece of token-related information hereafter denoted as TOKEN_INFO.</t >
<t>In particular:</t> <t>In particular:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<!--[rfced] When "tagged" appears in parentheses, should the reader
assume this means "either tagged or not tagged"? For example:
Original:
That is, TOKEN_INFO is the binary representation of the (tagged)
access token.
Perhaps:
That is, TOKEN_INFO is the binary representation of the tagged
access token (whether or not it is tagged).
-->
<t>If the AS-to-Client response was encoded in CBOR, then TOKEN_IN FO is the value of the CBOR byte string conveyed by the 'access_token' parameter of that response. That is, TOKEN_INFO is the binary representation of the (tagg ed) access token.</t> <t>If the AS-to-Client response was encoded in CBOR, then TOKEN_IN FO is the value of the CBOR byte string conveyed by the 'access_token' parameter of that response. That is, TOKEN_INFO is the binary representation of the (tagg ed) access token.</t>
</li> </li>
<li> <li>
<t>If the AS-to-Client response was encoded in JSON and the access token is a JWT, then TOKEN_INFO is the binary representation of the text string conveyed by the 'access_token' parameter of that response. That is, TOKEN_INFO is the binary representation of the access token.</t> <t>If the AS-to-Client response was encoded in JSON and the access token is a JWT, then TOKEN_INFO is the binary representation of the text string conveyed by the 'access_token' parameter of that response. That is, TOKEN_INFO is the binary representation of the access token.</t>
</li> </li>
<li> <li>
<t>If the AS-to-Client response was encoded in JSON and the access token is a CWT, then TOKEN_INFO is the binary representation of the base64url-e ncoded text string that encodes the binary representation of the (tagged) access token. That is, TOKEN_INFO is the binary representation of the base64url-encode d text string conveyed by the 'access_token' parameter.</t> <t>If the AS-to-Client response was encoded in JSON and the access token is a CWT, then TOKEN_INFO is the binary representation of the base64url-e ncoded text string that encodes the binary representation of the (tagged) access token. That is, TOKEN_INFO is the binary representation of the base64url-encode d text string conveyed by the 'access_token' parameter.</t>
</li> </li>
</ul> </ul>
<t>The following overviews how the above specifically applies to the e xisting transport profiles of ACE.</t> <t>The following overviews how the above specifically applies to the e xisting transport profiles of ACE:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>The (tagged) access token can be uploaded to the RS by means of a POST request to the /authz-info endpoint (see <xref section="5.10.1" sectionF ormat="of" target="RFC9200"/>), using a CoAP Content-Format or HTTP media-type t hat reflects the format of the access token, if available (e.g., "application/cw t" for CWTs), or "application/octet-stream" otherwise. When doing so (e.g., like in <xref target="RFC9202"/>), TOKEN_INFO is the payload of the POST request.</t > <t>The (tagged) access token can be uploaded to the RS by means of a POST request to the /authz-info endpoint (see <xref section="5.10.1" sectionF ormat="of" target="RFC9200"/>), using a CoAP Content-Format or HTTP media-type t hat reflects the format of the access token, if available (e.g., "application/cw t" for CWTs), or "application/octet-stream" otherwise. When doing so (e.g., like in <xref target="RFC9202"/>), TOKEN_INFO is the payload of the POST request.</t >
</li> </li>
<li> <li>
<t>The (tagged) access token can be uploaded to the RS by means of a POST request to the /authz-info endpoint, using the media-type "application/a ce+cbor". When doing so (e.g., like in <xref target="RFC9203"/>), TOKEN_INFO is the value of the CBOR byte string conveyed by the 'access_token' parameter, with in the CBOR map specified as payload of the POST request.</t> <t>The (tagged) access token can be uploaded to the RS by means of a POST request to the /authz-info endpoint, using the media-type "application/a ce+cbor". When doing so (e.g., like in <xref target="RFC9203"/>), TOKEN_INFO is the value of the CBOR byte string conveyed by the 'access_token' parameter, with in the CBOR map specified as payload of the POST request.</t>
</li> </li>
<li> <li>
<t>The (tagged) access token can be uploaded to the RS during a DT LS session establishment, e.g., like it is defined in <xref section="3.2.2" sect ionFormat="of" target="RFC9202"/>. When doing so, TOKEN_INFO is the value of the 'psk_identity' field of the ClientKeyExchange message (when using DTLS 1.2 <xre f target="RFC6347"/>), or of the 'identity' field of a PSKIdentity, within the P reSharedKeyExtension of a ClientHello message (when using DTLS 1.3 <xref target= "RFC9147"/>).</t> <t>The (tagged) access token can be uploaded to the RS during a DT LS session establishment, e.g., like it is defined in <xref section="3.2.2" sect ionFormat="of" target="RFC9202"/>. When doing so, TOKEN_INFO is the value of the 'psk_identity' field of the ClientKeyExchange message (when using DTLS 1.2 <xre f target="RFC6347"/>) or of the 'identity' field of a PSKIdentity, within the Pr eSharedKeyExtension of a ClientHello message (when using DTLS 1.3 <xref target=" RFC9147"/>).</t>
</li> </li>
<li> <li>
<t>The (tagged) access token can be uploaded to the RS within the MQTT CONNECT packet, e.g., like it is defined in <xref section="2.2.4.1" section Format="of" target="RFC9431"/>. When doing so, TOKEN_INFO is specified within th e 'Authentication Data' field of the MQTT CONNECT packet, following the property identifier 22 (0x16) and the token length.</t> <t>The (tagged) access token can be uploaded to the RS within the MQTT CONNECT packet, e.g., like it is defined in <xref section="2.2.4.1" section Format="of" target="RFC9431"/>. When doing so, TOKEN_INFO is specified within th e 'Authentication Data' field of the MQTT CONNECT packet, following the property identifier 22 (0x16) and the token length.</t>
</li> </li>
</ul> </ul>
</section> </section>
<section anchor="design-rationale"> <section anchor="design-rationale">
<name>Design Rationale</name> <name>Design Rationale</name>
<t>Considering the possible variants discussed above, it must always b e ensured that the same HASH_INPUT value is used as input for generating the tok en hash of a given access token, by the AS that has issued the access token and by the registered devices to which the access token pertains (both client and RS ).</t> <t>Considering the possible variants discussed above, it must always b e ensured that the same HASH_INPUT value is used as input for generating the tok en hash of a given access token, by the AS that has issued the access token and by the registered devices to which the access token pertains (both client and RS ).</t>
<t>This is achieved by building HASH_INPUT according to the content of the 'access_token' parameter in the AS-to-Client responses, since that is what all among the AS, the client, and the RS are able to see.</t> <t>This is achieved by building HASH_INPUT according to the content of the 'access_token' parameter in the AS-to-Client responses because that is what the AS, the client, and the RS are all able to see.</t>
</section> </section>
</section> </section>
<section anchor="sec-token-hash-input-c-as"> <section anchor="sec-token-hash-input-c-as">
<name>Hash Input on the Client and the AS</name> <name>Hash Input on the Client and the AS</name>
<t>The client and the AS consider the content of the 'access_token' para meter in the AS-to-Client response, where the (tagged) access token is included and provided to the requester client.</t> <t>The client and the AS consider the content of the 'access_token' para meter in the AS-to-Client response, in which the (tagged) access token is includ ed and provided to the requester client.</t>
<t>The following defines how the client and the AS determine the HASH_IN PUT value to use as input for computing the token hash of the conveyed access to ken, depending on the AS-to-Client response being encoded in CBOR (see <xref tar get="sec-token-hash-input-c-as-cbor"/>) or in JSON (see <xref target="sec-token- hash-input-c-as-json"/>).</t> <t>The following defines how the client and the AS determine the HASH_IN PUT value to use as input for computing the token hash of the conveyed access to ken, depending on the AS-to-Client response being encoded in CBOR (see <xref tar get="sec-token-hash-input-c-as-cbor"/>) or in JSON (see <xref target="sec-token- hash-input-c-as-json"/>).</t>
<t>Once determined HASH_INPUT, the client and the AS use it to compute t he token hash of the conveyed access token as defined in <xref target="sec-token -hash-output"/>.</t> <t>Once the HASH_INPUT is determined, the client and the AS use it to co mpute the token hash of the conveyed access token as defined in <xref target="se c-token-hash-output"/>.</t>
<section anchor="sec-token-hash-input-c-as-cbor"> <section anchor="sec-token-hash-input-c-as-cbor">
<name>AS-to-Client Response Encoded in CBOR</name> <name>AS-to-Client Response Encoded in CBOR</name>
<t>If the AS-to-Client response is encoded in CBOR, then HASH_INPUT is defined as follows:</t> <t>If the AS-to-Client response is encoded in CBOR, then HASH_INPUT is defined as follows:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>BYTES denotes the value of the CBOR byte string conveyed in the parameter 'access_token'. </t> <t>BYTES denotes the value of the CBOR byte string conveyed in the parameter 'access_token'. </t>
<!--[rfced] Please confirm that commas should not separate these
values in curly brackets:
Original:
With reference to the example in Figure 3, BYTES is the bytes
{0xd8 0x3d 0xd0 ... 0x64 0x3b}.
-->
<t> <t>
With reference to the example in <xref target="fig-as-response-cbor"/>, BYTES is the bytes {0xd8 0x3d 0xd0 ... 0x64 0x3b}. </t> With reference to the example in <xref target="fig-as-response-cbor"/>, BYTES is the bytes {0xd8 0x3d 0xd0 ... 0x64 0x3b}. </t>
<t> <t>
Note that BYTES is the binary representation of the tagged access token if this is a CWT (as per <xref target="sec-issuing-access-tokens-as"/>), or of the acces s token if this is a JWT.</t> Note that BYTES is the binary representation of the tagged access token if this is a CWT (as per <xref target="sec-issuing-access-tokens-as"/>) or of the access token if this is a JWT.</t>
</li> </li>
<li> <li>
<t>HASH_INPUT_TEXT is the base64url-encoded text string that encod es BYTES.</t> <t>HASH_INPUT_TEXT is the base64url-encoded text string that encod es BYTES.</t>
</li> </li>
<li> <li>
<t>HASH_INPUT is the binary representation of HASH_INPUT_TEXT.</t> <t>HASH_INPUT is the binary representation of HASH_INPUT_TEXT.</t>
</li> </li>
</ul> </ul>
<figure anchor="fig-as-response-cbor"> <figure anchor="fig-as-response-cbor">
<name>Example of AS-to-Client CoAP response using CBOR</name> <name>Example of AS-to-Client CoAP Response Using CBOR</name>
<artwork align="left"><![CDATA[ <sourcecode type="coap"><![CDATA[
Header: Created (Code=2.01) Header: Created (Code=2.01)
Content-Format: application/ace+cbor Content-Format: application/ace+cbor
Max-Age: 85800 Max-Age: 85800
Payload: Payload:
{ {
/ access_token / 1 : h'd83dd0835820a3010a044c53796d6d / access_token / 1 : h'd83dd0835820a3010a044c53796d6d
6574726963313238054d99a0d7846e 6574726963313238054d99a0d7846e
762c49ffe8a63e0ba05858b918a11f 762c49ffe8a63e0ba05858b918a11f
d81e438b7f973d9e2e119bcb22424b d81e438b7f973d9e2e119bcb22424b
a0f38a80f27562f400ee1d0d6c0fdb a0f38a80f27562f400ee1d0d6c0fdb
559c02421fd384fc2ebe22d7071378 559c02421fd384fc2ebe22d7071378
b0ea7428fff157444d45f7e6afcda1 b0ea7428fff157444d45f7e6afcda1
aae5f6495830c58627087fc5b4974f aae5f6495830c58627087fc5b4974f
319a8707a635dd643b', 319a8707a635dd643b',
/ token_type / 34 : 2 / PoP /, / token_type / 34 : 2 / PoP /,
/ expires_in / 2 : 86400, / expires_in / 2 : 86400,
/ ace_profile / 38 : 1 / coap_dtls /, / ace_profile / 38 : 1 / coap_dtls /,
/ (remainder of the response omitted for brevity) / / (remainder of the response omitted for brevity) /
} }
]]></artwork> ]]></sourcecode>
</figure> </figure>
</section> </section>
<section anchor="sec-token-hash-input-c-as-json"> <section anchor="sec-token-hash-input-c-as-json">
<name>AS-to-Client Response Encoded in JSON</name> <name>AS-to-Client Response Encoded in JSON</name>
<t>If the AS-to-Client response is encoded in JSON, then HASH_INPUT is the binary representation of the text string conveyed by the 'access_token' par ameter.</t> <t>If the AS-to-Client response is encoded in JSON, then HASH_INPUT is the binary representation of the text string conveyed by the 'access_token' par ameter.</t>
<t>With reference to the example in <xref target="fig-as-response-json "/>, HASH_INPUT is the binary representation of "eyJh...YFiA". When showing the access token, <xref target="fig-as-response-json"/> uses line breaks for display purposes only.</t> <t>With reference to the example in <xref target="fig-as-response-json "/>, HASH_INPUT is the binary representation of "eyJh...YFiA". When showing the access token, <xref target="fig-as-response-json"/> uses line breaks for display purposes only.</t>
<t>Note that:</t> <t>Note that:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>If the access token is a JWT, then HASH_INPUT is the binary rep resentation of the JWT.</t> <t>If the access token is a JWT, then HASH_INPUT is the binary rep resentation of the JWT.</t>
</li> </li>
<li> <li>
<t>If the access token is a CWT, then HASH_INPUT is the binary rep
resentation of a base64url-encoded text string, which encodes the binary represe <t>If the access token is a CWT, then HASH_INPUT is the binary rep
ntation of a tagged access token with the CWT as innermost tag content (as per < resentation of a base64url-encoded text string, which encodes the binary represe
xref target="sec-issuing-access-tokens-as"/>).</t> ntation of a tagged access token with the CWT as the innermost tag content (as p
er <xref target="sec-issuing-access-tokens-as"/>).</t>
</li> </li>
</ul> </ul>
<figure anchor="fig-as-response-json"> <figure anchor="fig-as-response-json">
<name>Example of AS-to-Client HTTP response using JSON</name> <name>Example of AS-to-Client HTTP Response Using JSON</name>
<artwork align="left"><![CDATA[ <sourcecode type="json"><![CDATA[
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Type: application/ace+json Content-Type: application/ace+json
Cache-Control: no-store Cache-Control: no-store
Pragma: no-cache Pragma: no-cache
Payload: Payload:
{ {
"access_token" : "eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJB "access_token" : "eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJB
MTI4Q0JDLUhTMjU2In0. MTI4Q0JDLUhTMjU2In0.
QR1Owv2ug2WyPBnbQrRARTeEk9kDO2w8 QR1Owv2ug2WyPBnbQrRARTeEk9kDO2w8
qDcjiHnSJflSdv1iNqhWXaKH4MqAkQtM qDcjiHnSJflSdv1iNqhWXaKH4MqAkQtM
skipping to change at line 524 skipping to change at line 727
AxY8DCtDaGlsbGljb3RoZQ. AxY8DCtDaGlsbGljb3RoZQ.
MKOle7UQrG6nSxTLX6Mqwt0orbHvAKeW MKOle7UQrG6nSxTLX6Mqwt0orbHvAKeW
nDYvpIAeZ72deHxz3roJDXQyhxx0wKaM nDYvpIAeZ72deHxz3roJDXQyhxx0wKaM
HDjUEOKIwrtkHthpqEanSBNYHZgmNOV7 HDjUEOKIwrtkHthpqEanSBNYHZgmNOV7
sln1Eu9g3J8. sln1Eu9g3J8.
fiK51VwhsxJ-siBMR-YFiA", fiK51VwhsxJ-siBMR-YFiA",
"token_type" : "pop", "token_type" : "pop",
"expires_in" : 86400, "expires_in" : 86400,
"ace_profile" : "1" "ace_profile" : "1"
} }
]]></artwork> ]]></sourcecode>
</figure> </figure>
</section> </section>
</section> </section>
<section anchor="sec-token-hash-input-rs"> <section anchor="sec-token-hash-input-rs">
<name>HASH_INPUT on the RS</name> <name>HASH_INPUT on the RS</name>
<t>The following defines how the RS determines the HASH_INPUT value to u se as input for computing the token hash of an access token, depending on the RS using either CWTs (see <xref target="sec-token-hash-input-rs-cwt"/>) or JWTs (s ee <xref target="sec-token-hash-input-rs-jwt"/>).</t> <t>The following defines how the RS determines the HASH_INPUT value to u se as input for computing the token hash of an access token, depending on the RS using either CWTs (see <xref target="sec-token-hash-input-rs-cwt"/>) or JWTs (s ee <xref target="sec-token-hash-input-rs-jwt"/>).</t>
<section anchor="sec-token-hash-input-rs-cwt"> <section anchor="sec-token-hash-input-rs-cwt">
<name>Access Tokens as CWTs</name> <name>Access Tokens as CWTs</name>
<t>If the RS expects access tokens to be CWTs, then the RS performs th e following steps.</t> <t>If the RS expects access tokens to be CWTs, then the RS performs th e following steps:</t>
<ol spacing="normal" type="1"><li> <ol spacing="normal" type="1"><li>
<t>The RS receives the token-related information TOKEN_INFO, in ac cordance with what is specified by the used profile of ACE (see <xref target="se c-token-hash-input-motivation-rs"/>).</t> <t>The RS receives the token-related information TOKEN_INFO, in ac cordance with what is specified by the used profile of ACE (see <xref target="se c-token-hash-input-motivation-rs"/>).</t>
</li> </li>
<li> <li>
<t>The RS assumes that the client received the access token in an AS-to-Client response encoded in CBOR (see <xref target="sec-token-hash-input-c- as-cbor"/>). Hence, the RS assumes TOKEN_INFO to be the binary representation of the tagged access token with the CWT as innermost tag content (as per <xref tar get="sec-issuing-access-tokens-as"/>).</t> <t>The RS assumes that the client received the access token in an AS-to-Client response encoded in CBOR (see <xref target="sec-token-hash-input-c- as-cbor"/>). Hence, the RS assumes TOKEN_INFO to be the binary representation of the tagged access token with the CWT as the innermost tag content (as per <xref target="sec-issuing-access-tokens-as"/>).</t>
</li> </li>
<li> <li>
<t>The RS verifies the access token as per <xref section="5.10.1.1 " sectionFormat="of" target="RFC9200"/>. If the verification fails, then the RS does not discard the access token yet, and it instead moves to step 4. </t> <t>The RS verifies the access token as per <xref section="5.10.1.1 " sectionFormat="of" target="RFC9200"/>. If the verification fails, then the RS does not discard the access token yet; instead, it moves to step 4.</t>
<t> <t>
Otherwise, the RS stores the access token and computes the corresponding token h ash, as defined in <xref target="sec-token-hash-output"/>. In particular, the RS considers HASH_INPUT_TEXT as the base64url-encoded text string that encodes TOK EN_INFO. Then, HASH_INPUT is the binary representation of HASH_INPUT_TEXT. </t> Otherwise, the RS stores the access token and computes the corresponding token h ash as defined in <xref target="sec-token-hash-output"/>. In particular, the RS considers HASH_INPUT_TEXT as the base64url-encoded text string that encodes TOKE N_INFO. Then, HASH_INPUT is the binary representation of HASH_INPUT_TEXT. </t>
<t> <t>
After that, the RS stores the computed token hash as associated with the access token, and then terminates this algorithm.</t> After that, the RS stores the computed token hash as associated with the access token; then, it terminates this algorithm.</t>
</li> </li>
<li> <li>
<t>The RS assumes that the client received the access token in an AS-to-Client response encoded in JSON (see <xref target="sec-token-hash-input-c- as-json"/>). Hence, the RS assumes TOKEN_INFO to be the binary representation of HASH_INPUT_TEXT. In turn, HASH_INPUT_TEXT is the base64url-encoded text string that encodes the binary representation of the tagged access token with the CWT a s innermost tag content (as per <xref target="sec-issuing-access-tokens-as"/>).< /t> <t>The RS assumes that the client received the access token in an AS-to-Client response encoded in JSON (see <xref target="sec-token-hash-input-c- as-json"/>). Hence, the RS assumes TOKEN_INFO to be the binary representation of HASH_INPUT_TEXT. In turn, HASH_INPUT_TEXT is the base64url-encoded text string that encodes the binary representation of the tagged access token with the CWT a s the innermost tag content (as per <xref target="sec-issuing-access-tokens-as"/ >).</t>
</li> </li>
<li> <li>
<t>The RS performs the base64url decoding of HASH_INPUT_TEXT, and considers the result as the binary representation of the tagged access token.</t > <t>The RS performs the base64url decoding of HASH_INPUT_TEXT and c onsiders the result to be the binary representation of the tagged access token.< /t>
</li> </li>
<li> <li>
<t>The RS verifies the access token as per <xref section="5.10.1.1 " sectionFormat="of" target="RFC9200"/>. If the verification fails, then the RS terminates this algorithm. </t> <t>The RS verifies the access token as per <xref section="5.10.1.1 " sectionFormat="of" target="RFC9200"/>. If the verification fails, then the RS terminates this algorithm. </t>
<t> <t>
Otherwise, the RS stores the access token and computes the corresponding token h ash, as defined in <xref target="sec-token-hash-output"/>. In particular, HASH_I NPUT is TOKEN_INFO. </t> Otherwise, the RS stores the access token and computes the corresponding token h ash as defined in <xref target="sec-token-hash-output"/>. In particular, HASH_IN PUT is TOKEN_INFO. </t>
<t> <t>
After that, the RS stores the computed token hash as associated with the access token.</t> After that, the RS stores the computed token hash as associated with the access token.</t>
</li> </li>
</ol> </ol>
</section> </section>
<section anchor="sec-token-hash-input-rs-jwt"> <section anchor="sec-token-hash-input-rs-jwt">
<name>Access Tokens as JWTs</name> <name>Access Tokens as JWTs</name>
<t>If the RS expects access tokens to be JWTs, then the RS performs th e following steps.</t> <t>If the RS expects access tokens to be JWTs, then the RS performs th e following steps:</t>
<ol spacing="normal" type="1"><li> <ol spacing="normal" type="1"><li>
<t>The RS receives the token-related information TOKEN_INFO, in ac cordance with what is specified by the used profile of ACE (see <xref target="se c-token-hash-input-motivation-rs"/>).</t> <t>The RS receives the token-related information TOKEN_INFO, in ac cordance with what is specified by the used profile of ACE (see <xref target="se c-token-hash-input-motivation-rs"/>).</t>
</li> </li>
<li> <li>
<t>The RS verifies the access token as per <xref section="5.10.1.1 " sectionFormat="of" target="RFC9200"/>. If the verification fails, then the RS terminates this algorithm. Otherwise, the RS stores the access token.</t> <t>The RS verifies the access token as per <xref section="5.10.1.1 " sectionFormat="of" target="RFC9200"/>. If the verification fails, then the RS terminates this algorithm. Otherwise, the RS stores the access token.</t>
</li> </li>
<li> <li>
<t>The RS computes a first token hash associated with the access t oken, as defined in <xref target="sec-token-hash-output"/>. </t> <t>The RS computes a first token hash associated with the access t oken as defined in <xref target="sec-token-hash-output"/>. </t>
<t> <t>
In particular, the RS assumes that the client received the access token in an AS -to-Client response encoded in JSON (see <xref target="sec-token-hash-input-c-as -json"/>). Hence, HASH_INPUT is TOKEN_INFO. </t> In particular, the RS assumes that the client received the access token in an AS -to-Client response encoded in JSON (see <xref target="sec-token-hash-input-c-as -json"/>). Hence, HASH_INPUT is TOKEN_INFO. </t>
<t> <t>
After that, the RS stores the computed token hash as associated with the access token.</t> After that, the RS stores the computed token hash as associated with the access token.</t>
</li> </li>
<li> <li>
<t>The RS computes a second token hash associated with the access token, as defined in <xref target="sec-token-hash-output"/>. </t> <t>The RS computes a second token hash associated with the access token as defined in <xref target="sec-token-hash-output"/>. </t>
<t> <t>
In particular, the RS assumes that the client received the access token in an AS -to-Client response encoded in CBOR (see <xref target="sec-token-hash-input-c-as -cbor"/>). Hence, HASH_INPUT is the binary representation of HASH_INPUT_TEXT, wh ich in turn is the base64url-encoded text string that encodes TOKEN_INFO. </t> In particular, the RS assumes that the client received the access token in an AS -to-Client response encoded in CBOR (see <xref target="sec-token-hash-input-c-as -cbor"/>). Hence, HASH_INPUT is the binary representation of HASH_INPUT_TEXT, wh ich, in turn, is the base64url-encoded text string that encodes TOKEN_INFO. </t >
<t> <t>
After that, the RS stores the computed token hash as associated with the access token.</t> After that, the RS stores the computed token hash as associated with the access token.</t>
</li> </li>
</ol> </ol>
<t>The RS skips step 3 only if it is certain that all its pertaining a ccess tokens are provided to any client by means of AS-to-Client responses encod ed as CBOR messages. Otherwise, the RS <bcp14>MUST</bcp14> perform step 3.</t> <t>The RS skips step 3 only if it is certain that all its pertaining a ccess tokens are provided to any client by means of AS-to-Client responses encod ed as CBOR messages. Otherwise, the RS <bcp14>MUST</bcp14> perform step 3.</t>
<t>The RS skips step 4 only if it is certain that all its pertaining a ccess tokens are provided to any client by means of AS-to-Client responses encod ed as JSON messages. Otherwise, the RS <bcp14>MUST</bcp14> perform step 4.</t> <t>The RS skips step 4 only if it is certain that all its pertaining a ccess tokens are provided to any client by means of AS-to-Client responses encod ed as JSON messages. Otherwise, the RS <bcp14>MUST</bcp14> perform step 4.</t>
<t>If the RS performs both step 3 and step 4 above, then the RS <bcp14 >MUST</bcp14> store, maintain, and rely on both token hashes as associated with the access token, consistent with what is specified in <xref target="sec-handlin g-token-hashes"/>.</t> <t>If the RS performs both steps 3 and 4 above, then the RS <bcp14>MUS T</bcp14> store, maintain, and rely on both token hashes as associated with the access token, consistent with what is specified in <xref target="sec-handling-to ken-hashes"/>.</t>
<t><xref target="sec-seccons-two-hashes-jwt"/> discusses how computing and storing both token hashes neutralizes an attack against the RS, where a dis honest client can induce the RS to compute a token hash different from the corre ct one.</t> <t><xref target="sec-seccons-two-hashes-jwt"/> discusses how computing and storing both token hashes neutralizes an attack against the RS, where a dis honest client can induce the RS to compute a token hash different from the corre ct one.</t>
</section> </section>
</section> </section>
<section anchor="sec-token-hash-output"> <section anchor="sec-token-hash-output">
<name>Computing the Token Hash</name> <name>Computing the Token Hash</name>
<t>Once determined HASH_INPUT as defined in <xref target="sec-token-hash <t>Once HASH_INPUT is determined as defined in Sections <xref target="se
-input-c-as"/> and <xref target="sec-token-hash-input-rs"/>, a hash value of HAS c-token-hash-input-c-as" format="counter"/> and <xref target="sec-token-hash-inp
H_INPUT is generated as per <xref section="6" sectionFormat="of" target="RFC6920 ut-rs" format="counter"/>, a hash value of HASH_INPUT is generated as per <xref
"/>. The resulting output in binary format is used as the token hash. Note that section="6" sectionFormat="of" target="RFC6920"/>. The resulting output in binar
the used binary format embeds the identifier of the used hash function, in the f y format is used as the token hash. Note that the used binary format embeds the
irst byte of the computed token hash.</t> identifier of the used hash function in the first byte of the computed token has
<t>The specifically used hash function <bcp14>MUST</bcp14> be collision- h.</t>
resistant on byte-strings, and <bcp14>MUST</bcp14> be selected from the "Named I
nformation Hash Algorithm" Registry <xref target="Named.Information.Hash.Algorit <t>The specific hash function used <bcp14>MUST</bcp14> be collision resi
hm"/>. Consistent with the compliance requirements in <xref section="2" sectionF stant on byte strings and <bcp14>MUST</bcp14> be selected from the "Named Inform
ormat="of" target="RFC6920"/>, the hash function sha-256 as specified in <xref t ation Hash Algorithm Registry" <xref target="IANA.Hash.Algorithms"/>. Consistent
arget="SHA-256"/> is mandatory to implement.</t> with the compliance requirements in <xref section="2" sectionFormat="of" target
="RFC6920"/>, the hash function sha-256 as specified in <xref target="SHA-256"/>
is mandatory to implement.</t>
<t>The AS specifies the used hash function to registered devices during their registration procedure (see <xref target="sec-registration"/>).</t> <t>The AS specifies the used hash function to registered devices during their registration procedure (see <xref target="sec-registration"/>).</t>
</section> </section>
</section> </section>
<section anchor="sec-trl-resource"> <section anchor="sec-trl-resource">
<name>Token Revocation List (TRL)</name> <name>Token Revocation List (TRL)</name>
<t>Upon startup, the AS creates a single Token Revocation List (TRL), enco <t>Upon startup, the AS creates a single Token Revocation List (TRL) encod
ded as a CBOR array.</t> ed as a CBOR array.</t>
<t>Each element of the array is a CBOR byte string, with value the token h
ash of an access token. The CBOR array <bcp14>MUST</bcp14> be treated as a set, <!--[rfced] These sentences do not parse. Please review "with value
i.e., the order of its elements has no meaning.</t> the token hash" in particular.
Original:
Each element of the array is a CBOR byte string, with value the token
hash of an access token.
Original:
Each element of the array is a CBOR byte string, with value the
token hash of an access token such that: it pertained to the
requester; and it was removed from the TRL during the update
associated with the diff entry.
-->
<t>Each element of the array is a CBOR byte string with value the token ha
sh of an access token. The CBOR array <bcp14>MUST</bcp14> be treated as a set, i
.e., the order of its elements has no meaning.</t>
<t>The TRL is initialized as empty, i.e., its initial content <bcp14>MUST< /bcp14> be the empty CBOR array. The TRL is accessible through the TRL endpoint at the AS.</t> <t>The TRL is initialized as empty, i.e., its initial content <bcp14>MUST< /bcp14> be the empty CBOR array. The TRL is accessible through the TRL endpoint at the AS.</t>
<section anchor="ssec-trl-update"> <section anchor="ssec-trl-update">
<name>Update of the TRL</name> <name>Update of the TRL</name>
<t>The AS updates the TRL in the following two cases.</t> <t>The AS updates the TRL in the following two cases:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>When a non-expired access token is revoked, the token hash of the access token is added to the TRL. That is, a CBOR byte string with the token ha sh as its value is added to the CBOR array encoding the TRL.</t> <t>When a non-expired access token is revoked, the token hash of the access token is added to the TRL. That is, a CBOR byte string with the token ha sh as its value is added to the CBOR array encoding the TRL.</t>
</li> </li>
<li> <li>
<t>When a revoked access token expires, the token hash of the access token is removed from the TRL. That is, the CBOR byte string with the token has h as its value is removed from the CBOR array encoding the TRL.</t> <t>When a revoked access token expires, the token hash of the access token is removed from the TRL. That is, the CBOR byte string with the token has h as its value is removed from the CBOR array encoding the TRL.</t>
</li> </li>
</ul> </ul>
<t>The AS <bcp14>MAY</bcp14> perform a single update to the TRL such tha t one or more token hashes are added or removed at once. For example, this can b e the case if multiple access tokens are revoked or expire at the same time, or within an acceptably narrow time window.</t> <t>The AS <bcp14>MAY</bcp14> perform a single update to the TRL such tha t one or more token hashes are added or removed at once. For example, this can b e the case if multiple access tokens are revoked or expire at the same time or w ithin an acceptably narrow time frame.</t>
</section> </section>
</section> </section>
<section anchor="sec-trl-endpoint"> <section anchor="sec-trl-endpoint">
<name>The TRL Endpoint</name> <name>The TRL Endpoint</name>
<!--[rfced] The double prepositions (between and towards) make this
text hard to parse. How may we rephrase?
Original:
Consistent with Section 6.5 of [RFC9200], all communications between
a requester towards the TRL endpoint and the AS MUST be encrypted, as
well as integrity and replay protected.
-->
<t>Consistent with <xref section="6.5" sectionFormat="of" target="RFC9200" />, all communications between a requester towards the TRL endpoint and the AS < bcp14>MUST</bcp14> be encrypted, as well as integrity and replay protected. Furt hermore, responses from the AS to the requester <bcp14>MUST</bcp14> be bound to the corresponding requests.</t> <t>Consistent with <xref section="6.5" sectionFormat="of" target="RFC9200" />, all communications between a requester towards the TRL endpoint and the AS < bcp14>MUST</bcp14> be encrypted, as well as integrity and replay protected. Furt hermore, responses from the AS to the requester <bcp14>MUST</bcp14> be bound to the corresponding requests.</t>
<t>Following a request to the TRL endpoint, the corresponding, success res ponse messages sent by the AS use Content-Format "application/ace-trl+cbor". The ir payload is formatted as a CBOR map, and the CBOR values used to abbreviate th e parameters included therein are defined in <xref target="trl-registry-paramete rs"/>.</t> <t>Following a request to the TRL endpoint, the corresponding success resp onse messages sent by the AS use Content-Format "application/ace-trl+cbor". Thei r payload is formatted as a CBOR map, and the CBOR values used to abbreviate the parameters included therein are defined in <xref target="trl-registry-parameter s"/>.</t>
<t>The AS <bcp14>MUST</bcp14> implement measures to prevent access to the TRL endpoint by entities other than registered devices and authorized administra tors (see <xref target="sec-registration"/>).</t> <t>The AS <bcp14>MUST</bcp14> implement measures to prevent access to the TRL endpoint by entities other than registered devices and authorized administra tors (see <xref target="sec-registration"/>).</t>
<t>The TRL endpoint supports only the GET method, and allows two types of <t>The TRL endpoint supports only the GET method, and allows two types of
queries of the TRL.</t> queries of the TRL:</t>
<ul spacing="normal"> <ol spacing="normal">
<li> <li>
<t>Full query: the AS returns the token hashes of the revoked access t okens currently in the TRL and pertaining to the requester. </t> <t>Full query: the AS returns the token hashes of the revoked access t okens currently in the TRL and pertaining to the requester. </t>
<t> <t>
The AS <bcp14>MUST</bcp14> support this type of query. The processing of a full query and the related response format are defined in <xref target="ssec-trl-full -query"/>.</t> The AS <bcp14>MUST</bcp14> support this type of query. The processing of a full query and the related response format are defined in <xref target="ssec-trl-full -query"/>.</t>
</li> </li>
<li> <li>
<t>Diff query: the AS returns a list of diff entries. Each diff entry is related to one update occurred to the TRL, and it contains a set of token has hes pertaining to the requester. In particular, all such token hashes were added to the TRL or removed from the TRL at the update related to the diff entry in q uestion. </t> <t>Diff query: the AS returns a list of diff entries. Each diff entry is related to one update to the TRL, and it contains a set of token hashes perta ining to the requester. In particular, all such token hashes were added to the T RL or removed from the TRL at the update related to the diff entry in question. </t>
<t> <t>
The AS <bcp14>MAY</bcp14> support this type of query. In such a case, the AS mai ntains the history of updates to the TRL as defined in <xref target="sec-trl-end point-supporting-diff-queries"/>. The processing of a diff query and the related response format are defined in <xref target="ssec-trl-diff-query"/>.</t> The AS <bcp14>MAY</bcp14> support this type of query. In such a case, the AS mai ntains the history of updates to the TRL as defined in <xref target="sec-trl-end point-supporting-diff-queries"/>. The processing of a diff query and the related response format are defined in <xref target="ssec-trl-diff-query"/>.</t>
</li> </li>
</ul> </ol>
<t>If it supports diff queries, the AS <bcp14>MAY</bcp14> additionally sup <t>If it supports diff queries, the AS <bcp14>MAY</bcp14> additionally sup
port its "Cursor" extension, which has two benefits. First, the AS can avoid exc port its "Cursor" extension, which has two benefits:</t>
essively long messages when several diff entries have to be transferred, by deli <ol>
vering several diff query responses, each containing one adjacent subset of diff <li>The AS can avoid excessively long messages when several diff entries
entries at a time. Second, a requester can retrieve diff entries associated wit have to be transferred by delivering several diff query responses, each containi
h TRL updates that, even if not the most recent ones, occurred after a TRL updat ng one adjacent subset of diff entries at a time.</li>
e associated with a diff entry indicated as reference point.</t> <li>A requester can retrieve diff entries associated with TRL updates tha
<t>If it supports the "Cursor" extension, the AS stores additional informa t, even if not the most recent ones, occurred after a TRL update associated with
tion when maintaining the history of updates to the TRL, as defined in <xref tar a diff entry indicated as a reference point.</li></ol>
get="sec-trl-endpoint-supporting-cursor"/>. Also, the processing of full query r <t>If it supports the "Cursor" extension, the AS stores additional informa
equests and diff query requests, as well as the related response format, are fur tion when maintaining the history of updates to the TRL as defined in <xref targ
ther extended as defined in <xref target="sec-using-cursor"/>.</t> et="sec-trl-endpoint-supporting-cursor"/>. Also, the processing of full query re
<t><xref target="sec-trl-parameteters"/> provides an aggregated overview o quests and diff query requests, as well as the related response format, are furt
f the local supportive parameters that the AS internally uses at its TRL endpoin her extended as defined in <xref target="sec-using-cursor"/>.</t>
t, when supporting diff queries and the "Cursor" extension.</t> <t><xref target="sec-trl-parameteters"/> provides an aggregated overview o
f the local supportive parameters that the AS internally uses at its TRL endpoin
t when supporting diff queries and the "Cursor" extension.</t>
<section anchor="sec-error-responses"> <section anchor="sec-error-responses">
<name>Error Responses with Problem Details</name> <name>Error Responses with Problem Details</name>
<t>Some error responses from the TRL endpoint at the AS can convey error -specific information according to the problem-details format defined in <xref t arget="RFC9290"/>. Such error responses <bcp14>MUST</bcp14> have Content-Format set to "application/concise-problem-details+cbor". The payload of these error re sponses <bcp14>MUST</bcp14> be a CBOR map specifying a Concise Problem Details d ata item (see <xref section="2" sectionFormat="of" target="RFC9290"/>). The CBOR map is formatted as follows.</t> <t>Some error responses from the TRL endpoint at the AS can convey error -specific information according to the problem-details format defined in <xref t arget="RFC9290"/>. Such error responses <bcp14>MUST</bcp14> have Content-Format set to "application/concise-problem-details+cbor". The payload of these error re sponses <bcp14>MUST</bcp14> be a CBOR map specifying a Concise Problem Details d ata item (see <xref section="2" sectionFormat="of" target="RFC9290"/>). The CBOR map is formatted as follows:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>It <bcp14>MUST</bcp14> include the Custom Problem Detail entry 'a ce-trl-error' registered in <xref target="iana-custom-problem-details"/> of this document. This entry is formatted as a CBOR map, which includes the following f ields. </t> <t>It <bcp14>MUST</bcp14> include the Custom Problem Detail entry 'a ce-trl-error' registered in <xref target="iana-custom-problem-details"/> of this document. This entry is formatted as a CBOR map, which includes the following f ields:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>The field 'error-id' <bcp14>MUST</bcp14> be present. The map key used for this field is the CBOR unsigned integer with value 0. The value of this field is a CBOR integer specifying the error occurred at the AS. This value is taken from the 'Value' column of the "ACE Token Revocation List Errors" regi stry defined in <xref target="iana-token-revocation-list-errors"/> of this docum ent.</t> <t>The 'error-id' field <bcp14>MUST</bcp14> be present. The map key used for this field is the CBOR unsigned integer with a value of 0. The valu e of this field is a CBOR integer specifying the error that occurred at the AS. This value is taken from the 'Value' column of the "ACE Token Revocation List Er rors" registry defined in <xref target="iana-token-revocation-list-errors"/> of this document.</t>
</li> </li>
<li> <li>
<t>The field 'cursor' <bcp14>MAY</bcp14> be present. The map key used for this field is the CBOR unsigned integer with value 1. The value of thi s field is a CBOR unsigned integer or the CBOR simple value <tt>null</tt> (0xf6) . The use of this field is defined in <xref target="sec-trl-endpoint-query-param eters"/>.</t> <t>The 'cursor' field <bcp14>MAY</bcp14> be present. The map key used for this field is the CBOR unsigned integer with a value of 1. The value o f this field is a CBOR unsigned integer or the CBOR simple value <tt>null</tt> ( 0xf6). The use of this field is defined in <xref target="sec-trl-endpoint-query- parameters"/>.</t>
</li> </li>
</ul> </ul>
<t> <t>
The CDDL notation <xref target="RFC8610"/> of the 'ace-trl-error' entry is given The CDDL notation <xref target="RFC8610"/> of the 'ace-trl-error' entry is given
below.</t> below:</t>
</li>
</ul>
<sourcecode type="CDDL"><![CDATA[ <sourcecode type="CDDL"><![CDATA[
ace-trl-error = { ace-trl-error = {
0: int, ; error-id 0: int, ; error-id
? 1: uint / null ; cursor ? 1: uint / null ; cursor
} }
]]></sourcecode> ]]></sourcecode>
<ul spacing="normal"> </li>
<li> <li>
<t>It <bcp14>MAY</bcp14> include further Standard Problem Detail ent ries or Custom Problem Detail entries (see <xref target="RFC9290"/>). </t> <t>It <bcp14>MAY</bcp14> include further Standard Problem Detail ent ries or Custom Problem Detail entries (see <xref target="RFC9290"/>). </t>
<t> <t>
In particular, it can include the Standard Problem Detail entry 'detail' (map ke y -2), whose value is a CBOR text string that specifies a human-readable, diagno stic description of the error occurred at the AS. The diagnostic text is intende d for software engineers as well as for device and network operators, in order t o aid debugging and provide context for possible intervention. The diagnostic me ssage <bcp14>SHOULD</bcp14> be logged by the AS. The 'detail' entry is unlikely relevant in an unattended setup where human intervention is not expected.</t> In particular, it can include the Standard Problem Detail entry 'detail' (map ke y -2), whose value is a CBOR text string that specifies a human-readable diagnos tic description of the error that occurred at the AS. The diagnostic text is int ended for software engineers as well as for device and network operators in orde r to aid in debugging and provide context for possible intervention. The diagnos tic message <bcp14>SHOULD</bcp14> be logged by the AS. The 'detail' entry is unl ikely to be relevant in an unattended setup where human intervention is not expe cted.</t>
</li> </li>
</ul> </ul>
<t>An example of error response using the problem-details format is show n in <xref target="fig-example-error-response"/>.</t> <t>An example of an error response using the problem-details format is s hown in <xref target="fig-example-error-response"/>.</t>
<figure anchor="fig-example-error-response"> <figure anchor="fig-example-error-response">
<name>Example of Error Response with Problem Details</name> <name>Example of Error Response with Problem Details</name>
<artwork><![CDATA[ <sourcecode type=""><![CDATA[
Header: Bad Request (Code=4.00) Header: Bad Request (Code=4.00)
Content-Format: application/concise-problem-details+cbor Content-Format: application/concise-problem-details+cbor
Payload: Payload:
{ {
/ title / -1: "Invalid parameter value", / title / -1: "Invalid parameter value",
/ detail / -2: "Invalid value for 'cursor': -53", / detail / -2: "Invalid value for 'cursor': -53",
/ ace-trl-error / e'ace-trl-error': { / ace-trl-error / e'ace-trl-error': {
/ error-id / 0: 0 / "Invalid parameter value" /, / error-id / 0: 0 / "Invalid parameter value" /,
/ cursor / 1: 42 / cursor / 1: 42
} }
} }
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t>The problem-details format in general and the Custom Problem Detail e ntry 'ace-trl-error' in particular are <bcp14>OPTIONAL</bcp14> to support for re gistered devices. A registered device supporting the entry 'ace-trl-error' and a ble to understand the specified error may use that information to determine what actions to take next.</t> <t>The problem-details format in general and the Custom Problem Detail e ntry 'ace-trl-error' in particular are <bcp14>OPTIONAL</bcp14> to support for re gistered devices. A registered device supporting the entry 'ace-trl-error' and t hat is able to understand the specified error may use that information to determ ine what actions to take next.</t>
</section> </section>
<section anchor="sec-trl-endpoint-supporting-diff-queries"> <section anchor="sec-trl-endpoint-supporting-diff-queries">
<name>Supporting Diff Queries</name> <name>Supporting Diff Queries</name>
<t>If the AS supports diff queries, it is able to transfer a list of dif <t>If the AS supports diff queries, it is able to transfer a list of dif
f entries, each of which is related to one update occurred to the TRL (see <xref f entries, each of which is related to one update that occurred to the TRL (see
target="sec-trl-endpoint"/>). That is, when replying to a diff query performed <xref target="sec-trl-endpoint"/>). That is, when replying to a diff query perfo
by a requester, the AS specifies the diff entries related to the most recent TRL rmed by a requester, the AS specifies the diff entries related to the most recen
updates pertaining to the requester.</t> t TRL updates pertaining to the requester.</t>
<t>The following defines how the AS builds and maintains an ordered list <t>The following defines how the AS builds and maintains an ordered list
of diff entries, for each registered device and administrator, hereafter referr of diff entries, for each registered device and administrator, hereafter referr
ed to as requesters. In particular, a requester's diff entry associated with a T ed to as "requesters". In particular, a requester's diff entry associated with a
RL update contains a set of token hashes pertaining to that requester, which wer TRL update contains a set of token hashes pertaining to that requester, each of
e added to the TRL or removed from the TRL at that update.</t> which was added to the TRL or removed from the TRL at that update.</t>
<t>The AS defines the single, constant positive integer MAX_N &gt;= 1. F <t>The AS defines the single constant positive integer MAX_N &gt;= 1. Fo
or each requester, the AS maintains an update collection of maximum MAX_N series r each requester, the AS maintains an updated collection of maximum MAX_N series
items, each of which is a diff entry. For each requester, the AS <bcp14>MUST</b items, each of which is a diff entry. For each requester, the AS <bcp14>MUST</b
cp14> keep track of the MAX_N most recent TRL updates pertaining to the requeste cp14> keep track of the MAX_N most recent TRL updates pertaining to the requeste
r. If the AS supports diff queries, the AS <bcp14>MUST</bcp14> provide requester r. If the AS supports diff queries, the AS <bcp14>MUST</bcp14> provide requester
s with the value of MAX_N, upon their registration (see <xref target="sec-regist s with the value of MAX_N upon their registration (see <xref target="sec-registr
ration"/>).</t> ation"/>).</t>
<t>The series items in the update collection <bcp14>MUST</bcp14> be stri <t>The series of items in the update collection <bcp14>MUST</bcp14> be s
ctly ordered in a chronological fashion. That is, at any point in time, the curr trictly chronologically ordered. That is, at any point in time, the first series
ent first series item is the one least recently added to the update collection a item would be the one least recently added to the update collection and still r
nd still retained by the AS, while the current last series item is the one most etained by the AS; the last series item would be the one most recently added to
recently added to the update collection. The particular method used to achieve t the update collection. The particular method used to achieve this is implementat
his is implementation-specific.</t> ion specific.</t>
<t>Each time the TRL changes, the AS performs the following operations f <t>Each time the TRL changes, the AS performs the following operations f
or each requester.</t> or each requester:</t>
<ol spacing="normal" type="1"><li> <ol spacing="normal" type="1"><li>
<t>The AS considers the subset of the TRL pertaining to that request er. If the TRL subset is not affected by this TRL update, the AS stops the proce ssing for that requester. Otherwise, the AS moves to step 2.</t> <t>The AS considers the subset of the TRL pertaining to that request er. If the TRL subset is not affected by this TRL update, the AS stops the proce ssing for that requester. Otherwise, the AS moves to step 2.</t>
</li> </li>
<!--[rfced] Please review the following text and let us know what
"trl_patch" names? Is this the name of the sets? The token
hashes?
Original:
2. The AS creates two sets "trl_patch" of token hashes, i.e., one
"removed" set and one "added" set, as related to this TRL update.
Perhaps:
2. The AS creates two sets of "trl_patch" token hashes, i.e., one
"removed" set and one "added" set, as related to this TRL update.
-->
<li> <li>
<t>The AS creates two sets "trl_patch" of token hashes, i.e., one " removed" set and one "added" set, as related to this TRL update.</t> <t>The AS creates two sets "trl_patch" of token hashes, i.e., one " removed" set and one "added" set, as related to this TRL update.</t>
</li> </li>
<li> <li>
<t>The AS fills the two sets with the token hashes of the removed an d added access tokens, respectively, from/to the TRL subset considered at step 1 .</t> <t>The AS fills the two sets with the token hashes of the removed an d added access tokens, respectively, from/to the TRL subset considered at step 1 .</t>
</li> </li>
<li> <li>
<t>The AS creates a new series item, which includes the two sets fro m step 3.</t> <t>The AS creates a new series item that includes the two sets from step 3.</t>
</li> </li>
<li> <li>
<t>If the update collection associated with the requester currently includes MAX_N series items, the AS <bcp14>MUST</bcp14> delete the oldest series item in the update collection.</t> <t>If the update collection associated with the requester currently includes MAX_N series items, the AS <bcp14>MUST</bcp14> delete the oldest series item in the update collection.</t>
</li> </li>
<li> <li>
<t>The AS adds the series item to the update collection associated w ith the requester, as the last (most recent) one.</t> <t>The AS adds the series item to the update collection associated w ith the requester as the last (most recent) entry.</t>
</li> </li>
</ol> </ol>
<section anchor="sec-trl-endpoint-supporting-cursor"> <section anchor="sec-trl-endpoint-supporting-cursor">
<name>Supporting the "Cursor" Extension</name> <name>Supporting the "Cursor" Extension</name>
<t>If it supports the "Cursor" extension for diff queries, the AS perf <t>If it supports the "Cursor" extension for diff queries, the AS also
orms also the following actions.</t> performs the following actions:</t>
<t>The AS defines the single, constant unsigned integer MAX_INDEX &lt; <t>The AS defines the single constant unsigned integer MAX_INDEX &lt;=
= ((2^64) - 1), where "^" is the exponentiation operator. The value of MAX_INDEX ((2^64) - 1), where "^" is the exponentiation operator. The value of MAX_INDEX
is <bcp14>REQUIRED</bcp14> to be at least (MAX_N - 1), and is <bcp14>RECOMMENDE is <bcp14>REQUIRED</bcp14> to be at least (MAX_N - 1) and is <bcp14>RECOMMENDED<
D</bcp14> to be at least ((2^32) - 1). MAX_INDEX <bcp14>SHOULD</bcp14> be orders /bcp14> to be at least ((2^32) - 1). MAX_INDEX <bcp14>SHOULD</bcp14> be orders o
of magnitude greater than MAX_N.</t> f magnitude greater than MAX_N.</t>
<t>The following applies separately for each requester's update collec <t>The following applies separately for each requester's update collec
tion.</t> tion:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Each series item X in the update collection is also associated with an unsigned integer 'index', whose minimum value is 0 and whose maximum val ue is MAX_INDEX. The first series item ever added to the update collection <bcp1 4>MUST</bcp14> have 'index' with value 0. </t> <t>Each series item X in the update collection is also associated with an unsigned integer 'index', whose minimum value is 0 and whose maximum val ue is MAX_INDEX. The first series item ever added to the update collection <bcp1 4>MUST</bcp14> have an 'index' with a value of 0. </t>
<t> <t>
If i_X is the value of 'index' associated with a series item X, then the followi ng series item Y will take 'index' with value i_Y = (i_X + 1) % (MAX_INDEX + 1). That is, after having added a series item whose associated 'index' has value MA X_INDEX, the next added series item will result in a wrap-around of the 'index' value, and will thus take 'index' with value 0. </t> If i_X is the value of 'index' associated with a series item X, then the followi ng series item Y will take 'index' with a value of i_Y = (i_X + 1) % (MAX_INDEX + 1). That is, after having added a series item whose associated 'index' has a v alue of MAX_INDEX, the next added series item will result in a wraparound of the 'index' value; thus, it will take an 'index' with a value of 0. </t>
<t> <t>
For example, assuming MAX_N = 3, the values of 'index' in the update collection chronologically evolve as follows, as new series items are added and old series items are deleted. </t> For example, assuming MAX_N = 3, the values of 'index' in the update collection chronologically evolve as follows, as new series items are added and old series items are deleted: </t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>...</t> <t>...</t>
</li> </li>
<li> <li>
<t>(i_A = MAX_INDEX - 2, i_B = MAX_INDEX - 1, i_C = MAX_INDEX) </t> <t>(i_A = MAX_INDEX - 2, i_B = MAX_INDEX - 1, i_C = MAX_INDEX) </t>
</li> </li>
<li> <li>
<t>(i_B = MAX_INDEX - 1, i_C = MAX_INDEX, i_D = 0)</t> <t>(i_B = MAX_INDEX - 1, i_C = MAX_INDEX, i_D = 0)</t>
</li> </li>
skipping to change at line 753 skipping to change at line 1003
<li> <li>
<t>...</t> <t>...</t>
</li> </li>
</ul> </ul>
</li> </li>
<li> <li>
<t>The unsigned integer 'last_index' is also defined, with minimum value 0 and maximum value MAX_INDEX. </t> <t>The unsigned integer 'last_index' is also defined, with minimum value 0 and maximum value MAX_INDEX. </t>
<t> <t>
If the update collection is empty (i.e., no series items have been added yet), t he value of 'last_index' is not defined. If the update collection is not empty, 'last_index' has the value of 'index' currently associated with the last series item in the update collection. </t> If the update collection is empty (i.e., no series items have been added yet), t he value of 'last_index' is not defined. If the update collection is not empty, 'last_index' has the value of 'index' currently associated with the last series item in the update collection. </t>
<t> <t>
That is, after having added V series items to the update collection, the last an d most recently added series item has 'index' with value 'last_index' = (V - 1) % (MAX_INDEX + 1). </t> That is, after having added V series items to the update collection, the last an d most recently added series item has an 'index' with a value of 'last_index' = (V - 1) % (MAX_INDEX + 1). </t>
<t> <t>
As long as a wrap-around of the 'index' value has not occurred, the value of 'la st_index' is the absolute counter of series items added to that update collectio n, minus 1.</t> As long as a wraparound of the 'index' value has not occurred, the value of 'las t_index' is the absolute counter of series items added to that update collection , minus 1.</t>
</li> </li>
</ul> </ul>
<t>When processing a diff query using the "Cursor" extension, the valu es of 'index' are used as cursor information, as defined in <xref target="sec-us ing-cursor-diff-query-response"/>.</t> <t>When processing a diff query using the "Cursor" extension, the valu es of 'index' are used as cursor information, as defined in <xref target="sec-us ing-cursor-diff-query-response"/>.</t>
<t>For each requester's update collection, the AS also defines a const ant, positive integer MAX_DIFF_BATCH &lt;= MAX_N, whose value specifies the maxi mum number of diff entries to be included in a single diff query response. The s pecific value <bcp14>MAY</bcp14> depend on the specific registered device or adm inistrator associated with the update collection in question. If supporting the "Cursor" extension, the AS <bcp14>MUST</bcp14> provide registered devices and ad ministrators with the corresponding value of MAX_DIFF_BATCH, upon their registra tion (see <xref target="sec-registration"/>).</t> <t>For each requester's update collection, the AS also defines a const ant positive integer MAX_DIFF_BATCH &lt;= MAX_N, whose value specifies the maxim um number of diff entries to be included in a single diff query response. The sp ecific value <bcp14>MAY</bcp14> depend on the specific registered device or admi nistrator associated with the update collection in question. If supporting the " Cursor" extension, the AS <bcp14>MUST</bcp14> provide registered devices and adm inistrators with the corresponding value of MAX_DIFF_BATCH upon their registrati on (see <xref target="sec-registration"/>).</t>
</section> </section>
</section> </section>
<section anchor="sec-trl-endpoint-query-parameters"> <section anchor="sec-trl-endpoint-query-parameters">
<name>Query Parameters</name> <name>Query Parameters</name>
<t>A GET request to the TRL endpoint can include the following query par ameters. The AS <bcp14>MUST</bcp14> silently ignore unknown query parameters.</t > <t>A GET request to the TRL endpoint can include the following query par ameters. The AS <bcp14>MUST</bcp14> silently ignore unknown query parameters.</t >
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>'diff': if included, it indicates to perform a diff query of the TRL (see <xref target="ssec-trl-diff-query"/>). Its value <bcp14>MUST</bcp14> be either: </t> <t>'diff': if included, perform a diff query of the TRL (see <xref t arget="ssec-trl-diff-query"/>). Its value <bcp14>MUST</bcp14> be either: </t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>the integer 0, indicating that a (notification) response shou ld include as many diff entries as the AS can provide in the response; or</t> <t>the integer 0, indicating that a (notification) response shou ld include as many diff entries as the AS can provide in the response; or</t>
</li> </li>
<li> <li>
<t>a positive integer strictly greater than 0, indicating the ma ximum number of diff entries that a (notification) response should include.</t> <t>a positive integer strictly greater than 0, indicating the ma ximum number of diff entries that a (notification) response should include.</t>
</li> </li>
</ul> </ul>
<t> <t>
If the AS does not support diff queries, it ignores the 'diff' query parameter w hen present in the GET request, and proceeds like when processing a full query o f the TRL (see <xref target="ssec-trl-full-query"/>). </t> If the AS does not support diff queries, it ignores the 'diff' query parameter w hen present in the GET request and proceeds like when processing a full query of the TRL (see <xref target="ssec-trl-full-query"/>). </t>
<t> <t>
Otherwise, the AS <bcp14>MUST</bcp14> return a 4.00 (Bad Request) response in ca se the 'diff' query parameter of the GET request specifies a value that is neith er 0 nor a positive integer, irrespective of the presence of the 'cursor' parame ter and its value (see below). The response <bcp14>MUST</bcp14> have Content-For mat "application/concise-problem-details+cbor" and its payload is formatted as d efined in <xref target="sec-error-responses"/>. Within the Custom Problem Detail entry 'ace-trl-error', the value of the 'error-id' field <bcp14>MUST</bcp14> be set to 0 ("Invalid parameter value"), and the field 'cursor' <bcp14>MUST NOT</b cp14> be present.</t> Otherwise, the AS <bcp14>MUST</bcp14> return a 4.00 (Bad Request) response in ca se the 'diff' query parameter of the GET request specifies a value that is neith er 0 nor a positive integer, irrespective of the presence of the 'cursor' parame ter and its value (see below). The response <bcp14>MUST</bcp14> have Content-For mat set to "application/concise-problem-details+cbor", and its payload is format ted as defined in <xref target="sec-error-responses"/>. Within the Custom Proble m Detail entry 'ace-trl-error', the value of the 'error-id' field <bcp14>MUST</b cp14> be set to 0 ("Invalid parameter value"), and the 'cursor' field <bcp14>MUS T NOT</bcp14> be present.</t>
</li> </li>
<li> <li>
<t>'cursor': if included, it indicates to perform a diff query of th e TRL together with the "Cursor" extension, as defined in <xref target="sec-usin g-cursor-diff-query-response"/>. Its value <bcp14>MUST</bcp14> be either 0 or a positive integer. If the 'cursor' query parameter is included, then the 'diff' q uery parameter <bcp14>MUST</bcp14> also be included. </t> <t>'cursor': if included, perform a diff query of the TRL together w ith the "Cursor" extension, as defined in <xref target="sec-using-cursor-diff-qu ery-response"/>. Its value <bcp14>MUST</bcp14> be either 0 or a positive integer . If the 'cursor' query parameter is included, then the 'diff' query parameter < bcp14>MUST</bcp14> also be included. </t>
<t> <t>
If included, the 'cursor' query parameter specifies an unsigned integer value th at was provided by the AS in a previous response from the TRL endpoint (see <xre f target="sec-using-cursor-full-query-response"/>, <xref target="sec-using-curso r-diff-query-response-no-cursor"/>, and <xref target="sec-using-cursor-diff-quer y-response-cursor"/>). </t> If included, the 'cursor' query parameter specifies an unsigned integer value th at was provided by the AS in a previous response from the TRL endpoint (see Sect ions <xref target="sec-using-cursor-full-query-response" format="counter"/>, <xr ef target="sec-using-cursor-diff-query-response-no-cursor" format="counter"/>, a nd <xref target="sec-using-cursor-diff-query-response-cursor" format="counter"/> ). </t>
<t> <t>
If the AS does not support the "Cursor" extension, it ignores the 'cursor' query If the AS does not support the "Cursor" extension, it ignores the 'cu
parameter when present in the GET request. In such a case, the AS proceeds as s rsor' query parameter when present in the GET request. In such a case, the AS pr
pecified elsewhere in this document, i.e.: i) it performs a diff query of the TR oceeds as specified elsewhere in this document, that is:</t>
L (see <xref target="ssec-trl-diff-query"/>), if it supports diff queries and th <ol>
e 'diff' query parameter is present in the GET request; or ii) it performs a ful <li>it performs a diff query of the TRL (see <xref target="ssec-trl
l query of the TRL (see <xref target="ssec-trl-full-query"/>) otherwise. </t> -diff-query"/>), if it supports diff queries and the 'diff' query parameter is p
resent in the GET request; or</li>
<li>it performs a full query of the TRL (see <xref target="ssec-trl
-full-query"/>). </li></ol>
<t> <t>
If the AS supports both diff queries and the "Cursor" extension, and the GET req uest specifies the 'cursor' query parameter, then the AS <bcp14>MUST</bcp14> ret urn a 4.00 (Bad Request) response in case any of the conditions below holds. </ t> If the AS supports both diff queries and the "Cursor" extension, and the GET req uest specifies the 'cursor' query parameter, then the AS <bcp14>MUST</bcp14> ret urn a 4.00 (Bad Request) response in case any of the conditions below holds. </ t>
<t> <t>
The 4.00 (Bad Request) response <bcp14>MUST</bcp14> have Content-Format "applica tion/concise-problem-details+cbor" and its payload is formatted as defined in <x ref target="sec-error-responses"/>. </t> The 4.00 (Bad Request) response <bcp14>MUST</bcp14> have Content-Format set to " application/concise-problem-details+cbor", and its payload is formatted as defin ed in <xref target="sec-error-responses"/>. </t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>The GET request does not specify the 'diff' query parameter, irrespective of the value of the 'cursor' parameter. </t> <t>The GET request does not specify the 'diff' query parameter, irrespective of the value of the 'cursor' parameter. </t>
<t> <t>
Within the Custom Problem Detail entry 'ace-trl-error', the value of the 'error- id' field <bcp14>MUST</bcp14> be set to 1 ("Invalid set of parameters"), and the field 'cursor' <bcp14>MUST NOT</bcp14> be present.</t> Within the Custom Problem Detail entry 'ace-trl-error', the value of the 'error- id' field <bcp14>MUST</bcp14> be set to 1 ("Invalid set of parameters"), and the 'cursor' field <bcp14>MUST NOT</bcp14> be present.</t>
</li> </li>
<li> <li>
<t>The 'cursor' query parameter has a value that is neither 0 no r a positive integer, or it has a value strictly greater than MAX_INDEX (see <xr ef target="sec-trl-endpoint-supporting-cursor"/>). </t> <t>The 'cursor' query parameter has a value that is neither 0 no r a positive integer; otherwise, it has a value strictly greater than MAX_INDEX (see <xref target="sec-trl-endpoint-supporting-cursor"/>). </t>
<t> <t>
Within the Custom Problem Detail entry 'ace-trl-error', the value of the 'error- Within the Custom Problem Detail entry 'ace-trl-error', the value
id' field <bcp14>MUST</bcp14> be set to 0 ("Invalid parameter value"). The entry of the 'error-id' field <bcp14>MUST</bcp14> be set to 0 ("Invalid parameter val
'ace-trl-error' <bcp14>MUST</bcp14> include the field 'cursor', whose value is ue"). The entry 'ace-trl-error' <bcp14>MUST</bcp14> include the 'cursor' field,
either: the CBOR simple value <tt>null</tt> (0xf6), if the update collection ass whose value is either:</t>
ociated with the requester is empty; or the corresponding current value of 'last <ul>
_index' otherwise.</t> <li>the CBOR simple value <tt>null</tt> (0xf6), if the update c
ollection associated with the requester is empty; or</li>
<li>the corresponding current value of 'last_index'.</li></ul>
</li> </li>
<li> <li>
<t>All of the following hold: the update collection associated w <!--[rfced] Please clarify what "it" refers to in the following:
ith the requester is not empty; no wrap-around of its 'index' value has occurred
; and the 'cursor' query parameter has a value strictly greater than the current Original:
'last_index' on the update collection (see <xref target="sec-trl-endpoint-suppo
rting-cursor"/>). </t> - All of the following hold: the update collection associated
with the requester is not empty; no wrap-around of its 'index'
value has occurred; and the 'cursor' query parameter has a
value strictly greater than the current 'last_index' on the
update collection (see Section 6.2.1).
-->
<t>All of the following hold: the update collection associated w
ith the requester is not empty; no wraparound of its 'index' value has occurred;
and the 'cursor' query parameter has a value strictly greater than the current
'last_index' on the update collection (see <xref target="sec-trl-endpoint-suppor
ting-cursor"/>). </t>
<t> <t>
Within the Custom Problem Detail entry 'ace-trl-error', the value of the 'error- id' field <bcp14>MUST</bcp14> be set to 2 ("Out of bound cursor value"), and the field 'cursor' <bcp14>MUST NOT</bcp14> be present.</t> Within the Custom Problem Detail entry 'ace-trl-error', the value of the 'error- id' field <bcp14>MUST</bcp14> be set to 2 ("Out of bound cursor value"), and the 'cursor' field <bcp14>MUST NOT</bcp14> be present.</t>
</li> </li>
</ul> </ul>
</li> </li>
</ul> </ul>
</section> </section>
</section> </section>
<section anchor="ssec-trl-full-query"> <section anchor="ssec-trl-full-query">
<name>Full Query of the TRL</name> <name>Full Query of the TRL</name>
<t>In order to produce a (notification) response to a GET request asking f or a full query of the TRL, the AS performs the following actions.</t> <t>In order to produce a (notification) response to a GET request asking f or a full query of the TRL, the AS performs the following actions:</t>
<ol spacing="normal" type="1"><li> <ol spacing="normal" type="1"><li>
<t>From the TRL, the AS builds a set HASHES such that: </t> <t>From the TRL, the AS builds a set of HASHES such that: </t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>If the requester is a registered device, HASHES specifies the t oken hashes currently in the TRL and associated with the access tokens pertainin g to that registered device. The AS can always use the authenticated identity of the registered device to perform the necessary filtering on the TRL content.</t > <t>If the requester is a registered device, HASHES specifies the t oken hashes currently in the TRL and associated with the access tokens pertainin g to that registered device. The AS can always use the authenticated identity of the registered device to perform the necessary filtering on the TRL content.</t >
</li> </li>
<li> <li>
<t>If the requester is an administrator, HASHES specifies all the token hashes currently in the TRL.</t> <t>If the requester is an administrator, HASHES specifies all the token hashes currently in the TRL.</t>
</li> </li>
</ul> </ul>
</li> </li>
<li> <li>
<t>The AS sends a 2.05 (Content) response to the requester. The respon se <bcp14>MUST</bcp14> have Content-Format "application/ace-trl+cbor". The paylo ad of the response is a CBOR map, which <bcp14>MUST</bcp14> be formatted as foll ows. </t> <t>The AS sends a 2.05 (Content) response to the requester. The respon se <bcp14>MUST</bcp14> have Content-Format set to "application/ace-trl+cbor". Th e payload of the response is a CBOR map, which <bcp14>MUST</bcp14> be formatted as follows. </t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>The 'full_set' parameter <bcp14>MUST</bcp14> be included and sp ecifies a CBOR array 'full_set_value'. Each element of 'full_set_value' is a CBO R byte string, with value one of the token hashes from the set HASHES. If the se t HASHES is empty, the 'full_set' parameter specifies the empty CBOR array. </t> <t>The 'full_set' parameter <bcp14>MUST</bcp14> be included and sp ecifies a CBOR array 'full_set_value'. Each element of 'full_set_value' is a CBO R byte string with a value of one of the token hashes from the set HASHES. If th e set HASHES is empty, the 'full_set' parameter specifies the empty CBOR array. </t>
<t> <t>
The CBOR array <bcp14>MUST</bcp14> be treated as a set, i.e., the order of its e lements has no meaning.</t> The CBOR array <bcp14>MUST</bcp14> be treated as a set, i.e., the order of its e lements has no meaning.</t>
</li> </li>
<li> <li>
<t>The 'cursor' parameter <bcp14>MUST</bcp14> be included if the A S supports both diff queries and the related "Cursor" extension (see <xref targe t="sec-trl-endpoint-supporting-diff-queries"/> and <xref target="sec-trl-endpoin t-supporting-cursor"/>). Its value is set as specified in <xref target="sec-usin g-cursor-full-query-response"/>, and provides the requester with information for performing a follow-up diff query using the "Cursor" extension (see <xref targe t="sec-using-cursor-diff-query-response"/>). </t> <t>The 'cursor' parameter <bcp14>MUST</bcp14> be included if the A S supports both diff queries and the related "Cursor" extension (see Sections <x ref target="sec-trl-endpoint-supporting-diff-queries" format="counter"/> and <xr ef target="sec-trl-endpoint-supporting-cursor" format="counter"/>). Its value is set as specified in <xref target="sec-using-cursor-full-query-response"/> and p rovides the requester with information for performing a follow-up diff query usi ng the "Cursor" extension (see <xref target="sec-using-cursor-diff-query-respons e"/>). </t>
<t> <t>
If the AS does not support both diff queries and the "Cursor" extension, this pa rameter <bcp14>MUST NOT</bcp14> be included. In case the requester does not supp ort both diff queries and the "Cursor" extension, it <bcp14>MUST</bcp14> silentl y ignore the 'cursor' parameter if present.</t> If the AS does not support both diff queries and the "Cursor" extension, this pa rameter <bcp14>MUST NOT</bcp14> be included. In case the requester does not supp ort both diff queries and the "Cursor" extension, it <bcp14>MUST</bcp14> silentl y ignore the 'cursor' parameter if present.</t>
</li> </li>
</ul> </ul>
</li> </li>
</ol> </ol>
<t><xref target="cddl-full"/> provides the CDDL definition <xref target="R FC8610"/> of the CBOR array 'full_set_value' specified in the response from the AS, as value of the 'full_set' parameter.</t> <t><xref target="cddl-full"/> provides the CDDL definition <xref target="R FC8610"/> of the CBOR array 'full_set_value' specified in the response from the AS as the value of the 'full_set' parameter.</t>
<figure anchor="cddl-full"> <figure anchor="cddl-full">
<name>CDDL definition of 'full_set_value'</name> <name>CDDL Definition of 'full_set_value'</name>
<artwork type="CDDL" align="left"><![CDATA[ <sourcecode type="CDDL"><![CDATA[
token_hash = bytes token_hash = bytes
full_set_value = [* token_hash] full_set_value = [* token_hash]
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t><xref target="response-full"/> shows an example response from the AS, f ollowing a full query request to the TRL endpoint. In this example, the AS does not support diff queries nor the "Cursor" extension, hence the 'cursor' paramete r is not included in the payload of the response. Also, full token hashes are om itted for brevity.</t> <t><xref target="response-full"/> shows an example response from the AS fo llowing a full query request to the TRL endpoint. In this example, the AS does n ot support diff queries nor the "Cursor" extension; hence the 'cursor' parameter is not included in the payload of the response. Also, full token hashes are omi tted for brevity.</t>
<figure anchor="response-full"> <figure anchor="response-full">
<name>Example of response following a full query request to the TRL endp <name>Example of Response Following a Full Query Request to the TRL Endp
oint</name> oint</name>
<artwork align="left"><![CDATA[ <sourcecode type=""><![CDATA[
Header: Content (Code=2.05) Header: Content (Code=2.05)
Content-Format: application/ace-trl+cbor Content-Format: application/ace-trl+cbor
Payload: Payload:
{ {
e'full_set' : [ e'full_set' : [
h'01fa51cc...4819', / elided for brevity / h'01fa51cc...4819', / elided for brevity /
h'01748190...223d' / elided for brevity / h'01748190...223d' / elided for brevity /
] ]
} }
]]></artwork> ]]></sourcecode>
</figure> </figure>
</section> </section>
<section anchor="ssec-trl-diff-query"> <section anchor="ssec-trl-diff-query">
<name>Diff Query of the TRL</name> <name>Diff Query of the TRL</name>
<t>In order to produce a (notification) response to a GET request asking f <t>In order to produce a (notification) response to a GET request asking f
or a diff query of the TRL, the AS performs the following actions.</t> or a diff query of the TRL, the AS performs the following actions:</t>
<t>Note that, if the AS supports both diff queries and the related "Cursor <t>Note that, if the AS supports both diff queries and the related "Cursor
" extension, the steps 3 and 4 defined below are extended as defined in <xref ta " extension, steps 3 and 4 defined below are extended as defined in <xref target
rget="sec-using-cursor-diff-query-response"/>.</t> ="sec-using-cursor-diff-query-response"/>.</t>
<ol spacing="normal" type="1"><li> <ol spacing="normal" type="1"><li>
<t>The AS defines the positive integer NUM as follows. If the value N specified in the 'diff' query parameter in the GET request is equal to 0 or grea ter than the pre-defined positive integer MAX_N (see <xref target="sec-trl-endpo int-supporting-diff-queries"/>), then NUM takes the value of MAX_N. Otherwise, N UM takes N.</t> <t>The AS defines the positive integer NUM as follows: if the value N specified in the 'diff' query parameter in the GET request is equal to 0 or grea ter than the predefined positive integer MAX_N (see <xref target="sec-trl-endpoi nt-supporting-diff-queries"/>), then NUM takes the value of MAX_N. Otherwise, NU M takes N.</t>
</li> </li>
<li> <li>
<t>The AS determines U = min(NUM, SIZE), where SIZE &lt;= MAX_N. In pa rticular, SIZE is the number of diff entries currently stored in the requester's update collection.</t> <t>The AS determines U = min(NUM, SIZE), where SIZE &lt;= MAX_N. In pa rticular, SIZE is the number of diff entries currently stored in the requester's update collection.</t>
</li> </li>
<li> <li>
<t>The AS prepares U diff entries. If U is equal to 0 (e.g., because S IZE is equal to 0 at step 2), then no diff entries are prepared. </t> <t>The AS prepares U diff entries. If U is equal to 0 (e.g., because S IZE is equal to 0 at step 2), then no diff entries are prepared. </t>
<t> <t>
The prepared diff entries are related to the U most recent TRL updates pertainin g to the requester, as maintained in the update collection for that requester (s ee <xref target="sec-trl-endpoint-supporting-diff-queries"/>). In particular, th e first diff entry refers to the most recent of such updates, the second diff en try refers to the second from last of such updates, and so on. </t> The prepared diff entries are related to the U most recent TRL updates pertainin g to the requester, as maintained in the update collection for that requester (s ee <xref target="sec-trl-endpoint-supporting-diff-queries"/>). In particular, th e first diff entry refers to the most recent of such updates, the second diff en try refers to the second from last of such updates, and so on. </t>
<t> <t>
Each diff entry is a CBOR array 'diff_entry', which includes the following two e Each diff entry is a CBOR array 'diff_entry', which includes the follow
lements. </t> ing two elements:</t>
<ul spacing="normal">
<!--[rfced] This sentence doesn't parse. Please rephrase especially
the part with "with value the token hash of an access token".
Note similar text is in both bullets under number 3 in Section 8.
Please let us know if the same fix may be applied in both places
or if different changes are required.
Original:
Each element of the array is a CBOR byte string, with value the token
hash of an access token such that: it pertained to the requester; and
it was removed from the TRL during the update associated with the diff
entry.
-->
<ol type="a" spacing="normal">
<li> <li>
<t>The first element is a 'trl_patch' set of token hashes, encoded as a CBOR array 'removed'. Each element of the array is a CBOR byte string, wit h value the token hash of an access token such that: it pertained to the request er; and it was removed from the TRL during the update associated with the diff e ntry.</t> <t>A 'trl_patch' set of token hashes encoded as a CBOR array 'remo ved'. Each element of the array is a CBOR byte string with value the token hash of an access token such that it pertains to the requester and was removed from t he TRL during the update associated with the diff entry.</t>
</li> </li>
<li> <li>
<t>The second element is a 'trl_patch' set of token hashes, encode d as a CBOR array 'added'. Each element of the array is a CBOR byte string, with value the token hash of an access token such that: it pertains to the requester ; and it was added to the TRL during the update associated with the diff entry.< /t> <t>A 'trl_patch' set of token hashes encoded as a CBOR array 'adde d'. Each element of the array is a CBOR byte string with value the token hash of an access token such that it pertains to the requester and was added to the TRL during the update associated with the diff entry.</t>
</li> </li>
</ul> </ol>
<t> <t>
The CBOR arrays 'removed' and 'added' <bcp14>MUST</bcp14> be treated as sets, i. e., the order of their elements has no meaning.</t> The CBOR arrays 'removed' and 'added' <bcp14>MUST</bcp14> be treated as sets, i. e., the order of their elements has no meaning.</t>
</li> </li>
<li> <li>
<t>The AS prepares a 2.05 (Content) response for the requester. The re sponse <bcp14>MUST</bcp14> have Content-Format "application/ace-trl+cbor". The p ayload of the response is a CBOR map, which <bcp14>MUST</bcp14> be formatted as follows. </t> <t>The AS prepares a 2.05 (Content) response for the requester. The re sponse <bcp14>MUST</bcp14> have Content-Format set to "application/ace-trl+cbor" . The payload of the response is a CBOR map, which <bcp14>MUST</bcp14> be format ted as follows:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>The 'diff_set' parameter <bcp14>MUST</bcp14> be present and spe cifies a CBOR array 'diff_set_value' of U elements. Each element of 'diff_set_va lue' specifies one of the CBOR arrays 'diff_entry' prepared above as a diff entr y. Note that U might have value 0, in which case 'diff_set_value' is the empty C BOR array. </t> <t>The 'diff_set' parameter <bcp14>MUST</bcp14> be present and spe cifies a CBOR array 'diff_set_value' of U elements. Each element of 'diff_set_va lue' specifies one of the CBOR arrays 'diff_entry' prepared above as a diff entr y. Note that U might have a value of 0; in this case, 'diff_set_value' is the em pty CBOR array. </t>
<t> <t>
Within 'diff_set_value', the CBOR arrays 'diff_entry' <bcp14>MUST</bcp14> be sor ted to reflect the corresponding updates to the TRL in reverse chronological ord er. That is, the first 'diff_entry' element of 'diff_set_value' relates to the m ost recent TRL update pertaining to the requester. The second 'diff_entry' eleme nt relates to the second from last most recent TRL update pertaining to the requ ester, and so on.</t> Within 'diff_set_value', any 'diff_entry' CBOR arrays <bcp14>MUST</bcp14> be so rted to reflect the corresponding updates to the TRL in reverse chronological or der. That is, the first 'diff_entry' element of 'diff_set_value' relates to the most recent TRL update pertaining to the requester. The second 'diff_entry' elem ent relates to the second-to-last most recent TRL update pertaining to the reque ster, and so on.</t>
</li> </li>
<li> <li>
<t>The 'cursor' parameter and the 'more' parameter <bcp14>MUST</bc p14> be included if the AS supports both diff queries and the related "Cursor" e xtension (see <xref target="sec-trl-endpoint-supporting-cursor"/>). Their values are set as specified in <xref target="sec-using-cursor-diff-query-response"/>, and provide the requester with information for performing a follow-up query of t he TRL (see <xref target="sec-using-cursor-diff-query-response"/>). </t> <t>The 'cursor' parameter and the 'more' parameter <bcp14>MUST</bc p14> be included if the AS supports both diff queries and the related "Cursor" e xtension (see <xref target="sec-trl-endpoint-supporting-cursor"/>). Their values are set as specified in <xref target="sec-using-cursor-diff-query-response"/> a nd provide the requester with information for performing a follow-up query of th e TRL (see <xref target="sec-using-cursor-diff-query-response"/>). </t>
<t> <t>
In case the AS supports diff queries but not the "Cursor" extension, these param eters <bcp14>MUST NOT</bcp14> be included. In case the requester supports diff q ueries but not the "Cursor" extension, it <bcp14>MUST</bcp14> silently ignore th e 'cursor' parameter and the 'more' parameter if present.</t> In case the AS supports diff queries but not the "Cursor" extension, these param eters <bcp14>MUST NOT</bcp14> be included, and the AS <bcp14>MUST</bcp14> silent ly ignore the 'cursor' parameter and the 'more' parameter if present.</t>
</li> </li>
</ul> </ul>
</li> </li>
</ol> </ol>
<t><xref target="cddl-diff"/> provides the CDDL definition <xref target="R FC8610"/> of the CBOR array 'diff_set_value' specified in the response from the AS, as value of the 'diff_set' parameter.</t> <t><xref target="cddl-diff"/> provides the CDDL definition <xref target="R FC8610"/> of the CBOR array 'diff_set_value' specified in the response from the AS, as the value of the 'diff_set' parameter.</t>
<figure anchor="cddl-diff"> <figure anchor="cddl-diff">
<name>CDDL definition of 'diff_set_value'</name> <name>CDDL Definition of 'diff_set_value'</name>
<artwork type="CDDL" align="left"><![CDATA[ <sourcecode type="CDDL"><![CDATA[
token_hash = bytes token_hash = bytes
trl_patch = [* token_hash] trl_patch = [* token_hash]
diff_entry = [removed: trl_patch, added: trl_patch] diff_entry = [removed: trl_patch, added: trl_patch]
diff_set_value = [* diff_entry] diff_set_value = [* diff_entry]
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t><xref target="response-diff"/> shows an example response from the AS, f ollowing a diff query request to the TRL endpoint, where U = 3 diff entries are specified. In this example, the AS does not support the "Cursor" extension, henc e the 'cursor' parameter and the 'more' parameter are not included in the payloa d of the response. Also, full token hashes are omitted for brevity.</t> <t><xref target="response-diff"/> shows an example response from the AS fo llowing a diff query request to the TRL endpoint, where U = 3 diff entries are s pecified. In this example, the AS does not support the "Cursor" extension; hence , the 'cursor' parameter and the 'more' parameter are not included in the payloa d of the response. Also, full token hashes are omitted for brevity.</t>
<figure anchor="response-diff"> <figure anchor="response-diff">
<name>Example of response following a diff query request to the TRL endp <name>Example of Response Following a Diff Query Request to the TRL Endp
oint</name> oint</name>
<artwork align="left"><![CDATA[ <sourcecode type=""><![CDATA[
Header: Content (Code=2.05) Header: Content (Code=2.05)
Content-Format: application/ace-trl+cbor Content-Format: application/ace-trl+cbor
Payload: Payload:
{ {
e'diff_set' : [ e'diff_set' : [
[ [
[ h'01fa51cc...0f6a', / elided for brevity / [ h'01fa51cc...0f6a', / elided for brevity /
h'01748190...8bce' / elided for brevity / h'01748190...8bce' / elided for brevity /
], ],
[ h'01cdf1ca...563d', / elided for brevity / [ h'01cdf1ca...563d', / elided for brevity /
skipping to change at line 950 skipping to change at line 1234
[] []
], ],
[ [
[], [],
[ h'01ca986f...ffc1', / elided for brevity / [ h'01ca986f...ffc1', / elided for brevity /
h'01fe1a2b...def0' / elided for brevity / h'01fe1a2b...def0' / elided for brevity /
] ]
] ]
] ]
} }
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t><xref target="sec-series-pattern"/> discusses how performing a diff que ry of the TRL is in fact a usage example of the Series Transfer Pattern defined in <xref target="I-D.bormann-t2trg-stp"/>.</t> <t><xref target="sec-series-pattern"/> discusses how performing a diff que ry of the TRL is, in fact, a usage example of the Series Transfer Pattern define d in <xref target="I-D.bormann-t2trg-stp"/>.</t>
</section> </section>
<section anchor="sec-using-cursor"> <section anchor="sec-using-cursor">
<name>Response Messages when Using the "Cursor" Extension</name> <name>Response Messages when Using the "Cursor" Extension</name>
<t>If the AS supports both diff queries and the "Cursor" extension, it com <t>If the AS supports both diff queries and the "Cursor" extension, it com
poses a response to a full query request or diff query request as defined in <xr poses a response to a full query request or diff query request as defined in Sec
ef target="sec-using-cursor-full-query-response"/> and <xref target="sec-using-c tions <xref target="sec-using-cursor-full-query-response" format="counter"/> and
ursor-diff-query-response"/>, respectively.</t> <xref target="sec-using-cursor-diff-query-response" format="counter"/>, respect
<t>The exact format of the response depends on the request being a full qu ively.</t>
ery or diff query request, on the presence of the 'diff' and 'cursor' query para <t>The exact format of the response depends on:</t>
meters and their values in the diff query request, and on the current status of <ul>
the update collection associated with the requester.</t> <li>the request being a full query or diff query request,</li>
<li>the presence of the 'diff' and 'cursor' query parameters and their va
lues in the diff query request, and</li>
<li>the current status of the update collection associated with the reque
ster.</li></ul>
<t>Error handling and the possible resulting error responses are as define d in <xref target="sec-trl-endpoint-query-parameters"/>.</t> <t>Error handling and the possible resulting error responses are as define d in <xref target="sec-trl-endpoint-query-parameters"/>.</t>
<section anchor="sec-using-cursor-full-query-response"> <section anchor="sec-using-cursor-full-query-response">
<name>Response to Full Query</name> <name>Response to Full Query</name>
<t>When processing a full query request to the TRL endpoint, the AS comp oses a response as defined in <xref target="ssec-trl-full-query"/>.</t> <t>When processing a full query request to the TRL endpoint, the AS comp oses a response as defined in <xref target="ssec-trl-full-query"/>.</t>
<t>In particular, the 'cursor' parameter included in the CBOR map carrie d in the response payload specifies either the CBOR simple value <tt>null</tt> ( 0xf6) or a CBOR unsigned integer.</t> <t>In particular, the 'cursor' parameter included in the CBOR map carrie d in the response payload specifies either the CBOR simple value <tt>null</tt> ( 0xf6) or a CBOR unsigned integer.</t>
<t>The 'cursor' parameter <bcp14>MUST</bcp14> specify the CBOR simple va <t>The 'cursor' parameter <bcp14>MUST</bcp14> specify the CBOR simple va
lue <tt>null</tt> in case there are currently no TRL updates pertaining to the r lue <tt>null</tt> (0xf6) in case there are currently no TRL updates pertaining t
equester, i.e., the update collection for that requester is empty. This is the c o the requester, i.e., the update collection for that requester is empty. This i
ase from when the requester registers at the AS until the first update pertainin s the case from when the requester registers at the AS until the first update pe
g to that requester occurs to the TRL.</t> rtaining to that requester occurs to the TRL.</t>
<t>Otherwise, the 'cursor' parameter <bcp14>MUST</bcp14> specify a CBOR
unsigned integer. This <bcp14>MUST</bcp14> take the 'index' value of the last se <!--[rfced] Please confirm our update to use the antecedent instead of
ries item in the update collection associated with the requester (see <xref targ "This" for clarity.
et="sec-trl-endpoint-supporting-cursor"/>), as corresponding to the most recent
TRL update pertaining to the requester. Such a value is in fact the current valu Original:
e of 'last_index' for the update collection associated with the requester.</t> Otherwise, the 'cursor' parameter MUST specify a CBOR unsigned
integer. This MUST take the 'index' value of the last series item in
the update collection associated with the requester (see Section
6.2.1), as corresponding to the most recent TRL update pertaining to
the requester.
Perhaps:
Otherwise, the 'cursor' parameter MUST specify a CBOR unsigned
integer. This integer MUST take the 'index' value of the last series item in
the update collection associated with the requester (see Section
6.2.1) as corresponding to the most recent TRL update pertaining to
the requester.
-->
<t>Otherwise, the 'cursor' parameter <bcp14>MUST</bcp14> specify a CBOR
unsigned integer. This <bcp14>MUST</bcp14> take the 'index' value of the last se
ries item in the update collection associated with the requester (see <xref targ
et="sec-trl-endpoint-supporting-cursor"/>) as corresponding to the most recent T
RL update pertaining to the requester. In fact, such a value is the current valu
e of 'last_index' for the update collection associated with the requester.</t>
</section> </section>
<section anchor="sec-using-cursor-diff-query-response"> <section anchor="sec-using-cursor-diff-query-response">
<name>Response to Diff Query</name> <name>Response to Diff Query</name>
<t>When processing a diff query request to the TRL endpoint, the AS comp oses a response as defined in the following.</t> <t>When processing a diff query request to the TRL endpoint, the AS comp oses a response as defined in the following subsections.</t>
<section anchor="sec-using-cursor-diff-query-response-empty"> <section anchor="sec-using-cursor-diff-query-response-empty">
<name>Empty Collection</name> <name>Empty Collection</name>
<t>If the update collection associated with the requester has no eleme <t>If the update collection associated with the requester has no eleme
nts, the AS returns a 2.05 (Content) response. The response <bcp14>MUST</bcp14> nts, the AS returns a 2.05 (Content) response. The response <bcp14>MUST</bcp14>
have Content-Format "application/ace-trl+cbor" and its payload <bcp14>MUST</bcp1 have Content-Format set to "application/ace-trl+cbor", and its payload <bcp14>MU
4> be a CBOR map formatted as follows.</t> ST</bcp14> be a CBOR map formatted as follows:</t>
<!--[rfced] *ADs - please review the following sentences that may lead
to two interpretations of what the BCP 14 language applies to
(due to the use of "and"). If the suggested text is not
accurate, we suggest breaking up these sentences or rewording for
clarity. Note that some of the following sentences appear in
more than one location.
Original:
* The 'diff_set' parameter MUST be included and specifies the empty
CBOR array.
* The 'cursor' parameter MUST be included and specifies the CBOR
simple value null (0xf6).
* The 'more' parameter MUST be included and specifies the CBOR
simple value false (0xf4).
Perhaps:
* The 'diff_set' parameter MUST be included and MUST specify the empty
CBOR array.
* The 'cursor' parameter MUST be included and MUST specify the CBOR
simple value null (0xf6).
* The 'more' parameter MUST be included and MUST specify the CBOR
simple value false (0xf4).
Original:
* The 'full_set' parameter MUST be included and specifies a CBOR
array 'full_set_value'.
Perhaps:
* The 'full_set' parameter MUST be included and MUST specify a CBOR
array 'full_set_value'.
Original:
* The 'diff_set' parameter MUST be present and specifies a CBOR
array 'diff_set_value' of U elements.
Perhaps:
* The 'diff_set' parameter MUST be present and MUST specify a CBOR
array 'diff_set_value' of U elements.
Original:
* The 'diff_set' parameter MUST be present and specifies a CBOR
array 'diff_set_value' of U elements.
Perhaps:
* The 'diff_set' parameter MUST be present and MUST specify a CBOR
array 'diff_set_value' of U elements.
Original:
- The 'cursor' parameter MUST be present and specifies a CBOR
unsigned integer.
Perhaps:
- The 'cursor' parameter MUST be present and MUST specify a CBOR
unsigned integer.
Original:
- The 'more' parameter MUST be present and MUST specify the CBOR
simple value false (0xf4) if U <= MAX_DIFF_BATCH, or the CBOR
simple value true (0xf5) otherwise.
Perhaps:
- The 'more' parameter MUST be present and MUST specify the CBOR
simple value false (0xf4) if U <= MAX_DIFF_BATCH; otherwise, it
MUST specify the CBOR simple value true (0xf5).
Original:
o The 'more' parameter MUST be present and MUST specify the
CBOR simple value false (0xf4) if SUB_U <= MAX_DIFF_BATCH,
or the CBOR simple value true (0xf5) otherwise.
Perhaps:
o The 'more' parameter MUST be present and MUST specify the
CBOR simple value false (0xf4) if SUB_U <= MAX_DIFF_BATCH;
otherwise, it MUST specify the CBOR simple value true (0xf5).
-->
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>The 'diff_set' parameter <bcp14>MUST</bcp14> be included and sp ecifies the empty CBOR array.</t> <t>The 'diff_set' parameter <bcp14>MUST</bcp14> be included and sp ecifies the empty CBOR array.</t>
</li> </li>
<li> <li>
<t>The 'cursor' parameter <bcp14>MUST</bcp14> be included and spec ifies the CBOR simple value <tt>null</tt> (0xf6).</t> <t>The 'cursor' parameter <bcp14>MUST</bcp14> be included and spec ifies the CBOR simple value <tt>null</tt> (0xf6).</t>
</li> </li>
<li> <li>
<t>The 'more' parameter <bcp14>MUST</bcp14> be included and specif ies the CBOR simple value <tt>false</tt> (0xf4).</t> <t>The 'more' parameter <bcp14>MUST</bcp14> be included and specif ies the CBOR simple value <tt>false</tt> (0xf4).</t>
</li> </li>
</ul> </ul>
<t>Note that the above applies when the update collection associated w ith the requester has no elements, regardless of whether the 'cursor' query para meter is included or not in the diff query request, and irrespective of the spec ified unsigned integer value if present.</t> <t>Note that the above applies when the update collection associated w ith the requester has no elements, regardless of whether or not the 'cursor' que ry parameter is included in the diff query request and irrespective of the speci fied unsigned integer value if present.</t>
</section> </section>
<section anchor="sec-using-cursor-diff-query-response-no-cursor"> <section anchor="sec-using-cursor-diff-query-response-no-cursor">
<name>Cursor Not Specified in the Diff Query Request</name> <name>Cursor Not Specified in the Diff Query Request</name>
<t>If the update collection associated with the requester is not empty and the diff query request does not include the 'cursor' query parameter, the A S performs the actions defined in <xref target="ssec-trl-diff-query"/>, with the following differences.</t> <t>If the update collection associated with the requester is not empty and the diff query request does not include the 'cursor' query parameter, the A S performs the actions defined in <xref target="ssec-trl-diff-query"/>, with the following differences:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>At step 3, the AS considers the value MAX_DIFF_BATCH (see <xref target="sec-trl-endpoint-supporting-cursor"/>), and prepares L = min(U, MAX_DIF F_BATCH) diff entries. </t> <t>At step 3, the AS considers the value MAX_DIFF_BATCH (see <xref target="sec-trl-endpoint-supporting-cursor"/>) and prepares L = min(U, MAX_DIFF _BATCH) diff entries. </t>
<t> <t>
If U &lt;= MAX_DIFF_BATCH, the prepared diff entries are the last series items i n the update collection associated with the requester, corresponding to the L mo st recent TRL updates pertaining to the requester. </t> If U &lt;= MAX_DIFF_BATCH, the prepared diff entries are the last series items i n the update collection associated with the requester, corresponding to the L mo st recent TRL updates pertaining to the requester. </t>
<t> <t>
If U &gt; MAX_DIFF_BATCH, the prepared diff entries are the eldest of the last U series items in the update collection associated with the requester, as corresp onding to the first L of the U most recent TRL updates pertaining to the request er.</t> If U &gt; MAX_DIFF_BATCH, the prepared diff entries are the eldest of the last U series items in the update collection associated with the requester, as corresp onding to the first L of the U most recent TRL updates pertaining to the request er.</t>
</li> </li>
<li> <li>
<t>At step 4, the CBOR map to carry in the payload of the 2.05 (Co ntent) response <bcp14>MUST</bcp14> be formatted as follows. </t> <t>At step 4, the CBOR map to carry in the payload of the 2.05 (Co ntent) response <bcp14>MUST</bcp14> be formatted as follows: </t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>The 'diff_set' parameter <bcp14>MUST</bcp14> be present and specifies a CBOR array 'diff_set_value' of L elements. Each element of 'diff_se t_value' specifies one of the CBOR arrays 'diff_entry' prepared as a diff entry. </t> <t>The 'diff_set' parameter <bcp14>MUST</bcp14> be present and specifies a CBOR array 'diff_set_value' of L elements. Each element of 'diff_se t_value' specifies one of the CBOR arrays 'diff_entry' prepared as a diff entry. </t>
</li> </li>
<li> <li>
<t>The 'cursor' parameter <bcp14>MUST</bcp14> be present and s pecifies a CBOR unsigned integer. This <bcp14>MUST</bcp14> take the 'index' valu e of the series item of the update collection included as first diff entry in th e 'diff_set_value' CBOR array, which is specified by the 'diff_set' parameter. T hat is, the 'cursor' parameter takes the 'index' value of the series item in the update collection corresponding to the most recent TRL update pertaining to the requester and returned in this diff query response. </t> <t>The 'cursor' parameter <bcp14>MUST</bcp14> be present and s pecifies a CBOR unsigned integer. This <bcp14>MUST</bcp14> take the 'index' valu e of the series item of the update collection included as first diff entry in th e 'diff_set_value' CBOR array, which is specified by the 'diff_set' parameter. T hat is, the 'cursor' parameter takes the 'index' value of the series item in the update collection corresponding to the most recent TRL update pertaining to the requester and returned in this diff query response. </t>
<t> <t>
Note that the 'cursor' parameter takes the same 'index' value of the last series item in the update collection when U &lt;= MAX_DIFF_BATCH.</t> Note that the 'cursor' parameter takes the same 'index' value of the last series item in the update collection when U &lt;= MAX_DIFF_BATCH.</t>
</li> </li>
<li> <li>
<t>The 'more' parameter <bcp14>MUST</bcp14> be present and <bc p14>MUST</bcp14> specify the CBOR simple value <tt>false</tt> (0xf4) if U &lt;= MAX_DIFF_BATCH, or the CBOR simple value <tt>true</tt> (0xf5) otherwise.</t> <t>The 'more' parameter <bcp14>MUST</bcp14> be present and <bc p14>MUST</bcp14> specify the CBOR simple value <tt>false</tt> (0xf4) if U &lt;= MAX_DIFF_BATCH or the CBOR simple value <tt>true</tt> (0xf5) otherwise.</t>
</li> </li>
</ul> </ul>
</li> </li>
</ul> </ul>
<t>If the 'more' parameter in the payload of the received 2.05 (Conten t) response has value <tt>true</tt>, the requester can send a follow-up diff que ry request including the 'cursor' query parameter, with the same value of the 'c ursor' parameter specified in this diff query response. As defined in <xref targ et="sec-using-cursor-diff-query-response-cursor"/>, this would result in the AS transferring the following subset of series items as diff entries, thus resuming from where interrupted in the previous transfer.</t> <t>If the 'more' parameter in the payload of the received 2.05 (Conten t) response has a value of <tt>true</tt>, the requester can send a follow-up dif f query request including the 'cursor' query parameter with the same value of th e 'cursor' parameter specified in this diff query response. As defined in <xref target="sec-using-cursor-diff-query-response-cursor"/>, this would result in the AS transferring the following subset of series items as diff entries, thus resu ming from where interrupted in the previous transfer.</t>
</section> </section>
<section anchor="sec-using-cursor-diff-query-response-cursor"> <section anchor="sec-using-cursor-diff-query-response-cursor">
<name>Cursor Specified in the Diff Query Request</name> <name>Cursor Specified in the Diff Query Request</name>
<t>If the update collection associated with the requester is not empty <t>If the update collection associated with the requester is not empty
and the diff query request includes the 'cursor' query parameter with value P, and the diff query request includes the 'cursor' query parameter with value P,
the AS proceeds as follows, depending on which of the following two cases hold.< the AS proceeds as follows, depending on which of the following two cases hold:<
/t> /t>
<ul spacing="normal"> <ol spacing="normal" type='Case %C:'>
<li> <li>
<t>Case A - The series item X with 'index' having value P and the series item Y with 'index' having value (P + 1) % (MAX_INDEX + 1) are both not f ound in the update collection associated with the requester. This occurs when th e item Y (and possibly further ones after it) has been previously removed from t he update collection for that requester (see step 5 at <xref target="sec-trl-end point-supporting-diff-queries"/>). </t> <t>The series item X with 'index' having value P and the series it em Y with 'index' having value (P + 1) % (MAX_INDEX + 1) are both not found in t he update collection associated with the requester. This occurs when the item Y (and possibly further ones after it) has been previously removed from the update collection for that requester (see step 5 at <xref target="sec-trl-endpoint-sup porting-diff-queries"/>). </t>
<t> <t>
In this case, the AS returns a 2.05 (Content) response. The response <bcp14>MUST </bcp14> have Content-Format "application/ace-trl+cbor" and its payload <bcp14>M UST</bcp14> be a CBOR map formatted as follows. </t> In this case, the AS returns a 2.05 (Content) response. The response <bcp14>MUST </bcp14> have Content-Format set to "application/ace-trl+cbor", and its payload <bcp14>MUST</bcp14> be a CBOR map formatted as follows: </t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>The 'diff_set' parameter <bcp14>MUST</bcp14> be included an d specifies the empty CBOR array.</t> <t>The 'diff_set' parameter <bcp14>MUST</bcp14> be included an d specifies the empty CBOR array.</t>
</li> </li>
<li> <li>
<t>The 'cursor' parameter <bcp14>MUST</bcp14> be included and specifies the CBOR simple value <tt>null</tt> (0xf6).</t> <t>The 'cursor' parameter <bcp14>MUST</bcp14> be included and specifies the CBOR simple value <tt>null</tt> (0xf6).</t>
</li> </li>
<li> <li>
<t>The 'more' parameter <bcp14>MUST</bcp14> be included and sp ecifies the CBOR simple value <tt>true</tt> (0xf5).</t> <t>The 'more' parameter <bcp14>MUST</bcp14> be included and sp ecifies the CBOR simple value <tt>true</tt> (0xf5).</t>
</li> </li>
</ul> </ul>
<t> <t>
With the combination ('cursor', 'more') = (<tt>null</tt>, <tt>true</tt>), the AS is indicating that the update collection is in fact not empty, but that one or more series items have been lost due to their removal. These include the item wi th 'index' value (P + 1) % (MAX_INDEX + 1), that the requester wished to obtain as the first one following the specified reference point with 'index' value P. </t> With the combination ('cursor', 'more') = (<tt>null</tt>, <tt>true</tt>), the AS is indicating that the update collection is, in fact, not empty, but that one o r more series items have been lost due to their removal. These include the item with 'index' value (P + 1) % (MAX_INDEX + 1) that the requester wished to obtain as the first one following the specified reference point with 'index' value P. </t>
<t> <t>
When receiving this diff query response, the requester <bcp14>SHOULD</bcp14> sen d a new full query request to the AS. A successful response provides the request er with the full, current pertaining subset of the TRL, as well as with a valid value of the 'cursor' parameter (see <xref target="sec-using-cursor-full-query-r esponse"/>) to be possibly used as query parameter in a following diff query req uest.</t> When receiving this diff query response, the requester <bcp14>SHOULD</bcp14> sen d a new full query request to the AS. A successful response provides the request er with the full current pertaining subset of the TRL as well as a valid value o f the 'cursor' parameter (see <xref target="sec-using-cursor-full-query-response "/>) to be, possibly, used as query parameter in a following diff query request. </t>
</li> </li>
<li> <li>
<t>Case B - The series item X with 'index' having value P is found in the update collection associated with the requester; or the series item X is not found and the series item Y with 'index' having value (P + 1) % (MAX_INDEX + 1) is found in the update collection associated with the requester. </t> <t>The series item X with 'index' having value P is found in the u pdate collection associated with the requester or the series item X is not found and the series item Y with 'index' having value (P + 1) % (MAX_INDEX + 1) is fo und in the update collection associated with the requester. </t>
<t> <t>
In this case, the AS performs the actions defined in <xref target="ssec-trl-diff -query"/>, with the following differences. </t> In this case, the AS performs the actions defined in <xref target="ssec-trl-diff -query"/> with the following differences:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>At step 3, the AS considers the value MAX_DIFF_BATCH (see < xref target="sec-trl-endpoint-supporting-cursor"/>), and prepares L = min(SUB_U, MAX_DIFF_BATCH) diff entries, where SUB_U = min(NUM, SUB_SIZE), and SUB_SIZE is the number of series items in the update collection starting from and including the series item added immediately after X. If L is equal to 0 (e.g., because SU B_U is equal to 0), then no diff entries are prepared. </t> <t>At step 3, the AS considers the value MAX_DIFF_BATCH (see < xref target="sec-trl-endpoint-supporting-cursor"/>) and prepares L = min(SUB_U, MAX_DIFF_BATCH) diff entries, where SUB_U = min(NUM, SUB_SIZE) and SUB_SIZE is t he number of series items in the update collection starting from and including t he series item added immediately after X. If L is equal to 0 (e.g., because SUB_ U is equal to 0), then no diff entries are prepared. </t>
<t> <t>
If SUB_U &lt;= MAX_DIFF_BATCH, the prepared diff entries are the last series ite ms in the update collection associated with the requester, corresponding to the L most recent TRL updates pertaining to the requester. </t> If SUB_U &lt;= MAX_DIFF_BATCH, the prepared diff entries are the last series ite ms in the update collection associated with the requester, corresponding to the L most recent TRL updates pertaining to the requester. </t>
<t> <t>
If SUB_U &gt; MAX_DIFF_BATCH, the prepared diff entries are the eldest of the la st SUB_U series items in the update collection associated with the requester, co rresponding to the first L of the SUB_U most recent TRL updates pertaining to th e requester.</t> If SUB_U &gt; MAX_DIFF_BATCH, the prepared diff entries are the eldest of the la st SUB_U series items in the update collection associated with the requester, co rresponding to the first L of the SUB_U most recent TRL updates pertaining to th e requester.</t>
</li> </li>
<li> <li>
<t>At step 4, the CBOR map to carry in the payload of the 2.05 (Content) response <bcp14>MUST</bcp14> be formatted as follows. </t> <t>At step 4, the CBOR map to carry in the payload of the 2.05 (Content) response <bcp14>MUST</bcp14> be formatted as follows: </t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>The 'diff_set' parameter <bcp14>MUST</bcp14> be present and specifies a CBOR array 'diff_set_value' of L elements. Each element of 'dif f_set_value' specifies one of the CBOR arrays 'diff_entry' prepared as a diff en try. Note that L might have value 0, in which case 'diff_set_value' is the empty CBOR array.</t> <t>The 'diff_set' parameter <bcp14>MUST</bcp14> be present and specifies a CBOR array 'diff_set_value' of L elements. Each element of 'dif f_set_value' specifies one of the CBOR arrays 'diff_entry' prepared as a diff en try. Note that L might have value 0, in which case 'diff_set_value' is the empty CBOR array.</t>
</li> </li>
<li> <li>
<t>The 'cursor' parameter <bcp14>MUST</bcp14> be present a nd <bcp14>MUST</bcp14> specify a CBOR unsigned integer. In particular: </t> <t>The 'cursor' parameter <bcp14>MUST</bcp14> be present a nd <bcp14>MUST</bcp14> specify a CBOR unsigned integer. In particular: </t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>If L is equal to 0, i.e., the series item X is the last one in the update collection, then the 'cursor' parameter <bcp14>MUST</bcp1 4> take the same 'index' value of the last series item in the update collection. Such a value is in fact the current value of 'last_index' for the update collec tion.</t> <t>If L is equal to 0, i.e., the series item X is the last one in the update collection, then the 'cursor' parameter <bcp14>MUST</bcp1 4> take the same 'index' value of the last series item in the update collection. In fact, such a value is the current value of 'last_index' for the update colle ction.</t>
</li> </li>
<li> <li>
<t>If L is different than 0, then the 'cursor' paramet er <bcp14>MUST</bcp14> take the 'index' value of the series element of the updat e collection included as first diff entry in the 'diff_set' CBOR array. That is, the 'cursor' parameter takes the 'index' value of the series item in the update collection corresponding to the most recent TRL update pertaining to the reques ter and returned in this diff query response.</t> <t>If L is different than 0, then the 'cursor' paramet er <bcp14>MUST</bcp14> take the 'index' value of the series element of the updat e collection included as first diff entry in the 'diff_set' CBOR array. That is, the 'cursor' parameter takes the 'index' value of the series item in the update collection corresponding to the most recent TRL update pertaining to the reques ter and returned in this diff query response.</t>
</li> </li>
</ul> </ul>
<t> <t>
Note that the 'cursor' parameter takes the same 'index' value of the last series item in the update collection when SUB_U &lt;= MAX_DIFF_BATCH.</t> Note that the 'cursor' parameter takes the same 'index' value of the last series item in the update collection when SUB_U &lt;= MAX_DIFF_BATCH.</t>
</li> </li>
<li> <li>
<t>The 'more' parameter <bcp14>MUST</bcp14> be present and <bcp14>MUST</bcp14> specify the CBOR simple value <tt>false</tt> (0xf4) if SUB_ U &lt;= MAX_DIFF_BATCH, or the CBOR simple value <tt>true</tt> (0xf5) otherwise. </t> <t>The 'more' parameter <bcp14>MUST</bcp14> be present and <bcp14>MUST</bcp14> specify the CBOR simple value <tt>false</tt> (0xf4) if SUB_ U &lt;= MAX_DIFF_BATCH, or the CBOR simple value <tt>true</tt> (0xf5) otherwise. </t>
</li> </li>
</ul> </ul>
</li> </li>
</ul> </ul>
<t> <t>
If the 'more' parameter in the payload of the received 2.05 (Content) response h as value <tt>true</tt>, the requester can send a follow-up diff query request in cluding the 'cursor' query parameter, with the same value of the 'cursor' parame ter specified in this diff query response. This would result in the AS transferr ing the following subset of series items as diff entries, thus resuming from whe re interrupted in the previous transfer.</t> If the 'more' parameter in the payload of the received 2.05 (Content) response h as value <tt>true</tt>, the requester can send a follow-up diff query request in cluding the 'cursor' query parameter with the same value of the 'cursor' paramet er specified in this diff query response. This would result in the AS transferri ng the following subset of series items as diff entries, thus, resuming from whe re interrupted in the previous transfer.</t>
</li> </li>
</ul> </ol>
</section> </section>
</section> </section>
</section> </section>
<section anchor="sec-registration"> <section anchor="sec-registration">
<name>Registration at the Authorization Server</name> <name>Registration at the Authorization Server</name>
<t>During the registration process at the AS, an administrator or a regist ered device receives the following information as part of the registration respo nse.</t> <t>During the registration process at the AS, an administrator or a regist ered device receives the following information as part of the registration respo nse:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>The url-path to the TRL endpoint at the AS.</t> <t>The url-path to the TRL endpoint at the AS.</t>
</li> </li>
<li> <li>
<t>The hash function used to compute token hashes. This is specified b y identifying an entry in the "Named Information Hash Algorithm" Registry <xref target="Named.Information.Hash.Algorithm"/>. The specific means for this is outs ide the scope of this document.</t> <t>The hash function used to compute token hashes. This is specified b y identifying an entry in the "Named Information Hash Algorithm Registry" <xref target="IANA.Hash.Algorithms"/>. The specific means for this is outside the scop e of this document.</t>
</li> </li>
<li> <li>
<t>A positive integer MAX_N, if the AS supports diff queries of the TR L (see <xref target="sec-trl-endpoint-supporting-diff-queries"/> and <xref targe t="ssec-trl-diff-query"/>).</t> <t>A positive integer MAX_N, if the AS supports diff queries of the TR L (see Sections <xref target="sec-trl-endpoint-supporting-diff-queries" format=" counter"/> and <xref target="ssec-trl-diff-query" format="counter"/>).</t>
</li> </li>
<li> <li>
<t>A positive integer MAX_DIFF_BATCH, if the AS supports diff queries of the TRL as well as the related "Cursor" extension (see <xref target="sec-trl- endpoint-supporting-cursor"/> and <xref target="sec-using-cursor"/>).</t> <t>A positive integer MAX_DIFF_BATCH, if the AS supports diff queries of the TRL as well as the related "Cursor" extension (see Sections <xref target= "sec-trl-endpoint-supporting-cursor" format="counter"/> and <xref target="sec-us ing-cursor" format="counter"/>).</t>
</li> </li>
</ul> </ul>
<t>Once completed the registration process, the AS maintains the registrat <t>Once the registration process is completed, the AS maintains the regist
ion and related information until a possible deregistration occurs, hence keepin ration and related information until a possible deregistration occurs, hence, ke
g track of active administrators and registered devices. The particular way to a eping track of active administrators and registered devices. The particular way
chieve this is implementation-specific. Such a mechanism to maintain registratio to achieve this is implementation specific. In any case, such a mechanism to mai
ns is enforced in any case at the AS, in order to ensure that requests sent by c ntain registrations is enforced at the AS in order to ensure that requests sent
lients to the /token endpoint (see <xref section="5.8" sectionFormat="of" target by clients to the /token endpoint (see <xref section="5.8" sectionFormat="of" ta
="RFC9200"/>) and by RSs to the /introspect endpoint (see <xref section="5.9" se rget="RFC9200"/>) and by RSs to the /introspect endpoint (see <xref section="5.9
ctionFormat="of" target="RFC9200"/>) are processed as intended.</t> " sectionFormat="of" target="RFC9200"/>) are processed as intended.</t>
<t>When communicating with one another, the registered devices and the AS <t>When communicating with one another, the registered devices and the AS
have to use a secure communication association and be mutually authenticated (se have to use a secure communication association and be mutually authenticated (se
e <xref section="5" sectionFormat="of" target="RFC9200"/>).</t> e <xref section="5" sectionFormat="of" target="RFC9200"/>). </t>
<t>In the same spirit, it <bcp14>MUST</bcp14> be ensured that communicatio
ns between the AS and an administrator are mutually authenticated, encrypted and <t>In the same spirit, communications between the AS and an administrator
integrity protected, as well as protected against message replay.</t> <bcp14>MUST</bcp14> be ensured to be mutually authenticated, encrypted, and inte
<t>Before starting its registration process at the AS, an administrator ha grity protected as well as protected against message replay.</t>
s to establish such a secure communication association with the AS, if they do n <t>Before starting its registration process at the AS, an administrator ha
ot share one already. In particular, mutual authentication is <bcp14>REQUIRED</b s to establish such a secure communication association with the AS, if they do n
cp14> during the establishment of the secure association. To this end, the admin ot share one already. In particular, mutual authentication is <bcp14>REQUIRED</b
istrator and the AS can rely, e.g., on establishing a TLS or DTLS secure session cp14> during the establishment of the secure association. To this end, the admin
with mutual authentication <xref target="RFC8446"/><xref target="RFC9147"/>, or istrator and the AS can rely, e.g., on establishing a TLS or DTLS secure session
an OSCORE Security Context <xref target="RFC8613"/> by running the authenticate with mutual authentication (see <xref target="RFC8446"/> and <xref target="RFC9
d key exchange protocol EDHOC <xref target="RFC9528"/>.</t> 147"/>) or an Object Security for Constrained RESTful Environments (OSCORE) Secu
rity Context <xref target="RFC8613"/> by running the authenticated key exchange
protocol EDHOC <xref target="RFC9528"/>.</t>
<t>When receiving authenticated requests from the administrator for access ing the TRL endpoint, the AS can always check whether the requester is authorize d to take such a role, i.e., to access the content of the whole TRL.</t> <t>When receiving authenticated requests from the administrator for access ing the TRL endpoint, the AS can always check whether the requester is authorize d to take such a role, i.e., to access the content of the whole TRL.</t>
<t>To this end, the AS may rely on a local access control list or similar, which specifies the authentication credentials of trusted, authorized administr ators. In particular, the AS verifies the requester to the TRL endpoint as an au thorized administrator, only if the access control list includes the same authen tication credential used by the requester when establishing the mutually-authent icated secure communication association with the AS.</t> <t>To this end, the AS may rely on a local access control list or similar, which specifies the authentication credentials of trusted, authorized administr ators. In particular, the AS verifies the requester to the TRL endpoint as an au thorized administrator only if the access control list includes the same authent ication credential used by the requester when establishing the mutually authenti cated secure communication association with the AS.</t>
<t>Further details about the registration process at the AS are out of sco pe for this specification. Note that the registration process is also out of the scope of the ACE framework for Authentication and Authorization (see <xref sect ion="5.5" sectionFormat="of" target="RFC9200"/>).</t> <t>Further details about the registration process at the AS are out of sco pe for this specification. Note that the registration process is also out of the scope of the ACE framework for Authentication and Authorization (see <xref sect ion="5.5" sectionFormat="of" target="RFC9200"/>).</t>
</section> </section>
<section anchor="sec-notification"> <section anchor="sec-notification">
<name>Notification of Revoked Access Tokens</name> <name>Notification of Revoked Access Tokens</name>
<t>Once registered at the AS, the administrator or registered device can s <t>Once registered at the AS, the administrator or registered device can s
end a GET request to the TRL endpoint at the AS. The request can express the wis end a GET request to the TRL endpoint at the AS. The request can express the wis
h for a full query (see <xref target="ssec-trl-full-query"/>) or a diff query (s h for a full query (see <xref target="ssec-trl-full-query"/>) or a diff query (s
ee <xref target="ssec-trl-diff-query"/>) of the TRL. Also, the request can inclu ee <xref target="ssec-trl-diff-query"/>) of the TRL. Also, the request can inclu
de the CoAP Observe Option set to 0 (register), in order to start an observation de the CoAP Observe Option set to 0 (register) in order to start an observation
of the TRL endpoint as per <xref section="3.1" sectionFormat="of" target="RFC76 of the TRL endpoint as per <xref section="3.1" sectionFormat="of" target="RFC764
41"/>.</t> 1"/>.</t>
<t>In case the request is successfully processed, the AS replies with a re
sponse specifying the CoAP response code 2.05 (Content). In particular, if the A <t>In case the request is successfully processed, the AS replies with a re
S supports diff queries but not the "Cursor" extension (see <xref target="sec-tr sponse specifying the CoAP response code 2.05 (Content). In particular, if the A
l-endpoint-supporting-diff-queries"/> and <xref target="sec-trl-endpoint-support S supports diff queries but not the "Cursor" extension (see Sections <xref targe
ing-cursor"/>), then the payload of the response is formatted as defined in <xre t="sec-trl-endpoint-supporting-diff-queries" format="counter"/> and <xref targe
f target="ssec-trl-full-query"/> or in <xref target="ssec-trl-diff-query"/>, in t="sec-trl-endpoint-supporting-cursor" format="counter"/>), then the payload of
case the GET request has yielded the execution of a full query or of a diff quer the response is formatted as defined in Sections <xref target="ssec-trl-full-qu
y of the TRL, respectively. Instead, if the AS supports both diff queries and th ery" format="counter"/> or <xref target="ssec-trl-diff-query" format="counter"/>
e related "Cursor" extension, then the payload of the response is formatted as d , in case the GET request has yielded the execution of a full query or of a diff
efined in <xref target="sec-using-cursor"/>.</t> query of the TRL, respectively. Instead, if the AS supports both diff queries a
<t>In case a requester does not receive a response from the TRL endpoint o nd the related "Cursor" extension, then the payload of the response is formatted
r it receives an error response from the TRL endpoint, the requester does not ma as defined in <xref target="sec-using-cursor"/>.</t>
ke any assumption or draw any conclusion regarding the revocation or expiration <t>In case a requester does not receive a response from the TRL endpoint o
of its pertaining access tokens. The requester <bcp14>MAY</bcp14> try again by s r it receives an error response from the TRL endpoint, the requester does not ma
ending a new request to the TRL endpoint.</t> ke any assumptions or draw any conclusions regarding the revocation or expiratio
<t>When the TRL is updated (see <xref target="ssec-trl-update"/>), the AS n of its pertaining access tokens. The requester <bcp14>MAY</bcp14> try again by
sends Observe notifications to the observers whose pertaining subset of the TRL sending a new request to the TRL endpoint.</t>
has changed. Observe notifications are sent as per <xref section="4.2" sectionFo <t>When the TRL is updated (see <xref target="ssec-trl-update"/>), the AS
rmat="of" target="RFC7641"/>. If supported by the AS, an observer may configure sends Observe notifications to the observers whose pertaining subset of the TRL
the behavior according to which the AS sends those Observe notifications. To thi has changed. Observe notifications are sent as per <xref section="4.2" sectionFo
s end, a possible way relies on the conditional control attribute "c.pmax" defin rmat="of" target="RFC7641"/>. If supported by the AS, an observer may configure
ed in <xref target="I-D.ietf-core-conditional-attributes"/>, which can be includ the behavior according to which the AS sends those Observe notifications. To thi
ed as a "name=value" query parameter in an Observation Request. This ensures tha s end, a possible way relies on the conditional control attribute "c.pmax" defin
t no more than c.pmax seconds elapse between two consecutive notifications sent ed in <xref target="I-D.ietf-core-conditional-attributes"/>, which can be includ
to that observer, regardless of whether the TRL has changed or not.</t> ed as a "name=value" query parameter in an Observation Request. This ensures tha
<t>Following a first exchange with the AS, an administrator or a registere t no more than c.pmax seconds elapse between two consecutive notifications sent
d device can send additional GET (Observation) requests to the TRL endpoint at a to that observer, regardless of whether or not the TRL has changed.</t>
ny time, analogously to what is defined above. When doing so, the requester towa <t>Following a first exchange with the AS, an administrator or a registere
rds the TRL endpoint can perform a full query (see <xref target="ssec-trl-full-q d device can send additional GET (Observation) requests to the TRL endpoint at a
uery"/>) or a diff query (see <xref target="ssec-trl-diff-query"/>) of the TRL. ny time, analogously to what is defined above. When doing so, the requester towa
In the latter case, the requester can additionally rely on the "Cursor" extensio rds the TRL endpoint can perform a full query (see <xref target="ssec-trl-full-q
n (see <xref target="sec-trl-endpoint-query-parameters"/> and <xref target="sec- uery"/>) or a diff query (see <xref target="ssec-trl-diff-query"/>) of the TRL.
using-cursor-diff-query-response"/>).</t> In the latter case, the requester can additionally rely on the "Cursor" extensio
<t>As specified in <xref target="sec-trl-endpoint-supporting-diff-queries" n (see Sections <xref target="sec-trl-endpoint-query-parameters" format="counter
/>, an AS supporting diff queries maintains an update collection of maximum MAX_ "/> and <xref target="sec-using-cursor-diff-query-response" format="counter"/>).
N series items for each administrator or registered device, hereafter referred t </t>
o as requester. In particular, if an update collection includes MAX_N series ite <t>As specified in <xref target="sec-trl-endpoint-supporting-diff-queries"
ms, adding a further series item to that update collection results in deleting t />, an AS supporting diff queries maintains an update collection of maximum MAX_
he oldest series item from that update collection.</t> N series items for each administrator or registered device, hereafter referred t
<t>From then on, the requester associated with the update collection will o as a "requester". In particular, if an update collection includes MAX_N series
not be able to retrieve the deleted series item, when sending a new diff query r items, adding a further series item to that update collection results in deleti
equest to the TRL endpoint. If that series item reflected the revocation of an a ng the oldest series item from that update collection.</t>
ccess token pertaining to the requester, then the requester will not learn about <t>From then on, the requester associated with the update collection will
that when receiving the corresponding diff query response from the AS.</t> not be able to retrieve the deleted series item when sending a new diff query re
<t>Sending a diff query request specifically as an Observation request, an quest to the TRL endpoint. If that series item reflected the revocation of an ac
d thus relying on Observe notifications, largely reduces the chances for a reque cess token pertaining to the requester, then the requester will not learn about
ster to miss updates occurred to its associated update collection altogether. In that when receiving the corresponding diff query response from the AS.</t>
turn, this relies on the requester successfully receiving the Observe notificat <t>Sending a diff query request specifically as an Observation Request, an
ion responses from the TRL (see also <xref target="sec-security-considerations-c d, thus, relying on Observe notifications, largely reduces the chances for a req
omm-patterns"/>).</t> uester to miss updates to its associated update collection. In turn, this relies
on the requester successfully receiving the Observe notification responses from
the TRL (see also <xref target="sec-security-considerations-comm-patterns"/>).<
/t>
<t>In order to limit the amount of time during which the requester is unaw are of pertaining access tokens that have been revoked but are not expired yet, a requester <bcp14>SHOULD NOT</bcp14> rely solely on diff query requests. In par ticular, a requester <bcp14>SHOULD</bcp14> also regularly send a full query requ est to the TRL endpoint according to a related application policy.</t> <t>In order to limit the amount of time during which the requester is unaw are of pertaining access tokens that have been revoked but are not expired yet, a requester <bcp14>SHOULD NOT</bcp14> rely solely on diff query requests. In par ticular, a requester <bcp14>SHOULD</bcp14> also regularly send a full query requ est to the TRL endpoint according to a related application policy.</t>
<section anchor="sec-handling-token-hashes"> <section anchor="sec-handling-token-hashes">
<name>Handling of Revoked Access Tokens and Token Hashes</name> <name>Handling of Revoked Access Tokens and Token Hashes</name>
<t>When receiving a response from the TRL endpoint, a registered device <bcp14>MUST</bcp14> expunge every stored access token associated with a token ha sh specified in the response. In case the registered device is an RS, it <bcp14> MUST NOT</bcp14> delete the stored token hash after having expunged the associat ed access token.</t> <t>When receiving a response from the TRL endpoint, a registered device <bcp14>MUST</bcp14> expunge every stored access token associated with a token ha sh specified in the response. In case the registered device is an RS, it <bcp14> MUST NOT</bcp14> delete the stored token hash after having expunged the associat ed access token.</t>
<t>If an RS uses the method defined in this document with the AS that ha s issued an access token, then the RS <bcp14>MUST NOT</bcp14> accept and store t hat access token if any of the following holds.</t> <t>If an RS uses the method defined in this document with the AS that ha s issued an access token, then the RS <bcp14>MUST NOT</bcp14> accept and store t hat access token if any of the following holds.</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>The token hash corresponding to the access token is among the cur rently stored ones.</t> <t>The token hash corresponding to the access token is among the cur rently stored ones.</t>
</li> </li>
<li> <li>
<t>The access token is a CWT and any of the following holds. </t> <t>The access token is a CWT and any of the following holds: </t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>The access token includes a non-empty "unprotected" field, i. e., the value of the field is not encoded as the empty CBOR map (0xa0). This app lies to: the top-level "unprotected" field of the COSE object used for the CWT; the "unprotected" field of each element of the "signatures" array; and the "unpr otected" field of each element of any "recipients" array.</t> <t>The access token includes a non-empty "unprotected" field, i. e., the value of the field is not encoded as the empty CBOR map (0xa0). This app lies to the top-level "unprotected" field of the COSE object used for the CWT, t he "unprotected" field of each element of the "signatures" array, and the "unpro tected" field of each element of any "recipients" array.</t>
</li> </li>
<li> <li>
<t>The received CBOR data item that embodies the access token do <t>The received CBOR data item that embodies the access token do
es not comply with what is defined in <xref target="sec-issuing-access-tokens-as es not comply with what is defined in <xref target="sec-issuing-access-tokens-as
"/>. This concerns: the use of exactly two nested CBOR tags, where the outer tag "/>. This concerns:</t><ul>
is the CWT CBOR tag and the inner tag is one of the COSE CBOR tags; the tag num <li>the use of exactly two nested CBOR tags, where the outer tag
bers encoded with the minimum possible length; and the access token being the in is the CWT CBOR tag and the inner tag is one of the COSE CBOR tags;</li>
nermost tag content of the received CBOR data item.</t> <li>the tag numbers encoded with the minimum possible length; and
</li>
<li>the access token being the innermost tag content of the recei
ved CBOR data item.</li></ul>
</li> </li>
<li> <li>
<t>In the received CBOR data item that embodies the access token , the inner tag has a tag number that is not consistent with the actual COSE dat a item to process. For instance, the inner tag number is 16 (COSE_Encrypt0), but the CWT is actually a COSE_Sign data item.</t> <t>In the received CBOR data item that embodies the access token , the inner tag has a tag number that is not consistent with the actual COSE dat a item to process. For instance, the inner tag number is 16 (COSE_Encrypt0) but the CWT is actually a COSE_Sign data item.</t>
</li> </li>
</ul> </ul>
</li> </li>
<li> <li>
<t>The access token relies on a JSON object for encoding its claims, but it is not a JWT <xref target="RFC7519"/> and any of the following holds. < /t> <t>The access token relies on a JSON object for encoding its claims, but it is not a JWT <xref target="RFC7519"/> and any of the following holds:</t >
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>The access token uses the JWS JSON Serialization from <xref t arget="RFC7515"/>, and it includes the JWS Unprotected Header.</t> <t>The access token uses the JWS JSON Serialization from <xref t arget="RFC7515"/> and includes the JWS Unprotected Header.</t>
</li> </li>
<li> <li>
<t>The access token uses the JWE JSON Serialization from <xref t arget="RFC7516"/>, and it includes the JWE Shared Unprotected Header and/or incl udes the "header" member in any of the elements of the "recipients" array.</t> <t>The access token uses the JWE JSON Serialization from <xref t arget="RFC7516"/> and includes the JWE Shared Unprotected Header and/or includes the "header" member in any of the elements of the "recipients" array.</t>
</li> </li>
</ul> </ul>
</li> </li>
</ul> </ul>
<t>An RS <bcp14>MUST</bcp14> store the token hash th1 corresponding to a n access token t1 until both the following conditions hold.</t> <t>An RS <bcp14>MUST</bcp14> store the token hash th1 corresponding to a n access token t1 until both the following conditions hold:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>The RS has received and seen t1, irrespective of having accepted and stored it.</t> <t>The RS has received and seen t1, irrespective of having accepted and stored it.</t>
</li> </li>
<li> <li>
<t>The RS has gained knowledge that t1 has expired. This can be achi eved, e.g., through the following means. </t> <t>The RS has gained knowledge that t1 has expired. This can be achi eved, e.g., through the following means:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>A response from the TRL endpoint indicating that t1 has expir ed after its earlier revocation, i.e., the token hash th1 has been removed from the TRL. This can be indicated, for instance, in a response from the TRL endpoin t following a diff query of the TRL (see <xref target="ssec-trl-diff-query"/>).< /t> <t>A response from the TRL endpoint indicating that t1 has expir ed after its earlier revocation, i.e., the token hash th1 has been removed from the TRL. This can be indicated, for instance, in a response from the TRL endpoin t following a diff query of the TRL (see <xref target="ssec-trl-diff-query"/>).< /t>
</li> </li>
<li> <li>
<t>The value of the 'exp' claim specified in t1 indicates that t 1 has expired.</t> <t>The value of the 'exp' claim specified in t1 indicates that t 1 has expired.</t>
</li> </li>
<li> <li>
<t>The locally determined expiration time for t1 has passed, bas ed on the time at the RS when t1 was first accepted and on the value of its 'exi ' claim.</t> <t>The locally determined expiration time for t1 has passed, bas ed on the time at the RS when t1 was first accepted and on the value of its 'exi ' claim.</t>
</li> </li>
<li> <li>
<t>The result of token introspection performed on t1 (see <xref section="5.9" sectionFormat="of" target="RFC9200"/>), if supported by both the R S and the AS.</t> <t>The result of token introspection performed on t1 (see <xref section="5.9" sectionFormat="of" target="RFC9200"/>), if supported by both the R S and the AS.</t>
</li> </li>
</ul> </ul>
</li> </li>
</ul> </ul>
<t>The RS <bcp14>MUST NOT</bcp14> delete the stored token hashes whose c orresponding access tokens do not fulfill both the two conditions above, unless it becomes necessary due to memory limitations. In such a case, the RS <bcp14>MU ST</bcp14> delete the earliest stored token hashes first.</t> <t>The RS <bcp14>MUST NOT</bcp14> delete the stored token hashes whose c orresponding access tokens do not fulfill both the two conditions above, unless it becomes necessary due to memory limitations. In such a case, the RS <bcp14>MU ST</bcp14> delete the earliest stored token hashes first.</t>
<t>Retaining the stored token hashes as specified above limits the impac <t>Retaining the stored token hashes as specified above limits the impac
t from a (dishonest) client whose pertaining access token: i) specifies the 'exi t from a (dishonest) client whose pertaining access token:</t>
' claim; ii) is uploaded at the RS for the first time after it has been revoked <ol>
and later expired; and iii) has the sequence number encoded in the 'cti' claim ( <li>specifies the 'exi' claim,</li>
for CWTs) or in the 'jti' claim (for JWTs) greater than the highest sequence num <li>is uploaded at the RS for the first time after it has been revoked
ber among the expired access tokens specifying the 'exi' claim for the RS (see < and later expired, and</li>
xref section="5.10.3" sectionFormat="of" target="RFC9200"/>). That is, the RS wo <li>has the sequence number encoded in the 'cti' claim (for CWTs) or in t
uld not accept such a revoked and expired access token as long as it stores the he 'jti' claim (for JWTs) greater than the highest sequence number among the exp
corresponding token hash.</t> ired access tokens specifying the 'exi' claim for the RS (see <xref section="5.1
0.3" sectionFormat="of" target="RFC9200"/>). That is, the RS would not accept su
ch a revoked and expired access token as long as it stores the corresponding tok
en hash.</li></ol>
<!--[rfced] We have attempted to break up and reorder this long
sentence. Please review if the following suggested edit
correctly captures your intent.
Original:
In order to further limit such a risk, when receiving an access token
that specifies the 'exi' claim and for which a corresponding token
hash is not stored, the RS can introspect the access token (see
Section 5.9 of [RFC9200]), if token introspection is implemented by
both the RS and the AS.
Perhaps:
This risk can be further limited. Specifically, if token
introspection is implemented by both the RS and the AS, the RS can
introspect the access token (see Section 5.9 of [RFC9200]) when
receiving an access token that specifies the 'exi' claim and for which
a corresponding token hash is not stored.
-->
<t>In order to further limit such a risk, when receiving an access token that specifies the 'exi' claim and for which a corresponding token hash is not stored, the RS can introspect the access token (see <xref section="5.9" sectionF ormat="of" target="RFC9200"/>), if token introspection is implemented by both th e RS and the AS.</t> <t>In order to further limit such a risk, when receiving an access token that specifies the 'exi' claim and for which a corresponding token hash is not stored, the RS can introspect the access token (see <xref section="5.9" sectionF ormat="of" target="RFC9200"/>), if token introspection is implemented by both th e RS and the AS.</t>
<t>When, due to the stored and corresponding token hash th2, an access t oken t2 that includes the 'exi' claim is expunged or is not accepted upon its up load, the RS retrieves the sequence number sn2 encoded in the 'cti' claim (for C WTs) or in the 'jti' claim (for JWTs) (see <xref section="5.10.3" sectionFormat= "of" target="RFC9200"/>). Then, the RS stores sn2 as associated with th2. If exp unging or not accepting t2 yields the deletion of th2, then the RS <bcp14>MUST</ bcp14> associate sn2 with th2 before continuing with the deletion of th2.</t> <t>When, due to the stored and corresponding token hash th2, an access t oken t2 that includes the 'exi' claim is expunged or is not accepted upon its up load, the RS retrieves the sequence number sn2 encoded in the 'cti' claim (for C WTs) or in the 'jti' claim (for JWTs) (see <xref section="5.10.3" sectionFormat= "of" target="RFC9200"/>). Then, the RS stores sn2 as associated with th2. If exp unging or not accepting t2 yields the deletion of th2, then the RS <bcp14>MUST</ bcp14> associate sn2 with th2 before continuing with the deletion of th2.</t>
<t>When deleting any token hash, the RS checks whether the token hash is associated with a sequence number sn_th. In such a case, the RS checks whether sn_th is greater than the highest sequence number sn* among the expired access t okens specifying the 'exi' claim for the RS. If that is the case, sn* <bcp14>MUS T</bcp14> take the value of sn_th.</t> <t>When deleting any token hash, the RS checks whether the token hash is associated with a sequence number sn_th. In such a case, the RS checks whether sn_th is greater than the highest sequence number sn* among the expired access t okens specifying the 'exi' claim for the RS. If that is the case, sn* <bcp14>MUS T</bcp14> take the value of sn_th.</t>
<t>By virtue of what is defined in <xref section="5.10.3" sectionFormat= "of" target="RFC9200"/>, this ensures that, following the deletion of the token hash associated with an access token specifying the 'exi' claim and uploaded for the first time after it has been revoked and later expired, the RS will not acc ept the access token at that point in time or in the future.</t> <t>By virtue of what is defined in <xref section="5.10.3" sectionFormat= "of" target="RFC9200"/>, this ensures that, following the deletion of the token hash associated with an access token specifying the 'exi' claim and uploaded for the first time after it has been revoked and later expired, the RS will not acc ept the access token at that point in time or in the future.</t>
</section> </section>
</section> </section>
<section anchor="trl-registry-parameters"> <section anchor="trl-registry-parameters">
<name>ACE Token Revocation List Parameters</name> <name>ACE Token Revocation List Parameters</name>
<t>This specification defines a number of parameters that can be transport ed in the response from the TRL endpoint, when the response payload is a CBOR ma p. Note that such a response <bcp14>MUST</bcp14> use the Content-Format "applica tion/ace-trl+cbor" defined in <xref target="iana-content-type"/> of this specifi cation.</t> <t>This specification defines a number of parameters that can be transport ed in the response from the TRL endpoint, when the response payload is a CBOR ma p. Note that such a response <bcp14>MUST</bcp14> use the Content-Format "applica tion/ace-trl+cbor" defined in <xref target="iana-content-type"/> of this specifi cation.</t>
<t>The table below summarizes the parameters. For each of them, it specifi es the value to use as CBOR key, i.e., as abbreviation in the key of the map pai r for the parameter, instead of the parameter's name as a text string.</t> <t>The table below summarizes the parameters. For each of them, it specifi es the value to use as CBOR key, i.e., as abbreviation in the key of the map pai r for the parameter, instead of the parameter's name as a text string.</t>
<table align="center" anchor="_table-cbor-trl-params"> <table align="center" anchor="_table-cbor-trl-params">
<name>CBOR abbreviations for the ACE Token Revocation List parameters</n ame> <name>CBOR Abbreviations for the ACE Token Revocation List Parameters</n ame>
<thead> <thead>
<tr> <tr>
<th align="left">Name</th> <th align="left">Name</th>
<th align="left">CBOR Key</th> <th align="left">CBOR Key</th>
<th align="left">CBOR Type</th> <th align="left">CBOR Type</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">full_set</td> <td align="left">full_set</td>
skipping to change at line 1250 skipping to change at line 1673
</tr> </tr>
<tr> <tr>
<td align="left">2</td> <td align="left">2</td>
<td align="left">Out of bound cursor value</td> <td align="left">Out of bound cursor value</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section anchor="sec-security-considerations"> <section anchor="sec-security-considerations">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>The protocol defined in this document inherits the security considerati ons from the ACE framework for Authentication and Authorization <xref target="RF C9200"/>, from <xref target="RFC8392"/> as to the usage of CWTs, from <xref targ et="RFC7519"/> and <xref target="RFC8725"/> as to the usage of JWTs, from <xref target="RFC7641"/> as to the usage of CoAP Observe, and from <xref target="RFC69 20"/> with regard to computing the token hashes. The following considerations al so apply.</t> <t>The protocol defined in this document inherits the security considerati ons from the ACE framework for Authentication and Authorization <xref target="RF C9200"/>, the usage of CWTs from <xref target="RFC8392"/>, the usage of JWTs fro m <xref target="RFC7519"/> and <xref target="RFC8725"/>, the usage of CoAP Obser ve from <xref target="RFC7641"/>, and computation of the token hashes from <xref target="RFC6920"/>. The following considerations also apply.</t>
<section anchor="content-retrieval-from-the-trl"> <section anchor="content-retrieval-from-the-trl">
<name>Content Retrieval from the TRL</name> <name>Content Retrieval from the TRL</name>
<t>The AS <bcp14>MUST</bcp14> ensure that each registered device can acc ess and retrieve only its pertaining subset of the TRL. To this end, the AS can always perform the required filtering based on the authenticated identity of the registered device, i.e., a (non-public) identifier that the AS can securely rel ate to the registered device and the secure association that they use to communi cate.</t> <t>The AS <bcp14>MUST</bcp14> ensure that each registered device can acc ess and retrieve only its pertaining subset of the TRL. To this end, the AS can always perform the required filtering based on the authenticated identity of the registered device, i.e., a (non-public) identifier that the AS can securely rel ate to the registered device and the secure association that they use to communi cate.</t>
<t>The AS <bcp14>MUST</bcp14> ensure that, other than registered devices accessing their own pertaining subset of the TRL, only authorized and authentic ated administrators can access the content of the whole TRL (see <xref target="s ec-registration"/>).</t> <t>The AS <bcp14>MUST</bcp14> ensure that, other than registered devices accessing their own pertaining subset of the TRL, only authorized and authentic ated administrators can access the content of the whole TRL (see <xref target="s ec-registration"/>).</t>
<t>Note that the TRL endpoint supports only the GET method (see <xref ta <t>Note that the TRL endpoint supports only the GET method (see <xref ta
rget="sec-trl-endpoint"/>). Therefore, as detailed in <xref target="ssec-trl-ful rget="sec-trl-endpoint"/>). Therefore, as detailed in Sections <xref target="sse
l-query"/> and <xref target="ssec-trl-diff-query"/>, accesses to the TRL endpoin c-trl-full-query" format="counter"/> and <xref target="ssec-trl-diff-query" form
t are performed only by means of protected and authenticated GET requests, which at="counter"/>, access to the TRL endpoint is performed only by means of protect
by definition are safe in the REST sense and do not alter the content of the TR ed and authenticated GET requests, which, by definition, are safe in the REST se
L. That is, registered devices and administrators can perform exclusively read-o nse and do not alter the content of the TRL. That is, registered devices and adm
nly operations when accessing the TRL endpoint.</t> inistrators can perform exclusively read-only operations when accessing the TRL
<t>In fact, the content of the TRL can be updated only internally by the endpoint.</t>
AS, in the two circumstances described in <xref target="ssec-trl-update"/>. The <t>In the two circumstances described in <xref target="ssec-trl-update"/
refore, an adversary that is not in control of the AS cannot manipulate the cont >, the content of the TRL can be updated only internally by the AS. Therefore,
ent of the TRL, e.g., by removing a token hash and thereby fraudulently allowing an adversary that is not in control of the AS cannot manipulate the content of t
a client to access protected resources in spite of a revoked access token, or b he TRL, e.g., by removing a token hash and thereby fraudulently allowing a clien
y adding a token hash and thereby fraudulently stopping a client from accessing t to access protected resources in spite of a revoked access token or by adding
protected resources in spite of an access token being still valid.</t> a token hash and thereby fraudulently stopping a client from accessing protected
resources in spite of an access token being still valid.</t>
</section> </section>
<section anchor="size-of-the-trl"> <section anchor="size-of-the-trl">
<name>Size of the TRL</name> <name>Size of the TRL</name>
<t>If many non-expired access tokens associated with a registered device are revoked, the pertaining subset of the TRL could grow to a size bigger than what the registered device is prepared to handle upon reception of a response fr om the TRL endpoint, especially if relying on a full query of the TRL (see <xref target="ssec-trl-full-query"/>).</t> <t>If many non-expired access tokens associated with a registered device are revoked, the pertaining subset of the TRL could grow to a size bigger than what the registered device is prepared to handle upon reception of a response fr om the TRL endpoint, especially if relying on a full query of the TRL (see <xref target="ssec-trl-full-query"/>).</t>
<t>This could be exploited by attackers to negatively affect the behavio r of a registered device. Therefore, in order to help reduce the size of the TRL , the AS <bcp14>SHOULD</bcp14> refrain from issuing access tokens with an excess ively long expiration time.</t> <t>This could be exploited by attackers to negatively affect the behavio r of a registered device. Therefore, in order to help reduce the size of the TRL , the AS <bcp14>SHOULD</bcp14> refrain from issuing access tokens with an excess ively long expiration time.</t>
</section> </section>
<section anchor="sec-security-considerations-comm-patterns"> <section anchor="sec-security-considerations-comm-patterns">
<name>Communication Patterns</name> <name>Communication Patterns</name>
<t>The communication about revoked access tokens presented in this speci fication is expected to especially rely on CoAP Observe notifications sent from the AS to a requester (i.e., an administrator or a registered device). The suppr ession of those notifications by an external attacker that has access to the net work would prevent requesters from ever knowing that their pertaining access tok ens have been revoked.</t> <t>The communication about revoked access tokens presented in this speci fication is expected to especially rely on CoAP Observe notifications sent from the AS to a requester (i.e., an administrator or a registered device). The suppr ession of those notifications by an external attacker that has access to the net work would prevent requesters from ever knowing that their pertaining access tok ens have been revoked.</t>
<t>In order to avoid this, a requester <bcp14>SHOULD NOT</bcp14> rely so lely on the CoAP Observe notifications. In particular, a requester <bcp14>SHOULD </bcp14> also regularly poll the AS for the most current information about revok ed access tokens, by sending GET requests to the TRL endpoint. Specific strategi es and schedules for polling the AS are to be defined by a related application p olicy, by also taking into account the expected operational and availability pat terns adopted by the requester (e.g., in the interest of energy saving and other optimizations).</t> <t>In order to avoid this, a requester <bcp14>SHOULD NOT</bcp14> rely so lely on the CoAP Observe notifications. In particular, a requester <bcp14>SHOULD </bcp14> also regularly poll the AS for the most current information about revok ed access tokens by sending GET requests to the TRL endpoint. Specific strategie s and schedules for polling the AS are to be defined by a related application po licy and by taking into account the expected operational and availability patter ns adopted by the requester (e.g., in the interest of energy saving and other op timizations).</t>
</section> </section>
<section anchor="request-of-new-access-tokens"> <section anchor="request-of-new-access-tokens">
<name>Request of New Access Tokens</name> <name>Request of New Access Tokens</name>
<t>If a client stores an access token that it still believes to be valid , and it accordingly attempts to access a protected resource at the RS, the clie nt may receive an unprotected 4.01 (Unauthorized) response from the RS.</t> <t>If a client stores an access token that it still believes to be valid , and it accordingly attempts to access a protected resource at the RS, the clie nt may receive an unprotected 4.01 (Unauthorized) response from the RS.</t>
<t>This can be due to a number of causes. For example, the access token <t>This can be due to a number of causes, for example:</t>
has been revoked, and the RS has become aware of it and has expunged the access <ul>
token, but the client is not aware of it (yet). As another example, the access t <li>the access token has been revoked, the RS has become aware of it, a
oken is still valid, but an on-path active adversary might have injected a forge nd the RS has expunged the access token, but the client is not aware of this (ye
d 4.01 (Unauthorized) response, or the RS might have deleted the access token fr t).</li>
om its local storage due to its dedicated storage space being all consumed.</t> <li>the access token is still valid, but an on-path active adversary mi
<t>In either case, if the client believes that the access token is still ght have injected a forged 4.01 (Unauthorized) response or the RS might have del
valid, it <bcp14>SHOULD NOT</bcp14> immediately ask for a new access token to t eted the access token from its local storage due to its dedicated storage space
he authorization server upon receiving a 4.01 (Unauthorized) response from the R being all consumed.</li></ul>
S. Instead, the client <bcp14>SHOULD</bcp14> send a request to the TRL endpoint <t>In either case, if the client believes that the access token is still
at the AS. If the client gains knowledge that the access token is not valid anym valid, it <bcp14>SHOULD NOT</bcp14> immediately ask for a new access token to t
ore, the client expunges the access token and can ask for a new one. Otherwise, he authorization server upon receiving a 4.01 (Unauthorized) response from the R
the client can try again to upload the same access token to the RS, or instead t S. Instead, the client <bcp14>SHOULD</bcp14> send a request to the TRL endpoint
o request a new one.</t> at the AS. If the client gains knowledge that the access token is not valid anym
ore, the client expunges the access token and can ask for a new one. Otherwise,
the client can try again to upload the same access token to the RS or request a
new one.</t>
</section> </section>
<section anchor="vulnerable-time-window-at-the-rs"> <section anchor="vulnerable-time-window-at-the-rs">
<name>Vulnerable Time Window at the RS</name> <name>Vulnerable Time Window at the RS</name>
<t>A client may attempt to access a protected resource at an RS after th <t>A client may attempt to access a protected resource at an RS after th
e access token allowing such an access has been revoked, but before the RS is aw e access token allowing such an access has been revoked but before the RS is awa
are of the revocation.</t> re of the revocation.</t>
<t>In such a case, if the RS is still storing the access token, the clie <t>In such a case, if the RS is still storing the access token, the clie
nt will be able to access the protected resource, even though it should not. Suc nt will be able to access the protected resource even though it should not. Such
h an access is a security violation, even if the client is not attempting to be access is a security violation, even if the client is not attempting to be mali
malicious.</t> cious.</t>
<t>In order to minimize such a risk, if an RS relies solely on polling t hrough individual requests to the TRL endpoint to learn of revoked access tokens , the RS <bcp14>SHOULD</bcp14> implement an adequate trade-off between the polli ng frequency and the maximum length of the vulnerable time window.</t> <t>In order to minimize such a risk, if an RS relies solely on polling t hrough individual requests to the TRL endpoint to learn of revoked access tokens , the RS <bcp14>SHOULD</bcp14> implement an adequate trade-off between the polli ng frequency and the maximum length of the vulnerable time window.</t>
</section> </section>
<section anchor="sec-seccons-token-manipulation"> <section anchor="sec-seccons-token-manipulation">
<name>Preventing Unnoticed Manipulation of Access Tokens</name> <name>Preventing Unnoticed Manipulation of Access Tokens</name>
<t>As defined in <xref target="sec-issuing-access-tokens-as"/>, issued a ccess tokens <bcp14>MUST NOT</bcp14> rely on unprotected headers to specify info rmation as header parameters. Also, when issued access tokens are CWTs, they <bc p14>MUST</bcp14> be tagged by using the COSE CBOR tag corresponding to the used COSE object, the result <bcp14>MUST</bcp14> be in turn tagged by using the CWT C BOR tag, and no further tagging is performed.</t> <t>As defined in <xref target="sec-issuing-access-tokens-as"/>, issued a ccess tokens <bcp14>MUST NOT</bcp14> rely on unprotected headers to specify info rmation as header parameters. Also, when issued access tokens are CWTs, they <bc p14>MUST</bcp14> be tagged by using the COSE CBOR tag corresponding to the used COSE object. Further, the result <bcp14>MUST</bcp14> be tagged using the CWT CB OR tag; no further tagging is performed.</t>
<t>This ensures that the RS always computes the correct token hash corre sponding to an access token, i.e., the same token hash computed by the AS and C for that access token.</t> <t>This ensures that the RS always computes the correct token hash corre sponding to an access token, i.e., the same token hash computed by the AS and C for that access token.</t>
<t>By construction, the rules defined in <xref target="sec-issuing-acces s-tokens-as"/> prevent an active adversary from successfully performing an attac k against the RS, which would otherwise be possible in case the access token is uploaded to the RS over an unprotected communication channel.</t> <t>By construction, the rules defined in <xref target="sec-issuing-acces s-tokens-as"/> prevent an active adversary from successfully performing an attac k against the RS, which would otherwise be possible in case the access token is uploaded to the RS over an unprotected communication channel.</t>
<t>In such an attack, the adversary intercepts the access token when thi s is sent to the RS. Then, the adversary manipulates the access token in a way w hich is going to be unnoticed by the RS, but without preventing the successful, cryptographic validation of the access token at the RS. To this end, the adversa ry has two possible options:</t> <t>In such an attack, the adversary intercepts the access token en route to the RS. Then, the adversary manipulates the access token in a way that is go ing to be unnoticed by the RS but without preventing the successful cryptographi c validation of the access token at the RS. To this end, the adversary has two p ossible options:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Adding and/or removing fields within the unprotected header(s) of the access token, as long as those fields do not play a role in the cryptograph ic validation of the access token.</t> <t>Adding and/or removing fields within the unprotected header(s) of the access token, as long as those fields do not play a role in the cryptograph ic validation of the access token.</t>
</li> </li>
<li> <li>
<t>Specifically when the access token is a CWT, adding/removing or m anipulating possible CBOR tag(s) enclosing the access token.</t> <t>Specifically when the access token is a CWT, adding, removing, or manipulating possible CBOR tags enclosing the access token.</t>
</li> </li>
</ul> </ul>
<t>After that, the adversary sends the manipulated access token to the R S.</t> <t>After that, the adversary sends the manipulated access token to the R S.</t>
<t>After having successfully validated the manipulated access token, the RS computes a corresponding token hash different from the one computed and stor ed by C and the AS. Finally, the RS stores the manipulated access token and the corresponding wrong token hash.</t> <t>After having successfully validated the manipulated access token, the RS computes a corresponding token hash different from the one computed and stor ed by C and the AS. Finally, the RS stores the manipulated access token and the corresponding wrong token hash.</t>
<t>Later on, if the access token is revoked and the AS provides the RS w ith the corresponding correct token hash, the RS does not recognize the received token hash among the stored ones, and therefore does not delete the revoked acc ess token.</t> <t>Later on, if the access token is revoked and the AS provides the RS w ith the corresponding correct token hash, the RS does not recognize the received token hash among the stored ones; therefore, it does not delete the revoked acc ess token.</t>
</section> </section>
<section anchor="sec-seccons-two-hashes-jwt"> <section anchor="sec-seccons-two-hashes-jwt">
<name>Two Token Hashes at the RS using JWTs</name> <name>Two Token Hashes at the RS Using JWTs</name>
<t><xref target="sec-token-hash-input-rs-jwt"/> defines that an RS using <t><xref target="sec-token-hash-input-rs-jwt"/> states that an RS using
JWTs as access tokens has to compute and store two token hashes associated with JWTs as access tokens has to compute and store two token hashes associated with
the same access token. This is because, when using JWTs, the RS does not know f the same access token. This is because, when using JWTs, the RS does not know fo
or sure if the AS provided the access token to the client by means of an AS-to-C r sure if the AS provided the access token to the client by means of an AS-to-Cl
lient response encoded in CBOR or in JSON.</t> ient response encoded in CBOR or in JSON.</t>
<t>Taking advantage of that, a dishonest client can attempt to perform a n attack against the RS. That is, the client can first receive the JWT in an AS- to-Client response encoded in CBOR (JSON). Then, the client can upload the JWT t o the RS in a way that makes the RS believe that the client instead received the JWT in an AS-to-Client response encoded in JSON (CBOR).</t> <t>Taking advantage of that, a dishonest client can attempt to perform a n attack against the RS. That is, the client can first receive the JWT in an AS- to-Client response encoded in CBOR (JSON). Then, the client can upload the JWT t o the RS in a way that makes the RS believe that the client instead received the JWT in an AS-to-Client response encoded in JSON (CBOR).</t>
<t>Consequently, the RS considers a HASH_INPUT different from the one co <t>Consequently, the RS considers a HASH_INPUT different from the one co
nsidered by the AS and the client (see <xref target="sec-token-hash-input-c-as"/ nsidered by the AS and the client (see <xref target="sec-token-hash-input-c-as"/
>). Hence, the RS computes a token hash h' different from the token hash h compu >). Hence, the RS computes a token hash h' different from the token hash h compu
ted by the AS and the client. It follows that, if the AS revokes the access toke ted by the AS and the client. It follows that, if the AS revokes the access toke
n and advertises the right token hash h, then the RS will not learn about the ac n and advertises the right token hash h, then the RS will not learn about the ac
cess token revocation and thus will not delete the access token.</t> cess token revocation; thus, it will not delete the access token.</t>
<t>Fundamentally, this would happen because the HASH_INPUT used to compu <t>Fundamentally, this would happen because the HASH_INPUT used to compu
te the token hash of a JWT depends on whether the AS-to-Client response is encod te the token hash of a JWT depends on whether the AS-to-Client response is encod
ed in CBOR or in JSON. This makes the RS vulnerable to the attack described abov ed in CBOR or in JSON. This makes the RS vulnerable to the attack described abov
e, when JWTs are used as access tokens. Instead, this is not a problem if the ac e when JWTs are used as access tokens. However, this is not a problem if the acc
cess token is a CWT, since the HASH_INPUT used to compute the token hash of a CW ess token is a CWT since the HASH_INPUT used to compute the token hash of a CWT
T does not depend on whether the AS-to-Client response is encoded in CBOR or in does not depend on whether the AS-to-Client response is encoded in CBOR or in JS
JSON.</t> ON.</t>
<t>While this asymmetry cannot be avoided altogether, the method defined <t>While this asymmetry cannot be avoided altogether, the method defined
for the AS and the client in <xref target="sec-token-hash-input-c-as"/> deliber for the AS and the client in <xref target="sec-token-hash-input-c-as"/> deliber
ately penalizes the case where the RS uses JWTs as access tokens. In such a case ately penalizes the case where the RS uses JWTs as access tokens. In such a case
, the RS effectively neutralizes the attack described above, by computing and st , the RS effectively neutralizes the attack described above by computing and sto
oring two token hashes associated with the same access token (see <xref target=" ring two token hashes associated with the same access token (see <xref target="s
sec-token-hash-input-rs-jwt"/>).</t> ec-token-hash-input-rs-jwt"/>).</t>
<t>Conversely, this design deliberately favors the case where the RS use <t>Conversely, this design deliberately favors the case where the RS use
s CWTs as access tokens, which is a preferable option for resource-constrained R s CWTs as access tokens, which is a preferable option for resource-constrained R
Ss as well as the default case in the ACE framework (see <xref section="3" secti Ss as well as the default case in the ACE framework for Authentication and Autho
onFormat="of" target="RFC9200"/>). That is, if an RS uses CWTs as access tokens, rization (see <xref section="3" sectionFormat="of" target="RFC9200"/>). That is,
then the RS is not exposed to the attack described above, and thus it safely co if an RS uses CWTs as access tokens, then the RS is not exposed to the attack d
mputes and stores only one token hash per access token (see <xref target="sec-to escribed above; thus, it safely computes and stores only one token hash per acce
ken-hash-input-rs-cwt"/>).</t> ss token (see <xref target="sec-token-hash-input-rs-cwt"/>).</t>
</section> </section>
<section anchor="additional-security-measures"> <section anchor="additional-security-measures">
<name>Additional Security Measures</name> <name>Additional Security Measures</name>
<t>By accessing the TRL at the AS, registered devices and administrators are able to learn that their pertaining access tokens have been revoked. Howeve r, they cannot learn the reason why that happened, including when that reason is the compromise, misbehavior, or decommissioning of a registered device.</t> <t>By accessing the TRL at the AS, registered devices and administrators are able to learn that their pertaining access tokens have been revoked. Howeve r, they cannot learn the reason why, including when that reason is the compromis e, misbehavior, or decommissioning of a registered device.</t>
<t>In fact, even the AS might not know that a registered device to which a revoked access token pertains has been specifically compromised, misbehaving, or decommissioned. At the same time, it might not be acceptable to only revoke the access tokens pertaining to such a registered device.</t> <t>In fact, even the AS might not know that a registered device to which a revoked access token pertains has been specifically compromised, misbehaving, or decommissioned. At the same time, it might not be acceptable to only revoke the access tokens pertaining to such a registered device.</t>
<t>Therefore, in order to preserve the security of the system and applic ation, the entity that authoritatively declares a registered device to be compro mised, misbehaving, or decommissioned should also promptly trigger the execution of additional revocation processes as deemed appropriate. These include, for in stance:</t> <t>Therefore, in order to preserve the security of the system and applic ation, the entity that authoritatively declares a registered device to be compro mised, misbehaving, or decommissioned should also promptly trigger the execution of additional revocation processes as deemed appropriate. These include, for in stance:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>The de-registration of the registered device from the AS, so that the AS does not issue further access tokens pertaining to that device.</t> <t>The de-registration of the registered device from the AS so that the AS does not issue further access tokens pertaining to that device.</t>
</li> </li>
<li> <li>
<t>If applicable, the revocation of the public authentication creden tial associated with the registered device (e.g., its public key certificate).</ t> <t>If applicable, the revocation of the public authentication creden tial associated with the registered device (e.g., its public key certificate).</ t>
</li> </li>
</ul> </ul>
<t>The methods by which these processes are triggered and carried out ar e out of the scope of this document.</t> <t>The methods by which these processes are triggered and carried out ar e out of the scope of this document.</t>
</section> </section>
</section> </section>
<section anchor="iana"> <section anchor="iana">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>This document has the following actions for IANA.</t> <t>The IANA actions for this document are described in the following subse
<t>Note to RFC Editor: Please replace all occurrences of "[RFC-XXXX]" with ctions.</t>
the RFC number of this specification and delete this paragraph.</t>
<section anchor="iana-media-type"> <section anchor="iana-media-type">
<name>Media Type Registrations</name> <name>Media Type Registrations</name>
<t>IANA is asked to register the media type "application/ace-trl+cbor" f <t>IANA has registered the media type "application/ace-trl+cbor" for mes
or messages of the protocol defined in this document encoded in CBOR. This regis sages of the protocol defined in this document encoded in CBOR. This registratio
tration follows the procedures specified in <xref target="RFC6838"/>.</t> n follows the procedures specified in <xref target="RFC6838"/>.</t>
<t>Type name: application</t> <dl newline="false">
<t>Subtype name: ace-trl+cbor</t> <dt>Type name:</dt><dd>application</dd>
<t>Required parameters: N/A</t> <dt>Subtype name:</dt><dd>ace-trl+cbor</dd>
<t>Optional parameters: N/A</t> <dt>Required parameters:</dt><dd>N/A</dd>
<t>Encoding considerations: Must be encoded as a CBOR map containing the <dt>Optional parameters:</dt><dd>N/A</dd>
protocol parameters defined in [RFC-XXXX].</t> <dt>Encoding considerations:</dt><dd>Must be encoded as a CBOR map
<t>Security considerations: See <xref target="sec-security-consideration containing the protocol parameters defined in RFC 9770.</dd>
s"/> of this document.</t> <dt>Security considerations:</dt><dd>See <xref target="sec-security-co
<t>Interoperability considerations: N/A</t> nsiderations"/> of this document.</dd>
<t>Published specification: [RFC-XXXX]</t> <dt>Interoperability considerations:</dt><dd>N/A</dd>
<t>Applications that use this media type: The type is used by authorizat <dt>Published specification:</dt><dd>RFC 9770</dd>
ion servers, clients, and resource servers that support the notification of revo <dt>Applications that use this media type:</dt><dd>The type is used
ked access tokens, according to a Token Revocation List maintained by the author by authorization servers, clients, and resource servers that support
ization server as specified in [RFC-XXXX].</t> the notification of revoked access tokens according to a Token
<t>Fragment identifier considerations: N/A</t> Revocation List maintained by the authorization server as specified
<t>Additional information: N/A</t> in RFC 9770.</dd>
<t>Person &amp; email address to contact for further information: ACE WG <dt>Fragment identifier considerations:</dt><dd>N/A</dd>
mailing list (ace@ietf.org) or IETF Applications and Real-Time Area (art@ietf.o <dt>Additional information:</dt><dd>N/A</dd>
rg)</t> <dt>Person &amp; email address to contact for further
<t>Intended usage: COMMON</t> information:</dt><dd>ACE WG mailing list (ace@ietf.org) or IETF
<t>Restrictions on usage: None</t> Applications and Real-Time Area (art@ietf.org)</dd>
<t>Author/Change controller: IETF</t> <dt>Intended usage:</dt><dd>COMMON</dd>
<t>Provisional registration: No</t> <dt>Restrictions on usage:</dt><dd>None</dd>
<dt>Author/Change controller:</dt><dd>IETF</dd>
</dl>
</section> </section>
<section anchor="iana-content-type"> <section anchor="iana-content-type">
<name>CoAP Content-Formats Registry</name> <name>CoAP Content-Formats Registry</name>
<t>IANA is asked to add the following entry to the "CoAP Content-Formats <t>IANA has added the following entry to the "CoAP Content-Formats" regi
" registry within the "Constrained RESTful Environments (CoRE) Parameters" regis stry within the "Constrained RESTful Environments (CoRE) Parameters" registry gr
try group.</t> oup.</t>
<t>Content Type: application/ace-trl+cbor</t> <dl newline="false" spacing="compact">
<t>Content Coding: -</t> <dt>Content Type:</dt><dd>application/ace-trl+cbor</dd>
<t>ID: TBD</t> <dt>Content Coding:</dt><dd>-</dd>
<t>Reference: [RFC-XXXX]</t> <dt>ID:</dt><dd>262</dd>
<dt>Reference:</dt><dd>RFC 9770</dd>
</dl>
</section> </section>
<section anchor="iana-custom-problem-details"> <section anchor="iana-custom-problem-details">
<name>Custom Problem Detail Keys Registry</name> <name>Custom Problem Detail Keys Registry</name>
<t>IANA is asked to register the following entry in the "Custom Problem <t>IANA has registered the following entry in the "Custom Problem Detail
Detail Keys" registry within the "Constrained RESTful Environments (CoRE) Parame Keys" registry within the "Constrained RESTful Environments (CoRE) Parameters"
ters" registry group.</t> registry group.</t>
<ul spacing="normal"> <dl newline="false" spacing="compact">
<li> <dt>Key Value:</dt><dd>1</dd>
<t>Key Value: TBD</t> <dt>Name:</dt><dd>ace-trl-error</dd>
</li> <dt>Brief Description:</dt><dd>Carry RFC 9770 problem details in a Con
<li> cise Problem Details data item.</dd>
<t>Name: ace-trl-error</t> <dt>Change Controller:</dt><dd>IETF</dd>
</li> <dt>Reference:</dt><dd><xref target="sec-error-responses"/> of RFC 977
<li> 0</dd>
<t>Brief Description: Carry [RFC-XXXX] problem details in a Concise </dl>
Problem Details data item.</t>
</li>
<li>
<t>Change Controller: IETF</t>
</li>
<li>
<t>Reference: <xref target="sec-error-responses"/> of [RFC-XXXX]</t>
</li>
</ul>
</section> </section>
<section anchor="iana-token-revocation-list"> <section anchor="iana-token-revocation-list">
<name>ACE Token Revocation List Parameters Registry</name> <name>ACE Token Revocation List Parameters Registry</name>
<t>IANA is asked to establish the "ACE Token Revocation List Parameters" <t>IANA has established the "ACE Token Revocation List Parameters" regi
IANA registry within the "Authentication and Authorization for Constrained Envi stry within the "Authentication and Authorization for Constrained Environments (
ronments (ACE)" registry group.</t> ACE)" registry group.</t>
<t>As registration policy, the registry uses either "Standards Action wi <t>One of the following registration policies is used: "Standards Action
th Expert Review", or "Specification Required" per <xref section="4.6" sectionFo with Expert Review", "Specification Required" per <xref section="4.6" sectionFo
rmat="of" target="RFC8126"/>, or "Expert Review" per <xref section="4.5" section rmat="of" target="RFC8126"/>, or "Expert Review" per <xref section="4.5" section
Format="of" target="RFC8126"/>. Expert Review guidelines are provided in <xref t Format="of" target="RFC8126"/>. Expert Review guidelines are provided in <xref t
arget="review"/>.</t> arget="review"/>.</t>
<t>All assignments according to "Standards Action with Expert Review" ar <t>All assignments according to "Standards Action with Expert Review" ar
e made on a "Standards Action" basis per <xref section="4.9" sectionFormat="of" e made on a "Standards Action" basis per <xref section="4.9" sectionFormat="of"
target="RFC8126"/>, with Expert Review additionally required per <xref section=" target="RFC8126"/> with Expert Review additionally required per <xref section="4
4.5" sectionFormat="of" target="RFC8126"/>. The procedure for early IANA allocat .5" sectionFormat="of" target="RFC8126"/>. The procedure for early IANA allocati
ion of Standards Track code points defined in <xref target="RFC7120"/> also appl on of Standards Track code points defined in <xref target="RFC7120"/> also appli
ies. When such a procedure is used, IANA will ask the designated expert(s) to ap es. When such a procedure is used, IANA will ask the designated expert(s) to app
prove the early allocation before registration. In addition, WG chairs are encou rove the early allocation before registration. In addition, WG chairs are encour
raged to consult the expert(s) early during the process outlined in <xref sectio aged to consult the expert(s) early during the process outlined in <xref section
n="3.1" sectionFormat="of" target="RFC7120"/>.</t> ="3.1" sectionFormat="of" target="RFC7120"/>.</t>
<t>The columns of this registry are:</t> <t>The columns of this registry are as follows:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>Name: This field contains a descriptive name that
<t>Name: This field contains a descriptive name that enables easier enables easier reference to the item. The name <bcp14>MUST</bcp14>
reference to the item. The name <bcp14>MUST</bcp14> be unique and it is not used be unique, and it is not used in the encoding.</li>
in the encoding.</t>
</li> <li>CBOR Key: This field contains the value used as CBOR map
<li> key of the item. The value <bcp14>MUST</bcp14> be unique. The value
<t>CBOR Key: This field contains the value used as CBOR map key of t is an unsigned integer or a negative integer. Different ranges of
he item. The value <bcp14>MUST</bcp14> be unique. The value is an unsigned integ values use different registration policies <xref
er or a negative integer. Different ranges of values use different registration target="RFC8126"/>. Integer values from -256 to 255 are designated
policies <xref target="RFC8126"/>. Integer values from -256 to 255 are designate as "Standards Action With Expert Review". Integer values from -65536
d as "Standards Action With Expert Review". Integer values from -65536 to -257 a to -257 and from 256 to 65535 are designated as "Specification
nd from 256 to 65535 are designated as "Specification Required". Integer values Required". Integer values greater than 65535 are designated as
greater than 65535 are designated as "Expert Review". Integer values less than - "Expert Review". Integer values less than -65536 are marked as
65536 are marked as "Private Use".</t> "Private Use".</li>
</li>
<li> <li>CBOR Type: This field contains the allowable CBOR data
<t>CBOR Type: This field contains the allowable CBOR data types for types for values of this item or a pointer to the registry that
values of this item, or a pointer to the registry that defines its type, when th defines its type, when that depends on another item.</li>
at depends on another item.</t>
</li> <li>Reference: This field contains a pointer to the public
<li> specification for the item.</li>
<t>Reference: This field contains a pointer to the public specificat
ion for the item.</t>
</li>
</ul> </ul>
<t>This registry has been initially populated by the values in <xref tar get="trl-registry-parameters"/>. The "Reference" column for all of these entries refers to this document.</t> <t>This registry has been initially populated by the values in <xref tar get="trl-registry-parameters"/>. The "Reference" column for all of these entries refers to this document.</t>
</section> </section>
<section anchor="iana-token-revocation-list-errors"> <section anchor="iana-token-revocation-list-errors">
<name>ACE Token Revocation List Errors</name> <name>ACE Token Revocation List Errors</name>
<t>IANA is asked to establish the "ACE Token Revocation List Errors" IAN <t>IANA has established the "ACE Token Revocation List Errors" registry
A registry within the "Authentication and Authorization for Constrained Environm within the "Authentication and Authorization for Constrained Environments (ACE)
ents (ACE)" registry group.</t> " registry group.</t>
<t>As registration policy, the registry uses either "Standards Action wi <t>One of the following registration policies is used: "Standards Action
th Expert Review", or "Specification Required" per <xref section="4.6" sectionFo with Expert Review", "Specification Required" per <xref section="4.6" sectionFo
rmat="of" target="RFC8126"/>, or "Expert Review" per <xref section="4.5" section rmat="of" target="RFC8126"/>, or "Expert Review" per <xref section="4.5" section
Format="of" target="RFC8126"/>. Expert Review guidelines are provided in <xref t Format="of" target="RFC8126"/>. Expert Review guidelines are provided in <xref t
arget="review"/>.</t> arget="review"/>.</t>
<t>All assignments according to "Standards Action with Expert Review" ar <t>All assignments according to "Standards Action with Expert Review" ar
e made on a "Standards Action" basis per <xref section="4.9" sectionFormat="of" e made on a "Standards Action" basis per <xref section="4.9" sectionFormat="of"
target="RFC8126"/>, with Expert Review additionally required per <xref section=" target="RFC8126"/> with Expert Review additionally required per <xref section="4
4.5" sectionFormat="of" target="RFC8126"/>. The procedure for early IANA allocat .5" sectionFormat="of" target="RFC8126"/>. The procedure for early IANA allocati
ion of Standards Track code points defined in <xref target="RFC7120"/> also appl on of Standards Track code points defined in <xref target="RFC7120"/> also appli
ies. When such a procedure is used, IANA will ask the designated expert(s) to ap es. When such a procedure is used, IANA will ask the designated expert(s) to app
prove the early allocation before registration. In addition, WG chairs are encou rove the early allocation before registration. In addition, WG chairs are encour
raged to consult the expert(s) early during the process outlined in <xref sectio aged to consult the expert(s) early during the process outlined in <xref section
n="3.1" sectionFormat="of" target="RFC7120"/>.</t> ="3.1" sectionFormat="of" target="RFC7120"/>.</t>
<t>The columns of this registry are:</t> <t>The columns of this registry are as follows:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Value: The field contains the value to be used to identify the er ror. The value <bcp14>MUST</bcp14> be unique. The value is an unsigned integer o r a negative integer. Different ranges of values use different registration poli cies <xref target="RFC8126"/>. Integer values from -256 to 255 are designated as "Standards Action With Expert Review". Integer values from -65536 to -257 and f rom 256 to 65535 are designated as "Specification Required". Integer values grea ter than 65535 are designated as "Expert Review". Integer values less than -6553 6 are marked as "Private Use".</t> <t>Value: The field contains the value to be used to identify the er ror. The value <bcp14>MUST</bcp14> be unique. The value is an unsigned integer o r a negative integer. Different ranges of values use different registration poli cies <xref target="RFC8126"/>. Integer values from -256 to 255 are designated as "Standards Action With Expert Review". Integer values from -65536 to -257 and f rom 256 to 65535 are designated as "Specification Required". Integer values grea ter than 65535 are designated as "Expert Review". Integer values less than -6553 6 are marked as "Private Use".</t>
</li> </li>
<li> <li>
<t>Description: This field contains a brief description of the error .</t> <t>Description: This field contains a brief description of the error .</t>
</li> </li>
<li> <li>
<t>Reference: This field contains a pointer to the public specificat ion defining the error, if one exists.</t> <t>Reference: This field contains a pointer to the public specificat ion defining the error, if one exists.</t>
</li> </li>
</ul> </ul>
<t>This registry has been initially populated by the values in <xref tar get="error-types"/>. The "Reference" column for all of these entries refers to t his document.</t> <t>This registry has been initially populated by the values in <xref tar get="error-types"/>. The "Reference" column for all of these entries refers to t his document.</t>
</section> </section>
<section anchor="review"> <section anchor="review">
<name>Expert Review Instructions</name> <name>Expert Review Instructions</name>
<t>The IANA registries established in this document are defined as "Stan dards Action with Expert Review", "Specification Required", or "Expert Review", depending on the range of values for which an assignment is requested. This sect ion gives some general guidelines for what the experts should be looking for, bu t they are being designated as experts for a reason so they should be given subs tantial latitude.</t> <t>The IANA registries established by this document use "Standards Actio n with Expert Review", "Specification Required", or "Expert Review" registration procedures depending on the range of values for which an assignment is requeste d. This section gives some general guidelines for what the experts should be loo king for, but they are being designated as experts for a reason, so they should be given substantial latitude.</t>
<t>Expert reviewers should take into consideration the following points: </t> <t>Expert reviewers should take into consideration the following points: </t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Point squatting should be discouraged. Reviewers are encouraged t o get sufficient information for registration requests to ensure that the usage is not going to duplicate one that is already registered and that the point is l ikely to be used in deployments. The zones tagged as private use are intended fo r testing purposes and closed environments. Code points in other ranges should n ot be assigned for testing.</t> <t>Point squatting should be discouraged. Reviewers are encouraged t o get sufficient information for registration requests to ensure that the usage is not going to duplicate one that is already registered and that the point is l ikely to be used in deployments. The zones tagged as Private Use are intended fo r testing purposes and closed environments. Code points in other ranges should n ot be assigned for testing.</t>
</li> </li>
<li> <li>
<t>Specifications are required for the "Standards Action With Expert Review" range of point assignment. Specifications should exist for "Specificati on Required" ranges, but early assignment before a specification is available is considered to be permissible. For the "Expert Review" range of point assignment , specifications are recommended, and are needed if they are expected to be used outside of closed environments in an interoperable way. When specifications are not provided, the description provided needs to have sufficient information to identify what the point is being used for.</t> <t>Specifications are required for the "Standards Action With Expert Review" range of point assignment. Specifications should exist for "Specificati on Required" ranges, but early assignment before a specification is available is considered to be permissible. For the "Expert Review" range of point assignment , specifications are recommended and are needed if they are expected to be used outside of closed environments in an interoperable way. When specifications are not provided, the description provided needs to have sufficient information to i dentify what the point is being used for.</t>
</li> </li>
<li> <li>
<t>Experts should take into account the expected usage of fields whe n approving point assignment. The fact that there is a range for Standards Track documents does not mean that a Standards Track document cannot have points assi gned outside of that range. The length of the encoded value should be weighed ag ainst how many code points of that length are left, the size of device it will b e used on, and the number of code points left that encode to that size.</t> <t>Experts should take into account the expected usage of fields whe n approving point assignment. The fact that there is a range for Standards Track documents does not mean that a Standards Track document cannot have points assi gned outside of that range. The length of the encoded value should be weighed ag ainst how many code points of that length are left, the size of device it will b e used on, and the number of code points left that encode to that size.</t>
</li> </li>
</ul> </ul>
</section> </section>
</section> </section>
</middle> </middle>
<back> <back>
<displayreference target="I-D.bormann-t2trg-stp" to="STP"/>
<displayreference target="I-D.ietf-core-conditional-attributes" to="CoRE-ATT
RIBUTES"/>
<references> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<reference anchor="RFC3629"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
<front> 629.xml"/>
<title>UTF-8, a transformation format of ISO 10646</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
<author fullname="F. Yergeau" initials="F." surname="Yergeau"/> 648.xml"/>
<date month="November" year="2003"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
<abstract> 347.xml"/>
<t>ISO/IEC 10646-1 defines a large character set called the Univer <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
sal Character Set (UCS) which encompasses most of the world's writing systems. T 749.xml"/>
he originally proposed encodings of the UCS, however, were not compatible with m <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
any current applications and protocols, and this has led to the development of U 838.xml"/>
TF-8, the object of this memo. UTF-8 has the characteristic of preserving the fu <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
ll US-ASCII range, providing compatibility with file systems, parsers and other 920.xml"/>
software that rely on US-ASCII values but are transparent to other values. This <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
memo obsoletes and replaces RFC 2279.</t> 120.xml"/>
</abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
</front> 252.xml"/>
<seriesInfo name="STD" value="63"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<seriesInfo name="RFC" value="3629"/> 641.xml"/>
<seriesInfo name="DOI" value="10.17487/RFC3629"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
</reference> 259.xml"/>
<reference anchor="RFC4648"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<front> 515.xml"/>
<title>The Base16, Base32, and Base64 Data Encodings</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<author fullname="S. Josefsson" initials="S." surname="Josefsson"/> 516.xml"/>
<date month="October" year="2006"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<abstract> 519.xml"/>
<t>This document describes the commonly used base 64, base 32, and <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
base 16 encoding schemes. It also discusses the use of line-feeds in encoded da 126.xml"/>
ta, use of padding in encoded data, use of non-alphabet characters in encoded da <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
ta, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRA 392.xml"/>
CK]</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
</abstract> 446.xml"/>
</front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<seriesInfo name="RFC" value="4648"/> 610.xml"/>
<seriesInfo name="DOI" value="10.17487/RFC4648"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
</reference> 613.xml"/>
<reference anchor="RFC6347"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<front> 725.xml"/>
<title>Datagram Transport Layer Security Version 1.2</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<author fullname="E. Rescorla" initials="E." surname="Rescorla"/> 949.xml"/>
<author fullname="N. Modadugu" initials="N." surname="Modadugu"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<date month="January" year="2012"/> 052.xml"/>
<abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<t>This document specifies version 1.2 of the Datagram Transport L 147.xml"/>
ayer Security (DTLS) protocol. The DTLS protocol provides communications privacy <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
for datagram protocols. The protocol allows client/server applications to commu 200.xml"/>
nicate in a way that is designed to prevent eavesdropping, tampering, or message <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
forgery. The DTLS protocol is based on the Transport Layer Security (TLS) proto 528.xml"/>
col and provides equivalent security guarantees. Datagram semantics of the under <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
lying transport are preserved by the DTLS protocol. This document updates DTLS 1 202.xml"/>
.0 to work with TLS version 1.2. [STANDARDS-TRACK]</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
</abstract> 203.xml"/>
</front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<seriesInfo name="RFC" value="6347"/> 290.xml"/>
<seriesInfo name="DOI" value="10.17487/RFC6347"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
</reference> 431.xml"/>
<reference anchor="RFC6749">
<front> <reference anchor="IANA.Hash.Algorithms" target="https://www.iana.org/as
<title>The OAuth 2.0 Authorization Framework</title> signments/named-information">
<author fullname="D. Hardt" initials="D." role="editor" surname="Har
dt"/>
<date month="October" year="2012"/>
<abstract>
<t>The OAuth 2.0 authorization framework enables a third-party app
lication to obtain limited access to an HTTP service, either on behalf of a reso
urce owner by orchestrating an approval interaction between the resource owner a
nd the HTTP service, or by allowing the third-party application to obtain access
on its own behalf. This specification replaces and obsoletes the OAuth 1.0 prot
ocol described in RFC 5849. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6749"/>
<seriesInfo name="DOI" value="10.17487/RFC6749"/>
</reference>
<reference anchor="RFC6838">
<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 regi
stration of media types for use in HTTP, MIME, and other Internet protocols. Thi
s 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="RFC6920">
<front>
<title>Naming Things with Hashes</title>
<author fullname="S. Farrell" initials="S." surname="Farrell"/>
<author fullname="D. Kutscher" initials="D." surname="Kutscher"/>
<author fullname="C. Dannewitz" initials="C." surname="Dannewitz"/>
<author fullname="B. Ohlman" initials="B." surname="Ohlman"/>
<author fullname="A. Keranen" initials="A." surname="Keranen"/>
<author fullname="P. Hallam-Baker" initials="P." surname="Hallam-Bak
er"/>
<date month="April" year="2013"/>
<abstract>
<t>This document defines a set of ways to identify a thing (a digi
tal object in this case) using the output from a hash function. It specifies a n
ew URI scheme for this purpose, a way to map these to HTTP URLs, and binary and
human-speakable formats for these names. The various formats are designed to sup
port, but not require, a strong link to the referenced object, such that the ref
erenced object may be authenticated to the same degree as the reference to it. T
he reason for this work is to standardise current uses of hash outputs in URLs a
nd to support new information-centric applications and other uses of hash output
s in protocols.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6920"/>
<seriesInfo name="DOI" value="10.17487/RFC6920"/>
</reference>
<reference anchor="RFC7120">
<front>
<title>Early IANA Allocation of Standards Track Code Points</title>
<author fullname="M. Cotton" initials="M." surname="Cotton"/>
<date month="January" year="2014"/>
<abstract>
<t>This memo describes the process for early allocation of code po
ints by IANA from registries for which "Specification Required", "RFC Required",
"IETF Review", or "Standards Action" policies apply. This process can be used t
o alleviate the problem where code point allocation is needed to facilitate desi
red or required implementation and deployment experience prior to publication of
an RFC, which would normally trigger code point allocation. The procedures in t
his document are intended to apply only to IETF Stream documents.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="100"/>
<seriesInfo name="RFC" value="7120"/>
<seriesInfo name="DOI" value="10.17487/RFC7120"/>
</reference>
<reference anchor="RFC7252">
<front>
<title>The Constrained Application Protocol (CoAP)</title>
<author fullname="Z. Shelby" initials="Z." surname="Shelby"/>
<author fullname="K. Hartke" initials="K." surname="Hartke"/>
<author fullname="C. Bormann" initials="C." surname="Bormann"/>
<date month="June" year="2014"/>
<abstract>
<t>The Constrained Application Protocol (CoAP) is a specialized we
b transfer protocol for use with constrained nodes and constrained (e.g., low-po
wer, lossy) networks. The nodes often have 8-bit microcontrollers with small amo
unts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wire
less Personal Area Networks (6LoWPANs) often have high packet error rates and a
typical throughput of 10s of kbit/s. The protocol is designed for machine- to-ma
chine (M2M) applications such as smart energy and building automation.</t>
<t>CoAP provides a request/response interaction model between appl
ication endpoints, supports built-in discovery of services and resources, and in
cludes key concepts of the Web such as URIs and Internet media types. CoAP is de
signed to easily interface with HTTP for integration with the Web while meeting
specialized requirements such as multicast support, very low overhead, and simpl
icity for constrained environments.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7252"/>
<seriesInfo name="DOI" value="10.17487/RFC7252"/>
</reference>
<reference anchor="RFC7641">
<front>
<title>Observing Resources in the Constrained Application Protocol (
CoAP)</title>
<author fullname="K. Hartke" initials="K." surname="Hartke"/>
<date month="September" year="2015"/>
<abstract>
<t>The Constrained Application Protocol (CoAP) is a RESTful applic
ation protocol for constrained nodes and networks. The state of a resource on a
CoAP server can change over time. This document specifies a simple protocol exte
nsion for CoAP that enables CoAP clients to "observe" resources, i.e., to retrie
ve a representation of a resource and keep this representation updated by the se
rver over a period of time. The protocol follows a best-effort approach for send
ing new representations to clients and provides eventual consistency between the
state observed by each client and the actual resource state at the server.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7641"/>
<seriesInfo name="DOI" value="10.17487/RFC7641"/>
</reference>
<reference anchor="RFC8259">
<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="RFC7515">
<front>
<title>JSON Web Signature (JWS)</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 Signature (JWS) represents content secured with digita
l signatures or Message Authentication Codes (MACs) using JSON-based data struct
ures. Cryptographic algorithms and identifiers for use with this specification a
re described in the separate JSON Web Algorithms (JWA) specification and an IANA
registry defined by that specification. Related encryption capabilities are des
cribed in the separate JSON Web Encryption (JWE) specification.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7515"/>
<seriesInfo name="DOI" value="10.17487/RFC7515"/>
</reference>
<reference anchor="RFC7516">
<front>
<title>JSON Web Encryption (JWE)</title>
<author fullname="M. Jones" initials="M." surname="Jones"/>
<author fullname="J. Hildebrand" initials="J." surname="Hildebrand"/
>
<date month="May" year="2015"/>
<abstract>
<t>JSON Web Encryption (JWE) represents encrypted content using JS
ON-based data structures. Cryptographic algorithms and identifiers for use with
this specification are described in the separate JSON Web Algorithms (JWA) speci
fication and IANA registries defined by that specification. Related digital sign
ature and Message Authentication Code (MAC) capabilities are described in the se
parate JSON Web Signature (JWS) specification.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7516"/>
<seriesInfo name="DOI" value="10.17487/RFC7516"/>
</reference>
<reference anchor="RFC7519">
<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 representi
ng 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) stru
cture or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the
claims to be digitally signed or integrity protected with a Message Authenticat
ion Code (MAC) and/or encrypted.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7519"/>
<seriesInfo name="DOI" value="10.17487/RFC7519"/>
</reference>
<reference anchor="RFC8126">
<front>
<title>Guidelines for Writing an IANA Considerations Section in RFCs
</title>
<author fullname="M. Cotton" initials="M." surname="Cotton"/>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<author fullname="T. Narten" initials="T." surname="Narten"/>
<date month="June" year="2017"/>
<abstract>
<t>Many protocols make use of points of extensibility that use con
stants to identify various protocol parameters. To ensure that the values in the
se fields do not have conflicting uses and to promote interoperability, their al
locations are often coordinated by a central record keeper. For IETF protocols,
that role is filled by the Internet Assigned Numbers Authority (IANA).</t>
<t>To make assignments in a given registry prudently, guidance des
cribing the conditions under which new values should be assigned, as well as whe
n and how modifications to existing values can be made, is needed. This document
defines a framework for the documentation of these guidelines by specification
authors, in order to assure that the provided guidance for the IANA Consideratio
ns is clear and addresses the various issues that are likely in the operation of
a registry.</t>
<t>This is the third edition of this document; it obsoletes RFC 52
26.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="26"/>
<seriesInfo name="RFC" value="8126"/>
<seriesInfo name="DOI" value="10.17487/RFC8126"/>
</reference>
<reference anchor="RFC8392">
<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="RFC8446">
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</titl
e>
<author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
<date month="August" year="2018"/>
<abstract>
<t>This document specifies version 1.3 of the Transport Layer Secu
rity (TLS) protocol. TLS allows client/server applications to communicate over t
he Internet in a way that is designed to prevent eavesdropping, tampering, and m
essage forgery.</t>
<t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 50
77, 5246, and 6961. This document also specifies new requirements for TLS 1.2 im
plementations.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8446"/>
<seriesInfo name="DOI" value="10.17487/RFC8446"/>
</reference>
<reference anchor="RFC8610">
<front>
<title>Concise Data Definition Language (CDDL): A Notational Convent
ion to Express Concise Binary Object Representation (CBOR) and JSON Data Structu
res</title>
<author fullname="H. Birkholz" initials="H." surname="Birkholz"/>
<author fullname="C. Vigano" initials="C." surname="Vigano"/>
<author fullname="C. Bormann" initials="C." surname="Bormann"/>
<date month="June" year="2019"/>
<abstract>
<t>This document proposes a notational convention to express Conci
se Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal
is to provide an easy and unambiguous way to express structures for protocol me
ssages and data formats that use CBOR or JSON.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8610"/>
<seriesInfo name="DOI" value="10.17487/RFC8610"/>
</reference>
<reference anchor="RFC8613">
<front>
<title>Object Security for Constrained RESTful Environments (OSCORE)
</title>
<author fullname="G. Selander" initials="G." surname="Selander"/>
<author fullname="J. Mattsson" initials="J." surname="Mattsson"/>
<author fullname="F. Palombini" initials="F." surname="Palombini"/>
<author fullname="L. Seitz" initials="L." surname="Seitz"/>
<date month="July" year="2019"/>
<abstract>
<t>This document defines Object Security for Constrained RESTful E
nvironments (OSCORE), a method for application-layer protection of the Constrain
ed Application Protocol (CoAP), using CBOR Object Signing and Encryption (COSE).
OSCORE provides end-to-end protection between endpoints communicating using CoA
P or CoAP-mappable HTTP. OSCORE is designed for constrained nodes and networks s
upporting a range of proxy operations, including translation between different t
ransport protocols.</t>
<t>Although an optional functionality of CoAP, OSCORE alters CoAP
options processing and IANA registration. Therefore, this document updates RFC 7
252.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8613"/>
<seriesInfo name="DOI" value="10.17487/RFC8613"/>
</reference>
<reference anchor="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 se
curity 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 num
erous protocols and applications, both in the area of digital identity and in ot
her application areas. This Best Current Practices document updates RFC 7519 to
provide actionable guidance leading to secure implementation and deployment of J
WTs.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="225"/>
<seriesInfo name="RFC" value="8725"/>
<seriesInfo name="DOI" value="10.17487/RFC8725"/>
</reference>
<reference anchor="RFC8949">
<front>
<title>Concise Binary Object Representation (CBOR)</title>
<author fullname="C. Bormann" initials="C." surname="Bormann"/>
<author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
<date month="December" year="2020"/>
<abstract>
<t>The Concise Binary Object Representation (CBOR) is a data forma
t whose design goals include the possibility of extremely small code size, fairl
y small message size, and extensibility without the need for version negotiation
. These design goals make it different from earlier binary serializations such a
s ASN.1 and MessagePack.</t>
<t>This document obsoletes RFC 7049, providing editorial improveme
nts, new details, and errata fixes while keeping full compatibility with the int
erchange format of RFC 7049. It does not create a new version of the format.</t>
</abstract>
</front>
<seriesInfo name="STD" value="94"/>
<seriesInfo name="RFC" value="8949"/>
<seriesInfo name="DOI" value="10.17487/RFC8949"/>
</reference>
<reference anchor="RFC9052">
<front>
<title>CBOR Object Signing and Encryption (COSE): Structures and Pro
cess</title>
<author fullname="J. Schaad" initials="J." surname="Schaad"/>
<date month="August" year="2022"/>
<abstract>
<t>Concise Binary Object Representation (CBOR) is a data format de
signed for small code size and small message size. There is a need to be able to
define basic security services for this data format. This document defines the
CBOR Object Signing and Encryption (COSE) protocol. This specification describes
how to create and process signatures, message authentication codes, and encrypt
ion using CBOR for serialization. This specification additionally describes how
to represent cryptographic keys using CBOR.</t>
<t>This document, along with RFC 9053, obsoletes RFC 8152.</t>
</abstract>
</front>
<seriesInfo name="STD" value="96"/>
<seriesInfo name="RFC" value="9052"/>
<seriesInfo name="DOI" value="10.17487/RFC9052"/>
</reference>
<reference anchor="RFC9147">
<front>
<title>The Datagram Transport Layer Security (DTLS) Protocol Version
1.3</title>
<author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
<author fullname="H. Tschofenig" initials="H." surname="Tschofenig"/
>
<author fullname="N. Modadugu" initials="N." surname="Modadugu"/>
<date month="April" year="2022"/>
<abstract>
<t>This document specifies version 1.3 of the Datagram Transport L
ayer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to com
municate over the Internet in a way that is designed to prevent eavesdropping, t
ampering, and message forgery.</t>
<t>The DTLS 1.3 protocol is based on the Transport Layer Security
(TLS) 1.3 protocol and provides equivalent security guarantees with the exceptio
n of order protection / non-replayability. Datagram semantics of the underlying
transport are preserved by the DTLS protocol.</t>
<t>This document obsoletes RFC 6347.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9147"/>
<seriesInfo name="DOI" value="10.17487/RFC9147"/>
</reference>
<reference anchor="RFC9200">
<front>
<title>Authentication and Authorization for Constrained Environments
Using the OAuth 2.0 Framework (ACE-OAuth)</title>
<author fullname="L. Seitz" initials="L." surname="Seitz"/>
<author fullname="G. Selander" initials="G." surname="Selander"/>
<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="August" year="2022"/>
<abstract>
<t>This specification defines a framework for authentication and a
uthorization in Internet of Things (IoT) environments called ACE-OAuth. The fram
ework is based on a set of building blocks including OAuth 2.0 and the Constrain
ed Application Protocol (CoAP), thus transforming a well-known and widely used a
uthorization solution into a form suitable for IoT devices. Existing specificati
ons are used where possible, but extensions are added and profiles are defined t
o better serve the IoT use cases.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9200"/>
<seriesInfo name="DOI" value="10.17487/RFC9200"/>
</reference>
<reference anchor="RFC9528">
<front>
<title>Ephemeral Diffie-Hellman Over COSE (EDHOC)</title>
<author fullname="G. Selander" initials="G." surname="Selander"/>
<author fullname="J. Preuß Mattsson" initials="J." surname="Preuß Ma
ttsson"/>
<author fullname="F. Palombini" initials="F." surname="Palombini"/>
<date month="March" year="2024"/>
<abstract>
<t>This document specifies Ephemeral Diffie-Hellman Over COSE (EDH
OC), a very compact and lightweight authenticated Diffie-Hellman key exchange wi
th ephemeral keys. EDHOC provides mutual authentication, forward secrecy, and id
entity protection. EDHOC is intended for usage in constrained scenarios, and a m
ain use case is to establish an Object Security for Constrained RESTful Environm
ents (OSCORE) security context. By reusing CBOR Object Signing and Encryption (C
OSE) for cryptography, Concise Binary Object Representation (CBOR) for encoding,
and Constrained Application Protocol (CoAP) for transport, the additional code
size can be kept very low.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9528"/>
<seriesInfo name="DOI" value="10.17487/RFC9528"/>
</reference>
<reference anchor="RFC9202">
<front>
<title>Datagram Transport Layer Security (DTLS) Profile for Authenti
cation and Authorization for Constrained Environments (ACE)</title>
<author fullname="S. Gerdes" initials="S." surname="Gerdes"/>
<author fullname="O. Bergmann" initials="O." surname="Bergmann"/>
<author fullname="C. Bormann" initials="C." surname="Bormann"/>
<author fullname="G. Selander" initials="G." surname="Selander"/>
<author fullname="L. Seitz" initials="L." surname="Seitz"/>
<date month="August" year="2022"/>
<abstract>
<t>This specification defines a profile of the Authentication and
Authorization for Constrained Environments (ACE) framework that allows constrain
ed servers to delegate client authentication and authorization. The protocol rel
ies on DTLS version 1.2 or later for communication security between entities in
a constrained network using either raw public keys or pre-shared keys. A resourc
e-constrained server can use this protocol to delegate management of authorizati
on information to a trusted host with less-severe limitations regarding processi
ng power and memory.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9202"/>
<seriesInfo name="DOI" value="10.17487/RFC9202"/>
</reference>
<reference anchor="RFC9203">
<front>
<title>The Object Security for Constrained RESTful Environments (OSC
ORE) Profile of the Authentication and Authorization for Constrained Environment
s (ACE) Framework</title>
<author fullname="F. Palombini" initials="F." surname="Palombini"/>
<author fullname="L. Seitz" initials="L." surname="Seitz"/>
<author fullname="G. Selander" initials="G." surname="Selander"/>
<author fullname="M. Gunnarsson" initials="M." surname="Gunnarsson"/
>
<date month="August" year="2022"/>
<abstract>
<t>This document specifies a profile for the Authentication and Au
thorization for Constrained Environments (ACE) framework. It utilizes Object Sec
urity for Constrained RESTful Environments (OSCORE) to provide communication sec
urity and proof-of-possession for a key owned by the client and bound to an OAut
h 2.0 access token.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9203"/>
<seriesInfo name="DOI" value="10.17487/RFC9203"/>
</reference>
<reference anchor="RFC9290">
<front>
<title>Concise Problem Details for Constrained Application Protocol
(CoAP) APIs</title>
<author fullname="T. Fossati" initials="T." surname="Fossati"/>
<author fullname="C. Bormann" initials="C." surname="Bormann"/>
<date month="October" year="2022"/>
<abstract>
<t>This document defines a concise "problem detail" as a way to ca
rry machine-readable details of errors in a Representational State Transfer (RES
T) response to avoid the need to define new error response formats for REST APIs
for constrained environments. The format is inspired by, but intended to be mor
e concise than, the problem details for HTTP APIs defined in RFC 7807.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9290"/>
<seriesInfo name="DOI" value="10.17487/RFC9290"/>
</reference>
<reference anchor="RFC9431">
<front>
<title>Message Queuing Telemetry Transport (MQTT) and Transport Laye
r Security (TLS) Profile of Authentication and Authorization for Constrained Env
ironments (ACE) Framework</title>
<author fullname="C. Sengul" initials="C." surname="Sengul"/>
<author fullname="A. Kirby" initials="A." surname="Kirby"/>
<date month="July" year="2023"/>
<abstract>
<t>This document specifies a profile for the Authentication and Au
thorization for Constrained Environments (ACE) framework to enable authorization
in a publish-subscribe messaging system based on Message Queuing Telemetry Tran
sport (MQTT). Proof-of-Possession keys, bound to OAuth 2.0 access tokens, are us
ed to authenticate and authorize MQTT Clients. The protocol relies on TLS for co
nfidentiality and MQTT server (Broker) authentication.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9431"/>
<seriesInfo name="DOI" value="10.17487/RFC9431"/>
</reference>
<reference anchor="Named.Information.Hash.Algorithm" target="https://www
.iana.org/assignments/named-information/named-information.xhtml">
<front> <front>
<title>Named Information Hash Algorithm</title> <title>Named Information Hash Algorithm Registry</title>
<author> <author>
<organization>IANA</organization> <organization>IANA</organization>
</author> </author>
<date/> <date/>
</front> </front>
</reference> </reference>
<!-- [rfced] [SHA-256] The reference to NIST FIPS 180-3 was very
outdated. FIPS 180-3 was superseded by FIPS 180-4 in 2012. The
latest version of this standard was released in August 2015. We
have updated to the most recent version. Please let us know any
objections-->
<reference anchor="SHA-256" target="https://nvlpubs.nist.gov/nistpubs/FI
PS/NIST.FIPS.180-4.pdf">
<front>
<title>Secure Hash Standard</title>
<author>
<organization>NIST</organization>
</author>
<date year="2015" month="August"/>
</front>
<seriesInfo name="NIST FIPS PUB" value="180-4"/>
<seriesInfo name="DOI" value="10.6028/NIST.FIPS.180-4"/>
</reference>
<!-- OLD XML for withdrawn version of [SHA-256]
<reference anchor="SHA-256" target="http://csrc.nist.gov/publications/fi ps/fips180-3/fips180-3_final.pdf"> <reference anchor="SHA-256" target="http://csrc.nist.gov/publications/fi ps/fips180-3/fips180-3_final.pdf">
<front> <front>
<title>Secure Hash Standard</title> <title>Secure Hash Standard</title>
<author> <author>
<organization>NIST</organization> <organization>NIST</organization>
</author> </author>
<date year="2008" month="October"/> <date year="2008" month="October"/>
</front> </front>
<seriesInfo name="FIPS 180-3" value=""/> <seriesInfo name="FIPS 180-3" value=""/>
</reference> </reference>
<reference anchor="RFC2119"> -->
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
<title>Key words for use in RFCs to Indicate Requirement Levels</tit 119.xml"/>
le> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<author fullname="S. Bradner" initials="S." surname="Bradner"/> 174.xml"/>
<date month="March" year="1997"/>
<abstract>
<t>In many standards track documents several words are used to sig
nify the requirements in the specification. These words are often capitalized. T
his document defines these words as they should be interpreted in IETF documents
. This document specifies an Internet Best Current Practices for the Internet Co
mmunity, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC8174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<date month="May" year="2017"/>
<abstract>
<t>RFC 2119 specifies common key words that may be used in protoco
l specifications. This document aims to reduce the ambiguity by clarifying that
only UPPERCASE usage of the key words have the defined special meanings.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
</references> </references>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<reference anchor="RFC7009"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<front> 009.xml"/>
<title>OAuth 2.0 Token Revocation</title> <!-- [I-D.ietf-core-conditional-attributes] IESG State: I-D Exists as of 12/12/2
<author fullname="T. Lodderstedt" initials="T." role="editor" surnam 4 -->
e="Lodderstedt"/>
<author fullname="S. Dronia" initials="S." surname="Dronia"/>
<author fullname="M. Scurtescu" initials="M." surname="Scurtescu"/>
<date month="August" year="2013"/>
<abstract>
<t>This document proposes an additional endpoint for OAuth authori
zation servers, which allows clients to notify the authorization server that a p
reviously obtained refresh or access token is no longer needed. This allows the
authorization server to clean up security credentials. A revocation request will
invalidate the actual token and, if applicable, other tokens based on the same
authorization grant.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7009"/>
<seriesInfo name="DOI" value="10.17487/RFC7009"/>
</reference>
<reference anchor="I-D.ietf-core-conditional-attributes">
<front>
<title>Conditional Attributes for Constrained RESTful Environments</
title>
<author fullname="Michael Koster" initials="M." surname="Koster">
<organization>Dogtiger Labs</organization>
</author>
<author fullname="Alan Soloway" initials="A." surname="Soloway">
<organization>Qualcomm Technologies</organization>
</author>
<author fullname="Bill Silverajan" initials="B." surname="Silverajan
">
<organization>Tampere University</organization>
</author>
<date day="8" month="July" year="2024"/>
<abstract>
<t> This specification defines Conditional Notification and Cont
rol
Attributes that work with CoAP Observe (RFC7641).
Editor note
The git repository for the draft is found at https://github.com/core-
wg/conditional-attributes/
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-core-conditional-a
ttributes-07"/>
</reference>
<reference anchor="I-D.bormann-t2trg-stp">
<front>
<title>The Series Transfer Pattern (STP)</title>
<author fullname="Carsten Bormann" initials="C." surname="Bormann">
<organization>Universität Bremen TZI</organization>
</author>
<author fullname="Klaus Hartke" initials="K." surname="Hartke">
<organization>Ericsson</organization>
</author>
<date day="7" month="April" year="2020"/>
<abstract>
<t> Many applications make use of Series of data items, i.e., an
array of
data items where new items can be added over time. Where such Series
are to be made available using REST protocols such as CoAP or HTTP,
the Series has to be mapped into a structure of one or more resources
and a protocol for a client to obtain the Series and to learn about
new items.
Various protocols have been standardized that make Series-shaped data <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
available, with rather different properties and objectives. The ietf-core-conditional-attributes.xml"/>
present document is an attempt to extract a common underlying pattern <!-- [I-D.bormann-t2trg-stp] IESG State: Expired as of 12/12/24 -->
and to define media types and an access scheme that can be used right
away for further protocols that provide Series-shaped data.
</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
</abstract> bormann-t2trg-stp.xml"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-bormann-t2trg-stp-03"/>
</reference>
</references> </references>
</references> </references>
<section anchor="sec-series-pattern"> <section anchor="sec-series-pattern">
<name>On using the Series Transfer Pattern</name> <name>On Using the Series Transfer Pattern</name>
<t>Performing a diff query of the TRL as specified in <xref target="ssec-t <t>Performing a diff query of the TRL as specified in <xref target="ssec-t
rl-diff-query"/> is in fact a usage example of the Series Transfer Pattern defin rl-diff-query"/> is, in fact, a usage example of the Series Transfer Pattern def
ed in <xref target="I-D.bormann-t2trg-stp"/>.</t> ined in <xref target="I-D.bormann-t2trg-stp"/>.</t>
<t>That is, a diff query enables the transfer of a series of diff entries, <t>That is, a diff query enables the transfer of a series of diff entries
with the AS specifying U &lt;= MAX_N diff entries as related to the U most rece with the AS specifying U &lt;= MAX_N diff entries as related to the U most recen
nt TRL updates pertaining to a requester, i.e., a registered device or an admini t TRL updates pertaining to a requester, i.e., a registered device or an adminis
strator.</t> trator.</t>
<t>When responding to a diff query request from a requester (see <xref tar <t>When responding to a diff query request from a requester (see <xref tar
get="ssec-trl-diff-query"/>), 'diff_set' is a subset of the update collection as get="ssec-trl-diff-query"/>), 'diff_set' is a subset of the update collection as
sociated with the requester, where each 'diff_entry' record is a series item fro sociated with the requester where each 'diff_entry' record is a series item from
m that update collection. Note that 'diff_set' specifies the whole current updat that update collection. Note that 'diff_set' specifies the whole current update
e collection when the value of U is equal to SIZE, i.e., the current number of s collection when the value of U is equal to SIZE, i.e., the current number of se
eries items in the update collection.</t> ries items in the update collection.</t>
<t>The value N of the 'diff' query parameter in the GET request allows the requester and the AS to trade the amount of provided information with the laten cy of the information transfer.</t> <t>The value N of the 'diff' query parameter in the GET request allows the requester and the AS to trade the amount of provided information with the laten cy of the information transfer.</t>
<t>Since the update collection associated with each requester includes up to MAX_N series items, the AS deletes the oldest series item when a new one is g enerated and added to the end of the update collection, due to a new TRL update pertaining to that requester (see <xref target="sec-trl-endpoint-supporting-diff -queries"/>). This addresses the question "When can the server decide to no long er retain older items?" raised in <xref section="3.2" sectionFormat="of" target= "I-D.bormann-t2trg-stp"/>.</t> <t>Since the update collection associated with each requester includes up to MAX_N series items, the AS deletes the oldest series item when a new one is g enerated and added to the end of the update collection, due to a new TRL update pertaining to that requester (see <xref target="sec-trl-endpoint-supporting-diff -queries"/>). This addresses the question "When can the server decide to no long er retain older items?" raised in <xref section="3.2" sectionFormat="of" target= "I-D.bormann-t2trg-stp"/>.</t>
<t>Furthermore, performing a diff query of the TRL together with the "Curs
or" extension as specified in <xref target="sec-using-cursor"/> in fact relies o <t>Furthermore, performing a diff query of the TRL together with the "Curs
n the "Cursor" pattern of the Series Transfer Pattern (see <xref section="3.3" s or" extension, as specified in <xref target="sec-using-cursor"/>, in fact, relie
ectionFormat="of" target="I-D.bormann-t2trg-stp"/>).</t> s on the "Cursor" pattern of the STP (see <xref section="3.3" sectionFormat="of"
target="I-D.bormann-t2trg-stp"/>).</t>
</section> </section>
<section anchor="sec-trl-parameteters"> <section anchor="sec-trl-parameteters">
<name>Local Supportive Parameters of the TRL Endpoint</name> <name>Local Supportive Parameters of the TRL Endpoint</name>
<t><xref target="_table-TRL-endpoint-parameters"/> provides an aggregated overview of the local supportive parameters that the AS internally uses at its T RL endpoint, when supporting diff queries (see <xref target="sec-trl-endpoint"/> ) and the "Cursor" extension (see <xref target="sec-trl-endpoint-supporting-curs or"/>).</t> <t><xref target="_table-TRL-endpoint-parameters"/> provides an aggregated overview of the local supportive parameters that the AS internally uses at its T RL endpoint when supporting diff queries (see <xref target="sec-trl-endpoint"/>) and the "Cursor" extension (see <xref target="sec-trl-endpoint-supporting-curso r"/>).</t>
<t>Except for MAX_N defined in <xref target="sec-trl-endpoint-supporting-d iff-queries"/>, all the other parameters are defined in <xref target="sec-trl-en dpoint-supporting-cursor"/> and are used only if the AS supports the "Cursor" ex tension.</t> <t>Except for MAX_N defined in <xref target="sec-trl-endpoint-supporting-d iff-queries"/>, all the other parameters are defined in <xref target="sec-trl-en dpoint-supporting-cursor"/> and are used only if the AS supports the "Cursor" ex tension.</t>
<t>For each parameter, the columns of the table specify the following info rmation. Both a registered device and an administrator are referred to as "reque ster".</t> <t>For each parameter, the columns of the table specify the following info rmation. Both a registered device and an administrator are referred to as "reque ster".</t>
<ul spacing="normal"> <dl spacing="normal">
<li> <dt>Name:</dt><dd>The parameter name. A name with letters in uppercase d
<t>Name: parameter name. A name with letters in uppercase denotes a pa enotes a parameter whose value does not change after its initialization.
rameter whose value does not change after its initialization.</t> </dd>
</li>
<li> <dt>Single instance:</dt><dd>"Y" if there is a single parameter instan
<t>Single instance: "Y", if there is a single parameter instance assoc ce associated with the TRL or "N" if there is one parameter instance per update
iated with the TRL; or "N", if there is one parameter instance per update collec collection (i.e., per requester).</dd>
tion (i.e., per requester).</t>
</li> <dt>Description:</dt><dd>A short description of the parameter.</dd>
<li>
<t>Description: short parameter description.</t> <dt>Values:</dt><dd>The unsigned integer values that the parameter can
</li> assume, where LB and UB denote the inclusive lower bound and upper bound, respe
<li> ctively, and "^" is the exponentiation operator.</dd>
<t>Values: the unsigned integer values that the parameter can assume, </dl>
where LB and UB denote the inclusive lower bound and upper bound, respectively,
and "^" is the exponentiation operator.</t> <!--[rfced] We noticed that Table 3 contains the only use of 'index' parameter.
</li> Please ensure parameter (and not value or unsigned integer) was intended.
</ul>
Original:
Max value of each instance of the 'index' parameter
-->
<table align="center" anchor="_table-TRL-endpoint-parameters"> <table align="center" anchor="_table-TRL-endpoint-parameters">
<name>Local Supportive Parameters of the TRL Endpoint</name> <name>Local Supportive Parameters of the TRL Endpoint</name>
<thead> <thead>
<tr> <tr>
<th align="left">Name</th> <th align="left">Name</th>
<th align="left">Single instance</th> <th align="left">Single instance</th>
<th align="left">Description</th> <th align="left">Description</th>
<th align="left">Values</th> <th align="left">Values</th>
</tr> </tr>
</thead> </thead>
skipping to change at line 2034 skipping to change at line 2040
<td align="left">N</td> <td align="left">N</td>
<td align="left">The 'index' value of the most recently added series item in an update collection</td> <td align="left">The 'index' value of the most recently added series item in an update collection</td>
<td align="left">LB = 0 <br/><br/> UB = MAX_INDEX</td> <td align="left">LB = 0 <br/><br/> UB = MAX_INDEX</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section anchor="sec-RS-examples"> <section anchor="sec-RS-examples">
<name>Interaction Examples</name> <name>Interaction Examples</name>
<t>This section provides examples of interactions between an RS as a regis tered device and an AS. In the examples, all the access tokens issued by the AS are intended to be consumed by the considered RS.</t> <t>This section provides examples of interactions between an RS as a regis tered device and an AS. In the examples, all the access tokens issued by the AS are intended to be consumed by the considered RS.</t>
<t>The AS supports both full queries and diff queries of the TRL, as defin <t>The AS supports both full queries and diff queries of the TRL, as defin
ed in <xref target="ssec-trl-full-query"/> and <xref target="ssec-trl-diff-query ed in Sections <xref target="ssec-trl-full-query" format="counter"/> and <xref t
"/>, respectively.</t> arget="ssec-trl-diff-query" format="counter"/>, respectively.</t>
<t>Registration is assumed to be done by the RS sending a POST request wit <t>Registration is assumed to be done by the RS sending a POST request wit
h an unspecified payload to the AS, which replies with a 2.01 (Created) response h an unspecified payload to the AS, which replies with a 2.01 (Created) response
. The payload of the registration response is assumed to be a CBOR map, which in . The payload of the registration response is assumed to be a CBOR map, which, i
turn is assumed to include the following entries:</t> n turn, is assumed to include the following entries:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>a 'trl_path' parameter, specifying the path of the TRL endpoint;</t > <t>a 'trl_path' parameter specifying the path of the TRL endpoint;</t>
</li> </li>
<li> <li>
<t>a 'trl_hash' parameter, specifying the "Hash Name String" of the ha sh function used to compute token hashes as defined in <xref target="sec-token-n ame"/>;</t> <t>a 'trl_hash' parameter specifying the "Hash Name String" of the has h function used to compute token hashes as defined in <xref target="sec-token-na me"/>;</t>
</li> </li>
<li> <li>
<t>a 'max_n' parameter, specifying the value of MAX_N, i.e., the maxim um number of series items that the AS retains in the update collection associate d with a registered device (see <xref target="ssec-trl-diff-query"/>);</t> <t>a 'max_n' parameter specifying the value of MAX_N, i.e., the maximu m number of series items that the AS retains in the update collection associated with a registered device (see <xref target="ssec-trl-diff-query"/>);</t>
</li> </li>
<li> <li>
<t>possible further parameters related to the registration process.</t > <t>possible further parameters related to the registration process.</t >
</li> </li>
</ul> </ul>
<t>Furthermore, 'h(x)' refers to the hash function used to compute the tok en hashes, as defined in <xref target="sec-token-name"/> of this specification a nd according to <xref target="RFC6920"/>. Assuming the usage of CWTs transported in AS-to-Client responses encoded in CBOR (see <xref target="sec-token-hash-inp ut-c-as-cbor"/>), 'bstr.h(t1)' and 'bstr.h(t2)' denote the CBOR byte strings wit h value the token hashes of the access tokens t1 and t2, respectively.</t> <t>Furthermore, 'h(x)' refers to the hash function used to compute the tok en hashes, as defined in <xref target="sec-token-name"/> of this specification a nd according to <xref target="RFC6920"/>. Assuming the usage of CWTs transported in AS-to-Client responses encoded in CBOR (see <xref target="sec-token-hash-inp ut-c-as-cbor"/>), 'bstr.h(t1)' and 'bstr.h(t2)' denote the CBOR byte strings wit h value the token hashes of the access tokens t1 and t2, respectively.</t>
<section anchor="sec-RS-example-1"> <section anchor="sec-RS-example-1">
<name>Full Query with Observe</name> <name>Full Query with Observe</name>
<t><xref target="fig-RS-AS"/> shows an interaction example considering a CoAP observation and a full query of the TRL.</t> <t><xref target="fig-RS-AS"/> shows an interaction example considering a CoAP observation and a full query of the TRL.</t>
<t>In this example, the AS does not support the "Cursor" extension. Henc e, the 'cursor' parameter is not included in the payload of the responses to a f ull query request.</t> <t>In this example, the AS does not support the "Cursor" extension. Henc e, the 'cursor' parameter is not included in the payload of the responses to a f ull query request.</t>
<figure anchor="fig-RS-AS"> <figure anchor="fig-RS-AS">
<name>Interaction for full query with Observe</name> <name>Interaction for Full Query with Observe</name>
<artset> <artset>
<artwork type="svg" align="center"><svg xmlns="http://www.w3.org/200 0/svg" version="1.1" height="1296" width="440" viewBox="0 0 440 1296" class="dia gram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linec ap="round"> <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/200 0/svg" version="1.1" height="1296" width="440" viewBox="0 0 440 1296" class="dia gram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linec ap="round">
<path d="M 8,48 L 8,1280" fill="none" stroke="black"/> <path d="M 8,48 L 8,1280" fill="none" stroke="black"/>
<path d="M 432,48 L 432,1280" fill="none" stroke="black"/> <path d="M 432,48 L 432,1280" fill="none" stroke="black"/>
<path d="M 8,80 L 424,80" fill="none" stroke="black"/> <path d="M 8,80 L 424,80" fill="none" stroke="black"/>
<path d="M 16,112 L 432,112" fill="none" stroke="black"/> <path d="M 16,112 L 432,112" fill="none" stroke="black"/>
<path d="M 8,288 L 424,288" fill="none" stroke="black"/> <path d="M 8,288 L 424,288" fill="none" stroke="black"/>
<path d="M 16,320 L 432,320" fill="none" stroke="black"/> <path d="M 16,320 L 432,320" fill="none" stroke="black"/>
<path d="M 16,592 L 432,592" fill="none" stroke="black"/> <path d="M 16,592 L 432,592" fill="none" stroke="black"/>
<path d="M 16,784 L 432,784" fill="none" stroke="black"/> <path d="M 16,784 L 432,784" fill="none" stroke="black"/>
skipping to change at line 2287 skipping to change at line 2293
| Payload: { | | Payload: { |
| e'full_set' : [] | | e'full_set' : [] |
| } | | } |
| | | |
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
</section> </section>
<section anchor="sec-RS-example-2"> <section anchor="sec-RS-example-2">
<name>Diff Query with Observe</name> <name>Diff Query with Observe</name>
<t><xref target="fig-RS-AS-2"/> shows an interaction example considering <t><xref target="fig-RS-AS-2"/> shows an interaction example of a CoAP o
a CoAP observation and a diff query of the TRL.</t> bservation and a diff query of the TRL.</t>
<t>The RS indicates N = 3 as value of the 'diff' query parameter, i.e., <t>The RS indicates N = 3 as the value of the 'diff' query parameter, i.
as the maximum number of diff entries to be specified in a response from the AS. e., as the maximum number of diff entries to be specified in a response from the
</t> AS.</t>
<t>In this example, the AS does not support the "Cursor" extension. Henc e, the 'cursor' parameter and the 'more' parameter are not included in the paylo ad of the responses to a diff query request.</t> <t>In this example, the AS does not support the "Cursor" extension. Henc e, the 'cursor' parameter and the 'more' parameter are not included in the paylo ad of the responses to a diff query request.</t>
<figure anchor="fig-RS-AS-2"> <figure anchor="fig-RS-AS-2">
<name>Interaction for diff query with Observe</name> <name>Interaction for Diff Query with Observe</name>
<artset> <artset>
<artwork type="svg" align="center"><svg xmlns="http://www.w3.org/200 0/svg" version="1.1" height="1504" width="440" viewBox="0 0 440 1504" class="dia gram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linec ap="round"> <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/200 0/svg" version="1.1" height="1504" width="440" viewBox="0 0 440 1504" class="dia gram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linec ap="round">
<path d="M 8,48 L 8,1488" fill="none" stroke="black"/> <path d="M 8,48 L 8,1488" fill="none" stroke="black"/>
<path d="M 432,48 L 432,1488" fill="none" stroke="black"/> <path d="M 432,48 L 432,1488" fill="none" stroke="black"/>
<path d="M 8,80 L 424,80" fill="none" stroke="black"/> <path d="M 8,80 L 424,80" fill="none" stroke="black"/>
<path d="M 16,112 L 432,112" fill="none" stroke="black"/> <path d="M 16,112 L 432,112" fill="none" stroke="black"/>
<path d="M 8,288 L 424,288" fill="none" stroke="black"/> <path d="M 8,288 L 424,288" fill="none" stroke="black"/>
<path d="M 16,320 L 432,320" fill="none" stroke="black"/> <path d="M 16,320 L 432,320" fill="none" stroke="black"/>
<path d="M 16,592 L 432,592" fill="none" stroke="black"/> <path d="M 16,592 L 432,592" fill="none" stroke="black"/>
<path d="M 16,816 L 432,816" fill="none" stroke="black"/> <path d="M 16,816 L 432,816" fill="none" stroke="black"/>
skipping to change at line 2573 skipping to change at line 2579
| [ [bstr.h(t1)], [] ], | | [ [bstr.h(t1)], [] ], |
| [ [], [bstr.h(t2)] ] | | [ [], [bstr.h(t2)] ] |
| ] | | ] |
| } | | } |
| | | |
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
</section> </section>
<section anchor="sec-RS-example-3"> <section anchor="sec-RS-example-3">
<name>Full Query with Observe plus Diff Query</name> <name>Full Query with Observe Plus Diff Query</name>
<t><xref target="fig-RS-AS-3"/> shows an interaction example considering <t><xref target="fig-RS-AS-3"/> shows an interaction example of a CoAP o
a CoAP observation and a full query of the TRL.</t> bservation and a full query of the TRL.</t>
<t>The example also considers one of the notifications from the AS to ge <t>The example also shows one of the notifications from the AS getting l
t lost in transmission, and thus not reaching the RS.</t> ost in transmission; thus, it does not reach the RS.</t>
<t>When this happens, and after a waiting time defined by the applicatio <t>When this happens, and after a waiting time defined by the applicatio
n has elapsed, the RS sends a GET request with no Observe Option to the AS, to p n has elapsed, the RS sends a GET request with no Observe Option to the AS to pe
erform a diff query of the TRL. The RS indicates N = 8 as value of the 'diff' qu rform a diff query of the TRL. The RS indicates N = 8 as the value of the 'diff'
ery parameter, i.e., as the maximum number of diff entries to be specified in a query parameter, i.e., as the maximum number of diff entries to be specified in
response from the AS.</t> a response from the AS.</t>
<t>In this example, the AS does not support the "Cursor" extension. Henc e, the 'cursor' parameter is not included in the payload of the responses to a f ull query request. Also, the 'cursor' parameter and the 'more' parameter are not included in the payload of the responses to a diff query request.</t> <t>In this example, the AS does not support the "Cursor" extension. Henc e, the 'cursor' parameter is not included in the payload of the responses to a f ull query request. Also, the 'cursor' parameter and the 'more' parameter are not included in the payload of the responses to a diff query request.</t>
<figure anchor="fig-RS-AS-3"> <figure anchor="fig-RS-AS-3">
<name>Interaction for full query with Observe plus diff query</name> <name>Interaction for Full Query with Observe Plus Diff Query</name>
<artset> <artset>
<artwork type="svg" align="center"><svg xmlns="http://www.w3.org/200 0/svg" version="1.1" height="1632" width="440" viewBox="0 0 440 1632" class="dia gram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linec ap="round"> <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/200 0/svg" version="1.1" height="1632" width="440" viewBox="0 0 440 1632" class="dia gram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linec ap="round">
<path d="M 8,48 L 8,1616" fill="none" stroke="black"/> <path d="M 8,48 L 8,1616" fill="none" stroke="black"/>
<path d="M 432,48 L 432,1616" fill="none" stroke="black"/> <path d="M 432,48 L 432,1616" fill="none" stroke="black"/>
<path d="M 8,80 L 424,80" fill="none" stroke="black"/> <path d="M 8,80 L 424,80" fill="none" stroke="black"/>
<path d="M 16,112 L 432,112" fill="none" stroke="black"/> <path d="M 16,112 L 432,112" fill="none" stroke="black"/>
<path d="M 8,288 L 424,288" fill="none" stroke="black"/> <path d="M 8,288 L 424,288" fill="none" stroke="black"/>
<path d="M 16,320 L 432,320" fill="none" stroke="black"/> <path d="M 16,320 L 432,320" fill="none" stroke="black"/>
<path d="M 16,592 L 432,592" fill="none" stroke="black"/> <path d="M 16,592 L 432,592" fill="none" stroke="black"/>
<path d="M 16,784 L 432,784" fill="none" stroke="black"/> <path d="M 16,784 L 432,784" fill="none" stroke="black"/>
skipping to change at line 2877 skipping to change at line 2883
| ] | | ] |
| } | | } |
| | | |
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
</section> </section>
<section anchor="sec-RS-example-2-3"> <section anchor="sec-RS-example-2-3">
<name>Diff Query with Observe and "Cursor"</name> <name>Diff Query with Observe and "Cursor"</name>
<t>In this example, the AS supports the "Cursor" extension. Hence, the C BOR map conveyed as payload of the registration response additionally includes a "max_diff_batch" parameter. This specifies the value of MAX_DIFF_BATCH, i.e., t he maximum number of diff entries that can be included in a response to a diff q uery request from this RS.</t> <t>In this example, the AS supports the "Cursor" extension. Hence, the C BOR map conveyed as payload of the registration response additionally includes a "max_diff_batch" parameter. This specifies the value of MAX_DIFF_BATCH, i.e., t he maximum number of diff entries that can be included in a response to a diff q uery request from this RS.</t>
<t><xref target="fig-RS-AS-4"/> shows an interaction example considering <t><xref target="fig-RS-AS-4"/> shows an interaction example of a CoAP o
a CoAP observation and a diff query of the TRL.</t> bservation and a diff query of the TRL.</t>
<t>The RS specifies the query parameter 'diff' with value 3, i.e., the m <t>The RS specifies the query parameter 'diff' with a value of 3, i.e.,
aximum number of diff entries to be specified in a response from the AS.</t> the maximum number of diff entries to be specified in a response from the AS.</t
<t>After the RS has not received a notification from the AS for a waitin >
g time defined by the application, the RS sends a GET request with no Observe Op <t>If the RS has not received a notification from the AS after a waiting
tion to the AS, to perform a diff query of the TRL.</t> time defined by the application, the RS sends a GET request with no Observe Opt
ion to the AS to perform a diff query of the TRL.</t>
<t>This is followed up by a further diff query request that specifies th e query parameter 'cursor'. Note that the payload of the corresponding response differs from the payload of the response to the previous diff query request.</t> <t>This is followed up by a further diff query request that specifies th e query parameter 'cursor'. Note that the payload of the corresponding response differs from the payload of the response to the previous diff query request.</t>
<figure anchor="fig-RS-AS-4"> <figure anchor="fig-RS-AS-4">
<name>Interaction for diff query with Observe and "Cursor"</name> <name>Interaction for Diff Query with Observe and "Cursor"</name>
<artset> <artset>
<artwork type="svg" align="center"><svg xmlns="http://www.w3.org/200 0/svg" version="1.1" height="2224" width="472" viewBox="0 0 472 2224" class="dia gram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linec ap="round"> <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/200 0/svg" version="1.1" height="2224" width="472" viewBox="0 0 472 2224" class="dia gram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linec ap="round">
<path d="M 8,48 L 8,2208" fill="none" stroke="black"/> <path d="M 8,48 L 8,2208" fill="none" stroke="black"/>
<path d="M 464,48 L 464,2208" fill="none" stroke="black"/> <path d="M 464,48 L 464,2208" fill="none" stroke="black"/>
<path d="M 8,80 L 456,80" fill="none" stroke="black"/> <path d="M 8,80 L 456,80" fill="none" stroke="black"/>
<path d="M 16,112 L 464,112" fill="none" stroke="black"/> <path d="M 16,112 L 464,112" fill="none" stroke="black"/>
<path d="M 8,304 L 456,304" fill="none" stroke="black"/> <path d="M 8,304 L 456,304" fill="none" stroke="black"/>
<path d="M 16,336 L 464,336" fill="none" stroke="black"/> <path d="M 16,336 L 464,336" fill="none" stroke="black"/>
<path d="M 16,640 L 464,640" fill="none" stroke="black"/> <path d="M 16,640 L 464,640" fill="none" stroke="black"/>
<path d="M 16,896 L 464,896" fill="none" stroke="black"/> <path d="M 16,896 L 464,896" fill="none" stroke="black"/>
skipping to change at line 3308 skipping to change at line 3314
| e'diff_set' : [], | | e'diff_set' : [], |
| e'cursor' : 3, | | e'cursor' : 3, |
| e'more' : false | | e'more' : false |
| } | | } |
| | | |
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
</section> </section>
<section anchor="sec-RS-example-5"> <section anchor="sec-RS-example-5">
<name>Full Query with Observe plus Diff Query with "Cursor"</name> <name>Full Query with Observe Plus Diff Query with "Cursor"</name>
<t>In this example, the AS supports the "Cursor" extension. Hence, the C BOR map conveyed as payload of the registration response additionally includes a "max_diff_batch" parameter. This specifies the value of MAX_DIFF_BATCH, i.e., t he maximum number of diff entries that can be included in a response to a diff q uery request from this RS.</t> <t>In this example, the AS supports the "Cursor" extension. Hence, the C BOR map conveyed as payload of the registration response additionally includes a "max_diff_batch" parameter. This specifies the value of MAX_DIFF_BATCH, i.e., t he maximum number of diff entries that can be included in a response to a diff q uery request from this RS.</t>
<t><xref target="fig-RS-AS-5"/> shows an interaction example considering <t><xref target="fig-RS-AS-5"/> shows an interaction example of a CoAP o
a CoAP observation and a full query of the TRL.</t> bservation and a full query of the TRL.</t>
<t>The example also considers some of the notifications from the AS to g <t>The example also shows some of the notifications from the AS getting
et lost in transmission, and thus not reaching the RS.</t> lost in transmission; thus, they do not reach the RS.</t>
<t>When this happens, and after a waiting time defined by the applicatio n has elapsed, the RS sends a GET request with no Observe Option to the AS, to p erform a diff query of the TRL. In particular, the RS specifies:</t> <t>When this happens, and after a waiting time defined by the applicatio n has elapsed, the RS sends a GET request with no Observe Option to the AS, to p erform a diff query of the TRL. In particular, the RS specifies:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>The query parameter 'diff' with value 8, i.e., the maximum number of diff entries to be specified in a response from the AS.</t> <t>The query parameter 'diff' with a value of 8, i.e., the maximum n umber of diff entries to be specified in a response from the AS.</t>
</li> </li>
<li> <li>
<t>The query parameter 'cursor' with value 2, thus requesting from t he update collection the series items following the one with 'index' value equal to 2 (i.e., following the last series item that the RS successfully received in an earlier notification response).</t> <t>The query parameter 'cursor' with a value of 2, thus requesting f rom the update collection the series items following the one with the 'index' va lue equal to 2 (i.e., following the last series item that the RS successfully re ceived in an earlier notification response).</t>
</li> </li>
</ul> </ul>
<t>The response from the AS conveys a first batch of MAX_DIFF_BATCH = 5 <t>The response from the AS conveys a first batch of MAX_DIFF_BATCH = 5
series items from the update collection corresponding to the RS. The AS indicate series items from the update collection corresponding to the RS. The AS indicate
s that further series items are actually available in the update collection, by s that further series items are actually available in the update collection by s
setting the 'more' parameter of the response to <tt>true</tt>. Also, the 'cursor etting the 'more' parameter of the response to <tt>true</tt>. Also, the 'cursor'
' parameter of the response is set to 7, i.e., to the 'index' value of the most parameter of the response is set to 7, i.e., to the 'index' value of the most r
recent series item included in the response.</t> ecent series item included in the response.</t>
<t>After that, the RS follows up with a further diff query request speci <t>After that, the RS follows up with a further diff query request speci
fying the query parameter 'cursor' with value 7, in order to retrieve the next a fying the query parameter 'cursor' with a value of 7 in order to retrieve the ne
nd last batch of series items from the update collection.</t> xt and last batch of series items from the update collection.</t>
<figure anchor="fig-RS-AS-5"> <figure anchor="fig-RS-AS-5">
<name>Interaction for full query with Observe plus diff query with "Cu rsor"</name> <name>Interaction for Full Query with Observe Plus Diff Query with "Cu rsor"</name>
<artset> <artset>
<artwork type="svg" align="center"><svg xmlns="http://www.w3.org/200 0/svg" version="1.1" height="3568" width="528" viewBox="0 0 528 3568" class="dia gram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linec ap="round"> <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/200 0/svg" version="1.1" height="3568" width="528" viewBox="0 0 528 3568" class="dia gram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linec ap="round">
<path d="M 8,48 L 8,3552" fill="none" stroke="black"/> <path d="M 8,48 L 8,3552" fill="none" stroke="black"/>
<path d="M 520,48 L 520,3552" fill="none" stroke="black"/> <path d="M 520,48 L 520,3552" fill="none" stroke="black"/>
<path d="M 8,80 L 512,80" fill="none" stroke="black"/> <path d="M 8,80 L 512,80" fill="none" stroke="black"/>
<path d="M 16,112 L 520,112" fill="none" stroke="black"/> <path d="M 16,112 L 520,112" fill="none" stroke="black"/>
<path d="M 8,304 L 512,304" fill="none" stroke="black"/> <path d="M 8,304 L 512,304" fill="none" stroke="black"/>
<path d="M 16,336 L 520,336" fill="none" stroke="black"/> <path d="M 16,336 L 520,336" fill="none" stroke="black"/>
<path d="M 16,704 L 520,704" fill="none" stroke="black"/> <path d="M 16,704 L 520,704" fill="none" stroke="black"/>
<path d="M 16,912 L 520,912" fill="none" stroke="black"/> <path d="M 16,912 L 520,912" fill="none" stroke="black"/>
skipping to change at line 3764 skipping to change at line 3770
<text x="160" y="3508">e'cursor'</text> <text x="160" y="3508">e'cursor'</text>
<text x="208" y="3508">:</text> <text x="208" y="3508">:</text>
<text x="232" y="3508">10,</text> <text x="232" y="3508">10,</text>
<text x="168" y="3524">e'more'</text> <text x="168" y="3524">e'more'</text>
<text x="208" y="3524">:</text> <text x="208" y="3524">:</text>
<text x="240" y="3524">false</text> <text x="240" y="3524">false</text>
<text x="96" y="3540">}</text> <text x="96" y="3540">}</text>
</g> </g>
</svg> </svg>
</artwork> </artwork>
<artwork type="ascii-art" align="center"><![CDATA[ <artwork type="ascii-art" align="center"><![CDATA[
RS AS RS AS
| | | |
| Registration: POST | | Registration: POST |
+-------------------------------------------------------------->| +-------------------------------------------------------------->|
| | | |
|<--------------------------------------------------------------+ |<--------------------------------------------------------------+
| 2.01 Created | | 2.01 Created |
| Payload: { | | Payload: { |
| / ... / | | / ... / |
| "trl_path" : "/revoke/trl", | | "trl_path" : "/revoke/trl", |
skipping to change at line 3990 skipping to change at line 3996
| [ [], [bstr.h(t5), bstr.h(t6)] ] | | [ [], [bstr.h(t5), bstr.h(t6)] ] |
| ], | | ], |
| e'cursor' : 10, | | e'cursor' : 10, |
| e'more' : false | | e'more' : false |
| } | | } |
| | | |
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
</section> </section>
</section> </section>
<section anchor="sec-cddl-model" removeInRFC="true">
<!-- [rfced] We note that Appendices D and E were tagged "removeInRFC"
in the XML. We have removed Appendix E (change log) but left
Appendix D as it has citations to it in the text. Please review
and let us know if any further updates are necessary. -->
<section anchor="sec-cddl-model" >
<name>CDDL Model</name> <name>CDDL Model</name>
<figure anchor="fig-cddl-model"> <figure anchor="fig-cddl-model">
<name>CDDL model</name> <name>CDDL Model</name>
<artwork type="CDDL" align="left"><![CDATA[ <sourcecode type="CDDL"><![CDATA[
full_set = 0 full_set = 0
diff_set = 1 diff_set = 1
cursor = 2 cursor = 2
more = 3 more = 3
ace-trl-error = 1 ace-trl-error = 1
]]></artwork> ]]></sourcecode>
</figure> </figure>
</section> </section>
<section anchor="sec-document-updates" removeInRFC="true">
<name>Document Updates</name>
<section anchor="sec-08-09">
<name>Version -08 to -09</name>
<ul spacing="normal">
<li>
<t>Terminology: </t>
<ul spacing="normal">
<li>
<t>Improved definition of "administrator".</t>
</li>
<li>
<t>Added early definitions of "Full query" and "Diff query".</t>
</li>
</ul>
</li>
<li>
<t>Rephrased "full TRL" to avoid confusion with "full query".</t>
</li>
<li>
<t>Consistent with RFC 6920, defined sha-256 as mandatory to impleme
nt.</t>
</li>
<li>
<t>Prevented an attack to the RS by: </t>
<ul spacing="normal">
<li>
<t>Using only Protected Headers in access tokens.</t>
</li>
<li>
<t>Using canonical CBOR tagging of CWTs.</t>
</li>
</ul>
</li>
<li>
<t>Clarifications: </t>
<ul spacing="normal">
<li>
<t>Handling of access tokens with 'exi' for both CWTs and JWTs.<
/t>
</li>
<li>
<t>Registrations of devices are persisted and tracked at the AS.
</t>
</li>
<li>
<t>No response or error response from the TRL endpoint yields no
assumption.</t>
</li>
<li>
<t>Rationale of application policies in defining strategies and
schedules for polling the AS.</t>
</li>
</ul>
</li>
<li>
<t>Security considerations: </t>
<ul spacing="normal">
<li>
<t>Added reference to RFC 8725.</t>
</li>
<li>
<t>Improved considerations on content retrieval from the TRL.</t
>
</li>
</ul>
</li>
<li>
<t>IANA: </t>
<ul spacing="normal">
<li>
<t>Added a pointer to where the use of the field 'cursor' in pro
blem-details is defined.</t>
</li>
<li>
<t>Revised text on Expert Review when using early allocation per
RFC 7120.</t>
</li>
</ul>
</li>
<li>
<t>Split elision and comments in examples with CBOR Diagnostic Notat
ion.</t>
</li>
<li>
<t>Lowercase capitalization for "client", "resource server", and "au
thorization server".</t>
</li>
<li>
<t>Editorial improvements.</t>
</li>
</ul>
</section>
<section anchor="sec-07-08">
<name>Version -07 to -08</name>
<ul spacing="normal">
<li>
<t>Added definition of pertaining token hash.</t>
</li>
<li>
<t>Added definition of pertaining TRL update.</t>
</li>
<li>
<t>Rephrased example of token uploading to be more future ready.</t>
</li>
<li>
<t>Consistent use of "TRL update" throughout the document.</t>
</li>
<li>
<t>Editorial improvements.</t>
</li>
</ul>
</section>
<section anchor="sec-06-07">
<name>Version -06 to -07</name>
<ul spacing="normal">
<li>
<t>RFC 9290 is used instead of the custom format for error responses
.</t>
</li>
<li>
<t>Avoided quotation marks when using CBOR simple values.</t>
</li>
<li>
<t>CBOR diagnostic notation uses placeholders from a CDDL model.</t>
</li>
<li>
<t>Early mentioning that there is a single MAX_N value.</t>
</li>
<li>
<t>Added more details on the authorization of administrators.</t>
</li>
<li>
<t>Added recommendations for avoiding lost TRL updates from going un
noticed.</t>
</li>
<li>
<t>If diff queries are supported, the AS <bcp14>MUST</bcp14> provide
MAX_N at registration.</t>
</li>
<li>
<t>If the "Cursor" extension is supported, the AS <bcp14>MUST</bcp14
> provide MAX_DIFF_BATCH at registration.</t>
</li>
<li>
<t>Clarified that how the token revocation specifically happens is o
ut of scope.</t>
</li>
<li>
<t>Clearer, upfront distinction between using CoAP Observe or not.</
t>
</li>
<li>
<t>Revised and extended method for computing the token hashes.</t>
</li>
<li>
<t>Clearer presentation of invalid requests to the TRL endpoint.</t>
</li>
<li>
<t>Clearer expected relation between MAX_INDEX and MAX_N values.</t>
</li>
<li>
<t>Clarified meaning of registered parameters.</t>
</li>
<li>
<t>Generalized security considerations on vulnerable time window at
the RS.</t>
</li>
<li>
<t>Added security considerations on additional security measures.</t
>
</li>
<li>
<t>Fixes and improvements in the IANA considerations.</t>
</li>
<li>
<t>Used AASVG in diagrams.</t>
</li>
<li>
<t>Used actual tables instead of figures.</t>
</li>
<li>
<t>Fixed notation in the examples.</t>
</li>
<li>
<t>Clarifications and editorial improvements.</t>
</li>
</ul>
</section>
<section anchor="sec-05-06">
<name>Version -05 to -06</name>
<ul spacing="normal">
<li>
<t>Clarified instructions for Expert Review in the IANA consideratio
ns.</t>
</li>
</ul>
</section>
<section anchor="sec-04-05">
<name>Version -04 to -05</name>
<ul spacing="normal">
<li>
<t>Explicit focus on CoAP in the abstract and introduction.</t>
</li>
<li>
<t>Removed terminology aliasing ("TRL endpoint" vs. "TRL resource").
</t>
</li>
<li>
<t>Use "requester" instead of "caller".</t>
</li>
<li>
<t>Use "subset" instead of "portion".</t>
</li>
<li>
<t>Revised presentation of how token hashes are computed.</t>
</li>
<li>
<t>Improved error handling.</t>
</li>
<li>
<t>Revised examples.</t>
</li>
<li>
<t>More precise security considerations.</t>
</li>
<li>
<t>Clarifications and editorial improvements.</t>
</li>
<li>
<t>Updated author list.</t>
</li>
</ul>
</section>
<section anchor="sec-03-04">
<name>Version -03 to -04</name>
<ul spacing="normal">
<li>
<t>Improved presentation of pre- and post-registration operations.</
t>
</li>
<li>
<t>Removed moot processing cases with the "Cursor" extension.</t>
</li>
<li>
<t>Positive integers as CBOR abbreviations for all parameters.</t>
</li>
<li>
<t>Renamed N_MAX as MAX_N.</t>
</li>
<li>
<t>Access tokens are not necessarily uploaded through /authz-info.</
t>
</li>
<li>
<t>The use of the "c.pmax" conditional attribute is just an example.
</t>
</li>
<li>
<t>Revised handling of token hashes at the RS.</t>
</li>
<li>
<t>Extended and improved security considerations.</t>
</li>
<li>
<t>Fixed details in IANA considerations.</t>
</li>
<li>
<t>New appendix overviewing parameters of the TRL endpoint.</t>
</li>
<li>
<t>Examples of message exchange moved to an appendix.</t>
</li>
<li>
<t>Added examples of message exchange with the "Cursor" extension.</
t>
</li>
<li>
<t>Clarifications and editorial improvements.</t>
</li>
</ul>
</section>
<section anchor="sec-02-03">
<name>Version -02 to -03</name>
<ul spacing="normal">
<li>
<t>Definition of MAX_INDEX for the "Cursor" extension.</t>
</li>
<li>
<t>Handling wrap-around of 'index' when using the "Cursor" extension
.</t>
</li>
<li>
<t>Error handling for the case where 'cursor' &gt; MAX_INDEX.</t>
</li>
<li>
<t>Improved error handling in case 'index' is out-of-bound.</t>
</li>
<li>
<t>Clarified parameter semantics, message content and examples.</t>
</li>
<li>
<t>Editorial improvements.</t>
</li>
</ul>
</section>
<section anchor="sec-01-02">
<name>Version -01 to -02</name>
<ul spacing="normal">
<li>
<t>Earlier mentioning of error cases.</t>
</li>
<li>
<t>Clearer distinction between maintaining the history of TRL update
s and preparing the response to a diff query.</t>
</li>
<li>
<t>Defined the use of "cursor" in the document body, as an extension
of diff queries.</t>
</li>
<li>
<t>Both success and error responses have a CBOR map as payload.</t>
</li>
<li>
<t>Corner cases of message processing explained more explicitly.</t>
</li>
<li>
<t>Clarifications and editorial improvements.</t>
</li>
</ul>
</section>
<section anchor="sec-00-01">
<name>Version -00 to -01</name>
<ul spacing="normal">
<li>
<t>Added actions to perform upon receiving responses from the TRL en
dpoint.</t>
</li>
<li>
<t>Fixed off-by-one error when using the "Cursor" pattern.</t>
</li>
<li>
<t>Improved error handling, with registered error codes.</t>
</li>
<li>
<t>Section restructuring (full- and diff-query as self-standing sect
ions).</t>
</li>
<li>
<t>Renamed identifiers and CBOR parameters.</t>
</li>
<li>
<t>Clarifications and editorial improvements.</t>
</li>
</ul>
</section>
</section>
<section numbered="false" anchor="acknowldegment"> <section numbered="false" anchor="acknowldegment">
<name>Acknowledgments</name> <name>Acknowledgments</name>
<t><contact fullname="Ludwig Seitz"/> contributed as a co-author of initia <t><contact fullname="Ludwig Seitz"/> contributed as a coauthor of
l versions of this document.</t> initial versions of this document.</t>
<t>The authors sincerely thank <contact fullname="Christian Amsüss"/>, <co <t>The authors sincerely thank <contact fullname="Christian Amsüss"/>,
ntact fullname="Carsten Bormann"/>, <contact fullname="Deb Cooley"/>, <contact f <contact fullname="Carsten Bormann"/>, <contact fullname="Deb Cooley"/>,
ullname="Roman Danyliw"/>, <contact fullname="Dhruv Dhody"/>, <contact fullname= <contact fullname="Roman Danyliw"/>, <contact fullname="Dhruv Dhody"/>,
"Rikard Höglund"/>, <contact fullname="Benjamin Kaduk"/>, <contact fullname="Dav <contact fullname="Rikard Höglund"/>, <contact fullname="Benjamin
id Navarro"/>, <contact fullname="Joerg Ott"/>, <contact fullname="Marco Rasori" Kaduk"/>, <contact fullname="David Navarro"/>, <contact fullname="Joerg
/>, <contact fullname="Michael Richardson"/>, <contact fullname="Kyle Rose"/>, < Ott"/>, <contact fullname="Marco Rasori"/>, <contact fullname="Michael
contact fullname="Zaheduzzaman Sarker"/>, <contact fullname="Jim Schaad"/>, <con Richardson"/>, <contact fullname="Kyle Rose"/>, <contact
tact fullname="Göran Selander"/>, <contact fullname="Travis Spencer"/>, <contact fullname="Zaheduzzaman Sarker"/>, <contact fullname="Jim Schaad"/>,
fullname="Orie Steele"/>, <contact fullname="Éric Vyncke"/>, <contact fullname= <contact fullname="Göran Selander"/>, <contact fullname="Travis
"Niklas Widell"/>, <contact fullname="Dale Worley"/>, and <contact fullname="Pau Spencer"/>, <contact fullname="Orie Steele"/>, <contact fullname="Éric
l Wouters"/> for their comments and feedback.</t> Vyncke"/>, <contact fullname="Niklas Widell"/>, <contact fullname="Dale
<t>The work on this document has been partly supported by the Sweden's Inn Worley"/>, and <contact fullname="Paul Wouters"/> for their comments and
ovation Agency VINNOVA and the Celtic-Next projects CRITISEC and CYPRESS; and by feedback.</t>
the H2020 project SIFIS-Home (Grant agreement 952652).</t> <t>The work on this document has been partly supported by the Sweden's
Innovation Agency VINNOVA and the Celtic-Next projects CRITISEC and
CYPRESS; and by the H2020 project SIFIS-Home (Grant agreement
952652).</t>
</section> </section>
</back> </back>
<!-- ##markdown-source:
H4sIAAAAAAAAA+y96XrbVpYo+l9Pgct890hKkbRIDZaVSnfLkhzLsSVFlCpD <!--[rfced] We had the following questions/comments related to
VdoHJEESMQUwAChZ5fg8y3mW+2R3TXsCNkhKcapS1fE5naJIYA9rr73modVq abbreviation use throughout the document.
rd0eBNtra0VcTKOD4Cwt4lE8CIs4TYJ0FFxGt+m7aBgcDgZRngdX8EeSB3ES
FJMoOJzDf5NCPR4mQ/oqzeK/8zejNAuO0iQvsjBOYJST5DbO0uQGXsqDjcOj a) After first use with expansion, we will update the following to use
k83gRRbeRHdp9m4t7Pez6LZ+CWZueHFtmA4SePMgGGbhqGjFUTFqhYOolfHT only the abbreviation thereafter unless we hear objection:
rQKfbiXWWK1pWER5sba29lmQF7DYt+E0TWCEIptHa2vxLKOPedHd2nq21V0L
syg8CHrRYJ7Fxf3a3fgAJw6+hbXGyTj4Kkvns7V3dwfBaVJEWRIVrWNcyhrM RS
dgATDNfyef8mznOYurifwTynJ1cv1tYG6RBePwjmsOD9tVl8EMC/z4JBmATz AS
PArCLAvvg414FITTaXAf5ZsBAHES5pNgEmWwziAo0sEB/gIf8zQrsmiUH9AY CWT
w2gUzqcA2iJVv9/f8M/451pIh3OwFtC/lvxvACCFJ960g6t4mg5C/TXD902Y
DdLyT2kGO7g87Z0Eh8/1l3DMUQR7P83D0U9pNszHIYA56Hb1EwMA5EHwdQzg b) We have expanded the following abbreviations on first use. Please
N9+lQ5ild9Lq7O3sbFlfz5Mig6d7d9EwSvT30U0YTw+CG1xVu6BV/VcWt/PI review and let us know any objections.
v6sX7eACjvmmHydxaWOAeQkg9SD0PEH7O8niQZ4DEnr2eJVm+SS8SdQet3+D
PY7UAtsztcD/imRN7UF6499xrx2cDCbRbZRlcfkse1E/zIsYFux5hPZ89OYa IoT
1nla2e/O7tZW8CIeFZPg8DZK5lFpvxdxUeT9eTaeNIOLw9LGO7vdznaru9fp CDDL
Vrd+ncQFXO5egZcTr/vhDe4xLAMjj/SK/yuP4vbgZt6OhnM/DL5qB6+juzgv CBOR
bf+rDChE6Zff967HU1yss+G1JM1ugKDdRniRL18cbe91n8nHnb2dffm4t73z JWE
VH18uqMe2Nvf1g88627Jx6cd87G721Uf93Y68nG/u6tGeLrb2TUf98xH9cB+ JWS
p6u+3d9+pgbb39nR3+51tszHbfURZlYfn+n1PtvSy3nW0RuClasRnu129823 OSCORE
XfNxW398pp/d2e6UXjsDvBi2T5MRwxTu1UugtO3D6RiYWDG5YVrp0k3CmNPD -->
Mz7vIZwgXNVwKhRI8VEcOLAGDnDgQA/Mz4bZGNFsUhSz/ODJk7u7uzZczrAN
UzwJgXOMmVU+QfQdtmIzWvWb9vtJcTOFYXsvD1vd3b3alZ+d9q7slRKDi3h5 <!--[rfced] We had the following questions regarding terminology used
PWSLYTak33PAyCjHKYBWnl70gs7+Vmvb2jScwn6rs1XZCuxkkGeDdgI0sD1O throughout the document:
b5/M5v2pMOH8ySie8X9oOPPp7ShOwml7NhwBL1b70kj+FHgyfjxtHbeJ1w/S
LIL/JMMYhw2nrbAosrg/h/uknuvjGEnSKrpFNm7lsLC1NRRX4OYinE5evzgI a) Please review the way parameter names are marked with regard to quotation, wo
Gn+FwVvfwb8fG2trrVYrCPsorgxATriaxHkAcsYcDyHIZ9EAZAm4rmFwEwFY rd order, and the use of simply "parameter" or "query parameter". For example (
h3hvHyUG+eSgkZKDmsHdJB5MkP2ndzBZIoeoBoNjATKILJ6Em/tgMI1pHJw3 there may be more/others), we see:
i/J0ngGR46dg8LgdtZvw/RgOA+SHIQgJt/EAxYqwn86LQOSlIGQBj8SmvB0c
5nrDQxb3LFg0adsCBFnnwlXAYmX8kMU4EuoEXq9hZUHKEqV3q/17kIxQ5MIn the 'access_token' parameter / the parameter 'access_token'
bDgezmYKr4KLLAW5KJ0GG0fp4cUmQBGuGb0xS+Em9acw+FAhC0lacHp6oWkf
5+KLBGvLQYrCCTfmSZ7CFEisNwNbmMz5dQ/sgMjfzKYR4Uw4RcmQ8DgIZ7Ms the 'diff' query parameter / the query parameter 'diff'
DYGJAWTneL7yAkC3yFIENo5Lpw9rhblg+J/ncYbrsFYeJcNZGiOkYdOLgN5m
dL6Jh8NphDLvKc4znNM0ICx++Iwm/ri29inE+A8fhC5//BjEeMwan+EMwgKW the 'cursor' query parameter / the query parameter 'cursor' / the 'cursor' param
DYMM8PIwrODmwuRT3MRpeqWQEn4luANsqph82cs327ALIGNDvgB4ijB7M+in eter
cNY2MOBZkJkB6vCUwn3GiLr7tHHY26RX+xEcIBxX9c60g3OQx6zvm/AUz0ri
ew5nQ+/9PAc9A6cm6tBr4se0XwDwaHoLWwi08N0lSG0v8KMaz9wYHOOyx1dO Please let us know if/how these may be made uniform throughout.
frwBJSWYAYToSfgetIx5CQ+DsNCvMkHBQw5uw2k8JKEjLmCrMD1AuEgJy+Cb
jTyK4Cx7jIzBbruz1e60O6SGqfPdBMw6AWkIBkzn40kJ+wnq0ftZnDF4i/gm b) We note that most field names were in single quotes. We have updated the wor
ymn1GSo3sIc4AyqCChgeONxtIXclwNyAFpREsCmARD/SV02WHMM5lyZpqmt1 d order in some places to appear as follows:
EGx0Nn3nh1oUDACD4xXNUlDO8AwB7DHeSbqCEVH1foTwsJ76Itjo+sdEsogY
I5oePbq9KfvVE8K5TsJkHGnNGRRJGHuEV51QoDoyjLOzcBwB14wIFICydhzE 'name' field
6o3dpWsCbkCYD/unMe+DCLBlbkiAb/sbUXsM/CXW74DYAqsi6jeMZnAjiFAN
70FgiQeBZtjahhC9B/mDpogMVWFsh+udEaGI3hd0TPilpgvw0lTuMGIkMKxh We also see a few uses of "unprotected" field. Is this a name? Or is
nA/mMD0xLIPEeyX8haGSqWKbIELBekI898ywJDhUEIoy+B0eNHyQiBxKIkDk this a different use of quotes? If a name, we suggest matching the
ECDnSCaDbnuLf0E5G4cHHQvRSDgaXM2bGWMpEkL3tsBCeRC8GXKLmUzBcqbE pattern above. If a different concept, perhaps we can remove the
OHAFQK6KYBqPIkT0dvAyvUNVqMlcGf4/cgu4Doy/fGGIXMBCaKEDQ7ybyG+i quotes?
7AY0F94e/Jbwi0KEm7xQunzuamll1rqmKdwStSxkOEslJkIjFBjwflWFEltQ
AKQVzg0AmPfzAUh3RM/rRIiNq8vXmwrsSHVji1UI+Z3PhnTWluAsctAsyvAJ c) We note that we normally see "a 2.05 (Content) response However,
4j7OpgkYd3hzFA2aZXGaCXmPM4sOrSQ2eXaNfOwBso3gIWhqgIewDKQ+8wQf there is one use of "the CoAP response code 2.05 (Content). Please
jozUc9gjENLfQJbgjxTvf5O+JW5lwxTfAPAZ6BmhyycjiURweCFLAU3x40dg review and let us know if/how these should be made uniform.
jzhDME8A5tN7fHcmCycoJvwGYjriK/w2ifukBo+AygrNzeezGSC7gh6g77wA
9YQoDPx5T68PoxHBiDF9npunka4ayQNXuUy4Aay9TqbxO00G6dKgZF8Vzqrs d) Please review uses of "Cursor". When double quoted, should it always be foll
8ZnLGZteGjlMo1xt+TYe4lkE6V1SZthaXqB1x4kW/gg/keMJTULrZRGhKATz owed by the word extension? Note also that [I-D.bormann-t2trg-stp] uses 'cursor
hEOfdB/kMQih9/8YtG+ivBaNRsiGiKTAHpOC70AfCQysOp8h5YdZyJKJfEUI ' pattern (single quotes) instead.
RgRHmMB5FjmrU3BflGKRRbwKkEuMTF0jNeO5wnMa1Cw7R3U3DnYhmAZv3vvl
azlsIpZJOk3H9yj7BLhkYiDWSzIbrw9PzzMlbkcLh08YInnE1DhkfLIv7yqU Examples below:
UN1aWWkeDVop8IXbOLpjZIQ38ZlpPJ4UdxH+lyA5L7Rx3ToOJVGHuYuX+jSz
3J5JDOxw11gkRLgAgtOLRqpzcIrv7mAaZsJuEa3gwBERRZfOB+ks0pigKCfg Originals:
ekFqxTRP1dP8pKWI6kkFgsOIjw4NbJlwSUbKOtWtiX8CyyBdM3VHQxaKZ0cI ...as specified in Section 9 in fact relies on the "Cursor" pattern of
zvcp1wcQLiL7AJvPPguuDBoFn6H2ZeMVQ+8dkLc7tJsHjTfXvatGk/83ODun the Series Transfer Pattern ...
z5cn31yfXp4c4+fey8PXr/WHNXmi9/L8+vWx+WTePDp/8+bk7Jhfhm8D56u1
xpvD7xuML43zi6vT87PD143KRvhGEs0lrAUNBIlKmK8NI0ZK2vzzo4v/7/92 If supporting "Cursor", then UB = MAX_INDEX+1
dgBN/h+gjN1OB8Ul/mO/83QH/rgDisyz0UXiP5G6r4GSHIUZSbfTKZDiWVzA
mROBASHoLiEfCAD0878iZH48CP7cH8w6O/8hX+CGnS8VzJwvCWbVbyovMxA9 ...in a diff query response when using "Cursor"
X3mm0dB0vi9B2l3v4ffO3wru1pdra5dA3/HeIeRLAt4IBOppHGaGaiBGMbkA
ZB1EswJVE+tgHscgbdWeDuIugqMJRRr0zEkCIi/z6Pn5ZfBt1Fe+u42jb69y C.4. Diff Query with Observe and "Cursor"
kV/QOAy4gK++6p2fOY+9Mo+hZRlkC74h1p2htZM1DwVMxbvhkgK5QvISZoMJ
CBcDlB5YSWOZQUvcJbGdLAuzMANAzIFAKdk6GUznAETRFpplswRaJYTQ1loV Figure 13: Interaction for diff query with Observe and "Cursor"
2u4xEg17zFnacD0+fi1Q3OvQuRCk+ZtnrIUQUPmb7i59c3TeO5HT3ELZsWmL
cF3rm3OS9CJbuDPMRExnxDhG82TA2hyaI0NUHvs/wcZyxA8L4gxnwCE6ybO0 C.5. Full Query with Observe plus Plus Diff Query with "Cursor"
EM6udho0FNtt4FmRREfK6ihVygIKCHxwNG5sUFOpXWGMJvcQ9U6k9Jboaixu
T8Q2Ant5YiQIZStBpYF+wrP8O1nXjRkFOb9NDLWoYaR3AJ21OACS2ZYywsAI etc.
jcOEEfde8C2ehbRcQWIaR0nO7YZoVcJf1C1FJMqikRhXSVDWoLJuCZJKUZfw
wA4sZo7rKxldSGXqx0mY0fW6Ibsd+6tZ7in0SGRGSFLRBlOSXknBqJcdtAwz e) Will it be clear to the reader what the difference between "hashes"
J7OLNoLCuOuARetEHYLT4024bHCWuL7l9MPaoFcfPEAzB0BGJHYt1+MeFF5o and "HASHES" is? Please review these uses and let us know if/how we
VHQlVY9di+wm2hQ1L7QyQ8IwfHcfFbwiEArU2R8gmNUfBtWUni/yQ0w3XIx6 may update (perhaps including a citation)? Should this actually be "a HASHES se
ok0iyMWnL7drpEUOPSDyymCeTVuARYRf6094hU+KbLoOZE1JzmK3VksWmXWo t" or "a set of
xD6idziLURH5Bou8j9w3Zo2DtnhZFnER1KLxWOKvdbXYFYHipSanyvpJn9CK HASHES"?
Cyq0R4MKhaRo+ZmU+rsQZaUyQGhxh0O4ATEq00WaHajrpkg0b3ocFUDAkJep
gzbynEsPjFV6pQUEcMFDewHKRJNEOFGYxag9+LZpiCZoZ7eRBpky/MrkVexU Uses of HASHES:
cCQOOL+pPNDGuJHKsm5IIyBa0o9K0AHFEEkAQCjja23eRG8GyN6ZQigDLDYG
FpOMDcOwmyGZJYb8OouNI3TCs2K3kuj//F7zdeUEcu4wSKFZHN0qO4I6jiKF 1. From the TRL, the AS builds a set HASHES such that:
A54osz/TJlv/ZdXYfutQrOwukNgfANtEFxIABpdx6ziTrFENCJCpDwrb5hf5
iAhKMYq0e7RGQuYLv45+gGcatIJv2SoHvCBC9wQqjqWDblas62JqBJWJN96u * If the requester is a registered device, HASHES specifies the
H6u6Ks9wcK7JUIszbNygwYkds/PksPSSmB7Y6KcwPB4p8ogMRpZJh1L2mtDY token hashes currently in the TRL and associated with the
8pYrJsgtWTIjXZfVpuNd8dWyNnbZK7FX25oioBNigbTRYp4uo5ET86xUfqXZ access tokens pertaining to that registered device.
9FiaKpSvs99Er/kRK60L16gsRTYtVLdZtGH75i1apYXrcFUYNbSVEQ0kN2n5
ytJKXyBFhjEwSgZgds8kgb6whkBxKhLzDhwekIB5luRV2iCkpcZRq038InkR f) Please note that we have made several updates related to the use of
6UdrS2lfkdlWGxbIBHEYwTNT5qeO8i/mEeDIiiOImgM/qF+Q77RoUyLCHMej the word "occur" throughout the document. Please review these and let
0aO3HQZT8qGPgiEOA3vCyA2gReFgYqsNaAeWA04HtHvnWETb0LQGlJiiIjH9 us know any objections.
9rDBPViwOXkfogSTK0REjlE1S4AAlkXK90Ni4zAOx0kKzHKAvFfE5pJWogy5
+2LGZd1JFqR+/Er9SKpWG46qOjCa4Nn5nOHBATVkJQYZqTL6BujHmpO10Bbz g) This document uses both GET request and GET (Observation) request.
FI4mcwoBQ50AhDC8QSiMsQ6o7aWnoiLUbdDYwh2/A/t/5oNC3wji7dF67/zN Please review and let us know if any updates for consistency are
yduzwzcn67RyWNkUuLNmDDRvwJFIvBv9gtZWUBW9SYfRVCw0BNhRPG4NhsNp necessary.
i34BkMK0fPb2t+zzjviAm8GHaB3vxVtAu/WD4G9//duPgMLrgKd5msEX2x85
bJctrB+21CNd/EmrlSkeVXACzBkFv4tphOZ8mC0q+NogeMdZOANRGY5siK4/ h) Please review the use of "Plus" in section and figure titles and
IABwILBtFi9YWEOGBYJRU+/zgSCf8cwCUW2dWHYK2gDw24Mew62m93qlGkZq let us know if "and" or something else is desirable.
/xgzoj1P52JXpsARx9As+qlSWOWCgayT3gHOozLbYoeo10DCstPi8CHF8Kri
UbPqxaiJZ3oJq2FixfpqPolnwJ2KO/aEe2RxMXcAmYXdAX0D+S8GCrjYYO1o i) Please review the use of HASH_INPUT and Hash Input to ensure
6eiVBuoUTEDMDqYgoU5ZMISJZsbboQFHxqFcZBmW/K5nCKkizIr5rKkt0VlE satisfaction with the variance.
xmegz7DhqdBu2i6FOSmG7dFL2Nuh9UYOm1DPabKUi9OAWQoaYv38syxEirBb
oxJ/OyFIlzRER32IC2XYGEQgY/M6tGprcSpL1wvUrnAzQTgizUw7fSQ+hPwS -->
Q7EEooEGD7LGHWuH8nx1clUO53F0b732Nm9vmJIPM6Wt4Djq5RESI6IB4sJT
0F2Gudrj4pMcNr9QURE3QJQIbDC0cU7A8jSfT28FMI+e2ebLmwT5isW0DpwZ <!--[rfced] Please consider if it would be helpful for the reader if
0lg4h/OlLuTTRAxD5IflMe1TyCU4ymMGEUutNqEpK+b5TAgOvbgVbKg1birC mentions of "step #" were links to the steps in the html version.
ErNzyV3fpdIiQP805+rfYzQaobDAwRrKQ5c7ghuqF6j9oqRE/IKRHMd14wqN We believe the majority of the instances were pointing to steps
u5cPss1UwDyOQ3oWqukDiNt5zTplQQoF2KOPl9BjWLIubUV5VBhTnbOs2WiV directly above or below the text in which the pointer existed;
x8BCMda7iZDeKvIFQCwTlJUAnkxHcj0Vaw5LZiupFQHhahSTcMqIxZSCQKyA thus, we have not made any such update (nor do we require it).
Sucks+QUuaRQqHRCJAW7eHvF9oymwSL3LQoxE9wVsbx8OBpxKkK544v0arS8
x2MKuMLtSByHtizI2HwTbGZmM4tapHI2IvJs7pAzFWCgMKuGYciqYDFRYeOc An example of how to add this functionality if you so desire:
R5FU8WWLyF/TR/6MqptXqF/4KwhvlfxpdcePJhjB2I/o1FkCx/MmdVOCcsZp
KbbXirCpv5IVK97A3E9EFm+EAAW4eE05HG48jgp9DSjiLtHnczdJp26Ygfcs <ol type="Step %d.">
FnGisrJZP2QZyCzOKhHJim4giTcX4apFwlWgftWiGf45iBTGiqRiiVysf9Cj <li>...
4TsS4ihsBuO97xnzRTcx8jVJ7fEYRQlllOSbAG/Op6CeROk8t0MJZS1wz6Ko <li anchor="step2">...
hGFFBybpimdtG48izetpmoSQFBN8a6Jem2yTT3Km2E+bgshUoEKVPvM6nFFd <li>...
uzd6G3nsRSRQjAkuIuJLI5DcfXbM4ASJ3jAtmEokpNqkA468FE/ILIwzJh6V </ol>
4Jk4YUNy7jHOiffmnqPA4ZwAb/6P+ReEYX471olV9r8/tbz//uR9+JeSW1wU
mF+WjpwuHtny1tAsAZ7EQbCBB43nDEe86Z3DWdyaZzN/WvGPNZq1vNvV/sB3 Following is a list of all such mentions in the current text for your convenienc
rZXKE/KN/sO8q56RP+ilteC2Mv/tin+slbf9JxsQq/6x9ovrMYK1/RIcsW25 e:
Q39cKp3U+qVb+mWtDMZfbGDhH4IzndpfYMhPtKMKRPHfgf6P86H0WR5bMkTR
8Q5RbK84RFv+OUO0rX9Lhyj9K7reR2uHaK/+78AmKGsfDoLPvGyJU+q+bFSs discard the access token yet; instead, it moves to step 4.
Jg0g3QVG3LTCaTxOvmwge4yyxkfkcMj7LnstYTU58DYtYqnvFBfRtoLRFK0r The RS skips step 3 only if it is certain that all its pertaining
QG9v0KE4RkbFwfy5Nmooyi85KVWvwGfBKSjwJC2OSvn9xkmtzD0xP9pi0svB step 3.
f3krzDF9KNG6v8RUMpWWsDzL4OqabSlgKxyyQbscw5DNcdukIsjUZTWEhaHp The RS skips step 4 only if it is certain that all its pertaining
lF7UDqgJRdoYI6oWOh2eQVP3bds0siBxUI4x3Z8Ol0N04PfpkO0xp6PqWJTt step 4.
dPTtVbO0gxADuCOWzFsgtd0HjXmiR23wsHol0c0MZQ6lj+Zi/9M/YxgGxdqx AS moves to step 2.
WIJPs0nyJpwFG1vvw61NCVCReWF1B+IPmYl85JtfEItCgzh2hw2aIxGMYGNf considered at step 1.
0Ieal0mXiSTdTQZroM0yxMCrvMH1DL7Q5rQVh0GDTgOkyHhGZsGGKovgxF/n step 3.
AUhBIP/sNINdFln2VDg2xTdtCuyPtOxtzKtaM1q086ZPyQzHY3iKDblkURKl because SIZE is equal to 0 at step 2), then no diff entries are
BjQaHOvtFT3w9o1cTHWCNHYpfrxbWq7RIrXFmfctKXSIA7lanB5ZVuRmSeKu * At step 3, the AS considers the value MAX_DIFF_BATCH (see
aAD4tepuJLsaLsjaPcxOLu6O6xpx12jldBBuweDJ/KYv94yDE8jwiRQWnRXz * At step 4, the CBOR map to carry in the payload of the 2.05
LFFGE5VUKesF1SAETI9uFm8ENqr3waen5wz2OmWIKgTg4CCA6KEYBMOivIzS update collection for that requester (see step 5 at
/BiqiZF4otLxWmQjJxIEpYV5a9tq8UNyrtG6JQYsCqZRMi4muRWITV+oYdSl * At step 3, the AS considers the value MAX_DIFF_BATCH (see
9g1HBBRGuZnfmARWfl3u+U0UqjB9d01BZ49M1oZkbL0fbtEa0C7Lf+93tmRz * At step 4, the CBOR map to carry in the payload of the
V5aaYxwId0VrANpIC0bJ7mfFlqVx4ZHQtPNcYaN1h+gOnMhb1YSJMsozVW2y -->
gopXD0M/7cjPZpXiZhEROPTncZSjTM0RoXJUlC+BcWT5IsLsIw1uiKwT/Vr4
8psGZKYy2iDuQCdxU8DnXXhvBXfBmRj8fvVtDxZxM8NYkV6UxeFUJ92iCUsB <!-- [rfced] We updated artwork tags to instead be sourcecode tags in
Yhf9OJm8cbLKG3tolXJ1wVCYZZVHun7aVXgh3W5KlXFynN10MeTsHOznPYED the XML formatting of Sections 3, 4.2.1, 4.2.2, 6.1, 7, and
Js8+pqpRC+FDZ7wYOGTD1fdYbMF6gGvDc4KXtPn2SlOfLJ16b/HUJ0FvQskO 8. Please confirm that this is correct.
1RWojBXvmw0+ogZccrrRlDh8r+mGyoRR/LbCKF0NeO2JS0afAOHcgP0/KV1W
64HO3gYRh/IjctOeBH8VofpJYDb2BP6erIfbW52tcGtnZ7C7/fTZ3hD+3+7T In addition, please consider whether the "type" attribute of any
nafdvWd729ud7W6tLru9v7W7M3z2LNwaPt3f2Yue7nUHO89Go2g/3NuOtvrr sourcecode element should be set and/or has been set correctly.
TT2nJUTAXx8+ml8AEEC+0dOOy5ms95919sNOZwQEL9rZ3u8/HT17uj18FnWj
TudZf9CvXU23u9Pd6Ydbo+39cH9r1H26u9cd7WxtRVFnuDXcG9S+uDUa9nd3 The current list of preferred values for "type" is available at
nw22YACYd3t/ZzToRv2o2x0+3Xra2a598el+fysKn+5090ejUQdgtrMz3Nkd <https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types>.
PY32wtFgGHZqXwzDaHe0t/Nsd397a7C7v9d9urX/dDTY7e88e7oz2q5/8Vm4 If the current list does not contain an applicable type, feel free to
D0sC6O4Oh3s72/11evJH+O/m2qZX5anwBaXySJQGBe0Crl0TgXNwp6IDTaNR suggest additions for consideration. Note that it is also acceptable
YTQg+D8koZJWdBMm8WzOrlogfSqzV7zKqDPYASikK1DEZJBEc1Dh4bJGXDqj to leave the "type" attribute not set.
KMLBuyAco5HcToinbPSEIjspmA+9IBj2jMbUOBnOxWV/2ZMEy9m8iNwYLjRV -->
RmT81s4GkrMGaENj/Yojw6iyitKjrKwpFdgtvNFIVrjHit1P1oAiyYs4Q8u8
nYaFD7biBJ5o3aSwJQU4x1hvftFCLgmBOi6BRbfn83hqnAhKcGJ9hJ4nV9Zs <!--[rfced] Please review artwork to ensure that it fits within the
XtSCJi6F2XjXOUDt8aNeiUTyGbe75PTVvp/Zb1P9BBXQUHkhnRfwBuKRFZvA 72-character line length limit. -->
bsZEtqKyDjhbGvdUjTUtJbnBqFPaYz9CbdyNxseQh72deTY1EgluB0sF0B/I
YylyAc3/WGmkJCiJmIQFnXQqH+U1ROR/akiUvhtK1CDVieKMUEExBn1b/L++ <!-- [rfced] In the html and pdf outputs, the text enclosed in <tt> is
etHaN6siToYlpJCT6RwF0qnRFI7oASwMtRsV6EI8sbTefZ1jz8kmKNiVZSvz output in fixed-width font. In the txt output, there are no
9HZ7xwm4YgzjRBDgPw3nNFhSLjCZk2NwtNwuPhURzMn6G9pysMIlVoHIqXFQ changes to the font and the quotation marks have been removed.
/kJttjS0Ck/mpGStDLDjsiGKii02mDVTiDAeFNAi8vUqtpoHGzoFQsduAKmw
a9XESQJQQBeKvUZeBUnenEz4pnqTr0mds25yieT4KQRZbxzxBwkghW6Sff8G Please review carefully and let us know if the output is acceptable or
M/wtSkdxzjlnJtAydSKT/ES0CjlAJcdLfafEer1nfBOr/EQKX1XKg6SgSH6C if any updates are needed.
N4GthIbbpUIlwbfk3apmoaazEMRiImAceNRUAcHw+x0H8SGXKMoZLaJxWeUa
KFlbaCEFCHM8IvuaMV8lEK2Gjs4xutF+LMObIh5sXyZqI0VTgHEaNVDdXUv7 -->
w7AgKSCpEOKwByffOlKJA5JuXFHI9o1KpnLYTYypr66MyYobcrCs8q6Vw0EF
tIwsAFqq6JIWlGpgQIwExyhtzr0PrXUrt7CJN6lOhLrkOWAtqFuWjojXz6Js <!--[rfced] Please review cases such as the following knowing that we can use <s
Ou0lHnGYiJqzhgILVJgZ4esc6okbppyCu7gK1QoaOnYd/8Fg/DnFI7Yo+LcR ub> or <sup> to express mathematical meaning (see https://authors.ietf.org/rfcxm
mvoPT8JB9KdBP80arLKT2MDUORcOLSqbpmRoFTQKHQ3N5qhZeD9NQ9HITKjp l-vocabulary#sup) and let us know if/how we should update:
Oh/xWzridbFpuiQR8RVXRl/374tIsRhdZoJFhOffX530StmUnKqwgv004dcV
VfZyOW2zBIoi5c3UNwssZvNEqDa8Rs5qZpVVSm4IE05Aso6HJreX7ejVI3b0 Original:
qrIjl5WXtgSPb+qQAEsLd/Ef2fUnwcCfcpAwaN+LEdA2yfwKHMTlhMoO7go1
VyffXfkwbKXjwJfVaSwDb3vJqEfeUbXs19IWPmseOFnCiJK09btGdeRbF0jn The AS defines the single, constant unsigned integer MAX_INDEX <=
scSV12MkxP+yt4rYgbI7xbJzuQWsBGaWwkJUFiY5ledQVbJwRmD9Um9KWeUo ((2^64) - 1), where "^" is the exponentiation operator. -->
Z1n9sW3+2NnuECuTNemA0jCYxdHA1HdpqewIOzMM2R+Hh7EgR8h7df71ydnb
07MX5xyG76CeRhH/zboLjTk2VhyJ0UaPqvCA8d0+ZZvWwpHcRvcm6LZ0Z8xl <!-- [rfced] Please review the "Inclusive Language" portion of the
ogEsBmpRgOqcC3FvgxFns+p8e8ieiSgogXzh9XzY6uyb9U8Azm8Jk6PHwmQx online Style Guide
/amQi0ec/qPhtXhpqx6gKOLGoKwc8GI7QXCSNcix0BvHKOuU70V3rNCaXIgN <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
Z87VAYEEbnTszZCZGfn3kmpnsXeGCO/Fea8SRW5XGNAhzN7ii2XhnF0HnFiB and let us know if any changes are needed. Updates of this
+h5S6NYL1pSA1L+8urqwubjg+WhKVRmUuhUWPgSmIlvhbRhPyREopNaRAwZ3 nature typically result in more precise language, which is
RYMjtzERn+Ivnd9T0AWLFpbPDm8aRkAuhceroVXZLYuab/pQSgQGtWYboP/g helpful for readers.
M2parpvl0vpqu96u2fWn4QQr6Aa/BXiHc9YNguOr1xhNTcUxTeQx50jZ8Cgq
VkNjLeraOioWfShnWywB3vosf/eWS1EU9+ulyAei0V9H9ycSQaPF1A2KPuHz Note that our script did not flag any words in particular, but this
pl10YBlccWR756kKP1ZTeIYHtOp9fSrfO+dwkUXsGKJ54QrnQiNDWc/LCEjb should still be reviewed as a best practice.
opVsC/p0aCWPPiZrTW++uboKjs7Pzk6OrgAlBu+ilU8Izqe9Y0gVCV9Lzqji
bSQglmoRHYPyWTou7yqt0idsn8Xg7nu71km3i0Eynb1NYxQkyIhHnSXc4wgD
V4LLkMOxIzFhWnUHtAnmNsziEF1wpuaoqtgg5XnF60uxO/mcgp+VsSbHUh4v
D3svARoX11eCq8oOoa3rSGbHUUJ1Fiq2aEaWcYx1eF0aXkrHWpTXTuWO78Vq
46uRtyTrINiwCi9L3eVNVQYUZZjBhAszwCR95VWwNu5UW2NLtRN6XivAKVug
T8oCoQQuilVi4o4Mdljng6yZxcRUelBlSBRSwI0gj72UegB+zPZWcuGc0qlI
ZsVR2V1Rr/cMOEzuyufk0GEDn2z7tvnOTw0ebMArS1u2F6Xw7kqX3qMvKqhu
Cg0aTK9zuihgaH7nYvuwnPLil7zZuFzSwarVDEun1kI2LrkNJcdH/TtoJmGS
TNXCNSiGFhyaNXAjO7fjV3sAMCrZ7TVeMKF2DqAuFaBOSiBaiNUMH1CHFyk9
cZ3ua6GFxVhMBizp1Ww8U56vB4hFckfqzEtk2alWO2HFoBQMBRtVuxGMaJaM
eve4uL99wLiqYOv99pAjrtrtNnzY28Gv+n/7SFOa2mermwV9lptYsoeVphhs
6Ky0heG6rtRSPyQbvz63Dunt6iYuR8Vke7A71tJtl6YtxbNwBM1BcESZ0EMs
izyMvuy2tzqba65KdBD4JPO1N+H71uE4Ogj2d/e3ttYuWAA+WPuwRkEkNqZg
MExwEEzWh/vbw+HW/vbufnerGuOyIEPDDX8pR7kseLEcABNu7cJ6VUTLghfr
gl04pmXBi/XhLhjVsuDFRQEvT/cXvPjIkJdlQS8LXtzuVMJemnzsdN5vSaF7
As/twLF34dNFehE8kUckGfVtnFC0Uxce2d8DMDUV4kRvlcHySbC9Dz93MCgp
DWdvh8U01+NsZNjgCQtlmxI1Qi9TKs3OPjBsiAe6w2bwZO2jNx6nTJo84TgO
VSargZ6KNQqkobXBOStxCmKMizkFccUHcQoc1MspfhObIFCYR3AD5vXNhyyw
Ed2/mgBn+P5FfKgsBBhZqyQfV7ypm5KjFCmPDnAkfMc1UUAZmU3D+2A2z0BT
IffP9N4uuHmwMInBGGEfCHDFLFbwkzxg5HAxl2nazuNlpsxf4f5YnbOWudTV
1cUTbJ7S3doKzr/WnOmKmkH6vGtrR9gfqHXEvXEOgiRtYW+WaO0iC8c3IX0x
wEdKHKthI3UDiA4hWf+rQXwev+pdb528/+7v1/Hro1fT/s0b/O65nz6+uTrd
+Wbr1fHr68nVm5+uu6fJVtv/5DeXnfO72+583P32/uJ50v8muzy8vIpO3j17
d3zevauh+D8fD36KXya9V6Npb3jbic9+nnz7Xfj1y503Px+++6Z4438rPRsd
Pj+9eBX+cLP1Mjzc6ezmt9thNH/+bXK8/6p17X8rfno42Rt8G47y7R/u7l58
ffzi+jr/9mXv69bpxdfvX3/lf+vq3dnx1rPv7n86v/zp7dHLw/H5xatWb7h/
fvbNZfLq9lv/W8nbyXd/6Tw/e/Py79c/Xdx/f3eSX06OJ3//6fC4uxffhP63
8vOrfJzN0/7s+6/SbwbfXd+9OE6e3qTfXVyOjk/2W/63ztJvvnt69vSH79/c
zK6P3122jt4/S/tnX929+mY7ebNbE177/VFcvE+/+cvF33/qT59++3z+/Olh
Ohk+T384H/7Q3anZ1/SsM/3LaTTZv+18vfMue77/fvz17eX1/rvxi+wkeVuz
r072w/hs9yq+z5Obv19dnr/Y33s2/aYGkQ7ff79/fFQch19N8/5X05/625fp
D3UPv/n6fBo9vf4m+2ov6b2/ev3d3puf74qtNOu/vD38Oqo7nePvb2enh9EP
T7vD6OX7v29n6avj7765n7x/v3X3dViDdS+Pf7o+Of/69C4r3r0sJrOfT8Kk
9/zs+5c/jG/Ozv/ytOZMp0nnZP5svP1qv2YPo/jr3c5f7ib5+1etPH7+5rJF
nIDkgoaRQBoBJjk2ZulMfjKSB/9kxI6GJXU06K1OYwVxAQnOMnGBvAklcQH5
cq24QMYSIPF/ExovSvkit3CmjCP1BoZLp5j/JzEpVCofVwwJlz3ZsB3KtUj7
z3IMjxZzwasVnv6JnlbquJuAmfN8C6BGk2mJClbLoXhu8way4vWJweXCgeVp
qe+qfEIK9FSbCpbU0WFbTjGmeqe5Me82pTmV49m/E2OcsfuKQEY2z7KTfwHc
3CgCAl9Xr5WaLanSR5aJRfbg87RSeRu/PPpYc1E7eBlRFYXCXZVlATc9mh6s
+X96oWVbw+82ykxyX9m2xMMtbA3XViIgDyRm/BHWgnSxTxdPR/t5mHkO5j4q
dFcXKTsdSOGflLA02OEYrHPlZNTwJpnJtweqb0l2tcXlg5orm9J8JbAujVU3
r9hPwgfbT6zAEzym5EHaRtWOgjy3lBPpgkwlGtgEk0Kx3HIdVV1F7JiJ1J+X
ah3UtUWa3sL0O7/9XX2YmfaT3NUymE3q66+3n/1OiMSuPjiHc5g8B53aUIVH
U5WWterlcCKuvg8P3CAsaO8fT7UWIfbvjRK5RMKJXvutSECdJPNqmSTz0wMk
mVf/MySZ3wFOr47Pjgyh8ToEXSejcBoLiZYykZV9WIG3/uTvj7H8cy7iju88
YNFpMvz3OZDHSeWPF590yDZz90cw83/U8cvZ5+/iWc7S8jb3WotHEsgz4BgO
Xh5GR2DBhNpukBgVYccJYDa6nKIdSOcPyLBLUXAEGsc15T4SQ/nwqvkIr9y7
n53fx36IJjxsP6i3GF6nuReF0shRUfk93qWEFdkkm4YkNGkG6EXCLTalcjbX
2aWx3BTiVSR4U6SyjtVpEjCB6aYoLZo7h6Wr2pV07rtUfmRzRymV25hoeMvc
iLy6/AeldeMckxSzL+3u7J8qq/szqr5h7EqcuedJ8rbpoz8YRFnJltBYJ19a
miXUZURjsyDT01PRsL8ZeicRZRL56QgSqniONGojBmLq5fBOqh3CrLg118zW
DtxGb/RUqbvYTT+SwpRuYzL9vNNmThfjZ8GC4j50REyFVArZcGLAq2PqijvY
JYzyW9BEGmOnAQr2wklaTMqlkI8uHhZNJfVVYUrjLMT+MKeWMEl4cahkqoZ0
zQIIfPhAD7eth9v4cFs/rAq4lOvTUC/cmARSp++st2wTnyVTI3ff+SRsdXf3
Kr1LYYyXh/gLIBuWGYItY0lEakMSq15iAlsslOwUhPLAt0h9wYUSH1xQa7Ga
Wu0WZ7efEJvpwi7g+iYCU1btBOASrlhPv37gpk37QysLCxuVeEqhcYaWSae0
QpWadtLkUgM130Yr60sXipIYmJAFvELVkMMRuft5OiJeqKvGSOc+ZHKwDDlJ
rP5KgYFxQbVueMRKVTr5XVsQ7HJVVlE6BklgDbxCfwKrmj6R2WvpVGPqIFPf
XF0rmKsLf9SYWG7Kq2iFCQ6+S6lkUW73I0jgwqtWBQurnFej8Cp+7lKfI7sq
eDVSzbT6dIQ7U/uvPKJ1+DphWs1kbchfT90uor58J97uTJ7qdA/dT2XcxXuS
g31z+L2WoPQlrTaqMr0csXQBtrdLs1KpYwruJZhaLaik6HGpGQ0pwxI4T1QX
a12BtIlVnuOZt6iAgnwqzdGjwA745mYbaaYC3uWCzzAj4j4ArpihtwubWACy
DtM7pnGytxN1R2zCplsoLaq1sdd2M9m5DBgmsc8TXc7ZboSyrL2hHa9qlafE
Gj94VawGwbqAmMimHJuiCjfpblE3JMga6drqx1cNSVYz9tN5om+Gaz2Th/GW
vzAlxxb18fDUeaT+pHTAWvFUUj7X8Tdh9uh3LCVilfOB8LhUTtAVsTyVcxPn
IgsVDk+5CWcmKp2+kR7tqsRI2KfYsNDqaqTrnUpsN8I2QkSjruuWeMlMkeWQ
lnlTd1lWB6u5PfIKzGEgGxzoyLcUtlzpmqkxpH9vOjNz40W4lolPDLAbJ0dD
t554vlgAuCrPqovPkmKIi8LGIVyFVvp4Ulwx8QH0sZOKh8Xm48gut19pQyfn
/A9sMidlHsxRyN6YKjnd4ZjLSk0iMb+H3NeUu8cpLFKmTo3PIoNX0GO1JnUl
oPhb0Kmy7+qre2YCKzak0/4/aUqXP6YlXckkhcSPGYU9AlUqXLVNoaLqsnBr
O/itvddyRVSLny06UF8PnMOeVvUZA+E9ksrhNS34WIX8fRqlxTJaMj9q8Lrn
QkwavBefhvrkfwU+lRr7nZLpRt9aPUVsNXtBUJkGGdRdh+GGYkXjiFrDNYDb
SgqdMtChiIu3vA/K7ijGgkVSM02J/Mh8b9N4iHWzcZ/UuWeK6UGaylPOXQ60
LgN510ZqLo8kXkHMHR5FiLiUeTWMpvEt54s5rzLorBQlKnhsNVvkbgo/hdQ3
wzRIceZF4JKE0A56ZMltOgybGy1xL9zSiyXLj90ihW2PSNJRukGXPMLI7uKB
lpSmuZ9cGSG0W4pWWzk4t0D3AM6t8FrV0KSEBaRGe85VDk6Mo/7mu3xk6poo
UXLhRamxb9fcFG5FiHeEC4EVlZti0V0lhnDpNhsJ+HtHVFpwoZp0o1RdYgKJ
6J+VdVO8klmlssUV1EGN2TwzelMXEC/CeAzclaYud1CZggY8VYeDpWUsOcOu
PUWdrRJlYSFMxQvqylh8oTQ0nQtv6oNXzp6VwRMQjzMdfJ4znl1kKSiUN8Gx
tBtVwnGED+tIN4wv66UgV9PXPkHTr4XSheL4cX61pYuG20hXSWKc8apaqgmq
0EXntEgcf0ZWth6S+vLSiOkTnSlJltLFzE3KB/UlzqNWaWJL4CyleOdVWCi5
OizniN+rcgM0RwXkpj5UXW1z2uamZb/Asctir9308FTMCnZB3KM5XOKb0uxC
YNZFwOZjX7fFTIJ1HCYhXAocoAwi7o5Z6jdO2ataWqmVzpUryGo7Z0wNVp3k
Fu2ck5jXGY/i4boGuLicpKQegOZddG8XQaOGhfiuXahwnkhbUFKxVI9zVrO3
eCgrTc4eQnag3rPOmEw4hBWG1Jv2hgQUrccXIQpP+v6s/wV/WEcT6vxGh200
0AHut6XRbc4byvB3714OOjDln1cvtlC+5CP2HlsF1NI3lkSI3wLOnVXgXBlA
NRfAH6nZlBrhfyfAOv43ZqmP9uS2oGJZGXgxsyIWU9bpWPCkbrG6ay2XZ6SO
xla6sXOP9BXgLHOqclpqrYRjomDrvBl8GXxQsc9bBwHRfvn3RaAuAD/wn0Hn
IJgj1X0S4P7hAT42/NkNYRbCAIep6IJiiT1sCowxhB7qQJpdtoB84ANCuSxi
5WluGSsvkiFKiyYGssQ0Zj3YUNjW6m6qJl/GwiflQcsOY2NWD4PJ/CbEqxAO
MTG9aXchBsqj2/qp6uAL7nBkv0tzxrnpnYIXIU9HBRVnjJIx4BkVhzdiCiUZ
mf64SURB4AHWWyCNnRw0bHVGG0WMin5/Ph4rB5/qhU3m4/ccpa1rKpAQgaYF
ZPrlxapSGL2X59evj/FCT1PVLcLen4a6xt55guUrplQSL7oNufMt1spMkKzT
xoGpzmfiPSRgO2vBQaShLRuuqGhqZELmXV5qVYipkQTQo+r2a5bBSoILXV5f
3utz4OTSoFFyX3faW1uLc18XCQluOtETzgqgBEegqXBDG6cJICycpsmmJgSm
1IQn0u2dn291rccZy/GQTRfv1u62vOYSjSdBVCJAB0JGnmiiAR+BoGzB/9Su
SDIsMemSZqRVwRZ2MDHmY01ahB/8nuQIVwr1CqGNj7pKtPfsE/HATo157wGy
TWwTJVIMzi+uTs/PDl9TWLQox6PU34PvsPqtLZAT9fBOS8YzKYoxx6xVasTO
tm3tO+RzxCqvyLi4+oYlJ1NdZFUWgmtyDHQzQRQogJy852KDIBPrRZHN6RvR
EnzW71pThpVtWmdlkMa/sjOlzNcYs0Rp11VrH2LKcqKUbNO9Ux2WNCS0k9+L
OuEYXsQFwjTPUvyNcuy4Yh0LQMlIVdcvdbFN8mqyKEkHFkA1XliXM8aqUDhC
NKyBKrVt8bfEJbyzbcJNqzgj2RIEzGFuVppXjX7mx/Xctk1UDReWVeOBVkeq
s6aPhFHkEXbFULVNNcZ4BWm6buT94lAdClEA9hmTaq4kzDeH3/3t7VnwH1+i
hPrCwLaMLc4J6S1Pp6K/wXZvwvfUf0hGzPkOorLnuwu20WfhxKT5vIuiGV64
wTtd2YlneQxqBksvuj21EkIMwhjfpZbmeTVNmJ7TwcpRCktdEza0lOm/CmUd
SwJ3YYBOAnVVUEYJBpMsTVIQdDB6JRgB3olopLzKBQWuqQbo4mIkX5b0ZeZA
GWstSr1BcjWNQg1rrI9o42l1qRygFYMgmCGHSmzZS7URtqeehvUzW4e8dGJl
wNBcT/oKak8YF5kKVO0S7bVitVHZbFSABnlY1Y2TnokaP2pCyVm+JV41quC1
CTE/7JVyHFZqdF1FY3Zm06sieobUXz4yHYzNzbBNo7O8bJK0CqnrWUoxikgK
nLyqrglEt6Jj0JwOK8qDBvCvt7OwGEwaZZqoIkXwiLErEdG4BlFPxB78ukGH
3eBIlbDEmJyNmaByWMUI8E48b2odnngD2xcnvn1iIMOyV87tmdwkMvzECSUg
6KvTZDWKgNMxsdVO6FAS3dnI7jUP6aUT1dexrbv64D2XzhOzaVn8Ld+izOOl
1Tb1G4IWJE7jdDqMyne0hlCZfBu7mbT9Zj3dWLSFpjJ+E7XYsOjCpo63dMRB
x0ZsSicuEwzFJr6iu0GKaXgYiCYQ4TQvtywVcXZFvl2xDNHJnZ4dn3wX/PnL
YGOj+997O5tBK+jojgyN/24oIgq6KIAH1FMJVRcFvGSSsoaE9y5Pvrk+vTw5
FtcVYDQzgA3BGZ5K+hxcnhydv3lzAu9Wn4elbXd5aW17DqObExfLWYYYJ3GB
FpMx3RUJBeApKzKlKtGbR6jXFai1VwkuiHA+/Pycfc02Tn5Xz3hjOcKKBJhU
T2YdC/W8X1e2G9WWUdtwuLei/Cgyk/7RwKct1skyR0Y/4TLma/wBshjX4svJ
F4Dab7+rFEBVL1RlXQdUVoi5lUNlPfE9vIYNBFFT8ywifvt9AGiLK/gTIEbw
/wpeMWr8iXDFCC4kwMN+6NCZPjuTMTCtJasZJ7olgBmdbydqjzKWMxJLLJRs
SELVXRbOWmFG8UO6eCsPTgM3paEFNUuc57UbFqg7QWOU6YJ7kiv1Jban1aeR
28dRi5mO0AcXILpNp7eR5SQhmlniN3ZoG7Ha6bD6M5N+aWrawvJ0/AEO7RCW
ah1XCzvrxm+fl7/t4LdHzrebeoxVnsZvjuGbLfNazQP44QQ+dMyT7vf44QV8
6G6a7UgV3OoNRvbyVkFerr5Y0iUO173VW6LE2pfZusnqvtXSFo6FlZYNSeqe
Bd3jPsXb0YHdR8Vms3RpSwumVHle7wJpQRkqOWrXGWMS1pAFI0P4GHVViK8X
ECjApf6C/8UFQh2pa5p56Qg8moK9HtyX53I6ewey9BfiVkKUbJrEWVg5x36Q
h28ZfZD46UKbeZYcHf4Y9vN0Oqd9zhPpQOBeT0P+tQHAAQqgJ9AilD4pzNcS
8R0bkbE91wVRVClRmJm+fmI0tex2/ggJO9LAiutxTddVG4CPdWvZyrqUeA5K
Ump6TRxvj09fvHj7/PDq6CWKS/jNmetcca1h6ipLa7hyaA2LODp0khiFBBp7
4neYk+toAEUevpciMqqCjH6gathKM9eu5b18ngtuRZQhGchrBONq4EzJ8uEP
xHSjL62EEzu81pYurVN4pKkEpPtvCLYXJrLEK8xXPJtra4cU4LkgrrfisTOS
jZhU9XBaueFwy3gqetU4wSDyefIuQYdN5S3kOOuIIesHlIooCMSWZQl84qhZ
Hb9u4ZNlGFBA8sXKgeR0qqPodcg1VSU6EF6Ow6jbgSySp9bexDDYAIql88A3
jbMqn6RzdCwLkEJK+Lkvh48pLEJ4KiQSTqBG+gJwWhYTVm+stm85WkB5pcuv
6UM243DpQ6vmjHKTVH0BdNq8Wz7V8omziV5iCRQILCxsKjfnIMLENiqcf1ch
2FaU2AIUsMNvN70VJhS6chAuDIxuwGDDcg9awImlX/eCzcli7Ftl+6FVqhK7
MBOpi7UFMM08Zw4QzYyVRY3NoBuY1gwqTMOsgoN+Fb4TVCj2YFNnJPKGamOk
Vg+O0nPVheNXGF85tAz7HFj9NVZ35ZWkBoKFiQ7icA+TaUjkDY621u+5adIF
yvEvqsG4FQRDZEu7ZH8V4SrSMXfJ1OzCx4UeKUPU0j2AhRfptHCst1/Gcav6
vaXy1lwImpTkEks6MNq2PU79jNYV8hgXrEuF7aF0UrrJLyFhBLMu4nRupaP4
oxctZuvA1xATC77NFU+ihXVHJaq0aWUgL31PvbS5lBbXIU6ZKtcBeQldrg2q
16TaSYONpnnENjcayoozYxM33JlNXJoxBz6GrTeleoHXZ6Wvcw1qxvmC7X5B
HQsqa3wE37F6OJWOUK+asvVXDOY1VMrPZBadsXVdH8X4UK4x/RM4gDyX5t2T
VIVrEo9ZNNzvhO1I/9GrEijNxeLIzgUo5GfQLkeqcGeeNwj+cVyvY3E98aYZ
AfzBfE8DrZaSUN/RB8s63ATaftcv8hrzQ01EiC/fYPMfD/WFsgYLYv5QoUro
tnsslQBI0WN4S4ujYpvcouLhfjJlkPtChd+6Gq3yWPtNOCUC+HlwCERUoGj0
SSQgB49dnDbafYG2wpIBCulE1QCljE9fGD6xCkL7kZJAIkBw915npP59I28X
kPd8TqSC84TFrPU4UfkzTgb9psw33WoEFtek/rA6ChY4ABWeqVdbKdDLJuJh
/k4572uY9rKIBeOLxCAgS1LUL6pYLYIZ1og56ZkMejYrmM7HDraGVftRU4/g
cHLHM1+bCLusLlFNqFVpCcYnjylN3HxtLupuaNrKIVOVjnwmVqBsnbPUHvYs
4WKobE2MbbatItEURGJ3BK+DWVKOY6sALCSH0wpAc8IzAEfpFLvtrV2MBaal
uLjlLOZROnQ1g73cM9Lu4VFNklHXsyblx/BkxPW3gJDrZR3MNs5SIJJllrBq
SOgB3tJVX5f8Y6soS/mJFWqzUDWJUfVstAJmbpBWP61LFesyKkXdFt1bU6mj
oujn1eS3qgBTlYoWwD9+iAqg4ns8QRYr8BA3NdmufbWU6VimA4y3jwpPoaNV
tWQrdSEv3W3CEzvMmVIamHiIsY/wvDWfreqnqdXhvTYSw14XaNcPU9FI4S0h
gHBFbQNBfVqbEw04fuXMceG3v9dYCgETDZv+8GEwHDIfthNcSdrA1CfSqeK6
5KcFRMTFGofaWaVKyMblSimeq+7Ln+KmD1Qv50tuJbfmrgC+/uvngXnsx0oS
g965ylko79hD+Wp7OHz4oO03AkzMViEeppJe/ACwxA9PIrTPQcOFsinf0tTd
WW6sJy2sDocm3L2pBmN4UNvRV9RzM5XnzZAtFxLyNOqq61On6m2rPnW7S/vU
aX5bavUTWVh1EPyVr/5kfaszCnc7g0G73d7Z7zwDofkJkPt46C4veGKef4rP
bcHz3e42yNELnv/RkzXjYIgnUcbKYX8oTtS3IjO5IAvkcMvC9mnlcK+Bb3U5
XNdCbH4qBspzU5lrKRm6ow1HbNWiPL5VCwbUuvFNdLMd0Fhx8Z1dv7HFOl1/
mijYWZWI1tk1K8ZMkqB+nodTtktgV+Sy8gpcoKU2V5cQ8WBxY1MMjrgxDAIr
BdBQyIETTW0ePHNkdKt3zTXQcvi0AY82g97pDyc6uBP/0JEMlQwW+lWCSWp8
o0ZVoCIZFrNaHDdpgqwBijAnrdIt4gNHeV06Bell348GIWpZan3WEypiuqvg
CBKn61amGrw0pfhUpPQMf1V9uJTEdP2YXJEmu7g59cUAqWrhqEbOPwKDvP1B
OALUykKiRCYdEeWUXhmxTi4bkxvPVbxrB5DfiTVTHFVlFNKgMGVNwO4p0uSq
VfjbW/ptfUnhA4xxV3qG1oiv9K6VJkYzrOtMgnVfhlVtrc1gXcL7Pfodqfuf
quimZRART4pgTRmrvlCVqu5Cf/FEq95pXdEc/MnKoLJhJyf6iYBHsWb/HNDl
iyFXyZR7JNRcRTk3+EKTCQB8+jNmZ3jV54LCmuoV6J0qEa23yYxEev0XMcrQ
5a8xyigX5CKbjHpfqVMpchNNI6oWmvLzZlzLEuMcr0WeDPugwumM/XZioqlJ
DfwjHk8KhrSE/VIBA4YPabeVxcRLbDRi4y6/11y8aG2/BjbCNwBIOnIij7fC
U+0txqzhW2ABUSllkPC3VLiVCbEz/SLoM9P1cicrV3ZhdqZFwrzTlqao8K+H
z1lhcbXWLe09wSqkvxezl2XFuiLCI0G7KAStaMnyCvOOJetXGLJqQwgearGy
bEh1ubtBf17osnQ1SlDuFCZ7iL3qcVM+0ExVi2M++xUu5Ffar+oI6EPtVx7C
X1P/x2PCwm+VhFI1YMGvhhLgz8KhD8xLTRYHrG/MayXTmBmqxjRGp7vANFaC
2CqmMTmnR5jGqrUA/TWJWS9EjXG7qgvpM32ACe1RFrNa5MVV/Kvb0gyGa1va
X1Xpqr+6ZrWt0V64xKxWMa3t9wfRQtMa/vux6c44GI46gxDe3t3bHq44Yz/a
6YR78E64tft0+YxrzsSlHe/sDIedLoz19Gl/sOL83e3OaDTC+bsP23HtUipQ
CZ/t7+EMo9Ggs+KqRlEn7PbhHbjtWytDZanJ0yYmy0yeq931BfSGe+ngtW/N
UErPkkoPHYdJ+8MQKeg1GIUDjJ6fUyEtq34VPtVjznelSuBc8GSuyfC0ddzu
4x1LklbRLbJxKy9mZCP8zBRFeuMU0L2uOrqsrG2V6eEULvXW7XmwHwm7pKRU
i7Rk4PVYoe1sb/PtUoOp11v4gPBYFMjsOgSSDg0nMyhUvaiyKscZRrmKP1Br
7UfVzALfpprqxUocPltjST+uCSTSIDcCqZB83zyhyYNSoUV5ERZzXaLhgXFS
WL+DCkypzlMaAXQBOdOrqFzdlJJjH1U78TMLswF9rEigKuZ6EcKXsLeaI8RU
q/agcmU3NUXbPfZHn1usxMN1ndYBiJQ+wVExeaObS4Skfrs+jI8j973lMeUG
1EUh2DGttZNYeS546llkWcaTdHU7sbECrWQcVmEeUipV7AS0EpIE71TssnlF
BR7lVs3heVLEU0tPr9F1nakpFtA2CAAYS5lCyyBadx68GXqU8uBpLCcYUVWK
XjVReEk05EO0Y1JZyp1zH22l6HF2gA4ZUQzTpmD+CFFlz3s4RStRF8u/6aEu
Pg6yJB3401AXx8IvJVlO2ABmtrraglt0RwyLfyh6iOFVWQ/1Jkwbihqj6683
sVaC9j0ls2trWi81pNZEt9XYGlcP1qoOt6z0sB59qUVspbFH4TSPePCdTdsP
zv4GNtJK2RdNI381WmBB+2w4RXcE1aiLNHNaJTEMORSrtgvFG1/6hLG11GR6
OTYfvEksvqJdOuiVDTUWQVD1Xle8ZyZj69F3zQ5M18KWh7hoO4Md9b8wiacS
MKEqgS7vG9I0K7VKUUrTzoG0djsU1/O2ReTsumy6noddReCBnIcMqeLqeS1e
/etmadBN15GuMqiulaPfTp8XqbzG9+3jsQvqCi4puuVlmq8fWRZU7ek/HrGl
iEuQ2ULE9afZYp1owGLVazXlo4IIHCTbsXw7yAOwsyzQ6fsae1idU/Cf6Y57
/Y9wx5UccasFHS/c0OOlVVtQrVVHDZ/LqzEbdhCTDR0DiKYpjWqYQv/efc02
rbtuOg9QTBDS0k3VV5f6NOKydPRDoUtxqzh3mYPIXcrX4/L9hbujdom/Ustg
41OVzjp4Vyfh2Fi3iuLpyDjI4b0Evr71Q5HN5fVdN+FWJbNXHEc1pvZBFGPk
SR2NMcXTeMpm6VAxdQYTSuqi1nVAHt0MZdirZ/WaLtOJLsksLbupavAJizU9
OI7Ryl6nge+oToipCidSgu7mpbZmVcLTpVzduk25w9dweM7R5zJwSvPPpLtB
Np8VlqdE5fSreV2J8BNKg/8oUdAJCqvP1TdxRBfeRHxd6I6tnZJvxeS0knmp
u/pSDiax5iO0uhxKOxi3ICTNbYoJ3pqKRhd6Y+Wqh3VvbFzYpQ6tqmIk3pDF
GqE2ohTEx8kxwtLEwqP1I1naBkmhbP681/1QUqqfRQXYYrj9eOmp2JxCN2qF
UQpRWz3+kWSeXbRYPSwSkuVEudhOCYbft+4erCZ5PUx/D1aRfX6VDh8s53IP
G9/mUTz+t1ZD+n6cSLEvk+jNE29i+T1eXVNG2dRHTzq3W6qqRhYz9jirwiHG
aVQaPteUWpyijDOcq4zIWGrwh1PCrjxytFepHGpd/CU3vmkWb4fU5BOO5kr7
KEipQlosTOKaLSrm2A5KbRJ9S7mQQ+CWEcj4eRg/2yxzeinVK8wei4nW+ySw
tc6haocMj1legAU5cbRRGLOpjaeWOFkpjO40Q5TytHYPmXqp4UEFbzal0J+m
maruoScLISwZGFzgGD7z/MF8hqp9PJ4n6CoGpVLHucVtPh0r+5WLXUD3fzsL
ENG+f5YRqHf9/O0SQ5DO+cBHnYwQ+EKyQnBs9Wc182M1E0lehFwckvg88UBH
crexg2Ov45ubaBhz5W0WIb6j9I/XS9I/aCPOIw/I+iD7EQ/xb2YXs7f2icxj
PNhvt9uSfYynezQA/glmsn87S5llOnn9W4SsP8gIt5rX2Ik6OFgzYVktDzGx
Xe0VlqbxHkFYh+h2Ib+abWh74CcwLv0mvuK2F0qKr5GcSwVTV9/pIiNhKe3n
Vxo/bbPnv7kZ859kyazhjuU7/JsZNGu58yOMmoEuVfGHXdOxcfy+DZPBpV3U
W0UszYtJmsV/5y972DM10/W7nWrfa2vHJpnPqQ8uwSsmCKpZKZfEIWPVQk2C
GeUkVKc9O5UysQIprZmt2y2NI0Dmn4V4uJ5i4qaTrnqcEh5G84QvqmpIhgE1
WOvfDnI3UWGOL4hLUUmP9cSlro2zEHs9nlp7eYnzHU7HAPFictNQJ3IPGgs9
3LYebuPDbf0wFtO9MjaGAeUu5qb3NRoZ50Wu8oLyQTozzaetJtsg0NVl2HsL
Gzghu/6MoYcV//EXSF+0MCRXf1P06gFLtCwSjDmfIqWrJjyY93COFh9EH+rT
UntTPC0cK48yY+MV29eB4wtDEzSL7c2s99jSrHJCsEsj3VnVqDHkYJdSpwCe
rNpv9mriNO67A6H6AQ37lJR1E2GbvjinHmNqy85uaZgIdzlgIoalXrnmq6Ep
dmdqOLd5Fjn2bUz+hUsOl3IwjSnJV2jAE77H5QrLPWHPu+19BAw1D9/C5uEE
DRjmsmeGgPeylEKFFozzrDxOplv5sRymGnWrJiCAKTfzRFlPiSmhlBwmxG2b
FlJUWj0IApEegT19EVSYeIlQsYa1dEiFVCBN3MyLObUmcuvqlTfkbodjkTXT
zGcx0CWTSoeVvelQhnwqziLQgVHcRab4L5UNLPMIhJd/aZQMn90Ti2MrCJCH
DLM/AL4FdVZ0DJD62yAc4/UqdPtxbM5LqtPzaETGZmVhQefCg7kaNeUBbIRR
+tMYaLtUqF56EFoAIcQmknUPVJqzvSaUUIWIMMWe8feVIhQMJBtEYmLXHeKs
vHu9OFtfkAVaS4LLLh0cAUUZ9UqnY7AOxbGM+i6yFQkm17NwCOvV6x6y/GP8
X5krx/hWtXX/Djgtcmdn7+NH+viss/MU7YU0e3DeOzq/PAEZBYaLKXaVe9Cr
ZMptIM5wbbN5kqi9u/j9DmAcveeWoYQiKUjpwcnxy/MjHuTZbnefgu5LRnl3
GE1vtPPNBRRVGxqocN6yFNK0gShlLgeTCKizHeTo1p4UGU1KK6B6KHiWpZgu
KNp3qus3TCJV01Kd990EnpTI8so5EyO6pxPFowyDaYq55zIajgTzSO/nDJWE
mLCQTRau36l0oAMgB/gnaCO0kmye81U1O3I5kbfeCqwPpFIziQGOV8rjYp01
MyCyYr6vVMvwbNFxgROpq90US4wSEmS5TxB7nAtByq1QtpaLTQ8hFdiSSXzE
qit92E/nhcUo6ogXJ2lySV2WDbXkqPi1kAFXO/aOqhqwyXgleROmOzqBywGg
w5Q4mujQBSHSElfzqDDTKvf5DJemF0o/R7fA2mEoPsYrLjartBe7SNhHkc0s
bmrR9eodTjOPsmJpocv6FhlVQ1zf/OiA8oxRmWf0QgdjtUrwknr+pVpmCzsU
WOKwyt8tSuux3aZH6eFFcA76KKiBwfmMfRC6nriCyKYrixELpS7x9KI+Hd/N
nMEr5pS32x055ad7Ox2V7lTO8ielSzsvp/dGprIiECT+nB2Ppp8QW0nUFaTt
6R+xuk7JIlEhP8u0jcWFBn7bCqmWKXFB3ZgFbQl8+EV18Be47uwmRPYlQEno
Hotxi9oTvQe6pjChnNZIX9WU43PyKeE4AOHC4actufdrYFZR+yycDS0eoGPq
xcJhY6W/8Qs3INAGEaQUThKk/7WypUzPe4NiAqpR1NKUrzJmlGbhHWtXKd77
nK0omGthTDu3qSKx2BkV5Hx9pSkCx1hjnSLfDqUj1f37AE0bJIEjk8wlEozD
FRYVFRUBTH0fq7p3wwqx4+/VZTD1tBUNs3mA1uaYTkUUj4WtDBbFNRBis8g4
bNcMy1VdfARup911CZzV8y+yWgQ1DfmE91EYg+MZxeO5uBH7ETr7Wa5MM2Uy
ZwHM2XdBG/IusyTgWxaEOxb+2M+lpEdurwIyjhKO4EJkcR/tYo1Be3YTvm9U
c8vjqBi1YIVRyxqhpd/Myfkvnq7EDWFCn1kjAZnhSy7y743oSGRrjJCXqjXQ
Fe8KtU9pMYe1vbigC7zDy5WyROg6CWd5ZDRSDD/EC4b0qnK2dK4qY1Od0KL0
pBLOSCYSNdO0CqlyLT2lizja4KqmUyONDPVZIUXesEC0aZSVGikFSUER31DT
5HCajjm8kJCLO6eoM6ZErzaHKw1TuitpmfgU6R1AJa9ORG0HdR+yf4CoI5aK
KRVBsKJWXJeCgdzUqD8PZOXVpPMHFRBAwfbQWw1qNYGB8MVwRSfWCS+0sTBi
77KKbyod6Y6NVLfU9UHo1u3LhWM0OGYRR5xQ8FvG2iqVU9SxsFXpyrsqrYJJ
5Vd7UVRVSGXhsy5ke+FqO/CKT4ZcvdRHW/G7lEM07EGE0/qGwYssfBigl5Sx
arUusNSbHJk0BrAiBaZ6cejnuWV6L42+7UU1Wa10mehqmcJSyjd0NykF6rSZ
2nD9ai3IhXn2RTUxXm9wGoXY3kuUVGyRVw53LFfH87jW7EpMAP+eBoFn+1qZ
JRtiXmYZTvqneNSm9xKf7mWbTSAi2TgiAoHlp8W8AoQbP4+EOFsGiZs4z3V8
jerygz+g8GThhyfaZ6p6MTIBm2eqlr/Lne3qZ5Za5ELVtxkN0dwVJom2kUav
6tWwia2lAu4YFC00UqgqNrk2CWtFcBrfxJIVfINtsokiA29R1kgjrzjmrXkS
3pF1YlQrWzLumFjgTBR/VL9UGSuSVCNqxt50zkRCZbGgHNH4PJ0Kqa/iT9UA
5RmJIAUUEB+Y3mvH9Eo1QVwJLtSqihX5DoIZfLzn6gIvVbGUWnMHYjJ9JO9i
ZOwfqs5Ki2DYYj/mx6pxc6mG4ZM+yOYPIJ+j/IKlK3XVaodwlOlhaBedrS1r
Vy72V56c+/Fc9oz3AQ+XiSZbo3gp1lxOP3tZN1M+a4n20jl5i6ZBM580IYfb
mQ7d0gqWe9UW5BTKorUsn0fDMk216OZlz2wCH5lJVFuRKheXA1PimlppdjuY
mWIF1t69sTbukDleWUWPy3XIMR9Fj1t5Lzj69kr8OQsWFUiQtfu64vPAzdKE
S0sEjXmi3TcNbvBlB5g5wRrc/kslN5l6yWSBMOFyGK64sfU+3NoUXUHVKyhS
bvlWpLPWFLB46ptdB/6d905ABfgJnYBk+FWhYACAL1hs9L8ceeo0NzDiLixQ
Y2lw3JVpBLfiMAjvBtzjeEbuzoYVFdgSXVzCbggIwG1CkZEQpaKbfjrUZnv7
VLQJgRzZ94zUZXVAi6mI3UhkeAimNXkrzDleISbj+gD5hTTXy+nwqEQWKhqg
fCVIXGWRRTjWwdUknM05HmusQgkR2dSTGmBxkpin7FBNPDE9Lp8RPsVh2LnG
GH1tUcpFWVirxtMoGRcTczQOoLhml14ARa/h8CXfS80xyEGdJoseWnJWzdL2
uVOg2WKg+1/ScQIzzwuHTsEpoB+OAGVNmiobazt4QQbBvEB5pzydTALjd/aC
DRzk7Qn7aTF6vC+OCTwyvHMD5dml6d724AI40PDQFyP3hMGr3vmZun6kmODh
Kc/tYBrGqBvgnLHeMbwEc5Nr7+lu55moZg+nU5r+v/q2x+vAanvhVDkviG+q
aXZVmd645EvCl6/NzQ64IOYKc54snXOvfs6ToDehqOTq1PjGkzRz32hM6LcG
8Do+3MQGmC6grsiYj/4cJpqlKR7m8KNi0qnypLLKUXQk1IXMvO5hWd1/dcro
FTPSCSmccpeIi5KNp1PtlSuyADNc9bA03ijKQ465bcC7JL2bRsOxcpB16EeR
PBW9Y8uWBMkMlY+8mGTpfFzeCQVxcUhlKzhcZiKupNo58+uUUfgGBNOYNHGl
1dkstHQUOr/U1/fA3ZRqLD9s0hU0dIHSrZasvqaspiemrC5ELFA3pdRM9P1s
nSlASaTs6AXn3gOzRiSXNxAn3eplaJu+SYshds8DzEJ2P/XDPNJVEukhcfwB
2nCub4f6IrC9z0E1eUnvhLrERu9j2Ym9Nokm1Q0iTDASaQtsV5N1dJaGJZHZ
xbFB6xt22bOiPKSUny2cLpKwI2VNd2+2q8ZJhAuoSiO0EOiJxQarLjXZGptw
/8nAGqOdBGQRlEp0I09JBAUilcJfpHkqM7evUbzahbUDviNoMvBshQ4MIHAZ
abtHzaadUu5cDYtWw9Q0vplRLVBK3wo2hnE+QWm62JQgtaoHwgYYdakv9VY3
KPIFN4hHYwM6soxLGzarRFNGPMZMoQ72fWd9Es98Sv2Y5GJITw8cfiLSdI4q
LXrQhecr0UllEgCyqTu4gZMD0883xZlID/xUeuAVPVBpBDWJxxM2x7nzGfVE
UzsHs0qeXgtMGhYAlsrd6Gy1t0uBBm76A15kCukmeYKVMxV8Y4HPtyhEjSmu
OiQcJuRRwTku81PoVLKnKPsm21XUrHH+rlk2o1WYJxn76hCHVoxQYYNMWLse
JUcx3muAcNSADoisyMUrUSAfKbNjSZeQJjRiNK10cG19wGbRddspJt1mFVZd
kZKd0hcWtKgyuxgMUl1KQxPz+QxXXqhrqKGkDLr++5Mn3U91h1ZEaqUtwNIE
FXENYe6xWXfJYsybJttTZm2ZYNplZ39urNU66KPrsWzoKWhONQtQIYrBRH0p
TuY6BtYzpnIJa8s9+a30yRrUxEi63HHIuehcNUhVT+Zvb4tJLRspzcBP48gr
kzJ45fNPQ8+MYd+qVtvkCdxUMi1myO7W1p7fB7dxVvC3Xu1+AUKJWdp2udot
EqoH6BxD5QzKnafq947XW7O7X8fkDH1Xzgoh7xV6ForvQgnhPJW5l6M52nEo
Qg0j39gYe2kcKq8xrPDCVOFGAy2KtxJb53gPUegqx+Tpto2hlUBuVfXmeGuW
0CnhR0S72mYhlTYVNcWhnbZTdmSg5oB2Uq9q1r56URcH3eIwCVtiOmkV97NI
9UaphCiyYFqQ54z7ZObzm5sQoz2ltaWGDdsvyHLGeHhDNmOXNUpHNImiz3nH
76J7pTMhjexTuwEJtGZwYTixIDcaGGdhnGmUtHLNYg5hUo/qX9aBj1B0KZls
MJCZ27TB9n4JMBsocP79wsv6GiaVj1cAo6D07xd4V/WXtd8NtvRHzo32/MN3
VUKo825ntXfZze2uOejqj2foH4HfK2VV8V0K1ijtN9jWH6+yOV24F5jW6M6L
nR0IFVqIU6Q2Eohz3S6GMlut88v1KdXfVoNBjUBaOmBWapRxH9v6F7nE/Smn
hcV4Oz98RnFchNIPuN9SoF8H4krEuKAoh4bFZhpVBAe9YWScjsvxYxIdueh2
oqk2zqPWLEsBoDctCTLm22r6C+VG86adxcN1sVLfcfM0ogJzkDJuggseKjim
oSRBbl3IQIveX7djK3hEvWbW+38J/kJX9BcYJh9kMUezVTFwS9DlNOHSMyZ4
iK84P9UpPSUBXxZBxae68tQ5xzj3qYSKoDiPZuMeIEQLqGqrevyChQ/AGC/G
2VkPlktWO/tqXLYfmVbqZIdaz1WcgDSjtFY1WOAOZvnhHx7gzQkWIj0Y4+X+
9rMu2mV1gBI3NwGIo/TbdM2cz3RwDb75tLvrf/NV+U2KvfPOYcU7swHVvLUH
i4W36NJwuJfJDVWiSTlDtGSktGFHTmO8bOLYVW2QLllNCKcOe+ZjOxTx2c52
I17mjwYToUVS4jmahLMd3LDNSpCjJ/fHTVBRsVssJfw8J4F1FE9hCTigYwZz
0xuYRBX3xhlSCRwSJotdvZPWbN4HcrRpkbYKCeSMCY7YCgutAFZhYmoolZOd
9Jj3LLWkVv5F1K4FfpPT4FnE9yXm2Vk/IA2kd8mSoll0PHauCvonHACWMjWt
c2ZLgj/NxyapThb3x2oJd8dIq6OraWX4M8YUit+7JgZOKZgZqXNNDppGcr84
0nxBPnBT9hjVxC1mkWP2hJX27yUhGim5yf6rgNOKWc9VLGr/3m4nR9G84UgX
K7k8QT9GRF0VsGszmzDDaSH6ZekIxGYuJqSa7E3PoaorFr2nsOxbRvBw2KLt
pTNNSEhcr88vYxsSFjNp1ixPqQoqpppJBLIaDoS0opIFBGSejTNgFWzvx/NF
PtyvHLCKx3bxASMtMd4aDbe2RxKTCSS6WGUO0RXn+PUkns35gnu3oRwrfamG
yY4FW83k659F8AQwq/lwLs0eQ+OHECusyZ0zuAMySDrPBtwkKZ/FRcR5C1qh
dPyw2JDs3oQmrrIMkI9mM2cZbCbWR7t0LSW9mf3ReYH6LIk2zGl6QFksuFFc
yw3aTyjmwmt9qFpJPNQ1ixQspBLWojD6ARlRxxkoaxT3lOOi+vF4rMjpnZtx
Vgr30bWV4GWKa4rY7oYm0JlJM1mm6pIDMCYsj0d26J+boVLvkXLik9sizPPe
+mTKmaaxmC7DoggH76StewICBOe0BOFopKymOqxfFl/auHOJ7IyrSTSdSTgi
Mzj3hDUHl3g1GCLDHAwCisRrlA5c2WGA+iDy0ULJdl1yginZxU5WlE5zS2XR
Uvggc9lS3iMFivpuWK5K4FjCq6tEsZlWIlpT+6hVZLeT3eYJ87fCTFVwnq6c
K0LKarH5m1KqA3hpJlnPdDro6nHnRTxJKMocia/GmUAHj2kY0MKSiLoMiksC
q7xw+2VZpkjoGI5Hrmq7Jmuc1UdXVgIrS46I8DaNhwTzVSMr2Q5UB+5HBFnO
0ulUnY1S3yngRlXrckrG1KNR085EsoUBf+B0T1VboQOHcxYGng8mERJytiXg
4hQvllRbLlOq1C085gWhnrQo2nARvuP6N8yRKIpWjMSM2VoQQGxBSeIW5Kyw
H0+pGIK6ieEwnVkJRhYeM88Uvk5MX+oTRkmUjQE0EhWBHmqSdWGg+EaUuHxT
tbzi+FZ47Sy6c+NROWxScTTxNHj9U+QTIzcwRvncsqzXj5h16XAWHS87JZKK
UX25xa9DD5c0flARgXgtnOMu2XhYSMW8udPe6gQb14mRxDc9vOSypyk+S1Di
frLNNlROU5kd7X6+zv7L1umm1lUk3oQd3oEOjI45JFSCF6zgVUcIURFXsmHl
qbIG2biPMMv1MFdFRhYsEimskSV4dExTS7jCkq4koyQ7q7JhnPwkAjjej/ES
COsiZLB5axCVBFFZGPOxIpc6BYhjqM/LaeAPw2io0uvlx3wWDiLVZXNKWW35
/EZROul9yO4TSTUVIBrk1C2vFgEJYGxRRacaa/5O0gUwc8O9DqnWnI3BRJIB
tZijorVXxlWTPGttx60bvWIK+6kDEaqoUgmF8gAGkY9NbCBt3pAUYw0jeOwJ
QCUfLpIMB2JpAgJRqSuiDIUPm1RTNOSTi4hlI7Kxe6CN1EFimNA8Tyk4DA0z
H1G7v8ynQBvJ23CFjp9v42QIYqwmMmtrhzaJESK1Ao3i4HJ2WVWBYOrDDWwX
WZV04L0UT6pcIvTbqEvP9F+ZHBndHb+moDu/xriMl0aXUKmEm6rIFSbdOoHJ
skpUt9tEoQTpPsXAIeWfqKgKVSZK75C8TtoECfLxVCLYaAj3dioSxzCXUEKs
cARoN8AKeCVJhgJ8UVp2oiliFegv8aZGjjGcnaP3MJ7sNh5izOzCzErMhqHU
p3RUJ4cI0OVC6rgHljGxuGpB3rxh1EpHI6d+klrUKGPPsunooXL5OGxZHf+t
QWDyXN4RAjNyX7AMicNdo94dYwGuN0r3FsnVX18D/g+pqKSX3FjvfKScxgeE
ijd1koQjl+rAMyXB2zyb41QJ/KoYZqlsID/heAO5BAaZULwz4qVhwzMZB1Vl
qyIcj1mcmmujixNc7s+xIEeMlTagsgUpnM90caBML/8cVrQ7ywiJCQvCF0hY
zI0xTAkoTjK0YJoqNsTVDa1IJNRGF2SLVBJXrGq/SFydd2lsK7OdFn1kmpGU
Umyes4+hyOamDnCQkWD9APTRmhAttSSWEEt064dY/dYT0bl0oTDFGtg0yIqW
Ln5qtR6InFIYZdanYxQ0swnSW4q4dnDY1X4xqTCJpjaNVstTNWrUpkhyR9OH
h32KP1+qVer8dZYJrnQckCW4aVObZzSK7MUKAboZ2jg1dHauaYacOIIOGRIa
FFAJmxn6Qgijz6EZUKJAOs7CGYzMgoJTO6YagyFbqNYpUzuhaMW71JxRSsah
/IDKS4pxjoPetc1wxIFMluuySmU28k3fqpp2iB+r9zKaWImx1pyU6VI610N2
TVHoPTujVcdqeNOwVG70E7057KmiCTOaFBVgFFXBnQELmaa5j+FjML+IJ2FR
BraqOBFZCDSsEbX0QBJ179xHAUI0XDiYicBSBGxB4KIpu60lYswL0vTJCvYH
xD2yYwuDFzHZwcvRcgs3qt53F3SXpeX4ztcUgkTx+B4sp1RfE68kJNTp0kIB
S7pvjz1blZbrLdjVaNJxggIQcyJJlLDN1Towzcr+0/opWyPNeFY8tU/MYRnj
Cm6kk6FqeBKzOnTYVsWKu1RyVls/3RUgUojjSSeztuIEDrOV8e8fdRQF85mk
NLxtSxOjV24cupGdcQnLLYV4V5P6K2qFKRAsPTVEzDBLqJ4G6lDEGsnDaEoc
yYF7VF+5UEo3tZxeVAYCoNM64t+0SmhFmdKl57g1zChCYYHtTXCpw6QQpzjf
dczRkGB1W82ytBtd0KOGh5Yiqa1BOGBP2WLwR8zT4gIvq21iA9fvhLVaw1va
H45rWLDmZYQiN7rKO/wkar4RmJSCIeqhuSoPWy1lbm3gmtF2hsEbJLMXFn0x
XW3C4OVh7+Xb07OL66t6EsZPV4Qsa9G2n7Z8XQYkMQHoXkY6o88lqhYxmKz7
lmE/UCfymdW0g1OV+6MiRQ2mM9GosQEQqylilQiXkWnIntyNNK4pOlFJKdTh
N7oGhH7TImclMvZingxDqnEsrEHXep+Esxk537iTDr5rnWKlprgLP3L8IDpx
o8Sc2ySa4GU/fsX5olvNhMjBblsDFFsT31jjx5WcG6JZTDBVJFmZcjqGJSZ5
nGwpYWN1nE1EFKCHg0eBCZUhi/EgvD4FuDCyPJ5KNeswv78BXTG7V25oNHCg
9wPhoMtz8K0pFQPQQYWV62hK+vgvI6IdnEHGdkLYF2Z5KgUNNQyTD62KEXhZ
Wm3MekQuR/bqJdG8yKwJ6hAB62jrWCfFHEnKehR7XEiTFAsXEokCZqRvGayM
MoVtGI3gTLKFADryAcjq6IzYimWKQqMl0Akqg1WL1VJO+8RK4KVi8nDqIWrx
NL3q8+BExZXSMurTjGKnzETNwm1Cp+odvAdp3qiYdQepqRxa3cIRgs8QeyX0
SLwPMhjr2mExu4cc4kAdIgh9h6YqmY5dfBOFZJYgvb8awmJVZF0tbgZJlCJq
TPQf5+0MXqZ30a3ca3311Ygo2oY5URqRHJjko+3VNBwRzYzq0dPTKiUDYA2M
k0zW8F/l8ifb8xC9PFgvCOAkNV58YQBWRI9YUblmM/FDLUey2OsJn9CVAv2x
KwpQlmnZKaJkNjC0dpCMKztAQB4Wll2IysoB1pmF9iNJslCnRljHq6rwjHJ3
Mp10UIXPlT9OgkIGMhExtUVZVSy+z6ltXuJ4ZJlmSswig5T9LIWK34AtT6lf
YA2s+9FDQKYM4eT9xZdmVBYjU5Ex5Uqq5lZZgowqiMtdY6Lohr3MWTrLkC6X
GqS6udsHKtN9GDmRgrUBm3aYBHDzNLDjMzV/JuuqNlUuOlZ6XZ/k5+hskvPo
T3XVPrs4GX7DYaILKnP7O+eVt6Lc4RgfyyNiUscApU4KVog2JRiUeT3Fa+gq
VnlkAx75D5+aykIMswxzglOpUeUvlu02Z/ksOD08O/TFeGN2jEoe0EHbKjnX
yqwfmAwHHEoHe6bIe4ITwJ40OwgugLbl0gwBfVGYmcGVyii6D1bW+PDhf/VO
Xr/4+LFhAIhDGFe3JwaHAiSVDB1T456QTF3ME96gM5TzVi6d7h+8vxY5Szn3
B2geQoJEsneRuOf4+ET4wqHw0UUJRggG6fygkxaWx8KXhEURqJ3LYfQZQYIh
mdtLZRwxinx/m1sK0K4x4efAJjdra715v7B+spaP2ecSam1cGAfB2ZPDtTWu
zQ14XvnlRJVFcYOvDoI387zgLh26TJLVPBvjK61Mdw0kKyvCMcgLclA5Pm+y
wAGwfSUr1CUnfPTdgVM0bVOYi0S1lMelbV7Mqbh+NHQx8MAsbW3t0MBZrEKs
oKF2pNHngKtl4RGg3V4K+vtc8SCFSWeZpsTYiytXVROW1DgKoCYoJqV69TWe
wFJJOH+aiCrkaTRtb7hAWEFCc1Iv4DJysocJrvcC15LdLJeagjxsFeb7X0F0
gxk9wJEyiVAjHJLqPIryO++jgPztV7gV8l9Su4UNQPn/wrrB7TQbU7bz6cnV
i8A5O4T2ZRROW+R/PwQBC17LCvMaYw221uHcjoPg6PzNm/MzvEKYVSdUkXp8
0c9nwHthnwTBJ0dchVdCkacREEhcA2wV7XC5Yrfm+uP7Egh5eFHKqMqtpl6f
VXMaPXQNIFii4pwlJXJ9wzdJQ63n3nZcNI5speWkd4XNvk+S2zhLEy7bs3GU
Xp5sWsmo1kDjLJ3PWAOjUOsruh11xNU8d0T05iBowd6O4To9P0awSzdn50Ii
xLxpYV9H9x640aPlZLSlnKEMRg2b2pl/S2B+ThmblL7GoPmccjs1peeEN/j2
OQgLIzu/DXCY2utq+Gn7iur9QebMI87ZK+0rtytrfR4Ihh+VMfzzwDkobwIe
Ei73DFdKctan+ZkSX0RlNMJcCwmA7zxNPyU6iFXma7Dk5D3IpblpVGzBOm33
lGH6Tc/JHpb7RUkop5E0s3tW6SW6rNEDgXtIBbIPVR1gEKxO3qM8jFuLo7sG
qQiNniNVKTGgUakuvydGhf1Od08aJTXc8Sqv7DqvtN3pg/E8RkNLovt8iyOC
OElGzxArOSRLCBpmGEgOC1tpo9ztKxxGHH5feaeBWWVxtaD+s9KWq0OXy3or
GWoJIK5sUU5KX2PkMeEVRmMZPm7WekV99aiTCAX+lKQkTD7sUBqhTv+LMTqU
almIPmvmFPmjyVOSURpD4NjcxPUiIyo1A3tFv22RspZ3awoa3dsrlaAwG0vJ
RKjg00RmPJiEsZhSUDKcY7SkmGITilNhHVTNyZNY7cVUTyBQb6bV2hFWhxeC
Q1tF/U/nN0muxT99X2AZpJAyjSS5mzOLRT6lztqKRt6y1MxyV5Sgvoilz/JY
1SCnqhvCRokU0iHTOyr6Zp7EP88jXTuPlVeVQM2mAJaniZarFHz/0vBxTg1W
dnMtXlu1AsxC+Fl3JfYvXOa2ki8vEZGcUKK+bQfH2lGThYnoO5KujWKv8eNU
qRbGvHFOrdyFU5lK3ieNv9Xd3UNgdnd3CVsslISdVu/8t9U7XzPw3u7uNg0N
Uzw1WbgyH/7qn9FPJCuTOIVZakdbstIpxzbCCLJcJl/ZO3n9IotvMWLvOo8a
BlWuRMHw4wqFeIY6GoM4NlUJIOpjp9rHqgY8nT1RGtP9TF8esaSwF5xyuWGw
pmWZtJxMKvxb1960BAH/tSvNKvYSV/9XPhAZ9cq529q8SJmWRJxnqYqmEJ1G
Nk00pK5EitDqhl5xQ+gJBwtPVTIhOWKpeTJTA4nULFlclhZzyBeKLywveaXS
laUYnuYPCeYPCeYPCebfRoJRKt8kqhcTJIZSnHiqlzivF2nCH2LCv72Y4Cj8
fsbbJ8vA0Kp8o4oxE458MubNNRBUVTocm3zT6BOO3sfYG+PXcnS7ENKn5uIu
AT01MeXIv4Xu89W12SwOq/m0zxfAKCAtsHz46+WAdUjn429NEcskE52YL1lr
zMW0anUmFtPicFFO7VTVp3MhW2NqIphjEuEYUzvDqc0ZecDQJo258kT2sRhy
SmGBI0QBSSokyiYJdO6dUO+rXjjk/Sa/ILxkBsUVJVQZAEBIPjqMSS7mQ3T7
CUj4nPCQ5T0qYEjZsI6humToY8ZFZPeCq5hg+gxFrpj5h3GumENbYB952cY4
Qiv+aIQEr5RYPNKtrzKnnxAhpV2lB9fHVYZEpdRB88M521M5mk9Vw5BO37aL
kuM2ZCwpPQgEJn4XcYO2vin0BQg0Te9JjuFb9feUAmE5o4T6oTPZmUuFMNWI
ngV22ABBcZ5hQAmb2zEiHFm1JUe20dKrpQT0s5NQKGzEJHSRlz8XbmRN4Eaz
i2U/swsKifawEpMwl0Q1l1XXol2eRJZGRIwmqZVOeS+M8yKMmNsmwkhYrTsg
SdhTOm0rQJNPaYYFxTnsnvOCaY+r7qbpTqdAhjEEdITsi6ImSFFEgu7IXFe7
IILCFxBzcH2UrFw9ZIlrjY0TjhtEKomvuhbKcxApu6lEPc2qtPyNq6NrQuE3
NffLloLuKrjPxEe1XiF0OnFplyEX3uR5XfdL5XxQKR0SQDUZcRCJpLdwUOiL
yDJuKMeFuFSWpBXnyK1WrFGYqPCcusdV0BFBR66YvkTWkXGEEc7Oq3Mz/ZRv
lwVDQ/vuIqxFO9QB2pP0jkvA2HK/Gl2GxLOdRiNJ+1AlRlRJFpP/yUiVmBR2
KxneGh2HUpY6+l6FfuDIcJatVgv0pcE7DII4T6wcuB73rLvCwqbA/1W5EStf
AH9XdUU+koNSp3fVNBqoekm9ZaioIDWHXsFQjD2SL69Gq1tdpTVqH5E8SVpF
t8jGrbyYiSohQYDOSpUtEyco1MgUHCYN/PAg8HGRjJpO4ymrfO518OcvpbGj
/Tx3ZWQxTSTCa66mgWHu6PoDGKkWdm60jlWpw1RuqwbWpFmlVkpbdx5zkgt9
TfykXL5VtmJRY4hmsK7Klq5L8rBTfsjTaM8bHKS3xdGkVGiPRyZH4jpR3Wyo
8pNXaxdpFc21VunWn+WqbaqQiaddpIr91FWcrymm+WdMQwYY9k5/OLGzMtVI
5iI6XT1VlpuntaVRKs90jU9c9bqvGy/+arcAD01IjNUQ06QxIaZhPjPbPnWH
QMtCYxiBPhZEUsxwVsZzm1nIzcAYFB1TvvywpYCibkCoyr7PZ7jCahdUXU2J
A5t4g56mocxMVOkASpQkwVvXoRta+aAUu16Dnk2rrggMZu6iL3CuekdWbh2r
m6FxBIfsjIZDuDXotg6kmLmElwwBb5l2JyllPpKrBRdFIGF7cv6fKM/EedWU
Qt2w66nhCw4a4VIRs+VkXMXjG3TxNO710PpKE3dN5d1Gm3o0YS7LiH455Jur
ptfsF0MLgde9phomPTkkYP6WD93a6omqLKDYni50DI9K5fAPH7gYLRai1cfv
dCbWmYRInMdjLGtKRYXgaEltlgmlropZU7nYuNwIq2ggmYmpqE/uKy9e1564
vqKk6Ya3ei9mC9XVyW6Sckl13VFaE15YTi1fudeyFKFizceCim0mWDqqxjol
uYsIxVXpFBdXhTj9MKCG4lLZ3Co2XpRNk6pOuiqR4CrOFjltB8/Tukp/ybBa
+YzVEKfRc0MTI7ZtsRPX8Ax0vLaDQ3bA0pUFgkrgizFpDy48ZVOAApByJpp5
ldvkMGsy/Qk5qsW0vRIzlDhFWN/EylGRiXYOGt83VAKaEuZzfsZmbvy0V1AA
7P6CzDhnpYGQ6nvGmFERnzJXkoJyM6KfArXNqkUQRPjMqkZuq1ZtbWVWrRXL
FuByCXEzDFfXwQJIStp5/ZyO+fq5gF+4rdQiBYpwB69xEWzuwTBTfzcD01cN
k3bw58Z/N1T+A2apJBSUzaZLql9G0mClyv0v6rT+3M/+wwBwUdXvR/6TguL5
pxgK9sFUxRr9e/+kb8L3DxXKqDSbK7E4Q8K5fRl0CGIEtdORTWvpK0U8JImI
vrvG13DZp2fHJ9/9qaO3cXz64sXb54dXRy+xZP8q23AUC5Gmhhyb5uvlbSVF
a6pW3YZen3cJy0+DtrXCaWiJmmCsUU7JvnEyjN6vWxdn8eS8DVp2q7yZje5/
7+1stjqLh7C2QXPbg9ecBpfG9/W1MbIp54dXkWvRNrY8p2GBddVtTMO8eGv2
UruNKwveTns/Sy+d3osUbe+NDVbVvX3KbZhC/zWylSrz/0BpzlvqnwLgOZEj
OGFrg6mOcNlriQXC9JJQjQCVcKceoJp/ZrBcF5GSwmP+FCbh9lT3TUKgZDwj
/7j5PFJJyUoAt03MKiWK6+2ppywr6aVqNWhLPdT4S9fkVWU3HdnRLngblusF
PbziuM3FqPOfZebnxlG0finsicxel7zRBUXD4OK8ZzRiVVUXOLPWQFRvHVEE
D3WpIUzGiVWXjjDoUpm/I3JKWhX+xMsvgzg5WtolYdKe3UWbdA+dCCu1p9xH
hYiXZEUh8eRlCYN1AOBbrAO5boufpc5NVCfSQnt1cb6wxsAM0kVjNLBmCEsK
PeqP01AjUorqaJ4w9lcyyN0UZY90TuE8KIt+/KgWdBO+f5ssWo2mTETkbaOL
Kr1Ww99ttYkV5gU8f5Xy2wtNYrQfXetH5WJY5Kpk/XN9/dL6uaSPr0823m+u
O07YpWcwcc/Bc09LB7Egr8wJ0LE6dGA1U0BddUJO/5ByOyxvfYBqdYBl9TOo
1RBbHvsAtvZko+gAaHCV+osufGGJ0jRu/x474BEWyz2XOJASnHy1oHLs7Uo6
cbdCqz77LHiBpPIbErVoYFV3uco3Wh0yFYziMX552AOgg5Zxl2u3j7AeZehW
lJrpGyWjpDS4dTT+6umcuMy1uuwqs3aeqJ0u5dFy7Sol66w32+KY7iNgpM7C
Rx7VQZNRzVqrEGpY6P8x/4IwzG/Ha0DWH/zvsAcSzyP+oaDkpEQeMCNZ+tqf
Wg//9x+/PHqRf37EdH/yzkbsTbhbPUg8/y74bA+CDw96LQieBO12G/77wNca
itE1goOg8YRT+J7Al6BPLXsNbzO9lk9CjIvCVxbPhm8SE8LXOlvuL3Wvfawf
bOlsS15D+/4gDWcHT56EeVtucRvouwWIJ9XXAkV/DoIt7+Ce2f6VUBmwd1d3
cFplNvVRg2Wnu+iN8mtu9l99Ul7ptSV3pW62IIjWVRPBdcDDv/640mtL0LB+
tk/yGl7u33K2jUM/M1baT81rVGHFLnaYz/s3cSGy12Vv85Mu0v33W4MkKEEF
gWIqGG4ueG312f7J13R3e9Eb5df+ydfUyKKVC/s/5poGFZzs/rvh5N7OQ177
3eBkMzCq0Y+l1/6n4WRHmlDnm4tfW322fzJOPt19yGu/E5zs/kEnHTr5b4aT
+3sPee0PEVu9ZplCyPGhLUXKyWE7KLjWizao2LYnTJCjdmWtqpPjM8pDWtFg
1XUNVq3uJzFZeUOKxBNBtYK5hVAenAVfBtu6+fXiuDirZbzfKOx4S9ks70Qn
+XoYHvZ+e0uairZZR2Ov84OEeD/MxlYN6vzDxrbiIv+wsf1hY6vY2P4TL9SX
2/Zrf9jYSrOpj/8yNjYTD/77EgD+sLEtWqT777eX01c0sf3ryum/dxubc01X
fa30769wwZuuhe7H5a8toAn/c4jCyga9f90b8Hu36P0GNwBtLz+uIKr9cXF+
1Wyr2R3/ZS/O793s+IkujoX9TZQUH3Fx/rhv/39717vcto3Ev/spMMrMNelY
Pke2bCc3vRk3dhK3iZuxnaR37cwVEiGJNUWq/CNH6fgB7oX66b7lxW53AZAg
RdEkJSeKTcxkYlLEAljsLhbA4ocvoW8L1lS/Wn1b9yXVFetbp5q+rUpNb67k
OunbwuXidmfRgrGxOlh+wXhRhOPEiQJzNTlnAXkns4C8c6sxjxdJyLwETUsu
eMOocfWtiQ0fmGu9GoLGwXMPtjrmrO4LMW7zkbc58v5IB75SGP37+O5XeUeN
gqqXR+Tw7jtbXsWKOOo6EFfDySfaScBOwuGTQEN6qBh3PDFgHvmmjnC9uC/k
tQRmbLt5T+CCJXeWu+J+cNdX3FcVu6rutG7W9Zt1/RRLclKzrj+XmtjZGm1r
1vUXlrbOG/vNun5RJdOpWde/8+v6Texss9JenG1tZLKJnW1iZ1VaE5lsYmdv
N3aWsVe4/vMzqyCc92iht3Gxs9keHrteNBzJpT1cv5vwAI/jBwSNuCCbRlhU
CCv2VFiphclH+dlqV7JatvKBcQdxtnsxE242Vkplu5/7n4v3Y3YqBvDLrZVk
ybdeQD/O4n9Vy+O/tnLj+2mDZtFy+01AiOYyu3md8VTMFPh9GbCc1I07MSYs
lyuKJP09HvZHrWQFXV+4kILyTeHDJFhqxUAx6R0KBIpBfL6eyKCpxXUthE0m
HtJekLnjtfs5jkykWZFFDFbbNwbsyU4VtlTYuDkc6LtgoVI4FMq9MjW+8fS1
zObOm7zBouQm2e1vjCl8L7zPhVCYEMF+QrdTx5A+OVIgQdWLu0LtE5no1Dl7
P33PN8C6Y2bLK4KMPcsFW0bxZTN4q4eXsiQr3zzCVHcDSZrNWptIMmsdn2MZ
v0NVuI7vkfI/zHTjnlLCpvlUxrEobmvNDSZMNTeZ4qy1Npoot7HZtFmuwtnR
5CnLzv0XZC3jOSwnTXXOoRilVt2zklm/Zs2p7b1jqrmXhamm84+p9gQAU/a8
ymZ+vrysmFmHJjyFEd5xFmXO7VehgheesgF3AjH/QV7Wz+Br35i1aNK/ylLL
76/NZS2/x/b1s6n8ntuypa6Rgam2C4dpTQxMlayZVG8Sj6nAqt1k1rarZW3M
WomsZfcj75C+VtuhxHTn9LXsWl1O1s+j6o8bVV95qSV3eZcudY1UvdrGL6Y7
oep1VvNV1q/KSnQaK7HyUkvuuy9d6hpZiWpb8ZjulJWoslWYyboKA1OuwktY
iZ3GSqy41NKREDml3n5AxCqy1l2pvbfLrY1FbCziF7SIFfT1b5IPqLiNvn5p
fa2/x3HHZHhxTNFuxTPemXCg1Rz5ph+LY4y6TYTR7UYYdb/UmfrAGzeH6ucP
1YOwgyCFdj9yuJ+Up2WJrnG7KBWmdXBLYVoLytdG1KhBZ1N2j+IQMjsmNX97
Gr5N3b2W3GGHPyEGA9FO3zYJpLmD9e/ou3nT2fAey9S9k3HUFLLV3EGNJw7y
ZkrBfcfG24/NqDPNkkdKtvNYpEwMisfA9qF0sg/zqs++Y91MgxczJx3TpWQK
pJypCxgTEAZqn44zS5FH6ABQ7ogsGZ9y26ErphddZ7eJygBDaqhZOYdFkBM4
9lvoR+K3G8ANsvnoMswQs+/HMitbeNPNopkbRdOQCPHdi0loIQ9jlZJiEmBo
nrqsryA4L3OdYBnhx6a4zPMtLNjDywOhplN5aZwLgxTZIpLOWD5KCsNKo+9U
WiYIL3Y3asfixRTqes4rcKCTVtT1o/Pc6UxaKlxPpeWj9lRaInhPpSVi+EwK
tUP5NJHqEX1mzjqBfSrdcnyfSaE6LMV8HepE+8UU7qpuLjXjVWmJuECVlpg6
q7TUDFql7Am9ShPpmEY6ZrAahc80Ny5LoXjx+5bqMBcXuEm3x4Y7eYGB+XWo
Eh94S63IpLXg5C5wsQv/9kpzsiIj7ywnWZUozFXVYd2tffUgTZXW0tqndhvK
UciEUlauQ2PtKZWPl1xVHdZds6qHU6q05pqVQoTZLKCQiVysXIdGs2QqH594
TzSrevSiSmutWZ3yY1aiVwyj/SrXodEsmcrH9K2sDtWxdT6nZlWP+FNpLTVr
6bl/kW/caFYBhYxi7dy+N7j2mnWQ82sZCmupWXrM2qk7zyryjRvNKqCQ0azd
RrMOntSksOaalcyzdqvMs4p840azCinMjVqL3cF7oVlPbt5j+wo1a7fumFXk
GzeaVUhhbtS675pVtBpWRGEtNWvpedZ+5To0mjW3MdiVwaR7FCS3Quj0LIU1
16w7Fb2gx6yu4Q3uVfEGi2adjWYVUsiMWd17P2bdyZ3ivbreYNGss9GsQgoZ
zdq795p1p3aKl/YGsxeo3Uyh0SxW7fD5gjpUOIN+W62oQ6ECWr8+5NoxKDRR
wTEn59K6WJhVHWZX6ZfMclCFg+nzFHZqUzBPuO9WABXKp7BTi8Lc2X5WhULF
w/Yqpeb+tSiYx5bxvFY1Cl9gvKhho/YNCnfMRlUzTWlO6lTFNOVTqGKa8ilU
MU2LKGTSL5m5iWFYqlPo1qZgGpbM6gPL3gM3n4rMwuI6pJ3AEiRy6lAOzSCf
QhWzUFSHyhQWgxx0l7w4JQtQUIB6sPGAPTs6esVee5ZwYiCDvmU57TG+uoaq
+WLsTYXt+oP+deoIZ3KWE2ls6AkB+45tb2gFgYfHG7KH4c/OBnYU/LGzsaHU
tS18n357nEs6Zk1SJ80dqji9mWugIwahat6R14/GaHHe0nnUIG6kpX5oy4Oq
wXxTHzxg74SPZ/ZZe/sAz020t5+wB5rA9gE8XtPBcuGPbddzvOHs6cYGY212
Mp74HnrSdECfgBjwpGyLW/ChPGnq+a0t+fGhhad/8eD2zPg+oAzP4y5v0VJv
6yi5H4cOtZ+Jycjn6PO3SDwuzl61CFBh6tkWnukeRNQCkolWIkEy9zPENQjI
ItMHZ8+fsb0nHdBDjSygzjYi7sQYKoD1niF9G8cy5B/ReQMDGgqVhUfQeRjy
/mVy2pv1NFveBngU2XOhoW98LxR9zPFScEJWwPPr5ur2lpmnz13PBUvvSEiM
kA+HRGrAnr2/CGRbHO4ncAyqxJdQZ0d9maKuDuWLD/Y3pFs9Dx6RFrH5B0kU
KZhHg6lPLDG1+0KeS5+gfASy3RbCPPQv8e8wgR1AEqdecmgcipISP38GH7qO
CdeaeDZ0x8wWjoUQEcD5IBpP1AlqqhGXwB50styEfJh48CcdxXaVIEHDqe7Q
BiFbFvRHwoocEVCrIYejT4crlIRzAepqh7MY8yLFTymrvhgIH1FK6DARyMzB
fqe7lRH9dH5GaABy8FeHyqEzzbZT6SeHp4epojgjfsjT6FcjKFaeLg/ic/UD
5FRylh3aDhXogXC2LRFy26ErbZQ4x306tVFlQjzQDhU7/gAdGdJrcYWluFAA
8kUqJXccT7MYKoIN3n/c2ZbsAvaHTDh2oGFFwL9DvaBeUD6fkjYS3SObD10v
CO0+XofDVb9+y155V8LvgyaDrE/sECzZRx5b/lbfsYFma5O1QG68yO8T6MQU
rLhEB2nxKBx5vs6jfiPCx5YNSmsDt23ZNVS7rYx925f27cCwb/vwSPZN9kTa
lCHDuJQwuaSHp6G3SnyNUi5NbsZ+acAV7FaiGE3QU1PAET0EUIDOH0RhRHtd
3JplTZgSilZSBJjCkY8rJF4kdVJb/Qqc2ZOc2Tc4swePxBkUhSedJ9soYlFA
GA5QFeNOoygIQcIH5K5ST6aVX1quQ7TVkPmPSAkEmFr/MjAFkUQnIKMrgRqU
zcPXViJRriYAlQnAL4BBduQ5Vnx/EmfJqClZQAKO7YZc0hJI6+UTvgXHlaQh
lIkYIKeyZKOTqUe0likslLQgooUyx7zAyO0LqSqWBtDB+7CQFVgPgs5JOlLV
f+jhb5GLC1R9UmcwGYPE97GVXVYYSxr65vCcvX57foGGYQqcVq3hYQo7SRPL
h2UitI+bqRo4KXnk1RiFpgf5PPKuiJKUd5wUKjOjIG36hHmiYICwBijGiLjR
9yZCEQQTJfxNYBMwCHTAshGxRvqMPRFeiUSEEANJu4weIcQoDZTGEM0INZd6
VkAvWtQl0EmTKEZTSZRdi6CsAd67FYAYxd1uuyAttqWxSALtD5ijXIqAACNM
DoEvHJ6qPzL25PTo+GeqoyGKQYapY8FdNdhL1oMYWwngifz8hXBhUALzit5N
/mCHsjyNHPwOoWZodfXKdi3orhiFxxDkAioJDFfyFdQyABsma/Pc/qBGZtMG
aSwYHA4zVCnXW+yww8Pzdy9orAcDAE00fpJ4OeAm9RxyB2KjBK50qmgrMRmq
SD1k5fhUUkRKGc2uNJp7htHswuN1ur+wYn7UT9Q/PRAXMiFV3K4srmsUtwuP
VBzQRLcIzS+YY+wU0gRFnOMkF9glu8ANfc+K+rG+ntGEAB2F2MMHb8DmpFAP
W6Yst9g02JJjjx6iW490j+CwTWoAg7LZHS3UcD1Q03dBBBoapj9CowM1aqXU
NatvZEsM5SQ7KHVXG0rtmckxaKRc4xTVVO+/RvMO5fThp0VCXllMvlUzMUuN
FAxcpzDbnzuyP3eN/tyBx+tUM7IcgOc2lT2BsaOdgsUDc2nWV3fr2PNCNN84
L5CzjED7agvA+Wiy4wWg01NBuHNDHFthckQjMe/18PZBczyD+VbG/pwJFx4t
dvofsGSYlQyaNCepGQp2IELEuQLfAodhLJA+EY0f5NewvyMXP7Ztd+DFIGeG
c9zqb03G/EMLey22RDBB8+0eyAUOKb+Di0LAYWp50pSGkTF7SstWygoe61HD
MGMLraJhemL/3F1o6E7BDNDwZ9kfGJD10TBgjRKmGjh06YHlWDvf8MEYOThE
69aHRg3RmZxKLAScsKoCDJMuivLeJCC1rWZHiv2OIfYdeCSxP0o51MmQiFJW
UJd4Anzl80mbg9C4ZFQ0RJnhYxZQOU5ZjLhMmq7ISVk8//pnUrciq4OdTtl1
RaR30/YG7R7WMTOyJ6BlgRhz8Fb7wWbcMXpeKT0Yw4CVc/AfS653DK4/hsdr
7R8jnJ7hIQPzZFPIWqRcmDznawzznnimBDwbwTeeRE803VuyW76AduoPF8Fj
bsXSQGYgVvdWX3WdGtn0VIf1PGu2iYaGtFz7s17abSaq3+MiiIINkdxMz1ag
9xBTNYElTdBI1VzMB59JmVFDcwwTC16ew6nqNHkQanB2Zstpzrbsw8dGH27D
ozF95crNMNAsowlhI+Kmt3nlbJC/JGMYLm8AUjprI7aj5NAiLZqAqRW+W6QI
m9KcGP6qki6YowV6RUajOJK3FJGIPMS1PDneYT+25dIvR0xCZ9AOQi4xFwOZ
OXiUGnvAyrq4xU+DF1CgDs2MU5X6AoauS9e7coQ1lA4sdgOX7yxB73CBVQF5
Cuu7luvhCu2ff/75KrKu7CG00g4/Xl9fkzbL4YnQbjm8aCtXgaYVYAOhAlPZ
9cr64wpPMrO/iKehgYyEgBkFAqRy95JBgc9GPuopaMPhOPj0vyCAUjfpB+7j
QgKoAUzXXVe/PhI9kGzPETP95syD39kRd2eOfRV/NvKjKTuCaVPynX3JfYu9
/PTX0AGbpl9/L9zfOfiT7EduRZdxfg6zSHbKpxz6X7/8wRP+kP0UhvrFa+73
PXbGQbzs+J0NA5Nw2Bn+71uBF1f9xxlMX868QOgX/+a4/PfxI8cGnHP/Uvhx
UfaYnQMBHtfzxae/fPwM5mNgo+MPL3yoacDOJ7gCGL/9CawIOw+FcOLCPv3X
t/vs3cztX8bvTu1LB3r1PUig4yRNh2q+93zNYpQ1eP2GRw68jlAkUTLUsGP7
yRobfjkQwuqBrKmex40AuRhhSAUFx/TQHiNMLeEhqbm8xs49vxKgFN8E7MR1
PYUSfDiEJs7Yu5PT05/eHSrgXsGeCQcGoPYprh6CGvwOKgYO4NnJxcn58TOp
T/96c3Z8fv4PelAFvOxsd7b19+z85PnJefslogk/fAFchtFr6AtSKPak29nr
dkBj/w9aeHcPb30CAA==
--> -->
</rfc> </rfc>
 End of changes. 242 change blocks. 
2693 lines changed or deleted 1559 lines changed or added

This html diff was produced by rfcdiff 1.48.