From 2c1d792bfbed770be547798a7e091e0a7aa66f6c Mon Sep 17 00:00:00 2001
From: ID Bot <idbot@example.com>
Date: Fri, 12 Jan 2024 10:17:34 +0000
Subject: [PATCH] Script updating gh-pages from 422fd05. [ci skip]

---
 .../draft-ietf-ace-key-groupcomm.html         | 1161 +++++++++++------
 .../draft-ietf-ace-key-groupcomm.txt          |  958 +++++++++-----
 2 files changed, 1442 insertions(+), 677 deletions(-)

diff --git a/warren-kumari-review/draft-ietf-ace-key-groupcomm.html b/warren-kumari-review/draft-ietf-ace-key-groupcomm.html
index e520344..5624874 100644
--- a/warren-kumari-review/draft-ietf-ace-key-groupcomm.html
+++ b/warren-kumari-review/draft-ietf-ace-key-groupcomm.html
@@ -10,10 +10,10 @@
 <meta content="
        This document defines how to use the Authentication and Authorization for Constrained Environments (ACE) framework to distribute keying material and configuration parameters for secure group communication. Candidate group members acting as Clients and authorized to join a group can do so by interacting with a Key Distribution Center (KDC) acting as Resource Server, from which they obtain the keying material to communicate with other group members. While defining general message formats as well as the interface and operations available at the KDC, this document supports different approaches and protocols for secure group communication. Therefore, details are delegated to separate application profiles of this document, as specialized instances that target a particular group communication approach and define how communications in the group are protected. Compliance requirements for such application profiles are also specified. 
     " name="description">
-<meta content="xml2rfc 3.18.2" name="generator">
+<meta content="xml2rfc 3.19.0" name="generator">
 <meta content="draft-ietf-ace-key-groupcomm-latest" name="ietf.draft">
 <!-- Generator version information:
-  xml2rfc 3.18.2
+  xml2rfc 3.19.0
     Python 3.11.6
     ConfigArgParse 1.7
     google-i18n-address 3.1.0
@@ -1025,11 +1025,11 @@
 <thead><tr>
 <td class="left">Internet-Draft</td>
 <td class="center">Key Provisioning for Group Communication</td>
-<td class="right">December 2023</td>
+<td class="right">January 2024</td>
 </tr></thead>
 <tfoot><tr>
 <td class="left">Palombini &amp; Tiloca</td>
-<td class="center">Expires 15 June 2024</td>
+<td class="center">Expires 15 July 2024</td>
 <td class="right">[Page]</td>
 </tr></tfoot>
 </table>
@@ -1042,12 +1042,12 @@
 <dd class="internet-draft">draft-ietf-ace-key-groupcomm-latest</dd>
 <dt class="label-published">Published:</dt>
 <dd class="published">
-<time datetime="2023-12-13" class="published">13 December 2023</time>
+<time datetime="2024-01-12" class="published">12 January 2024</time>
     </dd>
 <dt class="label-intended-status">Intended Status:</dt>
 <dd class="intended-status">Standards Track</dd>
 <dt class="label-expires">Expires:</dt>
-<dd class="expires"><time datetime="2024-06-15">15 June 2024</time></dd>
+<dd class="expires"><time datetime="2024-07-15">15 July 2024</time></dd>
 <dt class="label-authors">Authors:</dt>
 <dd class="authors">
 <div class="author">
@@ -1093,7 +1093,7 @@ <h2 id="name-status-of-this-memo">
         time. It is inappropriate to use Internet-Drafts as reference
         material or to cite them other than as "work in progress."<a href="#section-boilerplate.1-3" class="pilcrow">¶</a></p>
 <p id="section-boilerplate.1-4">
-        This Internet-Draft will expire on 15 June 2024.<a href="#section-boilerplate.1-4" class="pilcrow">¶</a></p>
+        This Internet-Draft will expire on 15 July 2024.<a href="#section-boilerplate.1-4" class="pilcrow">¶</a></p>
 </section>
 </div>
 <div id="copyright">
@@ -1102,7 +1102,7 @@ <h2 id="name-copyright-notice">
 <a href="#name-copyright-notice" class="section-name selfRef">Copyright Notice</a>
         </h2>
 <p id="section-boilerplate.2-1">
-            Copyright (c) 2023 IETF Trust and the persons identified as the
+            Copyright (c) 2024 IETF Trust and the persons identified as the
             document authors. All rights reserved.<a href="#section-boilerplate.2-1" class="pilcrow">¶</a></p>
 <p id="section-boilerplate.2-2">
             This document is subject to BCP 78 and the IETF Trust's Legal
@@ -1371,28 +1371,31 @@ <h2 id="name-copyright-notice">
                 <p id="section-toc.1-1.11.2.5.1"><a href="#section-11.5" class="auto internal xref">11.5</a>.  <a href="#name-interface-description-if-li" class="internal xref">Interface Description (if=) Link Target Attribute Values</a></p>
 </li>
               <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.11.2.6">
-                <p id="section-toc.1-1.11.2.6.1"><a href="#section-11.6" class="auto internal xref">11.6</a>.  <a href="#name-ace-groupcomm-parameters-3" class="internal xref">ACE Groupcomm Parameters</a></p>
+                <p id="section-toc.1-1.11.2.6.1"><a href="#section-11.6" class="auto internal xref">11.6</a>.  <a href="#name-custom-problem-detail-keys-" class="internal xref">Custom Problem Detail Keys Registry</a></p>
 </li>
               <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.11.2.7">
-                <p id="section-toc.1-1.11.2.7.1"><a href="#section-11.7" class="auto internal xref">11.7</a>.  <a href="#name-ace-groupcomm-key-types-2" class="internal xref">ACE Groupcomm Key Types</a></p>
+                <p id="section-toc.1-1.11.2.7.1"><a href="#section-11.7" class="auto internal xref">11.7</a>.  <a href="#name-ace-groupcomm-parameters-3" class="internal xref">ACE Groupcomm Parameters</a></p>
 </li>
               <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.11.2.8">
-                <p id="section-toc.1-1.11.2.8.1"><a href="#section-11.8" class="auto internal xref">11.8</a>.  <a href="#name-ace-groupcomm-profiles-2" class="internal xref">ACE Groupcomm Profiles</a></p>
+                <p id="section-toc.1-1.11.2.8.1"><a href="#section-11.8" class="auto internal xref">11.8</a>.  <a href="#name-ace-groupcomm-key-types-2" class="internal xref">ACE Groupcomm Key Types</a></p>
 </li>
               <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.11.2.9">
-                <p id="section-toc.1-1.11.2.9.1"><a href="#section-11.9" class="auto internal xref">11.9</a>.  <a href="#name-ace-groupcomm-policies-2" class="internal xref">ACE Groupcomm Policies</a></p>
+                <p id="section-toc.1-1.11.2.9.1"><a href="#section-11.9" class="auto internal xref">11.9</a>.  <a href="#name-ace-groupcomm-profiles-2" class="internal xref">ACE Groupcomm Profiles</a></p>
 </li>
               <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.11.2.10">
-                <p id="section-toc.1-1.11.2.10.1"><a href="#section-11.10" class="auto internal xref">11.10</a>. <a href="#name-sequence-number-synchroniza" class="internal xref">Sequence Number Synchronization Methods</a></p>
+                <p id="section-toc.1-1.11.2.10.1"><a href="#section-11.10" class="auto internal xref">11.10</a>. <a href="#name-ace-groupcomm-policies-2" class="internal xref">ACE Groupcomm Policies</a></p>
 </li>
               <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.11.2.11">
-                <p id="section-toc.1-1.11.2.11.1"><a href="#section-11.11" class="auto internal xref">11.11</a>. <a href="#name-ace-groupcomm-errors" class="internal xref">ACE Groupcomm Errors</a></p>
+                <p id="section-toc.1-1.11.2.11.1"><a href="#section-11.11" class="auto internal xref">11.11</a>. <a href="#name-sequence-number-synchroniza" class="internal xref">Sequence Number Synchronization Methods</a></p>
 </li>
               <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.11.2.12">
-                <p id="section-toc.1-1.11.2.12.1"><a href="#section-11.12" class="auto internal xref">11.12</a>. <a href="#name-ace-groupcomm-rekeying-schem" class="internal xref">ACE Groupcomm Rekeying Schemes</a></p>
+                <p id="section-toc.1-1.11.2.12.1"><a href="#section-11.12" class="auto internal xref">11.12</a>. <a href="#name-ace-groupcomm-errors" class="internal xref">ACE Groupcomm Errors</a></p>
 </li>
               <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.11.2.13">
-                <p id="section-toc.1-1.11.2.13.1"><a href="#section-11.13" class="auto internal xref">11.13</a>. <a href="#name-expert-review-instructions" class="internal xref">Expert Review Instructions</a></p>
+                <p id="section-toc.1-1.11.2.13.1"><a href="#section-11.13" class="auto internal xref">11.13</a>. <a href="#name-ace-groupcomm-rekeying-schem" class="internal xref">ACE Groupcomm Rekeying Schemes</a></p>
+</li>
+              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.11.2.14">
+                <p id="section-toc.1-1.11.2.14.1"><a href="#section-11.14" class="auto internal xref">11.14</a>. <a href="#name-expert-review-instructions" class="internal xref">Expert Review Instructions</a></p>
 </li>
             </ul>
 </li>
@@ -1480,12 +1483,13 @@ <h2 id="name-introduction">
 <a href="#section-1" class="section-number selfRef">1. </a><a href="#name-introduction" class="section-name selfRef">Introduction</a>
       </h2>
 <p id="section-1-1">This document builds on the Authentication and Authorization for Constrained Environments (ACE) framework and defines how to request, distribute, and renew keying material and configuration parameters to protect message exchanges in a group communication environment.<a href="#section-1-1" class="pilcrow">¶</a></p>
-<p id="section-1-2">Candidate group members acting as Clients and authorized to join a group can interact with the Key Distribution Center (KDC) acting as Resource Server and responsible for that group, in order to obtain the necessary keying material and parameters to communicate with other group members.<a href="#section-1-2" class="pilcrow">¶</a></p>
+<p id="section-1-2">Candidate group members acting as ACE Clients and authorized to join a group can interact with the Key Distribution Center (KDC) acting as ACE Resource Server and responsible for that group, in order to obtain the necessary keying material and parameters to communicate with other group members.<a href="#section-1-2" class="pilcrow">¶</a></p>
 <p id="section-1-3">In particular, this document defines the operations and interface available at the KDC, as well as general message formats for the interactions between Clients and KDC. At the same time, communications in the group can rely on different approaches, e.g., based on multicast <span>[<a href="#I-D.ietf-core-groupcomm-bis" class="cite xref">I-D.ietf-core-groupcomm-bis</a>]</span> or on publish-subscribe messaging <span>[<a href="#I-D.ietf-core-coap-pubsub" class="cite xref">I-D.ietf-core-coap-pubsub</a>]</span>, and can be protected in different ways.<a href="#section-1-3" class="pilcrow">¶</a></p>
-<p id="section-1-4">Therefore, this document delegates details on the communication and security approaches used in a group to separate application profiles. These are specialized instances of this document, targeting a particular group communication approach and defining how communications in the group are protected, as well as the specific keying material and configuration parameters provided to group members. In order to ensure consistency and aid the development of such application profiles, this document defines a number of related compliance requirements (see <a href="#req" class="auto internal xref">Appendix A</a>).<a href="#section-1-4" class="pilcrow">¶</a></p>
-<p id="section-1-5">New keying material is intended to be generated and distributed to the group upon membership changes (rekeying). If the application requires backward security (i.e., new group members must be prevented from accessing communications in the group prior to their joining), then a rekeying has to occur every time new members join the group. If the application requires forward security (i.e., former group members must be prevented from accessing communications in the group after their leaving), then a rekeying has to occur every time current members leave the group or are evicted from the group.<a href="#section-1-5" class="pilcrow">¶</a></p>
-<p id="section-1-6">A group rekeying scheme performs the actual distribution of the new keying material, by rekeying the current group members when a new Client joins the group, and the remaining group members when a Client leaves the group. This can rely on different approaches, including efficient group rekeying schemes such as <span>[<a href="#RFC2093" class="cite xref">RFC2093</a>]</span>, <span>[<a href="#RFC2094" class="cite xref">RFC2094</a>]</span>, and <span>[<a href="#RFC2627" class="cite xref">RFC2627</a>]</span>.<a href="#section-1-6" class="pilcrow">¶</a></p>
-<p id="section-1-7">Consistently with what is recommended in the ACE framework, this document uses CBOR <span>[<a href="#RFC8949" class="cite xref">RFC8949</a>]</span> for data encoding. However, using JSON <span>[<a href="#RFC8259" class="cite xref">RFC8259</a>]</span> instead of CBOR is possible, by relying on the conversion method specified in Sections <a href="https://rfc-editor.org/rfc/rfc8949#section-6.1" class="relref">6.1</a> and <a href="https://rfc-editor.org/rfc/rfc8949#section-6.2" class="relref">6.2</a> of <span>[<a href="#RFC8949" class="cite xref">RFC8949</a>]</span>.<a href="#section-1-7" class="pilcrow">¶</a></p>
+<p id="section-1-4">Therefore, this document delegates details on the communication and security approaches used in a group to separate application profiles. These are specialized instances of this document, targeting a particular group communication approach and defining how communications in the group are protected, as well as the specific keying material and configuration parameters provided to group members.<a href="#section-1-4" class="pilcrow">¶</a></p>
+<p id="section-1-5">In order to ensure consistency and aid the development of such application profiles, <a href="#req" class="auto internal xref">Appendix A</a> of this document defines a number of related compliance requirements. In particular, <a href="#req-mandatory" class="auto internal xref">Appendix A.1</a> compiles the requirements that application profiles are REQUIRED to fulfill; these are referred to by an identifier that starts with "REQ". Instead, <a href="#req-optional" class="auto internal xref">Appendix A.2</a> compiles the requirements that application profiles MAY fulfill; these are referred to by an identifier that starts with "OPT".<a href="#section-1-5" class="pilcrow">¶</a></p>
+<p id="section-1-6">New keying material is intended to be generated and distributed to the group upon membership changes (rekeying). If the application requires backward security (i.e., new group members must be prevented from accessing communications in the group prior to their joining), then a rekeying has to occur every time new members join the group. If the application requires forward security (i.e., former group members must be prevented from accessing communications in the group after their leaving), then a rekeying has to occur every time current members leave the group or are evicted from the group.<a href="#section-1-6" class="pilcrow">¶</a></p>
+<p id="section-1-7">A group rekeying scheme performs the actual distribution of the new keying material, by rekeying the current group members when a new Client joins the group, and the remaining group members when a Client leaves the group. This can rely on different approaches, including efficient group rekeying schemes such as <span>[<a href="#RFC2093" class="cite xref">RFC2093</a>]</span>, <span>[<a href="#RFC2094" class="cite xref">RFC2094</a>]</span>, and <span>[<a href="#RFC2627" class="cite xref">RFC2627</a>]</span>.<a href="#section-1-7" class="pilcrow">¶</a></p>
+<p id="section-1-8">Consistently with what is recommended in the ACE framework, this document uses CBOR <span>[<a href="#RFC8949" class="cite xref">RFC8949</a>]</span> for data encoding. However, using JSON <span>[<a href="#RFC8259" class="cite xref">RFC8259</a>]</span> instead of CBOR is possible, by relying on the conversion method specified in Sections <a href="https://rfc-editor.org/rfc/rfc8949#section-6.1" class="relref">6.1</a> and <a href="https://rfc-editor.org/rfc/rfc8949#section-6.2" class="relref">6.2</a> of <span>[<a href="#RFC8949" class="cite xref">RFC8949</a>]</span>.<a href="#section-1-8" class="pilcrow">¶</a></p>
 <div id="terminology">
 <section id="section-1.1">
         <h3 id="name-terminology">
@@ -1505,7 +1509,7 @@ <h3 id="name-terminology">
             <p id="section-1.1-3.2.1">The terms and concepts described in CoAP <span>[<a href="#RFC7252" class="cite xref">RFC7252</a>]</span>. Unless otherwise indicated, the term "endpoint" is used here following its OAuth definition, aimed at denoting resources such as /token and /introspect at the AS, and /authz-info at the RS. This document does not use the CoAP definition of "endpoint", which is "An entity participating in the CoAP protocol".<a href="#section-1.1-3.2.1" class="pilcrow">¶</a></p>
 </li>
           <li class="normal" id="section-1.1-3.3">
-            <p id="section-1.1-3.3.1">The terms and concepts described in CBOR <span>[<a href="#RFC8949" class="cite xref">RFC8949</a>]</span> and COSE <span>[<a href="#RFC9052" class="cite xref">RFC9052</a>]</span><span>[<a href="#RFC9053" class="cite xref">RFC9053</a>]</span><span>[<a href="#RFC9338" class="cite xref">RFC9338</a>]</span>.<a href="#section-1.1-3.3.1" class="pilcrow">¶</a></p>
+            <p id="section-1.1-3.3.1">The terms and concepts described in CDDL <span>[<a href="#RFC8610" class="cite xref">RFC8610</a>]</span>, CBOR <span>[<a href="#RFC8949" class="cite xref">RFC8949</a>]</span>, and COSE <span>[<a href="#RFC9052" class="cite xref">RFC9052</a>]</span><span>[<a href="#RFC9053" class="cite xref">RFC9053</a>]</span><span>[<a href="#RFC9338" class="cite xref">RFC9338</a>]</span>.<a href="#section-1.1-3.3.1" class="pilcrow">¶</a></p>
 </li>
         </ul>
 <p id="section-1.1-4">A principal interested to participate in group communication as well as already participating as a group member is interchangeably denoted as "Client" or "node".<a href="#section-1.1-4" class="pilcrow">¶</a></p>
@@ -1524,19 +1528,19 @@ <h3 id="name-terminology">
 <p id="section-1.1-6">Furthermore, this document uses "names" or "identifiers" for groups and nodes. Their different meanings are summarized below.<a href="#section-1.1-6" class="pilcrow">¶</a></p>
 <ul class="normal">
 <li class="normal" id="section-1.1-7.1">
-            <p id="section-1.1-7.1.1">Group name: the invariant once established identifier of a group. It is used in the interactions between Client, AS, and RS to identify a group. A group name is always unique among the group names of the existing groups under the same KDC.<a href="#section-1.1-7.1.1" class="pilcrow">¶</a></p>
+            <p id="section-1.1-7.1.1">Group name: The identifier of a group, as a text string. Once established, it is invariant. It is used in the interactions between Client, AS, and RS to identify a group. A group name is always unique among the group names of the existing groups under the same KDC.<a href="#section-1.1-7.1.1" class="pilcrow">¶</a></p>
 </li>
           <li class="normal" id="section-1.1-7.2">
-            <p id="section-1.1-7.2.1">GROUPNAME: the invariant once established text string used in URIs. GROUPNAME uniquely maps to the group name of a group, although they do not necessarily coincide.<a href="#section-1.1-7.2.1" class="pilcrow">¶</a></p>
+            <p id="section-1.1-7.2.1">GROUPNAME: The text string used in URIs to identify a group. Once established, it is invariant. GROUPNAME uniquely maps to the group name of a group, although they do not necessarily coincide.<a href="#section-1.1-7.2.1" class="pilcrow">¶</a></p>
 </li>
           <li class="normal" id="section-1.1-7.3">
             <p id="section-1.1-7.3.1">Group identifier: the identifier of the group keying material used in a group. Unlike group name and GROUPNAME, this identifier changes over time, when the group keying material is updated.<a href="#section-1.1-7.3.1" class="pilcrow">¶</a></p>
 </li>
           <li class="normal" id="section-1.1-7.4">
-            <p id="section-1.1-7.4.1">Node name: the invariant once established identifier of a node. It is used in the interactions between Client and RS, as well as to identify a member of a group. Within the same group, a node name is always unique among the node names of all the current members of that group.<a href="#section-1.1-7.4.1" class="pilcrow">¶</a></p>
+            <p id="section-1.1-7.4.1">Node name: The identifier of a node, as a text string. Once established, it is invariant. It is used in the interactions between Client and RS, as well as to identify a member of a group. Within the same group, a node name is always unique among the node names of all the current members of that group.<a href="#section-1.1-7.4.1" class="pilcrow">¶</a></p>
 </li>
           <li class="normal" id="section-1.1-7.5">
-            <p id="section-1.1-7.5.1">NODENAME: the invariant once established text string used in URIs to identify a member of a group. Its value coincides with the node name of the associated group member.<a href="#section-1.1-7.5.1" class="pilcrow">¶</a></p>
+            <p id="section-1.1-7.5.1">NODENAME: The text string used in URIs to identify a member of a group. Once established, it is invariant. Its value coincides with the node name of the associated group member.<a href="#section-1.1-7.5.1" class="pilcrow">¶</a></p>
 </li>
         </ul>
 <p id="section-1.1-8">This document additionally uses the following terminology:<a href="#section-1.1-8" class="pilcrow">¶</a></p>
@@ -1551,7 +1555,7 @@ <h3 id="name-terminology">
             <p id="section-1.1-9.3.1">Authentication credential, as the set of information associated with an entity, including that entity's public key and parameters associated with the public key. Examples of authentication credentials are CBOR Web Tokens (CWTs) and CWT Claims Sets (CCSs) <span>[<a href="#RFC8392" class="cite xref">RFC8392</a>]</span>, X.509 certificates <span>[<a href="#RFC5280" class="cite xref">RFC5280</a>]</span>, and C509 certificates <span>[<a href="#I-D.ietf-cose-cbor-encoded-cert" class="cite xref">I-D.ietf-cose-cbor-encoded-cert</a>]</span>.<a href="#section-1.1-9.3.1" class="pilcrow">¶</a></p>
 </li>
           <li class="normal" id="section-1.1-9.4">
-            <p id="section-1.1-9.4.1">Individual keying material: information exclusively pertaining to a group member, as associated with its group membership and related to other keying material and parameters used in the group. For example, this can be a member identifier that is unique within the group. The specific nature and format of individual keying material used in a group is defined in application profiles of this specification. The individual keying material of a group member is not related to the secure association between that group member and the KDC.<a href="#section-1.1-9.4.1" class="pilcrow">¶</a></p>
+            <p id="section-1.1-9.4.1">Individual keying material: information exclusively pertaining to a group member, as associated with its group membership and related to other keying material and parameters used in the group. For example, this can be an identifier that the secure communication protocol employs to uniquely identify a node as a group member (e.g., a cryptographic key identifier uniquely associated with the group member in question). The specific nature and format of individual keying material used in a group is defined in application profiles of this specification. The individual keying material of a group member is not related to the secure association between that group member and the KDC.<a href="#section-1.1-9.4.1" class="pilcrow">¶</a></p>
 </li>
         </ul>
 <p id="section-1.1-10">Examples throughout this document are expressed in CBOR diagnostic notation without the tag and value abbreviations.<a href="#section-1.1-10" class="pilcrow">¶</a></p>
@@ -1633,17 +1637,17 @@ <h2 id="name-overview">
           <p id="section-2-4.1.1">Client (C): node that wants to join a group and take part in group communication with other group members. Within the group, the Client can have different roles.<a href="#section-2-4.1.1" class="pilcrow">¶</a></p>
 </li>
         <li class="normal" id="section-2-4.2">
-          <p id="section-2-4.2.1">Authorization Server (AS): as per the AS defined in the ACE Framework, it enforces access policies, and knows if a node is allowed to join a given group with write and/or read rights.<a href="#section-2-4.2.1" class="pilcrow">¶</a></p>
+          <p id="section-2-4.2.1">Authorization Server (AS): as per the AS defined in the ACE Framework <span>[<a href="#RFC9200" class="cite xref">RFC9200</a>]</span>, it enforces access policies, and knows if a node is allowed to join a given group with write and/or read rights.<a href="#section-2-4.2.1" class="pilcrow">¶</a></p>
 </li>
         <li class="normal" id="section-2-4.3">
           <p id="section-2-4.3.1">Key Distribution Center (KDC): maintains the keying material to protect group communications, and provides it to Clients authorized to join a given group. During the first part of the exchange (<a href="#sec-auth" class="auto internal xref">Section 3</a>), it takes the role of the RS in the ACE Framework. During the second part (<a href="#key-distr" class="auto internal xref">Section 4</a>), which is not based on the ACE Framework, it distributes the keying material. In addition, it provides the latest keying material to group members when requested or, if required by the application, when membership changes.<a href="#section-2-4.3.1" class="pilcrow">¶</a></p>
 </li>
         <li class="normal" id="section-2-4.4">
-          <p id="section-2-4.4.1">Dispatcher: entity through which the Clients communicate with the group, when sending a message intended to multiple group members. That is, the Dispatcher distributes such a one-to-many message to the group members as intended recipients. A single-recipient message intended to only one group member may be delivered by alternative means, with no assistance from the Dispatcher.<a href="#section-2-4.4.1" class="pilcrow">¶</a></p>
+          <p id="section-2-4.4.1">Dispatcher: entity through which the Clients communicate with the group when sending a message intended to multiple group members. That is, the Dispatcher distributes such a one-to-many message to the group members as intended recipients. The Dispatcher does not have access to the group keying material. A single-recipient message intended to only one group member may be delivered by alternative means, with no assistance from the Dispatcher.<a href="#section-2-4.4.1" class="pilcrow">¶</a></p>
 <p id="section-2-4.4.2">
 Examples of a Dispatcher are: the Broker in a pub-sub setting; a relayer for group communication that delivers group messages as multiple unicast messages to all group members; an implicit entity as in a multicast communication setting, where messages are transmitted to a multicast IP address and delivered on the transport channel.<a href="#section-2-4.4.2" class="pilcrow">¶</a></p>
 <p id="section-2-4.4.3">
-If it consists of an explicit entity such as a pub-sub Broker or a message relayer, the Dispatcher is comparable to an untrusted on-path intermediary, and as such it is able to read the messages sent by Clients in the group.<a href="#section-2-4.4.3" class="pilcrow">¶</a></p>
+If it consists of an explicit entity such as a pub-sub Broker or a message relayer, the Dispatcher is comparable to an untrusted on-path intermediary, and as such it is able to see the messages sent by Clients in the group, but not to decrypt them and read their plain content.<a href="#section-2-4.4.3" class="pilcrow">¶</a></p>
 </li>
       </ul>
 <p id="section-2-5">This document specifies a mechanism for:<a href="#section-2-5" class="pilcrow">¶</a></p>
@@ -1771,7 +1775,7 @@ <h3 id="name-authorization-request">
 <p id="section-3.1-1">The Authorization Request sent from the Client to the AS is defined in <span><a href="https://rfc-editor.org/rfc/rfc9200#section-5.8.1" class="relref">Section 5.8.1</a> of [<a href="#RFC9200" class="cite xref">RFC9200</a>]</span> and MAY contain the following parameters, which, if included, MUST have format and value as specified below.<a href="#section-3.1-1" class="pilcrow">¶</a></p>
 <ul class="normal">
 <li class="normal" id="section-3.1-2.1">
-            <p id="section-3.1-2.1.1">'scope', specifying the name of the groups that the Client requests to access, and optionally the roles that the Client requests to have in those groups.<a href="#section-3.1-2.1.1" class="pilcrow">¶</a></p>
+            <p id="section-3.1-2.1.1">'scope', specifying the names of the groups that the Client requests to access, and optionally the roles that the Client requests to have in those groups.<a href="#section-3.1-2.1.1" class="pilcrow">¶</a></p>
 <p id="section-3.1-2.1.2">
 This parameter is encoded as a CBOR byte string, which wraps a CBOR array of one or more scope entries. All the scope entries are specified according to a same format, i.e., either the AIF format or the textual format defined below.<a href="#section-3.1-2.1.2" class="pilcrow">¶</a></p>
 <ul class="normal">
@@ -1811,6 +1815,8 @@ <h3 id="name-authorization-request">
 <figure id="figure-4">
           <div class="lang-CDDL sourcecode" id="section-3.1-4.1">
 <pre>
+;# include rfc9237
+
 gname = tstr
 
 permissions = uint .bits roles
@@ -1822,9 +1828,12 @@ <h3 id="name-authorization-request">
    Verifier: 4
 )
 
-scope_entry = AIF_Generic&lt;gname, permissions&gt;
+scope_entry = AIF-Generic&lt;gname, permissions&gt;
+
+scope_entries = [ + scope_entry ]
+
+scope = bstr .cbor scope_entries
 
-scope = &lt;&lt; [ + scope_entry ] &gt;&gt;
 </pre>
 </div>
 <figcaption><a href="#figure-4" class="selfRef">Figure 4</a>:
@@ -1841,7 +1850,9 @@ <h3 id="name-authorization-request">
 
 scope_entry = [ gname , ? ( role / [ 2*role ] ) ]
 
-scope = &lt;&lt; [ + scope_entry ] &gt;&gt;
+scope_entries = [ + scope_entry ]
+
+scope = bstr .cbor scope_entries
 </pre>
 </div>
 <figcaption><a href="#figure-5" class="selfRef">Figure 5</a>:
@@ -1901,7 +1912,7 @@ <h3 id="name-token-transferring">
 <a href="#section-3.3" class="section-number selfRef">3.3. </a><a href="#name-token-transferring" class="section-name selfRef">Token Transferring</a>
         </h3>
 <p id="section-3.3-1">The Client sends a Token Transfer Request to the KDC, i.e., a CoAP POST request including the access token and targeting the authz-info endpoint (see <span><a href="https://rfc-editor.org/rfc/rfc9200#section-5.10.1" class="relref">Section 5.10.1</a> of [<a href="#RFC9200" class="cite xref">RFC9200</a>]</span>).<a href="#section-3.3-1" class="pilcrow">¶</a></p>
-<p id="section-3.3-2">Note that this request deviates from the one defined in <span>[<a href="#RFC9200" class="cite xref">RFC9200</a>]</span>, since it allows to ask the KDC for additional information concerning the authentication credentials used in the group to ensure source authentication, as well as for possible additional group parameters.<a href="#section-3.3-2" class="pilcrow">¶</a></p>
+<p id="section-3.3-2">Note that this request deviates from the one defined in <span>[<a href="#RFC9200" class="cite xref">RFC9200</a>]</span>, since it allows the Client to ask the KDC for additional information concerning the authentication credentials used in the group to ensure source authentication, as well as for possible additional group parameters.<a href="#section-3.3-2" class="pilcrow">¶</a></p>
 <p id="section-3.3-3">The joining node MAY ask for this information from the KDC through the same Token Transfer Request. In this case, the message MUST have Content-Format set to application/ace+cbor defined in <span><a href="https://rfc-editor.org/rfc/rfc9200#section-8.16" class="relref">Section 8.16</a> of [<a href="#RFC9200" class="cite xref">RFC9200</a>]</span>, and the message payload MUST be formatted as a CBOR map, which MUST include the access token. The CBOR map MAY additionally include the following parameter, which, if included, MUST have format and value as specified below.<a href="#section-3.3-3" class="pilcrow">¶</a></p>
 <ul class="normal">
 <li class="normal" id="section-3.3-4.1">
@@ -1999,25 +2010,71 @@ <h2 id="name-kdc-functionalities">
         <h3 id="name-interface-at-the-kdc">
 <a href="#section-4.1" class="section-number selfRef">4.1. </a><a href="#name-interface-at-the-kdc" class="section-name selfRef">Interface at the KDC</a>
         </h3>
-<p id="section-4.1-1">The KDC provides its interface by hosting the following resources. Note that the root url-path "/ace-group" used hereafter is a default name; implementations are not required to use this name, and can define their own instead. The Interface Description (if=) Link Target Attribute value "ace.group" is registered in <a href="#if-ace-group" class="auto internal xref">Section 11.5</a> and can be used to describe this interface.<a href="#section-4.1-1" class="pilcrow">¶</a></p>
+<p id="section-4.1-1">The KDC provides its interface by hosting the following resources. Note that the root url-path "ace-group" used hereafter is a default name; implementations are not required to use this name, and can define their own instead.<a href="#section-4.1-1" class="pilcrow">¶</a></p>
 <p id="section-4.1-2">If request messages sent to the KDC as well as success response messages from the KDC include a payload and specify a Content-Format, those messages MUST have Content-Format set to application/ace-groupcomm+cbor, defined in <a href="#content-type" class="auto internal xref">Section 11.2</a>. CBOR labels for the message parameters are defined in <a href="#params" class="auto internal xref">Section 8</a>.<a href="#section-4.1-2" class="pilcrow">¶</a></p>
 <ul class="normal">
 <li class="normal" id="section-4.1-3.1">
-            <p id="section-4.1-3.1.1">/ace-group : the path of this resource is invariant once the resource is established, and indicates that this specification is used. If other applications run on a KDC implementing this specification and use this same path, those applications will collide, and a mechanism will be needed to differentiate the endpoints.<a href="#section-4.1-3.1.1" class="pilcrow">¶</a></p>
+            <p id="section-4.1-3.1.1">/ace-group : the path of this root resource is invariant once the resource is established, and indicates that this specification is used. If other applications run on a KDC implementing this specification and use this same path, those applications will collide, and a mechanism will be needed to differentiate the endpoints.<a href="#section-4.1-3.1.1" class="pilcrow">¶</a></p>
 <p id="section-4.1-3.1.2">
 A Client can access this resource in order to retrieve a set of group names, each corresponding to one of the specified group identifiers. This operation is described in <a href="#retrieval-gnames" class="auto internal xref">Section 4.2.1.1</a>.<a href="#section-4.1-3.1.2" class="pilcrow">¶</a></p>
+<p id="section-4.1-3.1.3">
+Clients may be authorized to access this resource even without being members of any group at the KDC, and even if they are not authorized to become group members (e.g., when authorized to be external signature verifiers).<a href="#section-4.1-3.1.3" class="pilcrow">¶</a></p>
+<p id="section-4.1-3.1.4">
+The Interface Description (if=) Link Target Attribute value "ace.groups" is registered in <a href="#if-ace-group" class="auto internal xref">Section 11.5</a> and can be used to describe the interface provided by this root resource.<a href="#section-4.1-3.1.4" class="pilcrow">¶</a></p>
+<p id="section-4.1-3.1.5">
+The example below shows an exchange with a KDC with address 2001:db8::ab that hosts the resource /ace-group and returns a link to such a resource in link-format <span>[<a href="#RFC6690" class="cite xref">RFC6690</a>]</span>.<a href="#section-4.1-3.1.5" class="pilcrow">¶</a></p>
+<div class="alignLeft art-text artwork" id="section-4.1-3.1.6">
+<pre>
+Request:
+
+Header: GET (Code=0.01)
+Uri-Host: "kdc.example.com"
+Uri-Path: ".well-known"
+Uri-Path: "core"
+Uri-Query: "if=ace.groups"
+
+Response:
+
+Header: Content (Code=2.05)
+Content-Format: 40 (application/link-format)
+Payload:
+  &lt;coap://[2001:db8::ab]/ace-group&gt;;if="ace.groups"
+</pre><a href="#section-4.1-3.1.6" class="pilcrow">¶</a>
+</div>
 </li>
           <li class="normal" id="section-4.1-3.2">
-            <p id="section-4.1-3.2.1">/ace-group/GROUPNAME : one such sub-resource to /ace-group is hosted for each group with name GROUPNAME that the KDC manages, and contains the symmetric group keying material for that group.<a href="#section-4.1-3.2.1" class="pilcrow">¶</a></p>
+            <p id="section-4.1-3.2.1">/ace-group/GROUPNAME : one such sub-resource to /ace-group is hosted for each group with name GROUPNAME that the KDC manages. In particular, it is the group-membership resource associated with that group, of which it contains the symmetric group keying material.<a href="#section-4.1-3.2.1" class="pilcrow">¶</a></p>
 <p id="section-4.1-3.2.2">
 A Client can access this resource in order to join the group with name GROUPNAME, or later as a group member to retrieve the current group keying material. These operations are described in <a href="#ssec-key-distribution-exchange" class="auto internal xref">Section 4.3.1.1</a> and <a href="#ssec-key-material-retrieval" class="auto internal xref">Section 4.3.2.1</a>, respectively.<a href="#section-4.1-3.2.2" class="pilcrow">¶</a></p>
 <p id="section-4.1-3.2.3">
-If the value of the GROUPNAME URI path and the group name in the access token scope ('gname' in <a href="#ssec-authorization-response" class="auto internal xref">Section 3.2</a>) are not required to coincide, the KDC MUST implement a mechanism to map the GROUPNAME value in the URI to the group name, in order to refer to the correct group (REQ7).<a href="#section-4.1-3.2.3" class="pilcrow">¶</a></p>
+The Interface Description (if=) Link Target Attribute value "ace.group" is registered in <a href="#if-ace-group" class="auto internal xref">Section 11.5</a> and can be used to describe the interface provided by a group-membership resource.<a href="#section-4.1-3.2.3" class="pilcrow">¶</a></p>
+<p id="section-4.1-3.2.4">
+The example below shows an exchange with a KDC with address 2001:db8::ab that hosts the group-membership resource /ace-group/gp1 and returns a link to such a resource in link-format <span>[<a href="#RFC6690" class="cite xref">RFC6690</a>]</span>.<a href="#section-4.1-3.2.4" class="pilcrow">¶</a></p>
+<div class="alignLeft art-text artwork" id="section-4.1-3.2.5">
+<pre>
+Request:
+
+Header: GET (Code=0.01)
+Uri-Host: "kdc.example.com"
+Uri-Path: ".well-known"
+Uri-Path: "core"
+Uri-Query: "if=ace.group"
+
+Response:
+
+Header: Content (Code=2.05)
+Content-Format: 40 (application/link-format)
+Payload:
+  &lt;coap://[2001:db8::ab]/ace-group/gp1&gt;;if="ace.group"
+</pre><a href="#section-4.1-3.2.5" class="pilcrow">¶</a>
+</div>
+<p id="section-4.1-3.2.6">
+If the value of the GROUPNAME URI path and the group name in the access token scope ('gname' in <a href="#ssec-authorization-response" class="auto internal xref">Section 3.2</a>) are not required to coincide, the KDC MUST implement a mechanism to map the GROUPNAME value in the URI to the group name, in order to refer to the correct group (REQ7).<a href="#section-4.1-3.2.6" class="pilcrow">¶</a></p>
 </li>
           <li class="normal" id="section-4.1-3.3">
             <p id="section-4.1-3.3.1">/ace-group/GROUPNAME/creds : the path of this resource is invariant once the resource is established. This resource contains the authentication credentials of all the members of the group with name GROUPNAME.<a href="#section-4.1-3.3.1" class="pilcrow">¶</a></p>
 <p id="section-4.1-3.3.2">
-This resource is created only in case the KDC acts as repository of authentication credentials for group members.<a href="#section-4.1-3.3.2" class="pilcrow">¶</a></p>
+This resource is created only in case the KDC acts as a repository of authentication credentials for group members.<a href="#section-4.1-3.3.2" class="pilcrow">¶</a></p>
 <p id="section-4.1-3.3.3">
 A Client can access this resource in order to retrieve the authentication credentials of other group members, in addition to when joining the group. That is, the Client can retrieve the authentication credentials of all the current group members, or a subset of them by specifying filter criteria. These operations are described in <a href="#sec-key-retrieval-all" class="auto internal xref">Section 4.4.2.1</a> and <a href="#sec-key-retrieval" class="auto internal xref">Section 4.4.1.1</a>, respectively.<a href="#section-4.1-3.3.3" class="pilcrow">¶</a></p>
 <p id="section-4.1-3.3.4">
@@ -2120,17 +2177,57 @@ <h4 id="name-error-handling">
 <p id="section-4.1.2-4">In case the KDC stores a valid access token but the verifications above fail, the KDC MUST reply with a 4.03 (Forbidden) error response. This response MAY be an AS Request Creation Hints, as defined in <span><a href="https://rfc-editor.org/rfc/rfc9200#section-5.3" class="relref">Section 5.3</a> of [<a href="#RFC9200" class="cite xref">RFC9200</a>]</span>, in which case the Content-Format MUST be set to application/ace+cbor.<a href="#section-4.1.2-4" class="pilcrow">¶</a></p>
 <p id="section-4.1.2-5">If the request is not formatted correctly (e.g., required fields are not present or are not encoded as expected), the handler MUST reply with a 4.00 (Bad Request) error response.<a href="#section-4.1.2-5" class="pilcrow">¶</a></p>
 <p id="section-4.1.2-6">If the request includes unknown or non-expected fields, the handler MUST silently ignore them and continue processing the request. Application profiles of this specification MAY define optional or mandatory payload formats for specific error cases (OPT4).<a href="#section-4.1.2-6" class="pilcrow">¶</a></p>
-<p id="section-4.1.2-7">Some error responses from the KDC can have Content-Format set to application/ace-groupcomm+cbor. In such a case, the payload of the response MUST be a CBOR map, which includes the following fields.<a href="#section-4.1.2-7" class="pilcrow">¶</a></p>
+<p id="section-4.1.2-7">Some error responses from the KDC can convey error-specific information according to the problem-details format defined in <span>[<a href="#RFC9290" class="cite xref">RFC9290</a>]</span>. Such error responses MUST have Content-Format set to application/concise-problem-details+cbor. The payload of these error responses MUST be a CBOR map specifying a Concise Problem Details data item (see <span><a href="https://rfc-editor.org/rfc/rfc9290#section-2" class="relref">Section 2</a> of [<a href="#RFC9290" class="cite xref">RFC9290</a>]</span>). The CBOR map is formatted as follows.<a href="#section-4.1.2-7" class="pilcrow">¶</a></p>
 <ul class="normal">
 <li class="normal" id="section-4.1.2-8.1">
-              <p id="section-4.1.2-8.1.1">'error', with value a CBOR integer specifying the error occurred at the KDC. The value is taken from the "Value" column of the "ACE Groupcomm Errors" registry defined in <a href="#iana-ace-groupcomm-errors" class="auto internal xref">Section 11.11</a> of this specification. This field MUST be present.<a href="#section-4.1.2-8.1.1" class="pilcrow">¶</a></p>
+              <p id="section-4.1.2-8.1.1">It MUST include the Custom Problem Detail entry 'ace-groupcomm-error' registered in <a href="#iana-custom-problem-details" class="auto internal xref">Section 11.6</a> of this document.<a href="#section-4.1.2-8.1.1" class="pilcrow">¶</a></p>
+<p id="section-4.1.2-8.1.2">
+This entry includes only one field, namely 'error-id'. The map key for 'error-id' is the CBOR unsigned integer with value 0. The value of 'error-id' is a CBOR integer specifying the error occurred at the KDC. This value is taken from the 'Value' column of the "ACE Groupcomm Errors" registry defined in <a href="#iana-ace-groupcomm-errors" class="auto internal xref">Section 11.12</a> of this document.<a href="#section-4.1.2-8.1.2" class="pilcrow">¶</a></p>
+<p id="section-4.1.2-8.1.3">
+The CDDL notation <span>[<a href="#RFC8610" class="cite xref">RFC8610</a>]</span> of the 'ace-groupcomm-error' entry is given below.<a href="#section-4.1.2-8.1.3" class="pilcrow">¶</a></p>
 </li>
-            <li class="normal" id="section-4.1.2-8.2">
-              <p id="section-4.1.2-8.2.1">'error_description', with value a CBOR text string specifying a human-readable diagnostic description of the error occurred at the KDC, written in English. The diagnostic text is intended for software engineers as well as for device and network operators, in order to aid debugging and provide context for possible intervention. The diagnostic message SHOULD be logged by the KDC. This field MAY be present, and it is unlikely relevant in an unattended setup where human intervention is not expected.<a href="#section-4.1.2-8.2.1" class="pilcrow">¶</a></p>
+          </ul>
+<div class="lang-CDDL sourcecode" id="section-4.1.2-9">
+<pre>
+   ace-groupcomm-error = {
+     &amp;(error-id: 0) =&gt; int
+   }
+</pre><a href="#section-4.1.2-9" class="pilcrow">¶</a>
+</div>
+<ul class="normal">
+<li class="normal" id="section-4.1.2-10.1">
+              <p id="section-4.1.2-10.1.1">It MAY include further Standard Problem Detail entries or Custom Problem Detail entries (see <span>[<a href="#RFC9290" class="cite xref">RFC9290</a>]</span>).<a href="#section-4.1.2-10.1.1" class="pilcrow">¶</a></p>
+<p id="section-4.1.2-10.1.2">
+In particular, it can include the Standard Problem Detail entry 'detail' (map key -2), whose value is a CBOR text string that specifies a human-readable, diagnostic description of the error occurred at the KDC. The diagnostic text is intended for software engineers as well as for device and network operators, in order to aid debugging and provide context for possible intervention. The diagnostic message SHOULD be logged by the KDC. The 'detail' entry is unlikely relevant in an unattended setup where human intervention is not expected.<a href="#section-4.1.2-10.1.2" class="pilcrow">¶</a></p>
 </li>
           </ul>
-<p id="section-4.1.2-9">The 'error' and 'error_description' fields are defined as OPTIONAL to support for Clients (see <a href="#params" class="auto internal xref">Section 8</a>). A Client supporting the 'error' parameter and able to understand the specified error may use that information to determine what actions to take next.<a href="#section-4.1.2-9" class="pilcrow">¶</a></p>
-<p id="section-4.1.2-10"><a href="#error-types" class="auto internal xref">Section 9</a> of this specification defines an initial set of error identifiers, as possible values for the 'error' field. Application profiles of this specification inherit this initial set of error identifiers and MAY define additional value (OPT5).<a href="#section-4.1.2-10" class="pilcrow">¶</a></p>
+<p id="section-4.1.2-11">An example of error response using the problem-details format is shown in <a href="#fig-exapmle-error-response" class="auto internal xref">Figure 6</a>.<a href="#section-4.1.2-11" class="pilcrow">¶</a></p>
+<span id="name-example-of-error-response-w"></span><div id="fig-exapmle-error-response">
+<figure id="figure-6">
+            <div class="alignLeft art-text artwork" id="section-4.1.2-12.1">
+<pre>
+Response:
+
+Header: Service Unavailable (Code=5.03)
+Content-Format: application/concise-problem-details+cbor
+Payload:
+{
+  / title /                -1: "No available node identifiers",
+  / detail /               -2: "Things will change after a
+                                group rekeying; try later",
+  / ace-groupcomm-error /  TBD: {
+    / error-id /  0: 4 / "No available node identifiers" /,
+  }
+}
+</pre>
+</div>
+<figcaption><a href="#figure-6" class="selfRef">Figure 6</a>:
+<a href="#name-example-of-error-response-w" class="selfRef">Example of Error Response with Problem Details</a>
+            </figcaption></figure>
+</div>
+<p id="section-4.1.2-13">Note to RFC Editor: In the figure above, please replace "TBD" with the unsigned integer assigned as key value to the Custom Problem Detail entry 'ace-groupcomm-error' (see <a href="#iana-custom-problem-details" class="auto internal xref">Section 11.6</a>). Then, please delete this paragraph.<a href="#section-4.1.2-13" class="pilcrow">¶</a></p>
+<p id="section-4.1.2-14">The problem-details format in general and the Custom Problem Detail entry 'ace-groupcomm-error' in particular are OPTIONAL to support for Clients. A Client supporting the entry 'ace-groupcomm-error' and able to understand the specified error may use that information to determine what actions to take next.<a href="#section-4.1.2-14" class="pilcrow">¶</a></p>
+<p id="section-4.1.2-15"><a href="#error-types" class="auto internal xref">Section 9</a> of this specification defines an initial set of error identifiers, as possible values for the 'error-id' field. Application profiles of this specification inherit this initial set of error identifiers and MAY define additional values (OPT5).<a href="#section-4.1.2-15" class="pilcrow">¶</a></p>
 </section>
 </div>
 </section>
@@ -2173,10 +2270,10 @@ <h4 id="name-fetch-handler">
             <h5 id="name-retrieve-group-names">
 <a href="#section-4.2.1.1" class="section-number selfRef">4.2.1.1. </a><a href="#name-retrieve-group-names" class="section-name selfRef">Retrieve Group Names</a>
             </h5>
-<p id="section-4.2.1.1-1">In case the joining node only knows the group identifier of the group it wishes to join or about which it wishes to get update information from the KDC, the node can contact the KDC to request the corresponding group name and group-membership resource URI. The node can request several group identifiers at once. It does so by sending a CoAP FETCH request to the /ace-group endpoint at the KDC formatted as defined in <a href="#ace-group-fetch" class="auto internal xref">Section 4.2.1</a>.<a href="#section-4.2.1.1-1" class="pilcrow">¶</a></p>
-<p id="section-4.2.1.1-2"><a href="#fig-ace-group-fetch" class="auto internal xref">Figure 6</a> gives an overview of the exchanges described above, and <a href="#fig-ace-group-fetch-2" class="auto internal xref">Figure 7</a> shows an example.<a href="#section-4.2.1.1-2" class="pilcrow">¶</a></p>
+<p id="section-4.2.1.1-1">In case the joining node only knows the group identifier of the group it wishes to join or about which it wishes to get updated information from the KDC, the node can contact the KDC to request the corresponding group name and group-membership resource URI. The node can request several group identifiers at once. It does so by sending a CoAP FETCH request to the /ace-group endpoint at the KDC formatted as defined in <a href="#ace-group-fetch" class="auto internal xref">Section 4.2.1</a>.<a href="#section-4.2.1.1-1" class="pilcrow">¶</a></p>
+<p id="section-4.2.1.1-2"><a href="#fig-ace-group-fetch" class="auto internal xref">Figure 7</a> gives an overview of the exchanges described above, and <a href="#fig-ace-group-fetch-2" class="auto internal xref">Figure 8</a> shows an example.<a href="#section-4.2.1.1-2" class="pilcrow">¶</a></p>
 <span id="name-message-flow-of-group-name-"></span><div id="fig-ace-group-fetch">
-<figure id="figure-6">
+<figure id="figure-7">
               <div class="alignCenter art-text artwork" id="section-4.2.1.1-3.1">
 <pre>
 Client                                                         KDC
@@ -2188,12 +2285,12 @@ <h5 id="name-retrieve-group-names">
    |                                                            |
 </pre>
 </div>
-<figcaption><a href="#figure-6" class="selfRef">Figure 6</a>:
+<figcaption><a href="#figure-7" class="selfRef">Figure 7</a>:
 <a href="#name-message-flow-of-group-name-" class="selfRef">Message Flow of Group Name and URI Retrieval Request-Response</a>
               </figcaption></figure>
 </div>
 <span id="name-example-of-group-name-and-u"></span><div id="fig-ace-group-fetch-2">
-<figure id="figure-7">
+<figure id="figure-8">
               <div class="alignLeft art-text artwork" id="section-4.2.1.1-4.1">
 <pre>
 Request:
@@ -2214,7 +2311,7 @@ <h5 id="name-retrieve-group-names">
     "guri": ["/ace-group/g1", "/ace-group/g2"] }
 </pre>
 </div>
-<figcaption><a href="#figure-7" class="selfRef">Figure 7</a>:
+<figcaption><a href="#figure-8" class="selfRef">Figure 8</a>:
 <a href="#name-example-of-group-name-and-u" class="selfRef">Example of Group Name and URI Retrieval Request-Response</a>
               </figcaption></figure>
 </div>
@@ -2261,13 +2358,13 @@ <h4 id="name-post-handler">
 </li>
               </ul>
 <p id="section-4.3.1-3.2.4">
-The CDDL definition <span>[<a href="#RFC8610" class="cite xref">RFC8610</a>]</span> of 'get_creds' is given in <a href="#cddl-ex-getpubkeys" class="auto internal xref">Figure 8</a>, using as example encoding: node identifier encoded as a CBOR byte string; role identifier encoded as a CBOR text string, and combination of roles encoded as a CBOR array of roles.<a href="#section-4.3.1-3.2.4" class="pilcrow">¶</a></p>
+The CDDL definition <span>[<a href="#RFC8610" class="cite xref">RFC8610</a>]</span> of 'get_creds' is given in <a href="#cddl-ex-getpubkeys" class="auto internal xref">Figure 9</a>, using as example encoding: node identifier encoded as a CBOR byte string; role identifier encoded as a CBOR text string, and combination of roles encoded as a CBOR array of roles.<a href="#section-4.3.1-3.2.4" class="pilcrow">¶</a></p>
 <p id="section-4.3.1-3.2.5">
 Note that, for this handler, 'inclusion_flag' is always set to true, the array of roles 'role_filter' is always non-empty, while the array of node identifiers 'id_filter' is always empty. However, this is not necessarily the case for other handlers using the 'get_creds' parameter.<a href="#section-4.3.1-3.2.5" class="pilcrow">¶</a></p>
 </li>
           </ul>
 <span id="name-cdll-definition-of-get_cred"></span><div id="cddl-ex-getpubkeys">
-<figure id="figure-8">
+<figure id="figure-9">
             <div class="lang-CDDL sourcecode" id="section-4.3.1-4.1">
 <pre>
 inclusion_flag = bool
@@ -2282,7 +2379,7 @@ <h4 id="name-post-handler">
 get_creds = null / [ inclusion_flag, role_filter, id_filter]
 </pre>
 </div>
-<figcaption><a href="#figure-8" class="selfRef">Figure 8</a>:
+<figcaption><a href="#figure-9" class="selfRef">Figure 9</a>:
 <a href="#name-cdll-definition-of-get_cred" class="selfRef">CDLL definition of get_creds, using as example node identifier encoded as bstr and role as tstr</a>
             </figcaption></figure>
 </div>
@@ -2309,7 +2406,7 @@ <h4 id="name-post-handler">
 </li>
               </ul>
 <p id="section-4.3.1-5.3.4">
-An example of PoP input to compute 'client_cred_verify' using CBOR encoding is given in <a href="#fig-client-cred-input" class="auto internal xref">Figure 9</a>.<a href="#section-4.3.1-5.3.4" class="pilcrow">¶</a></p>
+An example of PoP input to compute 'client_cred_verify' using CBOR encoding is given in <a href="#fig-client-cred-input" class="auto internal xref">Figure 10</a>.<a href="#section-4.3.1-5.3.4" class="pilcrow">¶</a></p>
 <p id="section-4.3.1-5.3.5">
 A possible type of PoP evidence is a signature that the Client computes by using its own private key, whose corresponding public key is specified in the authentication credential carried in the 'client_cred' parameter. Application profiles of this specification MUST specify the exact approaches used to compute the PoP evidence to include in 'client_cred_verify', and MUST specify which of those approaches is used in which case (REQ14).<a href="#section-4.3.1-5.3.5" class="pilcrow">¶</a></p>
 <p id="section-4.3.1-5.3.6">
@@ -2327,7 +2424,7 @@ <h4 id="name-post-handler">
 </li>
           </ul>
 <span id="name-example-of-pop-input-to-com"></span><div id="fig-client-cred-input">
-<figure id="figure-9">
+<figure id="figure-10">
             <div class="alignLeft art-text artwork" id="section-4.3.1-6.1">
 <pre>
 scope, N_S, and N_C expressed in CBOR diagnostic notation:
@@ -2346,7 +2443,7 @@ <h4 id="name-post-handler">
     48 018a278f7faab55a 48 25a8991cd700ac01
 </pre>
 </div>
-<figcaption><a href="#figure-9" class="selfRef">Figure 9</a>:
+<figcaption><a href="#figure-10" class="selfRef">Figure 10</a>:
 <a href="#name-example-of-pop-input-to-com" class="selfRef">Example of PoP input to compute 'client_cred_verify' using CBOR encoding</a>
             </figcaption></figure>
 </div>
@@ -2360,12 +2457,12 @@ <h4 id="name-post-handler">
             <li class="normal" id="section-4.3.1-10.2">
               <p id="section-4.3.1-10.2.1">The KDC checks the authentication credential to be valid for the group identified by GROUPNAME. That is, it checks that the authentication credential has the format used in the group, is intended for the public key algorithm used in the group, and is aligned with the possible associated parameters used in the group.<a href="#section-4.3.1-10.2.1" class="pilcrow">¶</a></p>
 <p id="section-4.3.1-10.2.2">
-If this verification fails, the handler MUST reply with a 4.00 (Bad Request) error response. The response MUST have Content-Format set to application/ace-groupcomm+cbor and is formatted as defined in <a href="#key-distr" class="auto internal xref">Section 4</a>. The value of the 'error' field MUST be set to 2 ("Authentication credential incompatible with the group configuration").<a href="#section-4.3.1-10.2.2" class="pilcrow">¶</a></p>
+If this verification fails, the handler MUST reply with a 4.00 (Bad Request) error response. The response MUST have Content-Format set to application/concise-problem-details+cbor and is formatted as defined in <a href="#kdc-if-errors" class="auto internal xref">Section 4.1.2</a>. Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' field  MUST be set to 2 ("Authentication credential incompatible with the group configuration").<a href="#section-4.3.1-10.2.2" class="pilcrow">¶</a></p>
 </li>
             <li class="normal" id="section-4.3.1-10.3">
               <p id="section-4.3.1-10.3.1">The KDC verifies the PoP evidence contained in the 'client_cred_verify' field. Application profiles of this specification MUST specify the exact approaches used to verify the PoP evidence, and MUST specify which of those approaches is used in which case (REQ14).<a href="#section-4.3.1-10.3.1" class="pilcrow">¶</a></p>
 <p id="section-4.3.1-10.3.2">
-If the PoP evidence does not pass verification, the handler MUST reply with a 4.00 (Bad Request) error response. The response MUST have Content-Format set to application/ace-groupcomm+cbor and is formatted as defined in <a href="#key-distr" class="auto internal xref">Section 4</a>. The value of the 'error' field MUST be set to 3 ("Invalid Proof-of-Possession evidence").<a href="#section-4.3.1-10.3.2" class="pilcrow">¶</a></p>
+If the PoP evidence does not pass verification, the handler MUST reply with a 4.00 (Bad Request) error response. The response MUST have Content-Format set to application/concise-problem-details+cbor and is formatted as defined in <a href="#kdc-if-errors" class="auto internal xref">Section 4.1.2</a>. Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' field  MUST be set to 3 ("Invalid Proof-of-Possession evidence").<a href="#section-4.3.1-10.3.2" class="pilcrow">¶</a></p>
 </li>
           </ul>
 <p id="section-4.3.1-11">If no authentication credential is included in the 'client_cred' field, the handler checks if an authentication credential is already associated with the received access token and to the group identified by GROUPNAME (see also <a href="#ssec-key-distribution-exchange" class="auto internal xref">Section 4.3.1.1</a>). Note that the same joining node may use different authentication credentials in different groups, and all those authentication credentials would be associated with the same access token.<a href="#section-4.3.1-11" class="pilcrow">¶</a></p>
@@ -2418,9 +2515,9 @@ <h4 id="name-post-handler">
               <p id="section-4.3.1-22.3.1">'num', containing the version number of the keying material for the group communication, formatted as an integer. This is a strictly monotonic increasing field. The application profile MUST define the initial version number (REQ16).<a href="#section-4.3.1-22.3.1" class="pilcrow">¶</a></p>
 </li>
           </ul>
-<p id="section-4.3.1-23">The exact format of the 'key' value MUST be defined in applications of this specification (REQ17), as well as values of 'gkty' accepted by the application (REQ18). Additionally, documents specifying the key format MUST register it in the "ACE Groupcomm Key Types" registry defined in <a href="#iana-key" class="auto internal xref">Section 11.7</a>, including its name, type, and application profile to be used with.<a href="#section-4.3.1-23" class="pilcrow">¶</a></p>
+<p id="section-4.3.1-23">The exact format of the 'key' value MUST be defined in applications of this specification (REQ17), as well as values of 'gkty' accepted by the application (REQ18). Additionally, documents specifying the key format MUST register it in the "ACE Groupcomm Key Types" registry defined in <a href="#iana-key" class="auto internal xref">Section 11.8</a>, including its name, type, and application profile to be used with.<a href="#section-4.3.1-23" class="pilcrow">¶</a></p>
 <span id="name-ace-groupcomm-key-types"></span><div id="fig-gkty">
-<figure id="figure-10">
+<figure id="figure-11">
             <div class="alignCenter art-text artwork" id="section-4.3.1-24.1">
 <pre>
 +----------+----------------+---------+-------------+------------+
@@ -2431,11 +2528,11 @@ <h4 id="name-post-handler">
 +----------+----------------+---------+-------------+------------+
 </pre>
 </div>
-<figcaption><a href="#figure-10" class="selfRef">Figure 10</a>:
+<figcaption><a href="#figure-11" class="selfRef">Figure 11</a>:
 <a href="#name-ace-groupcomm-key-types" class="selfRef">ACE Groupcomm Key Types</a>
             </figcaption></figure>
 </div>
-<p id="section-4.3.1-25">Note to RFC Editor: In <a href="#fig-gkty" class="auto internal xref">Figure 10</a>, please replace "[RFC-XXXX]" with the RFC number of this specification and delete this paragraph.<a href="#section-4.3.1-25" class="pilcrow">¶</a></p>
+<p id="section-4.3.1-25">Note to RFC Editor: In <a href="#fig-gkty" class="auto internal xref">Figure 11</a>, please replace "[RFC-XXXX]" with the RFC number of this specification and delete this paragraph.<a href="#section-4.3.1-25" class="pilcrow">¶</a></p>
 <p id="section-4.3.1-26">The response SHOULD contain the following parameter:<a href="#section-4.3.1-26" class="pilcrow">¶</a></p>
 <ul class="normal">
 <li class="normal" id="section-4.3.1-27.1">
@@ -2449,7 +2546,7 @@ <h4 id="name-post-handler">
 </li>
           </ul>
 <span id="name-ace-groupcomm-profiles"></span><div id="ace-groupcomm-profile-0">
-<figure id="figure-11">
+<figure id="figure-12">
             <div class="alignCenter art-text artwork" id="section-4.3.1-30.1">
 <pre>
 +----------+------------------------+------------+------------+
@@ -2459,11 +2556,11 @@ <h4 id="name-post-handler">
 +----------+------------------------+------------+------------+
 </pre>
 </div>
-<figcaption><a href="#figure-11" class="selfRef">Figure 11</a>:
+<figcaption><a href="#figure-12" class="selfRef">Figure 12</a>:
 <a href="#name-ace-groupcomm-profiles" class="selfRef">ACE Groupcomm Profiles</a>
             </figcaption></figure>
 </div>
-<p id="section-4.3.1-31">Note to RFC Editor: In <a href="#ace-groupcomm-profile-0" class="auto internal xref">Figure 11</a>, please replace "[RFC-XXXX]" with the RFC number of this specification and delete this paragraph.<a href="#section-4.3.1-31" class="pilcrow">¶</a></p>
+<p id="section-4.3.1-31">Note to RFC Editor: In <a href="#ace-groupcomm-profile-0" class="auto internal xref">Figure 12</a>, please replace "[RFC-XXXX]" with the RFC number of this specification and delete this paragraph.<a href="#section-4.3.1-31" class="pilcrow">¶</a></p>
 <ul class="normal">
 <li class="normal" id="section-4.3.1-32.1">
               <p id="section-4.3.1-32.1.1">'creds', MUST be present if 'get_creds' was present in the request, otherwise it MUST NOT be present. This parameter is a CBOR array specifying the authentication credentials of the group members, i.e., of all of them or of the ones selected according to the 'get_creds' parameter in the request. In particular, each element of the array is a CBOR byte string, with value the original binary representation of a group member's authentication credential. It is REQUIRED of the application profiles to define the specific formats of authentication credentials that are acceptable to use in the group (REQ6).<a href="#section-4.3.1-32.1.1" class="pilcrow">¶</a></p>
@@ -2476,14 +2573,14 @@ <h4 id="name-post-handler">
 When receiving the authentication credential of a Client in the 'client_cred' parameter of a Join Request (see <a href="#ssec-key-distribution-exchange" class="auto internal xref">Section 4.3.1.1</a>) or of an Authentication Credential Update Request (see <a href="#update-pub-key" class="auto internal xref">Section 4.9.1.1</a>), the KDC is not expected to check that the authentication credential indicates the role(s) that the Client can have or has in the group in question. When preparing a Join Response, the KDC can decide about including or not the 'peer_roles' parameter depending on the specific set of authentication credentials specified in the 'creds' parameter of that Join Response.<a href="#section-4.3.1-32.2.3" class="pilcrow">¶</a></p>
 </li>
             <li class="normal" id="section-4.3.1-32.3">
-              <p id="section-4.3.1-32.3.1">'peer_identifiers', MUST be present if 'creds' is also present, otherwise it MUST NOT be present. This parameter is a CBOR array of n elements, with n the number of authentication credentials included in the 'creds' parameter (at most the number of members in the group). The i-th element of the array specifies the node identifier that the group member associated with the i-th authentication credential in 'creds' has in the group. In particular, the i-th array element is encoded as a CBOR byte string, with value the node identifier of the group member.<a href="#section-4.3.1-32.3.1" class="pilcrow">¶</a></p>
+              <p id="section-4.3.1-32.3.1">'peer_identifiers', MUST be present if 'creds' is also present, otherwise it MUST NOT be present. This parameter is a CBOR array of n elements, with n the number of authentication credentials included in the 'creds' parameter (at most the number of members in the group). The i-th element of the array specifies the node identifier that the group member associated with the i-th authentication credential in 'creds' has in the group. In particular, the i-th array element is encoded as a CBOR byte string, with value the node identifier of the group member. The specific format of node identifiers of group members is specified by the application profile (REQ25).<a href="#section-4.3.1-32.3.1" class="pilcrow">¶</a></p>
 </li>
             <li class="normal" id="section-4.3.1-32.4">
-              <p id="section-4.3.1-32.4.1">'group_policies', with value a CBOR map, whose entries specify how the group handles specific management aspects. These include, for instance, approaches to achieve synchronization of sequence numbers among group members. The elements of this field are registered in the "ACE Groupcomm Policies" registry. This specification defines the three elements "Sequence Number Synchronization Methods", "Key Update Check Interval", and "Expiration Delta", which are summarized in <a href="#fig-ACE-Groupcomm-Policies" class="auto internal xref">Figure 12</a>. Application profiles that build on this document MUST specify the exact content format and default value of included map entries (REQ20).<a href="#section-4.3.1-32.4.1" class="pilcrow">¶</a></p>
+              <p id="section-4.3.1-32.4.1">'group_policies', with value a CBOR map, whose entries specify how the group handles specific management aspects. These include, for instance, approaches to achieve synchronization of sequence numbers among group members. The elements of this field are registered in the "ACE Groupcomm Policies" registry. This specification defines the three elements "Sequence Number Synchronization Methods", "Key Update Check Interval", and "Expiration Delta", which are summarized in <a href="#fig-ACE-Groupcomm-Policies" class="auto internal xref">Figure 13</a>. Application profiles that build on this document MUST specify the exact content format and default value of included map entries (REQ20).<a href="#section-4.3.1-32.4.1" class="pilcrow">¶</a></p>
 </li>
           </ul>
 <span id="name-ace-groupcomm-policies"></span><div id="fig-ACE-Groupcomm-Policies">
-<figure id="figure-12">
+<figure id="figure-13">
             <div class="alignCenter art-text artwork" id="section-4.3.1-33.1">
 <pre>
 +--------------+-------+----------+----------------------+------------+
@@ -2494,7 +2591,7 @@ <h4 id="name-post-handler">
 | Number       |       |          | group members to     |            |
 | Synchroniza- |       |          | synchronize with     |            |
 | tion Method  |       |          | sequence numbers of  |            |
-|              |       |          | of sender group      |            |
+|              |       |          | sender group         |            |
 |              |       |          | members. Its value   |            |
 |              |       |          | is taken from the    |            |
 |              |       |          | 'Value' column of    |            |
@@ -2522,11 +2619,11 @@ <h4 id="name-post-handler">
 +--------------+-------+----------|----------------------|------------+
 </pre>
 </div>
-<figcaption><a href="#figure-12" class="selfRef">Figure 12</a>:
+<figcaption><a href="#figure-13" class="selfRef">Figure 13</a>:
 <a href="#name-ace-groupcomm-policies" class="selfRef">ACE Groupcomm Policies</a>
             </figcaption></figure>
 </div>
-<p id="section-4.3.1-34">Note to RFC Editor: In <a href="#fig-ACE-Groupcomm-Policies" class="auto internal xref">Figure 12</a>, please replace all occurrences of "[RFC-XXXX]" with the RFC number of this specification and delete this paragraph.<a href="#section-4.3.1-34" class="pilcrow">¶</a></p>
+<p id="section-4.3.1-34">Note to RFC Editor: In <a href="#fig-ACE-Groupcomm-Policies" class="auto internal xref">Figure 13</a>, please replace all occurrences of "[RFC-XXXX]" with the RFC number of this specification and delete this paragraph.<a href="#section-4.3.1-34" class="pilcrow">¶</a></p>
 <ul class="normal">
 <li class="normal" id="section-4.3.1-35.1">
               <p id="section-4.3.1-35.1.1">'kdc_cred', encoded as a CBOR byte string, with value the original binary representation of the KDC's authentication credential. This parameter is used if the KDC has an associated authentication credential and this is required for the correct group operation. It is REQUIRED of application profiles to define whether the KDC has an authentication credential and if this has to be provided through the 'kdc_cred' parameter (REQ8).<a href="#section-4.3.1-35.1.1" class="pilcrow">¶</a></p>
@@ -2549,16 +2646,16 @@ <h4 id="name-post-handler">
 </li>
               </ul>
 <p id="section-4.3.1-35.3.4">
-An example of PoP input to compute 'kdc_cred_verify' using CBOR encoding is given in <a href="#fig-kdc-cred-input" class="auto internal xref">Figure 14</a>.<a href="#section-4.3.1-35.3.4" class="pilcrow">¶</a></p>
+An example of PoP input to compute 'kdc_cred_verify' using CBOR encoding is given in <a href="#fig-kdc-cred-input" class="auto internal xref">Figure 15</a>.<a href="#section-4.3.1-35.3.4" class="pilcrow">¶</a></p>
 <p id="section-4.3.1-35.3.5">
 A possible type of PoP evidence is a signature that the KDC computes by using its own private key, whose corresponding public key is specified in the authentication credential carried in the 'kdc_cred' parameter. Application profiles of this specification MUST specify the exact approaches used by the KDC to compute the PoP evidence to include in 'kdc_cred_verify', and MUST specify which of those approaches is used in which case (REQ21).<a href="#section-4.3.1-35.3.5" class="pilcrow">¶</a></p>
 </li>
             <li class="normal" id="section-4.3.1-35.4">
-              <p id="section-4.3.1-35.4.1">'rekeying_scheme', identifying the rekeying scheme that the KDC uses to provide new group keying meterial to the group members. This parameter is encoded as a CBOR integer, whose value is taken from the "Value" column of the "ACE Groupcomm Rekeying Schemes" registry defined in <a href="#iana-ace-groupcomm-rekeying-schemes" class="auto internal xref">Section 11.12</a> of this specification.<a href="#section-4.3.1-35.4.1" class="pilcrow">¶</a></p>
+              <p id="section-4.3.1-35.4.1">'rekeying_scheme', identifying the rekeying scheme that the KDC uses to provide new group keying meterial to the group members. This parameter is encoded as a CBOR integer, whose value is taken from the "Value" column of the "ACE Groupcomm Rekeying Schemes" registry defined in <a href="#iana-ace-groupcomm-rekeying-schemes" class="auto internal xref">Section 11.13</a> of this specification.<a href="#section-4.3.1-35.4.1" class="pilcrow">¶</a></p>
 </li>
           </ul>
 <span id="name-ace-groupcomm-rekeying-sche"></span><div id="rekeying-scheme-0">
-<figure id="figure-13">
+<figure id="figure-14">
             <div class="alignCenter art-text artwork" id="section-4.3.1-36.1">
 <pre>
 +-------+----------------+-------------------------------+------------+
@@ -2571,12 +2668,12 @@ <h4 id="name-post-handler">
 +-------+----------------+-------------------------------+------------+
 </pre>
 </div>
-<figcaption><a href="#figure-13" class="selfRef">Figure 13</a>:
+<figcaption><a href="#figure-14" class="selfRef">Figure 14</a>:
 <a href="#name-ace-groupcomm-rekeying-sche" class="selfRef">ACE Groupcomm Rekeying Schemes</a>
             </figcaption></figure>
 </div>
 <p id="section-4.3.1-37">Application profiles of this specification MAY define a default group rekeying scheme, to refer to in case the 'rekeying_scheme' parameter is not included in the Join Response (OPT9).<a href="#section-4.3.1-37" class="pilcrow">¶</a></p>
-<p id="section-4.3.1-38">Note to RFC Editor: In <a href="#rekeying-scheme-0" class="auto internal xref">Figure 13</a>, please replace "[RFC-XXXX]" with the RFC number of this specification and delete this paragraph.<a href="#section-4.3.1-38" class="pilcrow">¶</a></p>
+<p id="section-4.3.1-38">Note to RFC Editor: In <a href="#rekeying-scheme-0" class="auto internal xref">Figure 14</a>, please replace "[RFC-XXXX]" with the RFC number of this specification and delete this paragraph.<a href="#section-4.3.1-38" class="pilcrow">¶</a></p>
 <ul class="normal">
 <li class="normal" id="section-4.3.1-39.1">
               <p id="section-4.3.1-39.1.1">'mgt_key_material', encoded as a CBOR byte string and containing the specific administrative keying material that the joining node requires in order to participate in the group rekeying process performed by the KDC. This parameter MUST NOT be present if the 'rekeying_scheme' parameter is not present and the application profile does not specify a default group rekeying scheme to use in the group. Some simple rekeying scheme may not require specific administrative keying material to be provided, e.g., the basic "Point-to-Point" group rekeying scheme (see <a href="#point-to-point-rekeying" class="auto internal xref">Section 6.1</a>).<a href="#section-4.3.1-39.1.1" class="pilcrow">¶</a></p>
@@ -2596,7 +2693,7 @@ <h4 id="name-post-handler">
 </li>
           </ul>
 <span id="name-example-of-pop-input-to-comp"></span><div id="fig-kdc-cred-input">
-<figure id="figure-14">
+<figure id="figure-15">
             <div class="alignLeft art-text artwork" id="section-4.3.1-40.1">
 <pre>
 N_C and N_KDC expressed in CBOR diagnostic notation:
@@ -2612,7 +2709,7 @@ <h4 id="name-post-handler">
   0x48 25a8991cd700ac01 48 cef04b2aa791bc6d
 </pre>
 </div>
-<figcaption><a href="#figure-14" class="selfRef">Figure 14</a>:
+<figcaption><a href="#figure-15" class="selfRef">Figure 15</a>:
 <a href="#name-example-of-pop-input-to-comp" class="selfRef">Example of PoP input to compute 'kdc_cred_verify' using CBOR encoding</a>
             </figcaption></figure>
 </div>
@@ -2624,9 +2721,9 @@ <h4 id="name-post-handler">
             <h5 id="name-join-the-group">
 <a href="#section-4.3.1.1" class="section-number selfRef">4.3.1.1. </a><a href="#name-join-the-group" class="section-name selfRef">Join the Group</a>
             </h5>
-<p id="section-4.3.1.1-1"><a href="#fig-key-distr-join" class="auto internal xref">Figure 15</a> gives an overview of the join exchange between the Client and the KDC, when the Client first joins a group, while <a href="#fig-key-distr-join-2" class="auto internal xref">Figure 16</a> shows an example.<a href="#section-4.3.1.1-1" class="pilcrow">¶</a></p>
+<p id="section-4.3.1.1-1"><a href="#fig-key-distr-join" class="auto internal xref">Figure 16</a> gives an overview of the join exchange between the Client and the KDC, when the Client first joins a group, while <a href="#fig-key-distr-join-2" class="auto internal xref">Figure 17</a> shows an example.<a href="#section-4.3.1.1-1" class="pilcrow">¶</a></p>
 <span id="name-message-flow-of-the-join-re"></span><div id="fig-key-distr-join">
-<figure id="figure-15">
+<figure id="figure-16">
               <div class="alignCenter art-text artwork" id="section-4.3.1.1-2.1">
 <pre>
 Client                                                     KDC
@@ -2637,12 +2734,12 @@ <h5 id="name-join-the-group">
    | Location-Path = "/ace-group/GROUPNAME/nodes/NODENAME"  |
 </pre>
 </div>
-<figcaption><a href="#figure-15" class="selfRef">Figure 15</a>:
+<figcaption><a href="#figure-16" class="selfRef">Figure 16</a>:
 <a href="#name-message-flow-of-the-join-re" class="selfRef">Message Flow of the Join Request-Response</a>
               </figcaption></figure>
 </div>
 <span id="name-example-of-first-join-reque"></span><div id="fig-key-distr-join-2">
-<figure id="figure-16">
+<figure id="figure-17">
               <div class="alignCenter art-text artwork" id="section-4.3.1.1-3.1">
 <pre>
 Request:
@@ -2674,7 +2771,7 @@ <h5 id="name-join-the-group">
     "peer_identifiers": [ ID1, ID2 ] }
 </pre>
 </div>
-<figcaption><a href="#figure-16" class="selfRef">Figure 16</a>:
+<figcaption><a href="#figure-17" class="selfRef">Figure 17</a>:
 <a href="#name-example-of-first-join-reque" class="selfRef">Example of First Join Request-Response for Group Joining</a>
               </figcaption></figure>
 </div>
@@ -2694,7 +2791,7 @@ <h4 id="name-get-handler">
           </h4>
 <p id="section-4.3.2-1">The GET handler returns the symmetric group keying material for the group identified by GROUPNAME.<a href="#section-4.3.2-1" class="pilcrow">¶</a></p>
 <p id="section-4.3.2-2">The handler expects a GET request.<a href="#section-4.3.2-2" class="pilcrow">¶</a></p>
-<p id="section-4.3.2-3">In addition to what is defined in <a href="#kdc-if-errors" class="auto internal xref">Section 4.1.2</a>, the handler verifies that the Client is a current member of the group. If the verification fails, the KDC MUST reply with a 4.03 (Forbidden) error response. The response MUST have Content-Format set to application/ace-groupcomm+cbor and is formatted as defined in <a href="#key-distr" class="auto internal xref">Section 4</a>. The value of the 'error' field MUST be set to 0 ("Operation permitted only to group members").<a href="#section-4.3.2-3" class="pilcrow">¶</a></p>
+<p id="section-4.3.2-3">In addition to what is defined in <a href="#kdc-if-errors" class="auto internal xref">Section 4.1.2</a>, the handler verifies that the Client is a current member of the group. If the verification fails, the KDC MUST reply with a 4.03 (Forbidden) error response. The response MUST have Content-Format set to application/concise-problem-details+cbor and is formatted as defined in <a href="#kdc-if-errors" class="auto internal xref">Section 4.1.2</a>. Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' field  MUST be set to 0 ("Operation permitted only to group members").<a href="#section-4.3.2-3" class="pilcrow">¶</a></p>
 <p id="section-4.3.2-4">If all verifications succeed, the handler replies with a 2.05 (Content) response containing the symmetric group keying material. The payload of the response is formatted as a CBOR map which MUST contain the parameters 'gkty', 'key', and 'num' specified in <a href="#gid-post" class="auto internal xref">Section 4.3.1</a>.<a href="#section-4.3.2-4" class="pilcrow">¶</a></p>
 <p id="section-4.3.2-5">Each of the following parameters specified in <a href="#gid-post" class="auto internal xref">Section 4.3.1</a> MUST also be included in the payload of the response, if they are included in the payload of the Join Responses sent for the group: 'rekeying_scheme', 'mgt_key_material'.<a href="#section-4.3.2-5" class="pilcrow">¶</a></p>
 <p id="section-4.3.2-6">The payload MAY also include the parameters 'ace_groupcomm_profile' and 'exp' parameters specified in <a href="#gid-post" class="auto internal xref">Section 4.3.1</a>.<a href="#section-4.3.2-6" class="pilcrow">¶</a></p>
@@ -2704,9 +2801,9 @@ <h5 id="name-retrieve-group-keying-mater">
 <a href="#section-4.3.2.1" class="section-number selfRef">4.3.2.1. </a><a href="#name-retrieve-group-keying-mater" class="section-name selfRef">Retrieve Group Keying Material</a>
             </h5>
 <p id="section-4.3.2.1-1">A node in the group can contact the KDC to retrieve the current group keying material, by sending a CoAP GET request to the /ace-group/GROUPNAME endpoint at the KDC, where GROUPNAME is the group name.<a href="#section-4.3.2.1-1" class="pilcrow">¶</a></p>
-<p id="section-4.3.2.1-2"><a href="#fig-retrieve-key-material" class="auto internal xref">Figure 17</a> gives an overview of the join exchange between the Client and the KDC, when the Client first joins a group, while <a href="#fig-retrieve-key-material-2" class="auto internal xref">Figure 18</a> shows an example.<a href="#section-4.3.2.1-2" class="pilcrow">¶</a></p>
+<p id="section-4.3.2.1-2"><a href="#fig-retrieve-key-material" class="auto internal xref">Figure 18</a> gives an overview of the join exchange between the Client and the KDC, when the Client first joins a group, while <a href="#fig-retrieve-key-material-2" class="auto internal xref">Figure 19</a> shows an example.<a href="#section-4.3.2.1-2" class="pilcrow">¶</a></p>
 <span id="name-message-flow-of-key-distrib"></span><div id="fig-retrieve-key-material">
-<figure id="figure-17">
+<figure id="figure-18">
               <div class="alignCenter art-text artwork" id="section-4.3.2.1-3.1">
 <pre>
 Client                                                              KDC
@@ -2717,12 +2814,12 @@ <h5 id="name-retrieve-group-keying-mater">
    |                                                                 |
 </pre>
 </div>
-<figcaption><a href="#figure-17" class="selfRef">Figure 17</a>:
+<figcaption><a href="#figure-18" class="selfRef">Figure 18</a>:
 <a href="#name-message-flow-of-key-distrib" class="selfRef">Message Flow of Key Distribution Request-Response</a>
               </figcaption></figure>
 </div>
 <span id="name-example-of-key-distribution"></span><div id="fig-retrieve-key-material-2">
-<figure id="figure-18">
+<figure id="figure-19">
               <div class="alignLeft art-text artwork" id="section-4.3.2.1-4.1">
 <pre>
 Request:
@@ -2742,7 +2839,7 @@ <h5 id="name-retrieve-group-keying-mater">
   { "gkty": 13, "key": KEY, "num": 12 }
 </pre>
 </div>
-<figcaption><a href="#figure-18" class="selfRef">Figure 18</a>:
+<figcaption><a href="#figure-19" class="selfRef">Figure 19</a>:
 <a href="#name-example-of-key-distribution" class="selfRef">Example of Key Distribution Request-Response</a>
               </figcaption></figure>
 </div>
@@ -2842,9 +2939,9 @@ <h5 id="name-retrieve-a-subset-of-authen">
 <a href="#section-4.4.1.1" class="section-number selfRef">4.4.1.1. </a><a href="#name-retrieve-a-subset-of-authen" class="section-name selfRef">Retrieve a Subset of Authentication Credentials in the Group</a>
             </h5>
 <p id="section-4.4.1.1-1">In case the KDC maintains the authentication credentials of group members, a node in the group can contact the KDC to request the authentication credentials, roles, and node identifiers of a specified subset of group members, by sending a CoAP FETCH request to the /ace-group/GROUPNAME/creds endpoint at the KDC, where GROUPNAME is the group name, and formatted as defined in <a href="#pubkey-fetch" class="auto internal xref">Section 4.4.1</a>.<a href="#section-4.4.1.1-1" class="pilcrow">¶</a></p>
-<p id="section-4.4.1.1-2"><a href="#fig-public-key-1" class="auto internal xref">Figure 19</a> gives an overview of the exchange mentioned above, while <a href="#fig-public-key-2" class="auto internal xref">Figure 20</a> shows an example of such an exchange.<a href="#section-4.4.1.1-2" class="pilcrow">¶</a></p>
+<p id="section-4.4.1.1-2"><a href="#fig-public-key-1" class="auto internal xref">Figure 20</a> gives an overview of the exchange mentioned above, while <a href="#fig-public-key-2" class="auto internal xref">Figure 21</a> shows an example of such an exchange.<a href="#section-4.4.1.1-2" class="pilcrow">¶</a></p>
 <span id="name-message-flow-of-authenticat"></span><div id="fig-public-key-1">
-<figure id="figure-19">
+<figure id="figure-20">
               <div class="alignCenter art-text artwork" id="section-4.4.1.1-3.1">
 <pre>
 Client                                                      KDC
@@ -2857,12 +2954,12 @@ <h5 id="name-retrieve-a-subset-of-authen">
    |                                                         |
 </pre>
 </div>
-<figcaption><a href="#figure-19" class="selfRef">Figure 19</a>:
+<figcaption><a href="#figure-20" class="selfRef">Figure 20</a>:
 <a href="#name-message-flow-of-authenticat" class="selfRef">Message Flow of Authentication Credential Request-Response to Obtain the Authentication Credentials of Specific Group Members</a>
               </figcaption></figure>
 </div>
 <span id="name-example-of-authentication-c"></span><div id="fig-public-key-2">
-<figure id="figure-20">
+<figure id="figure-21">
               <div class="alignLeft art-text artwork" id="section-4.4.1.1-4.1">
 <pre>
 Request:
@@ -2874,19 +2971,19 @@ <h5 id="name-retrieve-a-subset-of-authen">
 Uri-Path: "pub-key"
 Content-Format: "application/ace-groupcomm+cbor"
 Payload:
-  { "get_creds": [true, [], [ ID3 ]] }
+  { "get_creds": [true, [], [ ID2, ID3 ]] }
 
 Response:
 
 Header: Content (Code=2.05)
 Content-Format: "application/ace-groupcomm+cbor"
 Payload (in CBOR diagnostic notation):
-  { "creds": [ AUTH_CRED_3 ],
-    "peer_roles": [ "receiver" ],
-    "peer_identifiers": [ ID3 ] }
+  { "creds": [ AUTH_CRED_2, AUTH_CRED_3, ],
+    "peer_roles": [ ["sender", "receiver"], "receiver" ],
+    "peer_identifiers": [ ID2, ID3 ] }
 </pre>
 </div>
-<figcaption><a href="#figure-20" class="selfRef">Figure 20</a>:
+<figcaption><a href="#figure-21" class="selfRef">Figure 21</a>:
 <a href="#name-example-of-authentication-c" class="selfRef">Example of Authentication Credential Request-Response to Obtain the Authentication Credentials of Specific Group Members</a>
               </figcaption></figure>
 </div>
@@ -2908,9 +3005,9 @@ <h5 id="name-retrieve-all-authentication">
 <a href="#section-4.4.2.1" class="section-number selfRef">4.4.2.1. </a><a href="#name-retrieve-all-authentication" class="section-name selfRef">Retrieve All Authentication Credentials in the Group</a>
             </h5>
 <p id="section-4.4.2.1-1">In case the KDC maintains the authentication credentials of group members, a group or an external signature verifier can contact the KDC to request the authentication credentials, roles, and node identifiers of all the current group members, by sending a CoAP GET request to the /ace-group/GROUPNAME/creds endpoint at the KDC, where GROUPNAME is the group name.<a href="#section-4.4.2.1-1" class="pilcrow">¶</a></p>
-<p id="section-4.4.2.1-2"><a href="#fig-public-key-3" class="auto internal xref">Figure 21</a> gives an overview of the message exchange, while <a href="#fig-public-key-4" class="auto internal xref">Figure 22</a> shows an example of such an exchange.<a href="#section-4.4.2.1-2" class="pilcrow">¶</a></p>
+<p id="section-4.4.2.1-2"><a href="#fig-public-key-3" class="auto internal xref">Figure 22</a> gives an overview of the message exchange, while <a href="#fig-public-key-4" class="auto internal xref">Figure 23</a> shows an example of such an exchange.<a href="#section-4.4.2.1-2" class="pilcrow">¶</a></p>
 <span id="name-message-flow-of-authenticati"></span><div id="fig-public-key-3">
-<figure id="figure-21">
+<figure id="figure-22">
               <div class="alignCenter art-text artwork" id="section-4.4.2.1-3.1">
 <pre>
 Client                                                      KDC
@@ -2923,12 +3020,12 @@ <h5 id="name-retrieve-all-authentication">
    |                                                         |
 </pre>
 </div>
-<figcaption><a href="#figure-21" class="selfRef">Figure 21</a>:
+<figcaption><a href="#figure-22" class="selfRef">Figure 22</a>:
 <a href="#name-message-flow-of-authenticati" class="selfRef">Message Flow of Authentication Credential Request-Response to Obtain the Authentication Credentials of all the Group Members</a>
               </figcaption></figure>
 </div>
 <span id="name-example-of-authentication-cr"></span><div id="fig-public-key-4">
-<figure id="figure-22">
+<figure id="figure-23">
               <div class="alignLeft art-text artwork" id="section-4.4.2.1-4.1">
 <pre>
 Request:
@@ -2951,7 +3048,7 @@ <h5 id="name-retrieve-all-authentication">
     "peer_identifiers": [ ID1, ID2, ID3 ] }
 </pre>
 </div>
-<figcaption><a href="#figure-22" class="selfRef">Figure 22</a>:
+<figcaption><a href="#figure-23" class="selfRef">Figure 23</a>:
 <a href="#name-example-of-authentication-cr" class="selfRef">Example of Authentication Credential Request-Response to Obtain the Authentication Credentials of all the Group Members</a>
               </figcaption></figure>
 </div>
@@ -2992,7 +3089,7 @@ <h4 id="name-get-handler-3">
 </li>
               </ul>
 <p id="section-4.5.1-3.3.3">
-An example of PoP input to compute 'kdc_cred_verify' using CBOR encoding is given in <a href="#fig-kdc-cred-input-2" class="auto internal xref">Figure 23</a>.<a href="#section-4.5.1-3.3.3" class="pilcrow">¶</a></p>
+An example of PoP input to compute 'kdc_cred_verify' using CBOR encoding is given in <a href="#fig-kdc-cred-input-2" class="auto internal xref">Figure 24</a>.<a href="#section-4.5.1-3.3.3" class="pilcrow">¶</a></p>
 <p id="section-4.5.1-3.3.4">
 The PoP evidence is computed by means of the same method used for computing the PoP evidence that was included in the Join Response for this Client (see <a href="#gid-post" class="auto internal xref">Section 4.3.1</a>).<a href="#section-4.5.1-3.3.4" class="pilcrow">¶</a></p>
 <p id="section-4.5.1-3.3.5">
@@ -3000,7 +3097,7 @@ <h4 id="name-get-handler-3">
 </li>
           </ul>
 <span id="name-example-of-pop-input-to-compu"></span><div id="fig-kdc-cred-input-2">
-<figure id="figure-23">
+<figure id="figure-24">
             <div class="alignLeft art-text artwork" id="section-4.5.1-4.1">
 <pre>
 N_C and N_KDC expressed in CBOR diagnostic notation:
@@ -3016,7 +3113,7 @@ <h4 id="name-get-handler-3">
   0x48 25a8991cd700ac01 48 0b7db12aaff56da3
 </pre>
 </div>
-<figcaption><a href="#figure-23" class="selfRef">Figure 23</a>:
+<figcaption><a href="#figure-24" class="selfRef">Figure 24</a>:
 <a href="#name-example-of-pop-input-to-compu" class="selfRef">Example of PoP input to compute 'kdc_cred_verify' using CBOR encoding</a>
             </figcaption></figure>
 </div>
@@ -3028,9 +3125,9 @@ <h5 id="name-retrieve-the-kdcs-authentic">
 <p id="section-4.5.1.1-1">In case the KDC has an associated authentication credential as required for the correct group operation, a group member or an external signature verifier can contact the KDC to request the KDC's authentication credential, by sending a CoAP GET request to the /ace-group/GROUPNAME/kdc-cred endpoint at the KDC, where GROUPNAME is the group name.<a href="#section-4.5.1.1-1" class="pilcrow">¶</a></p>
 <p id="section-4.5.1.1-2">Upon receiving the 2.05 (Content) response, the Client retrieves the KDC's authentication credential from the ’kdc_cred’ parameter, and MUST verify the proof-of-possession (PoP) evidence specified in the 'kdc_cred_verify' parameter. In case of successful verification of the PoP evidence, the Client MUST store the obtained KDC's authentication credential and replace the currently stored one.<a href="#section-4.5.1.1-2" class="pilcrow">¶</a></p>
 <p id="section-4.5.1.1-3">The PoP evidence is verified by means of the same method used when processing the Join Response (see <a href="#gid-post" class="auto internal xref">Section 4.3.1</a>). Application profiles of this specification MUST specify the exact approaches used by the Client to verify the PoP evidence in 'kdc_cred_verify', and MUST specify which of those approaches is used in which case (REQ21).<a href="#section-4.5.1.1-3" class="pilcrow">¶</a></p>
-<p id="section-4.5.1.1-4"><a href="#fig-kdc-pub-key-req-resp" class="auto internal xref">Figure 24</a> gives an overview of the exchange described above, while <a href="#fig-kdc-pub-key-req-resp-ex" class="auto internal xref">Figure 25</a> shows an example.<a href="#section-4.5.1.1-4" class="pilcrow">¶</a></p>
+<p id="section-4.5.1.1-4"><a href="#fig-kdc-pub-key-req-resp" class="auto internal xref">Figure 25</a> gives an overview of the exchange described above, while <a href="#fig-kdc-pub-key-req-resp-ex" class="auto internal xref">Figure 26</a> shows an example.<a href="#section-4.5.1.1-4" class="pilcrow">¶</a></p>
 <span id="name-message-flow-of-kdc-authent"></span><div id="fig-kdc-pub-key-req-resp">
-<figure id="figure-24">
+<figure id="figure-25">
               <div class="alignCenter art-text artwork" id="section-4.5.1.1-5.1">
 <pre>
 Group
@@ -3044,12 +3141,12 @@ <h5 id="name-retrieve-the-kdcs-authentic">
   |                                                             |
 </pre>
 </div>
-<figcaption><a href="#figure-24" class="selfRef">Figure 24</a>:
+<figcaption><a href="#figure-25" class="selfRef">Figure 25</a>:
 <a href="#name-message-flow-of-kdc-authent" class="selfRef">Message Flow of KDC Authentication Credential Request-Response to Obtain the Authentication Credential of the KDC</a>
               </figcaption></figure>
 </div>
 <span id="name-example-of-kdc-authenticati"></span><div id="fig-kdc-pub-key-req-resp-ex">
-<figure id="figure-25">
+<figure id="figure-26">
               <div class="alignLeft art-text artwork" id="section-4.5.1.1-6.1">
 <pre>
 Request:
@@ -3074,7 +3171,7 @@ <h5 id="name-retrieve-the-kdcs-authentic">
   }
 </pre>
 </div>
-<figcaption><a href="#figure-25" class="selfRef">Figure 25</a>:
+<figcaption><a href="#figure-26" class="selfRef">Figure 26</a>:
 <a href="#name-example-of-kdc-authenticati" class="selfRef">Example of KDC Authentication Credential Request-Response to Obtain the Authentication Credential of the KDC</a>
               </figcaption></figure>
 </div>
@@ -3096,7 +3193,7 @@ <h4 id="name-get-handler-4">
 <a href="#section-4.6.1" class="section-number selfRef">4.6.1. </a><a href="#name-get-handler-4" class="section-name selfRef">GET Handler</a>
           </h4>
 <p id="section-4.6.1-1">The handler expects a GET request.<a href="#section-4.6.1-1" class="pilcrow">¶</a></p>
-<p id="section-4.6.1-2">In addition to what is defined in <a href="#kdc-if-errors" class="auto internal xref">Section 4.1.2</a>, the handler verifies that the Client is a current member of the group. If the verification fails, the KDC MUST reply with a 4.03 (Forbidden) error response. The response MUST have Content-Format set to application/ace-groupcomm+cbor and is formatted as defined in <a href="#key-distr" class="auto internal xref">Section 4</a>. The value of the 'error' field MUST be set to 0 ("Operation permitted only to group members").<a href="#section-4.6.1-2" class="pilcrow">¶</a></p>
+<p id="section-4.6.1-2">In addition to what is defined in <a href="#kdc-if-errors" class="auto internal xref">Section 4.1.2</a>, the handler verifies that the Client is a current member of the group. If the verification fails, the KDC MUST reply with a 4.03 (Forbidden) error response. The response MUST have Content-Format set to application/concise-problem-details+cbor and is formatted as defined in <a href="#kdc-if-errors" class="auto internal xref">Section 4.1.2</a>. Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' field  MUST be set to 0 ("Operation permitted only to group members").<a href="#section-4.6.1-2" class="pilcrow">¶</a></p>
 <p id="section-4.6.1-3">If all verifications succeed, the handler replies with a 2.05 (Content) response containing the list of policies for the group identified by GROUPNAME. The payload of the response is formatted as a CBOR map including only the parameter 'group_policies' defined in <a href="#gid-post" class="auto internal xref">Section 4.3.1</a> and specifying the current policies in the group. If the KDC does not store any policy, the payload is formatted as a zero-length CBOR byte string.<a href="#section-4.6.1-3" class="pilcrow">¶</a></p>
 <p id="section-4.6.1-4">The specific format and meaning of group policies MUST be specified in the application profile (REQ20).<a href="#section-4.6.1-4" class="pilcrow">¶</a></p>
 <div id="policies">
@@ -3105,9 +3202,9 @@ <h5 id="name-retrieve-the-group-policies">
 <a href="#section-4.6.1.1" class="section-number selfRef">4.6.1.1. </a><a href="#name-retrieve-the-group-policies" class="section-name selfRef">Retrieve the Group Policies</a>
             </h5>
 <p id="section-4.6.1.1-1">A node in the group can contact the KDC to retrieve the current group policies, by sending a CoAP GET request to the /ace-group/GROUPNAME/policies endpoint at the KDC, where GROUPNAME is the group name, and formatted as defined in <a href="#policies-get" class="auto internal xref">Section 4.6.1</a><a href="#section-4.6.1.1-1" class="pilcrow">¶</a></p>
-<p id="section-4.6.1.1-2"><a href="#fig-policies" class="auto internal xref">Figure 26</a> gives an overview of the exchange described above, while <a href="#fig-policies-2" class="auto internal xref">Figure 27</a> shows an example.<a href="#section-4.6.1.1-2" class="pilcrow">¶</a></p>
+<p id="section-4.6.1.1-2"><a href="#fig-policies" class="auto internal xref">Figure 27</a> gives an overview of the exchange described above, while <a href="#fig-policies-2" class="auto internal xref">Figure 28</a> shows an example.<a href="#section-4.6.1.1-2" class="pilcrow">¶</a></p>
 <span id="name-message-flow-of-policies-re"></span><div id="fig-policies">
-<figure id="figure-26">
+<figure id="figure-27">
               <div class="alignCenter art-text artwork" id="section-4.6.1.1-3.1">
 <pre>
 Client                                                       KDC
@@ -3118,12 +3215,12 @@ <h5 id="name-retrieve-the-group-policies">
    |                                                          |
 </pre>
 </div>
-<figcaption><a href="#figure-26" class="selfRef">Figure 26</a>:
+<figcaption><a href="#figure-27" class="selfRef">Figure 27</a>:
 <a href="#name-message-flow-of-policies-re" class="selfRef">Message Flow of Policies Request-Response</a>
               </figcaption></figure>
 </div>
 <span id="name-example-of-policies-request"></span><div id="fig-policies-2">
-<figure id="figure-27">
+<figure id="figure-28">
               <div class="alignLeft art-text artwork" id="section-4.6.1.1-4.1">
 <pre>
 Request:
@@ -3143,7 +3240,7 @@ <h5 id="name-retrieve-the-group-policies">
   { "group_policies": {"exp-delta": 120} }
 </pre>
 </div>
-<figcaption><a href="#figure-27" class="selfRef">Figure 27</a>:
+<figcaption><a href="#figure-28" class="selfRef">Figure 28</a>:
 <a href="#name-example-of-policies-request" class="selfRef">Example of Policies Request-Response</a>
               </figcaption></figure>
 </div>
@@ -3165,7 +3262,7 @@ <h4 id="name-get-handler-5">
 <a href="#section-4.7.1" class="section-number selfRef">4.7.1. </a><a href="#name-get-handler-5" class="section-name selfRef">GET Handler</a>
           </h4>
 <p id="section-4.7.1-1">The handler expects a GET request.<a href="#section-4.7.1-1" class="pilcrow">¶</a></p>
-<p id="section-4.7.1-2">In addition to what is defined in <a href="#kdc-if-errors" class="auto internal xref">Section 4.1.2</a>, the handler verifies that the Client is a current member of the group. If the verification fails, the KDC MUST reply with a 4.03 (Forbidden) error response. The response MUST have Content-Format set to application/ace-groupcomm+cbor and is formatted as defined in <a href="#key-distr" class="auto internal xref">Section 4</a>. The value of the 'error' field MUST be set to 0 ("Operation permitted only to group members").<a href="#section-4.7.1-2" class="pilcrow">¶</a></p>
+<p id="section-4.7.1-2">In addition to what is defined in <a href="#kdc-if-errors" class="auto internal xref">Section 4.1.2</a>, the handler verifies that the Client is a current member of the group. If the verification fails, the KDC MUST reply with a 4.03 (Forbidden) error response. The response MUST have Content-Format set to application/concise-problem-details+cbor and is formatted as defined in <a href="#kdc-if-errors" class="auto internal xref">Section 4.1.2</a>. Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' field  MUST be set to 0 ("Operation permitted only to group members").<a href="#section-4.7.1-2" class="pilcrow">¶</a></p>
 <p id="section-4.7.1-3">If all verifications succeed, the handler returns a 2.05 (Content) message containing an integer that represents the version number of the symmetric group keying material. This number is incremented on the KDC every time the KDC updates the symmetric group keying material, before the new keying material is distributed. This number is stored in persistent storage.<a href="#section-4.7.1-3" class="pilcrow">¶</a></p>
 <p id="section-4.7.1-4">The payload of the response is formatted as a CBOR integer.<a href="#section-4.7.1-4" class="pilcrow">¶</a></p>
 <div id="key-version">
@@ -3174,9 +3271,9 @@ <h5 id="name-retrieve-the-keying-materia">
 <a href="#section-4.7.1.1" class="section-number selfRef">4.7.1.1. </a><a href="#name-retrieve-the-keying-materia" class="section-name selfRef">Retrieve the Keying Material Version</a>
             </h5>
 <p id="section-4.7.1.1-1">A node in the group can contact the KDC to request information about the version number of the symmetric group keying material, by sending a CoAP GET request to the /ace-group/GROUPNAME/num endpoint at the KDC, where GROUPNAME is the group name, formatted as defined in <a href="#num-get" class="auto internal xref">Section 4.7.1</a>. In particular, the version is incremented by the KDC every time the group keying material is renewed, before it's distributed to the group members.<a href="#section-4.7.1.1-1" class="pilcrow">¶</a></p>
-<p id="section-4.7.1.1-2"><a href="#fig-version" class="auto internal xref">Figure 28</a> gives an overview of the exchange described above, while <a href="#fig-version-2" class="auto internal xref">Figure 29</a> shows an example.<a href="#section-4.7.1.1-2" class="pilcrow">¶</a></p>
+<p id="section-4.7.1.1-2"><a href="#fig-version" class="auto internal xref">Figure 29</a> gives an overview of the exchange described above, while <a href="#fig-version-2" class="auto internal xref">Figure 30</a> shows an example.<a href="#section-4.7.1.1-2" class="pilcrow">¶</a></p>
 <span id="name-message-flow-of-version-req"></span><div id="fig-version">
-<figure id="figure-28">
+<figure id="figure-29">
               <div class="alignCenter art-text artwork" id="section-4.7.1.1-3.1">
 <pre>
 Client                                                     KDC
@@ -3187,12 +3284,12 @@ <h5 id="name-retrieve-the-keying-materia">
    |                                                        |
 </pre>
 </div>
-<figcaption><a href="#figure-28" class="selfRef">Figure 28</a>:
+<figcaption><a href="#figure-29" class="selfRef">Figure 29</a>:
 <a href="#name-message-flow-of-version-req" class="selfRef">Message Flow of Version Request-Response</a>
               </figcaption></figure>
 </div>
 <span id="name-example-of-version-request-"></span><div id="fig-version-2">
-<figure id="figure-29">
+<figure id="figure-30">
               <div class="alignLeft art-text artwork" id="section-4.7.1.1-4.1">
 <pre>
 Request:
@@ -3212,7 +3309,7 @@ <h5 id="name-retrieve-the-keying-materia">
   13
 </pre>
 </div>
-<figcaption><a href="#figure-29" class="selfRef">Figure 29</a>:
+<figcaption><a href="#figure-30" class="selfRef">Figure 30</a>:
 <a href="#name-example-of-version-request-" class="selfRef">Example of Version Request-Response</a>
               </figcaption></figure>
 </div>
@@ -3231,7 +3328,7 @@ <h3 id="name-ace-group-groupname-nodes-n">
 <p id="section-4.8-2">In addition to what is defined in <a href="#kdc-if-errors" class="auto internal xref">Section 4.1.2</a>, each of the handlers performs the following two verifications.<a href="#section-4.8-2" class="pilcrow">¶</a></p>
 <ul class="normal">
 <li class="normal" id="section-4.8-3.1">
-            <p id="section-4.8-3.1.1">The handler verifies that the Client is a current member of the group. If the verification fails, the KDC MUST reply with a 4.03 (Forbidden) error response. The response MUST have Content-Format set to application/ace-groupcomm+cbor and is formatted as defined in <a href="#key-distr" class="auto internal xref">Section 4</a>. The value of the 'error' field MUST be set to 0 ("Operation permitted only to group members").<a href="#section-4.8-3.1.1" class="pilcrow">¶</a></p>
+            <p id="section-4.8-3.1.1">The handler verifies that the Client is a current member of the group. If the verification fails, the KDC MUST reply with a 4.03 (Forbidden) error response. The response MUST have Content-Format set to application/concise-problem-details+cbor and is formatted as defined in <a href="#kdc-if-errors" class="auto internal xref">Section 4.1.2</a>. Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' field  MUST be set to 0 ("Operation permitted only to group members").<a href="#section-4.8-3.1.1" class="pilcrow">¶</a></p>
 </li>
           <li class="normal" id="section-4.8-3.2">
             <p id="section-4.8-3.2.1">The handler verifies that the node name of the Client is equal to NODENAME used in the url-path. If the verification fails, the handler replies with a 4.03 (Forbidden) error response.<a href="#section-4.8-3.2.1" class="pilcrow">¶</a></p>
@@ -3243,7 +3340,7 @@ <h4 id="name-get-handler-6">
 <a href="#section-4.8.1" class="section-number selfRef">4.8.1. </a><a href="#name-get-handler-6" class="section-name selfRef">GET Handler</a>
           </h4>
 <p id="section-4.8.1-1">The handler expects a GET request.<a href="#section-4.8.1-1" class="pilcrow">¶</a></p>
-<p id="section-4.8.1-2">If all verifications succeed, the handler replies with a 2.05 (Content) response containing both the group keying material and the individual keying material for the Client, or information enabling the Client to derive it. The payload of the response is formatted as a CBOR map. The format for the group keying material is the same as defined in the response of <a href="#gid-get" class="auto internal xref">Section 4.3.2</a>. The specific format of individual keying material for group members, or of the information to derive it, and corresponding CBOR label, MUST be specified in the application profile (REQ27) and registered in <a href="#iana-reg" class="auto internal xref">Section 11.6</a>.<a href="#section-4.8.1-2" class="pilcrow">¶</a></p>
+<p id="section-4.8.1-2">If all verifications succeed, the handler replies with a 2.05 (Content) response containing both the group keying material and the individual keying material for the Client, or information enabling the Client to derive it. The payload of the response is formatted as a CBOR map. The format for the group keying material is the same as defined in the response of <a href="#gid-get" class="auto internal xref">Section 4.3.2</a>. The specific format of individual keying material for group members, or of the information to derive it, and corresponding CBOR label, MUST be specified in the application profile (REQ27) and registered in <a href="#iana-reg" class="auto internal xref">Section 11.7</a>.<a href="#section-4.8.1-2" class="pilcrow">¶</a></p>
 <p id="section-4.8.1-3">Optionally, the KDC can make the sub-resource at /ace-group/GROUPNAME/nodes/NODENAME also Observable <span>[<a href="#RFC7641" class="cite xref">RFC7641</a>]</span> for the associated node. In case the KDC removes that node from the group without having been explicitly asked for it, this allows the KDC to send an unsolicited 4.04 (Not Found) response to the node as a notification of eviction from the group (see <a href="#sec-node-removal" class="auto internal xref">Section 5</a>).<a href="#section-4.8.1-3" class="pilcrow">¶</a></p>
 <p id="section-4.8.1-4">Note that the node could have also been observing the resource at /ace-group/GROUPNAME, in order to be informed of changes in the keying material. In such a case, this method would result in largely overlapping notifications received for the resource at /ace-group/GROUPNAME and the sub-resource at /ace-group/GROUPNAME/nodes/NODENAME.<a href="#section-4.8.1-4" class="pilcrow">¶</a></p>
 <p id="section-4.8.1-5">In order to mitigate this, a node that supports the No-Response option <span>[<a href="#RFC7967" class="cite xref">RFC7967</a>]</span> can use it when starting the observation of the sub-resource at /ace-group/GROUPNAME/nodes/NODENAME. In particular, the GET observation request can also include the No-Response option, with value set to 2 (Not interested in 2.xx responses).<a href="#section-4.8.1-5" class="pilcrow">¶</a></p>
@@ -3269,9 +3366,9 @@ <h5 id="name-retrieve-group-and-individu">
 <p id="section-4.8.1.1-5">It is application dependent and pertaining to the particular message exchange (e.g., <span>[<a href="#I-D.ietf-core-oscore-groupcomm" class="cite xref">I-D.ietf-core-oscore-groupcomm</a>]</span>) to set up these policies for instructing Clients to retain incoming messages and for how long (OPT11). This allows Clients to possibly decrypt such messages after getting updated keying material, rather than just consider them non valid messages to discard right away.<a href="#section-4.8.1.1-5" class="pilcrow">¶</a></p>
 <p id="section-4.8.1.1-6">After having failed to decrypt messages from another group member and having sent a Key Distribution Request to the KDC, the Client might end up retrieving the same, latest group keying material that it already stores. In such a case, multiple failed decryptions might be due to the message sender and/or the KDC that have changed their authentication credential. Hence, the Client can retrieve such latest authentication credentials, by sending to the KDC an Authentication Credential Request (see <a href="#sec-key-retrieval" class="auto internal xref">Section 4.4.1.1</a> and <a href="#sec-key-retrieval-all" class="auto internal xref">Section 4.4.2.1</a>) and a KDC Authentication Credential Request (see <a href="#kdc-pub-key" class="auto internal xref">Section 4.5.1.1</a>), respectively.<a href="#section-4.8.1.1-6" class="pilcrow">¶</a></p>
 <p id="section-4.8.1.1-7">The Client can also send to the KDC a Key Distribution Request without having been triggered by a failed decryption of a message from another group member, if the Client wants to be sure that it currently stores the latest group keying material. If that is the case, the Client will receive from the KDC the same group keying material it already stores.<a href="#section-4.8.1.1-7" class="pilcrow">¶</a></p>
-<p id="section-4.8.1.1-8"><a href="#fig-key-redistr-req-resp" class="auto internal xref">Figure 30</a> gives an overview of the exchange described above, while <a href="#fig-key-redistr-req-resp-2" class="auto internal xref">Figure 31</a> shows an example.<a href="#section-4.8.1.1-8" class="pilcrow">¶</a></p>
+<p id="section-4.8.1.1-8"><a href="#fig-key-redistr-req-resp" class="auto internal xref">Figure 31</a> gives an overview of the exchange described above, while <a href="#fig-key-redistr-req-resp-2" class="auto internal xref">Figure 32</a> shows an example.<a href="#section-4.8.1.1-8" class="pilcrow">¶</a></p>
 <span id="name-message-flow-of-key-distribu"></span><div id="fig-key-redistr-req-resp">
-<figure id="figure-30">
+<figure id="figure-31">
               <div class="alignCenter art-text artwork" id="section-4.8.1.1-9.1">
 <pre>
 Client                                                          KDC
@@ -3283,12 +3380,12 @@ <h5 id="name-retrieve-group-and-individu">
    |                                                             |
 </pre>
 </div>
-<figcaption><a href="#figure-30" class="selfRef">Figure 30</a>:
+<figcaption><a href="#figure-31" class="selfRef">Figure 31</a>:
 <a href="#name-message-flow-of-key-distribu" class="selfRef">Message Flow of Key Distribution Request-Response</a>
               </figcaption></figure>
 </div>
 <span id="name-example-of-key-distribution-"></span><div id="fig-key-redistr-req-resp-2">
-<figure id="figure-31">
+<figure id="figure-32">
               <div class="alignLeft art-text artwork" id="section-4.8.1.1-10.1">
 <pre>
 Request:
@@ -3312,7 +3409,7 @@ <h5 id="name-retrieve-group-and-individu">
   { "gkty": 13, "key": KEY, "num": 12, "ind-key": IND_KEY }
 </pre>
 </div>
-<figcaption><a href="#figure-31" class="selfRef">Figure 31</a>:
+<figcaption><a href="#figure-32" class="selfRef">Figure 32</a>:
 <a href="#name-example-of-key-distribution-" class="selfRef">Example of Key Distribution Request-Response</a>
               </figcaption></figure>
 </div>
@@ -3327,9 +3424,9 @@ <h4 id="name-put-handler">
           </h4>
 <p id="section-4.8.2-1">The PUT handler processes requests from a Client that asks for new individual keying material, as required to process messages exchanged in the group.<a href="#section-4.8.2-1" class="pilcrow">¶</a></p>
 <p id="section-4.8.2-2">The handler expects a PUT request with empty payload.<a href="#section-4.8.2-2" class="pilcrow">¶</a></p>
-<p id="section-4.8.2-3">In addition to what is defined in <a href="#kdc-if-errors" class="auto internal xref">Section 4.1.2</a> and at the beginning of <a href="#node-subresource" class="auto internal xref">Section 4.8</a>, the handler verifies that this operation is consistent with the set of roles that the Client has in the group (REQ11). If the verification fails, the KDC MUST reply with a 4.00 (Bad Request) error response. The response MUST have Content-Format set to application/ace-groupcomm+cbor and is formatted as defined in <a href="#key-distr" class="auto internal xref">Section 4</a>. The value of the 'error' field MUST be set to 1 ("Request inconsistent with the current roles").<a href="#section-4.8.2-3" class="pilcrow">¶</a></p>
-<p id="section-4.8.2-4">If the KDC is currently not able to serve this request, i.e., to generate new individual keying material for the requesting Client, the KDC MUST reply with a 5.03 (Service Unavailable) error response. The response MUST have Content-Format set to application/ace-groupcomm+cbor and is formatted as defined in <a href="#key-distr" class="auto internal xref">Section 4</a>. The value of the 'error' field MUST be set to 4 ("No available node identifiers").<a href="#section-4.8.2-4" class="pilcrow">¶</a></p>
-<p id="section-4.8.2-5">If all verifications succeed, the handler replies with a 2.05 (Content) response containing newly generated, individual keying material for the Client. The payload of the response is formatted as a CBOR map. The specific format of newly-generated individual keying material for group members, or of the information to derive it, and corresponding CBOR label, MUST be specified in the application profile (REQ27) and registered in <a href="#iana-reg" class="auto internal xref">Section 11.6</a>.<a href="#section-4.8.2-5" class="pilcrow">¶</a></p>
+<p id="section-4.8.2-3">In addition to what is defined in <a href="#kdc-if-errors" class="auto internal xref">Section 4.1.2</a> and at the beginning of <a href="#node-subresource" class="auto internal xref">Section 4.8</a>, the handler verifies that this operation is consistent with the set of roles that the Client has in the group (REQ11). If the verification fails, the KDC MUST reply with a 4.00 (Bad Request) error response. The response MUST have Content-Format set to application/concise-problem-details+cbor and is formatted as defined in <a href="#kdc-if-errors" class="auto internal xref">Section 4.1.2</a>. Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' field  MUST be set to 1 ("Request inconsistent with the current roles").<a href="#section-4.8.2-3" class="pilcrow">¶</a></p>
+<p id="section-4.8.2-4">If the KDC is currently not able to serve this request, i.e., to generate new individual keying material for the requesting Client, the KDC MUST reply with a 5.03 (Service Unavailable) error response. The response MUST have Content-Format set to application/concise-problem-details+cbor and is formatted as defined in <a href="#kdc-if-errors" class="auto internal xref">Section 4.1.2</a>. Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' field  MUST be set to 4 ("No available node identifiers").<a href="#section-4.8.2-4" class="pilcrow">¶</a></p>
+<p id="section-4.8.2-5">If all verifications succeed, the handler replies with a 2.05 (Content) response containing newly generated, individual keying material for the Client. The payload of the response is formatted as a CBOR map. The specific format of newly-generated individual keying material for group members, or of the information to derive it, and corresponding CBOR label, MUST be specified in the application profile (REQ27) and registered in <a href="#iana-reg" class="auto internal xref">Section 11.7</a>.<a href="#section-4.8.2-5" class="pilcrow">¶</a></p>
 <p id="section-4.8.2-6">The typical successful outcome consists in replying with newly generated, individual keying material for the Client, as defined above. However, application profiles of this specification MAY also extend this handler in order to achieve different akin outcomes (OPT12), for instance:<a href="#section-4.8.2-6" class="pilcrow">¶</a></p>
 <ul class="normal">
 <li class="normal" id="section-4.8.2-7.1">
@@ -3348,9 +3445,9 @@ <h5 id="name-request-to-change-individua">
             </h5>
 <p id="section-4.8.2.1-1">A Client may ask the KDC for new, individual keying material. For instance, this can be due to the expiration of such individual keying material, or to the exhaustion of AEAD nonces, if an AEAD encryption algorithm is used for protecting communications in the group. An example of individual keying material can simply be an individual encryption key associated with the Client. Hence, the Client may ask for a new individual encryption key, or for new input material to derive it.<a href="#section-4.8.2.1-1" class="pilcrow">¶</a></p>
 <p id="section-4.8.2.1-2">To this end, the Client performs a Key Renewal Request-Response exchange with the KDC, i.e., it sends a CoAP PUT request to the /ace-group/GROUPNAME/nodes/NODENAME endpoint at the KDC, where GROUPNAME is the group name and NODENAME is its node name, and formatted as defined in <a href="#node-get" class="auto internal xref">Section 4.8.1</a>.<a href="#section-4.8.2.1-2" class="pilcrow">¶</a></p>
-<p id="section-4.8.2.1-3"><a href="#fig-renewal-req-resp" class="auto internal xref">Figure 32</a> gives an overview of the exchange described above, while <a href="#fig-renewal-req-resp-2" class="auto internal xref">Figure 33</a> shows an example.<a href="#section-4.8.2.1-3" class="pilcrow">¶</a></p>
+<p id="section-4.8.2.1-3"><a href="#fig-renewal-req-resp" class="auto internal xref">Figure 33</a> gives an overview of the exchange described above, while <a href="#fig-renewal-req-resp-2" class="auto internal xref">Figure 34</a> shows an example.<a href="#section-4.8.2.1-3" class="pilcrow">¶</a></p>
 <span id="name-message-flow-of-key-renewal"></span><div id="fig-renewal-req-resp">
-<figure id="figure-32">
+<figure id="figure-33">
               <div class="alignCenter art-text artwork" id="section-4.8.2.1-4.1">
 <pre>
 Client                                                    KDC
@@ -3362,12 +3459,12 @@ <h5 id="name-request-to-change-individua">
    |                                                       |
 </pre>
 </div>
-<figcaption><a href="#figure-32" class="selfRef">Figure 32</a>:
+<figcaption><a href="#figure-33" class="selfRef">Figure 33</a>:
 <a href="#name-message-flow-of-key-renewal" class="selfRef">Message Flow of Key Renewal Request-Response</a>
               </figcaption></figure>
 </div>
 <span id="name-example-of-key-renewal-requ"></span><div id="fig-renewal-req-resp-2">
-<figure id="figure-33">
+<figure id="figure-34">
               <div class="alignLeft art-text artwork" id="section-4.8.2.1-5.1">
 <pre>
 Request:
@@ -3390,7 +3487,7 @@ <h5 id="name-request-to-change-individua">
   { "ind-key": IND_KEY }
 </pre>
 </div>
-<figcaption><a href="#figure-33" class="selfRef">Figure 33</a>:
+<figcaption><a href="#figure-34" class="selfRef">Figure 34</a>:
 <a href="#name-example-of-key-renewal-requ" class="selfRef">Example of Key Renewal Request-Response</a>
               </figcaption></figure>
 </div>
@@ -3407,7 +3504,7 @@ <h4 id="name-delete-handler">
           </h4>
 <p id="section-4.8.3-1">The DELETE handler removes the node identified by NODENAME from the group identified by GROUPNAME.<a href="#section-4.8.3-1" class="pilcrow">¶</a></p>
 <p id="section-4.8.3-2">The handler expects a DELETE request with empty payload.<a href="#section-4.8.3-2" class="pilcrow">¶</a></p>
-<p id="section-4.8.3-3">In addition to what is defined in <a href="#kdc-if-errors" class="auto internal xref">Section 4.1.2</a>, the handler verifies that the Client is a current member of the group. If the verification fails, the KDC MUST reply with a 4.03 (Forbidden) error response. The response MUST have Content-Format set to application/ace-groupcomm+cbor and is formatted as defined in <a href="#key-distr" class="auto internal xref">Section 4</a>. The value of the 'error' field MUST be set to 0 ("Operation permitted only to group members").<a href="#section-4.8.3-3" class="pilcrow">¶</a></p>
+<p id="section-4.8.3-3">In addition to what is defined in <a href="#kdc-if-errors" class="auto internal xref">Section 4.1.2</a>, the handler verifies that the Client is a current member of the group. If the verification fails, the KDC MUST reply with a 4.03 (Forbidden) error response. The response MUST have Content-Format set to application/concise-problem-details+cbor and is formatted as defined in <a href="#kdc-if-errors" class="auto internal xref">Section 4.1.2</a>. Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' field  MUST be set to 0 ("Operation permitted only to group members").<a href="#section-4.8.3-3" class="pilcrow">¶</a></p>
 <p id="section-4.8.3-4">If all verification succeeds, the handler performs the actions defined in <a href="#sec-node-removal" class="auto internal xref">Section 5</a> and replies with a 2.02 (Deleted) response with empty payload.<a href="#section-4.8.3-4" class="pilcrow">¶</a></p>
 <div id="ssec-group-leaving">
 <section id="section-4.8.3.1">
@@ -3436,12 +3533,12 @@ <h4 id="name-post-handler-2">
 <p id="section-4.9.1-1">The POST handler is used to replace the stored authentication credential of this Client (identified by NODENAME) with the one specified in the request at the KDC, for the group identified by GROUPNAME.<a href="#section-4.9.1-1" class="pilcrow">¶</a></p>
 <p id="section-4.9.1-2">The handler expects a POST request with payload as specified in <a href="#gid-post" class="auto internal xref">Section 4.3.1</a>, with the difference that it includes only the parameters 'client_cred', 'cnonce', and 'client_cred_verify'.<a href="#section-4.9.1-2" class="pilcrow">¶</a></p>
 <p id="section-4.9.1-3">The PoP evidence included in the 'client_cred_verify' parameter is computed in the same way considered in <a href="#gid-post" class="auto internal xref">Section 4.3.1</a> and defined by the specific application profile (REQ14), by using the following to build the PoP input: i) the same scope specified by the Client in the 'scope' parameter of the original Join Request; ii) the latest N_S value stored by the Client; iii) a new N_C nonce generated by the Client and specified in the parameter 'client_cred' of this request.<a href="#section-4.9.1-3" class="pilcrow">¶</a></p>
-<p id="section-4.9.1-4">An example of PoP input to compute 'client_cred_verify' using CBOR encoding is given in <a href="#fig-client-cred-input-2" class="auto internal xref">Figure 34</a>.<a href="#section-4.9.1-4" class="pilcrow">¶</a></p>
+<p id="section-4.9.1-4">An example of PoP input to compute 'client_cred_verify' using CBOR encoding is given in <a href="#fig-client-cred-input-2" class="auto internal xref">Figure 35</a>.<a href="#section-4.9.1-4" class="pilcrow">¶</a></p>
 <p id="section-4.9.1-5">It is REQUIRED of the application profiles to define the specific formats of authentication credentials that are acceptable to use in the group (REQ6).<a href="#section-4.9.1-5" class="pilcrow">¶</a></p>
-<p id="section-4.9.1-6">In addition to what is defined in <a href="#kdc-if-errors" class="auto internal xref">Section 4.1.2</a> and at the beginning of <a href="#node-subresource" class="auto internal xref">Section 4.8</a>, the handler verifies that this operation is consistent with the set of roles that the node has in the group. If the verification fails, the KDC MUST reply with a 4.00 (Bad Request) error response. The response MUST have Content-Format set to application/ace-groupcomm+cbor and is formatted as defined in <a href="#key-distr" class="auto internal xref">Section 4</a>. The value of the 'error' field MUST be set to 1 ("Request inconsistent with the current roles").<a href="#section-4.9.1-6" class="pilcrow">¶</a></p>
+<p id="section-4.9.1-6">In addition to what is defined in <a href="#kdc-if-errors" class="auto internal xref">Section 4.1.2</a> and at the beginning of <a href="#node-subresource" class="auto internal xref">Section 4.8</a>, the handler verifies that this operation is consistent with the set of roles that the node has in the group. If the verification fails, the KDC MUST reply with a 4.00 (Bad Request) error response. The response MUST have Content-Format set to application/concise-problem-details+cbor and is formatted as defined in <a href="#kdc-if-errors" class="auto internal xref">Section 4.1.2</a>. Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' field  MUST be set to 1 ("Request inconsistent with the current roles").<a href="#section-4.9.1-6" class="pilcrow">¶</a></p>
 <p id="section-4.9.1-7">If the KDC cannot retrieve the 'kdcchallenge' associated with this Client (see <a href="#token-post" class="auto internal xref">Section 3.3</a>), the KDC MUST reply with a 4.00 (Bad Request) error response, which MUST also have Content-Format application/ace-groupcomm+cbor. The payload of the error response is a CBOR map including a newly generated 'kdcchallenge' value. This is specified in the 'kdcchallenge' parameter. In such a case the KDC MUST store the newly generated value as the 'kdcchallenge' value associated with this Client, replacing the currently stored value (if any).<a href="#section-4.9.1-7" class="pilcrow">¶</a></p>
-<p id="section-4.9.1-8">Otherwise, the handler checks that the authentication credential specified in the 'client_cred' field is valid for the group identified by GROUPNAME. That is, the handler checks that the authentication credential is encoded according to the format used in the group, is intended for the public key algorithm used in the group, and is aligned with the possible associated parameters used in the group. If that cannot be successfully verified, the handler MUST reply with a 4.00 (Bad Request) error response. The response MUST have Content-Format set to application/ace-groupcomm+cbor and is formatted as defined in <a href="#key-distr" class="auto internal xref">Section 4</a>. The value of the 'error' field MUST be set to 2 ("Authentication Credential incompatible with the group configuration").<a href="#section-4.9.1-8" class="pilcrow">¶</a></p>
-<p id="section-4.9.1-9">Otherwise, the handler verifies the PoP evidence contained in the 'client_cred_verify' field of the request, by using the authentication credential specified in the 'client_cred' field, as well as the same way considered in <a href="#gid-post" class="auto internal xref">Section 4.3.1</a> and defined by the specific application profile (REQ14). If the PoP evidence does not pass verification, the handler MUST reply with a 4.00 (Bad Request) error response. The response MUST have Content-Format set to application/ace-groupcomm+cbor and is formatted as defined in <a href="#key-distr" class="auto internal xref">Section 4</a>. The value of the 'error' field MUST be set to 3 ("Invalid Proof-of-Possession evidence").<a href="#section-4.9.1-9" class="pilcrow">¶</a></p>
+<p id="section-4.9.1-8">Otherwise, the handler checks that the authentication credential specified in the 'client_cred' field is valid for the group identified by GROUPNAME. That is, the handler checks that the authentication credential is encoded according to the format used in the group, is intended for the public key algorithm used in the group, and is aligned with the possible associated parameters used in the group. If that cannot be successfully verified, the handler MUST reply with a 4.00 (Bad Request) error response. The response MUST have Content-Format set to application/concise-problem-details+cbor and is formatted as defined in <a href="#kdc-if-errors" class="auto internal xref">Section 4.1.2</a>. Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' field  MUST be set to 2 ("Authentication credential incompatible with the group configuration").<a href="#section-4.9.1-8" class="pilcrow">¶</a></p>
+<p id="section-4.9.1-9">Otherwise, the handler verifies the PoP evidence contained in the 'client_cred_verify' field of the request, by using the authentication credential specified in the 'client_cred' field, as well as the same way considered in <a href="#gid-post" class="auto internal xref">Section 4.3.1</a> and defined by the specific application profile (REQ14). If the PoP evidence does not pass verification, the handler MUST reply with a 4.00 (Bad Request) error response. The response MUST have Content-Format set to application/concise-problem-details+cbor and is formatted as defined in <a href="#kdc-if-errors" class="auto internal xref">Section 4.1.2</a>. Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' field  MUST be set to 3 ("Invalid Proof-of-Possession evidence").<a href="#section-4.9.1-9" class="pilcrow">¶</a></p>
 <p id="section-4.9.1-10">If all verifications succeed, the handler performs the following actions.<a href="#section-4.9.1-10" class="pilcrow">¶</a></p>
 <ul class="normal">
 <li class="normal" id="section-4.9.1-11.1">
@@ -3453,7 +3550,7 @@ <h4 id="name-post-handler-2">
           </ul>
 <p id="section-4.9.1-12">Then, the handler replies with a 2.04 (Changed) response, which does not include a payload.<a href="#section-4.9.1-12" class="pilcrow">¶</a></p>
 <span id="name-example-of-pop-input-to-comput"></span><div id="fig-client-cred-input-2">
-<figure id="figure-34">
+<figure id="figure-35">
             <div class="alignLeft art-text artwork" id="section-4.9.1-13.1">
 <pre>
 scope, N_S, and N_C expressed in CBOR diagnostic notation:
@@ -3472,7 +3569,7 @@ <h4 id="name-post-handler-2">
     48 018a278f7faab55a 48 0446baefc56111bf
 </pre>
 </div>
-<figcaption><a href="#figure-34" class="selfRef">Figure 34</a>:
+<figcaption><a href="#figure-35" class="selfRef">Figure 35</a>:
 <a href="#name-example-of-pop-input-to-comput" class="selfRef">Example of PoP input to compute 'client_cred_verify' using CBOR encoding</a>
             </figcaption></figure>
 </div>
@@ -3484,9 +3581,9 @@ <h5 id="name-uploading-a-authentication-">
 <p id="section-4.9.1.1-1">In case the KDC maintains the authentication credentials of group members, a node in the group can contact the KDC to upload a new authentication credential to use in the group, and to replace the currently stored one.<a href="#section-4.9.1.1-1" class="pilcrow">¶</a></p>
 <p id="section-4.9.1.1-2">To this end, the Client performs an Authentication Credential Update Request-Response exchange with the KDC, i.e., it sends a CoAP POST request to the /ace-group/GROUPNAME/nodes/NODENAME/cred endpoint at the KDC, where GROUPNAME is the group name and NODENAME is its node name.<a href="#section-4.9.1.1-2" class="pilcrow">¶</a></p>
 <p id="section-4.9.1.1-3">The request is formatted as specified in <a href="#node-pub-key-post" class="auto internal xref">Section 4.9.1</a>.<a href="#section-4.9.1.1-3" class="pilcrow">¶</a></p>
-<p id="section-4.9.1.1-4">Figure <a href="#fig-pub-key-update-req-resp" class="auto internal xref">Figure 35</a> gives an overview of the exchange described above, while <a href="#fig-pub-key-update-req-resp-2" class="auto internal xref">Figure 36</a> shows an example.<a href="#section-4.9.1.1-4" class="pilcrow">¶</a></p>
+<p id="section-4.9.1.1-4">Figure <a href="#fig-pub-key-update-req-resp" class="auto internal xref">Figure 36</a> gives an overview of the exchange described above, while <a href="#fig-pub-key-update-req-resp-2" class="auto internal xref">Figure 37</a> shows an example.<a href="#section-4.9.1.1-4" class="pilcrow">¶</a></p>
 <span id="name-message-flow-of-authenticatio"></span><div id="fig-pub-key-update-req-resp">
-<figure id="figure-35">
+<figure id="figure-36">
               <div class="alignCenter art-text artwork" id="section-4.9.1.1-5.1">
 <pre>
 Client                                                          KDC
@@ -3498,12 +3595,12 @@ <h5 id="name-uploading-a-authentication-">
 |                                                                |
 </pre>
 </div>
-<figcaption><a href="#figure-35" class="selfRef">Figure 35</a>:
+<figcaption><a href="#figure-36" class="selfRef">Figure 36</a>:
 <a href="#name-message-flow-of-authenticatio" class="selfRef">Message Flow of Authentication Credential Update Request-Response</a>
               </figcaption></figure>
 </div>
 <span id="name-example-of-authentication-cre"></span><div id="fig-pub-key-update-req-resp-2">
-<figure id="figure-36">
+<figure id="figure-37">
               <div class="alignLeft art-text artwork" id="section-4.9.1.1-6.1">
 <pre>
 Request:
@@ -3527,7 +3624,7 @@ <h5 id="name-uploading-a-authentication-">
 Payload: -
 </pre>
 </div>
-<figcaption><a href="#figure-36" class="selfRef">Figure 36</a>:
+<figcaption><a href="#figure-37" class="selfRef">Figure 37</a>:
 <a href="#name-example-of-authentication-cre" class="selfRef">Example of Authentication Credential Update Request-Response</a>
               </figcaption></figure>
 </div>
@@ -3551,7 +3648,7 @@ <h2 id="name-removal-of-a-group-member">
           <p id="section-5-2.1.1">The Client explicitly asks to leave the group, as defined in <a href="#ssec-group-leaving" class="auto internal xref">Section 4.8.3.1</a>.<a href="#section-5-2.1.1" class="pilcrow">¶</a></p>
 </li>
         <li id="section-5-2.2">
-          <p id="section-5-2.2.1">The node has been found compromised or is suspected so.<a href="#section-5-2.2.1" class="pilcrow">¶</a></p>
+          <p id="section-5-2.2.1">The node has been found compromised or is suspected so. The KDC is expected to determine that a group member has to be evicted either through its own means, or based on information that it obtains from a trusted source (e.g., an Intrusion Detection System, or an issuer of authentication credentials). Additional mechanics, protocols, and interfaces at the KDC that can support this are out of the scope of this document.<a href="#section-5-2.2.1" class="pilcrow">¶</a></p>
 </li>
         <li id="section-5-2.3">
           <p id="section-5-2.3.1">The Client's authorization to be a group member with the current roles is not valid anymore, i.e., the access token has expired or has been revoked. If the AS provides token introspection (see <span><a href="https://rfc-editor.org/rfc/rfc9200#section-5.9" class="relref">Section 5.9</a> of [<a href="#RFC9200" class="cite xref">RFC9200</a>]</span>), the KDC can optionally use it and check whether the Client is still authorized.<a href="#section-5-2.3.1" class="pilcrow">¶</a></p>
@@ -3563,7 +3660,7 @@ <h2 id="name-removal-of-a-group-member">
           <p id="section-5-4.1.1">The KDC removes the Client from the list of current members of the group.<a href="#section-5-4.1.1" class="pilcrow">¶</a></p>
 </li>
         <li class="normal" id="section-5-4.2">
-          <p id="section-5-4.2.1">In case of forced eviction, i.e., for cases 2 and 3 above, the KDC deletes the authentication credential of the removed Client, if it acts as repository of authentication credentials for group members.<a href="#section-5-4.2.1" class="pilcrow">¶</a></p>
+          <p id="section-5-4.2.1">In case of forced eviction, i.e., for cases 2 and 3 above, the KDC deletes the authentication credential of the removed Client, if it acts as a repository of authentication credentials for group members.<a href="#section-5-4.2.1" class="pilcrow">¶</a></p>
 </li>
         <li class="normal" id="section-5-4.3">
           <p id="section-5-4.3.1">If the removed Client is registered as an observer of the group-membership resource at /ace-group/GROUPNAME, the KDC removes the Client from the list of observers of that resource.<a href="#section-5-4.3.1" class="pilcrow">¶</a></p>
@@ -3579,7 +3676,7 @@ <h2 id="name-removal-of-a-group-member">
             <li class="normal" id="section-5-4.4.3.2">
               <p id="section-5-4.4.3.2.1">If the evicted Client is observing its associated sub-resource at /ace-group/GROUPNAME/nodes/NODENAME (see <a href="#node-get" class="auto internal xref">Section 4.8.1</a>), the KDC sends an unsolicited 4.04 (Not Found) error response, which does not include the Observe option and indicates that the observed resource has been deleted (see <span><a href="https://rfc-editor.org/rfc/rfc7641#section-3.2" class="relref">Section 3.2</a> of [<a href="#RFC7641" class="cite xref">RFC7641</a>]</span>).<a href="#section-5-4.4.3.2.1" class="pilcrow">¶</a></p>
 <p id="section-5-4.4.3.2.2">
-The response MUST have Content-Format set to application/ace-groupcomm+cbor and is formatted as defined in <a href="#key-distr" class="auto internal xref">Section 4</a>. The value of the 'error' field MUST be set to 5 ("Group membership terminated").<a href="#section-5-4.4.3.2.2" class="pilcrow">¶</a></p>
+The response MUST have Content-Format set to application/concise-problem-details+cbor and is formatted as defined in <a href="#kdc-if-errors" class="auto internal xref">Section 4.1.2</a>. Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' field  MUST be set to 5 ("Group membership terminated").<a href="#section-5-4.4.3.2.2" class="pilcrow">¶</a></p>
 </li>
           </ul>
 </li>
@@ -3595,11 +3692,11 @@ <h2 id="name-group-rekeying-process">
 <a href="#section-6" class="section-number selfRef">6. </a><a href="#name-group-rekeying-process" class="section-name selfRef">Group Rekeying Process</a>
       </h2>
 <p id="section-6-1">A group rekeying is started and driven by the KDC. The KDC is not intended to accommodate explicit requests from group members to trigger a group rekeying. That is, the scheduling and execution of a group rekeying is an exclusive prerogative of the KDC. Reasons that can trigger a group rekeying are a change in the group membership, the current group keying material approaching its expiration time, or a regularly scheduled update of the group keying material.<a href="#section-6-1" class="pilcrow">¶</a></p>
-<p id="section-6-2">The KDC can perform a group rekeying before the current group keying material expires, unless it is acceptable or there are reasons to temporarily pause secure communications in the group, following the expiration of the current keying material.<a href="#section-6-2" class="pilcrow">¶</a></p>
+<p id="section-6-2">The KDC can perform a group rekeying before the current group keying material expires, unless it is acceptable or there are reasons to temporarily pause secure communications in the group, following the expiration of the current keying material. For example, a pause in the group communication might have been scheduled to start anyway when the group keying material expires, e.g., to allow maintenance operations on the group members. As another example, the KDC might be carrying out a verification that some group members are seemingly compromised and to be evicted, and this requires to be completed in order to appropriately define and schedule the exact rekeying process to perform. As a result, the KDC could delay the execution of the group rekeying.<a href="#section-6-2" class="pilcrow">¶</a></p>
 <p id="section-6-3">The KDC MUST increment the version number NUM of the current keying material, before distributing the newly generated keying material with version number NUM+1 to the group. Once completed the group rekeying, the KDC MUST delete the old keying material and SHOULD store the newly distributed keying material in persistent storage.<a href="#section-6-3" class="pilcrow">¶</a></p>
 <p id="section-6-4">Distributing the new group keying material requires the KDC to send multiple rekeying messages to the group members. Depending on the rekeying scheme used in the group and the reason that has triggered the rekeying process, each rekeying message can be intended to one or multiple group members, hereafter referred to as target group members. The KDC MUST support at least the "Point-to-Point" group rekeying scheme in <a href="#point-to-point-rekeying" class="auto internal xref">Section 6.1</a> and MAY support additional ones.<a href="#section-6-4" class="pilcrow">¶</a></p>
 <p id="section-6-5">Each rekeying message MUST have Content-Format set to application/ace-groupcomm+cbor and its payload formatted as a CBOR map, which MUST include at least the information specified in the Key Distribution Response message (see <a href="#gid-get" class="auto internal xref">Section 4.3.2</a>), i.e., the parameters 'gkty', 'key', and 'num' defined in <a href="#gid-post" class="auto internal xref">Section 4.3.1</a>. The CBOR map MAY include the parameter 'exp', as well as the parameter 'mgt_key_material' specifying new administrative keying material for the target group members, if relevant for the used rekeying scheme.<a href="#section-6-5" class="pilcrow">¶</a></p>
-<p id="section-6-6">A rekeying message may include additional information, depending on the rekeying scheme used in the group, the reason that has triggered the rekeying process, and the specific target group members. In particular, if the group rekeying is performed due to one or multiple Clients that have joined the group and the KDC acts as repository of authentication credentials of the group members, then a rekeying message MAY also include the authentication credentials that those Clients use in the group, together with the roles and node identifier that the corresponding Client has in the group. It is RECOMMENDED to specify this information by means of the parameters 'creds', 'peer_roles', and 'peer_identifiers', like done in the Join Response message (see <a href="#gid-post" class="auto internal xref">Section 4.3.1</a>).<a href="#section-6-6" class="pilcrow">¶</a></p>
+<p id="section-6-6">A rekeying message may include additional information, depending on the rekeying scheme used in the group, the reason that has triggered the rekeying process, and the specific target group members. In particular, if the group rekeying is performed due to one or multiple Clients that have joined the group and the KDC acts as a repository of authentication credentials of the group members, then a rekeying message MAY also include the authentication credentials that those Clients use in the group, together with the roles and node identifier that the corresponding Client has in the group. It is RECOMMENDED to specify this information by means of the parameters 'creds', 'peer_roles', and 'peer_identifiers', like done in the Join Response message (see <a href="#gid-post" class="auto internal xref">Section 4.3.1</a>).<a href="#section-6-6" class="pilcrow">¶</a></p>
 <p id="section-6-7">The complete format of a rekeying message, including the encoding and content of the 'mgt_key_material' parameter, has to be defined in separate specifications aimed at profiling the used rekeying scheme in the context of the used application profile of this specification. As a particular case, an application profile of this specification MAY define additional information to include in rekeying messages for the "Point-to-Point" group rekeying scheme in <a href="#point-to-point-rekeying" class="auto internal xref">Section 6.1</a> (OPT14).<a href="#section-6-7" class="pilcrow">¶</a></p>
 <p id="section-6-8">Consistently with the used group rekeying scheme, the actual delivery of rekeying messages can occur through different approaches, as discussed in the following <a href="#point-to-point-rekeying" class="auto internal xref">Section 6.1</a> and <a href="#one-to-many-rekeying" class="auto internal xref">Section 6.2</a>.<a href="#section-6-8" class="pilcrow">¶</a></p>
 <p id="section-6-9">The possible, temporary misalignment of the keying material stored by the different group members due to a group rekeying is discussed in <a href="#sec-misalignment-keying-material" class="auto internal xref">Section 6.3</a>. Further security considerations related to the group rekeying process are compiled in <a href="#sec-cons-rekeying" class="auto internal xref">Section 10.2</a>.<a href="#section-6-9" class="pilcrow">¶</a></p>
@@ -3608,14 +3705,14 @@ <h2 id="name-group-rekeying-process">
         <h3 id="name-point-to-point-group-rekeyi">
 <a href="#section-6.1" class="section-number selfRef">6.1. </a><a href="#name-point-to-point-group-rekeyi" class="section-name selfRef">Point-to-Point Group Rekeying</a>
         </h3>
-<p id="section-6.1-1">This approach consists in the KDC sending one individual rekeying message to each target group member. In particular, the rekeying message is protected by means of the security association between the KDC and the target group member in question, as per the used application profile of this specification and the used transport profile of ACE.<a href="#section-6.1-1" class="pilcrow">¶</a></p>
+<p id="section-6.1-1">A point-to-point group rekeying consists in the KDC sending one individual rekeying message to each target group member. In particular, the rekeying message is protected by means of the security association between the KDC and the target group member in question, as per the used application profile of this specification and the used transport profile of ACE.<a href="#section-6.1-1" class="pilcrow">¶</a></p>
 <p id="section-6.1-2">This is the approach taken by the basic "Point-to-Point" group rekeying scheme, that the KDC can explicitly signal in the Join Response (see <a href="#gid-post" class="auto internal xref">Section 4.3.1</a>), through the 'rekeying_scheme' parameter specifying the value 0.<a href="#section-6.1-2" class="pilcrow">¶</a></p>
 <p id="section-6.1-3">When taking this approach in the group identified by GROUPNAME, the KDC can practically deliver the rekeying messages to the target group members in different, co-existing ways.<a href="#section-6.1-3" class="pilcrow">¶</a></p>
 <ul class="normal">
 <li class="normal" id="section-6.1-4.1">
             <p id="section-6.1-4.1.1">The KDC SHOULD make the /ace-group/GROUPNAME resource Observable <span>[<a href="#RFC7641" class="cite xref">RFC7641</a>]</span>. Thus, upon performing a group rekeying, the KDC can distribute the new group keying material through individual notification responses sent to the target group members that are also observing that resource.<a href="#section-6.1-4.1.1" class="pilcrow">¶</a></p>
 <p id="section-6.1-4.1.2">
-In case the KDC deletes the group (and thus deletes the /ace-group/GROUPNAME resource), relying on CoAP Observe as discussed above also allows the KDC to send an unsolicited 4.04 (Not Found) response to each observer group member, as a notification of group termination. The response MUST have Content-Format set to application/ace-groupcomm+cbor and is formatted as defined in <a href="#key-distr" class="auto internal xref">Section 4</a>. The value of the 'error' field MUST be set to 6 ("Group deleted").<a href="#section-6.1-4.1.2" class="pilcrow">¶</a></p>
+In case the KDC deletes the group (and thus deletes the /ace-group/GROUPNAME resource), relying on CoAP Observe as discussed above also allows the KDC to send an unsolicited 4.04 (Not Found) response to each observer group member, as a notification of group termination. The response MUST have Content-Format set to application/concise-problem-details+cbor and is formatted as defined in <a href="#kdc-if-errors" class="auto internal xref">Section 4.1.2</a>. Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' field  MUST be set to 6 ("Group deleted").<a href="#section-6.1-4.1.2" class="pilcrow">¶</a></p>
 </li>
           <li class="normal" id="section-6.1-4.2">
             <p id="section-6.1-4.2.1">If a target group member specified a URI in the 'control_uri' parameter of the Join Request upon joining the group (see <a href="#gid-post" class="auto internal xref">Section 4.3.1</a>), the KDC can provide that group member with the new group keying material by sending a unicast POST request to that URI.<a href="#section-6.1-4.2.1" class="pilcrow">¶</a></p>
@@ -3624,6 +3721,97 @@ <h3 id="name-point-to-point-group-rekeyi">
 </li>
         </ul>
 <p id="section-6.1-5">If the KDC has to send a rekeying message to a target group member, but this did not include the 'control_uri' parameter in the Join Request and is not a registered observer for the /ace-group/GROUPNAME resource, then that target group member would not be able to participate to the group rekeying. Later on, after having repeatedly failed to successfully exchange secure messages in the group, that group member can retrieve the current group keying material from the KDC, by sending a GET request to /ace-group/GROUPNAME or /ace-group/GROUPNAME/nodes/NODENAME (see <a href="#gid-get" class="auto internal xref">Section 4.3.2</a> and <a href="#node-get" class="auto internal xref">Section 4.8.1</a>, respectively).<a href="#section-6.1-5" class="pilcrow">¶</a></p>
+<p id="section-6.1-6">Figure <a href="#fig-rekeying-example-1" class="auto internal xref">Figure 38</a> provides an example of point-to-point group rekeying. In particular, the example makes the following assumptions.<a href="#section-6.1-6" class="pilcrow">¶</a></p>
+<ul class="normal">
+<li class="normal" id="section-6.1-7.1">
+            <p id="section-6.1-7.1.1">The group currently consists of four group members, namely C1, C2, C3, and C4.<a href="#section-6.1-7.1.1" class="pilcrow">¶</a></p>
+</li>
+          <li class="normal" id="section-6.1-7.2">
+            <p id="section-6.1-7.2.1">Each group member, when joining the group, provided the KDC with a URI in the 'control_uri' parameter, with url-path "grp-rek".<a href="#section-6.1-7.2.1" class="pilcrow">¶</a></p>
+</li>
+          <li class="normal" id="section-6.1-7.3">
+            <p id="section-6.1-7.3.1">Before the group rekeying is performed, the keying material used in the group has version number num=5.<a href="#section-6.1-7.3.1" class="pilcrow">¶</a></p>
+</li>
+          <li class="normal" id="section-6.1-7.4">
+            <p id="section-6.1-7.4.1">The KDC performs the group rekeying in such a way to evict the group member C3, which has been found to be compromised.<a href="#section-6.1-7.4.1" class="pilcrow">¶</a></p>
+</li>
+        </ul>
+<p id="section-6.1-8">In the example, the KDC individually rekeys the group members intended to remain in the group (i.e., C1, C2, and C4), by means of one rekeying message each.<a href="#section-6.1-8" class="pilcrow">¶</a></p>
+<span id="name-example-of-message-exchange"></span><div id="fig-rekeying-example-1">
+<figure id="figure-38">
+          <div id="section-6.1-9.1">
+            <div class="alignCenter art-svg artwork" id="section-6.1-9.1.1">
+<svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="384" width="560" viewBox="0 0 560 384" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
+                <path d="M 32,32 L 32,64" fill="none" stroke="black"></path>
+                <path d="M 40,256 L 40,288" fill="none" stroke="black"></path>
+                <path d="M 80,72 L 80,208" fill="none" stroke="black"></path>
+                <path d="M 112,256 L 112,288" fill="none" stroke="black"></path>
+                <path d="M 184,256 L 184,288" fill="none" stroke="black"></path>
+                <path d="M 224,72 L 224,208" fill="none" stroke="black"></path>
+                <path d="M 256,256 L 256,288" fill="none" stroke="black"></path>
+                <path d="M 328,256 L 328,288" fill="none" stroke="black"></path>
+                <path d="M 400,256 L 400,288" fill="none" stroke="black"></path>
+                <path d="M 480,256 L 480,288" fill="none" stroke="black"></path>
+                <path d="M 520,72 L 520,208" fill="none" stroke="black"></path>
+                <path d="M 552,32 L 552,64" fill="none" stroke="black"></path>
+                <path d="M 552,256 L 552,288" fill="none" stroke="black"></path>
+                <path d="M 32,32 L 552,32" fill="none" stroke="black"></path>
+                <path d="M 32,64 L 552,64" fill="none" stroke="black"></path>
+                <path d="M 40,256 L 112,256" fill="none" stroke="black"></path>
+                <path d="M 184,256 L 256,256" fill="none" stroke="black"></path>
+                <path d="M 328,256 L 400,256" fill="none" stroke="black"></path>
+                <path d="M 480,256 L 552,256" fill="none" stroke="black"></path>
+                <path d="M 40,288 L 112,288" fill="none" stroke="black"></path>
+                <path d="M 184,288 L 256,288" fill="none" stroke="black"></path>
+                <path d="M 328,288 L 400,288" fill="none" stroke="black"></path>
+                <path d="M 480,288 L 552,288" fill="none" stroke="black"></path>
+                <path d="M 44,344 L 140,344" fill="none" stroke="black"></path>
+                <path d="M 444,344 L 548,344" fill="none" stroke="black"></path>
+                <polygon class="arrowhead" points="528,208 516,202.4 516,213.6" fill="black" transform="rotate(90,520,208)"></polygon>
+                <polygon class="arrowhead" points="232,208 220,202.4 220,213.6" fill="black" transform="rotate(90,224,208)"></polygon>
+                <polygon class="arrowhead" points="88,208 76,202.4 76,213.6" fill="black" transform="rotate(90,80,208)"></polygon>
+                <g class="text">
+                  <text x="288" y="52">KDC</text>
+                  <text x="24" y="100">Group</text>
+                  <text x="168" y="100">Group</text>
+                  <text x="464" y="100">Group</text>
+                  <text x="28" y="116">keying</text>
+                  <text x="172" y="116">keying</text>
+                  <text x="468" y="116">keying</text>
+                  <text x="36" y="132">material</text>
+                  <text x="180" y="132">material</text>
+                  <text x="476" y="132">material</text>
+                  <text x="32" y="148">(num=6)</text>
+                  <text x="176" y="148">(num=6)</text>
+                  <text x="472" y="148">(num=6)</text>
+                  <text x="76" y="244">/grp-rek</text>
+                  <text x="220" y="244">/grp-rek</text>
+                  <text x="364" y="244">/grp-rek</text>
+                  <text x="516" y="244">/grp-rek</text>
+                  <text x="76" y="276">C1</text>
+                  <text x="220" y="276">C2</text>
+                  <text x="364" y="276">C3</text>
+                  <text x="516" y="276">C4</text>
+                  <text x="320" y="308">[TO</text>
+                  <text x="348" y="308">BE</text>
+                  <text x="396" y="308">EVICTED]</text>
+                  <text x="40" y="324">|</text>
+                  <text x="552" y="324">|</text>
+                  <text x="40" y="340">\</text>
+                  <text x="172" y="340">Stored</text>
+                  <text x="224" y="340">group</text>
+                  <text x="276" y="340">keying</text>
+                  <text x="340" y="340">material</text>
+                  <text x="408" y="340">(num=5)</text>
+                  <text x="552" y="340">/</text>
+                </g>
+              </svg><a href="#section-6.1-9.1.1" class="pilcrow">¶</a>
+</div>
+</div>
+<figcaption><a href="#figure-38" class="selfRef">Figure 38</a>:
+<a href="#name-example-of-message-exchange" class="selfRef">Example of Message Exchanges for a Point-to-Point Group Rekeying</a>
+          </figcaption></figure>
+</div>
 </section>
 </div>
 <div id="one-to-many-rekeying">
@@ -3643,7 +3831,7 @@ <h3 id="name-one-to-many-group-rekeying">
 If a particular rekeying message is intended to a single target group member, the KDC may alternatively protect the message using the security association with that group member, and deliver the message like when using the "Point-to-Point" group rekeying scheme (see <a href="#point-to-point-rekeying" class="auto internal xref">Section 6.1</a>).<a href="#section-6.2-6.1.2" class="pilcrow">¶</a></p>
 </li>
           <li class="normal" id="section-6.2-6.2">
-            <p id="section-6.2-6.2.1">Through a pub-sub communication model - In this case, the KDC acts as publisher and publishes each rekeying message to a specific "rekeying topic", which is associated with the group and is hosted at a broker server. Following their group joining, the group members subscribe to the rekeying topic at the broker, thus receiving the group rekeying messages as they are published by the KDC.<a href="#section-6.2-6.2.1" class="pilcrow">¶</a></p>
+            <p id="section-6.2-6.2.1">Through a pub-sub communication model - In this case, the KDC acts as a publisher and publishes each rekeying message to a specific "rekeying topic", which is associated with the group and is hosted at a broker server. Following their group joining, the group members subscribe to the rekeying topic at the broker, thus receiving the group rekeying messages as they are published by the KDC.<a href="#section-6.2-6.2.1" class="pilcrow">¶</a></p>
 <p id="section-6.2-6.2.2">
 In order to make such message delivery more efficient, the rekeying topic associated with a group can be further organized into subtopics. For instance, the KDC can use a particular subtopic to address a particular set of target group members during the rekeying process, as possibly aligned to a similar organization of the administrative keying material (e.g., a key hierarchy).<a href="#section-6.2-6.2.2" class="pilcrow">¶</a></p>
 <p id="section-6.2-6.2.3">
@@ -3661,86 +3849,215 @@ <h3 id="name-one-to-many-group-rekeying">
 </li>
         </ul>
 <p id="section-6.2-10">Further details depend on the specific rekeying scheme used in the group.<a href="#section-6.2-10" class="pilcrow">¶</a></p>
+<p id="section-6.2-11">Figure <a href="#fig-rekeying-example-2" class="auto internal xref">Figure 39</a> provides an example of one-to-many group rekeying over multicast. In particular, the example makes the following assumptions.<a href="#section-6.2-11" class="pilcrow">¶</a></p>
+<ul class="normal">
+<li class="normal" id="section-6.2-12.1">
+            <p id="section-6.2-12.1.1">The group currently consists of four group members, namely C1, C2, C3, and C4.<a href="#section-6.2-12.1.1" class="pilcrow">¶</a></p>
+</li>
+          <li class="normal" id="section-6.2-12.2">
+            <p id="section-6.2-12.2.1">Each group member, when joining the group, provided the KDC with a URI in the 'control_uri' parameter, with url-path "grp-rek".<a href="#section-6.2-12.2.1" class="pilcrow">¶</a></p>
+</li>
+          <li class="normal" id="section-6.2-12.3">
+            <p id="section-6.2-12.3.1">Each group member, when joining the group, received from the KDC a URI in the 'control_group_uri' parameter, specifying the multicast address MULT_ADDR and url-path "grp-mrek".<a href="#section-6.2-12.3.1" class="pilcrow">¶</a></p>
+</li>
+          <li class="normal" id="section-6.2-12.4">
+            <p id="section-6.2-12.4.1">Before the group rekeying is performed, the keying material used in the group has version number num=5.<a href="#section-6.2-12.4.1" class="pilcrow">¶</a></p>
+</li>
+          <li class="normal" id="section-6.2-12.5">
+            <p id="section-6.2-12.5.1">The KDC performs the group rekeying in such a way to evict the group member C3, which has been found to be compromised.<a href="#section-6.2-12.5.1" class="pilcrow">¶</a></p>
+</li>
+        </ul>
+<p id="section-6.2-13">In the example, the KDC determines that the most convenient way to perform a group rekeying that evicts C3 is as follows.<a href="#section-6.2-13" class="pilcrow">¶</a></p>
+<p id="section-6.2-14">First, the KDC sends one rekeying message over multicast, to the multicast address MULT_ADDR and the url-path "grp-mrek". In the figure, the message is denoted with dashed lines. The message is protected with a non-compromised key from the administrative keying material that only C1 and C2 store. Therefore, even though all the group members receive this message, only C1 and C2 are able to decrypt it. The message includes: the new group keying material with version number num=6; and new keys from the administrative keying material to replace those stored by the group members C1, C2, and C3.<a href="#section-6.2-14" class="pilcrow">¶</a></p>
+<p id="section-6.2-15">After that, the KDC sends one rekeying message addressed individually to C4 and with url-path "grp-rek". In the figure, the message is denoted with a dotted line. The message is protected with the secure association shared between C4 and the KDC. The message includes: the new group keying material with version number num=6; and new keys from the administrative keying material to replace those stored by both C4 and C3.<a href="#section-6.2-15" class="pilcrow">¶</a></p>
+<span id="name-example-of-message-exchanges"></span><div id="fig-rekeying-example-2">
+<figure id="figure-39">
+          <div id="section-6.2-16.1">
+            <div class="alignCenter art-svg artwork" id="section-6.2-16.1.1">
+<svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="400" width="576" viewBox="0 0 576 400" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
+                <path d="M 8,32 L 8,64" fill="none" stroke="black"></path>
+                <path d="M 8,288 L 8,320" fill="none" stroke="black"></path>
+                <path d="M 56,192 L 56,240" fill="none" stroke="black"></path>
+                <path d="M 80,288 L 80,320" fill="none" stroke="black"></path>
+                <path d="M 112,288 L 112,320" fill="none" stroke="black"></path>
+                <path d="M 160,192 L 160,240" fill="none" stroke="black"></path>
+                <path d="M 184,288 L 184,320" fill="none" stroke="black"></path>
+                <path d="M 216,288 L 216,320" fill="none" stroke="black"></path>
+                <path d="M 272,72 L 272,240" fill="none" stroke="black"></path>
+                <path d="M 312,288 L 312,320" fill="none" stroke="black"></path>
+                <path d="M 344,288 L 344,320" fill="none" stroke="black"></path>
+                <path d="M 392,192 L 392,240" fill="none" stroke="black"></path>
+                <path d="M 568,32 L 568,64" fill="none" stroke="black"></path>
+                <path d="M 568,288 L 568,320" fill="none" stroke="black"></path>
+                <path d="M 8,32 L 568,32" fill="none" stroke="black"></path>
+                <path d="M 8,64 L 568,64" fill="none" stroke="black"></path>
+                <path d="M 56,192 L 392,192" fill="none" stroke="black"></path>
+                <path d="M 8,288 L 80,288" fill="none" stroke="black"></path>
+                <path d="M 112,288 L 184,288" fill="none" stroke="black"></path>
+                <path d="M 216,288 L 312,288" fill="none" stroke="black"></path>
+                <path d="M 344,288 L 568,288" fill="none" stroke="black"></path>
+                <path d="M 8,320 L 80,320" fill="none" stroke="black"></path>
+                <path d="M 112,320 L 184,320" fill="none" stroke="black"></path>
+                <path d="M 216,320 L 312,320" fill="none" stroke="black"></path>
+                <path d="M 344,320 L 568,320" fill="none" stroke="black"></path>
+                <path d="M 12,376 L 132,376" fill="none" stroke="black"></path>
+                <path d="M 436,376 L 564,376" fill="none" stroke="black"></path>
+                <polygon class="arrowhead" points="400,240 388,234.4 388,245.6" fill="black" transform="rotate(90,392,240)"></polygon>
+                <polygon class="arrowhead" points="280,240 268,234.4 268,245.6" fill="black" transform="rotate(90,272,240)"></polygon>
+                <polygon class="arrowhead" points="168,240 156,234.4 156,245.6" fill="black" transform="rotate(90,160,240)"></polygon>
+                <polygon class="arrowhead" points="64,240 52,234.4 52,245.6" fill="black" transform="rotate(90,56,240)"></polygon>
+                <circle cx="8" cy="96" r="6" class="closeddot" fill="black"></circle>
+                <circle cx="8" cy="112" r="6" class="closeddot" fill="black"></circle>
+                <circle cx="336" cy="96" r="6" class="closeddot" fill="black"></circle>
+                <circle cx="336" cy="128" r="6" class="closeddot" fill="black"></circle>
+                <g class="text">
+                  <text x="272" y="52">KDC</text>
+                  <text x="544" y="84">:</text>
+                  <text x="40" y="100">Group</text>
+                  <text x="92" y="100">keying</text>
+                  <text x="156" y="100">material</text>
+                  <text x="224" y="100">(num=6)</text>
+                  <text x="368" y="100">Group</text>
+                  <text x="420" y="100">keying</text>
+                  <text x="544" y="100">:</text>
+                  <text x="48" y="116">Updated</text>
+                  <text x="140" y="116">administrative</text>
+                  <text x="380" y="116">material</text>
+                  <text x="448" y="116">(num=6)</text>
+                  <text x="544" y="116">:</text>
+                  <text x="44" y="132">keying</text>
+                  <text x="108" y="132">material</text>
+                  <text x="160" y="132">for</text>
+                  <text x="188" y="132">C1</text>
+                  <text x="216" y="132">and</text>
+                  <text x="244" y="132">C2</text>
+                  <text x="376" y="132">Updated</text>
+                  <text x="468" y="132">administrative</text>
+                  <text x="544" y="132">:</text>
+                  <text x="372" y="148">keying</text>
+                  <text x="436" y="148">material</text>
+                  <text x="488" y="148">for</text>
+                  <text x="516" y="148">C4</text>
+                  <text x="544" y="148">:</text>
+                  <text x="544" y="164">:</text>
+                  <text x="544" y="180">:</text>
+                  <text x="544" y="196">:</text>
+                  <text x="544" y="212">:</text>
+                  <text x="544" y="228">:</text>
+                  <text x="544" y="244">v</text>
+                  <text x="48" y="276">/grp-mrek</text>
+                  <text x="152" y="276">/grp-mrek</text>
+                  <text x="256" y="276">/grp-mrek</text>
+                  <text x="384" y="276">/grp-mrek</text>
+                  <text x="532" y="276">/grp-rek</text>
+                  <text x="44" y="308">C1</text>
+                  <text x="148" y="308">C2</text>
+                  <text x="268" y="308">C3</text>
+                  <text x="452" y="308">C4</text>
+                  <text x="216" y="340">[TO</text>
+                  <text x="244" y="340">BE</text>
+                  <text x="292" y="340">EVICTED]</text>
+                  <text x="8" y="356">|</text>
+                  <text x="568" y="356">|</text>
+                  <text x="8" y="372">\</text>
+                  <text x="164" y="372">Stored</text>
+                  <text x="216" y="372">group</text>
+                  <text x="268" y="372">keying</text>
+                  <text x="332" y="372">material</text>
+                  <text x="400" y="372">(num=5)</text>
+                  <text x="568" y="372">/</text>
+                </g>
+              </svg><a href="#section-6.2-16.1.1" class="pilcrow">¶</a>
+</div>
+</div>
+<figcaption><a href="#figure-39" class="selfRef">Figure 39</a>:
+<a href="#name-example-of-message-exchanges" class="selfRef">Example of Message Exchanges for a One-to-Many Group Rekeying</a>
+          </figcaption></figure>
+</div>
 <div id="one-to-many-rekeying-protection">
 <section id="section-6.2.1">
           <h4 id="name-protection-of-rekeying-mess">
 <a href="#section-6.2.1" class="section-number selfRef">6.2.1. </a><a href="#name-protection-of-rekeying-mess" class="section-name selfRef">Protection of Rekeying Messages</a>
           </h4>
 <p id="section-6.2.1-1">When using a group rekeying scheme relying on one-to-many rekeying messages, the actual data content of each rekeying message is prepared according to what the rekeying scheme prescribes.<a href="#section-6.2.1-1" class="pilcrow">¶</a></p>
-<p id="section-6.2.1-2">Then, the KDC can protect the rekeying message as defined below. The used encryption algorithm which SHOULD be the same one used to protect communications in the group. The method defined below assumes that the following holds for the management keying material specified in the 'mgt_key_material' parameter of the Join Response (see <a href="#gid-post" class="auto internal xref">Section 4.3.1</a>).<a href="#section-6.2.1-2" class="pilcrow">¶</a></p>
+<p id="section-6.2.1-2">The following describes one possible method for the KDC to protect the rekeying messages.<a href="#section-6.2.1-2" class="pilcrow">¶</a></p>
+<p id="section-6.2.1-3">The method assumes that the following holds for the management keying material specified in the 'mgt_key_material' parameter of the Join Response (see <a href="#gid-post" class="auto internal xref">Section 4.3.1</a>).<a href="#section-6.2.1-3" class="pilcrow">¶</a></p>
 <ul class="normal">
-<li class="normal" id="section-6.2.1-3.1">
-              <p id="section-6.2.1-3.1.1">The included symmetric encryption keys are accompanied by a corresponding and unique key identifier assigned by the KDC.<a href="#section-6.2.1-3.1.1" class="pilcrow">¶</a></p>
+<li class="normal" id="section-6.2.1-4.1">
+              <p id="section-6.2.1-4.1.1">The encryption algorithm SHOULD be the same one used to protect communications in the group.<a href="#section-6.2.1-4.1.1" class="pilcrow">¶</a></p>
 </li>
-            <li class="normal" id="section-6.2.1-3.2">
-              <p id="section-6.2.1-3.2.1">A Base IV is also included, with the same size of the AEAD nonce considered by the encryption algorithm to use.<a href="#section-6.2.1-3.2.1" class="pilcrow">¶</a></p>
+            <li class="normal" id="section-6.2.1-4.2">
+              <p id="section-6.2.1-4.2.1">The included symmetric encryption keys are accompanied by a corresponding and unique key identifier assigned by the KDC.<a href="#section-6.2.1-4.2.1" class="pilcrow">¶</a></p>
+</li>
+            <li class="normal" id="section-6.2.1-4.3">
+              <p id="section-6.2.1-4.3.1">A Base IV is also included, with the same size of the AEAD nonce considered by the encryption algorithm to use.<a href="#section-6.2.1-4.3.1" class="pilcrow">¶</a></p>
 </li>
           </ul>
-<p id="section-6.2.1-4">First, the KDC computes a COSE_Encrypt0 object as follows.<a href="#section-6.2.1-4" class="pilcrow">¶</a></p>
+<p id="section-6.2.1-5">First, the KDC computes a COSE_Encrypt0 object as follows.<a href="#section-6.2.1-5" class="pilcrow">¶</a></p>
 <ul class="normal">
-<li class="normal" id="section-6.2.1-5.1">
-              <p id="section-6.2.1-5.1.1">The encryption key to use is selected from the administrative keying material, as defined by the rekeying scheme used in the group.<a href="#section-6.2.1-5.1.1" class="pilcrow">¶</a></p>
+<li class="normal" id="section-6.2.1-6.1">
+              <p id="section-6.2.1-6.1.1">The encryption key to use is selected from the administrative keying material, as defined by the rekeying scheme used in the group.<a href="#section-6.2.1-6.1.1" class="pilcrow">¶</a></p>
 </li>
-            <li class="normal" id="section-6.2.1-5.2">
-              <p id="section-6.2.1-5.2.1">The plaintext is the actual data content of the rekeying message.<a href="#section-6.2.1-5.2.1" class="pilcrow">¶</a></p>
+            <li class="normal" id="section-6.2.1-6.2">
+              <p id="section-6.2.1-6.2.1">The plaintext is the actual data content of the rekeying message.<a href="#section-6.2.1-6.2.1" class="pilcrow">¶</a></p>
 </li>
-            <li class="normal" id="section-6.2.1-5.3">
-              <p id="section-6.2.1-5.3.1">The Additional Authenticated Data (AAD) is empty, unless otherwise specified by separate documents profiling the use of the group rekeying scheme.<a href="#section-6.2.1-5.3.1" class="pilcrow">¶</a></p>
+            <li class="normal" id="section-6.2.1-6.3">
+              <p id="section-6.2.1-6.3.1">The Additional Authenticated Data (AAD) is empty, unless otherwise specified by separate documents profiling the use of the group rekeying scheme.<a href="#section-6.2.1-6.3.1" class="pilcrow">¶</a></p>
 </li>
-            <li class="normal" id="section-6.2.1-5.4">
-              <p id="section-6.2.1-5.4.1">Since the KDC is the only sender of rekeying messages, the AEAD nonce can be computed as follows, where NONCE_SIZE is the size in bytes of the AEAD nonce. Separate documents profiling the use of the group rekeying scheme may define alternative ways to compute the AEAD nonce.<a href="#section-6.2.1-5.4.1" class="pilcrow">¶</a></p>
-<p id="section-6.2.1-5.4.2">
-The KDC considers the following values.<a href="#section-6.2.1-5.4.2" class="pilcrow">¶</a></p>
+            <li class="normal" id="section-6.2.1-6.4">
+              <p id="section-6.2.1-6.4.1">Since the KDC is the only sender of rekeying messages, the AEAD nonce can be computed as follows, where NONCE_SIZE is the size in bytes of the AEAD nonce. Separate documents profiling the use of the group rekeying scheme may define alternative ways to compute the AEAD nonce.<a href="#section-6.2.1-6.4.1" class="pilcrow">¶</a></p>
+<p id="section-6.2.1-6.4.2">
+The KDC considers the following values.<a href="#section-6.2.1-6.4.2" class="pilcrow">¶</a></p>
 <ul class="normal">
-<li class="normal" id="section-6.2.1-5.4.3.1">
-                  <p id="section-6.2.1-5.4.3.1.1">COUNT, as a 2-byte unsigned integer associated with the used encryption key. Its value is set to 0 when starting to perform a new group rekeying instance, and is incremented after each use of the encryption key.<a href="#section-6.2.1-5.4.3.1.1" class="pilcrow">¶</a></p>
+<li class="normal" id="section-6.2.1-6.4.3.1">
+                  <p id="section-6.2.1-6.4.3.1.1">COUNT, as a 2-byte unsigned integer associated with the used encryption key. Its value is set to 0 when starting to perform a new group rekeying instance, and is incremented after each use of the encryption key.<a href="#section-6.2.1-6.4.3.1.1" class="pilcrow">¶</a></p>
 </li>
-                <li class="normal" id="section-6.2.1-5.4.3.2">
-                  <p id="section-6.2.1-5.4.3.2.1">NEW_NUM, as the version number of the new group keying material to distribute in this rekeying instance, left-padded with zeros to exactly NONCE_SIZE - 2 bytes.<a href="#section-6.2.1-5.4.3.2.1" class="pilcrow">¶</a></p>
+                <li class="normal" id="section-6.2.1-6.4.3.2">
+                  <p id="section-6.2.1-6.4.3.2.1">NEW_NUM, as the version number of the new group keying material to distribute in this rekeying instance, left-padded with zeros to exactly NONCE_SIZE - 2 bytes.<a href="#section-6.2.1-6.4.3.2.1" class="pilcrow">¶</a></p>
 </li>
               </ul>
-<p id="section-6.2.1-5.4.4">
-Then, the KDC computes a Partial IV as the byte string concatenation of COUNT and NEW_NUM, in this order. Finally, the AEAD nonce is computed as the XOR between the Base IV and the Partial IV.<a href="#section-6.2.1-5.4.4" class="pilcrow">¶</a></p>
-<p id="section-6.2.1-5.4.5">
-In order to comply with the security requirements of AEAD encryption algorithms, the KDC MUST NOT use the same pair (AEAD encryption key, AEAD nonce). For example, this includes not using the same encryption key from the administrative keying material more than 2^16 times during the same rekeying instance.<a href="#section-6.2.1-5.4.5" class="pilcrow">¶</a></p>
+<p id="section-6.2.1-6.4.4">
+Then, the KDC computes a Partial IV as the byte string concatenation of COUNT and NEW_NUM, in this order. Finally, the AEAD nonce is computed as the XOR between the Base IV and the Partial IV.<a href="#section-6.2.1-6.4.4" class="pilcrow">¶</a></p>
+<p id="section-6.2.1-6.4.5">
+In order to comply with the security requirements of AEAD encryption algorithms, the KDC MUST NOT use the same pair (AEAD encryption key, AEAD nonce). For example, this includes not using the same encryption key from the administrative keying material more than 2^16 times during the same rekeying instance.<a href="#section-6.2.1-6.4.5" class="pilcrow">¶</a></p>
 </li>
-            <li class="normal" id="section-6.2.1-5.5">
-              <p id="section-6.2.1-5.5.1">The protected header of the COSE_Encrypt0 object MUST include the following parameters.<a href="#section-6.2.1-5.5.1" class="pilcrow">¶</a></p>
+            <li class="normal" id="section-6.2.1-6.5">
+              <p id="section-6.2.1-6.5.1">The protected header of the COSE_Encrypt0 object MUST include the following parameters.<a href="#section-6.2.1-6.5.1" class="pilcrow">¶</a></p>
 <ul class="normal">
-<li class="normal" id="section-6.2.1-5.5.2.1">
-                  <p id="section-6.2.1-5.5.2.1.1">'alg', specifying the used encryption algorithm.<a href="#section-6.2.1-5.5.2.1.1" class="pilcrow">¶</a></p>
+<li class="normal" id="section-6.2.1-6.5.2.1">
+                  <p id="section-6.2.1-6.5.2.1.1">'alg', specifying the used encryption algorithm.<a href="#section-6.2.1-6.5.2.1.1" class="pilcrow">¶</a></p>
 </li>
-                <li class="normal" id="section-6.2.1-5.5.2.2">
-                  <p id="section-6.2.1-5.5.2.2.1">'kid', specifying the identifier of the encryption key from the administrative keying material used to protect this rekeying message.<a href="#section-6.2.1-5.5.2.2.1" class="pilcrow">¶</a></p>
+                <li class="normal" id="section-6.2.1-6.5.2.2">
+                  <p id="section-6.2.1-6.5.2.2.1">'kid', specifying the identifier of the encryption key from the administrative keying material used to protect this rekeying message.<a href="#section-6.2.1-6.5.2.2.1" class="pilcrow">¶</a></p>
 </li>
               </ul>
 </li>
-            <li class="normal" id="section-6.2.1-5.6">
-              <p id="section-6.2.1-5.6.1">The unprotected header of the COSE_Encrypt0 object MUST include the 'Partial IV' parameter, with value the Partial IV computed above.<a href="#section-6.2.1-5.6.1" class="pilcrow">¶</a></p>
+            <li class="normal" id="section-6.2.1-6.6">
+              <p id="section-6.2.1-6.6.1">The unprotected header of the COSE_Encrypt0 object MUST include the 'Partial IV' parameter, with value the Partial IV computed above.<a href="#section-6.2.1-6.6.1" class="pilcrow">¶</a></p>
 </li>
           </ul>
-<p id="section-6.2.1-6">In order to ensure source authentication, each rekeying message protected with the administrative keying material MUST be signed by the KDC. To this end, the KDC computes a countersignature of the COSE_Encrypt0 object, as described in Sections <a href="https://rfc-editor.org/rfc/rfc9338#section-3.2" class="relref">3.2</a> and <a href="https://rfc-editor.org/rfc/rfc9338#section-3.3" class="relref">3.3</a> of <span>[<a href="#RFC9338" class="cite xref">RFC9338</a>]</span>. In particular, the following applies when computing the countersignature.<a href="#section-6.2.1-6" class="pilcrow">¶</a></p>
+<p id="section-6.2.1-7">In order to ensure source authentication, each rekeying message protected with the administrative keying material MUST be signed by the KDC. To this end, the KDC computes a countersignature of the COSE_Encrypt0 object, as described in Sections <a href="https://rfc-editor.org/rfc/rfc9338#section-3.2" class="relref">3.2</a> and <a href="https://rfc-editor.org/rfc/rfc9338#section-3.3" class="relref">3.3</a> of <span>[<a href="#RFC9338" class="cite xref">RFC9338</a>]</span>. In particular, the following applies when computing the countersignature.<a href="#section-6.2.1-7" class="pilcrow">¶</a></p>
 <ul class="normal">
-<li class="normal" id="section-6.2.1-7.1">
-              <p id="section-6.2.1-7.1.1">The Countersign_structure contains the context text string "CounterSignature0".<a href="#section-6.2.1-7.1.1" class="pilcrow">¶</a></p>
+<li class="normal" id="section-6.2.1-8.1">
+              <p id="section-6.2.1-8.1.1">The Countersign_structure contains the context text string "CounterSignature0".<a href="#section-6.2.1-8.1.1" class="pilcrow">¶</a></p>
 </li>
-            <li class="normal" id="section-6.2.1-7.2">
-              <p id="section-6.2.1-7.2.1">The private key of the KDC is used as signing key.<a href="#section-6.2.1-7.2.1" class="pilcrow">¶</a></p>
+            <li class="normal" id="section-6.2.1-8.2">
+              <p id="section-6.2.1-8.2.1">The private key of the KDC is used as signing key.<a href="#section-6.2.1-8.2.1" class="pilcrow">¶</a></p>
 </li>
-            <li class="normal" id="section-6.2.1-7.3">
-              <p id="section-6.2.1-7.3.1">The payload is the ciphertext of the COSE_Encrypt0 object.<a href="#section-6.2.1-7.3.1" class="pilcrow">¶</a></p>
+            <li class="normal" id="section-6.2.1-8.3">
+              <p id="section-6.2.1-8.3.1">The payload is the ciphertext of the COSE_Encrypt0 object.<a href="#section-6.2.1-8.3.1" class="pilcrow">¶</a></p>
 </li>
-            <li class="normal" id="section-6.2.1-7.4">
-              <p id="section-6.2.1-7.4.1">The Additional Authenticated Data (AAD) is empty, unless otherwise specified by separate documents profiling the use of a group rekeying scheme.<a href="#section-6.2.1-7.4.1" class="pilcrow">¶</a></p>
+            <li class="normal" id="section-6.2.1-8.4">
+              <p id="section-6.2.1-8.4.1">The Additional Authenticated Data (AAD) is empty, unless otherwise specified by separate documents profiling the use of a group rekeying scheme.<a href="#section-6.2.1-8.4.1" class="pilcrow">¶</a></p>
 </li>
-            <li class="normal" id="section-6.2.1-7.5">
-              <p id="section-6.2.1-7.5.1">The protected header of the signing object MUST include the parameter 'alg', specifying the used signature algorithm.<a href="#section-6.2.1-7.5.1" class="pilcrow">¶</a></p>
+            <li class="normal" id="section-6.2.1-8.5">
+              <p id="section-6.2.1-8.5.1">The protected header of the signing object MUST include the parameter 'alg', specifying the used signature algorithm.<a href="#section-6.2.1-8.5.1" class="pilcrow">¶</a></p>
 </li>
           </ul>
-<p id="section-6.2.1-8">If source authentication of messages exchanged in the group is also ensured by means of signatures, then rekeying messages MUST be signed using the same signature algorithm and related parameters. Also, the KDC's authentication credential including the public key to use for signature verification MUST be provided in the Join Response through the 'kdc_cred' parameter, together with the corresponding proof-of-possession (PoP) evidence in the 'kdc_cred_verify' parameter.<a href="#section-6.2.1-8" class="pilcrow">¶</a></p>
-<p id="section-6.2.1-9">If source authentication of messages exchanged in the group is not ensured by means of signatures, then the KDC MUST provide its authentication credential together with a corresponding PoP evidence as part of the management keying material specified in the 'mgt_key_material' parameter of the Join Response (see <a href="#gid-post" class="auto internal xref">Section 4.3.1</a>). It is RECOMMENDED to specify this information by using the same format and encoding used for the parameters 'kdc_cred', 'kdc_nonce', and 'kdc_cred_verify' in the Join Response. It is up to separate documents profiling the use of the group rekeying scheme to specify such details.<a href="#section-6.2.1-9" class="pilcrow">¶</a></p>
-<p id="section-6.2.1-10">After that, the KDC specifies the computed countersignature in the 'COSE_Countersignature0' header parameter of the COSE_Encrypt0 object.<a href="#section-6.2.1-10" class="pilcrow">¶</a></p>
-<p id="section-6.2.1-11">Finally, the KDC specifies the COSE_Encrypt0 object as payload of a CoAP request, which is sent to the target group members as per the used message delivery method.<a href="#section-6.2.1-11" class="pilcrow">¶</a></p>
+<p id="section-6.2.1-9">If source authentication of messages exchanged in the group is also ensured by means of signatures, then rekeying messages MUST be signed using the same signature algorithm and related parameters. Also, the KDC's authentication credential including the public key to use for signature verification MUST be provided in the Join Response through the 'kdc_cred' parameter, together with the corresponding proof-of-possession (PoP) evidence in the 'kdc_cred_verify' parameter.<a href="#section-6.2.1-9" class="pilcrow">¶</a></p>
+<p id="section-6.2.1-10">If source authentication of messages exchanged in the group is not ensured by means of signatures, then the KDC MUST provide its authentication credential together with a corresponding PoP evidence as part of the management keying material specified in the 'mgt_key_material' parameter of the Join Response (see <a href="#gid-post" class="auto internal xref">Section 4.3.1</a>). It is RECOMMENDED to specify this information by using the same format and encoding used for the parameters 'kdc_cred', 'kdc_nonce', and 'kdc_cred_verify' in the Join Response. It is up to separate documents profiling the use of the group rekeying scheme to specify such details.<a href="#section-6.2.1-10" class="pilcrow">¶</a></p>
+<p id="section-6.2.1-11">After that, the KDC specifies the computed countersignature in the 'COSE_Countersignature0' header parameter of the COSE_Encrypt0 object.<a href="#section-6.2.1-11" class="pilcrow">¶</a></p>
+<p id="section-6.2.1-12">Finally, the KDC specifies the COSE_Encrypt0 object as payload of a CoAP request, which is sent to the target group members as per the used message delivery method.<a href="#section-6.2.1-12" class="pilcrow">¶</a></p>
 </section>
 </div>
 </section>
@@ -3767,11 +4084,13 @@ <h2 id="name-extended-scope-format">
 <p id="section-7-3">The extended format is intended only for the 'scope' claim of access tokens, for the cases where the claim takes as value a CBOR byte string. That is, the extended format does not apply to the 'scope' parameter included in ACE messages, i.e., the Authorization Request and Authorization Response exchanged between the Client and the Authorization Server (see Sections <a href="https://rfc-editor.org/rfc/rfc9200#section-5.8.1" class="relref">5.8.1</a> and <a href="https://rfc-editor.org/rfc/rfc9200#section-5.8.2" class="relref">5.8.2</a> of <span>[<a href="#RFC9200" class="cite xref">RFC9200</a>]</span>), the AS Request Creation Hints message from the Resource Server (see <span><a href="https://rfc-editor.org/rfc/rfc9200#section-5.3" class="relref">Section 5.3</a> of [<a href="#RFC9200" class="cite xref">RFC9200</a>]</span>), and the Introspection Response from the Authorization Server (see <span><a href="https://rfc-editor.org/rfc/rfc9200#section-5.9.2" class="relref">Section 5.9.2</a> of [<a href="#RFC9200" class="cite xref">RFC9200</a>]</span>).<a href="#section-7-3" class="pilcrow">¶</a></p>
 <p id="section-7-4">The value of the 'scope' claim following the extended format is composed as follows. Given the original scope using a semantics SEM and encoded as a CBOR byte string, the corresponding extended scope consists of the same CBOR byte string enclosed by a CBOR tag <span>[<a href="#RFC8949" class="cite xref">RFC8949</a>]</span>, whose tag number identifies the semantics SEM.<a href="#section-7-4" class="pilcrow">¶</a></p>
 <p id="section-7-5">The resulting tagged CBOR byte string is used as value of the 'scope' claim of the access token.<a href="#section-7-5" class="pilcrow">¶</a></p>
-<p id="section-7-6"><a href="#cddl-ex-0-ext" class="auto internal xref">Figure 37</a> and <a href="#cddl-ex-ext" class="auto internal xref">Figure 38</a> build on the examples in <a href="#ssec-authorization-response" class="auto internal xref">Section 3.2</a>, and show the corresponding extended scopes.<a href="#section-7-6" class="pilcrow">¶</a></p>
+<p id="section-7-6"><a href="#cddl-ex-0-ext" class="auto internal xref">Figure 40</a> and <a href="#cddl-ex-ext" class="auto internal xref">Figure 41</a> build on the examples in <a href="#ssec-authorization-response" class="auto internal xref">Section 3.2</a>, and show the corresponding extended scopes.<a href="#section-7-6" class="pilcrow">¶</a></p>
 <span id="name-example-cdll-definition-of-"></span><div id="cddl-ex-0-ext">
-<figure id="figure-37">
+<figure id="figure-40">
         <div class="lang-CDDL sourcecode" id="section-7-7.1">
 <pre>
+;# include rfc9237
+
 gname = tstr
 
 permissions = uint .bits roles
@@ -3783,19 +4102,21 @@ <h2 id="name-extended-scope-format">
    Verifier: 4
 )
 
-scope_entry = AIF_Generic&lt;gname, permissions&gt;
+scope_entry = AIF-Generic&lt;gname, permissions&gt;
 
-scope = &lt;&lt; [ + scope_entry ] &gt;&gt;
+scope_entries = [ + scope_entry ]
+
+scope = bstr .cbor scope_entries
 
 extended_scope = #6.TAG_FOR_THIS_SEMANTICS(scope)
 </pre>
 </div>
-<figcaption><a href="#figure-37" class="selfRef">Figure 37</a>:
+<figcaption><a href="#figure-40" class="selfRef">Figure 40</a>:
 <a href="#name-example-cdll-definition-of-" class="selfRef">Example CDLL definition of scope, using the default Authorization Information Format</a>
         </figcaption></figure>
 </div>
 <span id="name-cdll-definition-of-scope-us"></span><div id="cddl-ex-ext">
-<figure id="figure-38">
+<figure id="figure-41">
         <div class="lang-CDDL sourcecode" id="section-7-8.1">
 <pre>
 gname = tstr
@@ -3804,12 +4125,14 @@ <h2 id="name-extended-scope-format">
 
 scope_entry = [ gname , ? ( role / [ 2*role ] ) ]
 
-scope = &lt;&lt; [ + scope_entry ] &gt;&gt;
+scope_entries = [ + scope_entry ]
+
+scope = bstr .cbor scope_entries
 
 extended_scope = #6.TAG_FOR_THIS_SEMANTICS(scope)
 </pre>
 </div>
-<figcaption><a href="#figure-38" class="selfRef">Figure 38</a>:
+<figcaption><a href="#figure-41" class="selfRef">Figure 41</a>:
 <a href="#name-cdll-definition-of-scope-us" class="selfRef">CDLL definition of scope, using as example group name encoded as tstr and role as tstr</a>
         </figcaption></figure>
 </div>
@@ -3827,17 +4150,13 @@ <h2 id="name-ace-groupcomm-parameters">
 <p id="section-8-1">This specification defines a number of parameters used during the second part of the message exchange, after the exchange of Token Transfer Request and Response. The table below summarizes them, and specifies the CBOR key to use instead of the full descriptive name.<a href="#section-8-1" class="pilcrow">¶</a></p>
 <p id="section-8-2">Note that the media type application/ace-groupcomm+cbor MUST be used when these parameters are transported in the respective message fields.<a href="#section-8-2" class="pilcrow">¶</a></p>
 <span id="name-ace-groupcomm-parameters-2"></span><div id="fig-ACE-Groupcomm-Parameters">
-<figure id="figure-39">
+<figure id="figure-42">
         <div class="alignCenter art-text artwork" id="section-8-3.1">
 <pre>
 +-----------------------+------+---------------------+------------+
 | Name                  | CBOR | CBOR Type           | Reference  |
 |                       | Key  |                     |            |
 +-----------------------+------+---------------------+------------+
-| error                 | TBD  | int                 | [RFC-XXXX] |
-+-----------------------+------+---------------------+------------+
-| error_description     | TBD  | tstr                | [RFC-XXXX] |
-+-----------------------+------+---------------------+------------+
 | gid                   | TBD  | array               | [RFC-XXXX] |
 +-----------------------+------+---------------------+------------+
 | gname                 | TBD  | array of tstr       | [RFC-XXXX] |
@@ -3869,7 +4188,7 @@ <h2 id="name-ace-groupcomm-parameters">
 +-----------------------+------+---------------------+------------+
 | ace_groupcomm_profile | TBD  | int                 | [RFC-XXXX] |
 +-----------------------+------+---------------------+------------+
-| exp                   | TBD  | int                 | [RFC-XXXX] |
+| exp                   | TBD  | uint                | [RFC-XXXX] |
 +-----------------------+------+---------------------+------------+
 | creds                 | TBD  | array               | [RFC-XXXX] |
 +-----------------------+------+---------------------+------------+
@@ -3897,11 +4216,11 @@ <h2 id="name-ace-groupcomm-parameters">
 +-----------------------+------+---------------------+------------+
 </pre>
 </div>
-<figcaption><a href="#figure-39" class="selfRef">Figure 39</a>:
+<figcaption><a href="#figure-42" class="selfRef">Figure 42</a>:
 <a href="#name-ace-groupcomm-parameters-2" class="selfRef">ACE Groupcomm Parameters</a>
         </figcaption></figure>
 </div>
-<p id="section-8-4">Note to RFC Editor: In <a href="#fig-ACE-Groupcomm-Parameters" class="auto internal xref">Figure 39</a>, please replace all occurrences of "[RFC-XXXX]" with the RFC number of this specification and delete this paragraph.<a href="#section-8-4" class="pilcrow">¶</a></p>
+<p id="section-8-4">Note to RFC Editor: In <a href="#fig-ACE-Groupcomm-Parameters" class="auto internal xref">Figure 42</a>, please replace all occurrences of "[RFC-XXXX]" with the RFC number of this specification and delete this paragraph.<a href="#section-8-4" class="pilcrow">¶</a></p>
 <p id="section-8-5">The KDC is expected to support all the parameters above. Instead, a Client can support only a subset of such parameters, depending on the roles it expects to take in the joined groups or on other conditions defined in application profiles of this specification.<a href="#section-8-5" class="pilcrow">¶</a></p>
 <p id="section-8-6">In the following, the parameters are categorized according to the support expected by Clients. That is, a Client that supports a parameter is able to: i) use and specify it in a request message to the KDC; and ii) understand and process it if specified in a response message from the KDC. It is REQUIRED of application profiles of this specification to sort their newly defined parameters according to the same categorization (REQ29).<a href="#section-8-6" class="pilcrow">¶</a></p>
 <p id="section-8-7">Note that the actual use of a parameter and its inclusion in a message depends on the specific exchange, the specific Client and group involved, as well as what is defined in the used application profile of this specification.<a href="#section-8-7" class="pilcrow">¶</a></p>
@@ -3917,37 +4236,31 @@ <h2 id="name-ace-groupcomm-parameters">
           <p id="section-8-11.1.1">'get_creds'. That is, not supporting this parameter would yield the inconvenient and undesirable behavior where: i) the Client does not ask for the other group members' authentication credentials upon joining the group (see <a href="#ssec-key-distribution-exchange" class="auto internal xref">Section 4.3.1.1</a>); and ii) later on as a group member, the Client only retrieves the authentication credentials of all group members (see <a href="#sec-key-retrieval-all" class="auto internal xref">Section 4.4.2.1</a>).<a href="#section-8-11.1.1" class="pilcrow">¶</a></p>
 </li>
       </ul>
-<p id="section-8-12">A Client MAY support the following optional parameters. Application profiles of this specification MAY define that Clients must or should support these parameters instead (OPT15).<a href="#section-8-12" class="pilcrow">¶</a></p>
+<p id="section-8-12">The following conditional parameters are relevant only if specific conditions hold. It is REQUIRED of application profiles of this specification to define whether Clients must, should, or may support these parameters, and under which circumstances (REQ30).<a href="#section-8-12" class="pilcrow">¶</a></p>
 <ul class="normal">
 <li class="normal" id="section-8-13.1">
-          <p id="section-8-13.1.1">'error', 'error_description'.<a href="#section-8-13.1.1" class="pilcrow">¶</a></p>
+          <p id="section-8-13.1.1">'client_cred' and 'client_cred_verify'. These parameters are relevant for a Client that has an authentication credential to use in a joined group.<a href="#section-8-13.1.1" class="pilcrow">¶</a></p>
 </li>
-      </ul>
-<p id="section-8-14">The following conditional parameters are relevant only if specific conditions hold. It is REQUIRED of application profiles of this specification to define whether Clients must, should, or may support these parameters, and under which circumstances (REQ30).<a href="#section-8-14" class="pilcrow">¶</a></p>
-<ul class="normal">
-<li class="normal" id="section-8-15.1">
-          <p id="section-8-15.1.1">'client_cred' and 'client_cred_verify'. These parameters are relevant for a Client that has an authentication credential to use in a joined group.<a href="#section-8-15.1.1" class="pilcrow">¶</a></p>
+        <li class="normal" id="section-8-13.2">
+          <p id="section-8-13.2.1">'kdcchallenge'. This parameter is relevant for a Client that has an authentication credential to use in a joined group and that provides the access token to the KDC through a Token Transfer Request (see <a href="#token-post" class="auto internal xref">Section 3.3</a>).<a href="#section-8-13.2.1" class="pilcrow">¶</a></p>
 </li>
-        <li class="normal" id="section-8-15.2">
-          <p id="section-8-15.2.1">'kdcchallenge'. This parameter is relevant for a Client that has an authentication credential to use in a joined group and that provides the access token to the KDC through a Token Transfer Request (see <a href="#token-post" class="auto internal xref">Section 3.3</a>).<a href="#section-8-15.2.1" class="pilcrow">¶</a></p>
+        <li class="normal" id="section-8-13.3">
+          <p id="section-8-13.3.1">'creds_repo'. This parameter is relevant for a Client that has an authentication credential to use in a joined group and that makes it available from a key repository different than the KDC.<a href="#section-8-13.3.1" class="pilcrow">¶</a></p>
 </li>
-        <li class="normal" id="section-8-15.3">
-          <p id="section-8-15.3.1">'creds_repo'. This parameter is relevant for a Client that has an authentication credential to use in a joined group and that makes it available from a key repository different than the KDC.<a href="#section-8-15.3.1" class="pilcrow">¶</a></p>
+        <li class="normal" id="section-8-13.4">
+          <p id="section-8-13.4.1">'group_policies'. This parameter is relevant for a Client that is interested in the specific policies used in a group, but it does not know them or cannot become aware of them before joining that group.<a href="#section-8-13.4.1" class="pilcrow">¶</a></p>
 </li>
-        <li class="normal" id="section-8-15.4">
-          <p id="section-8-15.4.1">'group_policies'. This parameter is relevant for a Client that is interested in the specific policies used in a group, but it does not know them or cannot become aware of them before joining that group.<a href="#section-8-15.4.1" class="pilcrow">¶</a></p>
+        <li class="normal" id="section-8-13.5">
+          <p id="section-8-13.5.1">'peer_roles'. This parameter is relevant for a Client that has to know about the roles of other group members, especially when retrieving and handling their corresponding authentication credentials.<a href="#section-8-13.5.1" class="pilcrow">¶</a></p>
 </li>
-        <li class="normal" id="section-8-15.5">
-          <p id="section-8-15.5.1">'peer_roles'. This parameter is relevant for a Client that has to know about the roles of other group members, especially when retrieving and handling their corresponding authentication credentials.<a href="#section-8-15.5.1" class="pilcrow">¶</a></p>
+        <li class="normal" id="section-8-13.6">
+          <p id="section-8-13.6.1">'kdc_nonce', 'kdc_cred', 'kdc_cred_verify'. These parameters are relevant for a Client that joins a group for which, as per the used application profile of this specification, the KDC has an associated authentication credential and this is required for the correct group operation.<a href="#section-8-13.6.1" class="pilcrow">¶</a></p>
 </li>
-        <li class="normal" id="section-8-15.6">
-          <p id="section-8-15.6.1">'kdc_nonce', 'kdc_cred', 'kdc_cred_verify'. These parameters are relevant for a Client that joins a group for which, as per the used application profile of this specification, the KDC has an associated authentication credential and this is required for the correct group operation.<a href="#section-8-15.6.1" class="pilcrow">¶</a></p>
+        <li class="normal" id="section-8-13.7">
+          <p id="section-8-13.7.1">'mgt_key_material'. This parameter is relevant for a Client that supports an advanced rekeying scheme possibly used in the group, such as based on one-to-many rekeying messages sent over IP multicast.<a href="#section-8-13.7.1" class="pilcrow">¶</a></p>
 </li>
-        <li class="normal" id="section-8-15.7">
-          <p id="section-8-15.7.1">'mgt_key_material'. This parameter is relevant for a Client that supports an advanced rekeying scheme possibly used in the group, such as based on one-to-many rekeying messages sent over IP multicast.<a href="#section-8-15.7.1" class="pilcrow">¶</a></p>
-</li>
-        <li class="normal" id="section-8-15.8">
-          <p id="section-8-15.8.1">'control_group_uri'. This parameter is relevant for a Client that supports the hosting of local resources each associated with a group (hence acting as CoAP server) and the reception of one-to-many requests sent to those resources by the KDC (e.g., over IP multicast), targeting multiple members of the corresponding group. Examples of related management operations that the KDC can perform by this means are the eviction of group members and the execution of a group rekeying process through an advanced rekeying scheme, such as based on one-to-many rekeying messages.<a href="#section-8-15.8.1" class="pilcrow">¶</a></p>
+        <li class="normal" id="section-8-13.8">
+          <p id="section-8-13.8.1">'control_group_uri'. This parameter is relevant for a Client that supports the hosting of local resources each associated with a group (hence acting as CoAP server) and the reception of one-to-many requests sent to those resources by the KDC (e.g., over IP multicast), targeting multiple members of the corresponding group. Examples of related management operations that the KDC can perform by this means are the eviction of group members and the execution of a group rekeying process through an advanced rekeying scheme, such as based on one-to-many rekeying messages.<a href="#section-8-13.8.1" class="pilcrow">¶</a></p>
 </li>
       </ul>
 </section>
@@ -3957,9 +4270,9 @@ <h2 id="name-ace-groupcomm-parameters">
       <h2 id="name-ace-groupcomm-error-identif">
 <a href="#section-9" class="section-number selfRef">9. </a><a href="#name-ace-groupcomm-error-identif" class="section-name selfRef">ACE Groupcomm Error Identifiers</a>
       </h2>
-<p id="section-9-1">This specification defines a number of values that the KDC can include as error identifiers, in the 'error' field of an error response with Content-Format application/ace-groupcomm+cbor.<a href="#section-9-1" class="pilcrow">¶</a></p>
+<p id="section-9-1">This specification defines a number of values that the KDC can use as error identifiers. These are used in error responses with Content-Format application/concise-problem-details+cbor, as values of the 'error-id' field within the Custom Problem Detail entry 'ace-groupcomm-error' (see <a href="#kdc-if-errors" class="auto internal xref">Section 4.1.2</a>).<a href="#section-9-1" class="pilcrow">¶</a></p>
 <span id="name-ace-groupcomm-error-identifi"></span><div id="fig-ACE-Groupcomm-Error-Identifiers">
-<figure id="figure-40">
+<figure id="figure-43">
         <div class="alignCenter art-text artwork" id="section-9-2.1">
 <pre>
 +-------+---------------------------------------------+
@@ -3982,11 +4295,11 @@ <h2 id="name-ace-groupcomm-error-identif">
 +-------+---------------------------------------------+
 </pre>
 </div>
-<figcaption><a href="#figure-40" class="selfRef">Figure 40</a>:
+<figcaption><a href="#figure-43" class="selfRef">Figure 43</a>:
 <a href="#name-ace-groupcomm-error-identifi" class="selfRef">ACE Groupcomm Error Identifiers</a>
         </figcaption></figure>
 </div>
-<p id="section-9-3">A Client supporting the 'error' parameter (see <a href="#kdc-if-errors" class="auto internal xref">Section 4.1.2</a> and <a href="#params" class="auto internal xref">Section 8</a>) and able to understand the specified error may use that information to determine what actions to take next. If it is included in the error response and supported by the Client, the 'error_description' parameter may provide additional context.<a href="#section-9-3" class="pilcrow">¶</a></p>
+<p id="section-9-3">If a Client supports the problem-details format <span>[<a href="#RFC9290" class="cite xref">RFC9290</a>]</span> and the Custom Problem Detail entry 'ace-groupcomm-error' defined in <a href="#kdc-if-errors" class="auto internal xref">Section 4.1.2</a>, and is able to understand the error specified in the 'error-id' field therein, then the Client may use that information to determine what actions to take next. If the Concise Problem Details data item specified in the error response includes the 'detail' entry and the Client supports it, such an entry may provide additional context.<a href="#section-9-3" class="pilcrow">¶</a></p>
 <p id="section-9-4">In particular, the following guidelines apply, and application profiles of this specification can define more detailed actions for the Client to take when learning that a specific error has occurred.<a href="#section-9-4" class="pilcrow">¶</a></p>
 <ul class="normal">
 <li class="normal" id="section-9-5.1">
@@ -4019,14 +4332,15 @@ <h2 id="name-security-considerations">
 <a href="#section-10" class="section-number selfRef">10. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
       </h2>
 <p id="section-10-1">Security considerations are inherited from the ACE framework <span>[<a href="#RFC9200" class="cite xref">RFC9200</a>]</span>, and from the specific transport profile of ACE used between the Clients and the KDC, e.g., <span>[<a href="#RFC9202" class="cite xref">RFC9202</a>]</span> and <span>[<a href="#RFC9203" class="cite xref">RFC9203</a>]</span>.<a href="#section-10-1" class="pilcrow">¶</a></p>
-<p id="section-10-2">Furthermore, the following security considerations apply.<a href="#section-10-2" class="pilcrow">¶</a></p>
+<p id="section-10-2">When using the problem-details format defined in <span>[<a href="#RFC9290" class="cite xref">RFC9290</a>]</span> for error responses, then the privacy and security considerations from Sections <a href="https://rfc-editor.org/rfc/rfc9290#section-4" class="relref">4</a> and <a href="https://rfc-editor.org/rfc/rfc9290#section-5" class="relref">5</a> of <span>[<a href="#RFC9290" class="cite xref">RFC9290</a>]</span> also apply.<a href="#section-10-2" class="pilcrow">¶</a></p>
+<p id="section-10-3">Furthermore, the following security considerations apply.<a href="#section-10-3" class="pilcrow">¶</a></p>
 <div id="sec-cons-communication">
 <section id="section-10.1">
         <h3 id="name-secure-communication-in-the">
 <a href="#section-10.1" class="section-number selfRef">10.1. </a><a href="#name-secure-communication-in-the" class="section-name selfRef">Secure Communication in the Group</a>
         </h3>
 <p id="section-10.1-1">When a group member receives a message from a certain sender for the first time since joining the group, it needs to have a mechanism in place to avoid replayed messages and to assert their freshness, e.g., <span><a href="https://rfc-editor.org/rfc/rfc8613#appendix-B.1.2" class="relref">Appendix B.1.2</a> of [<a href="#RFC8613" class="cite xref">RFC8613</a>]</span> or <span><a href="https://datatracker.ietf.org/doc/html/draft-ietf-core-oscore-groupcomm-20#section-10" class="relref">Section 10</a> of [<a href="#I-D.ietf-core-oscore-groupcomm" class="cite xref">I-D.ietf-core-oscore-groupcomm</a>]</span>. Such a mechanism aids the recipient group member also in case it has rebooted and lost the security state used to protect previous group communications with that sender.<a href="#section-10.1-1" class="pilcrow">¶</a></p>
-<p id="section-10.1-2">By its nature, the KDC is invested with a large amount of trust, since it acts as generator and provider of the symmetric keying material used to protect communications in each of its groups. While details depend on the specific communication and security protocols used in the group, the KDC is in the position to decrypt messages exchanged in the group as if it was also a group member, as long as those are protected through commonly shared group keying material.<a href="#section-10.1-2" class="pilcrow">¶</a></p>
+<p id="section-10.1-2">By its nature, the KDC is invested with a large amount of trust, since it acts as a generator and provider of the symmetric keying material used to protect communications in each of its groups. While details depend on the specific communication and security protocols used in the group, the KDC is in the position to decrypt messages exchanged in the group as if it was also a group member, as long as those are protected through commonly shared group keying material.<a href="#section-10.1-2" class="pilcrow">¶</a></p>
 <p id="section-10.1-3">A compromised KDC would thus put the attacker in the same position, which also means that:<a href="#section-10.1-3" class="pilcrow">¶</a></p>
 <ul class="normal">
 <li class="normal" id="section-10.1-4.1">
@@ -4050,24 +4364,25 @@ <h3 id="name-update-of-group-keying-mate">
         </h3>
 <p id="section-10.2-1">The KDC can generate new group keying material and provide it to the group members (rekeying) through the rekeying scheme used in the group, as discussed in <a href="#sec-group-rekeying" class="auto internal xref">Section 6</a>.<a href="#section-10.2-1" class="pilcrow">¶</a></p>
 <p id="section-10.2-2">In particular, the KDC must renew the group keying material latest upon its expiration. Before then, the KDC may also renew the group keying material on a regular or periodical fashion.<a href="#section-10.2-2" class="pilcrow">¶</a></p>
-<p id="section-10.2-3">Unless otherwise defined by an application profile of this specification, the KDC SHOULD renew the group keying material upon a group membership change. In particular, since the minimum number of group members is one, the KDC SHOULD provide even a Client joining an empty group with new keying material never used before in that group. Similarly, the KDC SHOULD provide new group keying material also to a Client that remains the only member in the group after the leaving of other group members.<a href="#section-10.2-3" class="pilcrow">¶</a></p>
-<p id="section-10.2-4">Note that the considerations in <a href="#sec-cons-communication" class="auto internal xref">Section 10.1</a> about dealing with replayed messages still hold, even in case the KDC rekeys the group upon every single joining of a new group member. However, if the KDC has renewed the group keying material upon a group member's joining, and the time interval between the end of the rekeying process and that member's joining is sufficiently small, then that group member is also on the safe side, since it would not accept replayed messages protected with the old group keying material previous to its joining.<a href="#section-10.2-4" class="pilcrow">¶</a></p>
-<p id="section-10.2-5">Once a joining node has obtained the new, latest keying material through a Join Response from the KDC (see <a href="#ssec-key-distribution-exchange" class="auto internal xref">Section 4.3.1.1</a>), the joining node becomes able to read any message that was exchanged in the group and protected with that keying material. This is the case if the KDC provides the current group members with the new, latest keying material before completing the joining procedure. However, the joining node is not able to read messages exchanged in the group and protected with keying material older than the one provided in the Join Response, i.e., having a strictly lower version number NUM.<a href="#section-10.2-5" class="pilcrow">¶</a></p>
-<p id="section-10.2-6">A node that has left the group should not expect any of its outgoing messages to be successfully processed, if received by other nodes in the group after its leaving, due to a possible group rekeying occurred before the message reception.<a href="#section-10.2-6" class="pilcrow">¶</a></p>
-<p id="section-10.2-7">The KDC may enforce a rekeying policy that takes into account the overall time required to rekey the group, as well as the expected rate of changes in the group membership. That is, the KDC may not rekey the group at each and every group membership change, for instance if members' joining and leaving occur frequently and performing a group rekeying takes too long. Instead, the KDC might rekey the group after a minimum number of group members have joined or left within a given time interval, or after a maximum amount of time since the last group rekeying was completed, or yet during predictable network inactivity periods.<a href="#section-10.2-7" class="pilcrow">¶</a></p>
-<p id="section-10.2-8">However, this would result in the KDC not constantly preserving backward and forward security in the group. That is:<a href="#section-10.2-8" class="pilcrow">¶</a></p>
+<p id="section-10.2-3">Unless otherwise defined by an application profile of this specification, the KDC SHOULD renew the group keying material upon a group membership change. As a possible exception, the KDC may not rekey the group upon the joining of a new group member, if the application does not require backward security. As another possible exception discussed more in detail later in this section, the KDC may rely on a rekeying policy that reasonably take into account the expected rate of group membership changes and the duration of a group rekeying.<a href="#section-10.2-3" class="pilcrow">¶</a></p>
+<p id="section-10.2-4">Since the minimum number of group members is one, the KDC SHOULD provide even a Client joining an empty group with new keying material never used before in that group. Similarly, the KDC SHOULD provide new group keying material also to a Client that remains the only member in the group after the leaving of other group members.<a href="#section-10.2-4" class="pilcrow">¶</a></p>
+<p id="section-10.2-5">Note that the considerations in <a href="#sec-cons-communication" class="auto internal xref">Section 10.1</a> about dealing with replayed messages still hold, even in case the KDC rekeys the group upon every single joining of a new group member. However, if the KDC has renewed the group keying material upon a group member's joining, and the time interval between the end of the rekeying process and that member's joining is sufficiently small, then that group member is also on the safe side, since it would not accept replayed messages protected with the old group keying material previous to its joining.<a href="#section-10.2-5" class="pilcrow">¶</a></p>
+<p id="section-10.2-6">Once a joining node has obtained the new, latest keying material through a Join Response from the KDC (see <a href="#ssec-key-distribution-exchange" class="auto internal xref">Section 4.3.1.1</a>), the joining node becomes able to read any message that was exchanged in the group and protected with that keying material. This is the case if the KDC provides the current group members with the new, latest keying material before completing the joining procedure. However, the joining node is not able to read messages exchanged in the group and protected with keying material older than the one provided in the Join Response, i.e., having a strictly lower version number NUM.<a href="#section-10.2-6" class="pilcrow">¶</a></p>
+<p id="section-10.2-7">A node that has left the group should not expect any of its outgoing messages to be successfully processed, if received by other nodes in the group after its leaving, due to a possible group rekeying occurred before the message reception.<a href="#section-10.2-7" class="pilcrow">¶</a></p>
+<p id="section-10.2-8">The KDC may enforce a rekeying policy that takes into account the overall time required to rekey the group, as well as the expected rate of changes in the group membership. That is, the KDC may not rekey the group at each and every group membership change, for instance if members' joining and leaving occur frequently and performing a group rekeying takes too long. Instead, the KDC might rekey the group after a minimum number of group members have joined or left within a given time interval, or after a maximum amount of time since the last group rekeying was completed, or yet during predictable network inactivity periods.<a href="#section-10.2-8" class="pilcrow">¶</a></p>
+<p id="section-10.2-9">However, this would result in the KDC not constantly preserving backward and forward security in the group. That is:<a href="#section-10.2-9" class="pilcrow">¶</a></p>
 <ul class="normal">
-<li class="normal" id="section-10.2-9.1">
-            <p id="section-10.2-9.1.1">Newly joining group members would be able to access the keying material used before their joining, and thus they could access past group communications if they have recorded old exchanged messages. This might still be acceptable for some applications and in situations where the new group members are freshly deployed through strictly controlled procedures.<a href="#section-10.2-9.1.1" class="pilcrow">¶</a></p>
+<li class="normal" id="section-10.2-10.1">
+            <p id="section-10.2-10.1.1">Newly joining group members would be able to access the keying material used before their joining, and thus they could access past group communications if they have recorded old exchanged messages. This might still be acceptable for some applications and in situations where the new group members are freshly deployed through strictly controlled procedures.<a href="#section-10.2-10.1.1" class="pilcrow">¶</a></p>
 </li>
-          <li class="normal" id="section-10.2-9.2">
-            <p id="section-10.2-9.2.1">The leaving group members would remain able to access upcoming group communications, as protected with the current keying material that has not been updated. This is typically undesirable, especially if the leaving group member is compromised or suspected to be, and it might have an impact or compromise the security properties of the protocols used in the group to protect messages exchanged among the group members.<a href="#section-10.2-9.2.1" class="pilcrow">¶</a></p>
+          <li class="normal" id="section-10.2-10.2">
+            <p id="section-10.2-10.2.1">The leaving group members would remain able to access upcoming group communications, as protected with the current keying material that has not been updated. This is typically undesirable, especially if the leaving group member is compromised or suspected to be, and it might have an impact or compromise the security properties of the protocols used in the group to protect messages exchanged among the group members.<a href="#section-10.2-10.2.1" class="pilcrow">¶</a></p>
 </li>
         </ul>
-<p id="section-10.2-10">The KDC should renew the group keying material in case it has rebooted, even if it stores the whole group keying material in persistent storage. This assumes that the secure associations with the current group members as well as any administrative keying material required to rekey the group are also stored in persistent storage.<a href="#section-10.2-10" class="pilcrow">¶</a></p>
-<p id="section-10.2-11">However, if the KDC relies on Observe notifications to distribute the new group keying material, the KDC would have lost all the current ongoing Observations with the group members after rebooting, and the group members would continue using the old group keying material. Therefore, the KDC will rather rely on each group member asking for the new group keying material (see <a href="#ssec-key-material-retrieval" class="auto internal xref">Section 4.3.2.1</a> and <a href="#update-keys" class="auto internal xref">Section 4.8.1.1</a>), or rather perform a group rekeying by actively sending rekeying messages to group members as discussed in <a href="#sec-group-rekeying" class="auto internal xref">Section 6</a>.<a href="#section-10.2-11" class="pilcrow">¶</a></p>
-<p id="section-10.2-12">The KDC needs to have a mechanism in place to detect DoS attacks from nodes repeatedly performing actions that might trigger a group rekeying. Such actions can include leaving and/or re-joining the group at high rates, or often asking the KDC for new indidivual keying material. Ultimately, the KDC can resort to removing these nodes from the group and (temporarily) preventing them from joining the group again.<a href="#section-10.2-12" class="pilcrow">¶</a></p>
-<p id="section-10.2-13">The KDC also needs to have a congestion control mechanism in place, in order to avoid network congestion upon distributing new group keying material. For example, CoAP and Observe give guidance on such mechanisms, see <span><a href="https://rfc-editor.org/rfc/rfc7252#section-4.7" class="relref">Section 4.7</a> of [<a href="#RFC7252" class="cite xref">RFC7252</a>]</span> and <span><a href="https://rfc-editor.org/rfc/rfc7641#section-4.5.1" class="relref">Section 4.5.1</a> of [<a href="#RFC7641" class="cite xref">RFC7641</a>]</span>.<a href="#section-10.2-13" class="pilcrow">¶</a></p>
+<p id="section-10.2-11">The KDC should renew the group keying material in case it has rebooted, even if it stores the whole group keying material in persistent storage. This assumes that the secure associations with the current group members as well as any administrative keying material required to rekey the group are also stored in persistent storage.<a href="#section-10.2-11" class="pilcrow">¶</a></p>
+<p id="section-10.2-12">However, if the KDC relies on Observe notifications to distribute the new group keying material, the KDC would have lost all the current ongoing Observations with the group members after rebooting, and the group members would continue using the old group keying material. Therefore, the KDC will rather rely on each group member asking for the new group keying material (see <a href="#ssec-key-material-retrieval" class="auto internal xref">Section 4.3.2.1</a> and <a href="#update-keys" class="auto internal xref">Section 4.8.1.1</a>), or rather perform a group rekeying by actively sending rekeying messages to group members as discussed in <a href="#sec-group-rekeying" class="auto internal xref">Section 6</a>.<a href="#section-10.2-12" class="pilcrow">¶</a></p>
+<p id="section-10.2-13">The KDC needs to have a mechanism in place to detect DoS attacks from nodes repeatedly performing actions that might trigger a group rekeying. Such actions can include leaving and/or re-joining the group at high rates, or often asking the KDC for new indidivual keying material. Ultimately, the KDC can resort to removing these nodes from the group and (temporarily) preventing them from joining the group again.<a href="#section-10.2-13" class="pilcrow">¶</a></p>
+<p id="section-10.2-14">The KDC also needs to have a congestion control mechanism in place, in order to avoid network congestion upon distributing new group keying material. For example, CoAP and Observe give guidance on such mechanisms, see <span><a href="https://rfc-editor.org/rfc/rfc7252#section-4.7" class="relref">Section 4.7</a> of [<a href="#RFC7252" class="cite xref">RFC7252</a>]</span> and <span><a href="https://rfc-editor.org/rfc/rfc7641#section-4.5.1" class="relref">Section 4.5.1</a> of [<a href="#RFC7641" class="cite xref">RFC7641</a>]</span>.<a href="#section-10.2-14" class="pilcrow">¶</a></p>
 </section>
 </div>
 <div id="block-wise-considerations">
@@ -4118,8 +4433,8 @@ <h3 id="name-coap-content-formats">
 <a href="#section-11.2" class="section-number selfRef">11.2. </a><a href="#name-coap-content-formats" class="section-name selfRef">CoAP Content-Formats</a>
         </h3>
 <p id="section-11.2-1">IANA is asked to register the following entry to the "CoAP Content-Formats" registry within the "CoRE Parameters" registry group.<a href="#section-11.2-1" class="pilcrow">¶</a></p>
-<p id="section-11.2-2">Media Type: application/ace-groupcomm+cbor<a href="#section-11.2-2" class="pilcrow">¶</a></p>
-<p id="section-11.2-3">Encoding: -<a href="#section-11.2-3" class="pilcrow">¶</a></p>
+<p id="section-11.2-2">Content Type: application/ace-groupcomm+cbor<a href="#section-11.2-2" class="pilcrow">¶</a></p>
+<p id="section-11.2-3">Content Coding: -<a href="#section-11.2-3" class="pilcrow">¶</a></p>
 <p id="section-11.2-4">ID: TBD<a href="#section-11.2-4" class="pilcrow">¶</a></p>
 <p id="section-11.2-5">Reference: [RFC-XXXX]<a href="#section-11.2-5" class="pilcrow">¶</a></p>
 </section>
@@ -4207,50 +4522,61 @@ <h3 id="name-interface-description-if-li">
 <p id="section-11.5-1">IANA is asked to register the following entry in the "Interface Description (if=) Link Target Attribute Values" registry within the "CoRE Parameters" registry group.<a href="#section-11.5-1" class="pilcrow">¶</a></p>
 <ul class="normal">
 <li class="normal" id="section-11.5-2.1">
-            <p id="section-11.5-2.1.1">Attribute Value: ace.group<a href="#section-11.5-2.1.1" class="pilcrow">¶</a></p>
+            <p id="section-11.5-2.1.1">Value: ace.groups<a href="#section-11.5-2.1.1" class="pilcrow">¶</a></p>
 </li>
           <li class="normal" id="section-11.5-2.2">
-            <p id="section-11.5-2.2.1">Description: The 'ace group' interface is used to provision keying material and related information and policies to members of a group using the ACE framework.<a href="#section-11.5-2.2.1" class="pilcrow">¶</a></p>
+            <p id="section-11.5-2.2.1">Description: The KDC interface at the parent resource of group-membership resources is used to retrieve names of security groups using the ACE framework.<a href="#section-11.5-2.2.1" class="pilcrow">¶</a></p>
 </li>
           <li class="normal" id="section-11.5-2.3">
-            <p id="section-11.5-2.3.1">Reference: [RFC-XXXX]<a href="#section-11.5-2.3.1" class="pilcrow">¶</a></p>
+            <p id="section-11.5-2.3.1">Reference: <a href="#kdc-if" class="auto internal xref">Section 4.1</a> of [RFC-XXXX]<a href="#section-11.5-2.3.1" class="pilcrow">¶</a></p>
+</li>
+        </ul>
+<p id="section-11.5-3"></p>
+<ul class="normal">
+<li class="normal" id="section-11.5-4.1">
+            <p id="section-11.5-4.1.1">Value: ace.group<a href="#section-11.5-4.1.1" class="pilcrow">¶</a></p>
+</li>
+          <li class="normal" id="section-11.5-4.2">
+            <p id="section-11.5-4.2.1">Description: The KDC interface at a group-membership resource is used to provision keying material and related information and policies to members of the corresponding security group using the ACE framework.<a href="#section-11.5-4.2.1" class="pilcrow">¶</a></p>
+</li>
+          <li class="normal" id="section-11.5-4.3">
+            <p id="section-11.5-4.3.1">Reference: <a href="#kdc-if" class="auto internal xref">Section 4.1</a> of [RFC-XXXX]<a href="#section-11.5-4.3.1" class="pilcrow">¶</a></p>
 </li>
         </ul>
 </section>
 </div>
-<div id="iana-reg">
+<div id="iana-custom-problem-details">
 <section id="section-11.6">
-        <h3 id="name-ace-groupcomm-parameters-3">
-<a href="#section-11.6" class="section-number selfRef">11.6. </a><a href="#name-ace-groupcomm-parameters-3" class="section-name selfRef">ACE Groupcomm Parameters</a>
+        <h3 id="name-custom-problem-detail-keys-">
+<a href="#section-11.6" class="section-number selfRef">11.6. </a><a href="#name-custom-problem-detail-keys-" class="section-name selfRef">Custom Problem Detail Keys Registry</a>
         </h3>
-<p id="section-11.6-1">This specification establishes the "ACE Groupcomm Parameters" IANA registry within the "Authentication and Authorization for Constrained Environments (ACE)" registry group.<a href="#section-11.6-1" class="pilcrow">¶</a></p>
-<p id="section-11.6-2">The registry has been created to use the "Expert Review" registration procedure <span>[<a href="#RFC8126" class="cite xref">RFC8126</a>]</span>. Expert review guidelines are provided in <a href="#review" class="auto internal xref">Section 11.13</a>. Values in this registry are covered by different registration policies as indicated. It should be noted that, in addition to the expert review, some portions of the registry require a specification, potentially a Standards Track RFC, to be supplied as well.<a href="#section-11.6-2" class="pilcrow">¶</a></p>
-<p id="section-11.6-3">The columns of this registry are:<a href="#section-11.6-3" class="pilcrow">¶</a></p>
+<p id="section-11.6-1">IANA is asked to register the following entry in the "Custom Problem Detail Keys" registry within the "CoRE Parameters" registry group.<a href="#section-11.6-1" class="pilcrow">¶</a></p>
 <ul class="normal">
-<li class="normal" id="section-11.6-4.1">
-            <p id="section-11.6-4.1.1">Name: This is a descriptive name that enables easier reference to
-the item. The name MUST be unique. It is not used in the encoding.<a href="#section-11.6-4.1.1" class="pilcrow">¶</a></p>
+<li class="normal" id="section-11.6-2.1">
+            <p id="section-11.6-2.1.1">Key Value: TBD<a href="#section-11.6-2.1.1" class="pilcrow">¶</a></p>
+</li>
+          <li class="normal" id="section-11.6-2.2">
+            <p id="section-11.6-2.2.1">Name: ace-groupcomm-error<a href="#section-11.6-2.2.1" class="pilcrow">¶</a></p>
 </li>
-          <li class="normal" id="section-11.6-4.2">
-            <p id="section-11.6-4.2.1">CBOR Key: This is the value used as the CBOR key of the item. These values MUST be unique. The value can be a positive integer, a negative integer, or a text string. Different ranges of values use different registration policies <span>[<a href="#RFC8126" class="cite xref">RFC8126</a>]</span>. Integer values from -256 to 255 as well as text strings of length 1 are designated as "Standards Action With Expert Review". Integer values from -65536 to -257 and from 256 to 65535, as well as text strings of length 2 are designated as "Specification Required". Integer values greater than 65535 as well as text strings of length greater than 2 are designated as "Expert Review". Integer values less than -65536 are marked as "Private Use".<a href="#section-11.6-4.2.1" class="pilcrow">¶</a></p>
+          <li class="normal" id="section-11.6-2.3">
+            <p id="section-11.6-2.3.1">Brief Description: Carry [RFC-XXXX] problem details in a Concise Problem Details data item.<a href="#section-11.6-2.3.1" class="pilcrow">¶</a></p>
 </li>
-          <li class="normal" id="section-11.6-4.3">
-            <p id="section-11.6-4.3.1">CBOR Type: This contains the CBOR type of the item, or a pointer to the registry that defines its type, when that depends on another item.<a href="#section-11.6-4.3.1" class="pilcrow">¶</a></p>
+          <li class="normal" id="section-11.6-2.4">
+            <p id="section-11.6-2.4.1">Change Controller: IETF<a href="#section-11.6-2.4.1" class="pilcrow">¶</a></p>
 </li>
-          <li class="normal" id="section-11.6-4.4">
-            <p id="section-11.6-4.4.1">Reference: This contains a pointer to the public specification for the item.<a href="#section-11.6-4.4.1" class="pilcrow">¶</a></p>
+          <li class="normal" id="section-11.6-2.5">
+            <p id="section-11.6-2.5.1">Reference: <a href="#kdc-if-errors" class="auto internal xref">Section 4.1.2</a> of [RFC-XXXX]<a href="#section-11.6-2.5.1" class="pilcrow">¶</a></p>
 </li>
         </ul>
-<p id="section-11.6-5">This registry has been initially populated with the values in <a href="#fig-ACE-Groupcomm-Parameters" class="auto internal xref">Figure 39</a>.<a href="#section-11.6-5" class="pilcrow">¶</a></p>
 </section>
 </div>
-<div id="iana-key">
+<div id="iana-reg">
 <section id="section-11.7">
-        <h3 id="name-ace-groupcomm-key-types-2">
-<a href="#section-11.7" class="section-number selfRef">11.7. </a><a href="#name-ace-groupcomm-key-types-2" class="section-name selfRef">ACE Groupcomm Key Types</a>
+        <h3 id="name-ace-groupcomm-parameters-3">
+<a href="#section-11.7" class="section-number selfRef">11.7. </a><a href="#name-ace-groupcomm-parameters-3" class="section-name selfRef">ACE Groupcomm Parameters</a>
         </h3>
-<p id="section-11.7-1">This specification establishes the "ACE Groupcomm Key Types" IANA registry within the "Authentication and Authorization for Constrained Environments (ACE)" registry group.<a href="#section-11.7-1" class="pilcrow">¶</a></p>
-<p id="section-11.7-2">The registry has been created to use the "Expert Review" registration procedure <span>[<a href="#RFC8126" class="cite xref">RFC8126</a>]</span>. Expert review guidelines are provided in <a href="#review" class="auto internal xref">Section 11.13</a>. Values in this registry are covered by different registration policies as indicated. It should be noted that, in addition to the expert review, some portions of the registry require a specification, potentially a Standards Track RFC, to be supplied as well.<a href="#section-11.7-2" class="pilcrow">¶</a></p>
+<p id="section-11.7-1">This specification establishes the "ACE Groupcomm Parameters" IANA registry within the "Authentication and Authorization for Constrained Environments (ACE)" registry group.<a href="#section-11.7-1" class="pilcrow">¶</a></p>
+<p id="section-11.7-2">The registry has been created to use the "Expert Review" registration procedure <span>[<a href="#RFC8126" class="cite xref">RFC8126</a>]</span>. Expert review guidelines are provided in <a href="#review" class="auto internal xref">Section 11.14</a>. Values in this registry are covered by different registration policies as indicated. It should be noted that, in addition to the expert review, some portions of the registry require a specification, potentially a Standards Track RFC, to be supplied as well.<a href="#section-11.7-2" class="pilcrow">¶</a></p>
 <p id="section-11.7-3">The columns of this registry are:<a href="#section-11.7-3" class="pilcrow">¶</a></p>
 <ul class="normal">
 <li class="normal" id="section-11.7-4.1">
@@ -4258,162 +4584,188 @@ <h3 id="name-ace-groupcomm-key-types-2">
 the item. The name MUST be unique. It is not used in the encoding.<a href="#section-11.7-4.1.1" class="pilcrow">¶</a></p>
 </li>
           <li class="normal" id="section-11.7-4.2">
-            <p id="section-11.7-4.2.1">Key Type Value: This is the value used to identify the keying material. These values MUST be unique. The value can be a positive integer, a negative integer, or a text string. Different ranges of values use different registration policies <span>[<a href="#RFC8126" class="cite xref">RFC8126</a>]</span>. Integer values from -256 to 255 as well as text strings of length 1 are designated as "Standards Action With Expert Review". Integer values from -65536 to -257 and from 256 to 65535, as well as text strings of length 2 are designated as "Specification Required". Integer values greater than 65535 as well as text strings of length greater than 2 are designated as "Expert Review". Integer values less than -65536 are marked as "Private Use".<a href="#section-11.7-4.2.1" class="pilcrow">¶</a></p>
+            <p id="section-11.7-4.2.1">CBOR Key: This is the value used as the CBOR key of the item. These values MUST be unique. The value can be a positive integer, a negative integer, or a text string. Different ranges of values use different registration policies <span>[<a href="#RFC8126" class="cite xref">RFC8126</a>]</span>. Integer values from -256 to 255 as well as text strings of length 1 are designated as "Standards Action With Expert Review". Integer values from -65536 to -257 and from 256 to 65535, as well as text strings of length 2 are designated as "Specification Required". Integer values greater than 65535 as well as text strings of length greater than 2 are designated as "Expert Review". Integer values less than -65536 are marked as "Private Use".<a href="#section-11.7-4.2.1" class="pilcrow">¶</a></p>
 </li>
           <li class="normal" id="section-11.7-4.3">
-            <p id="section-11.7-4.3.1">Profile: This field may contain one or more descriptive strings of application profiles to be used with this item. The values should be taken from the Name column of the "ACE Groupcomm Profiles" registry.<a href="#section-11.7-4.3.1" class="pilcrow">¶</a></p>
+            <p id="section-11.7-4.3.1">CBOR Type: This contains the CBOR type of the item, or a pointer to the registry that defines its type, when that depends on another item.<a href="#section-11.7-4.3.1" class="pilcrow">¶</a></p>
 </li>
           <li class="normal" id="section-11.7-4.4">
-            <p id="section-11.7-4.4.1">Description: This field contains a brief description of the keying material.<a href="#section-11.7-4.4.1" class="pilcrow">¶</a></p>
-</li>
-          <li class="normal" id="section-11.7-4.5">
-            <p id="section-11.7-4.5.1">Reference: This contains a pointer to the public specification for the format of the keying material, if one exists.<a href="#section-11.7-4.5.1" class="pilcrow">¶</a></p>
+            <p id="section-11.7-4.4.1">Reference: This contains a pointer to the public specification for the item.<a href="#section-11.7-4.4.1" class="pilcrow">¶</a></p>
 </li>
         </ul>
-<p id="section-11.7-5">This registry has been initially populated with the value in <a href="#fig-gkty" class="auto internal xref">Figure 10</a>.<a href="#section-11.7-5" class="pilcrow">¶</a></p>
+<p id="section-11.7-5">This registry has been initially populated with the values in <a href="#fig-ACE-Groupcomm-Parameters" class="auto internal xref">Figure 42</a>.<a href="#section-11.7-5" class="pilcrow">¶</a></p>
 </section>
 </div>
-<div id="ace-groupcomm-profiles">
+<div id="iana-key">
 <section id="section-11.8">
-        <h3 id="name-ace-groupcomm-profiles-2">
-<a href="#section-11.8" class="section-number selfRef">11.8. </a><a href="#name-ace-groupcomm-profiles-2" class="section-name selfRef">ACE Groupcomm Profiles</a>
+        <h3 id="name-ace-groupcomm-key-types-2">
+<a href="#section-11.8" class="section-number selfRef">11.8. </a><a href="#name-ace-groupcomm-key-types-2" class="section-name selfRef">ACE Groupcomm Key Types</a>
         </h3>
-<p id="section-11.8-1">This specification establishes the "ACE Groupcomm Profiles" IANA registry within the "Authentication and Authorization for Constrained Environments (ACE)" registry group.<a href="#section-11.8-1" class="pilcrow">¶</a></p>
-<p id="section-11.8-2">The registry has been created to use the "Expert Review" registration procedure <span>[<a href="#RFC8126" class="cite xref">RFC8126</a>]</span>. Expert review guidelines are provided in <a href="#review" class="auto internal xref">Section 11.13</a>. Values in this registry are covered by different registration policies as indicated. It should be noted that, in addition to the expert review, some portions of the registry require a specification, potentially a Standards Track RFC, to be supplied as well.<a href="#section-11.8-2" class="pilcrow">¶</a></p>
+<p id="section-11.8-1">This specification establishes the "ACE Groupcomm Key Types" IANA registry within the "Authentication and Authorization for Constrained Environments (ACE)" registry group.<a href="#section-11.8-1" class="pilcrow">¶</a></p>
+<p id="section-11.8-2">The registry has been created to use the "Expert Review" registration procedure <span>[<a href="#RFC8126" class="cite xref">RFC8126</a>]</span>. Expert review guidelines are provided in <a href="#review" class="auto internal xref">Section 11.14</a>. Values in this registry are covered by different registration policies as indicated. It should be noted that, in addition to the expert review, some portions of the registry require a specification, potentially a Standards Track RFC, to be supplied as well.<a href="#section-11.8-2" class="pilcrow">¶</a></p>
 <p id="section-11.8-3">The columns of this registry are:<a href="#section-11.8-3" class="pilcrow">¶</a></p>
 <ul class="normal">
 <li class="normal" id="section-11.8-4.1">
-            <p id="section-11.8-4.1.1">Name: The name of the application profile, to be used as value of the profile attribute.<a href="#section-11.8-4.1.1" class="pilcrow">¶</a></p>
+            <p id="section-11.8-4.1.1">Name: This is a descriptive name that enables easier reference to
+the item. The name MUST be unique. It is not used in the encoding.<a href="#section-11.8-4.1.1" class="pilcrow">¶</a></p>
 </li>
           <li class="normal" id="section-11.8-4.2">
-            <p id="section-11.8-4.2.1">Description: Text giving an overview of the application profile and the context it is developed for.<a href="#section-11.8-4.2.1" class="pilcrow">¶</a></p>
+            <p id="section-11.8-4.2.1">Key Type Value: This is the value used to identify the keying material. These values MUST be unique. The value can be a positive integer, a negative integer, or a text string. Different ranges of values use different registration policies <span>[<a href="#RFC8126" class="cite xref">RFC8126</a>]</span>. Integer values from -256 to 255 as well as text strings of length 1 are designated as "Standards Action With Expert Review". Integer values from -65536 to -257 and from 256 to 65535, as well as text strings of length 2 are designated as "Specification Required". Integer values greater than 65535 as well as text strings of length greater than 2 are designated as "Expert Review". Integer values less than -65536 are marked as "Private Use".<a href="#section-11.8-4.2.1" class="pilcrow">¶</a></p>
 </li>
           <li class="normal" id="section-11.8-4.3">
-            <p id="section-11.8-4.3.1">CBOR Value: CBOR abbreviation for the name of this application profile. These values MUST be unique. The value can be a positive integer or a negative integer. Different ranges of values use different registration policies <span>[<a href="#RFC8126" class="cite xref">RFC8126</a>]</span>. Integer values from -256 to 255 are designated as "Standards Action With Expert Review". Integer values from -65536 to -257 and from 256 to 65535 are designated as "Specification Required". Integer values greater than 65535 are designated as "Expert Review". Integer values less than -65536 are marked as "Private Use".<a href="#section-11.8-4.3.1" class="pilcrow">¶</a></p>
+            <p id="section-11.8-4.3.1">Profile: This field may contain one or more descriptive strings of application profiles to be used with this item. The values should be taken from the Name column of the "ACE Groupcomm Profiles" registry.<a href="#section-11.8-4.3.1" class="pilcrow">¶</a></p>
 </li>
           <li class="normal" id="section-11.8-4.4">
-            <p id="section-11.8-4.4.1">Reference: This contains a pointer to the public specification of the abbreviation for this application profile, if one exists.<a href="#section-11.8-4.4.1" class="pilcrow">¶</a></p>
+            <p id="section-11.8-4.4.1">Description: This field contains a brief description of the keying material.<a href="#section-11.8-4.4.1" class="pilcrow">¶</a></p>
+</li>
+          <li class="normal" id="section-11.8-4.5">
+            <p id="section-11.8-4.5.1">Reference: This contains a pointer to the public specification for the format of the keying material, if one exists.<a href="#section-11.8-4.5.1" class="pilcrow">¶</a></p>
 </li>
         </ul>
-<p id="section-11.8-5">This registry has been initially populated with the value in <a href="#ace-groupcomm-profile-0" class="auto internal xref">Figure 11</a>.<a href="#section-11.8-5" class="pilcrow">¶</a></p>
+<p id="section-11.8-5">This registry has been initially populated with the value in <a href="#fig-gkty" class="auto internal xref">Figure 11</a>.<a href="#section-11.8-5" class="pilcrow">¶</a></p>
 </section>
 </div>
-<div id="ace-groupcomm-policies">
+<div id="ace-groupcomm-profiles">
 <section id="section-11.9">
-        <h3 id="name-ace-groupcomm-policies-2">
-<a href="#section-11.9" class="section-number selfRef">11.9. </a><a href="#name-ace-groupcomm-policies-2" class="section-name selfRef">ACE Groupcomm Policies</a>
+        <h3 id="name-ace-groupcomm-profiles-2">
+<a href="#section-11.9" class="section-number selfRef">11.9. </a><a href="#name-ace-groupcomm-profiles-2" class="section-name selfRef">ACE Groupcomm Profiles</a>
         </h3>
-<p id="section-11.9-1">This specification establishes the "ACE Groupcomm Policies" IANA registry within the "Authentication and Authorization for Constrained Environments (ACE)" registry group.<a href="#section-11.9-1" class="pilcrow">¶</a></p>
-<p id="section-11.9-2">The registry has been created to use the "Expert Review" registration procedure <span>[<a href="#RFC8126" class="cite xref">RFC8126</a>]</span>. Expert review guidelines are provided in <a href="#review" class="auto internal xref">Section 11.13</a>. Values in this registry are covered by different registration policies as indicated. It should be noted that, in addition to the expert review, some portions of the registry require a specification, potentially a Standards Track RFC, to be supplied as well.<a href="#section-11.9-2" class="pilcrow">¶</a></p>
+<p id="section-11.9-1">This specification establishes the "ACE Groupcomm Profiles" IANA registry within the "Authentication and Authorization for Constrained Environments (ACE)" registry group.<a href="#section-11.9-1" class="pilcrow">¶</a></p>
+<p id="section-11.9-2">The registry has been created to use the "Expert Review" registration procedure <span>[<a href="#RFC8126" class="cite xref">RFC8126</a>]</span>. Expert review guidelines are provided in <a href="#review" class="auto internal xref">Section 11.14</a>. Values in this registry are covered by different registration policies as indicated. It should be noted that, in addition to the expert review, some portions of the registry require a specification, potentially a Standards Track RFC, to be supplied as well.<a href="#section-11.9-2" class="pilcrow">¶</a></p>
 <p id="section-11.9-3">The columns of this registry are:<a href="#section-11.9-3" class="pilcrow">¶</a></p>
 <ul class="normal">
 <li class="normal" id="section-11.9-4.1">
-            <p id="section-11.9-4.1.1">Name: The name of the group communication policy.<a href="#section-11.9-4.1.1" class="pilcrow">¶</a></p>
+            <p id="section-11.9-4.1.1">Name: The name of the application profile, to be used as value of the profile attribute.<a href="#section-11.9-4.1.1" class="pilcrow">¶</a></p>
 </li>
           <li class="normal" id="section-11.9-4.2">
-            <p id="section-11.9-4.2.1">CBOR label: The value to be used to identify this group communication policy. These values MUST be unique. The value can be a positive integer, a negative integer, or a text string. Different ranges of values use different registration policies <span>[<a href="#RFC8126" class="cite xref">RFC8126</a>]</span>. Integer values from -256 to 255 as well as text strings of length 1 are designated as "Standards Action With Expert Review". Integer values from -65536 to -257 and from 256 to 65535, as well as text strings of length 2 are designated as "Specification Required". Integer values greater than 65535 as well as text strings of length greater than 2 are designated as "Expert Review". Integer values less than -65536 are marked as "Private Use".<a href="#section-11.9-4.2.1" class="pilcrow">¶</a></p>
+            <p id="section-11.9-4.2.1">Description: Text giving an overview of the application profile and the context it is developed for.<a href="#section-11.9-4.2.1" class="pilcrow">¶</a></p>
 </li>
           <li class="normal" id="section-11.9-4.3">
-            <p id="section-11.9-4.3.1">CBOR type: the CBOR type used to encode the value of this group communication policy.<a href="#section-11.9-4.3.1" class="pilcrow">¶</a></p>
+            <p id="section-11.9-4.3.1">CBOR Value: CBOR abbreviation for the name of this application profile. These values MUST be unique. The value can be a positive integer or a negative integer. Different ranges of values use different registration policies <span>[<a href="#RFC8126" class="cite xref">RFC8126</a>]</span>. Integer values from -256 to 255 are designated as "Standards Action With Expert Review". Integer values from -65536 to -257 and from 256 to 65535 are designated as "Specification Required". Integer values greater than 65535 are designated as "Expert Review". Integer values less than -65536 are marked as "Private Use".<a href="#section-11.9-4.3.1" class="pilcrow">¶</a></p>
 </li>
           <li class="normal" id="section-11.9-4.4">
-            <p id="section-11.9-4.4.1">Description: This field contains a brief description for this group communication policy.<a href="#section-11.9-4.4.1" class="pilcrow">¶</a></p>
-</li>
-          <li class="normal" id="section-11.9-4.5">
-            <p id="section-11.9-4.5.1">Reference: This field contains a pointer to the public specification providing the format of the group communication policy, if one exists.<a href="#section-11.9-4.5.1" class="pilcrow">¶</a></p>
+            <p id="section-11.9-4.4.1">Reference: This contains a pointer to the public specification of the abbreviation for this application profile, if one exists.<a href="#section-11.9-4.4.1" class="pilcrow">¶</a></p>
 </li>
         </ul>
-<p id="section-11.9-5">This registry has been initially populated with the values in <a href="#fig-ACE-Groupcomm-Policies" class="auto internal xref">Figure 12</a>.<a href="#section-11.9-5" class="pilcrow">¶</a></p>
+<p id="section-11.9-5">This registry has been initially populated with the value in <a href="#ace-groupcomm-profile-0" class="auto internal xref">Figure 12</a>.<a href="#section-11.9-5" class="pilcrow">¶</a></p>
 </section>
 </div>
-<div id="sequence-number-synchronization-methods">
+<div id="ace-groupcomm-policies">
 <section id="section-11.10">
-        <h3 id="name-sequence-number-synchroniza">
-<a href="#section-11.10" class="section-number selfRef">11.10. </a><a href="#name-sequence-number-synchroniza" class="section-name selfRef">Sequence Number Synchronization Methods</a>
+        <h3 id="name-ace-groupcomm-policies-2">
+<a href="#section-11.10" class="section-number selfRef">11.10. </a><a href="#name-ace-groupcomm-policies-2" class="section-name selfRef">ACE Groupcomm Policies</a>
         </h3>
-<p id="section-11.10-1">This specification establishes the "Sequence Number Synchronization Methods" IANA registry within the "Authentication and Authorization for Constrained Environments (ACE)" registry group.<a href="#section-11.10-1" class="pilcrow">¶</a></p>
-<p id="section-11.10-2">The registry has been created to use the "Expert Review" registration procedure <span>[<a href="#RFC8126" class="cite xref">RFC8126</a>]</span>. Expert review guidelines are provided in <a href="#review" class="auto internal xref">Section 11.13</a>. Values in this registry are covered by different registration policies as indicated. It should be noted that, in addition to the expert review, some portions of the registry require a specification, potentially a Standards Track RFC, to be supplied as well.<a href="#section-11.10-2" class="pilcrow">¶</a></p>
+<p id="section-11.10-1">This specification establishes the "ACE Groupcomm Policies" IANA registry within the "Authentication and Authorization for Constrained Environments (ACE)" registry group.<a href="#section-11.10-1" class="pilcrow">¶</a></p>
+<p id="section-11.10-2">The registry has been created to use the "Expert Review" registration procedure <span>[<a href="#RFC8126" class="cite xref">RFC8126</a>]</span>. Expert review guidelines are provided in <a href="#review" class="auto internal xref">Section 11.14</a>. Values in this registry are covered by different registration policies as indicated. It should be noted that, in addition to the expert review, some portions of the registry require a specification, potentially a Standards Track RFC, to be supplied as well.<a href="#section-11.10-2" class="pilcrow">¶</a></p>
 <p id="section-11.10-3">The columns of this registry are:<a href="#section-11.10-3" class="pilcrow">¶</a></p>
 <ul class="normal">
 <li class="normal" id="section-11.10-4.1">
-            <p id="section-11.10-4.1.1">Name: The name of the sequence number synchronization method.<a href="#section-11.10-4.1.1" class="pilcrow">¶</a></p>
+            <p id="section-11.10-4.1.1">Name: The name of the group communication policy.<a href="#section-11.10-4.1.1" class="pilcrow">¶</a></p>
 </li>
           <li class="normal" id="section-11.10-4.2">
-            <p id="section-11.10-4.2.1">Value: The value to be used to identify this sequence number synchronization method. These values MUST be unique. The value can be a positive integer, a negative integer, or a text string. Different ranges of values use different registration policies <span>[<a href="#RFC8126" class="cite xref">RFC8126</a>]</span>. Integer values from -256 to 255 as well as text strings of length 1 are designated as "Standards Action With Expert Review". Integer values from -65536 to -257 and from 256 to 65535, as well as text strings of length 2 are designated as "Specification Required". Integer values greater than 65535 as well as text strings of length greater than 2 are designated as "Expert Review". Integer values less than -65536 are marked as "Private Use".<a href="#section-11.10-4.2.1" class="pilcrow">¶</a></p>
+            <p id="section-11.10-4.2.1">CBOR label: The value to be used to identify this group communication policy. These values MUST be unique. The value can be a positive integer, a negative integer, or a text string. Different ranges of values use different registration policies <span>[<a href="#RFC8126" class="cite xref">RFC8126</a>]</span>. Integer values from -256 to 255 as well as text strings of length 1 are designated as "Standards Action With Expert Review". Integer values from -65536 to -257 and from 256 to 65535, as well as text strings of length 2 are designated as "Specification Required". Integer values greater than 65535 as well as text strings of length greater than 2 are designated as "Expert Review". Integer values less than -65536 are marked as "Private Use".<a href="#section-11.10-4.2.1" class="pilcrow">¶</a></p>
 </li>
           <li class="normal" id="section-11.10-4.3">
-            <p id="section-11.10-4.3.1">Description: This field contains a brief description for this sequence number synchronization method.<a href="#section-11.10-4.3.1" class="pilcrow">¶</a></p>
+            <p id="section-11.10-4.3.1">CBOR type: the CBOR type used to encode the value of this group communication policy.<a href="#section-11.10-4.3.1" class="pilcrow">¶</a></p>
 </li>
           <li class="normal" id="section-11.10-4.4">
-            <p id="section-11.10-4.4.1">Reference: This field contains a pointer to the public specification describing the sequence number synchronization method.<a href="#section-11.10-4.4.1" class="pilcrow">¶</a></p>
+            <p id="section-11.10-4.4.1">Description: This field contains a brief description for this group communication policy.<a href="#section-11.10-4.4.1" class="pilcrow">¶</a></p>
+</li>
+          <li class="normal" id="section-11.10-4.5">
+            <p id="section-11.10-4.5.1">Reference: This field contains a pointer to the public specification providing the format of the group communication policy, if one exists.<a href="#section-11.10-4.5.1" class="pilcrow">¶</a></p>
 </li>
         </ul>
+<p id="section-11.10-5">This registry has been initially populated with the values in <a href="#fig-ACE-Groupcomm-Policies" class="auto internal xref">Figure 13</a>.<a href="#section-11.10-5" class="pilcrow">¶</a></p>
 </section>
 </div>
-<div id="iana-ace-groupcomm-errors">
+<div id="sequence-number-synchronization-methods">
 <section id="section-11.11">
-        <h3 id="name-ace-groupcomm-errors">
-<a href="#section-11.11" class="section-number selfRef">11.11. </a><a href="#name-ace-groupcomm-errors" class="section-name selfRef">ACE Groupcomm Errors</a>
+        <h3 id="name-sequence-number-synchroniza">
+<a href="#section-11.11" class="section-number selfRef">11.11. </a><a href="#name-sequence-number-synchroniza" class="section-name selfRef">Sequence Number Synchronization Methods</a>
         </h3>
-<p id="section-11.11-1">This specification establishes the "ACE Groupcomm Errors" IANA registry within the "Authentication and Authorization for Constrained Environments (ACE)" registry group.<a href="#section-11.11-1" class="pilcrow">¶</a></p>
-<p id="section-11.11-2">The registry has been created to use the "Expert Review" registration procedure <span>[<a href="#RFC8126" class="cite xref">RFC8126</a>]</span>. Expert review guidelines are provided in <a href="#review" class="auto internal xref">Section 11.13</a>. Values in this registry are covered by different registration policies as indicated. It should be noted that, in addition to the expert review, some portions of the registry require a specification, potentially a Standards Track RFC, to be supplied as well.<a href="#section-11.11-2" class="pilcrow">¶</a></p>
+<p id="section-11.11-1">This specification establishes the "Sequence Number Synchronization Methods" IANA registry within the "Authentication and Authorization for Constrained Environments (ACE)" registry group.<a href="#section-11.11-1" class="pilcrow">¶</a></p>
+<p id="section-11.11-2">The registry has been created to use the "Expert Review" registration procedure <span>[<a href="#RFC8126" class="cite xref">RFC8126</a>]</span>. Expert review guidelines are provided in <a href="#review" class="auto internal xref">Section 11.14</a>. Values in this registry are covered by different registration policies as indicated. It should be noted that, in addition to the expert review, some portions of the registry require a specification, potentially a Standards Track RFC, to be supplied as well.<a href="#section-11.11-2" class="pilcrow">¶</a></p>
 <p id="section-11.11-3">The columns of this registry are:<a href="#section-11.11-3" class="pilcrow">¶</a></p>
 <ul class="normal">
 <li class="normal" id="section-11.11-4.1">
-            <p id="section-11.11-4.1.1">Value: The value to be used to identify the error. These values MUST be unique. The value can be a positive integer or a negative integer. Different ranges of values use different registration policies <span>[<a href="#RFC8126" class="cite xref">RFC8126</a>]</span>. Integer values from -256 to 255 are designated as "Standards Action With Expert Review". Integer values from -65536 to -257 and from 256 to 65535 are designated as "Specification Required". Integer values greater than 65535 are designated as "Expert Review". Integer values less than -65536 are marked as "Private Use".<a href="#section-11.11-4.1.1" class="pilcrow">¶</a></p>
+            <p id="section-11.11-4.1.1">Name: The name of the sequence number synchronization method.<a href="#section-11.11-4.1.1" class="pilcrow">¶</a></p>
 </li>
           <li class="normal" id="section-11.11-4.2">
-            <p id="section-11.11-4.2.1">Description: This field contains a brief description of the error.<a href="#section-11.11-4.2.1" class="pilcrow">¶</a></p>
+            <p id="section-11.11-4.2.1">Value: The value to be used to identify this sequence number synchronization method. These values MUST be unique. The value can be a positive integer, a negative integer, or a text string. Different ranges of values use different registration policies <span>[<a href="#RFC8126" class="cite xref">RFC8126</a>]</span>. Integer values from -256 to 255 as well as text strings of length 1 are designated as "Standards Action With Expert Review". Integer values from -65536 to -257 and from 256 to 65535, as well as text strings of length 2 are designated as "Specification Required". Integer values greater than 65535 as well as text strings of length greater than 2 are designated as "Expert Review". Integer values less than -65536 are marked as "Private Use".<a href="#section-11.11-4.2.1" class="pilcrow">¶</a></p>
 </li>
           <li class="normal" id="section-11.11-4.3">
-            <p id="section-11.11-4.3.1">Reference: This field contains a pointer to the public specification defining the error, if one exists.<a href="#section-11.11-4.3.1" class="pilcrow">¶</a></p>
+            <p id="section-11.11-4.3.1">Description: This field contains a brief description for this sequence number synchronization method.<a href="#section-11.11-4.3.1" class="pilcrow">¶</a></p>
+</li>
+          <li class="normal" id="section-11.11-4.4">
+            <p id="section-11.11-4.4.1">Reference: This field contains a pointer to the public specification describing the sequence number synchronization method.<a href="#section-11.11-4.4.1" class="pilcrow">¶</a></p>
 </li>
         </ul>
-<p id="section-11.11-5">This registry has been initially populated with the values in <a href="#fig-ACE-Groupcomm-Error-Identifiers" class="auto internal xref">Figure 40</a>. The Reference column for all of these entries refers to this document.<a href="#section-11.11-5" class="pilcrow">¶</a></p>
 </section>
 </div>
-<div id="iana-ace-groupcomm-rekeying-schemes">
+<div id="iana-ace-groupcomm-errors">
 <section id="section-11.12">
-        <h3 id="name-ace-groupcomm-rekeying-schem">
-<a href="#section-11.12" class="section-number selfRef">11.12. </a><a href="#name-ace-groupcomm-rekeying-schem" class="section-name selfRef">ACE Groupcomm Rekeying Schemes</a>
+        <h3 id="name-ace-groupcomm-errors">
+<a href="#section-11.12" class="section-number selfRef">11.12. </a><a href="#name-ace-groupcomm-errors" class="section-name selfRef">ACE Groupcomm Errors</a>
         </h3>
-<p id="section-11.12-1">This specification establishes the "ACE Groupcomm Rekeying Schemes" IANA registry within the "Authentication and Authorization for Constrained Environments (ACE)" registry group.<a href="#section-11.12-1" class="pilcrow">¶</a></p>
-<p id="section-11.12-2">The registry has been created to use the "Expert Review" registration procedure <span>[<a href="#RFC8126" class="cite xref">RFC8126</a>]</span>. Expert review guidelines are provided in <a href="#review" class="auto internal xref">Section 11.13</a>. Values in this registry are covered by different registration policies as indicated. It should be noted that, in addition to the expert review, some portions of the registry require a specification, potentially a Standards Track RFC, to be supplied as well.<a href="#section-11.12-2" class="pilcrow">¶</a></p>
+<p id="section-11.12-1">This specification establishes the "ACE Groupcomm Errors" IANA registry within the "Authentication and Authorization for Constrained Environments (ACE)" registry group.<a href="#section-11.12-1" class="pilcrow">¶</a></p>
+<p id="section-11.12-2">The registry has been created to use the "Expert Review" registration procedure <span>[<a href="#RFC8126" class="cite xref">RFC8126</a>]</span>. Expert review guidelines are provided in <a href="#review" class="auto internal xref">Section 11.14</a>. Values in this registry are covered by different registration policies as indicated. It should be noted that, in addition to the expert review, some portions of the registry require a specification, potentially a Standards Track RFC, to be supplied as well.<a href="#section-11.12-2" class="pilcrow">¶</a></p>
 <p id="section-11.12-3">The columns of this registry are:<a href="#section-11.12-3" class="pilcrow">¶</a></p>
 <ul class="normal">
 <li class="normal" id="section-11.12-4.1">
-            <p id="section-11.12-4.1.1">Value: The value to be used to identify the group rekeying scheme. These values MUST be unique. The value can be a positive integer or a negative integer. Different ranges of values use different registration policies <span>[<a href="#RFC8126" class="cite xref">RFC8126</a>]</span>. Integer values from -256 to 255 are designated as "Standards Action With Expert Review". Integer values from -65536 to -257 and from 256 to 65535 are designated as "Specification Required". Integer values greater than 65535 are designated as "Expert Review". Integer values less than -65536 are marked as "Private Use".<a href="#section-11.12-4.1.1" class="pilcrow">¶</a></p>
+            <p id="section-11.12-4.1.1">Value: The value to be used to identify the error. These values MUST be unique. The value can be a positive integer or a negative integer. Different ranges of values use different registration policies <span>[<a href="#RFC8126" class="cite xref">RFC8126</a>]</span>. Integer values from -256 to 255 are designated as "Standards Action With Expert Review". Integer values from -65536 to -257 and from 256 to 65535 are designated as "Specification Required". Integer values greater than 65535 are designated as "Expert Review". Integer values less than -65536 are marked as "Private Use".<a href="#section-11.12-4.1.1" class="pilcrow">¶</a></p>
 </li>
           <li class="normal" id="section-11.12-4.2">
-            <p id="section-11.12-4.2.1">Name: The name of the group rekeying scheme.<a href="#section-11.12-4.2.1" class="pilcrow">¶</a></p>
+            <p id="section-11.12-4.2.1">Description: This field contains a brief description of the error.<a href="#section-11.12-4.2.1" class="pilcrow">¶</a></p>
 </li>
           <li class="normal" id="section-11.12-4.3">
-            <p id="section-11.12-4.3.1">Description: This field contains a brief description of the group rekeying scheme.<a href="#section-11.12-4.3.1" class="pilcrow">¶</a></p>
+            <p id="section-11.12-4.3.1">Reference: This field contains a pointer to the public specification defining the error, if one exists.<a href="#section-11.12-4.3.1" class="pilcrow">¶</a></p>
 </li>
-          <li class="normal" id="section-11.12-4.4">
-            <p id="section-11.12-4.4.1">Reference: This field contains a pointer to the public specification defining the group rekeying scheme, if one exists.<a href="#section-11.12-4.4.1" class="pilcrow">¶</a></p>
+        </ul>
+<p id="section-11.12-5">This registry has been initially populated with the values in <a href="#fig-ACE-Groupcomm-Error-Identifiers" class="auto internal xref">Figure 43</a>. The Reference column for all of these entries refers to this document.<a href="#section-11.12-5" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="iana-ace-groupcomm-rekeying-schemes">
+<section id="section-11.13">
+        <h3 id="name-ace-groupcomm-rekeying-schem">
+<a href="#section-11.13" class="section-number selfRef">11.13. </a><a href="#name-ace-groupcomm-rekeying-schem" class="section-name selfRef">ACE Groupcomm Rekeying Schemes</a>
+        </h3>
+<p id="section-11.13-1">This specification establishes the "ACE Groupcomm Rekeying Schemes" IANA registry within the "Authentication and Authorization for Constrained Environments (ACE)" registry group.<a href="#section-11.13-1" class="pilcrow">¶</a></p>
+<p id="section-11.13-2">The registry has been created to use the "Expert Review" registration procedure <span>[<a href="#RFC8126" class="cite xref">RFC8126</a>]</span>. Expert review guidelines are provided in <a href="#review" class="auto internal xref">Section 11.14</a>. Values in this registry are covered by different registration policies as indicated. It should be noted that, in addition to the expert review, some portions of the registry require a specification, potentially a Standards Track RFC, to be supplied as well.<a href="#section-11.13-2" class="pilcrow">¶</a></p>
+<p id="section-11.13-3">The columns of this registry are:<a href="#section-11.13-3" class="pilcrow">¶</a></p>
+<ul class="normal">
+<li class="normal" id="section-11.13-4.1">
+            <p id="section-11.13-4.1.1">Value: The value to be used to identify the group rekeying scheme. These values MUST be unique. The value can be a positive integer or a negative integer. Different ranges of values use different registration policies <span>[<a href="#RFC8126" class="cite xref">RFC8126</a>]</span>. Integer values from -256 to 255 are designated as "Standards Action With Expert Review". Integer values from -65536 to -257 and from 256 to 65535 are designated as "Specification Required". Integer values greater than 65535 are designated as "Expert Review". Integer values less than -65536 are marked as "Private Use".<a href="#section-11.13-4.1.1" class="pilcrow">¶</a></p>
+</li>
+          <li class="normal" id="section-11.13-4.2">
+            <p id="section-11.13-4.2.1">Name: The name of the group rekeying scheme.<a href="#section-11.13-4.2.1" class="pilcrow">¶</a></p>
+</li>
+          <li class="normal" id="section-11.13-4.3">
+            <p id="section-11.13-4.3.1">Description: This field contains a brief description of the group rekeying scheme.<a href="#section-11.13-4.3.1" class="pilcrow">¶</a></p>
+</li>
+          <li class="normal" id="section-11.13-4.4">
+            <p id="section-11.13-4.4.1">Reference: This field contains a pointer to the public specification defining the group rekeying scheme, if one exists.<a href="#section-11.13-4.4.1" class="pilcrow">¶</a></p>
 </li>
         </ul>
-<p id="section-11.12-5">This registry has been initially populated with the value in <a href="#rekeying-scheme-0" class="auto internal xref">Figure 13</a>.<a href="#section-11.12-5" class="pilcrow">¶</a></p>
+<p id="section-11.13-5">This registry has been initially populated with the value in <a href="#rekeying-scheme-0" class="auto internal xref">Figure 14</a>.<a href="#section-11.13-5" class="pilcrow">¶</a></p>
 </section>
 </div>
 <div id="review">
-<section id="section-11.13">
+<section id="section-11.14">
         <h3 id="name-expert-review-instructions">
-<a href="#section-11.13" class="section-number selfRef">11.13. </a><a href="#name-expert-review-instructions" class="section-name selfRef">Expert Review Instructions</a>
+<a href="#section-11.14" class="section-number selfRef">11.14. </a><a href="#name-expert-review-instructions" class="section-name selfRef">Expert Review Instructions</a>
         </h3>
-<p id="section-11.13-1">The IANA Registries established in this document are defined as expert review.
-This section gives some general guidelines for what the experts should be looking for, but they are being designated as experts for a reason so they should be given substantial latitude.<a href="#section-11.13-1" class="pilcrow">¶</a></p>
-<p id="section-11.13-2">Expert reviewers should take into consideration the following points:<a href="#section-11.13-2" class="pilcrow">¶</a></p>
+<p id="section-11.14-1">The IANA Registries established in this document are defined as expert review.
+This section gives some general guidelines for what the experts should be looking for, but they are being designated as experts for a reason so they should be given substantial latitude.<a href="#section-11.14-1" class="pilcrow">¶</a></p>
+<p id="section-11.14-2">Expert reviewers should take into consideration the following points:<a href="#section-11.14-2" class="pilcrow">¶</a></p>
 <ul class="normal">
-<li class="normal" id="section-11.13-3.1">
-            <p id="section-11.13-3.1.1">Point squatting should be discouraged. Reviewers are encouraged to get sufficient information for registration requests to ensure that the usage is not going to duplicate one that is already registered and that the point is likely to be used in deployments. The zones tagged as private use are intended for testing purposes and closed environments, code points in other ranges should not be assigned for testing.<a href="#section-11.13-3.1.1" class="pilcrow">¶</a></p>
+<li class="normal" id="section-11.14-3.1">
+            <p id="section-11.14-3.1.1">Point squatting should be discouraged. Reviewers are encouraged to get sufficient information for registration requests to ensure that the usage is not going to duplicate one that is already registered and that the point is likely to be used in deployments. The zones tagged as private use are intended for testing purposes and closed environments, code points in other ranges should not be assigned for testing.<a href="#section-11.14-3.1.1" class="pilcrow">¶</a></p>
 </li>
-          <li class="normal" id="section-11.13-3.2">
-            <p id="section-11.13-3.2.1">Specifications are required for the standards track range of point assignment. Specifications should exist for specification required ranges, but early assignment before a specification is available is considered to be permissible. When specifications are not provided, the description provided needs to have sufficient information to identify what the point is being used for.<a href="#section-11.13-3.2.1" class="pilcrow">¶</a></p>
+          <li class="normal" id="section-11.14-3.2">
+            <p id="section-11.14-3.2.1">Specifications are required for the standards track range of point assignment. Specifications should exist for specification required ranges, but early assignment before a specification is available is considered to be permissible. When specifications are not provided, the description provided needs to have sufficient information to identify what the point is being used for.<a href="#section-11.14-3.2.1" class="pilcrow">¶</a></p>
 </li>
-          <li class="normal" id="section-11.13-3.3">
-            <p id="section-11.13-3.3.1">Experts should take into account the expected usage of fields when approving point assignments. The fact that there is a range for Standards Track documents does not mean that a Standards Track document cannot have points assigned outside of that range. The length of the encoded value should be weighed against how many code points of that length are left, the size of device it will be used on, and the number of code points left that encode to that size.<a href="#section-11.13-3.3.1" class="pilcrow">¶</a></p>
+          <li class="normal" id="section-11.14-3.3">
+            <p id="section-11.14-3.3.1">Experts should take into account the expected usage of fields when approving point assignments. The fact that there is a range for Standards Track documents does not mean that a Standards Track document cannot have points assigned outside of that range. The length of the encoded value should be weighed against how many code points of that length are left, the size of device it will be used on, and the number of code points left that encode to that size.<a href="#section-11.14-3.3.1" class="pilcrow">¶</a></p>
 </li>
         </ul>
 </section>
@@ -4458,6 +4810,10 @@ <h3 id="name-normative-references">
         <dd>
 <span class="refAuthor">Bradner, S.</span>, <span class="refTitle">"Key words for use in RFCs to Indicate Requirement Levels"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 2119</span>, <span class="seriesInfo">DOI 10.17487/RFC2119</span>, <time datetime="1997-03" class="refDate">March 1997</time>, <span>&lt;<a href="https://www.rfc-editor.org/rfc/rfc2119">https://www.rfc-editor.org/rfc/rfc2119</a>&gt;</span>. </dd>
 <dd class="break"></dd>
+<dt id="RFC6690">[RFC6690]</dt>
+        <dd>
+<span class="refAuthor">Shelby, Z.</span>, <span class="refTitle">"Constrained RESTful Environments (CoRE) Link Format"</span>, <span class="seriesInfo">RFC 6690</span>, <span class="seriesInfo">DOI 10.17487/RFC6690</span>, <time datetime="2012-08" class="refDate">August 2012</time>, <span>&lt;<a href="https://www.rfc-editor.org/rfc/rfc6690">https://www.rfc-editor.org/rfc/rfc6690</a>&gt;</span>. </dd>
+<dd class="break"></dd>
 <dt id="RFC6749">[RFC6749]</dt>
         <dd>
 <span class="refAuthor">Hardt, D., Ed.</span>, <span class="refTitle">"The OAuth 2.0 Authorization Framework"</span>, <span class="seriesInfo">RFC 6749</span>, <span class="seriesInfo">DOI 10.17487/RFC6749</span>, <time datetime="2012-10" class="refDate">October 2012</time>, <span>&lt;<a href="https://www.rfc-editor.org/rfc/rfc6749">https://www.rfc-editor.org/rfc/rfc6749</a>&gt;</span>. </dd>
@@ -4510,6 +4866,10 @@ <h3 id="name-normative-references">
         <dd>
 <span class="refAuthor">Bormann, C.</span>, <span class="refTitle">"An Authorization Information Format (AIF) for Authentication and Authorization for Constrained Environments (ACE)"</span>, <span class="seriesInfo">RFC 9237</span>, <span class="seriesInfo">DOI 10.17487/RFC9237</span>, <time datetime="2022-08" class="refDate">August 2022</time>, <span>&lt;<a href="https://www.rfc-editor.org/rfc/rfc9237">https://www.rfc-editor.org/rfc/rfc9237</a>&gt;</span>. </dd>
 <dd class="break"></dd>
+<dt id="RFC9290">[RFC9290]</dt>
+        <dd>
+<span class="refAuthor">Fossati, T.</span> and <span class="refAuthor">C. Bormann</span>, <span class="refTitle">"Concise Problem Details for Constrained Application Protocol (CoAP) APIs"</span>, <span class="seriesInfo">RFC 9290</span>, <span class="seriesInfo">DOI 10.17487/RFC9290</span>, <time datetime="2022-10" class="refDate">October 2022</time>, <span>&lt;<a href="https://www.rfc-editor.org/rfc/rfc9290">https://www.rfc-editor.org/rfc/rfc9290</a>&gt;</span>. </dd>
+<dd class="break"></dd>
 <dt id="RFC9338">[RFC9338]</dt>
       <dd>
 <span class="refAuthor">Schaad, J.</span>, <span class="refTitle">"CBOR Object Signing and Encryption (COSE): Countersignatures"</span>, <span class="seriesInfo">STD 96</span>, <span class="seriesInfo">RFC 9338</span>, <span class="seriesInfo">DOI 10.17487/RFC9338</span>, <time datetime="2022-12" class="refDate">December 2022</time>, <span>&lt;<a href="https://www.rfc-editor.org/rfc/rfc9338">https://www.rfc-editor.org/rfc/rfc9338</a>&gt;</span>. </dd>
@@ -4605,7 +4965,7 @@ <h2 id="name-requirements-on-application">
 <a href="#appendix-A" class="section-number selfRef">Appendix A. </a><a href="#name-requirements-on-application" class="section-name selfRef">Requirements on Application Profiles</a>
       </h2>
 <p id="appendix-A-1">This section lists the requirements on application profiles of this specification, for the convenience of application profile designers.<a href="#appendix-A-1" class="pilcrow">¶</a></p>
-<div id="mandatory-to-address-requirements">
+<div id="req-mandatory">
 <section id="appendix-A.1">
         <h3 id="name-mandatory-to-address-requir">
 <a href="#appendix-A.1" class="section-number selfRef">A.1. </a><a href="#name-mandatory-to-address-requir" class="section-name selfRef">Mandatory-to-Address Requirements</a>
@@ -4684,7 +5044,7 @@ <h3 id="name-mandatory-to-address-requir">
             <p id="appendix-A.1-1.24.1">REQ24: Specify how the communication is secured between Client and KDC. Optionally, specify transport profile of ACE <span>[<a href="#RFC9200" class="cite xref">RFC9200</a>]</span> to use between Client and KDC (see <a href="#ssec-key-distribution-exchange" class="auto internal xref">Section 4.3.1.1</a>).<a href="#appendix-A.1-1.24.1" class="pilcrow">¶</a></p>
 </li>
           <li class="normal" id="appendix-A.1-1.25">
-            <p id="appendix-A.1-1.25.1">REQ25: Specify the format of the identifiers of group members (see <a href="#gid-post" class="auto internal xref">Section 4.3.1</a>).<a href="#appendix-A.1-1.25.1" class="pilcrow">¶</a></p>
+            <p id="appendix-A.1-1.25.1">REQ25: Specify the format of the identifiers of group members (see <a href="#gid-post" class="auto internal xref">Section 4.3.1</a> and <a href="#pubkey-fetch" class="auto internal xref">Section 4.4.1</a>).<a href="#appendix-A.1-1.25.1" class="pilcrow">¶</a></p>
 </li>
           <li class="normal" id="appendix-A.1-1.26">
             <p id="appendix-A.1-1.26.1">REQ26: Specify policies at the KDC to handle ids that are not included in 'get_creds' (see <a href="#pubkey-fetch" class="auto internal xref">Section 4.4.1</a>).<a href="#appendix-A.1-1.26.1" class="pilcrow">¶</a></p>
@@ -4704,7 +5064,7 @@ <h3 id="name-mandatory-to-address-requir">
         </ul>
 </section>
 </div>
-<div id="optional-to-address-requirements">
+<div id="req-optional">
 <section id="appendix-A.2">
         <h3 id="name-optional-to-address-require">
 <a href="#appendix-A.2" class="section-number selfRef">A.2. </a><a href="#name-optional-to-address-require" class="section-name selfRef">Optional-to-Address Requirements</a>
@@ -4723,7 +5083,7 @@ <h3 id="name-optional-to-address-require">
             <p id="appendix-A.2-1.4.1">OPT4: Optionally, specify possible or required payload formats for specific error cases.<a href="#appendix-A.2-1.4.1" class="pilcrow">¶</a></p>
 </li>
           <li class="normal" id="appendix-A.2-1.5">
-            <p id="appendix-A.2-1.5.1">OPT5: Optionally, specify additional identifiers of error types, as values of the 'error' field in an error response from the KDC.<a href="#appendix-A.2-1.5.1" class="pilcrow">¶</a></p>
+            <p id="appendix-A.2-1.5.1">OPT5: Optionally, specify additional identifiers of error types, as values of the 'error-id' field within the Custom Problem Detail entry 'ace-groupcomm-error' (see <a href="#kdc-if-errors" class="auto internal xref">Section 4.1.2</a>).<a href="#appendix-A.2-1.5.1" class="pilcrow">¶</a></p>
 </li>
           <li class="normal" id="appendix-A.2-1.6">
             <p id="appendix-A.2-1.6.1">OPT6: Optionally, specify the encoding of 'creds_repo' if the default is not used (see <a href="#gid-post" class="auto internal xref">Section 4.3.1</a>).<a href="#appendix-A.2-1.6.1" class="pilcrow">¶</a></p>
@@ -4751,9 +5111,6 @@ <h3 id="name-optional-to-address-require">
 </li>
           <li class="normal" id="appendix-A.2-1.14">
             <p id="appendix-A.2-1.14.1">OPT14: Optionally, specify additional information to include in rekeying messages for the "Point-to-Point" group rekeying scheme (see <a href="#sec-group-rekeying" class="auto internal xref">Section 6</a>).<a href="#appendix-A.2-1.14.1" class="pilcrow">¶</a></p>
-</li>
-          <li class="normal" id="appendix-A.2-1.15">
-            <p id="appendix-A.2-1.15.1">OPT15: Optionally, specify if Clients must or should support any of the parameters defined as optional in this specification (see <a href="#params" class="auto internal xref">Section 8</a>).<a href="#appendix-A.2-1.15.1" class="pilcrow">¶</a></p>
 </li>
         </ul>
 </section>
@@ -4791,7 +5148,7 @@ <h3 id="name-format-of-sign_info_entry">
 </li>
         </ul>
 <span id="name-sign_info_entry-with-genera"></span><div id="fig-sign-info-entry-general">
-<figure id="figure-41">
+<figure id="figure-44">
           <div class="lang-CDDL sourcecode" id="appendix-B.1-3.1">
 <pre>
 sign_info_entry =
@@ -4806,7 +5163,7 @@ <h3 id="name-format-of-sign_info_entry">
 gname = tstr
 </pre>
 </div>
-<figcaption><a href="#figure-41" class="selfRef">Figure 41</a>:
+<figcaption><a href="#figure-44" class="selfRef">Figure 44</a>:
 <a href="#name-sign_info_entry-with-genera" class="selfRef">'sign_info_entry' with general format</a>
           </figcaption></figure>
 </div>
@@ -4827,16 +5184,70 @@ <h3 id="name-version-17-to-18">
         </h3>
 <ul class="normal">
 <li class="normal" id="appendix-C.1-1.1">
-            <p id="appendix-C.1-1.1.1">Consistent use of leading slash in URI paths.<a href="#appendix-C.1-1.1.1" class="pilcrow">¶</a></p>
+            <p id="appendix-C.1-1.1.1">Provided more details when early introducing "backward security" and "forward security".<a href="#appendix-C.1-1.1.1" class="pilcrow">¶</a></p>
 </li>
           <li class="normal" id="appendix-C.1-1.2">
-            <p id="appendix-C.1-1.2.1">Consistency fix: Clients always support the 'cnonce' parameter.<a href="#appendix-C.1-1.2.1" class="pilcrow">¶</a></p>
+            <p id="appendix-C.1-1.2.1">Clarified definition and semantics of "group name" and "node name".<a href="#appendix-C.1-1.2.1" class="pilcrow">¶</a></p>
 </li>
           <li class="normal" id="appendix-C.1-1.3">
-            <p id="appendix-C.1-1.3.1">The KDC might not have to store the 'cnonce' from a Join Request.<a href="#appendix-C.1-1.3.1" class="pilcrow">¶</a></p>
+            <p id="appendix-C.1-1.3.1">Clarified definition of "individual keying material".<a href="#appendix-C.1-1.3.1" class="pilcrow">¶</a></p>
 </li>
           <li class="normal" id="appendix-C.1-1.4">
-            <p id="appendix-C.1-1.4.1">Fixes and editorial improvements.<a href="#appendix-C.1-1.4.1" class="pilcrow">¶</a></p>
+            <p id="appendix-C.1-1.4.1">Clarified definition of "Dispatcher".<a href="#appendix-C.1-1.4.1" class="pilcrow">¶</a></p>
+</li>
+          <li class="normal" id="appendix-C.1-1.5">
+            <p id="appendix-C.1-1.5.1">Enforced consistent use of leading slash in URI paths.<a href="#appendix-C.1-1.5.1" class="pilcrow">¶</a></p>
+</li>
+          <li class="normal" id="appendix-C.1-1.6">
+            <p id="appendix-C.1-1.6.1">Fixed CDDL definitions and examples in CBOR diagnostic notation.<a href="#appendix-C.1-1.6.1" class="pilcrow">¶</a></p>
+</li>
+          <li class="normal" id="appendix-C.1-1.7">
+            <p id="appendix-C.1-1.7.1">RFC 9290 is used instead of the custom format for error responses.<a href="#appendix-C.1-1.7.1" class="pilcrow">¶</a></p>
+</li>
+          <li class="normal" id="appendix-C.1-1.8">
+            <p id="appendix-C.1-1.8.1">Clarified which operations are limited to group members and which are allowed also to non group members.<a href="#appendix-C.1-1.8.1" class="pilcrow">¶</a></p>
+</li>
+          <li class="normal" id="appendix-C.1-1.9">
+            <p id="appendix-C.1-1.9.1">Improved examples of message exchange.<a href="#appendix-C.1-1.9.1" class="pilcrow">¶</a></p>
+</li>
+          <li class="normal" id="appendix-C.1-1.10">
+            <p id="appendix-C.1-1.10.1">Added ASCII-art diagrams with examples of group rekeying.<a href="#appendix-C.1-1.10.1" class="pilcrow">¶</a></p>
+</li>
+          <li class="normal" id="appendix-C.1-1.11">
+            <p id="appendix-C.1-1.11.1">Clarified for how long nonces are stored at the KDC.<a href="#appendix-C.1-1.11.1" class="pilcrow">¶</a></p>
+</li>
+          <li class="normal" id="appendix-C.1-1.12">
+            <p id="appendix-C.1-1.12.1">Clarified that the KDC might not have to store the 'cnonce' from a Join Request.<a href="#appendix-C.1-1.12.1" class="pilcrow">¶</a></p>
+</li>
+          <li class="normal" id="appendix-C.1-1.13">
+            <p id="appendix-C.1-1.13.1">Consistency fix: Clients always support the 'cnonce' parameter.<a href="#appendix-C.1-1.13.1" class="pilcrow">¶</a></p>
+</li>
+          <li class="normal" id="appendix-C.1-1.14">
+            <p id="appendix-C.1-1.14.1">Added new parameter 'exi' providing the residual lifetime of the current group keying material.<a href="#appendix-C.1-1.14.1" class="pilcrow">¶</a></p>
+</li>
+          <li class="normal" id="appendix-C.1-1.15">
+            <p id="appendix-C.1-1.15.1">Clarified text about the KDC knowledge of compromised nodes.<a href="#appendix-C.1-1.15.1" class="pilcrow">¶</a></p>
+</li>
+          <li class="normal" id="appendix-C.1-1.16">
+            <p id="appendix-C.1-1.16.1">Clarified the impact on performance of a one-to-many group rekeying.<a href="#appendix-C.1-1.16.1" class="pilcrow">¶</a></p>
+</li>
+          <li class="normal" id="appendix-C.1-1.17">
+            <p id="appendix-C.1-1.17.1">Mentioned explicit exceptions to a group rekeying at each group membership change.<a href="#appendix-C.1-1.17.1" class="pilcrow">¶</a></p>
+</li>
+          <li class="normal" id="appendix-C.1-1.18">
+            <p id="appendix-C.1-1.18.1">Explained reasons for delaying a rekeying and halting communications.<a href="#appendix-C.1-1.18.1" class="pilcrow">¶</a></p>
+</li>
+          <li class="normal" id="appendix-C.1-1.19">
+            <p id="appendix-C.1-1.19.1">Fixes in current IANA registrations.<a href="#appendix-C.1-1.19.1" class="pilcrow">¶</a></p>
+</li>
+          <li class="normal" id="appendix-C.1-1.20">
+            <p id="appendix-C.1-1.20.1">Added integer abbreviation values for registrations in new IANA registries.<a href="#appendix-C.1-1.20.1" class="pilcrow">¶</a></p>
+</li>
+          <li class="normal" id="appendix-C.1-1.21">
+            <p id="appendix-C.1-1.21.1">IANA registration of two CoRE if= values: "ace.group" and "ace.groups".<a href="#appendix-C.1-1.21.1" class="pilcrow">¶</a></p>
+</li>
+          <li class="normal" id="appendix-C.1-1.22">
+            <p id="appendix-C.1-1.22.1">Editorial fixes and improvements.<a href="#appendix-C.1-1.22.1" class="pilcrow">¶</a></p>
 </li>
         </ul>
 </section>
@@ -5235,7 +5646,7 @@ <h3 id="name-version-00-to-01">
       <h2 id="name-acknowledgments">
 <a href="#name-acknowledgments" class="section-name selfRef">Acknowledgments</a>
       </h2>
-<p id="appendix-D-1">The following individuals were helpful in shaping this document: <span class="contact-name">Christian Amsüss</span>, <span class="contact-name">Carsten Bormann</span>, <span class="contact-name">Rikard Höglund</span>, <span class="contact-name">Ben Kaduk</span>, <span class="contact-name">Warren Kumari</span>, <span class="contact-name">Watson Ladd</span>, <span class="contact-name">John Preuß Mattsson</span>, <span class="contact-name">Daniel Migault</span>, <span class="contact-name">Jim Schaad</span>, <span class="contact-name">Ludwig Seitz</span>, <span class="contact-name">Göran Selander</span>, <span class="contact-name">Cigdem Sengul</span>, <span class="contact-name">Peter van der Stok</span>, and <span class="contact-name">Paul Wouters</span>.<a href="#appendix-D-1" class="pilcrow">¶</a></p>
+<p id="appendix-D-1">The following individuals were helpful in shaping this document: <span class="contact-name">Christian Amsüss</span>, <span class="contact-name">Carsten Bormann</span>, <span class="contact-name">Roman Danyliw</span>, <span class="contact-name">Martin Duke</span>, <span class="contact-name">Thomas Fossati</span>, <span class="contact-name">Vidhi Goel</span>, <span class="contact-name">Rikard Höglund</span>, <span class="contact-name">Ben Kaduk</span>, <span class="contact-name">Erik Kline</span>, <span class="contact-name">Warren Kumari</span>, <span class="contact-name">Watson Ladd</span>, <span class="contact-name">John Preuß Mattsson</span>, <span class="contact-name">Daniel Migault</span>, <span class="contact-name">Zaheduzzaman Sarker</span>, <span class="contact-name">Jim Schaad</span>, <span class="contact-name">Ludwig Seitz</span>, <span class="contact-name">Göran Selander</span>, <span class="contact-name">Cigdem Sengul</span>, <span class="contact-name">Henry Thompson</span>, <span class="contact-name">Peter van der Stok</span>, and <span class="contact-name">Paul Wouters</span>.<a href="#appendix-D-1" class="pilcrow">¶</a></p>
 <p id="appendix-D-2">The work on this document has been partly supported by VINNOVA and the Celtic-Next project CRITISEC; by the H2020 project SIFIS-Home (Grant agreement 952652); and by the EIT-Digital High Impact Initiative ACTIVE.<a href="#appendix-D-2" class="pilcrow">¶</a></p>
 </section>
 </div>
diff --git a/warren-kumari-review/draft-ietf-ace-key-groupcomm.txt b/warren-kumari-review/draft-ietf-ace-key-groupcomm.txt
index 7332fa3..f5a9fa0 100644
--- a/warren-kumari-review/draft-ietf-ace-key-groupcomm.txt
+++ b/warren-kumari-review/draft-ietf-ace-key-groupcomm.txt
@@ -5,8 +5,8 @@
 ACE Working Group                                           F. Palombini
 Internet-Draft                                               Ericsson AB
 Intended status: Standards Track                               M. Tiloca
-Expires: 15 June 2024                                            RISE AB
-                                                        13 December 2023
+Expires: 15 July 2024                                            RISE AB
+                                                         12 January 2024
 
 
            Key Provisioning for Group Communication using ACE
@@ -51,11 +51,11 @@ Status of This Memo
    time.  It is inappropriate to use Internet-Drafts as reference
    material or to cite them other than as "work in progress."
 
-   This Internet-Draft will expire on 15 June 2024.
+   This Internet-Draft will expire on 15 July 2024.
 
 Copyright Notice
 
-   Copyright (c) 2023 IETF Trust and the persons identified as the
+   Copyright (c) 2024 IETF Trust and the persons identified as the
    document authors.  All rights reserved.
 
    This document is subject to BCP 78 and the IETF Trust's Legal
@@ -135,14 +135,15 @@ Table of Contents
      11.3.  OAuth Parameters
      11.4.  OAuth Parameters CBOR Mappings
      11.5.  Interface Description (if=) Link Target Attribute Values
-     11.6.  ACE Groupcomm Parameters
-     11.7.  ACE Groupcomm Key Types
-     11.8.  ACE Groupcomm Profiles
-     11.9.  ACE Groupcomm Policies
-     11.10. Sequence Number Synchronization Methods
-     11.11. ACE Groupcomm Errors
-     11.12. ACE Groupcomm Rekeying Schemes
-     11.13. Expert Review Instructions
+     11.6.  Custom Problem Detail Keys Registry
+     11.7.  ACE Groupcomm Parameters
+     11.8.  ACE Groupcomm Key Types
+     11.9.  ACE Groupcomm Profiles
+     11.10. ACE Groupcomm Policies
+     11.11. Sequence Number Synchronization Methods
+     11.12. ACE Groupcomm Errors
+     11.13. ACE Groupcomm Rekeying Schemes
+     11.14. Expert Review Instructions
    12. References
      12.1.  Normative References
      12.2.  Informative References
@@ -173,11 +174,11 @@ Table of Contents
    distribute, and renew keying material and configuration parameters to
    protect message exchanges in a group communication environment.
 
-   Candidate group members acting as Clients and authorized to join a
-   group can interact with the Key Distribution Center (KDC) acting as
-   Resource Server and responsible for that group, in order to obtain
-   the necessary keying material and parameters to communicate with
-   other group members.
+   Candidate group members acting as ACE Clients and authorized to join
+   a group can interact with the Key Distribution Center (KDC) acting as
+   ACE Resource Server and responsible for that group, in order to
+   obtain the necessary keying material and parameters to communicate
+   with other group members.
 
    In particular, this document defines the operations and interface
    available at the KDC, as well as general message formats for the
@@ -193,9 +194,16 @@ Table of Contents
    particular group communication approach and defining how
    communications in the group are protected, as well as the specific
    keying material and configuration parameters provided to group
-   members.  In order to ensure consistency and aid the development of
-   such application profiles, this document defines a number of related
-   compliance requirements (see Appendix A).
+   members.
+
+   In order to ensure consistency and aid the development of such
+   application profiles, Appendix A of this document defines a number of
+   related compliance requirements.  In particular, Appendix A.1
+   compiles the requirements that application profiles are REQUIRED to
+   fulfill; these are referred to by an identifier that starts with
+   "REQ".  Instead, Appendix A.2 compiles the requirements that
+   application profiles MAY fulfill; these are referred to by an
+   identifier that starts with "OPT".
 
    New keying material is intended to be generated and distributed to
    the group upon membership changes (rekeying).  If the application
@@ -243,8 +251,8 @@ Table of Contents
       document does not use the CoAP definition of "endpoint", which is
       "An entity participating in the CoAP protocol".
 
-   *  The terms and concepts described in CBOR [RFC8949] and COSE
-      [RFC9052][RFC9053][RFC9338].
+   *  The terms and concepts described in CDDL [RFC8610], CBOR
+      [RFC8949], and COSE [RFC9052][RFC9053][RFC9338].
 
    A principal interested to participate in group communication as well
    as already participating as a group member is interchangeably denoted
@@ -274,28 +282,29 @@ Table of Contents
    Furthermore, this document uses "names" or "identifiers" for groups
    and nodes.  Their different meanings are summarized below.
 
-   *  Group name: the invariant once established identifier of a group.
-      It is used in the interactions between Client, AS, and RS to
-      identify a group.  A group name is always unique among the group
-      names of the existing groups under the same KDC.
+   *  Group name: The identifier of a group, as a text string.  Once
+      established, it is invariant.  It is used in the interactions
+      between Client, AS, and RS to identify a group.  A group name is
+      always unique among the group names of the existing groups under
+      the same KDC.
 
-   *  GROUPNAME: the invariant once established text string used in
-      URIs.  GROUPNAME uniquely maps to the group name of a group,
-      although they do not necessarily coincide.
+   *  GROUPNAME: The text string used in URIs to identify a group.  Once
+      established, it is invariant.  GROUPNAME uniquely maps to the
+      group name of a group, although they do not necessarily coincide.
 
    *  Group identifier: the identifier of the group keying material used
       in a group.  Unlike group name and GROUPNAME, this identifier
       changes over time, when the group keying material is updated.
 
-   *  Node name: the invariant once established identifier of a node.
-      It is used in the interactions between Client and RS, as well as
-      to identify a member of a group.  Within the same group, a node
-      name is always unique among the node names of all the current
-      members of that group.
+   *  Node name: The identifier of a node, as a text string.  Once
+      established, it is invariant.  It is used in the interactions
+      between Client and RS, as well as to identify a member of a group.
+      Within the same group, a node name is always unique among the node
+      names of all the current members of that group.
 
-   *  NODENAME: the invariant once established text string used in URIs
-      to identify a member of a group.  Its value coincides with the
-      node name of the associated group member.
+   *  NODENAME: The text string used in URIs to identify a member of a
+      group.  Once established, it is invariant.  Its value coincides
+      with the node name of the associated group member.
 
    This document additionally uses the following terminology:
 
@@ -323,12 +332,14 @@ Table of Contents
    *  Individual keying material: information exclusively pertaining to
       a group member, as associated with its group membership and
       related to other keying material and parameters used in the group.
-      For example, this can be a member identifier that is unique within
-      the group.  The specific nature and format of individual keying
-      material used in a group is defined in application profiles of
-      this specification.  The individual keying material of a group
-      member is not related to the secure association between that group
-      member and the KDC.
+      For example, this can be an identifier that the secure
+      communication protocol employs to uniquely identify a node as a
+      group member (e.g., a cryptographic key identifier uniquely
+      associated with the group member in question).  The specific
+      nature and format of individual keying material used in a group is
+      defined in application profiles of this specification.  The
+      individual keying material of a group member is not related to the
+      secure association between that group member and the KDC.
 
    Examples throughout this document are expressed in CBOR diagnostic
    notation without the tag and value abbreviations.
@@ -364,8 +375,9 @@ Table of Contents
       Client can have different roles.
 
    *  Authorization Server (AS): as per the AS defined in the ACE
-      Framework, it enforces access policies, and knows if a node is
-      allowed to join a given group with write and/or read rights.
+      Framework [RFC9200], it enforces access policies, and knows if a
+      node is allowed to join a given group with write and/or read
+      rights.
 
    *  Key Distribution Center (KDC): maintains the keying material to
       protect group communications, and provides it to Clients
@@ -378,9 +390,10 @@ Table of Contents
       changes.
 
    *  Dispatcher: entity through which the Clients communicate with the
-      group, when sending a message intended to multiple group members.
+      group when sending a message intended to multiple group members.
       That is, the Dispatcher distributes such a one-to-many message to
-      the group members as intended recipients.  A single-recipient
+      the group members as intended recipients.  The Dispatcher does not
+      have access to the group keying material.  A single-recipient
       message intended to only one group member may be delivered by
       alternative means, with no assistance from the Dispatcher.
 
@@ -393,8 +406,9 @@ Table of Contents
 
       If it consists of an explicit entity such as a pub-sub Broker or a
       message relayer, the Dispatcher is comparable to an untrusted on-
-      path intermediary, and as such it is able to read the messages
-      sent by Clients in the group.
+      path intermediary, and as such it is able to see the messages sent
+      by Clients in the group, but not to decrypt them and read their
+      plain content.
 
    This document specifies a mechanism for:
 
@@ -544,7 +558,7 @@ Table of Contents
    parameters, which, if included, MUST have format and value as
    specified below.
 
-   *  'scope', specifying the name of the groups that the Client
+   *  'scope', specifying the names of the groups that the Client
       requests to access, and optionally the roles that the Client
       requests to have in those groups.
 
@@ -607,6 +621,8 @@ Table of Contents
    As defined in [RFC9200], other additional parameters can be included
    if necessary.
 
+   ;# include rfc9237
+
    gname = tstr
 
    permissions = uint .bits roles
@@ -618,9 +634,11 @@ Table of Contents
       Verifier: 4
    )
 
-   scope_entry = AIF_Generic<gname, permissions>
+   scope_entry = AIF-Generic<gname, permissions>
 
-   scope = << [ + scope_entry ] >>
+   scope_entries = [ + scope_entry ]
+
+   scope = bstr .cbor scope_entries
 
               Figure 4: Example of scope using the AIF format
 
@@ -630,7 +648,9 @@ Table of Contents
 
    scope_entry = [ gname , ? ( role / [ 2*role ] ) ]
 
-   scope = << [ + scope_entry ] >>
+   scope_entries = [ + scope_entry ]
+
+   scope = bstr .cbor scope_entries
 
        Figure 5: Example of scope using the textual format, with the
           group name and role identifiers encoded as text strings
@@ -713,9 +733,10 @@ Table of Contents
    endpoint (see Section 5.10.1 of [RFC9200]).
 
    Note that this request deviates from the one defined in [RFC9200],
-   since it allows to ask the KDC for additional information concerning
-   the authentication credentials used in the group to ensure source
-   authentication, as well as for possible additional group parameters.
+   since it allows the Client to ask the KDC for additional information
+   concerning the authentication credentials used in the group to ensure
+   source authentication, as well as for possible additional group
+   parameters.
 
    The joining node MAY ask for this information from the KDC through
    the same Token Transfer Request.  In this case, the message MUST have
@@ -946,11 +967,9 @@ Table of Contents
 4.1.  Interface at the KDC
 
    The KDC provides its interface by hosting the following resources.
-   Note that the root url-path "/ace-group" used hereafter is a default
+   Note that the root url-path "ace-group" used hereafter is a default
    name; implementations are not required to use this name, and can
-   define their own instead.  The Interface Description (if=) Link
-   Target Attribute value "ace.group" is registered in Section 11.5 and
-   can be used to describe this interface.
+   define their own instead.
 
    If request messages sent to the KDC as well as success response
    messages from the KDC include a payload and specify a Content-Format,
@@ -958,7 +977,7 @@ Table of Contents
    groupcomm+cbor, defined in Section 11.2.  CBOR labels for the message
    parameters are defined in Section 8.
 
-   *  /ace-group : the path of this resource is invariant once the
+   *  /ace-group : the path of this root resource is invariant once the
       resource is established, and indicates that this specification is
       used.  If other applications run on a KDC implementing this
       specification and use this same path, those applications will
@@ -969,15 +988,69 @@ Table of Contents
       group names, each corresponding to one of the specified group
       identifiers.  This operation is described in Section 4.2.1.1.
 
+      Clients may be authorized to access this resource even without
+      being members of any group at the KDC, and even if they are not
+      authorized to become group members (e.g., when authorized to be
+      external signature verifiers).
+
+      The Interface Description (if=) Link Target Attribute value
+      "ace.groups" is registered in Section 11.5 and can be used to
+      describe the interface provided by this root resource.
+
+      The example below shows an exchange with a KDC with address
+      2001:db8::ab that hosts the resource /ace-group and returns a link
+      to such a resource in link-format [RFC6690].
+
+      Request:
+
+      Header: GET (Code=0.01)
+      Uri-Host: "kdc.example.com"
+      Uri-Path: ".well-known"
+      Uri-Path: "core"
+      Uri-Query: "if=ace.groups"
+
+      Response:
+
+      Header: Content (Code=2.05)
+      Content-Format: 40 (application/link-format)
+      Payload:
+        <coap://[2001:db8::ab]/ace-group>;if="ace.groups"
+
    *  /ace-group/GROUPNAME : one such sub-resource to /ace-group is
-      hosted for each group with name GROUPNAME that the KDC manages,
-      and contains the symmetric group keying material for that group.
+      hosted for each group with name GROUPNAME that the KDC manages.
+      In particular, it is the group-membership resource associated with
+      that group, of which it contains the symmetric group keying
+      material.
 
       A Client can access this resource in order to join the group with
       name GROUPNAME, or later as a group member to retrieve the current
       group keying material.  These operations are described in
       Section 4.3.1.1 and Section 4.3.2.1, respectively.
 
+      The Interface Description (if=) Link Target Attribute value
+      "ace.group" is registered in Section 11.5 and can be used to
+      describe the interface provided by a group-membership resource.
+
+      The example below shows an exchange with a KDC with address
+      2001:db8::ab that hosts the group-membership resource /ace-group/
+      gp1 and returns a link to such a resource in link-format
+      [RFC6690].
+
+      Request:
+
+      Header: GET (Code=0.01)
+      Uri-Host: "kdc.example.com"
+      Uri-Path: ".well-known"
+      Uri-Path: "core"
+      Uri-Query: "if=ace.group"
+
+      Response:
+
+      Header: Content (Code=2.05)
+      Content-Format: 40 (application/link-format)
+      Payload:
+        <coap://[2001:db8::ab]/ace-group/gp1>;if="ace.group"
+
       If the value of the GROUPNAME URI path and the group name in the
       access token scope ('gname' in Section 3.2) are not required to
       coincide, the KDC MUST implement a mechanism to map the GROUPNAME
@@ -989,7 +1062,7 @@ Table of Contents
       contains the authentication credentials of all the members of the
       group with name GROUPNAME.
 
-      This resource is created only in case the KDC acts as repository
+      This resource is created only in case the KDC acts as a repository
       of authentication credentials for group members.
 
       A Client can access this resource in order to retrieve the
@@ -1192,33 +1265,78 @@ Table of Contents
    Application profiles of this specification MAY define optional or
    mandatory payload formats for specific error cases (OPT4).
 
-   Some error responses from the KDC can have Content-Format set to
-   application/ace-groupcomm+cbor.  In such a case, the payload of the
-   response MUST be a CBOR map, which includes the following fields.
-
-   *  'error', with value a CBOR integer specifying the error occurred
-      at the KDC.  The value is taken from the "Value" column of the
-      "ACE Groupcomm Errors" registry defined in Section 11.11 of this
-      specification.  This field MUST be present.
-
-   *  'error_description', with value a CBOR text string specifying a
-      human-readable diagnostic description of the error occurred at the
-      KDC, written in English.  The diagnostic text is intended for
-      software engineers as well as for device and network operators, in
-      order to aid debugging and provide context for possible
-      intervention.  The diagnostic message SHOULD be logged by the KDC.
-      This field MAY be present, and it is unlikely relevant in an
-      unattended setup where human intervention is not expected.
-
-   The 'error' and 'error_description' fields are defined as OPTIONAL to
-   support for Clients (see Section 8).  A Client supporting the 'error'
-   parameter and able to understand the specified error may use that
-   information to determine what actions to take next.
+   Some error responses from the KDC can convey error-specific
+   information according to the problem-details format defined in
+   [RFC9290].  Such error responses MUST have Content-Format set to
+   application/concise-problem-details+cbor.  The payload of these error
+   responses MUST be a CBOR map specifying a Concise Problem Details
+   data item (see Section 2 of [RFC9290]).  The CBOR map is formatted as
+   follows.
+
+   *  It MUST include the Custom Problem Detail entry 'ace-groupcomm-
+      error' registered in Section 11.6 of this document.
+
+      This entry includes only one field, namely 'error-id'.  The map
+      key for 'error-id' is the CBOR unsigned integer with value 0.  The
+      value of 'error-id' is a CBOR integer specifying the error
+      occurred at the KDC.  This value is taken from the 'Value' column
+      of the "ACE Groupcomm Errors" registry defined in Section 11.12 of
+      this document.
+
+      The CDDL notation [RFC8610] of the 'ace-groupcomm-error' entry is
+      given below.
+
+      ace-groupcomm-error = {
+        &(error-id: 0) => int
+      }
+
+   *  It MAY include further Standard Problem Detail entries or Custom
+      Problem Detail entries (see [RFC9290]).
+
+      In particular, it can include the Standard Problem Detail entry
+      'detail' (map key -2), whose value is a CBOR text string that
+      specifies a human-readable, diagnostic description of the error
+      occurred at the KDC.  The diagnostic text is intended for software
+      engineers as well as for device and network operators, in order to
+      aid debugging and provide context for possible intervention.  The
+      diagnostic message SHOULD be logged by the KDC.  The 'detail'
+      entry is unlikely relevant in an unattended setup where human
+      intervention is not expected.
+
+   An example of error response using the problem-details format is
+   shown in Figure 6.
+
+   Response:
+
+   Header: Service Unavailable (Code=5.03)
+   Content-Format: application/concise-problem-details+cbor
+   Payload:
+   {
+     / title /                -1: "No available node identifiers",
+     / detail /               -2: "Things will change after a
+                                   group rekeying; try later",
+     / ace-groupcomm-error /  TBD: {
+       / error-id /  0: 4 / "No available node identifiers" /,
+     }
+   }
+
+          Figure 6: Example of Error Response with Problem Details
+
+   Note to RFC Editor: In the figure above, please replace "TBD" with
+   the unsigned integer assigned as key value to the Custom Problem
+   Detail entry 'ace-groupcomm-error' (see Section 11.6).  Then, please
+   delete this paragraph.
+
+   The problem-details format in general and the Custom Problem Detail
+   entry 'ace-groupcomm-error' in particular are OPTIONAL to support for
+   Clients.  A Client supporting the entry 'ace-groupcomm-error' and
+   able to understand the specified error may use that information to
+   determine what actions to take next.
 
    Section 9 of this specification defines an initial set of error
-   identifiers, as possible values for the 'error' field.  Application
-   profiles of this specification inherit this initial set of error
-   identifiers and MAY define additional value (OPT5).
+   identifiers, as possible values for the 'error-id' field.
+   Application profiles of this specification inherit this initial set
+   of error identifiers and MAY define additional values (OPT5).
 
 4.2.  /ace-group
 
@@ -1274,15 +1392,15 @@ Table of Contents
 4.2.1.1.  Retrieve Group Names
 
    In case the joining node only knows the group identifier of the group
-   it wishes to join or about which it wishes to get update information
+   it wishes to join or about which it wishes to get updated information
    from the KDC, the node can contact the KDC to request the
    corresponding group name and group-membership resource URI.  The node
    can request several group identifiers at once.  It does so by sending
    a CoAP FETCH request to the /ace-group endpoint at the KDC formatted
    as defined in Section 4.2.1.
 
-   Figure 6 gives an overview of the exchanges described above, and
-   Figure 7 shows an example.
+   Figure 7 gives an overview of the exchanges described above, and
+   Figure 8 shows an example.
 
     Client                                                         KDC
        |                                                            |
@@ -1292,7 +1410,7 @@ Table of Contents
        |<-- Group Name and URI Retrieval Response: 2.05 (Content) --|
        |                                                            |
 
-      Figure 6: Message Flow of Group Name and URI Retrieval Request-
+      Figure 7: Message Flow of Group Name and URI Retrieval Request-
                                   Response
 
    Request:
@@ -1312,7 +1430,7 @@ Table of Contents
      { "gid": [01, 02], "gname": ["group1", "group2"],
        "guri": ["/ace-group/g1", "/ace-group/g2"] }
 
-     Figure 7: Example of Group Name and URI Retrieval Request-Response
+     Figure 8: Example of Group Name and URI Retrieval Request-Response
 
 4.3.  /ace-group/GROUPNAME
 
@@ -1390,7 +1508,7 @@ Table of Contents
          authentication credentials associated with specific group
          identifiers as defined in Section 4.4.1.1.
 
-      The CDDL definition [RFC8610] of 'get_creds' is given in Figure 8,
+      The CDDL definition [RFC8610] of 'get_creds' is given in Figure 9,
       using as example encoding: node identifier encoded as a CBOR byte
       string; role identifier encoded as a CBOR text string, and
       combination of roles encoded as a CBOR array of roles.
@@ -1412,7 +1530,7 @@ Table of Contents
 
    get_creds = null / [ inclusion_flag, role_filter, id_filter]
 
-       Figure 8: CDLL definition of get_creds, using as example node
+       Figure 9: CDLL definition of get_creds, using as example node
                 identifier encoded as bstr and role as tstr
 
    *  'client_cred', encoded as a CBOR byte string, with value the
@@ -1453,7 +1571,7 @@ Table of Contents
          'cnonce' parameter above, encoded as a CBOR byte string.
 
       An example of PoP input to compute 'client_cred_verify' using CBOR
-      encoding is given in Figure 9.
+      encoding is given in Figure 10.
 
       A possible type of PoP evidence is a signature that the Client
       computes by using its own private key, whose corresponding public
@@ -1510,7 +1628,7 @@ Table of Contents
      0x4f 826667726f7570316673656e646572
        48 018a278f7faab55a 48 25a8991cd700ac01
 
-       Figure 9: Example of PoP input to compute 'client_cred_verify'
+      Figure 10: Example of PoP input to compute 'client_cred_verify'
                             using CBOR encoding
 
    If the request does not include a 'scope' field, the KDC is expected
@@ -1550,10 +1668,11 @@ Table of Contents
 
       If this verification fails, the handler MUST reply with a 4.00
       (Bad Request) error response.  The response MUST have Content-
-      Format set to application/ace-groupcomm+cbor and is formatted as
-      defined in Section 4.  The value of the 'error' field MUST be set
-      to 2 ("Authentication credential incompatible with the group
-      configuration").
+      Format set to application/concise-problem-details+cbor and is
+      formatted as defined in Section 4.1.2.  Within the Custom Problem
+      Detail entry 'ace-groupcomm-error', the value of the 'error-id'
+      field MUST be set to 2 ("Authentication credential incompatible
+      with the group configuration").
 
    *  The KDC verifies the PoP evidence contained in the
       'client_cred_verify' field.  Application profiles of this
@@ -1563,9 +1682,11 @@ Table of Contents
 
       If the PoP evidence does not pass verification, the handler MUST
       reply with a 4.00 (Bad Request) error response.  The response MUST
-      have Content-Format set to application/ace-groupcomm+cbor and is
-      formatted as defined in Section 4.  The value of the 'error' field
-      MUST be set to 3 ("Invalid Proof-of-Possession evidence").
+      have Content-Format set to application/concise-problem-
+      details+cbor and is formatted as defined in Section 4.1.2.  Within
+      the Custom Problem Detail entry 'ace-groupcomm-error', the value
+      of the 'error-id' field MUST be set to 3 ("Invalid Proof-of-
+      Possession evidence").
 
    If no authentication credential is included in the 'client_cred'
    field, the handler checks if an authentication credential is already
@@ -1664,7 +1785,7 @@ Table of Contents
    of this specification (REQ17), as well as values of 'gkty' accepted
    by the application (REQ18).  Additionally, documents specifying the
    key format MUST register it in the "ACE Groupcomm Key Types" registry
-   defined in Section 11.7, including its name, type, and application
+   defined in Section 11.8, including its name, type, and application
    profile to be used with.
 
     +----------+----------------+---------+-------------+------------+
@@ -1674,9 +1795,9 @@ Table of Contents
     |          |                |         | is reserved |            |
     +----------+----------------+---------+-------------+------------+
 
-                     Figure 10: ACE Groupcomm Key Types
+                     Figure 11: ACE Groupcomm Key Types
 
-   Note to RFC Editor: In Figure 10, please replace "[RFC-XXXX]" with
+   Note to RFC Editor: In Figure 11, please replace "[RFC-XXXX]" with
    the RFC number of this specification and delete this paragraph.
 
    The response SHOULD contain the following parameter:
@@ -1705,9 +1826,9 @@ Table of Contents
       | Reserved | This value is reserved | 0          | [RFC-XXXX] |
       +----------+------------------------+------------+------------+
 
-                     Figure 11: ACE Groupcomm Profiles
+                     Figure 12: ACE Groupcomm Profiles
 
-   Note to RFC Editor: In Figure 11, please replace "[RFC-XXXX]" with
+   Note to RFC Editor: In Figure 12, please replace "[RFC-XXXX]" with
    the RFC number of this specification and delete this paragraph.
 
    *  'creds', MUST be present if 'get_creds' was present in the
@@ -1762,7 +1883,9 @@ Table of Contents
       identifier that the group member associated with the i-th
       authentication credential in 'creds' has in the group.  In
       particular, the i-th array element is encoded as a CBOR byte
-      string, with value the node identifier of the group member.
+      string, with value the node identifier of the group member.  The
+      specific format of node identifiers of group members is specified
+      by the application profile (REQ25).
 
    *  'group_policies', with value a CBOR map, whose entries specify how
       the group handles specific management aspects.  These include, for
@@ -1771,7 +1894,7 @@ Table of Contents
       registered in the "ACE Groupcomm Policies" registry.  This
       specification defines the three elements "Sequence Number
       Synchronization Methods", "Key Update Check Interval", and
-      "Expiration Delta", which are summarized in Figure 12.
+      "Expiration Delta", which are summarized in Figure 13.
       Application profiles that build on this document MUST specify the
       exact content format and default value of included map entries
       (REQ20).
@@ -1784,7 +1907,7 @@ Table of Contents
  | Number       |       |          | group members to     |            |
  | Synchroniza- |       |          | synchronize with     |            |
  | tion Method  |       |          | sequence numbers of  |            |
- |              |       |          | of sender group      |            |
+ |              |       |          | sender group         |            |
  |              |       |          | members. Its value   |            |
  |              |       |          | is taken from the    |            |
  |              |       |          | 'Value' column of    |            |
@@ -1811,9 +1934,9 @@ Table of Contents
  |              |       |          | incoming messages    |            |
  +--------------+-------+----------|----------------------|------------+
 
-                   Figure 12: ACE Groupcomm Policies
+                   Figure 13: ACE Groupcomm Policies
 
-   Note to RFC Editor: In Figure 12, please replace all occurrences of
+   Note to RFC Editor: In Figure 13, please replace all occurrences of
    "[RFC-XXXX]" with the RFC number of this specification and delete
    this paragraph.
 
@@ -1851,7 +1974,7 @@ Table of Contents
          'kdc_nonce' parameter, encoded as a CBOR byte string.
 
       An example of PoP input to compute 'kdc_cred_verify' using CBOR
-      encoding is given in Figure 14.
+      encoding is given in Figure 15.
 
       A possible type of PoP evidence is a signature that the KDC
       computes by using its own private key, whose corresponding public
@@ -1865,7 +1988,7 @@ Table of Contents
       uses to provide new group keying meterial to the group members.
       This parameter is encoded as a CBOR integer, whose value is taken
       from the "Value" column of the "ACE Groupcomm Rekeying Schemes"
-      registry defined in Section 11.12 of this specification.
+      registry defined in Section 11.13 of this specification.
 
  +-------+----------------+-------------------------------+------------+
  | Value |      Name      |          Description          | Reference  |
@@ -1876,13 +1999,13 @@ Table of Contents
  |       |                | association with that node    |            |
  +-------+----------------+-------------------------------+------------+
 
-               Figure 13: ACE Groupcomm Rekeying Schemes
+               Figure 14: ACE Groupcomm Rekeying Schemes
 
    Application profiles of this specification MAY define a default group
    rekeying scheme, to refer to in case the 'rekeying_scheme' parameter
    is not included in the Join Response (OPT9).
 
-   Note to RFC Editor: In Figure 13, please replace "[RFC-XXXX]" with
+   Note to RFC Editor: In Figure 14, please replace "[RFC-XXXX]" with
    the RFC number of this specification and delete this paragraph.
 
    *  'mgt_key_material', encoded as a CBOR byte string and containing
@@ -1954,7 +2077,7 @@ Table of Contents
    PoP input:
      0x48 25a8991cd700ac01 48 cef04b2aa791bc6d
 
-        Figure 14: Example of PoP input to compute 'kdc_cred_verify'
+        Figure 15: Example of PoP input to compute 'kdc_cred_verify'
                             using CBOR encoding
 
    After sending the Join Response, if the KDC has an associated
@@ -1982,8 +2105,8 @@ Table of Contents
 
 4.3.1.1.  Join the Group
 
-   Figure 15 gives an overview of the join exchange between the Client
-   and the KDC, when the Client first joins a group, while Figure 16
+   Figure 16 gives an overview of the join exchange between the Client
+   and the KDC, when the Client first joins a group, while Figure 17
    shows an example.
 
       Client                                                     KDC
@@ -1993,7 +2116,7 @@ Table of Contents
          |<------------ Join Response: 2.01 (Created) ----------- |
          | Location-Path = "/ace-group/GROUPNAME/nodes/NODENAME"  |
 
-            Figure 15: Message Flow of the Join Request-Response
+            Figure 16: Message Flow of the Join Request-Response
 
  Request:
 
@@ -2023,7 +2146,7 @@ Table of Contents
      "peer_roles": ["sender", ["sender", "receiver"]],
      "peer_identifiers": [ ID1, ID2 ] }
 
-  Figure 16: Example of First Join Request-Response for Group Joining
+  Figure 17: Example of First Join Request-Response for Group Joining
 
    If not previously established, the Client and the KDC MUST first
    establish a pairwise secure communication channel (REQ24).  This can
@@ -2080,9 +2203,10 @@ Table of Contents
    that the Client is a current member of the group.  If the
    verification fails, the KDC MUST reply with a 4.03 (Forbidden) error
    response.  The response MUST have Content-Format set to application/
-   ace-groupcomm+cbor and is formatted as defined in Section 4.  The
-   value of the 'error' field MUST be set to 0 ("Operation permitted
-   only to group members").
+   concise-problem-details+cbor and is formatted as defined in
+   Section 4.1.2.  Within the Custom Problem Detail entry 'ace-
+   groupcomm-error', the value of the 'error-id' field MUST be set to 0
+   ("Operation permitted only to group members").
 
    If all verifications succeed, the handler replies with a 2.05
    (Content) response containing the symmetric group keying material.
@@ -2104,8 +2228,8 @@ Table of Contents
    keying material, by sending a CoAP GET request to the /ace-group/
    GROUPNAME endpoint at the KDC, where GROUPNAME is the group name.
 
-   Figure 17 gives an overview of the join exchange between the Client
-   and the KDC, when the Client first joins a group, while Figure 18
+   Figure 18 gives an overview of the join exchange between the Client
+   and the KDC, when the Client first joins a group, while Figure 19
    shows an example.
 
  Client                                                              KDC
@@ -2115,7 +2239,7 @@ Table of Contents
     |<----------- Key Distribution Response: 2.05 (Content) --------- |
     |                                                                 |
 
-      Figure 17: Message Flow of Key Distribution Request-Response
+      Figure 18: Message Flow of Key Distribution Request-Response
 
    Request:
 
@@ -2133,7 +2257,7 @@ Table of Contents
             with KEY being a CBOR byte strings):
      { "gkty": 13, "key": KEY, "num": 12 }
 
-          Figure 18: Example of Key Distribution Request-Response
+          Figure 19: Example of Key Distribution Request-Response
 
 4.4.  /ace-group/GROUPNAME/creds
 
@@ -2277,8 +2401,8 @@ Table of Contents
    the /ace-group/GROUPNAME/creds endpoint at the KDC, where GROUPNAME
    is the group name, and formatted as defined in Section 4.4.1.
 
-   Figure 19 gives an overview of the exchange mentioned above, while
-   Figure 20 shows an example of such an exchange.
+   Figure 20 gives an overview of the exchange mentioned above, while
+   Figure 21 shows an example of such an exchange.
 
       Client                                                      KDC
          |                                                         |
@@ -2289,7 +2413,7 @@ Table of Contents
          |<-- Authentication Credential Response: 2.05 (Created) --|
          |                                                         |
 
-       Figure 19: Message Flow of Authentication Credential Request-
+       Figure 20: Message Flow of Authentication Credential Request-
        Response to Obtain the Authentication Credentials of Specific
                                Group Members
 
@@ -2302,18 +2426,18 @@ Table of Contents
    Uri-Path: "pub-key"
    Content-Format: "application/ace-groupcomm+cbor"
    Payload:
-     { "get_creds": [true, [], [ ID3 ]] }
+     { "get_creds": [true, [], [ ID2, ID3 ]] }
 
    Response:
 
    Header: Content (Code=2.05)
    Content-Format: "application/ace-groupcomm+cbor"
    Payload (in CBOR diagnostic notation):
-     { "creds": [ AUTH_CRED_3 ],
-       "peer_roles": [ "receiver" ],
-       "peer_identifiers": [ ID3 ] }
+     { "creds": [ AUTH_CRED_2, AUTH_CRED_3, ],
+       "peer_roles": [ ["sender", "receiver"], "receiver" ],
+       "peer_identifiers": [ ID2, ID3 ] }
 
-      Figure 20: Example of Authentication Credential Request-Response
+      Figure 21: Example of Authentication Credential Request-Response
          to Obtain the Authentication Credentials of Specific Group
                                   Members
 
@@ -2339,7 +2463,7 @@ Table of Contents
    request to the /ace-group/GROUPNAME/creds endpoint at the KDC, where
    GROUPNAME is the group name.
 
-   Figure 21 gives an overview of the message exchange, while Figure 22
+   Figure 22 gives an overview of the message exchange, while Figure 23
    shows an example of such an exchange.
 
       Client                                                      KDC
@@ -2351,7 +2475,7 @@ Table of Contents
          |<-- Authentication Credential Response: 2.05 (Content) --|
          |                                                         |
 
-       Figure 21: Message Flow of Authentication Credential Request-
+       Figure 22: Message Flow of Authentication Credential Request-
         Response to Obtain the Authentication Credentials of all the
                                Group Members
 
@@ -2374,7 +2498,7 @@ Table of Contents
        "peer_roles": ["sender", ["sender", "receiver"], "receiver"],
        "peer_identifiers": [ ID1, ID2, ID3 ] }
 
-      Figure 22: Example of Authentication Credential Request-Response
+      Figure 23: Example of Authentication Credential Request-Response
      to Obtain the Authentication Credentials of all the Group Members
 
 4.5.  /ace-group/GROUPNAME/kdc-cred
@@ -2414,7 +2538,7 @@ Table of Contents
          'kdc_nonce' parameter, encoded as a CBOR byte string.
 
       An example of PoP input to compute 'kdc_cred_verify' using CBOR
-      encoding is given in Figure 23.
+      encoding is given in Figure 24.
 
       The PoP evidence is computed by means of the same method used for
       computing the PoP evidence that was included in the Join Response
@@ -2437,7 +2561,7 @@ Table of Contents
    PoP input:
      0x48 25a8991cd700ac01 48 0b7db12aaff56da3
 
-        Figure 23: Example of PoP input to compute 'kdc_cred_verify'
+        Figure 24: Example of PoP input to compute 'kdc_cred_verify'
                             using CBOR encoding
 
 4.5.1.1.  Retrieve the KDC's Authentication Credential
@@ -2462,8 +2586,8 @@ Table of Contents
    by the Client to verify the PoP evidence in 'kdc_cred_verify', and
    MUST specify which of those approaches is used in which case (REQ21).
 
-   Figure 24 gives an overview of the exchange described above, while
-   Figure 25 shows an example.
+   Figure 25 gives an overview of the exchange described above, while
+   Figure 26 shows an example.
 
     Group
     Member                                                         KDC
@@ -2475,7 +2599,7 @@ Table of Contents
       |<-- KDC Authentication Credential Response: 2.05 (Content) --|
       |                                                             |
 
-     Figure 24: Message Flow of KDC Authentication Credential Request-
+     Figure 25: Message Flow of KDC Authentication Credential Request-
         Response to Obtain the Authentication Credential of the KDC
 
    Request:
@@ -2499,7 +2623,7 @@ Table of Contents
        "kdc_cred_verify": POP_EVIDENCE
      }
 
-        Figure 25: Example of KDC Authentication Credential Request-
+        Figure 26: Example of KDC Authentication Credential Request-
         Response to Obtain the Authentication Credential of the KDC
 
 4.6.  /ace-group/GROUPNAME/policies
@@ -2514,9 +2638,10 @@ Table of Contents
    that the Client is a current member of the group.  If the
    verification fails, the KDC MUST reply with a 4.03 (Forbidden) error
    response.  The response MUST have Content-Format set to application/
-   ace-groupcomm+cbor and is formatted as defined in Section 4.  The
-   value of the 'error' field MUST be set to 0 ("Operation permitted
-   only to group members").
+   concise-problem-details+cbor and is formatted as defined in
+   Section 4.1.2.  Within the Custom Problem Detail entry 'ace-
+   groupcomm-error', the value of the 'error-id' field MUST be set to 0
+   ("Operation permitted only to group members").
 
    If all verifications succeed, the handler replies with a 2.05
    (Content) response containing the list of policies for the group
@@ -2536,8 +2661,8 @@ Table of Contents
    policies endpoint at the KDC, where GROUPNAME is the group name, and
    formatted as defined in Section 4.6.1
 
-   Figure 26 gives an overview of the exchange described above, while
-   Figure 27 shows an example.
+   Figure 27 gives an overview of the exchange described above, while
+   Figure 28 shows an example.
 
      Client                                                       KDC
         |                                                          |
@@ -2546,7 +2671,7 @@ Table of Contents
         |<----------- Policies Response: 2.05 (Content) -----------|
         |                                                          |
 
-            Figure 26: Message Flow of Policies Request-Response
+            Figure 27: Message Flow of Policies Request-Response
 
    Request:
 
@@ -2564,7 +2689,7 @@ Table of Contents
    Payload(in CBOR diagnostic notation):
      { "group_policies": {"exp-delta": 120} }
 
-              Figure 27: Example of Policies Request-Response
+              Figure 28: Example of Policies Request-Response
 
 4.7.  /ace-group/GROUPNAME/num
 
@@ -2578,9 +2703,10 @@ Table of Contents
    that the Client is a current member of the group.  If the
    verification fails, the KDC MUST reply with a 4.03 (Forbidden) error
    response.  The response MUST have Content-Format set to application/
-   ace-groupcomm+cbor and is formatted as defined in Section 4.  The
-   value of the 'error' field MUST be set to 0 ("Operation permitted
-   only to group members").
+   concise-problem-details+cbor and is formatted as defined in
+   Section 4.1.2.  Within the Custom Problem Detail entry 'ace-
+   groupcomm-error', the value of the 'error-id' field MUST be set to 0
+   ("Operation permitted only to group members").
 
    If all verifications succeed, the handler returns a 2.05 (Content)
    message containing an integer that represents the version number of
@@ -2601,8 +2727,8 @@ Table of Contents
    every time the group keying material is renewed, before it's
    distributed to the group members.
 
-   Figure 28 gives an overview of the exchange described above, while
-   Figure 29 shows an example.
+   Figure 29 gives an overview of the exchange described above, while
+   Figure 30 shows an example.
 
       Client                                                     KDC
          |                                                        |
@@ -2611,7 +2737,7 @@ Table of Contents
          |<---------- Version Response: 2.05 (Content) -----------|
          |                                                        |
 
-            Figure 28: Message Flow of Version Request-Response
+            Figure 29: Message Flow of Version Request-Response
 
    Request:
 
@@ -2629,7 +2755,7 @@ Table of Contents
    Payload(in CBOR diagnostic notation):
      13
 
-               Figure 29: Example of Version Request-Response
+               Figure 30: Example of Version Request-Response
 
 4.8.  /ace-group/GROUPNAME/nodes/NODENAME
 
@@ -2641,9 +2767,10 @@ Table of Contents
    *  The handler verifies that the Client is a current member of the
       group.  If the verification fails, the KDC MUST reply with a 4.03
       (Forbidden) error response.  The response MUST have Content-Format
-      set to application/ace-groupcomm+cbor and is formatted as defined
-      in Section 4.  The value of the 'error' field MUST be set to 0
-      ("Operation permitted only to group members").
+      set to application/concise-problem-details+cbor and is formatted
+      as defined in Section 4.1.2.  Within the Custom Problem Detail
+      entry 'ace-groupcomm-error', the value of the 'error-id' field
+      MUST be set to 0 ("Operation permitted only to group members").
 
    *  The handler verifies that the node name of the Client is equal to
       NODENAME used in the url-path.  If the verification fails, the
@@ -2661,7 +2788,7 @@ Table of Contents
    defined in the response of Section 4.3.2.  The specific format of
    individual keying material for group members, or of the information
    to derive it, and corresponding CBOR label, MUST be specified in the
-   application profile (REQ27) and registered in Section 11.6.
+   application profile (REQ27) and registered in Section 11.7.
 
    Optionally, the KDC can make the sub-resource at /ace-
    group/GROUPNAME/nodes/NODENAME also Observable [RFC7641] for the
@@ -2740,8 +2867,8 @@ Table of Contents
    case, the Client will receive from the KDC the same group keying
    material it already stores.
 
-   Figure 30 gives an overview of the exchange described above, while
-   Figure 31 shows an example.
+   Figure 31 gives an overview of the exchange described above, while
+   Figure 32 shows an example.
 
     Client                                                          KDC
        |                                                             |
@@ -2751,7 +2878,7 @@ Table of Contents
        |<-------- Key Distribution Response: 2.05 (Content) ---------|
        |                                                             |
 
-        Figure 30: Message Flow of Key Distribution Request-Response
+        Figure 31: Message Flow of Key Distribution Request-Response
 
    Request:
 
@@ -2773,7 +2900,7 @@ Table of Contents
             for individual keying material):
      { "gkty": 13, "key": KEY, "num": 12, "ind-key": IND_KEY }
 
-          Figure 31: Example of Key Distribution Request-Response
+          Figure 32: Example of Key Distribution Request-Response
 
 4.8.2.  PUT Handler
 
@@ -2788,16 +2915,18 @@ Table of Contents
    consistent with the set of roles that the Client has in the group
    (REQ11).  If the verification fails, the KDC MUST reply with a 4.00
    (Bad Request) error response.  The response MUST have Content-Format
-   set to application/ace-groupcomm+cbor and is formatted as defined in
-   Section 4.  The value of the 'error' field MUST be set to 1 ("Request
-   inconsistent with the current roles").
+   set to application/concise-problem-details+cbor and is formatted as
+   defined in Section 4.1.2.  Within the Custom Problem Detail entry
+   'ace-groupcomm-error', the value of the 'error-id' field MUST be set
+   to 1 ("Request inconsistent with the current roles").
 
    If the KDC is currently not able to serve this request, i.e., to
    generate new individual keying material for the requesting Client,
    the KDC MUST reply with a 5.03 (Service Unavailable) error response.
-   The response MUST have Content-Format set to application/ace-
-   groupcomm+cbor and is formatted as defined in Section 4.  The value
-   of the 'error' field MUST be set to 4 ("No available node
+   The response MUST have Content-Format set to application/concise-
+   problem-details+cbor and is formatted as defined in Section 4.1.2.
+   Within the Custom Problem Detail entry 'ace-groupcomm-error', the
+   value of the 'error-id' field MUST be set to 4 ("No available node
    identifiers").
 
    If all verifications succeed, the handler replies with a 2.05
@@ -2806,7 +2935,7 @@ Table of Contents
    a CBOR map.  The specific format of newly-generated individual keying
    material for group members, or of the information to derive it, and
    corresponding CBOR label, MUST be specified in the application
-   profile (REQ27) and registered in Section 11.6.
+   profile (REQ27) and registered in Section 11.7.
 
    The typical successful outcome consists in replying with newly
    generated, individual keying material for the Client, as defined
@@ -2849,8 +2978,8 @@ Table of Contents
    is the group name and NODENAME is its node name, and formatted as
    defined in Section 4.8.1.
 
-   Figure 32 gives an overview of the exchange described above, while
-   Figure 33 shows an example.
+   Figure 33 gives an overview of the exchange described above, while
+   Figure 34 shows an example.
 
        Client                                                    KDC
           |                                                       |
@@ -2860,7 +2989,7 @@ Table of Contents
           |<-------- Key Renewal Response: 2.05 (Content) --------|
           |                                                       |
 
-          Figure 32: Message Flow of Key Renewal Request-Response
+          Figure 33: Message Flow of Key Renewal Request-Response
 
    Request:
 
@@ -2881,7 +3010,7 @@ Table of Contents
             label for individual keying material):
      { "ind-key": IND_KEY }
 
-             Figure 33: Example of Key Renewal Request-Response
+             Figure 34: Example of Key Renewal Request-Response
 
    Note that there is a difference between the Key Renewal Request in
    this section and the Key Distribution Request in Section 4.8.1.1.
@@ -2906,9 +3035,10 @@ Table of Contents
    that the Client is a current member of the group.  If the
    verification fails, the KDC MUST reply with a 4.03 (Forbidden) error
    response.  The response MUST have Content-Format set to application/
-   ace-groupcomm+cbor and is formatted as defined in Section 4.  The
-   value of the 'error' field MUST be set to 0 ("Operation permitted
-   only to group members").
+   concise-problem-details+cbor and is formatted as defined in
+   Section 4.1.2.  Within the Custom Problem Detail entry 'ace-
+   groupcomm-error', the value of the 'error-id' field MUST be set to 0
+   ("Operation permitted only to group members").
 
    If all verification succeeds, the handler performs the actions
    defined in Section 5 and replies with a 2.02 (Deleted) response with
@@ -2953,7 +3083,7 @@ Table of Contents
    Client and specified in the parameter 'client_cred' of this request.
 
    An example of PoP input to compute 'client_cred_verify' using CBOR
-   encoding is given in Figure 34.
+   encoding is given in Figure 35.
 
    It is REQUIRED of the application profiles to define the specific
    formats of authentication credentials that are acceptable to use in
@@ -2964,9 +3094,10 @@ Table of Contents
    consistent with the set of roles that the node has in the group.  If
    the verification fails, the KDC MUST reply with a 4.00 (Bad Request)
    error response.  The response MUST have Content-Format set to
-   application/ace-groupcomm+cbor and is formatted as defined in
-   Section 4.  The value of the 'error' field MUST be set to 1 ("Request
-   inconsistent with the current roles").
+   application/concise-problem-details+cbor and is formatted as defined
+   in Section 4.1.2.  Within the Custom Problem Detail entry 'ace-
+   groupcomm-error', the value of the 'error-id' field MUST be set to 1
+   ("Request inconsistent with the current roles").
 
    If the KDC cannot retrieve the 'kdcchallenge' associated with this
    Client (see Section 3.3), the KDC MUST reply with a 4.00 (Bad
@@ -2986,10 +3117,11 @@ Table of Contents
    group, and is aligned with the possible associated parameters used in
    the group.  If that cannot be successfully verified, the handler MUST
    reply with a 4.00 (Bad Request) error response.  The response MUST
-   have Content-Format set to application/ace-groupcomm+cbor and is
-   formatted as defined in Section 4.  The value of the 'error' field
-   MUST be set to 2 ("Authentication Credential incompatible with the
-   group configuration").
+   have Content-Format set to application/concise-problem-details+cbor
+   and is formatted as defined in Section 4.1.2.  Within the Custom
+   Problem Detail entry 'ace-groupcomm-error', the value of the 'error-
+   id' field MUST be set to 2 ("Authentication credential incompatible
+   with the group configuration").
 
    Otherwise, the handler verifies the PoP evidence contained in the
    'client_cred_verify' field of the request, by using the
@@ -2998,9 +3130,10 @@ Table of Contents
    specific application profile (REQ14).  If the PoP evidence does not
    pass verification, the handler MUST reply with a 4.00 (Bad Request)
    error response.  The response MUST have Content-Format set to
-   application/ace-groupcomm+cbor and is formatted as defined in
-   Section 4.  The value of the 'error' field MUST be set to 3 ("Invalid
-   Proof-of-Possession evidence").
+   application/concise-problem-details+cbor and is formatted as defined
+   in Section 4.1.2.  Within the Custom Problem Detail entry 'ace-
+   groupcomm-error', the value of the 'error-id' field MUST be set to 3
+   ("Invalid Proof-of-Possession evidence").
 
    If all verifications succeed, the handler performs the following
    actions.
@@ -3034,7 +3167,7 @@ Table of Contents
      0x4f 826667726f7570316673656e646572
        48 018a278f7faab55a 48 0446baefc56111bf
 
-      Figure 34: Example of PoP input to compute 'client_cred_verify'
+      Figure 35: Example of PoP input to compute 'client_cred_verify'
                             using CBOR encoding
 
 4.9.1.1.  Uploading a Authentication Credential Key
@@ -3052,8 +3185,8 @@ Table of Contents
 
    The request is formatted as specified in Section 4.9.1.
 
-   Figure Figure 35 gives an overview of the exchange described above,
-   while Figure 36 shows an example.
+   Figure Figure 36 gives an overview of the exchange described above,
+   while Figure 37 shows an example.
 
     Client                                                          KDC
     |                                                                |
@@ -3063,7 +3196,7 @@ Table of Contents
     |<-- Authentication Credential Update Response: 2.04 (Changed) --|
     |                                                                |
 
-        Figure 35: Message Flow of Authentication Credential Update
+        Figure 36: Message Flow of Authentication Credential Update
                               Request-Response
 
    Request:
@@ -3086,7 +3219,7 @@ Table of Contents
    Header: Changed (Code=2.04)
    Payload: -
 
-      Figure 36: Example of Authentication Credential Update Request-
+      Figure 37: Example of Authentication Credential Update Request-
                                   Response
 
    Additionally, after updating its own authentication credential, a
@@ -3105,7 +3238,13 @@ Table of Contents
    1.  The Client explicitly asks to leave the group, as defined in
        Section 4.8.3.1.
 
-   2.  The node has been found compromised or is suspected so.
+   2.  The node has been found compromised or is suspected so.  The KDC
+       is expected to determine that a group member has to be evicted
+       either through its own means, or based on information that it
+       obtains from a trusted source (e.g., an Intrusion Detection
+       System, or an issuer of authentication credentials).  Additional
+       mechanics, protocols, and interfaces at the KDC that can support
+       this are out of the scope of this document.
 
    3.  The Client's authorization to be a group member with the current
        roles is not valid anymore, i.e., the access token has expired or
@@ -3120,7 +3259,7 @@ Table of Contents
 
    *  In case of forced eviction, i.e., for cases 2 and 3 above, the KDC
       deletes the authentication credential of the removed Client, if it
-      acts as repository of authentication credentials for group
+      acts as a repository of authentication credentials for group
       members.
 
    *  If the removed Client is registered as an observer of the group-
@@ -3146,10 +3285,11 @@ Table of Contents
          observed resource has been deleted (see Section 3.2 of
          [RFC7641]).
 
-         The response MUST have Content-Format set to application/ace-
-         groupcomm+cbor and is formatted as defined in Section 4.  The
-         value of the 'error' field MUST be set to 5 ("Group membership
-         terminated").
+         The response MUST have Content-Format set to application/
+         concise-problem-details+cbor and is formatted as defined in
+         Section 4.1.2.  Within the Custom Problem Detail entry 'ace-
+         groupcomm-error', the value of the 'error-id' field MUST be set
+         to 5 ("Group membership terminated").
 
    *  If the application requires forward security or the used
       application profile requires so, the KDC MUST generate new group
@@ -3169,7 +3309,15 @@ Table of Contents
    The KDC can perform a group rekeying before the current group keying
    material expires, unless it is acceptable or there are reasons to
    temporarily pause secure communications in the group, following the
-   expiration of the current keying material.
+   expiration of the current keying material.  For example, a pause in
+   the group communication might have been scheduled to start anyway
+   when the group keying material expires, e.g., to allow maintenance
+   operations on the group members.  As another example, the KDC might
+   be carrying out a verification that some group members are seemingly
+   compromised and to be evicted, and this requires to be completed in
+   order to appropriately define and schedule the exact rekeying process
+   to perform.  As a result, the KDC could delay the execution of the
+   group rekeying.
 
    The KDC MUST increment the version number NUM of the current keying
    material, before distributing the newly generated keying material
@@ -3198,8 +3346,8 @@ Table of Contents
    the rekeying scheme used in the group, the reason that has triggered
    the rekeying process, and the specific target group members.  In
    particular, if the group rekeying is performed due to one or multiple
-   Clients that have joined the group and the KDC acts as repository of
-   authentication credentials of the group members, then a rekeying
+   Clients that have joined the group and the KDC acts as a repository
+   of authentication credentials of the group members, then a rekeying
    message MAY also include the authentication credentials that those
    Clients use in the group, together with the roles and node identifier
    that the corresponding Client has in the group.  It is RECOMMENDED to
@@ -3226,12 +3374,12 @@ Table of Contents
 
 6.1.  Point-to-Point Group Rekeying
 
-   This approach consists in the KDC sending one individual rekeying
-   message to each target group member.  In particular, the rekeying
-   message is protected by means of the security association between the
-   KDC and the target group member in question, as per the used
-   application profile of this specification and the used transport
-   profile of ACE.
+   A point-to-point group rekeying consists in the KDC sending one
+   individual rekeying message to each target group member.  In
+   particular, the rekeying message is protected by means of the
+   security association between the KDC and the target group member in
+   question, as per the used application profile of this specification
+   and the used transport profile of ACE.
 
    This is the approach taken by the basic "Point-to-Point" group
    rekeying scheme, that the KDC can explicitly signal in the Join
@@ -3253,9 +3401,10 @@ Table of Contents
       above also allows the KDC to send an unsolicited 4.04 (Not Found)
       response to each observer group member, as a notification of group
       termination.  The response MUST have Content-Format set to
-      application/ace-groupcomm+cbor and is formatted as defined in
-      Section 4.  The value of the 'error' field MUST be set to 6
-      ("Group deleted").
+      application/concise-problem-details+cbor and is formatted as
+      defined in Section 4.1.2.  Within the Custom Problem Detail entry
+      'ace-groupcomm-error', the value of the 'error-id' field MUST be
+      set to 6 ("Group deleted").
 
    *  If a target group member specified a URI in the 'control_uri'
       parameter of the Join Request upon joining the group (see
@@ -3278,6 +3427,50 @@ Table of Contents
    group/GROUPNAME/nodes/NODENAME (see Section 4.3.2 and Section 4.8.1,
    respectively).
 
+   Figure Figure 38 provides an example of point-to-point group
+   rekeying.  In particular, the example makes the following
+   assumptions.
+
+   *  The group currently consists of four group members, namely C1, C2,
+      C3, and C4.
+
+   *  Each group member, when joining the group, provided the KDC with a
+      URI in the 'control_uri' parameter, with url-path "grp-rek".
+
+   *  Before the group rekeying is performed, the keying material used
+      in the group has version number num=5.
+
+   *  The KDC performs the group rekeying in such a way to evict the
+      group member C3, which has been found to be compromised.
+
+   In the example, the KDC individually rekeys the group members
+   intended to remain in the group (i.e., C1, C2, and C4), by means of
+   one rekeying message each.
+
+      .----------------------------------------------------------------.
+      |                              KDC                               |
+      '----------------------------------------------------------------'
+            |                 |                                    |
+   Group    |        Group    |                           Group    |
+   keying   |        keying   |                           keying   |
+   material |        material |                           material |
+   (num=6)  |        (num=6)  |                           (num=6)  |
+            |                 |                                    |
+            |                 |                                    |
+            |                 |                                    |
+            v                 v                                    v
+
+        /grp-rek          /grp-rek          /grp-rek           /grp-rek
+       .--------.        .--------.        .--------.         .--------.
+       |   C1   |        |   C2   |        |   C3   |         |   C4   |
+       '--------'        '--------'        '--------'         '--------'
+                                         [TO BE EVICTED]
+       |                                                               |
+       \____________ Stored group keying material (num=5) _____________/
+
+       Figure 38: Example of Message Exchanges for a Point-to-Point
+                              Group Rekeying
+
 6.2.  One-to-Many Group Rekeying
 
    This section provides high-level recommendations on how the KDC can
@@ -3335,7 +3528,7 @@ Table of Contents
       (see Section 6.1).
 
    *  Through a pub-sub communication model - In this case, the KDC acts
-      as publisher and publishes each rekeying message to a specific
+      as a publisher and publishes each rekeying message to a specific
       "rekeying topic", which is associated with the group and is hosted
       at a broker server.  Following their group joining, the group
       members subscribe to the rekeying topic at the broker, thus
@@ -3386,18 +3579,88 @@ Table of Contents
    Further details depend on the specific rekeying scheme used in the
    group.
 
+   Figure Figure 39 provides an example of one-to-many group rekeying
+   over multicast.  In particular, the example makes the following
+   assumptions.
+
+   *  The group currently consists of four group members, namely C1, C2,
+      C3, and C4.
+
+   *  Each group member, when joining the group, provided the KDC with a
+      URI in the 'control_uri' parameter, with url-path "grp-rek".
+
+   *  Each group member, when joining the group, received from the KDC a
+      URI in the 'control_group_uri' parameter, specifying the multicast
+      address MULT_ADDR and url-path "grp-mrek".
+
+   *  Before the group rekeying is performed, the keying material used
+      in the group has version number num=5.
+
+   *  The KDC performs the group rekeying in such a way to evict the
+      group member C3, which has been found to be compromised.
+
+   In the example, the KDC determines that the most convenient way to
+   perform a group rekeying that evicts C3 is as follows.
+
+   First, the KDC sends one rekeying message over multicast, to the
+   multicast address MULT_ADDR and the url-path "grp-mrek".  In the
+   figure, the message is denoted with dashed lines.  The message is
+   protected with a non-compromised key from the administrative keying
+   material that only C1 and C2 store.  Therefore, even though all the
+   group members receive this message, only C1 and C2 are able to
+   decrypt it.  The message includes: the new group keying material with
+   version number num=6; and new keys from the administrative keying
+   material to replace those stored by the group members C1, C2, and C3.
+
+   After that, the KDC sends one rekeying message addressed individually
+   to C4 and with url-path "grp-rek".  In the figure, the message is
+   denoted with a dotted line.  The message is protected with the secure
+   association shared between C4 and the KDC.  The message includes: the
+   new group keying material with version number num=6; and new keys
+   from the administrative keying material to replace those stored by
+   both C4 and C3.
+
+ .---------------------------------------------------------------------.
+ |                               KDC                                   |
+ '---------------------------------------------------------------------'
+                                  |                                 :
+ * Group keying material (num=6)  |       * Group keying            :
+ * Updated administrative         |         material (num=6)        :
+   keying material for C1 and C2  |       * Updated administrative  :
+                                  |         keying material for C4  :
+                                  |                                 :
+                                  |                                 :
+       +------------+-------------+--------------+                  :
+       |            |             |              |                  :
+       |            |             |              |                  :
+       v            v             v              v                  v
+
+  /grp-mrek    /grp-mrek    /grp-mrek       /grp-mrek          /grp-rek
+ .--------.   .--------.   .-----------.   .---------------------------.
+ |   C1   |   |   C2   |   |     C3    |   |            C4             |
+ '--------'   '--------'   '-----------'   '---------------------------'
+                          [TO BE EVICTED]
+ |                                                                     |
+ \_______________ Stored group keying material (num=5) ________________/
+
+    Figure 39: Example of Message Exchanges for a One-to-Many Group
+                                Rekeying
+
 6.2.1.  Protection of Rekeying Messages
 
    When using a group rekeying scheme relying on one-to-many rekeying
    messages, the actual data content of each rekeying message is
    prepared according to what the rekeying scheme prescribes.
 
-   Then, the KDC can protect the rekeying message as defined below.  The
-   used encryption algorithm which SHOULD be the same one used to
-   protect communications in the group.  The method defined below
-   assumes that the following holds for the management keying material
-   specified in the 'mgt_key_material' parameter of the Join Response
-   (see Section 4.3.1).
+   The following describes one possible method for the KDC to protect
+   the rekeying messages.
+
+   The method assumes that the following holds for the management keying
+   material specified in the 'mgt_key_material' parameter of the Join
+   Response (see Section 4.3.1).
+
+   *  The encryption algorithm SHOULD be the same one used to protect
+      communications in the group.
 
    *  The included symmetric encryption keys are accompanied by a
       corresponding and unique key identifier assigned by the KDC.
@@ -3571,9 +3834,11 @@ Table of Contents
    The resulting tagged CBOR byte string is used as value of the 'scope'
    claim of the access token.
 
-   Figure 37 and Figure 38 build on the examples in Section 3.2, and
+   Figure 40 and Figure 41 build on the examples in Section 3.2, and
    show the corresponding extended scopes.
 
+   ;# include rfc9237
+
    gname = tstr
 
    permissions = uint .bits roles
@@ -3585,13 +3850,15 @@ Table of Contents
       Verifier: 4
    )
 
-   scope_entry = AIF_Generic<gname, permissions>
+   scope_entry = AIF-Generic<gname, permissions>
+
+   scope_entries = [ + scope_entry ]
 
-   scope = << [ + scope_entry ] >>
+   scope = bstr .cbor scope_entries
 
    extended_scope = #6.TAG_FOR_THIS_SEMANTICS(scope)
 
-       Figure 37: Example CDLL definition of scope, using the default
+       Figure 40: Example CDLL definition of scope, using the default
                       Authorization Information Format
 
    gname = tstr
@@ -3600,11 +3867,13 @@ Table of Contents
 
    scope_entry = [ gname , ? ( role / [ 2*role ] ) ]
 
-   scope = << [ + scope_entry ] >>
+   scope_entries = [ + scope_entry ]
+
+   scope = bstr .cbor scope_entries
 
    extended_scope = #6.TAG_FOR_THIS_SEMANTICS(scope)
 
-      Figure 38: CDLL definition of scope, using as example group name
+      Figure 41: CDLL definition of scope, using as example group name
                       encoded as tstr and role as tstr
 
    The usage of the extended scope format is not limited to application
@@ -3647,10 +3916,6 @@ Table of Contents
     | Name                  | CBOR | CBOR Type           | Reference  |
     |                       | Key  |                     |            |
     +-----------------------+------+---------------------+------------+
-    | error                 | TBD  | int                 | [RFC-XXXX] |
-    +-----------------------+------+---------------------+------------+
-    | error_description     | TBD  | tstr                | [RFC-XXXX] |
-    +-----------------------+------+---------------------+------------+
     | gid                   | TBD  | array               | [RFC-XXXX] |
     +-----------------------+------+---------------------+------------+
     | gname                 | TBD  | array of tstr       | [RFC-XXXX] |
@@ -3682,7 +3947,7 @@ Table of Contents
     +-----------------------+------+---------------------+------------+
     | ace_groupcomm_profile | TBD  | int                 | [RFC-XXXX] |
     +-----------------------+------+---------------------+------------+
-    | exp                   | TBD  | int                 | [RFC-XXXX] |
+    | exp                   | TBD  | uint                | [RFC-XXXX] |
     +-----------------------+------+---------------------+------------+
     | creds                 | TBD  | array               | [RFC-XXXX] |
     +-----------------------+------+---------------------+------------+
@@ -3709,9 +3974,9 @@ Table of Contents
     | kdcchallenge          | TBD  | bstr                | [RFC-XXXX] |
     +-----------------------+------+---------------------+------------+
 
-                    Figure 39: ACE Groupcomm Parameters
+                    Figure 42: ACE Groupcomm Parameters
 
-   Note to RFC Editor: In Figure 39, please replace all occurrences of
+   Note to RFC Editor: In Figure 42, please replace all occurrences of
    "[RFC-XXXX]" with the RFC number of this specification and delete
    this paragraph.
 
@@ -3749,12 +4014,6 @@ Table of Contents
       authentication credentials of all group members (see
       Section 4.4.2.1).
 
-   A Client MAY support the following optional parameters.  Application
-   profiles of this specification MAY define that Clients must or should
-   support these parameters instead (OPT15).
-
-   *  'error', 'error_description'.
-
    The following conditional parameters are relevant only if specific
    conditions hold.  It is REQUIRED of application profiles of this
    specification to define whether Clients must, should, or may support
@@ -3806,9 +4065,11 @@ Table of Contents
 
 9.  ACE Groupcomm Error Identifiers
 
-   This specification defines a number of values that the KDC can
-   include as error identifiers, in the 'error' field of an error
-   response with Content-Format application/ace-groupcomm+cbor.
+   This specification defines a number of values that the KDC can use as
+   error identifiers.  These are used in error responses with Content-
+   Format application/concise-problem-details+cbor, as values of the
+   'error-id' field within the Custom Problem Detail entry 'ace-
+   groupcomm-error' (see Section 4.1.2).
 
           +-------+---------------------------------------------+
           | Value |                 Description                 |
@@ -3829,13 +4090,16 @@ Table of Contents
           |   6   | Group deleted                               |
           +-------+---------------------------------------------+
 
-                 Figure 40: ACE Groupcomm Error Identifiers
+                 Figure 43: ACE Groupcomm Error Identifiers
 
-   A Client supporting the 'error' parameter (see Section 4.1.2 and
-   Section 8) and able to understand the specified error may use that
-   information to determine what actions to take next.  If it is
-   included in the error response and supported by the Client, the
-   'error_description' parameter may provide additional context.
+   If a Client supports the problem-details format [RFC9290] and the
+   Custom Problem Detail entry 'ace-groupcomm-error' defined in
+   Section 4.1.2, and is able to understand the error specified in the
+   'error-id' field therein, then the Client may use that information to
+   determine what actions to take next.  If the Concise Problem Details
+   data item specified in the error response includes the 'detail' entry
+   and the Client supports it, such an entry may provide additional
+   context.
 
    In particular, the following guidelines apply, and application
    profiles of this specification can define more detailed actions for
@@ -3889,6 +4153,10 @@ Table of Contents
    [RFC9200], and from the specific transport profile of ACE used
    between the Clients and the KDC, e.g., [RFC9202] and [RFC9203].
 
+   When using the problem-details format defined in [RFC9290] for error
+   responses, then the privacy and security considerations from Sections
+   4 and 5 of [RFC9290] also apply.
+
    Furthermore, the following security considerations apply.
 
 10.1.  Secure Communication in the Group
@@ -3903,7 +4171,7 @@ Table of Contents
    that sender.
 
    By its nature, the KDC is invested with a large amount of trust,
-   since it acts as generator and provider of the symmetric keying
+   since it acts as a generator and provider of the symmetric keying
    material used to protect communications in each of its groups.  While
    details depend on the specific communication and security protocols
    used in the group, the KDC is in the position to decrypt messages
@@ -3946,12 +4214,19 @@ Table of Contents
 
    Unless otherwise defined by an application profile of this
    specification, the KDC SHOULD renew the group keying material upon a
-   group membership change.  In particular, since the minimum number of
-   group members is one, the KDC SHOULD provide even a Client joining an
-   empty group with new keying material never used before in that group.
-   Similarly, the KDC SHOULD provide new group keying material also to a
-   Client that remains the only member in the group after the leaving of
-   other group members.
+   group membership change.  As a possible exception, the KDC may not
+   rekey the group upon the joining of a new group member, if the
+   application does not require backward security.  As another possible
+   exception discussed more in detail later in this section, the KDC may
+   rely on a rekeying policy that reasonably take into account the
+   expected rate of group membership changes and the duration of a group
+   rekeying.
+
+   Since the minimum number of group members is one, the KDC SHOULD
+   provide even a Client joining an empty group with new keying material
+   never used before in that group.  Similarly, the KDC SHOULD provide
+   new group keying material also to a Client that remains the only
+   member in the group after the leaving of other group members.
 
    Note that the considerations in Section 10.1 about dealing with
    replayed messages still hold, even in case the KDC rekeys the group
@@ -4108,9 +4383,9 @@ Table of Contents
    IANA is asked to register the following entry to the "CoAP Content-
    Formats" registry within the "CoRE Parameters" registry group.
 
-   Media Type: application/ace-groupcomm+cbor
+   Content Type: application/ace-groupcomm+cbor
 
-   Encoding: -
+   Content Coding: -
 
    ID: TBD
 
@@ -4168,15 +4443,41 @@ Table of Contents
    Description (if=) Link Target Attribute Values" registry within the
    "CoRE Parameters" registry group.
 
-   *  Attribute Value: ace.group
+   *  Value: ace.groups
 
-   *  Description: The 'ace group' interface is used to provision keying
-      material and related information and policies to members of a
-      group using the ACE framework.
+   *  Description: The KDC interface at the parent resource of group-
+      membership resources is used to retrieve names of security groups
+      using the ACE framework.
 
-   *  Reference: [RFC-XXXX]
+   *  Reference: Section 4.1 of [RFC-XXXX]
 
-11.6.  ACE Groupcomm Parameters
+
+   *  Value: ace.group
+
+   *  Description: The KDC interface at a group-membership resource is
+      used to provision keying material and related information and
+      policies to members of the corresponding security group using the
+      ACE framework.
+
+   *  Reference: Section 4.1 of [RFC-XXXX]
+
+11.6.  Custom Problem Detail Keys Registry
+
+   IANA is asked to register the following entry in the "Custom Problem
+   Detail Keys" registry within the "CoRE Parameters" registry group.
+
+   *  Key Value: TBD
+
+   *  Name: ace-groupcomm-error
+
+   *  Brief Description: Carry [RFC-XXXX] problem details in a Concise
+      Problem Details data item.
+
+   *  Change Controller: IETF
+
+   *  Reference: Section 4.1.2 of [RFC-XXXX]
+
+11.7.  ACE Groupcomm Parameters
 
    This specification establishes the "ACE Groupcomm Parameters" IANA
    registry within the "Authentication and Authorization for Constrained
@@ -4184,7 +4485,7 @@ Table of Contents
 
    The registry has been created to use the "Expert Review" registration
    procedure [RFC8126].  Expert review guidelines are provided in
-   Section 11.13.  Values in this registry are covered by different
+   Section 11.14.  Values in this registry are covered by different
    registration policies as indicated.  It should be noted that, in
    addition to the expert review, some portions of the registry require
    a specification, potentially a Standards Track RFC, to be supplied as
@@ -4216,9 +4517,9 @@ Table of Contents
       the item.
 
    This registry has been initially populated with the values in
-   Figure 39.
+   Figure 42.
 
-11.7.  ACE Groupcomm Key Types
+11.8.  ACE Groupcomm Key Types
 
    This specification establishes the "ACE Groupcomm Key Types" IANA
    registry within the "Authentication and Authorization for Constrained
@@ -4226,7 +4527,7 @@ Table of Contents
 
    The registry has been created to use the "Expert Review" registration
    procedure [RFC8126].  Expert review guidelines are provided in
-   Section 11.13.  Values in this registry are covered by different
+   Section 11.14.  Values in this registry are covered by different
    registration policies as indicated.  It should be noted that, in
    addition to the expert review, some portions of the registry require
    a specification, potentially a Standards Track RFC, to be supplied as
@@ -4263,9 +4564,9 @@ Table of Contents
       the format of the keying material, if one exists.
 
    This registry has been initially populated with the value in
-   Figure 10.
+   Figure 11.
 
-11.8.  ACE Groupcomm Profiles
+11.9.  ACE Groupcomm Profiles
 
    This specification establishes the "ACE Groupcomm Profiles" IANA
    registry within the "Authentication and Authorization for Constrained
@@ -4273,7 +4574,7 @@ Table of Contents
 
    The registry has been created to use the "Expert Review" registration
    procedure [RFC8126].  Expert review guidelines are provided in
-   Section 11.13.  Values in this registry are covered by different
+   Section 11.14.  Values in this registry are covered by different
    registration policies as indicated.  It should be noted that, in
    addition to the expert review, some portions of the registry require
    a specification, potentially a Standards Track RFC, to be supplied as
@@ -4301,9 +4602,9 @@ Table of Contents
       the abbreviation for this application profile, if one exists.
 
    This registry has been initially populated with the value in
-   Figure 11.
+   Figure 12.
 
-11.9.  ACE Groupcomm Policies
+11.10.  ACE Groupcomm Policies
 
    This specification establishes the "ACE Groupcomm Policies" IANA
    registry within the "Authentication and Authorization for Constrained
@@ -4311,7 +4612,7 @@ Table of Contents
 
    The registry has been created to use the "Expert Review" registration
    procedure [RFC8126].  Expert review guidelines are provided in
-   Section 11.13.  Values in this registry are covered by different
+   Section 11.14.  Values in this registry are covered by different
    registration policies as indicated.  It should be noted that, in
    addition to the expert review, some portions of the registry require
    a specification, potentially a Standards Track RFC, to be supplied as
@@ -4345,9 +4646,9 @@ Table of Contents
       policy, if one exists.
 
    This registry has been initially populated with the values in
-   Figure 12.
+   Figure 13.
 
-11.10.  Sequence Number Synchronization Methods
+11.11.  Sequence Number Synchronization Methods
 
    This specification establishes the "Sequence Number Synchronization
    Methods" IANA registry within the "Authentication and Authorization
@@ -4355,7 +4656,7 @@ Table of Contents
 
    The registry has been created to use the "Expert Review" registration
    procedure [RFC8126].  Expert review guidelines are provided in
-   Section 11.13.  Values in this registry are covered by different
+   Section 11.14.  Values in this registry are covered by different
    registration policies as indicated.  It should be noted that, in
    addition to the expert review, some portions of the registry require
    a specification, potentially a Standards Track RFC, to be supplied as
@@ -4385,7 +4686,7 @@ Table of Contents
       specification describing the sequence number synchronization
       method.
 
-11.11.  ACE Groupcomm Errors
+11.12.  ACE Groupcomm Errors
 
    This specification establishes the "ACE Groupcomm Errors" IANA
    registry within the "Authentication and Authorization for Constrained
@@ -4393,7 +4694,7 @@ Table of Contents
 
    The registry has been created to use the "Expert Review" registration
    procedure [RFC8126].  Expert review guidelines are provided in
-   Section 11.13.  Values in this registry are covered by different
+   Section 11.14.  Values in this registry are covered by different
    registration policies as indicated.  It should be noted that, in
    addition to the expert review, some portions of the registry require
    a specification, potentially a Standards Track RFC, to be supplied as
@@ -4417,10 +4718,10 @@ Table of Contents
       specification defining the error, if one exists.
 
    This registry has been initially populated with the values in
-   Figure 40.  The Reference column for all of these entries refers to
+   Figure 43.  The Reference column for all of these entries refers to
    this document.
 
-11.12.  ACE Groupcomm Rekeying Schemes
+11.13.  ACE Groupcomm Rekeying Schemes
 
    This specification establishes the "ACE Groupcomm Rekeying Schemes"
    IANA registry within the "Authentication and Authorization for
@@ -4428,7 +4729,7 @@ Table of Contents
 
    The registry has been created to use the "Expert Review" registration
    procedure [RFC8126].  Expert review guidelines are provided in
-   Section 11.13.  Values in this registry are covered by different
+   Section 11.14.  Values in this registry are covered by different
    registration policies as indicated.  It should be noted that, in
    addition to the expert review, some portions of the registry require
    a specification, potentially a Standards Track RFC, to be supplied as
@@ -4455,9 +4756,9 @@ Table of Contents
       specification defining the group rekeying scheme, if one exists.
 
    This registry has been initially populated with the value in
-   Figure 13.
+   Figure 14.
 
-11.13.  Expert Review Instructions
+11.14.  Expert Review Instructions
 
    The IANA Registries established in this document are defined as
    expert review.  This section gives some general guidelines for what
@@ -4533,6 +4834,10 @@ Table of Contents
               DOI 10.17487/RFC2119, March 1997,
               <https://www.rfc-editor.org/rfc/rfc2119>.
 
+   [RFC6690]  Shelby, Z., "Constrained RESTful Environments (CoRE) Link
+              Format", RFC 6690, DOI 10.17487/RFC6690, August 2012,
+              <https://www.rfc-editor.org/rfc/rfc6690>.
+
    [RFC6749]  Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
               RFC 6749, DOI 10.17487/RFC6749, October 2012,
               <https://www.rfc-editor.org/rfc/rfc6749>.
@@ -4597,6 +4902,11 @@ Table of Contents
               Environments (ACE)", RFC 9237, DOI 10.17487/RFC9237,
               August 2022, <https://www.rfc-editor.org/rfc/rfc9237>.
 
+   [RFC9290]  Fossati, T. and C. Bormann, "Concise Problem Details for
+              Constrained Application Protocol (CoAP) APIs", RFC 9290,
+              DOI 10.17487/RFC9290, October 2022,
+              <https://www.rfc-editor.org/rfc/rfc9290>.
+
    [RFC9338]  Schaad, J., "CBOR Object Signing and Encryption (COSE):
               Countersignatures", STD 96, RFC 9338,
               DOI 10.17487/RFC9338, December 2022,
@@ -4812,7 +5122,7 @@ A.1.  Mandatory-to-Address Requirements
       use between Client and KDC (see Section 4.3.1.1).
 
    *  REQ25: Specify the format of the identifiers of group members (see
-      Section 4.3.1).
+      Section 4.3.1 and Section 4.4.1).
 
    *  REQ26: Specify policies at the KDC to handle ids that are not
       included in 'get_creds' (see Section 4.4.1).
@@ -4849,7 +5159,8 @@ A.2.  Optional-to-Address Requirements
       specific error cases.
 
    *  OPT5: Optionally, specify additional identifiers of error types,
-      as values of the 'error' field in an error response from the KDC.
+      as values of the 'error-id' field within the Custom Problem Detail
+      entry 'ace-groupcomm-error' (see Section 4.1.2).
 
    *  OPT6: Optionally, specify the encoding of 'creds_repo' if the
       default is not used (see Section 4.3.1).
@@ -4887,10 +5198,6 @@ A.2.  Optional-to-Address Requirements
       rekeying messages for the "Point-to-Point" group rekeying scheme
       (see Section 6).
 
-   *  OPT15: Optionally, specify if Clients must or should support any
-      of the parameters defined as optional in this specification (see
-      Section 8).
-
 Appendix B.  Extensibility for Future COSE Algorithms
 
    As defined in Section 8.1 of [RFC9053], future algorithms can be
@@ -4948,7 +5255,7 @@ B.1.  Format of 'sign_info_entry'
 
    gname = tstr
 
-              Figure 41: 'sign_info_entry' with general format
+              Figure 44: 'sign_info_entry' with general format
 
 Appendix C.  Document Updates
 
@@ -4956,13 +5263,59 @@ Appendix C.  Document Updates
 
 C.1.  Version -17 to -18
 
-   *  Consistent use of leading slash in URI paths.
+   *  Provided more details when early introducing "backward security"
+      and "forward security".
+
+   *  Clarified definition and semantics of "group name" and "node
+      name".
+
+   *  Clarified definition of "individual keying material".
+
+   *  Clarified definition of "Dispatcher".
+
+   *  Enforced consistent use of leading slash in URI paths.
+
+   *  Fixed CDDL definitions and examples in CBOR diagnostic notation.
+
+   *  RFC 9290 is used instead of the custom format for error responses.
+
+   *  Clarified which operations are limited to group members and which
+      are allowed also to non group members.
+
+   *  Improved examples of message exchange.
+
+   *  Added ASCII-art diagrams with examples of group rekeying.
+
+   *  Clarified for how long nonces are stored at the KDC.
+
+   *  Clarified that the KDC might not have to store the 'cnonce' from a
+      Join Request.
 
    *  Consistency fix: Clients always support the 'cnonce' parameter.
 
-   *  The KDC might not have to store the 'cnonce' from a Join Request.
+   *  Added new parameter 'exi' providing the residual lifetime of the
+      current group keying material.
 
-   *  Fixes and editorial improvements.
+   *  Clarified text about the KDC knowledge of compromised nodes.
+
+   *  Clarified the impact on performance of a one-to-many group
+      rekeying.
+
+   *  Mentioned explicit exceptions to a group rekeying at each group
+      membership change.
+
+   *  Explained reasons for delaying a rekeying and halting
+      communications.
+
+   *  Fixes in current IANA registrations.
+
+   *  Added integer abbreviation values for registrations in new IANA
+      registries.
+
+   *  IANA registration of two CoRE if= values: "ace.group" and
+      "ace.groups".
+
+   *  Editorial fixes and improvements.
 
 C.2.  Version -16 to -17
 
@@ -5238,10 +5591,11 @@ C.11.  Version -00 to -01
 Acknowledgments
 
    The following individuals were helpful in shaping this document:
-   Christian Amsüss, Carsten Bormann, Rikard Höglund, Ben Kaduk, Warren
-   Kumari, Watson Ladd, John Preuß Mattsson, Daniel Migault, Jim Schaad,
-   Ludwig Seitz, Göran Selander, Cigdem Sengul, Peter van der Stok, and
-   Paul Wouters.
+   Christian Amsüss, Carsten Bormann, Roman Danyliw, Martin Duke, Thomas
+   Fossati, Vidhi Goel, Rikard Höglund, Ben Kaduk, Erik Kline, Warren
+   Kumari, Watson Ladd, John Preuß Mattsson, Daniel Migault,
+   Zaheduzzaman Sarker, Jim Schaad, Ludwig Seitz, Göran Selander, Cigdem
+   Sengul, Henry Thompson, Peter van der Stok, and Paul Wouters.
 
    The work on this document has been partly supported by VINNOVA and
    the Celtic-Next project CRITISEC; by the H2020 project SIFIS-Home