rfc9237.original.xml   rfc9237.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version="1.0" encoding="UTF-8"?>
<!-- draft submitted in xml v3 -->
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.6.6 (Ruby 3 <rfc xmlns:xi="http://www.w3.org/2001/XInclude" xml:lang="en" ipr="trust200902"
.1.1) --> docName="draft-ietf-ace-aif-07" number="9237" submissionType="IETF" category="st
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft d" consensus="true" tocDepth="4" tocInclude="true" sortRefs="true" symRefs="true
-ietf-ace-aif-07" category="std" consensus="true" submissionType="IETF" tocDepth " updates=""
="4" tocInclude="true" sortRefs="true" symRefs="true" version="3"> obsoletes="" version="3">
<!-- xml2rfc v2v3 conversion 3.12.1 -->
<!-- xml2rfc v2v3 conversion 3.12.1 -->
<!-- [rfced] Please note that the title of the document has been updated as
follows. The abbreviation "ACE" has been expanded per Section 3.6 of RFC
7322 (“RFC Style Guide”). Please review.
Original:
An Authorization Information Format (AIF) for ACE
Current:
An Authorization Information Format (AIF) for Authentication and
Authorization for Constrained Environments (ACE)
-->
<!-- [rfced] We note that AIF and ACE are mentioned in the document title but
not in the abstract. Please review and let us know if any updates are
needed.
-->
<front> <front>
-&gt; <title abbrev="ACE AIF">An Authorization Information Format (AIF) for Authen
<title abbrev="ACE AIF">An Authorization Information Format (AIF) for ACE</t tication and Authorization for Constrained Environments (ACE)</title>
itle> <seriesInfo name="RFC" value="9237"/>
<seriesInfo name="Internet-Draft" value="draft-ietf-ace-aif-07"/>
<author initials="C." surname="Bormann" fullname="Carsten Bormann"> <author initials="C." surname="Bormann" fullname="Carsten Bormann">
<organization>Universität Bremen TZI</organization> <organization>Universität Bremen TZI</organization>
<address> <address>
<postal> <postal>
<street>Postfach 330440</street> <street>Postfach 330440</street>
<city>Bremen</city> <city>Bremen</city>
<code>D-28359</code> <code>D-28359</code>
<country>Germany</country> <country>Germany</country>
</postal> </postal>
<phone>+49-421-218-63921</phone> <phone>+49-421-218-63921</phone>
<email>cabo@tzi.org</email> <email>cabo@tzi.org</email>
</address> </address>
</author> </author>
<date year="2022" month="March" day="15"/> <date year="2022" month="April"/>
<area>Internet</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. -->
<abstract> <abstract>
<t>Information about which entities are authorized to perform what <t>Information about which entities are authorized to perform what
operations on which constituents of other entities is a crucial operations on which constituents of other entities is a crucial
component of producing an overall system that is secure. Conveying component of producing an overall system that is secure. Conveying
precise authorization information is especially critical in highly precise authorization information is especially critical in highly
automated systems with large numbers of entities, such as the automated systems with large numbers of entities, such as the
"Internet of Things".</t> Internet of Things.</t>
<t>This specification provides a generic information model and format for <t>This specification provides a generic information model and format for
representing such authorization information, as well as two variants representing such authorization information, as well as two variants
of a specific instantiation of that format for use with REST resources of a specific instantiation of that format for use with Representational State T ransfer (REST) resources
identified by URI path.</t> identified by URI path.</t>
</abstract> </abstract>
<note removeInRFC="true">
<name>About This Document</name>
<t>
Status information for this document may be found at <eref target="https
://datatracker.ietf.org/doc/draft-ietf-ace-aif/"/>.
</t>
<t>
Discussion of this document takes place on the
Authentication and Authorization for Constrained Environments (ace) Work
ing Group mailing list (<eref target="mailto:ace@ietf.org"/>),
which is archived at <eref target="https://mailarchive.ietf.org/arch/bro
wse/ace/"/>.
</t>
<t>Source for this draft and an issue tracker can be found at
<eref target="https://github.com/cabo/ace-aif"/>.</t>
</note>
</front> </front>
<middle> <middle>
<section anchor="introduction"> <section anchor="introduction">
<name>Introduction</name> <name>Introduction</name>
<t>Constrained Devices as they are used in the "Internet of Things" need <t>Constrained devices, as they are used in the Internet of Things, need
security in order to operate correctly and prevent misuse. security in order to operate correctly and prevent misuse.
One important element of this security is that devices in the Internet One important element of this security is that devices in the Internet
of Things need to be able to decide which operations requested of them of Things need to be able to decide which operations requested of them
should be considered authorized, need to ascertain that the should be considered authorized, ascertain that the
authorization to request the operation does apply to the actual authorization to request the operation does apply to the actual
requester as authenticated, requester as authenticated,
and need to ascertain that other devices they make and ascertain that other devices they make
requests of are the ones they intended.</t> requests of are the ones they intended.</t>
<t>To transfer detailed authorization information from an authorization ma nager <t>To transfer detailed authorization information from an authorization ma nager
(such as an ACE-OAuth Authorization Server <xref target="I-D.ietf-ace-oauth-auth z"/>) to a device, a (such as an ACE-OAuth authorization server <xref target="RFC9200"/>) to a device , a
compact representation format is needed. compact representation format is needed.
This document defines such a format, the This document defines such a format -- the
Authorization Information Format (AIF). Authorization Information Format (AIF).
AIF is defined both as a general structure that can be used for many AIF is defined both as a general structure that can be used for many
different applications and different applications and
as a specific instantiation tailored to REST resources and the permissions as a specific instantiation tailored to REST resources and the permissions
on them, including some provision for dynamically created resources.</t> on them, including some provision for dynamically created resources.</t>
<section anchor="terminology"> <section anchor="terminology">
<name>Terminology</name> <name>Terminology</name>
<t>This memo uses terms from CoAP <xref target="RFC7252"/> and the Inter
net Security Glossary <xref target="RFC4949"/>; CoAP is used for <!-- [rfced] Although not required, the text about the RFC 2119 key words
the explanatory examples as it is a good fit for Constrained Devices.</t> often appears at the end of the Terminology section. Would you like to
<t>The shape of data is specified in CDDL <xref target="RFC8610"/> <xref leave it as is or move it to the end of the section?
target="RFC9165"/>. -->
Terminology for Constrained Devices is defined in <xref target="RFC7228"/>.</t>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp <t>This memo uses terms from the Constrained Application Protocol (CoAP)
14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL <xref target="RFC7252"/> and the Internet Security Glossary <xref target="RFC494
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO 9"/>; CoAP is used for
MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", the explanatory examples as it is a good fit for constrained devices.</t>
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i <t>The shape of data is specified in Concise Data Definition Language (C
nterpreted as DDL) <xref target="RFC8610"/> <xref target="RFC9165"/>.
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and Terminology for constrained devices is defined in <xref target="RFC7228"/>.</t>
only when, they <t>
appear in all capitals, as shown here.</t> The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
<t>The term "byte", abbreviated by "B", is used in its now customary "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
"<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be
interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref
target="RFC8174"/> when, and only when, they appear in all capitals, as shown
here.
</t>
<t>The term "byte", abbreviated by "B", is used in its now customary
sense as a synonym for "octet".</t> sense as a synonym for "octet".</t>
</section> </section>
</section> </section>
<section anchor="information-model"> <section anchor="information-model">
<name>Information Model</name> <name>Information Model</name>
<t>Authorizations are generally expressed through some data structures <t>Authorizations are generally expressed through some data structures
that are cryptographically secured (or transmitted in a secure way). that are cryptographically secured (or transmitted in a secure way).
This section discusses the information model underlying the payload of This section discusses the information model underlying the payload of
that data (as opposed to the cryptographic armor around it).</t> that data (as opposed to the cryptographic armor around it).</t>
<t>The semantics of the authorization information defined in this <t>The semantics of the authorization information defined in this
document are that of an <em>allow-list</em>: document are that of an <em>allow-list</em>:
everything is denied until it is explicitly allowed.</t> everything is denied until it is explicitly allowed.</t>
<t>For the purposes of this specification, the underlying access control m odel <t>For the purposes of this specification, the underlying access control m odel
will be that of an access matrix, which gives a set of permissions for will be that of an access matrix, which gives a set of permissions for
each possible combination of a subject and an object. each possible combination of a subject and an object.
We are focusing the AIF data item on a single row in the access matrix We are focusing the AIF data item on a single row in the access matrix
(such a row has often been called a capability list), without (such a row has often been called a "capability list") without
concern to the subject for which the data item is issued. concern to the subject for which the data item is issued.
As a consequence, AIF <bcp14>MUST</bcp14> be used in a way that the subject of t he As a consequence, AIF <bcp14>MUST</bcp14> be used in a way that the subject of t he
authorizations is unambiguously identified (e.g., as part of the armor authorizations is unambiguously identified (e.g., as part of the armor
around it).</t> around it).</t>
<t>The generic model of such a capability list is a list of pairs of <t>The generic model of such a capability list is a list of pairs of
object identifiers (of type <tt>Toid</tt>) and the permissions (of type <tt>Tper m</tt>) the subject has on the object identifiers (of type <tt>Toid</tt>) and the permissions (of type <tt>Tper m</tt>) that the subject has on the
object(s) identified.</t> object(s) identified.</t>
<figure anchor="genaif"> <figure anchor="genaif">
<name>Definition of Generic AIF</name> <name>Definition of Generic AIF</name>
<sourcecode type="cddl"><![CDATA[ <sourcecode type="cddl"><![CDATA[
AIF-Generic<Toid, Tperm> = [* [Toid, Tperm]] AIF-Generic<Toid, Tperm> = [* [Toid, Tperm]]
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
<t>In a specific data model (such as the one also specified in <t>In a specific data model (such as the one specified in
this document), the object identifier (<tt>Toid</tt>) will often be this document), the object identifier (<tt>Toid</tt>) will often be
a text string, and the set of permissions (<tt>Tperm</tt>) will be represented a text string, and the set of permissions (<tt>Tperm</tt>) will be represented
by a bitset in turn represented as a number (see <xref target="data-model"/>).</ t> by a bit set, which in turn is represented as a number (see <xref target="data-m odel"/>).</t>
<figure anchor="specaif"> <figure anchor="specaif">
<name>Commonly used shape of a specific AIF</name> <name>Commonly Used Shape of a Specific AIF</name>
<sourcecode type="cddl"><![CDATA[ <sourcecode type="cddl"><![CDATA[
AIF-Specific = AIF-Generic<tstr, uint> AIF-Specific = AIF-Generic<tstr, uint>
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
<section anchor="rest-model"> <section anchor="rest-model">
<name>REST-specific Model</name> <name>REST-Specific Model</name>
<!-- [rfced] May we move the phrase "for the object identifiers (Toid)" to
appear at the end of the sentence? Also, please confirm that the plural
"object identifiers" is correct here.
Original:
In the specific instantiation of the REST resources and the
permissions on them, for the object identifiers (Toid), we use the
URI of a resource on a CoAP server.
Perhaps:
In the specific instantiation of the REST resources and the
permissions on them, we use the
URI of a resource on a CoAP server for the object identifiers (Toid).
-->
<t>In the specific instantiation of the REST resources and the <t>In the specific instantiation of the REST resources and the
permissions on them, for the object identifiers (<tt>Toid</tt>), we permissions on them, for the object identifiers (<tt>Toid</tt>), we
use the URI of a resource on a CoAP server. More specifically, since the use the URI of a resource on a CoAP server. More specifically, since the
parts of the URI that identify the server ("authority" in parts of the URI that identify the server ("authority" in
<xref target="RFC3986"/>) are what are authenticated during REST resource access (<xref section="4.2.2" sectionFormat="of" target="I-D.ietf-httpbis-semantics"/> and <xref section="6.2" sectionFormat="of" target="RFC7252"/>), they <xref target="RFC3986"/>) are authenticated during REST resource access (<xref s ection="4.2.2" sectionFormat="of" target="RFC9110"/> and <xref section="6.2" sec tionFormat="of" target="RFC7252"/>), they
naturally fall into the realm handled by the cryptographic armor; we therefore f ocus on naturally fall into the realm handled by the cryptographic armor; we therefore f ocus on
the "path" ("path-abempty") and "query" parts of the URI (<em>URI-local-part</em > in the "path" ("path-abempty") and "query" parts of the URI (<em>URI-local-part</em > in
this specification, as expressed by the Uri-Path and Uri-Query options this specification, as expressed by the Uri-Path and Uri-Query options
in CoAP). As a consequence, AIF <bcp14>MUST</bcp14> be used in a way that it is in CoAP).
clear who is the target (enforcement point) of these authorizations
<!--[rfced] We updated this text slightly for ease of readability
(i.e., updated "that it is clear who" to "that clearly shows
who". Please let us know of any objections.
Original:
As a consequence, AIF MUST be used in a way that it is clear who is
the target (enforcement point) of these authorizations (note that
there may be more than one target that the same authorization applies
to, e.g., in a situation with homogeneous devices).
Current
As a consequence, AIF MUST be used in a way that clearly shows
who is the target (enforcement point) of these authorizations (note
that there may be more than one target that the same authorization
applies to, e.g., in a situation with homogeneous devices).
-->
As a consequence, AIF <bcp14>MUST</bcp14> be used in a way that clearly shows
who is the target (enforcement point) of these authorizations
(note that there may be more than one target that the same (note that there may be more than one target that the same
authorization applies to, e.g., in a situation with homogeneous authorization applies to, e.g., in a situation with homogeneous
devices).</t> devices).</t>
<t>For the permissions (<tt>Tperm</tt>), we use a simple permissions mod el that <t>For the permissions (<tt>Tperm</tt>), we use a simple permissions mod el that
lists the subset of the REST (CoAP or HTTP) methods permitted. lists the subset of the REST (CoAP or HTTP) methods permitted.
This model is summarized in <xref target="im-example"/>.</t> This model is summarized in <xref target="im-example"/>.</t>
<table anchor="im-example"> <!-- [rfced] Please review these table titles and let us know if any updates
<name>An authorization instance in the AIF Information Model</name> are needed to "AIF Information Model". We ask because the corresponding
sections are titled "REST-Specific Model" and "REST-Specific Model with
Dynamic Resource Creation", respectively.
Current:
Table 1: An Authorization Instance in the AIF Information Model
...
Table 2: An Authorization Instance in the AIF Information Model
with Dynamic Resource Creation
-->
<table anchor="im-example">
<name>An Authorization Instance in the AIF Information Model</name>
<thead> <thead>
<tr> <tr>
<th align="left">URI-local-part</th> <th align="left">URI-local-part</th>
<th align="left">Permission Set</th> <th align="left">Permission Set</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">/s/temp</td> <td align="left">/s/temp</td>
<td align="left">GET</td> <td align="left">GET</td>
skipping to change at line 175 skipping to change at line 238
</tr> </tr>
<tr> <tr>
<td align="left">/dtls</td> <td align="left">/dtls</td>
<td align="left">POST</td> <td align="left">POST</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>In this example, a device offers a temperature sensor <tt>/s/temp</tt > for <t>In this example, a device offers a temperature sensor <tt>/s/temp</tt > for
read-only access, a LED actuator <tt>/a/led</tt> for read/write, and a read-only access, a LED actuator <tt>/a/led</tt> for read/write, and a
<tt>/dtls</tt> resource for POST access.</t> <tt>/dtls</tt> resource for POST access.</t>
<t>As will be seen in the data model (<xref target="data-model"/>), the representations <t>As shown in the data model (<xref target="data-model"/>), the represe ntations
of REST methods provided are limited to those that have a CoAP method of REST methods provided are limited to those that have a CoAP method
number assigned; an extension to the model may be necessary to represent number assigned; an extension to the model may be necessary to represent
permissions for exotic HTTP methods.</t> permissions for exotic HTTP methods.</t>
</section> </section>
<section anchor="limitations"> <section anchor="limitations">
<name>Limitations</name> <name>Limitations</name>
<t>This simple information model only allows granting permissions for <t>This simple information model only allows granting permissions for
statically identifiable objects, e.g., URIs for the REST-specific statically identifiable objects, e.g., URIs for the REST-specific
instantiation. One might be tempted to extend the model towards URI instantiation. One might be tempted to extend the model towards URI
templates <xref target="RFC6570"/> (for instance, to open up an templates <xref target="RFC6570"/> (for instance, to open up an
authorization for many parameter values as in authorization for many parameter values as in
<tt>/s/temp{?any*}</tt>). <tt>/s/temp{?any*}</tt>).
However, that requires some considerations of However, that requires some considerations of
the ease and unambiguity of matching a given URI against a set of the ease and unambiguity of matching a given URI against a set of
templates in an AIF data item.</t> templates in an AIF data item.</t>
<t>This simple information model also does not allow expressing <!-- [rfced] May we update "that is not locked" here to read either "it is not
locked" or "that door is not locked"?
Original:
This simple information model also does not allow expressing
conditionalized access based on state outside the identification of
objects (e.g., "opening a door is allowed if that is not locked").
-->
<t>This simple information model also does not allow expressing
conditionalized access based on state outside the identification of conditionalized access based on state outside the identification of
objects (e.g., "opening a door is allowed if that is not locked").</t> objects (e.g., "opening a door is allowed if that is not locked").</t>
<t>Finally, the model does not provide any special access for a set of <t>Finally, the model does not provide any special access for a set of
resources that are specific to a subject, e.g., that the subject resources that are specific to a subject, e.g., that the subject
created itself by previous operations (PUT, POST, or PATCH/iPATCH <xref target=" RFC8132"/>) or that were created itself by previous operations (PUT, POST, or PATCH/iPATCH <xref target=" RFC8132"/>) or that were
specifically created for the subject by others.</t> specifically created for the subject by others.</t>
</section> </section>
<section anchor="ext-rest-model"> <section anchor="ext-rest-model">
<name>REST-specific Model With Dynamic Resource Creation</name> <name>REST-Specific Model with Dynamic Resource Creation</name>
<t>The REST-specific Model With Dynamic Resource Creation addresses the <t>The REST-Specific Model with Dynamic Resource Creation addresses the
need to provide defined need to provide defined
access to dynamic resources that were created by the subject itself, access to dynamic resources that were created by the subject itself,
specifically, a resource that is made known to the subject by specifically, a resource that is made known to the subject by
providing Location-* options in a CoAP response or using the Location providing Location-* options in a CoAP response or using the Location
header field in HTTP <xref target="I-D.ietf-httpbis-semantics"/> (the Location-i header field in HTTP <xref target="RFC9110"/> (the Location-indicating mechanism
ndicating mechanisms). s).
(The concept is somewhat comparable to "ACL inheritance" in NFSv4 (The concept is somewhat comparable to "Access Control List (ACL) inheritance" i
n the Network File System version 4 (NFSv4) protocol
<xref target="RFC8881"/>, except that it does not use a containment relationship <xref target="RFC8881"/>, except that it does not use a containment relationship
but the fact that the dynamic resource was created from a resource to but rather the fact that the dynamic resource was created from a resource to
which the subject had access.) which the subject had access.)
In other words, it addresses an important subset of the third In other words, it addresses an important subset of the third
limitation mentioned in <xref target="limitations"/>.</t> limitation mentioned in <xref target="limitations"/>.</t>
<table anchor="im-example-dynamic"> <table anchor="im-example-dynamic">
<name>An authorization instance in the AIF Information Model With Dyna mic Resource Creation</name> <name>An Authorization Instance in the AIF Information Model with Dyna mic Resource Creation</name>
<thead> <thead>
<tr> <tr>
<th align="left">URI-local-part</th> <th align="left">URI-local-part</th>
<th align="left">Permission Set</th> <th align="left">Permission Set</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">/a/make-coffee</td> <td align="left">/a/make-coffee</td>
<td align="left">POST, Dynamic-GET, Dynamic-DELETE</td> <td align="left">POST, Dynamic-GET, Dynamic-DELETE</td>
skipping to change at line 249 skipping to change at line 320
another explicit switch between the basic and the model extended by another explicit switch between the basic and the model extended by
dynamic resource creation; the dynamic resource creation; the
extended model is always presumed once a Dynamic-X permission is present.</t> extended model is always presumed once a Dynamic-X permission is present.</t>
</section> </section>
</section> </section>
<section anchor="data-model"> <section anchor="data-model">
<name>Data Model</name> <name>Data Model</name>
<t>Different data model specializations can be defined for the generic <t>Different data model specializations can be defined for the generic
information model given above.</t> information model given above.</t>
<t>In this section, we will give the data model for simple REST <t>In this section, we will give the data model for simple REST
authorization as per <xref target="rest-model"/> and <xref target="ext-rest-mode l"/>. authorization as per Sections <xref target="rest-model" format="counter"/> and < xref target="ext-rest-model" format="counter"/>.
As discussed, in this case the object identifier is specialized as a text string As discussed, in this case the object identifier is specialized as a text string
giving a relative URI (URI-local-part as absolute path on the server giving a relative URI (URI-local-part as the absolute path on the server
serving as enforcement point). serving as the enforcement point).
The permission set is specialized to a single number <tt>REST-method-set</tt> by the following steps:</t> The permission set is specialized to a single number <tt>REST-method-set</tt> by the following steps:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>The entries in the table that specify the same URI-local-part are me rged <li>The entries in the table that specify the same URI-local-part are me rged
into a single entry that specifies the union of the permission sets.</li> into a single entry that specifies the union of the permission sets.</li>
<li>The (non-dynamic) methods in the permission sets are converted into <li>The (non-dynamic) methods in the permission sets are converted into
their CoAP method numbers, minus 1.</li> their CoAP method numbers, minus 1.</li>
<li>Dynamic-X permissions are converted into what the number would have <!-- [rfced] Is "chosen as" correct here? Would "of" be better?
Original:
* Dynamic-X permissions are converted into what the number would
have been for X, plus a Dynamic-Offset chosen as 32 (e.g., 35 is
the number for Dynamic-DELETE as the number for DELETE is 3).
Similarly, what about "choosing 32 as Dynamic-Offset" here? Would "a
Dynamic-Offset of 32" or something similar be better?
Original:
Note that choosing 32 as Dynamic-Offset means that all future CoAP
methods that can be registered can be represented both as themselves
and in the Dynamic-X variant, but only the dynamic forms of methods 1
to 21 are typically usable in a JSON form [RFC7493].
-->
<li>Dynamic-X permissions are converted into what the number would have
been for X, plus a Dynamic-Offset chosen as 32 (e.g., 35 is the been for X, plus a Dynamic-Offset chosen as 32 (e.g., 35 is the
number for Dynamic-DELETE as the number for DELETE is 3).</li> number for Dynamic-DELETE as the number for DELETE is 3).</li>
<li>The set of numbers is converted into a single number <tt>REST-method -set</tt> by taking two to the <li>The set of numbers is converted into a single number <tt>REST-method -set</tt> by taking two to the
power of each (decremented) method number and computing the inclusive OR of the power of each (decremented) method number and computing the inclusive OR of the
binary representations of all the power values.</li> binary representations of all the power values.</li>
</ul> </ul>
<t>This data model could be interchanged in the JSON <t>This data model could be interchanged in the JSON
<xref target="RFC8259"/> representation given in <xref target="dm-json"/>.</t> <xref target="RFC8259"/> representation given in <xref target="dm-json"/>.</t>
<figure anchor="dm-json"> <figure anchor="dm-json">
<name>An authorization instance encoded in JSON (40 bytes)</name> <name>An Authorization Instance Encoded in JSON (40 Bytes)</name>
<sourcecode type="json"><![CDATA[ <sourcecode type="json"><![CDATA[
[["/s/temp",1],["/a/led",5],["/dtls",2]] [["/s/temp",1],["/a/led",5],["/dtls",2]]
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
<t>In <xref target="aif-cddl"/>, a straightforward specification of the da ta model <t>In <xref target="aif-cddl"/>, a straightforward specification of the da ta model
(including both the methods from <xref target="RFC7252"/> and the new ones from (including both the methods from <xref target="RFC7252"/> and the new ones from
<xref target="RFC8132"/>, identified by the method code minus 1) is shown in CDD L <xref target="RFC8132"/>, identified by the method code minus 1) is shown in CDD L
<xref target="RFC8610"/> <xref target="RFC9165"/>:</t> <xref target="RFC8610"/> <xref target="RFC9165"/>:</t>
<figure anchor="aif-cddl"> <figure anchor="aif-cddl">
<name>AIF in CDDL</name> <name>AIF in CDDL</name>
skipping to change at line 303 skipping to change at line 390
Dynamic-POST: 33; 1 .plus Dynamic-Offset Dynamic-POST: 33; 1 .plus Dynamic-Offset
Dynamic-PUT: 34; 2 .plus Dynamic-Offset Dynamic-PUT: 34; 2 .plus Dynamic-Offset
Dynamic-DELETE: 35; 3 .plus Dynamic-Offset Dynamic-DELETE: 35; 3 .plus Dynamic-Offset
Dynamic-FETCH: 36; 4 .plus Dynamic-Offset Dynamic-FETCH: 36; 4 .plus Dynamic-Offset
Dynamic-PATCH: 37; 5 .plus Dynamic-Offset Dynamic-PATCH: 37; 5 .plus Dynamic-Offset
Dynamic-iPATCH: 38; 6 .plus Dynamic-Offset Dynamic-iPATCH: 38; 6 .plus Dynamic-Offset
) )
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
<t>For the information shown in <xref target="im-example"/> and <xref targ et="dm-json"/>, a <t>For the information shown in <xref target="im-example"/> and <xref targ et="dm-json"/>, a
representation in CBOR <xref target="RFC8949"/> is given in <xref target="dm-cbo representation in Concise Binary Object Representation (CBOR) <xref target="RFC8
r"/>; again, 949"/> is given in <xref target="dm-cbor"/>; again,
several optimizations/improvements are possible.</t> several optimizations and improvements are possible.</t>
<figure anchor="dm-cbor"> <figure anchor="dm-cbor">
<name>An authorization instance encoded in CBOR (28 bytes)</name> <name>An Authorization Instance Encoded in CBOR (28 Bytes)</name>
<artwork type="hex-dump"><![CDATA[ <artwork><![CDATA[
83 # array(3) 83 # array(3)
82 # array(2) 82 # array(2)
67 # text(7) 67 # text(7)
2f732f74656d70 # "/s/temp" 2f732f74656d70 # "/s/temp"
01 # unsigned(1) 01 # unsigned(1)
82 # array(2) 82 # array(2)
66 # text(6) 66 # text(6)
2f612f6c6564 # "/a/led" 2f612f6c6564 # "/a/led"
05 # unsigned(5) 05 # unsigned(5)
82 # array(2) 82 # array(2)
65 # text(5) 65 # text(5)
2f64746c73 # "/dtls" 2f64746c73 # "/dtls"
02 # unsigned(2) 02 # unsigned(2)
]]></artwork> ]]></artwork>
</figure> </figure>
<t>Note that choosing 32 as Dynamic-Offset means that all future CoAP <t>Note that choosing 32 as Dynamic-Offset means that all future CoAP
methods that can be registered can be represented both as themselves methods that are registered can be represented both as themselves
and in the Dynamic-X variant, but only the dynamic forms of methods 1 and in the Dynamic-X variant, but only the dynamic forms of methods 1
to 21 are typically usable in a JSON form <xref target="RFC7493"/>.</t> to 21 are typically usable in a JSON form <xref target="RFC7493"/>.</t>
</section> </section>
<section anchor="media-types"> <section anchor="media-types">
<name>Media Types</name> <name>Media Types</name>
<t>This specification defines media types for the generic information <t>This specification defines media types for the generic information
model, expressed in JSON (<tt>application/aif+json</tt>) or in CBOR (<tt>applica tion/aif+cbor</tt>). These media types have model, expressed in JSON (<tt>application/aif+json</tt>) or in CBOR (<tt>applica tion/aif+cbor</tt>). These media types have
parameters for specifying <tt>Toid</tt> and <tt>Tperm</tt>; default values are t he parameters for specifying <tt>Toid</tt> and <tt>Tperm</tt>; default values are t he
values "URI-local-part" for <tt>Toid</tt> and "REST-method-set" for <tt>Tperm</t t>, as values "URI-local-part" for <tt>Toid</tt> and "REST-method-set" for <tt>Tperm</t t>, as
per <xref target="data-model"/> of the present specification.</t> per <xref target="data-model"/> of the present specification.</t>
<t>A specification that wants to use Generic AIF with different <tt>Toid</ tt> <t>A specification that wants to use generic AIF with different <tt>Toid</ tt>
and/or <tt>Tperm</tt> is expected to request these as media type parameters and/or <tt>Tperm</tt> is expected to request these as media type parameters
(<xref target="registries"/>) and register a corresponding Content-Format (<xref target="content-format"/>).</t> (<xref target="registries"/>) and register a corresponding Content-Format (<xref target="content-format"/>).</t>
</section> </section>
<section anchor="iana-considerations"> <section anchor="iana-considerations">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t><cref anchor="replace-xxxx">RFC Ed.: throughout this section, please re
place RFC <!-- [rfced] FYI: In the media type registration entries in Section 5.1, we
XXXX with the RFC number of this specification and remove this note.</cref></t updated "none" to "N/A" per Section 5.6 of RFC 6838, which states:
>
"N/A", written exactly that way, can be used in any field if desired
to emphasize the fact that it does not apply or that the question was
not omitted by accident. Do not use 'none' or other words that could
be mistaken for a response.
-->
<!-- [rfced] We note that spacing="compact" was used for the media type
registration entries in Section 5.1. However, spacing="normal" is more
typical for these (see examples in RFCS 8866 and 8801). When we updated
to spacing="normal", the two entries ran together; thus, we put each
entry in a new subsection (i.e., Section 5.1.1 for application/aif+cbor
and Section 5.1.2 for application/aif+json). Please review and let us
know any objections.
-->
<section anchor="media-types-1"> <section anchor="media-types-1">
<name>Media Types</name> <name>Media Types</name>
<t>IANA is requested to add the following Media-Types to the "Media Type s" registry.</t> <t>IANA has added the following media types to the "Media Types" registr y. The registration entries are in the following subsections.</t>
<table align="left"> <table align="left">
<name>New Media Types</name> <name>New Media Types</name>
<thead> <thead>
<tr> <tr>
<th align="left">Name</th> <th align="left">Name</th>
<th align="left">Template</th> <th align="left">Template</th>
<th align="left">Reference</th> <th align="left">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">aif+cbor</td> <td align="left">aif+cbor</td>
<td align="left">application/aif+cbor</td> <td align="left">application/aif+cbor</td>
<td align="left">RFC XXXX, <xref target="media-types"/></td> <td align="left">RFC 9237, <xref target="media-types"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">aif+json</td> <td align="left">aif+json</td>
<td align="left">application/aif+json</td> <td align="left">application/aif+json</td>
<td align="left">RFC XXXX, <xref target="media-types"/></td> <td align="left">RFC 9237, <xref target="media-types"/></td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>For <tt>application/aif+cbor</tt>:</t> <section anchor="media-type-template1">
<dl spacing="compact"> <name>application/aif+cbor</name>
<dl spacing="normal">
<dt>Type name:</dt> <dt>Type name:</dt>
<dd> <dd>
<t>application</t> <t>application</t>
</dd> </dd>
<dt>Subtype name:</dt> <dt>Subtype name:</dt>
<dd> <dd>
<t>aif+cbor</t> <t>aif+cbor</t>
</dd> </dd>
<dt>Required parameters:</dt> <dt>Required parameters:</dt>
<dd> <dd>
<t>N/A</t> <t>N/A</t>
</dd> </dd>
<dt>Optional parameters:</dt> <dt>Optional parameters:</dt>
<dd> <dd>
<ul spacing="normal"> <t><br/></t>
<li> <dl newline="true" spacing="normal">
<tt>Toid</tt>: the identifier for the object for which permissio <dt>
ns are <tt>Toid</tt>:</dt><dd>the identifier for the object for which p
ermissions are
supplied. supplied.
A value from the media-type parameter sub-registry for <tt>Toid</tt>. A value from the "Sub-Parameter Registry for application/aif+cbor and applicatio
Default value: "URI-local-part" (RFC XXXX).</li> n/aif+json" subregistry for <tt>Toid</tt>.
<li> Default value: "URI-local-part" (RFC 9237).</dd>
<tt>Tperm</tt>: the data type of a permission set for the object <dt>
<tt>Tperm</tt>:</dt><dd>the data type of a permission set for th
e object
identified via a <tt>Toid</tt>. identified via a <tt>Toid</tt>.
A value from the media-type parameter sub-registry for <tt>Tperm</tt>. A value from the "Sub-Parameter Registry for application/aif+cbor and applicatio
Default value: "REST-method-set" (RFC XXXX).</li> n/aif+json" subregistry for <tt>Tperm</tt>.
</ul> Default value: "REST-method-set" (RFC 9237).</dd>
</dl>
</dd> </dd>
<dt>Encoding considerations:</dt> <dt>Encoding considerations:</dt>
<dd> <dd>
<t>binary (CBOR)</t> <t>binary (CBOR)</t>
</dd> </dd>
<dt>Security considerations:</dt> <dt>Security considerations:</dt>
<dd> <dd>
<t><xref target="seccons"/> of RFC XXXX</t> <t><xref target="seccons"/> of RFC 9237</t>
</dd> </dd>
<dt>Interoperability considerations:</dt> <dt>Interoperability considerations:</dt>
<dd> <dd>
<t>none</t> <t>N/A</t>
</dd> </dd>
<dt>Published specification:</dt> <dt>Published specification:</dt>
<dd> <dd>
<t><xref target="media-types"/> of RFC XXXX</t> <t><xref target="media-types"/> of RFC 9237</t>
</dd> </dd>
<dt>Applications that use this media type:</dt> <dt>Applications that use this media type:</dt>
<dd> <dd>
<t>Applications that need to convey structured authorization data fo r <t>Applications that need to convey structured authorization data fo r
identified resources, conveying sets of permissions.</t> identified resources, conveying sets of permissions.</t>
</dd> </dd>
<dt>Fragment identifier considerations:</dt> <dt>Fragment identifier considerations:</dt>
<dd> <dd>
<t>The syntax and semantics of fragment identifiers is as specified for <t>The syntax and semantics of fragment identifiers is as specified for
"application/cbor". (At publication of RFC XXXX, there is no "application/cbor". (At publication of RFC 9237, there is no
fragment identification syntax defined for "application/cbor".)</t> fragment identification syntax defined for "application/cbor".)</t>
</dd> </dd>
<dt>Person &amp; email address to contact for further information:</dt > <dt>Person &amp; email address to contact for further information:</dt >
<dd> <dd>
<t>ACE WG mailing list (ace@ietf.org), <t>ACE WG mailing list (ace@ietf.org)
or IETF Applications and Real-Time Area (art@ietf.org)</t> or IETF Applications and Real-Time Area (art@ietf.org)</t>
</dd> </dd>
<dt>Intended usage:</dt> <dt>Intended usage:</dt>
<dd> <dd>
<t>COMMON</t> <t>COMMON</t>
</dd> </dd>
<dt>Restrictions on usage:</dt> <dt>Restrictions on usage:</dt>
<dd> <dd>
<t>none</t> <t>N/A</t>
</dd> </dd>
<dt>Author/Change controller:</dt> <dt>Author/Change controller:</dt>
<dd> <dd>
<t>IETF</t> <t>IETF</t>
</dd> </dd>
<dt>Provisional registration:</dt> <dt>Provisional registration:</dt>
<dd> <dd>
<t>no</t> <t>no</t>
</dd> </dd>
</dl> </dl>
<t>For <tt>application/aif+json</tt>:</t> </section>
<dl spacing="compact"> <section anchor="media-type-template2">
<name>application/aif+json</name>
<dl spacing="normal">
<dt>Type name:</dt> <dt>Type name:</dt>
<dd> <dd>
<t>application</t> <t>application</t>
</dd> </dd>
<dt>Subtype name:</dt> <dt>Subtype name:</dt>
<dd> <dd>
<t>aif+json</t> <t>aif+json</t>
</dd> </dd>
<dt>Required parameters:</dt> <dt>Required parameters:</dt>
<dd> <dd>
<t>N/A</t> <t>N/A</t>
</dd> </dd>
<dt>Optional parameters:</dt> <dt>Optional parameters:</dt>
<dd> <dd>
<ul spacing="normal"> <t><br/></t>
<li> <dl newline="true" spacing="normal">
<tt>Toid</tt>: the identifier for the object for which permissio <dt>
ns are <tt>Toid</tt>:</dt><dd>the identifier for the object for which p
ermissions are
supplied. supplied.
A value from the media-type parameter sub-registry for <tt>Toid</tt>. A value from the media-type parameter subregistry for <tt>Toid</tt>.
Default value: "URI-local-part" (RFC XXXX).</li> Default value: "URI-local-part" (RFC 9237).</dd>
<li> <dt>
<tt>Tperm</tt>: the data type of a permission set for the object <tt>Tperm</tt>:</dt><dd>the data type of a permission set for th
e object
identified via a <tt>Toid</tt>. identified via a <tt>Toid</tt>.
A value from the media-type parameter sub-registry for <tt>Tperm</tt>. A value from the media-type parameter subregistry for <tt>Tperm</tt>.
Default value: "REST-method-set" (RFC XXXX).</li> Default value: "REST-method-set" (RFC 9237).</dd>
</ul> </dl>
</dd> </dd>
<dt>Encoding considerations:</dt> <dt>Encoding considerations:</dt>
<dd> <dd>
<t>binary (JSON is UTF-8-encoded text)</t> <t>binary (JSON is UTF-8-encoded text)</t>
</dd> </dd>
<dt>Security considerations:</dt> <dt>Security considerations:</dt>
<dd> <dd>
<t><xref target="seccons"/> of RFC XXXX</t> <t><xref target="seccons"/> of RFC 9237</t>
</dd> </dd>
<dt>Interoperability considerations:</dt> <dt>Interoperability considerations:</dt>
<dd> <dd>
<t>none</t> <t>N/A</t>
</dd> </dd>
<dt>Published specification:</dt> <dt>Published specification:</dt>
<dd> <dd>
<t><xref target="media-types"/> of RFC XXXX</t> <t><xref target="media-types"/> of RFC 9237</t>
</dd> </dd>
<dt>Applications that use this media type:</dt> <dt>Applications that use this media type:</dt>
<dd> <dd>
<t>Applications that need to convey structured authorization data fo r <t>Applications that need to convey structured authorization data fo r
identified resources, conveying sets of permissions.</t> identified resources, conveying sets of permissions.</t>
</dd> </dd>
<dt>Fragment identifier considerations:</dt> <dt>Fragment identifier considerations:</dt>
<dd> <dd>
<t>The syntax and semantics of fragment identifiers is as specified for <t>The syntax and semantics of fragment identifiers is as specified for
"application/json". (At publication of RFC XXXX, there is no "application/json". (At publication of RFC 9237, there is no
fragment identification syntax defined for "application/json".)</t> fragment identification syntax defined for "application/json".)</t>
</dd> </dd>
<dt>Person &amp; email address to contact for further information:</dt > <dt>Person &amp; email address to contact for further information:</dt >
<dd> <dd>
<t>ACE WG mailing list (ace@ietf.org), <t>ACE WG mailing list (ace@ietf.org)
or IETF Applications and Real-Time Area (art@ietf.org)</t> or IETF Applications and Real-Time Area (art@ietf.org)</t>
</dd> </dd>
<dt>Intended usage:</dt> <dt>Intended usage:</dt>
<dd> <dd>
<t>COMMON</t> <t>COMMON</t>
</dd> </dd>
<dt>Restrictions on usage:</dt> <dt>Restrictions on usage:</dt>
<dd> <dd>
<t>none</t> <t>N/A</t>
</dd> </dd>
<dt>Author/Change controller:</dt> <dt>Author/Change controller:</dt>
<dd> <dd>
<t>IETF</t> <t>IETF</t>
</dd> </dd>
<dt>Provisional registration:</dt> <dt>Provisional registration:</dt>
<dd> <dd>
<t>no</t> <t>no</t>
</dd> </dd>
</dl> </dl>
</section> </section>
</section>
<section anchor="registries"> <section anchor="registries">
<name>Registries</name> <name>Registries</name>
<t>For the media types application/aif+cbor and application/aif+json, <t>For the media types application/aif+cbor and application/aif+json,
IANA is requested to create a sub-registry within IANA has created a subregistry within
<xref target="IANA.media-type-sub-parameters"/> for the two media-type parameter <xref target="IANA.media-type-sub-parameters"/> for the media-type parameters
s <tt>Toid</tt> and <tt>Tperm</tt>, populated with the following:</t>
<tt>Toid</tt> and <tt>Tperm</tt>, populated with:</t>
<table align="left"> <table align="left">
<name>New Media Type Parameters</name> <name>New Media Type Parameters</name>
<thead> <thead>
<tr> <tr>
<th align="left">Parameter</th> <th align="left">Parameter</th>
<th align="left">name</th> <th align="left">name</th>
<th align="left">Description/Specification</th> <th align="left">Description/Specification</th>
<th align="left">Reference</th> <th align="left">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">Toid</td> <td align="left">Toid</td>
<td align="left">URI-local-part</td> <td align="left">URI-local-part</td>
<td align="left">local-part of URI</td> <td align="left">local-part of URI</td>
<td align="left">RFC XXXX</td> <td align="left">RFC 9237</td>
</tr> </tr>
<tr> <tr>
<td align="left">Tperm</td> <td align="left">Tperm</td>
<td align="left">REST-method-set</td> <td align="left">REST-method-set</td>
<td align="left">set of REST methods represented</td> <td align="left">set of REST methods represented</td>
<td align="left">RFC XXXX</td> <td align="left">RFC 9237</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>The registration policy is Specification required <xref target="RFC81 <t>The registration policy is Specification Required <xref target="RFC81
26"/>. 26"/>.
The designated expert will engage with the submitter to ascertain the The designated expert will engage with the submitter to ascertain whether the
requirements of this document are addressed:</t> requirements of this document are addressed:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>The specifications for <tt>Toid</tt> and <tt>Tperm</tt> need to re alize the <li>The specifications for <tt>Toid</tt> and <tt>Tperm</tt> need to re alize the
general ideas of unambiguous object identifiers and permission lists general ideas of unambiguous object identifiers and permission lists
in the context where the AIF data item is intended to be used, and in the context where the AIF data item is intended to be used, and
their structure needs to be usable with the intended media types their structure needs to be usable with the intended media types
(application/aif+cbor and application/aif+json) as identified in the (application/aif+cbor and application/aif+json) as identified in the
specification.</li> specification.</li>
<li>The parameter names need to conform to <xref section="4.3" section <!-- [rfced] Please review "popular programming language APIs". Would updating
Format="of" target="RFC6838"/>, but preferably are in <xref target="KebabCase"/> to "APIs for popular programming language" make this phrase easier to read?
so they can
easily be translated into names used in popular programming Original:
* The parameter names need to conform to Section 4.3 of [RFC6838],
but preferably are in [KebabCase] so they can easily be translated
into names used in popular programming language APIs.
Perhaps:
* The parameter names need to conform to Section 4.3 of [RFC6838],
but preferably they are in [KebabCase] so they can easily be
translated into names used in APIs for popular programming
languages.
-->
<li>The parameter names need to conform to <xref section="4.3" sectionFormat="of
" target="RFC6838"/>, but preferably are in <xref target="KebabCase"/> so they c
an be
easily translated into names used in popular programming
language APIs.</li> language APIs.</li>
</ul> </ul>
<t>The designated experts will develop further criteria and guidelines a s <t>The designated experts will develop further criteria and guidelines a s
needed.</t> needed.</t>
</section> </section>
<section anchor="content-format"> <section anchor="content-format">
<name>Content-Format</name> <name>Content-Format</name>
<t>IANA is requested to register Content-Format numbers in the "CoAP <t>IANA has registered Content-Format numbers in the "CoAP
Content-Formats" sub-registry, within the "Constrained RESTful Content-Formats" subregistry, within the "Constrained RESTful
Environments (CoRE) Parameters" Registry <xref target="IANA.core-parameters"/>, Environments (CoRE) Parameters" registry <xref target="IANA.core-parameters"/>,
as as
follows:</t> follows:</t>
<table align="left"> <table align="left">
<name>New Content-Formats</name> <name>New Content-Formats</name>
<thead> <thead>
<tr> <tr>
<th align="left">Content-Type</th> <th align="left">Content-Type</th>
<th align="left">Content Coding</th> <th align="left">Content Coding</th>
<th align="left">ID</th> <th align="left">ID</th>
<th align="left">Reference</th> <th align="left">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">application/aif+cbor</td> <td align="left">application/aif+cbor</td>
<td align="left">-</td> <td align="left">-</td>
<td align="left">TBD1</td> <td align="left">290</td>
<td align="left">RFC XXXX</td> <td align="left">RFC 9237</td>
</tr> </tr>
<tr> <tr>
<td align="left">application/aif+json</td> <td align="left">application/aif+json</td>
<td align="left">-</td> <td align="left">-</td>
<td align="left">TBD2</td> <td align="left">291</td>
<td align="left">RFC XXXX</td> <td align="left">RFC 9237</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>// RFC Ed.: please replace TBD1 and TBD2 with assigned IDs and remove
this note.</t> <!--[rfced] In Section 5.3, we notice that the headers for Table 5 are
different than the headers in the "CoAP Content-Formats”
subregistry, and this variance is pointed out in the text below.
Should the headers in Table 5 perhaps match the current headers
in the registry? Please clarify why different header names were
used.
Original:
In the registry as defined by Section 12.3 of [RFC7252] at the time
of writing, the column "Content-Type" is called "Media type" and the
column "Content Coding" is called "Encoding”.
-->
<t>In the registry as defined by <xref section="12.3" sectionFormat="of" target="RFC7252"/> at the time of <t>In the registry as defined by <xref section="12.3" sectionFormat="of" target="RFC7252"/> at the time of
writing, the column "Content-Type" is called "Media type" and the writing, the column "Content-Type" is called "Media type" and the
column "Content Coding" is called "Encoding".</t> column "Content Coding" is called "Encoding".</t>
<t>Note that applications that register <tt>Toid</tt> and <tt>Tperm</tt> values are <t>Note that applications that register <tt>Toid</tt> and <tt>Tperm</tt> values are
encouraged to also register Content-Formats for the relevant encouraged to also register Content-Formats for the relevant
combinations.</t> combinations.</t>
</section> </section>
</section> </section>
<section anchor="seccons"> <section anchor="seccons">
<name>Security Considerations</name> <name>Security Considerations</name>
<!-- [rfced] May we update this sentence as follows for clarity?
Original:
The security considerations of [RFC7252] apply when AIF is used with
CoAP, and, if complex formats such as URIs are used for Toid or
Tperm, specifically Section 11.1 of [RFC7252].
Perhaps:
The security considerations of [RFC7252] apply when AIF is used with
CoAP; Section 11.1 of [RFC7252] specifically applies if complex
formats such as URIs are used for Toid or Tperm.
-->
<t>The security considerations of <xref target="RFC7252"/> apply when AIF is used with <t>The security considerations of <xref target="RFC7252"/> apply when AIF is used with
CoAP, and, if complex formats such as URIs are used for <tt>Toid</tt> or CoAP, and, if complex formats such as URIs are used for <tt>Toid</tt> or
<tt>Tperm</tt>, specifically <xref section="11.1" sectionFormat="of" target="RFC 7252"/>. <tt>Tperm</tt>, specifically <xref section="11.1" sectionFormat="of" target="RFC 7252"/>.
Some wider issues are discussed in <xref target="RFC8576"/>.</t> Some wider issues are discussed in <xref target="RFC8576"/>.</t>
<t>When applying these formats, the referencing specification needs to be <t>When applying these formats, the referencing specification needs to be
careful to:</t> careful to ensure that:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>ensure that the cryptographic armor employed around this format <li>the cryptographic armor employed around this format
fulfills the referencing specification's security objectives, and that the armor fulfills the referencing specification's security objectives and that the armor
or some or some
additional information included in it with the AIF data item additional information included in it with the AIF data item
(1) unambiguously identifies the subject to which the authorizations (1) unambiguously identifies the subject to which the authorizations
shall apply and (2) provides any context information needed to derive the shall apply and (2) provides any context information needed to derive the
identity of the object to which authorization is being granted identity of the object to which authorization is being granted
from the object identifiers (such as, for from the object identifiers (such as, for
the data models defined in the present specification, the scheme and the data models defined in the present specification, the scheme and
authority information that is used to construct the full URI), and</li> authority information that is used to construct the full URI), and</li>
<li>ensure that the types used for <tt>Toid</tt> and <tt>Tperm</tt> prov ide the <li>the types used for <tt>Toid</tt> and <tt>Tperm</tt> provide the
appropriate granularity and precision so that application requirements on the appropriate granularity and precision so that application requirements on the
precision of the authorization information are fulfilled, and that precision of the authorization information are fulfilled and that
all parties have the same understanding of each Toid/Tperm pair in all parties have the same understanding of each Toid/Tperm pair in
terms of specified objects (resources) and operations on those.</li> terms of specified objects (resources) and operations on those.</li>
</ul> </ul>
<t>For the data formats, the security considerations of <xref target="RFC8 259"/> and <t>For the data formats, the security considerations of <xref target="RFC8 259"/> and
<xref target="RFC8949"/> apply.</t> <xref target="RFC8949"/> apply.</t>
<t>A plain implementation of AIF might implement just the basic REST <t>A plain implementation of AIF might implement just the basic REST
model as per <xref target="rest-model"/>. If it receives authorizations that model as per <xref target="rest-model"/>. If it receives authorizations that
include permissions that use the REST-specific Model With Dynamic include permissions that use the REST-Specific Model with Dynamic
Resource Creation <xref target="ext-rest-model"/>, it needs to either Resource Creation (<xref target="ext-rest-model"/>), it needs to either
reject the AIF data item entirely or act only on the reject the AIF data item entirely or act only on the
permissions that it does understand. permissions that it does understand.
In other words, the semantics underlying an allow-list as discussed In other words, the semantics underlying an allow-list as discussed
above need to hold here as well.</t> above need to hold here as well.</t>
<t>An implementation of the REST-specific Model With Dynamic Resource <t>An implementation of the REST-Specific Model with Dynamic Resource
Creation <xref target="ext-rest-model"/> needs to carefully keep track of the Creation (<xref target="ext-rest-model"/>) needs to carefully keep track of the
dynamically created objects and the subjects to which the Dynamic-X dynamically created objects and the subjects to which the Dynamic-X
permissions apply -- both on the server side to enforce the permissions permissions apply -- both on the server side to enforce the permissions
and on the client side to know which permissions are available.</t> and on the client side to know which permissions are available.</t>
</section> </section>
</middle> </middle>
<back> <back>
<references> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<reference anchor="RFC3986" target="https://www.rfc-editor.org/info/rfc3
986">
<front>
<title>Uniform Resource Identifier (URI): Generic Syntax</title>
<author fullname="T. Berners-Lee" initials="T." surname="Berners-Lee
">
<organization/>
</author>
<author fullname="R. Fielding" initials="R." surname="Fielding">
<organization/>
</author>
<author fullname="L. Masinter" initials="L." surname="Masinter">
<organization/>
</author>
<date month="January" year="2005"/>
<abstract>
<t>A Uniform Resource Identifier (URI) is a compact sequence of ch
aracters that identifies an abstract or physical resource. This specification d
efines the generic URI syntax and a process for resolving URI references that mi
ght be in relative form, along with guidelines and security considerations for t
he use of URIs on the Internet. The URI syntax defines a grammar that is a supe
rset of all valid URIs, allowing an implementation to parse the common component
s of a URI reference without knowing the scheme-specific requirements of every p
ossible identifier. This specification does not define a generative grammar for
URIs; that task is performed by the individual specifications of each URI schem
e. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="STD" value="66"/>
<seriesInfo name="RFC" value="3986"/>
<seriesInfo name="DOI" value="10.17487/RFC3986"/>
</reference>
<reference anchor="RFC7252" target="https://www.rfc-editor.org/info/rfc7
252">
<front>
<title>The Constrained Application Protocol (CoAP)</title>
<author fullname="Z. Shelby" initials="Z." surname="Shelby">
<organization/>
</author>
<author fullname="K. Hartke" initials="K." surname="Hartke">
<organization/>
</author>
<author fullname="C. Bormann" initials="C." surname="Bormann">
<organization/>
</author>
<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 am
ounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wir
eless 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-
machine (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 d
esigned to easily interface with HTTP for integration with the Web while meeting
specialized requirements such as multicast support, very low overhead, and simp
licity for constrained environments.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7252"/>
<seriesInfo name="DOI" value="10.17487/RFC7252"/>
</reference>
<reference anchor="I-D.ietf-httpbis-semantics" target="https://www.ietf.
org/archive/id/draft-ietf-httpbis-semantics-19.txt">
<front>
<title>HTTP Semantics</title>
<author fullname="Roy T. Fielding">
<organization>Adobe</organization>
</author>
<author fullname="Mark Nottingham">
<organization>Fastly</organization>
</author>
<author fullname="Julian Reschke">
<organization>greenbytes GmbH</organization>
</author>
<date day="12" month="September" year="2021"/>
<abstract>
<t> The Hypertext Transfer Protocol (HTTP) is a stateless applic
ation-
level protocol for distributed, collaborative, hypertext information
systems. This document describes the overall architecture of HTTP,
establishes common terminology, and defines aspects of the protocol
that are shared by all versions. In this definition are core
protocol elements, extensibility mechanisms, and the "http" and
"https" Uniform Resource Identifier (URI) schemes.
This document updates RFC 3864 and obsoletes RFC 2818, RFC 7231, RFC <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
7232, RFC 7233, RFC 7235, RFC 7538, RFC 7615, RFC 7694, and portions C.3986.xml"/>
of RFC 7230. <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7252.xml"/>
<!-- [I-D.ietf-httpbis-semantics] in AUTH48 state as RFC 9110 as of 4/22/2022 --
>
<reference anchor='RFC9110' target="https://www.rfc-editor.org/info/rfc9110">
<front>
<title>HTTP Semantics</title>
<author initials='R' surname='Fielding' fullname='Roy Fielding' role='editor'>
<organization />
</author>
<author initials='M' surname='Nottingham' fullname='Mark Nottingham' role='edito
r'>
<organization />
</author>
<author initials='J' surname='Reschke' fullname='Julian Reschke' role='editor'>
<organization />
</author>
<date year='2022' month='April' />
</front>
<seriesInfo name="RFC" value="9110"/>
<seriesInfo name="DOI" value="10.17487/RFC9110"/>
</reference>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8126.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.6838.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8610.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.9165.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8174.xml"/>
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-semantics-
19"/>
</reference>
<reference anchor="RFC8126" target="https://www.rfc-editor.org/info/rfc8
126">
<front>
<title>Guidelines for Writing an IANA Considerations Section in RFCs
</title>
<author fullname="M. Cotton" initials="M." surname="Cotton">
<organization/>
</author>
<author fullname="B. Leiba" initials="B." surname="Leiba">
<organization/>
</author>
<author fullname="T. Narten" initials="T." surname="Narten">
<organization/>
</author>
<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 th
ese fields do not have conflicting uses and to promote interoperability, their a
llocations 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 documen
t defines a framework for the documentation of these guidelines by specification
authors, in order to assure that the provided guidance for the IANA Considerati
ons is clear and addresses the various issues that are likely in the operation o
f 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="RFC6838" target="https://www.rfc-editor.org/info/rfc6
838">
<front>
<title>Media Type Specifications and Registration Procedures</title>
<author fullname="N. Freed" initials="N." surname="Freed">
<organization/>
</author>
<author fullname="J. Klensin" initials="J." surname="Klensin">
<organization/>
</author>
<author fullname="T. Hansen" initials="T." surname="Hansen">
<organization/>
</author>
<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. Th
is 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="RFC8610" target="https://www.rfc-editor.org/info/rfc8
610">
<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">
<organization/>
</author>
<author fullname="C. Vigano" initials="C." surname="Vigano">
<organization/>
</author>
<author fullname="C. Bormann" initials="C." surname="Bormann">
<organization/>
</author>
<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 goa
l is to provide an easy and unambiguous way to express structures for protocol m
essages 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="RFC9165" target="https://www.rfc-editor.org/info/rfc9
165">
<front>
<title>Additional Control Operators for the Concise Data Definition
Language (CDDL)</title>
<author fullname="C. Bormann" initials="C." surname="Bormann">
<organization/>
</author>
<date month="December" year="2021"/>
<abstract>
<t>The Concise Data Definition Language (CDDL), standardized in RF
C 8610, provides "control operators" as its main language extension point.</t>
<t>The present document defines a number of control operators that
were not yet ready at the time RFC 8610 was completed: , , and for the constru
ction of constants; / for including ABNF (RFC 5234 and RFC 7405) in CDDL specifi
cations; and for indicating the use of a non-basic feature in an instance.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9165"/>
<seriesInfo name="DOI" value="10.17487/RFC9165"/>
</reference>
<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit
le>
<author fullname="S. Bradner" initials="S." surname="Bradner">
<organization/>
</author>
<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.
This document defines these words as they should be interpreted in IETF document
s. This document specifies an Internet Best Current Practices for the Internet
Community, 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" target="https://www.rfc-editor.org/info/rfc8
174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<author fullname="B. Leiba" initials="B." surname="Leiba">
<organization/>
</author>
<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 tha
t 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="RFC4949" target="https://www.rfc-editor.org/info/rfc4
949">
<front>
<title>Internet Security Glossary, Version 2</title>
<author fullname="R. Shirey" initials="R." surname="Shirey">
<organization/>
</author>
<date month="August" year="2007"/>
<abstract>
<t>This Glossary provides definitions, abbreviations, and explanat
ions of terminology for information system security. The 334 pages of entries of
fer recommendations to improve the comprehensibility of written material that is
generated in the Internet Standards Process (RFC 2026). The recommendations fol
low the principles that such writing should (a) use the same term or definition
whenever the same concept is mentioned; (b) use terms in their plainest, diction
ary sense; (c) use terms that are already well-established in open publications;
and (d) avoid terms that either favor a particular vendor or favor a particular
technology or mechanism over other, competing techniques that already exist or
could be developed. This memo provides information for the Internet community.<
/t>
</abstract>
</front>
<seriesInfo name="FYI" value="36"/>
<seriesInfo name="RFC" value="4949"/>
<seriesInfo name="DOI" value="10.17487/RFC4949"/>
</reference>
<reference anchor="RFC8259" target="https://www.rfc-editor.org/info/rfc8
259">
<front>
<title>The JavaScript Object Notation (JSON) Data Interchange Format
</title>
<author fullname="T. Bray" initials="T." role="editor" surname="Bray
">
<organization/>
</author>
<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 ECMAScri
pt Programming Language Standard. JSON defines a small set of formatting rules
for the portable representation of structured data.</t>
<t>This document removes inconsistencies with other specifications
of JSON, repairs specification errors, and offers experience-based 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="I-D.ietf-ace-oauth-authz" target="https://www.ietf.or
g/archive/id/draft-ietf-ace-oauth-authz-46.txt">
<front>
<title>Authentication and Authorization for Constrained Environments
(ACE) using the OAuth 2.0 Framework (ACE-OAuth)</title>
<author fullname="Ludwig Seitz">
<organization>Combitech</organization>
</author>
<author fullname="Goeran Selander">
<organization>Ericsson</organization>
</author>
<author fullname="Erik Wahlstroem">
</author>
<author fullname="Samuel Erdtman">
<organization>Spotify AB</organization>
</author>
<author fullname="Hannes Tschofenig">
<organization>Arm Ltd.</organization>
</author>
<date day="8" month="November" year="2021"/>
<abstract>
<t> This specification defines a framework for authentication an
d
authorization in Internet of Things (IoT) environments called ACE-
OAuth. The framework is based on a set of building blocks including
OAuth 2.0 and the Constrained Application Protocol (CoAP), thus
transforming a well-known and widely used authorization solution into
a form suitable for IoT devices. Existing specifications are used
where possible, but extensions are added and profiles are defined to
better serve the IoT use cases.
</t> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
</abstract> C.4949.xml"/>
</front> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
<seriesInfo name="Internet-Draft" value="draft-ietf-ace-oauth-authz-46 C.8259.xml"/>
"/>
</reference> <!-- [I-D.ietf-ace-oauth-authz] in AUTH48-DONE state as RFC 9200 as of 4/22/2022
<reference anchor="RFC7493" target="https://www.rfc-editor.org/info/rfc7 -->
493">
<front> <reference anchor='RFC9200' target="https://www.rfc-editor.org/info/rfc9200">
<title>The I-JSON Message Format</title> <front>
<author fullname="T. Bray" initials="T." role="editor" surname="Bray <title>Authentication and Authorization for Constrained Environments Using the O
"> Auth 2.0 Framework (ACE-OAuth)</title>
<organization/> <author initials='L' surname='Seitz' fullname='Ludwig Seitz'>
</author> <organization />
<date month="March" year="2015"/> </author>
<abstract> <author initials='G' surname='Selander' fullname='Goeran Selander'>
<t>I-JSON (short for "Internet JSON") is a restricted profile of J <organization />
SON designed to maximize interoperability and increase confidence that software </author>
can process it successfully with predictable results.</t> <author initials='E' surname='Wahlstroem' fullname='Erik Wahlstroem'>
</abstract> <organization />
</front> </author>
<seriesInfo name="RFC" value="7493"/> <author initials='S' surname='Erdtman' fullname='Samuel Erdtman'>
<seriesInfo name="DOI" value="10.17487/RFC7493"/> <organization />
</reference> </author>
<reference anchor="RFC8949" target="https://www.rfc-editor.org/info/rfc8 <author initials='H' surname='Tschofenig' fullname='Hannes Tschofenig'>
949"> <organization />
<front> </author>
<title>Concise Binary Object Representation (CBOR)</title> <date year='2022' month='April' />
<author fullname="C. Bormann" initials="C." surname="Bormann"> </front>
<organization/> <seriesInfo name="RFC" value="9200"/>
</author> <seriesInfo name="DOI" value="10.17487/RFC9200"/>
<author fullname="P. Hoffman" initials="P." surname="Hoffman"> </reference>
<organization/>
</author> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
<date month="December" year="2020"/> C.7493.xml"/>
<abstract> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
<t>The Concise Binary Object Representation (CBOR) is a data forma C.8949.xml"/>
t whose design goals include the possibility of extremely small code size, fairl <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
y small message size, and extensibility without the need for version negotiation C.8132.xml"/>
. These design goals make it different from earlier binary serializations such a <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
s ASN.1 and MessagePack.</t> C.8576.xml"/>
<t>This document obsoletes RFC 7049, providing editorial improveme <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
nts, new details, and errata fixes while keeping full compatibility with the int C.6570.xml"/>
erchange format of RFC 7049. It does not create a new version of the format.</t <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
> C.7228.xml"/>
</abstract>
</front>
<seriesInfo name="STD" value="94"/>
<seriesInfo name="RFC" value="8949"/>
<seriesInfo name="DOI" value="10.17487/RFC8949"/>
</reference>
<reference anchor="RFC8132" target="https://www.rfc-editor.org/info/rfc8
132">
<front>
<title>PATCH and FETCH Methods for the Constrained Application Proto
col (CoAP)</title>
<author fullname="P. van der Stok" initials="P." surname="van der St
ok">
<organization/>
</author>
<author fullname="C. Bormann" initials="C." surname="Bormann">
<organization/>
</author>
<author fullname="A. Sehgal" initials="A." surname="Sehgal">
<organization/>
</author>
<date month="April" year="2017"/>
<abstract>
<t>The methods defined in RFC 7252 for the Constrained Application
Protocol (CoAP) only allow access to a complete resource, not to parts of a res
ource. In case of resources with larger or complex data, or in situations where
resource continuity is required, replacing or requesting the whole resource is
undesirable. Several applications using CoAP need to access parts of the resour
ces.</t>
<t>This specification defines the new CoAP methods, FETCH, PATCH,
and iPATCH, which are used to access and update parts of a resource.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8132"/>
<seriesInfo name="DOI" value="10.17487/RFC8132"/>
</reference>
<reference anchor="RFC8576" target="https://www.rfc-editor.org/info/rfc8
576">
<front>
<title>Internet of Things (IoT) Security: State of the Art and Chall
enges</title>
<author fullname="O. Garcia-Morchon" initials="O." surname="Garcia-M
orchon">
<organization/>
</author>
<author fullname="S. Kumar" initials="S." surname="Kumar">
<organization/>
</author>
<author fullname="M. Sethi" initials="M." surname="Sethi">
<organization/>
</author>
<date month="April" year="2019"/>
<abstract>
<t>The Internet of Things (IoT) concept refers to the usage of sta
ndard Internet protocols to allow for human-to-thing and thing-to-thing communic
ation. The security needs for IoT systems are well recognized, and many standar
dization steps to provide security have been taken -- for example, the specifica
tion of the Constrained Application Protocol (CoAP) secured with Datagram Transp
ort Layer Security (DTLS). However, security challenges still exist, not only b
ecause there are some use cases that lack a suitable solution, but also because
many IoT devices and systems have been designed and deployed with very limited s
ecurity capabilities. In this document, we first discuss the various stages in
the lifecycle of a thing. Next, we document the security threats to a thing and
the challenges that one might face to protect against these threats. Lastly, we
discuss the next steps needed to facilitate the deployment of secure IoT system
s. This document can be used by implementers and authors of IoT specifications
as a reference for details about security considerations while documenting their
specific security challenges, threat models, and mitigations.</t>
<t>This document is a product of the IRTF Thing-to-Thing Research
Group (T2TRG).</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8576"/>
<seriesInfo name="DOI" value="10.17487/RFC8576"/>
</reference>
<reference anchor="RFC6570" target="https://www.rfc-editor.org/info/rfc6
570">
<front>
<title>URI Template</title>
<author fullname="J. Gregorio" initials="J." surname="Gregorio">
<organization/>
</author>
<author fullname="R. Fielding" initials="R." surname="Fielding">
<organization/>
</author>
<author fullname="M. Hadley" initials="M." surname="Hadley">
<organization/>
</author>
<author fullname="M. Nottingham" initials="M." surname="Nottingham">
<organization/>
</author>
<author fullname="D. Orchard" initials="D." surname="Orchard">
<organization/>
</author>
<date month="March" year="2012"/>
<abstract>
<t>A URI Template is a compact sequence of characters for describi
ng a range of Uniform Resource Identifiers through variable expansion. This spec
ification defines the URI Template syntax and the process for expanding a URI Te
mplate into a URI reference, along with guidelines for the use of URI Templates
on the Internet. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6570"/>
<seriesInfo name="DOI" value="10.17487/RFC6570"/>
</reference>
<reference anchor="RFC7228" target="https://www.rfc-editor.org/info/rfc7
228">
<front>
<title>Terminology for Constrained-Node Networks</title>
<author fullname="C. Bormann" initials="C." surname="Bormann">
<organization/>
</author>
<author fullname="M. Ersue" initials="M." surname="Ersue">
<organization/>
</author>
<author fullname="A. Keranen" initials="A." surname="Keranen">
<organization/>
</author>
<date month="May" year="2014"/>
<abstract>
<t>The Internet Protocol Suite is increasingly used on small devic
es with severe constraints on power, memory, and processing resources, creating
constrained-node networks. This document provides a number of basic terms that
have been useful in the standardization work for constrained-node networks.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7228"/>
<seriesInfo name="DOI" value="10.17487/RFC7228"/>
</reference>
<reference anchor="IANA.core-parameters" target="https://www.iana.org/as signments/core-parameters"> <reference anchor="IANA.core-parameters" target="https://www.iana.org/as signments/core-parameters">
<front> <front>
<title>Constrained RESTful Environments (CoRE) Parameters</title> <title>Constrained RESTful Environments (CoRE) Parameters</title>
<author> <author>
<organization>IANA</organization> <organization>IANA</organization>
</author> </author>
<date/> <date/>
</front> </front>
</reference> </reference>
<reference anchor="IANA.media-type-sub-parameters" target="https://www.i ana.org/assignments/media-type-sub-parameters"> <reference anchor="IANA.media-type-sub-parameters" target="https://www.i ana.org/assignments/media-type-sub-parameters">
<front> <front>
<title>MIME Media Type Sub-Parameter Registries</title> <title>MIME Media Type Sub-Parameter Registries</title>
<author> <author>
<organization>IANA</organization> <organization>IANA</organization>
</author> </author>
<date/> <date/>
</front> </front>
</reference> </reference>
<reference anchor="KebabCase" target="http://wiki.c2.com/?KebabCase"> <reference anchor="KebabCase" target="http://wiki.c2.com/?KebabCase">
<front> <front>
<title>KebabCase</title> <title>Kebab Case</title>
<author> <author>
<organization/> <organization/>
</author> </author>
<date year="2014" month="August" day="29"/> <date year="2014" month="August" day="29"/>
</front> </front>
</reference> </reference>
<reference anchor="RFC8881" target="https://www.rfc-editor.org/info/rfc8
881"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8881.
<front> xml"/>
<title>Network File System (NFS) Version 4 Minor Version 1 Protocol<
/title>
<author fullname="D. Noveck" initials="D." role="editor" surname="No
veck">
<organization/>
</author>
<author fullname="C. Lever" initials="C." surname="Lever">
<organization/>
</author>
<date month="August" year="2020"/>
<abstract>
<t>This document describes the Network File System (NFS) version 4
minor version 1, including features retained from the base protocol (NFS versio
n 4 minor version 0, which is specified in RFC 7530) and protocol extensions mad
e subsequently. The later minor version has no dependencies on NFS version 4 mi
nor version 0, and is considered a separate protocol. </t>
<t>This document obsoletes RFC 5661. It substantially revises the
treatment of features relating to multi-server namespace, superseding the descr
iption of those features appearing in RFC 5661.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8881"/>
<seriesInfo name="DOI" value="10.17487/RFC8881"/>
</reference>
</references> </references>
</references> </references>
<section numbered="false" anchor="acknowledgements"> <section numbered="false" anchor="acknowledgements">
<name>Acknowledgements</name> <name>Acknowledgements</name>
<t><contact fullname="Jim Schaad"/>, <t><contact fullname="Jim Schaad"/>,
<contact fullname="Francesca Palombini"/>, <contact fullname="Francesca Palombini"/>,
<contact fullname="Olaf Bergmann"/>, <contact fullname="Olaf Bergmann"/>,
<contact fullname="Marco Tiloca"/>, <contact fullname="Marco Tiloca"/>,
and and
<contact fullname="Christian Amsüss"/> <contact fullname="Christian Amsüss"/>
provided comments that shaped the provided comments that shaped the
direction of this document. direction of this document.
<contact fullname="Alexey Melnikov"/> pointed out that there were gaps in the me dia <contact fullname="Alexey Melnikov"/> pointed out that there were gaps in the me dia
type specifications, and <contact fullname="Loganaden Velvindron"/> provided a s hepherd type specifications, and <contact fullname="Loganaden Velvindron"/> provided a s hepherd
review with further comments. review with further comments.
Many thanks also to the IESG reviewers, which provided several small Many thanks also to the IESG reviewers, who provided several small
but significant observations. but significant observations.
<contact fullname="Benjamin Kaduk"/> provided an extensive review as responsible <contact fullname="Benjamin Kaduk"/> provided an extensive review as Responsible
Area Area
Director, and indeed is responsible for much improvement in the document.</t> Director and indeed is responsible for much improvement in the document.</t>
</section> </section>
</back> </back>
<!-- ##markdown-source: <!-- [rfced] Terminology
H4sIANOHMGIAA+1ca3IbSXL+X6eoxUSsQS0AiiD1gnZmlyKpGe3qtSLl2fXE
2GqgC0CPGt1wP0hhKG74ED6Af/gY/uW9iU/i/DKrqqsboDRjOxzh8DJiRkCj
HllZmV8+KquHw6Gqkio1E32c6eO6WuZF8mNUJXmmn2XzvFjJ56f8SfePnz3d
0/RYH5+cqWg6LczlBJ81/aDifJZFKxoqLqJ5NUxMNR9GMzOMkvkwjSpTVuoL
HdOHiR7fHY+Hd8fDgyOlyirK4n+I0jyjH6qiNkol64I/ltX47t1Hd8cqKkw0
IYoqU2SmUlcLmfXbvHifZAv9dZHXa/X+qmkyPAUNahZVE11WsZrlWWmysi7t
FGU9XSVlSWurNmua99nZxVOl1slEaV3ls4nemFI+xmZdLSf6iL6VeVEVZl66
X8vNqvmqLk1WG/RfgJoJc9NkVTITFtIiOwwGH0+IrqqIkszE+iy7TIo8W1Gn
UveJc3s02CpK0ommL78FP0d5scAMSbWspxM9i6b5vmWxUhGPDgrwN7T/ap1k
ROLJSD/BJmaZfy6bdRIVZWWyrV9ppol+myWXpiiT6i//WuknhSHa9MXfPfON
iHZjiMWv87KaR7OlPjy8e3R01/8+S6rNxHZsHuYxzXs6HD88vPcoeFpnVUGt
vzYgZON/WC9ZMn519Gh4ND4Yjg8eDu8fPhof+AZGeARm/Lb6MWEeqUxk95J3
5M3Tk8NHD+9PdF0k8vXB+N6YuuTRmr4/G56OWFqXVbWeJuWwpCGxc8Q3PGq+
S+eHB2MaK4myCGIlz+4/PHw40SsTJ9EQIjUszMK2vn9wl6aK41S+Pzq4f0++
r9Oa5CZxeuZpPXp09GiiF2leugnH9+jBD2WehdRi43Ns+hD/+5GlRB6QnrWb
xVVaDiMrfdBQ/j4zWw3zcpYXZrgu8nkCVMD3aM1NhW9Hjw5p6UNLC2hjYmfT
vHDMOSTOrqNqtrQP7j0gbpVmFjDr3oO7vBnDyqzWjA1uW8bERVLhFRZ6/PJ4
JOREBckqPS4n7nnAadLlTovfm2k0PYlKI8pQRcUCUoq9nOzvXyXvk9FsTEOv
9n/jm0pLwcL2QwdZB0fDuw+H40dKDYdDHU2huLNKqRAoSQbrSl8tE9IFKH+V
mFITemnP/JhARa9NgT7UMKpUTt+4d6lpBOkLXlHvmrEgn+ucsKRoRkxoUD0r
6lkSpYRtqzWpSFahIe1cTI8JFKNM56S8UZoSUJGKr3RFs6Er7UVdmJEG+lya
DTVW68LMkrIhU1aTBCujfqZcG8yYbmjuBMiWUhO9TBbLdAP4yaktLVCmK/UV
wZROwXyd1aspbQ4odIsY6LKmlUYl0WVUzyE3mlwsiaayN1KKPhG9mHbugJRW
eJnEYKtemMwUyaxF54rQJWW0lWf4RxWGFlhiZmKMTHvbQgeg6MoQ10DZVa4v
o4JUvSoVERZ5WoCqFUBBBqDfmLvNnLomdjIH3pydX2iaPq+LGQk60U7d5gkx
arrRb988g7Isaa3f/X1CCJgfDL+ftOzCqblMZlgvc2rD4kSDx+A9PdC7WKcz
Y2KWXt5sgmG0zouYpIjkT0TOkJgVtPEVbSgYRjy6hBiRZaTxR9z9VWZ0QvJV
YLHapEDySpbrJIkHL2X9saXVkuYtNlsURx0TBzKmJHDT1OBjTGyNjZX+QCMK
8481eQ7Unuc0K1nUMq/TGP2hKNSxoAaNig38DFE5M0Q6k0PkQdLQv7371M5O
w0T72XWcg+3rNfGH2uA3Uvg6SnkMR1mBjYkaY0/TyxzE0VvIEG12vOJNXUXv
TTgsqwp2minKXDOSEJPFJm7EZQxxYTUh/6vm3YnNPEEPEXQrkwO/+J/m5sn2
0yfsrYxIDCfKebmieqT/JKU18YQJpa4zQp2pFU8ogbfkcTKf0y4RdeCn1eUS
TBJmlbfrFvEtzQthZFuXmMdgEO2YdedKETUWv9WARpqldcxan6+MYEfpnK94
Qy4QUIwBzTB2+bFHAvOrhAy1AchXjKygSH0Z/IV6S3hFYlJEWTnn/QXlgWBu
g+q8yFcA6nYLYlq0MIXqO4CkFuTuDl9h5zrbd24KAnl9fd24Azc3eyxzVsAI
0NhEkOhqj4PeA12JSYCgQqoaoaK1gKlZnuaLDVjh/iwor8wqxz6XbK5LWcpJ
fvwatMBpuLnx2+MB6tzhxddwbqJig8bs6NzcPJbeNLSTHoW+5gM5CFlU5dTY
fIjIXRAoTCqxgos8p8ZJteVOW9hkI2IIMaK1gU6RNY90Y1QERk9OT58z3bTZ
RLf9BP/s5mYUMuK2WUIlofFoAHAFnXn296S6V4S+pe69eHt+0RvIv/rlK/78
5uwPb5+9OTvF5/Nvjp8/9x+UbXH+zau3z0+bT03Pk1cvXpy9PJXO9FS3Hqne
i+M/0S/Yid6r1xfPXr08ft4TeA4hg5GGARkIU5CUQBmiUpGhJVs/lWU9OXn9
7/9ycETL+wU5a+ODg0fMrF+w2/fgiL5cEQrKbHlGWiVfgVyK1N5EBUaBRzKL
1kkVpSVbW0LzK3IjCB6IXXe+A2cI0349na0Pjr6yD7Dg1kPHs9ZD5tn2k63O
wsQdj3ZM47nZet7hdJve4z+1vju+Bw9FLCAjujfdVAZbxOF0wihEjkHvCT1z
ykBcS8gkZPmVnlFUTH5WsVEIaI1Fzk2WZ5sVS2cvn1WmgvMUQvsLuEUt4LLo
1YIT8VUttqdQOOAFKKiWFNUulgKjrEMe+UvF0I+es2KzrvJFEa2XFlfF14x1
nyhjZFwlVSUriuyP+irakLm5sA6FWN6kpIWWYvZ2+Hc1GcEihesq+B9t0jyC
jyC0MIF9Yk2+XuelmA60a9FHFK+IqogWRvKaVHsOKly0Z12OT+B3oPLQJ9XW
Jzb1c6D3HeJFfjVMk7K6M1HkZRWbCq6QwEYGFKLoN0ktqgHzEoqd4ZehI9v7
p+Ag1loXWFPZOGGhe8zaFrInmhE8lfCTCNdTYZ+6SkgHpy0SbTtaWJF8GFhH
bEFBKcuXOJeBmWV8Ngj5iZgygRdHRmaaZN4fpl719AfaT4YDRCP8baS+Ncye
OfGqdBsIP0OQGYFKzsJBv9GoBcm89SZbJDrryA2W2Oo50hhTQ/+D6AG+ADPR
NElhccD7vQF75BSiISFELlnmBMORCgWSpeNpQ1EChC9rbMQxx17IJ5GjlsG+
gnjGqGnjmEeQau90+vFFolTUVjqoObki02RR53VJux7ECH0zWowYJinGrbxI
QnTVlui6gEiUhNpaHnX4IJaTP2FXo4QjMyUb1ExOT/uYj4Js/e4iT+J3e7s8
rrARHlOrcMm8N7yBdoJ+uRcskCj/85//LPkRYuTwa1nCrzHfQPOAX+kv9Xd3
9HfBo++/Ry91PdFf0JqjZC6h+5e9U2hk4mTQDoYd6t0AEEMvk3dXONUPQlF4
26R2Zd5yEVTLXu6Jmm0xTPcdn1jDnEiqiKD+QwXIJKEeeCbuUKu+56HTUe+z
UUBHdiHSUzIF1BFKUZMEB7+LMZBYm9ZkDBlnrHLIqyS/sMvsc8eLL3XI+4oI
HeiaXIGvPJvBjIDPJ/lqxSaeBd57VwF7Lc8VXPahf8p2SF9/QSRXlqzQuWyc
zGei85+Kt80t4YAKGepDgbnFz11SbneN4MEoxO1oh8icV+TGF1hiJ7Vkr3uk
aTlFQyMM3gC4NTNCBimsNyIYThIwMvHGSgC77/2eRYRqA+dMkf9IfjIceSDl
lTOvrShTxzWkqc0Dh5H96+tzMaXqaDQejUHFsJ3LtP65b6jvSzObHaXJredG
kF6LOzCH60ZSIZhJEVO6IvXO4lRcllss7GPiKn4rzDx3uE+8ZO++h9xHj9aP
f4fR1KzWxAKBmR7ha0H82GJj/w79f5jmxHAk/qo7Xj87pjAqAw/GEvi2SIav
I4SxNAW+/AGzkKPAUKwQDNAO79He/mygZ+OtZin83KtlLkkRY9OPBORwHGaS
QFnnxMY9u6hu3q1U/SyvjLcexLQVzUGTrnLxKzIGKTtwY2SiVce0SLANLyof
aDEk4nglVS0NOEO1zFc5TAcZH2WzEnuhx7ELn6ArnOPCaIjKWs0EVkGZgpkp
nUWwiOd1t8/qRPN8c3Hxeo+CSiKeoiQeCn6idQtlOGxwvSLfl9OoHGYlq6EN
CjnW+qjbkqE/6teeKoo+6QG12S/3kXdGouCj/vrsQgd//Hu0D4mW31+/vRgE
jfh3pM+1+/3V+UWrP8CyIcvh5XE3yBc8mxnn3EC2thx2a7RYtu2AAx/YEyPn
QC8YlxXnrOBMIyogfr6zi3xn859RPGS4FnzAIM/PTiWdVXFzXjO3hmLH+1cE
RkZMVaTe8ZLfNTCDZrxyGY9Yf1x6i1XCB7PLCo1sxxgNLIqEKQnOsrJkeFGQ
dG/MAJgmJBbOnc9LqyLL6NI4ZJZuytrAiDZ+QQ76Y/ifZIGJNzbhh6mFLKta
mcFCkJLgdKAlSnVcXhokJ/BkcXUk0uKfgy67gO1UidWP7ShGdgQefqkJMiU9
3XWySwwswZSzWZw0FTtWOr0mwS+9jWvZXNUynSPJ6a6SxbLiEACQKyxlBsUB
a6r8KkLSgsZW/qRGi3Fqjm7IkPQxsZPogc0wZ7peE987iOSygtof2ejLKK1t
UidTXnKvf0Ot7ty8IyT6hkIgMpMD2W5kSJMC+U3Eoi4B7E5Q5pI1ioBMWez9
ari+JFornEtxWMSxTcb2JFpEoN3HOcFagZZZOzoZfW5X2Xfk1DGhuGyvM0M4
aiGCY3ZQo5RxzFrsaQSDQoNgv2l36wrLkvDXbvvM+T7WkS5dcNADt2VVcY6d
KF3cqJO5P/YBNQSN703cY3SnWI0dlma/PdFW6TT2yR76ODqxf55RjevlUwDe
YeMUpA0CnJB24yHl0q5wadM5bDQOIZIcHkJzCNBnEAbeDGArXh9fnHyzn/A/
kEY+bISzxNJPM1yRyVShV+bTu05BXHBCE3IyHkq8y1H9FubxVPLE+o1DvxOM
hq24/oJ0ZvgZX7YFBx3d/GnTRHHMTowclblDBbdJNgmh7AbhMMWO1NkesMVz
wrpDjhGyAQPV9mUD59dJ0SqiKd9nyNh1YufpRglJkMTnuUjr8I5zrcTzYJCm
QdfwqzQfk7kcgOuilmR/CBbIN0/ZzDPY0j5v+a/9sNswIb3CRxpuZWbkJCXl
Cn5MH1zneH8tx58EG+xSc1a8cCdQveOT5zQbCUPCMMZZ0pdPzy+PyB3/DVKc
Dx8e3NyQKH/gkZzL55VGnCEkWghO2MsrTCoSvEzWalqL6M+RiPeK0N0q8ibL
Rlr5eCDYg1w1yYkmvnYYMtqDsyCHS5xtHoC+RngIyZqjvLYzRh5GEavUmzEN
+ulf52c1v5Q/0dHa8Wd9Kxx1DWdwXoz1nwZO9ofkaDVfTs+en12cbblUQ8ez
/5Zr9Rmdg+f1lKFOrLz+owCl+AUzG+w6Sv8YWG3qEGXlNtQt89R5tqXzQswH
U/C5O2OwnQhGoKO57OEgtUWIi6DfhR7j0d0D3R/T/05EZPYa3eJcwSeVQyC6
Ofq0B6ROsFjTfaxn+QNvHm65Dc+dlysp/I5L7jYKSsPOYqvSQb1ry8I765PI
Cnn0NPcmL1SD4NzOGxAJ87UVq1UEK29ByzpY8OFpNYSVsUKRhpRq8A6RZMPg
zMXdtWJHbWeQonQQjDwkgmHE/UpIF85dwM8IYBWqcTY7OWKf4rZHpTG5QDOb
2xEpYMXDRtmhdglZObCBIdt1OWeGsxhltlLEZpB1SQEeAcbUVFfwyjEeeRoI
zVuenrh+bBbUFiTNrE48ZvHwTX1QFqUUApesGvWK9wKJiN3KkZRWhSri3Cl8
qu7JBD32Z8VB9GDdEJ8z9ewT7jrDbjOgatstE3+Pdv3SjJqoyu4GR7Mcv6BZ
N3LB4Nbdg/Xuxtis1ST5gR/gcisd9+CG08fucCMeeKGYRRYEtlOKLq3h3EUJ
+Hw2URHB4vqJtbm0OZIOPqPbtMzTujJcb+IURhJQCv/wKBRnbqUpRuy3BJvI
6cc2WeLtScreBl/v2NMRVCOzXb1zPsc8h0byoXxl1uVEqTsaM9CMRdIUj1Ri
maHC4pVsfJaja33geK5MseCaF05QeWIw6CYcJbGHSnUWJBLbiyNvUCjqZwSd
Vh+a7ISlr9NHDsBQUVXIARdZa42GSRGGpq4UakBwlxHqHGCunSq+Y0BJBWJy
y+MrroOBeaC5+OwDskq2CmfXgQ6+ms+xaTMEzSyxh2MXPBzes4kqGsGOijE6
RtjmxsMG8gP1Pdxz/LIehav2Ssou/T9NRhhjufhKzA9RtqZopuDyMZw59WMz
46JSNnktxrLiwbOrK+dYchFICc149cadwBC3KP4hyejkH9jUpKlsMM8p0amL
+gJUmLkaJD4yh01dNEVZvzt/9RJpXBRKEhp0Ci8Ei9hcxivbRnLzXFj53Xc9
GwT3BgffD+gbZ2d6g3v8BbmY3mAcnIHYQT7vEZHrksdCJSjU/aO7GufP5Z5N
NV1fo1xb6iDg/3OhA5ll2nHkAjq1eFZ7GqaoflNxw8VCjWNjS0S2q0MycyUV
TvhdNfHcQLdL5QIfCYtw+rPHUOT8D1RyqFsqOSbM4eD4gxNN7aMPByrVcqA7
svmVan6kXjgkIaf2McOtx144dV0AVZ2BqDPOVvQIJzmOO8px6Uv9yz6JJ7kr
E41KanhOE41yZ4qCJ3pMH0T1JvqQPj89oyhY6tM5IJ7oe8BA+/k+Wje+NXUZ
P9Z39YjhoQ0OQUuZ8vDwsT74bFPQdHj0WI8/19ITfe+xPvxcY7uqw/uP9dFn
SZClHj54rO99rq3jy+HDx/r+7sZ7LCSsVk4VvF6hGk5kzMUH3fKEnY6wdwe8
sqMoq4MJGPgJARREdpoX1Ifkug0U8vyxJKwoVjdc38sB9so5Rvvkp1AUbuQa
AUyIO6AXgFmaD8O4Xq3Vw8NdMRr+vqBuRbTpH+ICgn44/mSj8Z4txL//YFcj
eCr9B64N/Y3nDw7pv6P79+7HD+5yGw92thWFMztGqjPJ5fYPfh5Z928l636L
rPsH9N+MyDqybRzqOqrufZKqez+Pqp2DMVX32lQdEatmDw59Gwv/jqgd8wVE
jfdCEwHx+VkmguWxP34YmIiX/mCKfImcczfkSkRdLQqDYJjTec2HE/CDPNCF
BaOFWSCwRKWQf9Ica7uyUxzklia9NKWCPllT2zhPtlR7oJFr4eR6mGKBkrJ9
dwQcKELr8YEU62zWNlVYl+x3cnzNNpIr9Ukrk8ZQv8DtA32xWRMlrWqqHfXq
rhqXbyxwnUTZjVZCBFFsRwfBwaW31e+C0tl9wqZfgZ53nPb0m7XVBpv+DseZ
F3zQGFLBbmNzc0LCHPG0sa9yKM7IZQ/9HmMxUZ1WPmUvBcrKfu213fIejxgM
0+sYQteAB8dxrZJAKjwm8h66SEObuTh36rBbMp0o2IctRkQeFIHIcWdTiyy0
QZj2G0JsBRZH5Z3acKm3a3jYHGKUqo8AEFKMGIaP7rPYyzUnBgvJzbBzdJKj
krsaupLr6+uZfSKSIMUauOrC5abNCcd2DZ/UIJO+pCgB/kB/3289mOBYX5/F
o4m2lXyS/AgjYDJUiEJtP3SwIPNH+hPO8dkSDWRd7Z0VaHbdq5zjaDl3MB2d
aVd6YJFJWOqPQCGOO7Ei9x9yf5eV6gVj9iyviw2nJ18iSsTfR31hT3NaIPlR
vzEsBDPTxU/OUzrVoYa7NAr9iQ/gzIAEtrmNhLS0688u+XZ/+/hT/QmwKa5e
ZF/2UjMnNbGg/ZI85XDJ1gfZrfPk7dIw5TrCbaAve7YEnPqgr1z+U5OQOKXO
62nV+tGOpdQbOXOLdXjRaqJf7h8r9Wotp1md3+5Y7Zq0zrBs8BikOpqSu07s
Kzc9aq5giO11BAEeiSQkHnCMC84TcSHMCUMAQTLEaYhgk23I6rt9gf5pXgWj
wqSJdHg6Tkl2ciLtlfF0QQhzSfsWtWj5Ly+HKdq9ni2IbS3oDMYd2tQ+NsV+
2Xi4DzuyR7LgSvW3W15f29t8gs5ufL4kYQpOjdpiw+2+GUV6Sr2up2lSLk0n
npTB28rQmuA4vDvCSC/VWkkIyhhlu6E7NeOExKapXu5ez+AdnvNtxmDvfD5+
YAfg7JWRuqRAbnGuWkQLjv0Ckd/mA2dLNuT7f2C8bNUcz7dHkCt/4a0FIbEX
qj5UtUeWvn9MgSc43ETpDdgEaWPqvzWV7WJJC7OrO6YiMXlNtFH7X8otXHfY
ZBldRVa/53XBaenAz+Fdwh3ur/mOM/jJBan98K7zHq5SUX9cz27vKZj2xpDW
XiQE9MeFQb13UTU9RRo5UU0e3YKlAuX6r14CzWClZ/7OpW8g0ikl8fsnnNFx
ldOpKdBCLoq/dveICPWsavpFEV9vgWV21/6HYJnzRH+F5f8/sMwhAKnt24un
w4dDF6QhYvwrWP9fBGso8P8SWMtUfwXr28CapnBxmwoDE5ffC2PmncEAF0nu
APvB7thGzqylOqqBEARYXPr96fcbkJY5PMMByS5oKtV26E7hXb6uUz4rx0wT
BEmvPZh9ZOPSDpBO+eofW5H981aEtx1CUcgTxHTh59uefKoFAiiswM3TOe2j
J8E3Uhhk4DshnFciCeeYCe6XTjb+ozu2atWdhvmn9mg/KThreMth2sXStGSP
doOkhe/Nt1lbOIuOhJN9wwjfQYWVM0jr8RYiP0Fr5xNrky1II5oAnd9tU1Vy
0z+8eW6UHX3lXiuxfQnUVQvF/lS2BfplN6XjciYOsXEpIPnR2DM2d0ucAItv
aIXXnHZdxOC3EDTGm0vH+UTXlmBkfPB9xajoKnval7QcjMhl1poP2eWSuZzE
NvfVQXHp23HOz7PQDxOoPg3R/1nav8cVrY1Zsnugt1JYwufGs4AqlqEN5Awk
fWzuahyNDlF/qfWw/coZnCwg+UmyO4dlT+V1EXyA4N9qQhBScgJlg2QrDUKb
k6RcBc1XNAUl+LxWSHF3HQRCClQeLojYFcoPtE4JeWtI4PHrZ+669Zao2urw
2FyaNF97G4P3iJgCHhgxcVETt1JOlkalclfSVTtV1qmwvCV95PNunTybP5m2
r87ghHS7Tdlr4fLAArNr31z9BlzM61S139t0kr852wu1X79xCG+hvfNKGz4M
KpUkukrGZUcQA0kDafYx/cu+4kf97HQbhm9LVw27AHnx5PRgCydvyVXt6jz+
6bDYZTAB4v5+k5HsJB6ZMMgDT8I66er4acXlbflFW5Hm7WkUvLZiE6jOwZh1
R/tjaCmoqOCakErh3gNf0hPESetVxtvuN6THZQ1yw9QmICt+7G6fdTrZ7Wp1
c/4+bmk3JyrRlh/sxXgH4jYpeIVooCbn0KZOUX9+iwI0Rw+FSc0lubEquLYL
7W1iiXbeWV9/4QKJXSlod/xhmnfCbFXmh2f//FIVvB7AvWKEMQabraCTDNoD
VK8jQE7NB/uuitK/NIjvO/hX4QRWiVxt7/O0asADETgYHQQiMFLnuElwBWLl
mq+M7Ou07CsdfCBFbPoWpPMqbJVJaRyJ7l6LKCXHHi0THxgeNaN5CEPoG9tb
vKLO3Ryvdt+m08hm5xu+EMO3f1kHZGrECHU6J6AtP03D3wSv7hEzjIve7mKq
nVymw5kQcYeGJtfA3ltovxiKCz7cSwoaG9qyzTCeB3u33XL218PYIeAyJ1fl
3LkYh1f/4DxR5Afk9sd7wSuhso33EkIaxZbIe4YKW+DnY0a5GRKkPjwBnRPS
knYMrOSrOlxq5jMEuy6VWkkd2OivXShTtutCbznfElEqZ0ty2awb4y+Kthbo
qvPr0jsN4unIIUpNLCOF2RNfaIegSXDTVaUQbtxtA+Ec8b/I1wXeVsHsgFsA
muxrpGbykh32MtrAptsuqHOJmj6ffecCvztApNw6dzwJiEo52cVvSOOKaV8u
yO9D4BdN2rpariLDIvclMsAdeL59ZN9mg6vzPnr3t218YkEO99ovbuMLacGt
SZebaCDh08hoK8WwQU0JCMs5n3KSbUy4fl9eweWTBVAzKZz2v+kfavsqKyn1
5ZpVezdpV63qSOtnc+gubYKRNz6030/A/LV63koHBlmdz19sUTvuz2wVyPKV
BY+QJoGXSGGL6OWWxw9tI0O2AUohfcFn/laotuh0dzUaYRht3ZeQbXLpnfA1
Gplu3uHBvoUzDopLir27jjJ/fpeNe48cdm/Xxv0Ulvl7CeoTLGvYZa0J8eC9
MWs487P3ruBx18uunGD79xHU9kELgn19RYulgsD/8U//LNUZrXJiLVfXfClc
p1xWqjdcxX6aMOzZHrhZtDvvrKPLKEkjKWQiz5+Ee/aeeDtDF4KChWDKlnMC
x1TcfhN/2ctyeJ/X19e/S1b6fLaMoviGpA5PnhaofylnEXnvKTtFifvpVRrN
9RNTLPCKVPfwRVTMcn2RIBfBz0R1r0+WBclIgnuDq/Iv/4Z3W90of42V/BnB
PilJxosTxG2Mk8K6J93AfIRRj8kJooDthUmz5H1+SWNKcSG2sW5ub+B1Afjf
Ilr7KIdDRMU5onYwP7BladfP80WURWS89N+a9DLJ4gJYdBNcviVKzZqGjxXu
55FPz3beh3F2USP1AiYYN9Tfl+KI2qP6Z2fnX2vpysXPdovd+K6UrVyRgPJV
KTj8TCleNziFXDkXleh9YrIfSCYz/fsort+3KfUXfS+NnRCaaK/F8ItqkIBU
p8zuvBAe0JKhv0m7Id9VhRUPaur8xWa/OSyM87Sez5X69S/oM9+6Sb8Fokz0
jncitb06xJNXJFecxeJ4VA+HX+0aCdgX3mdt3SQFSPEZAc5vbx2iVSrYeadG
52KqjPGf7uZ9eiJaAAA=
a) We updated "Constrained Devices" (capitalized) to "constrained devices"
(lowercase) per usage in RFC 7228. Aside from the usage in RFC 7228, the
lowercase form is also more common in the RFC Series as a whole. Please let us
know any objections.
b) We see both of the following forms in the document. Please review each
instance and let us know if any updates are needed.
location vs. Location
c) Does the following need to be capitalized in running text?
Current:
REST-Specific Model with Dynamic Resource Creation
Perhaps:
REST-specific model with dynamic resource creation
--> -->
<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. -->
<!-- [rfced] XML Formatting
a) We note that URI-local-part appears in several ways: with quotation marks,
with no quotation marks, and in italics/underscores (i.e., <em> in xml). In
addition, we see that REST-method-set appears with quotation marks in some
instances and in fixed-width font (i.e., <tt> in xml) in others. Should the
formatting of these terms be consistent? Let us know if any updates are
needed.
URI-local-part
REST-method-set
b) The document has two instances of "allow-list". One is enclosed in <em> in
the xml but the other is not. Should this be consistent? If so, please let us
know which form is preferred.
c) In the xml file, <tt> is used consistently for Toid and Tperm in general
text. Should <tt> also be used for "Toid/Tperm" in the following sentence?
Original:
...that all parties have the same understanding of
each Toid/Tperm pair in terms of specified objects (resources) and
operations on those.
d) The following appear both with and without <tt> in the xml file. Should
this be consistent? If so, please let us know which form to use.
application/aif+json
application/aif+cbor
e) A question about the use of <tt> was sent on 28 February 2022 to all
authors of documents in cluster 442. It seems that the cluster authors decided
to use <tt> for claims and parameters. Please let us know if any updates are
needed for this document to correspond with that cluster-wide decision.
-->
</rfc> </rfc>
 End of changes. 91 change blocks. 
878 lines changed or deleted 460 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/