<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" ipr="trust200902" docName="draft-ietf-ace-key-groupcomm-18" number="9594" category="std" consensus="true" submissionType="IETF" updates="" obsoletes="" tocDepth="4" tocInclude="true" sortRefs="true" symRefs="true" xml:lang="en" prepTime="2024-09-13T17:53:05" indexInclude="true" scripts="Common,Latin">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-ace-key-groupcomm-18" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9594" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="Key Provisioning for Group Communication">Key Provisioning for Group Communication Using Authentication and Authorization for Constrained Environments (ACE)</title>
    <seriesInfo name="RFC" value="9594" stream="IETF"/>
    <author initials="F." surname="Palombini" fullname="Francesca Palombini">
      <organization showOnFrontPage="true">Ericsson AB</organization>
      <address>
        <postal>
          <street>Torshamnsgatan 23</street>
          <city>Kista</city>
          <code>164 40</code>
          <country>Sweden</country>
        </postal>
        <email>francesca.palombini@ericsson.com</email>
      </address>
    </author>
    <author initials="M." surname="Tiloca" fullname="Marco Tiloca">
      <organization showOnFrontPage="true">RISE AB</organization>
      <address>
        <postal>
          <street>Isafjordsgatan 22</street>
          <city>Kista</city>
          <code>164 40</code>
          <country>Sweden</country>
        </postal>
        <email>marco.tiloca@ri.se</email>
      </address>
    </author>
    <date month="09" year="2024"/>
    <area>sec</area>
    <workgroup>ace</workgroup>
    <keyword>Key Management</keyword>
    <keyword>Access Control</keyword>
    <keyword>Constrained Application Protocol (CoAP)</keyword>
    <keyword>Secure group communication</keyword>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">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 that act as Clients and are authorized to join a group can do so by interacting with a Key Distribution Center (KDC) acting as the 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.</t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This is an Internet Standards Track document.
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by
            the Internet Engineering Steering Group (IESG).  Further
            information on Internet Standards is available in Section 2 of 
            RFC 7841.
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc9594" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2024 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Revised BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Revised BSD License.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.1.2">
              <li pn="section-toc.1-1.1.2.1">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.1.1"><xref derivedContent="1.1" format="counter" sectionFormat="of" target="section-1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-terminology">Terminology</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-overview">Overview</xref></t>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-authorization-to-join-a-gro">Authorization to Join a Group</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2">
              <li pn="section-toc.1-1.3.2.1">
                <t indent="0" pn="section-toc.1-1.3.2.1.1"><xref derivedContent="3.1" format="counter" sectionFormat="of" target="section-3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-authorization-request">Authorization Request</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.2">
                <t indent="0" pn="section-toc.1-1.3.2.2.1"><xref derivedContent="3.2" format="counter" sectionFormat="of" target="section-3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-authorization-response">Authorization Response</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.3">
                <t indent="0" pn="section-toc.1-1.3.2.3.1"><xref derivedContent="3.3" format="counter" sectionFormat="of" target="section-3.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-token-transferring">Token Transferring</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2.3.2">
                  <li pn="section-toc.1-1.3.2.3.2.1">
                    <t indent="0" pn="section-toc.1-1.3.2.3.2.1.1"><xref derivedContent="3.3.1" format="counter" sectionFormat="of" target="section-3.3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-sign_info-parameter">'sign_info' Parameter</xref></t>
                  </li>
                  <li pn="section-toc.1-1.3.2.3.2.2">
                    <t indent="0" pn="section-toc.1-1.3.2.3.2.2.1"><xref derivedContent="3.3.2" format="counter" sectionFormat="of" target="section-3.3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-kdcchallenge-parameter">'kdcchallenge' Parameter</xref></t>
                  </li>
                </ul>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-kdc-functionalities">KDC Functionalities</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2">
              <li pn="section-toc.1-1.4.2.1">
                <t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent="4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-interface-at-the-kdc">Interface at the KDC</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2.1.2">
                  <li pn="section-toc.1-1.4.2.1.2.1">
                    <t indent="0" pn="section-toc.1-1.4.2.1.2.1.1"><xref derivedContent="4.1.1" format="counter" sectionFormat="of" target="section-4.1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-operations-supported-by-cli">Operations Supported by Clients</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.1.2.2">
                    <t indent="0" pn="section-toc.1-1.4.2.1.2.2.1"><xref derivedContent="4.1.2" format="counter" sectionFormat="of" target="section-4.1.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-error-handling">Error Handling</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.4.2.2">
                <t indent="0" pn="section-toc.1-1.4.2.2.1"><xref derivedContent="4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ace-group">/ace-group</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2.2.2">
                  <li pn="section-toc.1-1.4.2.2.2.1">
                    <t indent="0" pn="section-toc.1-1.4.2.2.2.1.1"><xref derivedContent="4.2.1" format="counter" sectionFormat="of" target="section-4.2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-fetch-handler">FETCH Handler</xref></t>
                    <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2.2.2.1.2">
                      <li pn="section-toc.1-1.4.2.2.2.1.2.1">
                        <t indent="0" pn="section-toc.1-1.4.2.2.2.1.2.1.1"><xref derivedContent="4.2.1.1" format="counter" sectionFormat="of" target="section-4.2.1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-retrieve-group-names">Retrieve Group Names</xref></t>
                      </li>
                    </ul>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.4.2.3">
                <t indent="0" pn="section-toc.1-1.4.2.3.1"><xref derivedContent="4.3" format="counter" sectionFormat="of" target="section-4.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ace-group-groupname">/ace-group/GROUPNAME</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2.3.2">
                  <li pn="section-toc.1-1.4.2.3.2.1">
                    <t indent="0" pn="section-toc.1-1.4.2.3.2.1.1"><xref derivedContent="4.3.1" format="counter" sectionFormat="of" target="section-4.3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-post-handler">POST Handler</xref></t>
                    <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2.3.2.1.2">
                      <li pn="section-toc.1-1.4.2.3.2.1.2.1">
                        <t indent="0" pn="section-toc.1-1.4.2.3.2.1.2.1.1"><xref derivedContent="4.3.1.1" format="counter" sectionFormat="of" target="section-4.3.1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-join-the-group">Join the Group</xref></t>
                      </li>
                    </ul>
                  </li>
                  <li pn="section-toc.1-1.4.2.3.2.2">
                    <t indent="0" pn="section-toc.1-1.4.2.3.2.2.1"><xref derivedContent="4.3.2" format="counter" sectionFormat="of" target="section-4.3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-get-handler">GET Handler</xref></t>
                    <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2.3.2.2.2">
                      <li pn="section-toc.1-1.4.2.3.2.2.2.1">
                        <t indent="0" pn="section-toc.1-1.4.2.3.2.2.2.1.1"><xref derivedContent="4.3.2.1" format="counter" sectionFormat="of" target="section-4.3.2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-retrieve-group-keying-mater">Retrieve Group Keying Material</xref></t>
                      </li>
                    </ul>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.4.2.4">
                <t indent="0" pn="section-toc.1-1.4.2.4.1"><xref derivedContent="4.4" format="counter" sectionFormat="of" target="section-4.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ace-group-groupname-creds">/ace-group/GROUPNAME/creds</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2.4.2">
                  <li pn="section-toc.1-1.4.2.4.2.1">
                    <t indent="0" pn="section-toc.1-1.4.2.4.2.1.1"><xref derivedContent="4.4.1" format="counter" sectionFormat="of" target="section-4.4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-fetch-handler-2">FETCH Handler</xref></t>
                    <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2.4.2.1.2">
                      <li pn="section-toc.1-1.4.2.4.2.1.2.1">
                        <t indent="0" pn="section-toc.1-1.4.2.4.2.1.2.1.1"><xref derivedContent="4.4.1.1" format="counter" sectionFormat="of" target="section-4.4.1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-retrieve-a-subset-of-authen">Retrieve a Subset of Authentication Credentials in the Group</xref></t>
                      </li>
                    </ul>
                  </li>
                  <li pn="section-toc.1-1.4.2.4.2.2">
                    <t indent="0" pn="section-toc.1-1.4.2.4.2.2.1"><xref derivedContent="4.4.2" format="counter" sectionFormat="of" target="section-4.4.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-get-handler-2">GET Handler</xref></t>
                    <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2.4.2.2.2">
                      <li pn="section-toc.1-1.4.2.4.2.2.2.1">
                        <t indent="0" pn="section-toc.1-1.4.2.4.2.2.2.1.1"><xref derivedContent="4.4.2.1" format="counter" sectionFormat="of" target="section-4.4.2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-retrieve-all-authentication">Retrieve All Authentication Credentials in the Group</xref></t>
                      </li>
                    </ul>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.4.2.5">
                <t indent="0" pn="section-toc.1-1.4.2.5.1"><xref derivedContent="4.5" format="counter" sectionFormat="of" target="section-4.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ace-group-groupname-kdc-cre">/ace-group/GROUPNAME/kdc-cred</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2.5.2">
                  <li pn="section-toc.1-1.4.2.5.2.1">
                    <t indent="0" pn="section-toc.1-1.4.2.5.2.1.1"><xref derivedContent="4.5.1" format="counter" sectionFormat="of" target="section-4.5.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-get-handler-3">GET Handler</xref></t>
                    <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2.5.2.1.2">
                      <li pn="section-toc.1-1.4.2.5.2.1.2.1">
                        <t indent="0" pn="section-toc.1-1.4.2.5.2.1.2.1.1"><xref derivedContent="4.5.1.1" format="counter" sectionFormat="of" target="section-4.5.1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-retrieve-the-kdcs-authentic">Retrieve the KDC's Authentication Credential</xref></t>
                      </li>
                    </ul>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.4.2.6">
                <t indent="0" pn="section-toc.1-1.4.2.6.1"><xref derivedContent="4.6" format="counter" sectionFormat="of" target="section-4.6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ace-group-groupname-policie">/ace-group/GROUPNAME/policies</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2.6.2">
                  <li pn="section-toc.1-1.4.2.6.2.1">
                    <t indent="0" pn="section-toc.1-1.4.2.6.2.1.1"><xref derivedContent="4.6.1" format="counter" sectionFormat="of" target="section-4.6.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-get-handler-4">GET Handler</xref></t>
                    <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2.6.2.1.2">
                      <li pn="section-toc.1-1.4.2.6.2.1.2.1">
                        <t indent="0" pn="section-toc.1-1.4.2.6.2.1.2.1.1"><xref derivedContent="4.6.1.1" format="counter" sectionFormat="of" target="section-4.6.1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-retrieve-the-group-policies">Retrieve the Group Policies</xref></t>
                      </li>
                    </ul>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.4.2.7">
                <t indent="0" pn="section-toc.1-1.4.2.7.1"><xref derivedContent="4.7" format="counter" sectionFormat="of" target="section-4.7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ace-group-groupname-num">/ace-group/GROUPNAME/num</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2.7.2">
                  <li pn="section-toc.1-1.4.2.7.2.1">
                    <t indent="0" pn="section-toc.1-1.4.2.7.2.1.1"><xref derivedContent="4.7.1" format="counter" sectionFormat="of" target="section-4.7.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-get-handler-5">GET Handler</xref></t>
                    <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2.7.2.1.2">
                      <li pn="section-toc.1-1.4.2.7.2.1.2.1">
                        <t indent="0" pn="section-toc.1-1.4.2.7.2.1.2.1.1"><xref derivedContent="4.7.1.1" format="counter" sectionFormat="of" target="section-4.7.1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-retrieve-the-keying-materia">Retrieve the Keying Material Version</xref></t>
                      </li>
                    </ul>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.4.2.8">
                <t indent="0" pn="section-toc.1-1.4.2.8.1"><xref derivedContent="4.8" format="counter" sectionFormat="of" target="section-4.8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ace-group-groupname-nodes-n">/ace-group/GROUPNAME/nodes/NODENAME</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2.8.2">
                  <li pn="section-toc.1-1.4.2.8.2.1">
                    <t indent="0" pn="section-toc.1-1.4.2.8.2.1.1"><xref derivedContent="4.8.1" format="counter" sectionFormat="of" target="section-4.8.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-get-handler-6">GET Handler</xref></t>
                    <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2.8.2.1.2">
                      <li pn="section-toc.1-1.4.2.8.2.1.2.1">
                        <t indent="0" pn="section-toc.1-1.4.2.8.2.1.2.1.1"><xref derivedContent="4.8.1.1" format="counter" sectionFormat="of" target="section-4.8.1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-retrieve-group-and-individu">Retrieve Group and Individual Keying Material</xref></t>
                      </li>
                    </ul>
                  </li>
                  <li pn="section-toc.1-1.4.2.8.2.2">
                    <t indent="0" pn="section-toc.1-1.4.2.8.2.2.1"><xref derivedContent="4.8.2" format="counter" sectionFormat="of" target="section-4.8.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-post-handler-2">POST Handler</xref></t>
                    <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2.8.2.2.2">
                      <li pn="section-toc.1-1.4.2.8.2.2.2.1">
                        <t indent="0" pn="section-toc.1-1.4.2.8.2.2.2.1.1"><xref derivedContent="4.8.2.1" format="counter" sectionFormat="of" target="section-4.8.2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-request-to-change-individua">Request to Change Individual Keying Material</xref></t>
                      </li>
                    </ul>
                  </li>
                  <li pn="section-toc.1-1.4.2.8.2.3">
                    <t indent="0" pn="section-toc.1-1.4.2.8.2.3.1"><xref derivedContent="4.8.3" format="counter" sectionFormat="of" target="section-4.8.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-delete-handler">DELETE Handler</xref></t>
                    <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2.8.2.3.2">
                      <li pn="section-toc.1-1.4.2.8.2.3.2.1">
                        <t indent="0" pn="section-toc.1-1.4.2.8.2.3.2.1.1"><xref derivedContent="4.8.3.1" format="counter" sectionFormat="of" target="section-4.8.3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-leave-the-group">Leave the Group</xref></t>
                      </li>
                    </ul>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.4.2.9">
                <t indent="0" pn="section-toc.1-1.4.2.9.1"><xref derivedContent="4.9" format="counter" sectionFormat="of" target="section-4.9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ace-group-groupname-nodes-no">/ace-group/GROUPNAME/nodes/NODENAME/cred</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2.9.2">
                  <li pn="section-toc.1-1.4.2.9.2.1">
                    <t indent="0" pn="section-toc.1-1.4.2.9.2.1.1"><xref derivedContent="4.9.1" format="counter" sectionFormat="of" target="section-4.9.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-post-handler-3">POST Handler</xref></t>
                    <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2.9.2.1.2">
                      <li pn="section-toc.1-1.4.2.9.2.1.2.1">
                        <t indent="0" pn="section-toc.1-1.4.2.9.2.1.2.1.1"><xref derivedContent="4.9.1.1" format="counter" sectionFormat="of" target="section-4.9.1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-uploading-an-authentication">Uploading an Authentication Credential</xref></t>
                      </li>
                    </ul>
                  </li>
                </ul>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-removal-of-a-group-member">Removal of a Group Member</xref></t>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-group-rekeying-process">Group Rekeying Process</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2">
              <li pn="section-toc.1-1.6.2.1">
                <t indent="0" pn="section-toc.1-1.6.2.1.1"><xref derivedContent="6.1" format="counter" sectionFormat="of" target="section-6.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-point-to-point-group-rekeyi">Point-to-Point Group Rekeying</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.2">
                <t indent="0" pn="section-toc.1-1.6.2.2.1"><xref derivedContent="6.2" format="counter" sectionFormat="of" target="section-6.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-one-to-many-group-rekeying">One-to-Many Group Rekeying</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2.2.2">
                  <li pn="section-toc.1-1.6.2.2.2.1">
                    <t indent="0" pn="section-toc.1-1.6.2.2.2.1.1"><xref derivedContent="6.2.1" format="counter" sectionFormat="of" target="section-6.2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-protection-of-rekeying-mess">Protection of Rekeying Messages</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.6.2.3">
                <t indent="0" pn="section-toc.1-1.6.2.3.1"><xref derivedContent="6.3" format="counter" sectionFormat="of" target="section-6.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-misalignment-of-group-keyin">Misalignment of Group Keying Material</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-extended-scope-format">Extended Scope Format</xref></t>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ace-groupcomm-parameters">ACE Groupcomm Parameters</xref></t>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" format="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ace-groupcomm-error-identif">ACE Groupcomm Error Identifiers</xref></t>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="10" format="counter" sectionFormat="of" target="section-10"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.10.2">
              <li pn="section-toc.1-1.10.2.1">
                <t indent="0" pn="section-toc.1-1.10.2.1.1"><xref derivedContent="10.1" format="counter" sectionFormat="of" target="section-10.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-secure-communication-in-the">Secure Communication in the Group</xref></t>
              </li>
              <li pn="section-toc.1-1.10.2.2">
                <t indent="0" pn="section-toc.1-1.10.2.2.1"><xref derivedContent="10.2" format="counter" sectionFormat="of" target="section-10.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-update-of-group-keying-mate">Update of Group Keying Material</xref></t>
              </li>
              <li pn="section-toc.1-1.10.2.3">
                <t indent="0" pn="section-toc.1-1.10.2.3.1"><xref derivedContent="10.3" format="counter" sectionFormat="of" target="section-10.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-block-wise-considerations">Block-Wise Considerations</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.11">
            <t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="11" format="counter" sectionFormat="of" target="section-11"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.11.2">
              <li pn="section-toc.1-1.11.2.1">
                <t indent="0" pn="section-toc.1-1.11.2.1.1"><xref derivedContent="11.1" format="counter" sectionFormat="of" target="section-11.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-media-type-registrations">Media Type Registrations</xref></t>
              </li>
              <li pn="section-toc.1-1.11.2.2">
                <t indent="0" pn="section-toc.1-1.11.2.2.1"><xref derivedContent="11.2" format="counter" sectionFormat="of" target="section-11.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-coap-content-formats">CoAP Content-Formats</xref></t>
              </li>
              <li pn="section-toc.1-1.11.2.3">
                <t indent="0" pn="section-toc.1-1.11.2.3.1"><xref derivedContent="11.3" format="counter" sectionFormat="of" target="section-11.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-oauth-parameters">OAuth Parameters</xref></t>
              </li>
              <li pn="section-toc.1-1.11.2.4">
                <t indent="0" pn="section-toc.1-1.11.2.4.1"><xref derivedContent="11.4" format="counter" sectionFormat="of" target="section-11.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-oauth-parameters-cbor-mappi">OAuth Parameters CBOR Mappings</xref></t>
              </li>
              <li pn="section-toc.1-1.11.2.5">
                <t indent="0" pn="section-toc.1-1.11.2.5.1"><xref derivedContent="11.5" format="counter" sectionFormat="of" target="section-11.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-interface-description-if-li">Interface Description (if=) Link Target Attribute Values</xref></t>
              </li>
              <li pn="section-toc.1-1.11.2.6">
                <t indent="0" pn="section-toc.1-1.11.2.6.1"><xref derivedContent="11.6" format="counter" sectionFormat="of" target="section-11.6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-custom-problem-detail-keys-">Custom Problem Detail Keys Registry</xref></t>
              </li>
              <li pn="section-toc.1-1.11.2.7">
                <t indent="0" pn="section-toc.1-1.11.2.7.1"><xref derivedContent="11.7" format="counter" sectionFormat="of" target="section-11.7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ace-groupcomm-parameters-3">ACE Groupcomm Parameters</xref></t>
              </li>
              <li pn="section-toc.1-1.11.2.8">
                <t indent="0" pn="section-toc.1-1.11.2.8.1"><xref derivedContent="11.8" format="counter" sectionFormat="of" target="section-11.8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ace-groupcomm-key-types-2">ACE Groupcomm Key Types</xref></t>
              </li>
              <li pn="section-toc.1-1.11.2.9">
                <t indent="0" pn="section-toc.1-1.11.2.9.1"><xref derivedContent="11.9" format="counter" sectionFormat="of" target="section-11.9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ace-groupcomm-profiles-2">ACE Groupcomm Profiles</xref></t>
              </li>
              <li pn="section-toc.1-1.11.2.10">
                <t indent="0" pn="section-toc.1-1.11.2.10.1"><xref derivedContent="11.10" format="counter" sectionFormat="of" target="section-11.10"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-ace-groupcomm-policies-2">ACE Groupcomm Policies</xref></t>
              </li>
              <li pn="section-toc.1-1.11.2.11">
                <t indent="0" pn="section-toc.1-1.11.2.11.1"><xref derivedContent="11.11" format="counter" sectionFormat="of" target="section-11.11"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-sequence-number-synchroniza">Sequence Number Synchronization Methods</xref></t>
              </li>
              <li pn="section-toc.1-1.11.2.12">
                <t indent="0" pn="section-toc.1-1.11.2.12.1"><xref derivedContent="11.12" format="counter" sectionFormat="of" target="section-11.12"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-ace-groupcomm-errors">ACE Groupcomm Errors</xref></t>
              </li>
              <li pn="section-toc.1-1.11.2.13">
                <t indent="0" pn="section-toc.1-1.11.2.13.1"><xref derivedContent="11.13" format="counter" sectionFormat="of" target="section-11.13"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-ace-groupcomm-rekeying-schem">ACE Groupcomm Rekeying Schemes</xref></t>
              </li>
              <li pn="section-toc.1-1.11.2.14">
                <t indent="0" pn="section-toc.1-1.11.2.14.1"><xref derivedContent="11.14" format="counter" sectionFormat="of" target="section-11.14"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-expert-review-instructions">Expert Review Instructions</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.12">
            <t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="12" format="counter" sectionFormat="of" target="section-12"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.12.2">
              <li pn="section-toc.1-1.12.2.1">
                <t indent="0" pn="section-toc.1-1.12.2.1.1"><xref derivedContent="12.1" format="counter" sectionFormat="of" target="section-12.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.12.2.2">
                <t indent="0" pn="section-toc.1-1.12.2.2.1"><xref derivedContent="12.2" format="counter" sectionFormat="of" target="section-12.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.13">
            <t indent="0" pn="section-toc.1-1.13.1"><xref derivedContent="Appendix A" format="default" sectionFormat="of" target="section-appendix.a"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-requirements-for-applicatio">Requirements for Application Profiles</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.13.2">
              <li pn="section-toc.1-1.13.2.1">
                <t indent="0" pn="section-toc.1-1.13.2.1.1"><xref derivedContent="A.1" format="counter" sectionFormat="of" target="section-appendix.a.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-mandatory-to-address-requir">Mandatory-to-Address Requirements</xref></t>
              </li>
              <li pn="section-toc.1-1.13.2.2">
                <t indent="0" pn="section-toc.1-1.13.2.2.1"><xref derivedContent="A.2" format="counter" sectionFormat="of" target="section-appendix.a.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-optional-to-address-require">Optional-to-Address Requirements</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.14">
            <t indent="0" pn="section-toc.1-1.14.1"><xref derivedContent="Appendix B" format="default" sectionFormat="of" target="section-appendix.b"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-extensibility-for-future-co">Extensibility for Future COSE Algorithms</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.14.2">
              <li pn="section-toc.1-1.14.2.1">
                <t indent="0" pn="section-toc.1-1.14.2.1.1"><xref derivedContent="B.1" format="counter" sectionFormat="of" target="section-appendix.b.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-format-of-sign_info_entry">Format of 'sign_info_entry'</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.15">
            <t indent="0" pn="section-toc.1-1.15.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.c"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgments">Acknowledgments</xref></t>
          </li>
          <li pn="section-toc.1-1.16">
            <t indent="0" pn="section-toc.1-1.16.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.d"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section anchor="intro" numbered="true" removeInRFC="false" toc="include" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="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.</t>
      <t indent="0" pn="section-1-2">Candidate group members that act as ACE Clients and are authorized to join a group can interact with the Key Distribution Center (KDC) acting as the ACE Resource Server that is responsible for that group in order to obtain the necessary keying material and parameters to communicate with other group members.</t>
      <t indent="0" pn="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 the KDC. At the same time, communications in the group can rely on different approaches, e.g., based on multicast <xref target="I-D.ietf-core-groupcomm-bis" format="default" sectionFormat="of" derivedContent="GROUP-CoAP"/> or publish-subscribe (pub-sub) messaging <xref target="I-D.ietf-core-coap-pubsub" format="default" sectionFormat="of" derivedContent="CoAP-PUBSUB"/>, and can be protected in different ways.</t>
      <t indent="0" pn="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 that target a particular group communication approach and define how communications in the group are protected, as well as the specific keying material and configuration parameters provided to group members.</t>
      <t indent="0" pn="section-1-5">In order to ensure consistency and aid the development of such application profiles, <xref target="req" format="default" sectionFormat="of" derivedContent="Appendix A"/> of this document defines a number of related compliance requirements. In particular, <xref target="req-mandatory" format="default" sectionFormat="of" derivedContent="Appendix A.1"/> compiles the requirements that application profiles are <bcp14>REQUIRED</bcp14> to fulfill; these are referred to by an identifier that starts with "REQ". Instead, <xref target="req-optional" format="default" sectionFormat="of" derivedContent="Appendix A.2"/> compiles the requirements that application profiles <bcp14>MAY</bcp14> fulfill; these are referred to by an identifier that starts with "OPT".</t>
      <t indent="0" pn="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 or are evicted from the group.</t>
      <t indent="0" pn="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 rekeying the remaining group members when a Client leaves the group. This can rely on different approaches, including efficient group rekeying schemes such as those described in <xref target="RFC2093" format="default" sectionFormat="of" derivedContent="RFC2093"/>, <xref target="RFC2094" format="default" sectionFormat="of" derivedContent="RFC2094"/>, and <xref target="RFC2627" format="default" sectionFormat="of" derivedContent="RFC2627"/>.</t>
      <t indent="0" pn="section-1-8">Consistently with what is recommended in the ACE framework, this document uses Concise Binary Object Representation (CBOR) <xref target="RFC8949" format="default" sectionFormat="of" derivedContent="RFC8949"/> for data encoding. However, using JSON <xref target="RFC8259" format="default" sectionFormat="of" derivedContent="RFC8259"/> instead of CBOR is possible by relying on the conversion method specified in Sections <xref target="RFC8949" section="6.1" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8949#section-6.1" derivedContent="RFC8949"/> and <xref target="RFC8949" section="6.2" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8949#section-6.2" derivedContent="RFC8949"/> of <xref target="RFC8949" format="default" sectionFormat="of" derivedContent="RFC8949"/>.</t>
      <section anchor="terminology" numbered="true" removeInRFC="false" toc="include" pn="section-1.1">
        <name slugifiedName="name-terminology">Terminology</name>
        <t indent="0" pn="section-1.1-1">The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.</t>
        <t indent="0" pn="section-1.1-2">Readers are expected to be familiar with the following:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-1.1-3">
          <li pn="section-1.1-3.1">The terms and concepts described in the ACE framework <xref target="RFC9200" format="default" sectionFormat="of" derivedContent="RFC9200"/> and in the Authorization Information Format (AIF) <xref target="RFC9237" format="default" sectionFormat="of" derivedContent="RFC9237"/> to express authorization information. The terminology for entities in the considered architecture is defined in OAuth 2.0 <xref target="RFC6749" format="default" sectionFormat="of" derivedContent="RFC6749"/>. In particular, this includes Client (C), Resource Server (RS), and Authorization Server (AS).</li>
          <li pn="section-1.1-3.2">The terms and concepts described in the Constrained Application Protocol (CoAP) <xref target="RFC7252" format="default" sectionFormat="of" derivedContent="RFC7252"/>. 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".</li>
          <li pn="section-1.1-3.3">The terms and concepts described in Concise Data Definition Language (CDDL) <xref target="RFC8610" format="default" sectionFormat="of" derivedContent="RFC8610"/>, CBOR <xref target="RFC8949" format="default" sectionFormat="of" derivedContent="RFC8949"/>, and CBOR Object Signing and Encryption (COSE) <xref target="RFC9052" format="default" sectionFormat="of" derivedContent="RFC9052"/> <xref target="RFC9053" format="default" sectionFormat="of" derivedContent="RFC9053"/> <xref target="RFC9338" format="default" sectionFormat="of" derivedContent="RFC9338"/>.</li>
        </ul>
        <t indent="0" pn="section-1.1-4">A node interested in participating in group communication, as well as one that is already participating as a group member, is interchangeably denoted as "Client".</t>
        <t indent="0" pn="section-1.1-5">This document also uses the following terms.</t>
        <dl spacing="normal" indent="3" newline="false" pn="section-1.1-6">
          <dt pn="section-1.1-6.1">Group:</dt>
          <dd pn="section-1.1-6.2">
            <t indent="0" pn="section-1.1-6.2.1">A set of nodes that share common keying material and security parameters used to protect their communications with one another. That is, the term refers to a "security group".</t>
            <t indent="0" pn="section-1.1-6.2.2">
This term is not to be confused with an "application group", which has relevance at the application level and whose members share a common pool of resources or content. Examples of application groups are the set of all nodes deployed in a same physical room or the set of nodes registered to a pub-sub topic.  </t>
            <t indent="0" pn="section-1.1-6.2.3">
This term is also not to be confused with a "multicast group", which has relevance at the network level and whose members all listen to a group network address for receiving messages sent to that group. An example of a multicast group is the set of nodes that are configured to receive messages that are sent to the group's associated IP multicast address.  </t>
            <t indent="0" pn="section-1.1-6.2.4">
The same security group might be associated with multiple application groups. Also, the same application group might be associated with multiple security groups. Further details and considerations on the mapping between the three types of groups are out of the scope of this document.</t>
          </dd>
          <dt pn="section-1.1-6.3">Key Distribution Center (KDC):</dt>
          <dd pn="section-1.1-6.4">The entity responsible for managing one or multiple groups, with particular reference to the group membership and the keying material to use for protecting group communications.</dd>
        </dl>
        <t indent="0" pn="section-1.1-7">Furthermore, this document uses "names" or "identifiers" for groups and nodes. Their different meanings are summarized below.</t>
        <dl spacing="normal" indent="3" newline="false" pn="section-1.1-8">
          <dt pn="section-1.1-8.1">Group name:</dt>
          <dd pn="section-1.1-8.2">The identifier of a group as a text string encoded as UTF-8 <xref target="RFC3629" format="default" sectionFormat="of" derivedContent="RFC3629"/>. Once established, it is invariant. It is used in the interactions between the 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.</dd>
          <dt pn="section-1.1-8.3">GROUPNAME:</dt>
          <dd pn="section-1.1-8.4">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.</dd>
          <dt pn="section-1.1-8.5">Group identifier:</dt>
          <dd pn="section-1.1-8.6">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.</dd>
          <dt pn="section-1.1-8.7">Node name:</dt>
          <dd pn="section-1.1-8.8">The identifier of a node as a text string encoded as UTF-8 <xref target="RFC3629" format="default" sectionFormat="of" derivedContent="RFC3629"/> and consistent with the semantics of URI path segments (see <xref section="3.3" sectionFormat="of" target="RFC3986" format="default" derivedLink="https://rfc-editor.org/rfc/rfc3986#section-3.3" derivedContent="RFC3986"/>). Once established, it is invariant. It is used in the interactions between the Client and RS, as well as to identify a member of a group. A node name is always unique among the node names of the current nodes within a group.</dd>
          <dt pn="section-1.1-8.9">NODENAME:</dt>
          <dd pn="section-1.1-8.10">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.</dd>
        </dl>
        <t indent="0" pn="section-1.1-9">This document additionally uses the following terminology:</t>
        <dl spacing="normal" indent="3" newline="false" pn="section-1.1-10">
          <dt pn="section-1.1-10.1">Transport profile:</dt>
          <dd pn="section-1.1-10.2">A profile of the ACE framework as per <xref section="5.8.4.3" sectionFormat="of" target="RFC9200" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9200#section-5.8.4.3" derivedContent="RFC9200"/>. 
A transport profile specifies the communication protocol and communication security protocol between an ACE Client and Resource Server, as well as proof-of-possession methods if it supports proof-of-possession access tokens. Transport profiles of ACE include, for instance, those described in <xref target="RFC9202" format="default" sectionFormat="of" derivedContent="RFC9202"/>, <xref target="RFC9203" format="default" sectionFormat="of" derivedContent="RFC9203"/>, and <xref target="RFC9431" format="default" sectionFormat="of" derivedContent="RFC9431"/>.</dd>
          <dt pn="section-1.1-10.3">Application profile:</dt>
          <dd pn="section-1.1-10.4">A profile that defines how applications enforce and use supporting security services they require. These services may include, for instance, provisioning, revocation, and distribution of keying material. An application profile may define specific procedures and message formats.</dd>
          <dt pn="section-1.1-10.5">Authentication credential:</dt>
          <dd pn="section-1.1-10.6">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) <xref target="RFC8392" format="default" sectionFormat="of" derivedContent="RFC8392"/>, X.509 certificates <xref target="RFC5280" format="default" sectionFormat="of" derivedContent="RFC5280"/>, and C509 certificates <xref target="I-D.ietf-cose-cbor-encoded-cert" format="default" sectionFormat="of" derivedContent="C509-CERT"/>.</dd>
          <dt pn="section-1.1-10.7">Individual keying material:</dt>
          <dd pn="section-1.1-10.8">Information pertaining exclusively 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 the 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.</dd>
        </dl>
        <t indent="0" pn="section-1.1-11">Throughout this document, examples for CBOR data items are expressed in CBOR extended diagnostic notation as defined in <xref target="RFC8949" sectionFormat="of" section="8" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8949#section-8" derivedContent="RFC8949"/> and <xref target="RFC8610" sectionFormat="of" section="G" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8610#appendix-G" derivedContent="RFC8610"/> ("diagnostic notation"), unless noted otherwise. We often use diagnostic notation comments to provide a textual representation of the parameters' keys and values.</t>
      </section>
    </section>
    <section anchor="overview" numbered="true" removeInRFC="false" toc="include" pn="section-2">
      <name slugifiedName="name-overview">Overview</name>
      <t indent="0" pn="section-2-1">At a high level, the key provisioning process is separated in two phases: the first one follows the ACE framework between the Client, AS, and KDC, while the second one is the actual key distribution between the Client and KDC. After the two phases are completed, the Client is able to participate in the group communication via a Dispatcher entity.</t>
      <figure anchor="fig-roles" align="left" suppress-title="false" pn="figure-1">
        <name slugifiedName="name-key-distribution-participan">Key Distribution Participants</name>
        <artset pn="section-2-2.1">
          <artwork type="svg" align="center" pn="section-2-2.1.1"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" viewBox="0 0 700 224" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px">
              <path d="M 8,32 L 8,64" fill="none" stroke="black"/>
              <path d="M 8,128 L 8,176" fill="none" stroke="black"/>
              <path d="M 56,72 L 56,120" fill="none" stroke="black"/>
              <path d="M 112,32 L 112,64" fill="none" stroke="black"/>
              <path d="M 112,128 L 112,176" fill="none" stroke="black"/>
              <path d="M 184,48 L 184,144" fill="none" stroke="black"/>
              <path d="M 240,32 L 240,64" fill="none" stroke="black"/>
              <path d="M 240,144 L 240,176" fill="none" stroke="black"/>
              <path d="M 344,32 L 344,64" fill="none" stroke="black"/>
              <path d="M 344,144 L 344,176" fill="none" stroke="black"/>
              <path d="M 408,128 L 408,176" fill="none" stroke="black"/>
              <path d="M 424,144 L 424,192" fill="none" stroke="black"/>
              <path d="M 440,160 L 440,208" fill="none" stroke="black"/>
              <path d="M 504,128 L 504,144" fill="none" stroke="black"/>
              <path d="M 520,144 L 520,160" fill="none" stroke="black"/>
              <path d="M 536,160 L 536,208" fill="none" stroke="black"/>
              <path d="M 8,32 L 112,32" fill="none" stroke="black"/>
              <path d="M 240,32 L 344,32" fill="none" stroke="black"/>
              <path d="M 184,48 L 232,48" fill="none" stroke="black"/>
              <path d="M 8,64 L 112,64" fill="none" stroke="black"/>
              <path d="M 240,64 L 344,64" fill="none" stroke="black"/>
              <path d="M 8,128 L 112,128" fill="none" stroke="black"/>
              <path d="M 408,128 L 504,128" fill="none" stroke="black"/>
              <path d="M 120,144 L 184,144" fill="none" stroke="black"/>
              <path d="M 240,144 L 344,144" fill="none" stroke="black"/>
              <path d="M 424,144 L 520,144" fill="none" stroke="black"/>
              <path d="M 120,160 L 232,160" fill="none" stroke="black"/>
              <path d="M 352,160 L 400,160" fill="none" stroke="black"/>
              <path d="M 440,160 L 536,160" fill="none" stroke="black"/>
              <path d="M 8,176 L 112,176" fill="none" stroke="black"/>
              <path d="M 240,176 L 344,176" fill="none" stroke="black"/>
              <path d="M 408,176 L 424,176" fill="none" stroke="black"/>
              <path d="M 424,192 L 440,192" fill="none" stroke="black"/>
              <path d="M 440,208 L 536,208" fill="none" stroke="black"/>
              <polygon class="arrowhead" points="408,160 396,154.4 396,165.6" fill="black" transform="rotate(0,400,160)"/>
              <polygon class="arrowhead" points="360,160 348,154.4 348,165.6" fill="black" transform="rotate(180,352,160)"/>
              <polygon class="arrowhead" points="240,160 228,154.4 228,165.6" fill="black" transform="rotate(0,232,160)"/>
              <polygon class="arrowhead" points="240,48 228,42.4 228,53.6" fill="black" transform="rotate(0,232,48)"/>
              <polygon class="arrowhead" points="128,160 116,154.4 116,165.6" fill="black" transform="rotate(180,120,160)"/>
              <polygon class="arrowhead" points="128,144 116,138.4 116,149.6" fill="black" transform="rotate(180,120,144)"/>
              <polygon class="arrowhead" points="64,120 52,114.4 52,125.6" fill="black" transform="rotate(90,56,120)"/>
              <polygon class="arrowhead" points="64,72 52,66.4 52,77.6" fill="black" transform="rotate(270,56,72)"/>
              <g class="text">
                <text x="60" y="52">AS</text>
                <text x="288" y="52">KDC</text>
                <text x="60" y="148">Client</text>
                <text x="292" y="164">Dispatcher</text>
                <text x="488" y="180">Group</text>
                <text x="488" y="196">members</text>
              </g>
            </svg>
          </artwork>
          <artwork type="ascii-art" align="center" pn="section-2-2.1.2">
.------------.               .------------.
|     AS     |        .-----&gt;|    KDC     |
'------------'        |      '------------'
      ^               |
      |               |
      v               |
.------------.        |                           .-----------.
|   Client   |&lt;-------'      .------------.       | .---------+-.
|            |&lt;-------------&gt;| Dispatcher |&lt;-----&gt;| | .---------+-.
'------------'               '------------'       '-+ |   Group   |
                                                    '-+  members  |
                                                      '-----------'
</artwork>
        </artset>
      </figure>
      <t indent="0" pn="section-2-3">The following participants (see <xref target="fig-roles" format="default" sectionFormat="of" derivedContent="Figure 1"/>) take part in the authorization and key distribution.</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-2-4">
        <li pn="section-2-4.1">Client (C): A 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.</li>
        <li pn="section-2-4.2">Authorization Server (AS): As per the AS defined in the ACE framework <xref target="RFC9200" format="default" sectionFormat="of" derivedContent="RFC9200"/>, it enforces access policies that prescribe whether a node is allowed to join a given group or not and with what roles and rights (e.g., write and/or read).</li>
        <li pn="section-2-4.3">Key Distribution Center (KDC): An entity that maintains the keying material to protect group communications and provides it to Clients authorized to join a given group. During the first phase of the process (<xref target="sec-auth" format="default" sectionFormat="of" derivedContent="Section 3"/>), the KDC takes the role of the RS in the ACE framework. During the second phase of the process (<xref target="key-distr" format="default" sectionFormat="of" derivedContent="Section 4"/>), which is not based on the ACE framework, the KDC distributes the keying material. In addition, the KDC provides the latest keying material to group members when requested or, if required by the application, when group membership changes.</li>
        <li pn="section-2-4.4">
          <t indent="0" pn="section-2-4.4.1">Group members: Nodes that have joined a group where they take part in group communication with one another, protecting it with the group keying material obtained from the KDC.</t>
        </li>
        <li pn="section-2-4.5">
          <t indent="0" pn="section-2-4.5.1">Dispatcher: An entity through which the Clients communicate with the group when sending a message intended for 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 for only one group member may be delivered by alternative means, i.e., with no assistance from the Dispatcher.  </t>
          <t indent="0" pn="section-2-4.5.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; and an implicit entity as in a multicast communication setting, where messages are transmitted to a multicast IP address and delivered on the transport channel.  </t>
          <t indent="0" pn="section-2-4.5.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; as such, it is able to see the messages sent by Clients in the group but not able to decrypt them and read their plain content.</t>
        </li>
      </ul>
      <t indent="0" pn="section-2-5">This document specifies a mechanism for:</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-2-6">
        <li pn="section-2-6.1">Authorizing a Client to join the group (<xref target="sec-auth" format="default" sectionFormat="of" derivedContent="Section 3"/>) and providing it with the group keying material to communicate with the other group members (<xref target="key-distr" format="default" sectionFormat="of" derivedContent="Section 4"/>),</li>
        <li pn="section-2-6.2">Allowing a group member to retrieve group keying material (Sections <xref target="ssec-key-material-retrieval" format="counter" sectionFormat="of" derivedContent="4.3.2.1"/> and <xref target="update-keys" format="counter" sectionFormat="of" derivedContent="4.8.1.1"/>),</li>
        <li pn="section-2-6.3">Allowing a group member to retrieve authentication credentials of other group members (<xref target="sec-key-retrieval" format="default" sectionFormat="of" derivedContent="Section 4.4.1.1"/>) and to provide an updated authentication credential (<xref target="update-pub-key" format="default" sectionFormat="of" derivedContent="Section 4.9.1.1"/>),</li>
        <li pn="section-2-6.4">Allowing a group member to leave the group (<xref target="ssec-group-leaving" format="default" sectionFormat="of" derivedContent="Section 4.8.3.1"/>),</li>
        <li pn="section-2-6.5">Evicting a group member from the group (<xref target="sec-node-removal" format="default" sectionFormat="of" derivedContent="Section 5"/>), and</li>
        <li pn="section-2-6.6">
          <t indent="0" pn="section-2-6.6.1">Renewing and redistributing the group keying material (rekeying), e.g., upon a membership change in the group (<xref target="sec-group-rekeying" format="default" sectionFormat="of" derivedContent="Section 6"/>).  </t>
          <t indent="0" pn="section-2-6.6.2">
Rekeying the group may result in a temporary misalignment of the keying material stored by the different group members. Different situations where this can happen and how they can be handled are discussed in <xref target="sec-misalignment-keying-material" format="default" sectionFormat="of" derivedContent="Section 6.3"/>.</t>
        </li>
      </ul>
      <t indent="0" pn="section-2-7"><xref target="fig-flow" format="default" sectionFormat="of" derivedContent="Figure 2"/> provides a high-level overview of the message flow for a node joining a group. The message flow can be expanded as follows.</t>
      <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-2-8"><li pn="section-2-8.1" derivedCounter="1.">
          <t indent="0" pn="section-2-8.1.1">The joining node requests an access token from the AS in order to access one or more group-membership resources at the KDC and hence join the associated groups.  </t>
          <t indent="0" pn="section-2-8.1.2">
This exchange between the Client and AS <bcp14>MUST</bcp14> be secured, as specified by the transport profile of ACE used between the Client and KDC. Based on the response from the AS, the joining node will establish or continue using a secure communication association with the KDC.</t>
        </li>
        <li pn="section-2-8.2" derivedCounter="2.">
          <t indent="0" pn="section-2-8.2.1">The joining node transfers authentication and authorization information to the KDC by transferring the obtained access token. This is typically achieved by including the access token in a request sent to the /authz-info endpoint at the KDC.  </t>
          <t indent="0" pn="section-2-8.2.2">
Once this exchange is completed, the joining node <bcp14>MUST</bcp14> have a secure communication association established with the KDC before joining a group under that KDC.  </t>
          <t indent="0" pn="section-2-8.2.3">
This exchange and the following secure communications between the Client and the KDC <bcp14>MUST</bcp14> occur in accordance with the transport profile of ACE used between the Client and KDC, such as the DTLS transport profile of ACE <xref target="RFC9202" format="default" sectionFormat="of" derivedContent="RFC9202"/> or the OSCORE transport profile of ACE <xref target="RFC9203" format="default" sectionFormat="of" derivedContent="RFC9203"/>.</t>
        </li>
        <li pn="section-2-8.3" derivedCounter="3.">
          <t indent="0" pn="section-2-8.3.1">The joining node starts the joining process to become a member of the group by sending a request to the related group-membership resource at the KDC. Based on the application requirements and policies, the KDC may perform a group rekeying by generating new group keying material and distributing it to the current group members through the rekeying scheme used in the group.  </t>
          <t indent="0" pn="section-2-8.3.2">
At the end of the joining process, the joining node has received the parameters and group keying material from the KDC to securely communicate with the other group members. Also, the KDC has stored the association between the authorization information from the access token and the secure communication association with the joining node.</t>
        </li>
        <li pn="section-2-8.4" derivedCounter="4.">The joining node and the KDC maintain the secure communication association to support possible future communications. These especially include key management operations, such as the retrieval of updated keying material or the participation in a group rekeying process.</li>
        <li pn="section-2-8.5" derivedCounter="5.">The joining node can communicate securely with the other group members by using the keying material obtained in step 3.</li>
      </ol>
      <figure anchor="fig-flow" align="left" suppress-title="false" pn="figure-2">
        <name slugifiedName="name-message-flow-upon-a-new-nod">Message Flow upon a New Node's Joining</name>
        <artset pn="section-2-9.1">
          <artwork type="svg" align="center" pn="section-2-9.1.1">
<svg xmlns="http://www.w3.org/2000/svg" version="1.1" viewBox="0 0 650 432" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
              <path d="M 48,64 L 48,96" fill="none" stroke="black"/>
              <path d="M 48,128 L 48,176" fill="none" stroke="black"/>
              <path d="M 72,32 L 72,384" fill="none" stroke="black"/>
              <path d="M 312,32 L 312,136" fill="none" stroke="black"/>
              <path d="M 312,184 L 312,216" fill="none" stroke="black"/>
              <path d="M 312,232 L 312,280" fill="none" stroke="black"/>
              <path d="M 312,296 L 312,336" fill="none" stroke="black"/>
              <path d="M 344,32 L 344,336" fill="none" stroke="black"/>
              <path d="M 440,352 L 440,384" fill="none" stroke="black"/>
              <path d="M 528,48 L 528,384" fill="none" stroke="black"/>
              <path d="M 80,64 L 96,64" fill="none" stroke="black"/>
              <path d="M 288,64 L 304,64" fill="none" stroke="black"/>
              <path d="M 80,96 L 96,96" fill="none" stroke="black"/>
              <path d="M 80,144 L 96,144" fill="none" stroke="black"/>
              <path d="M 304,144 L 336,144" fill="none" stroke="black"/>
              <path d="M 80,176 L 104,176" fill="none" stroke="black"/>
              <path d="M 304,176 L 336,176" fill="none" stroke="black"/>
              <path d="M 80,224 L 144,224" fill="none" stroke="black"/>
              <path d="M 264,224 L 336,224" fill="none" stroke="black"/>
              <path d="M 504,256 L 520,256" fill="none" stroke="black"/>
              <path d="M 80,288 L 144,288" fill="none" stroke="black"/>
              <path d="M 272,288 L 336,288" fill="none" stroke="black"/>
              <path d="M 80,366 L 136,366" fill="none" stroke="black"/>
              <path d="M 80,370 L 136,370" fill="none" stroke="black"/>
              <path d="M 368,366 L 432,366" fill="none" stroke="black"/>
              <path d="M 368,370 L 432,370" fill="none" stroke="black"/>
              <path d="M 448,366 L 520,366" fill="none" stroke="black"/>
              <path d="M 448,370 L 520,370" fill="none" stroke="black"/>
              <polygon class="arrowhead" points="528,368 516,362.4 516,373.6" fill="black" transform="rotate(0,520,368)"/>
              <polygon class="arrowhead" points="528,256 516,250.4 516,261.6" fill="black" transform="rotate(0,520,256)"/>
              <polygon class="arrowhead" points="344,224 332,218.4 332,229.6" fill="black" transform="rotate(0,336,224)"/>
              <polygon class="arrowhead" points="344,144 332,138.4 332,149.6" fill="black" transform="rotate(0,336,144)"/>
              <polygon class="arrowhead" points="312,64 300,58.4 300,69.6" fill="black" transform="rotate(0,304,64)"/>
              <polygon class="arrowhead" points="88,368 76,362.4 76,373.6" fill="black" transform="rotate(180,80,368)"/>
              <polygon class="arrowhead" points="88,288 76,282.4 76,293.6" fill="black" transform="rotate(180,80,288)"/>
              <polygon class="arrowhead" points="88,176 76,170.4 76,181.6" fill="black" transform="rotate(180,80,176)"/>
              <polygon class="arrowhead" points="88,96 76,90.4 76,101.6" fill="black" transform="rotate(180,80,96)"/>
              <g class="text">
                <text x="72" y="20">C</text>
                <text x="308" y="20">AS</text>
                <text x="344" y="20">KDC</text>
                <text x="528" y="20">Group</text>
                <text x="528" y="36">Members</text>
                <text x="56" y="52">/</text>
                <text x="192" y="68">Authorization Request</text>
                <text x="208" y="100">Authorization Response --</text>
                <text x="24" y="116">(1) &lt;</text>
                <text x="204" y="148">Token Transfer Request</text>
                <text x="208" y="180">Token Transfer Response</text>
                <text x="56" y="196">\</text>
                <text x="204" y="228">Join Request</text>
                <text x="424" y="260">-- Group rekeying</text>
                <text x="436" y="276">(optional)</text>
                <text x="208" y="292">Join Response</text>
                <text x="444" y="340">Dispatcher</text>
                <text x="252" y="372">Secure group communication</text>
                <text x="132" y="420">(1) Defined in the ACE framework</text>
              </g>
            </svg>
          </artwork>
          <artwork type="ascii-art" align="center" pn="section-2-9.1.2">
        C                            AS  KDC                   Group
        |                             |   |                   Members
      / |                             |   |                      |
     |  |--- Authorization Request --&gt;|   |                      |
     |  |                             |   |                      |
     |  |&lt;-- Authorization Response --|   |                      |
(*) &lt;   |                             |   |                      |
     |  |                             |   |                      |
     |  |---  Token Transfer Request ----&gt;|                      |
     |  |                                 |                      |
     |  |&lt;--- Token Transfer Response-----|                      |
      \ |                             |   |                      |
        |                             |   |                      |
        |--------- Join Request ---------&gt;|                      |
        |                             |   |                      |
        |                             |   | -- Group rekeying --&gt;|
        |                             |   |      (optional)      |
        |&lt;-------- Join Response ---------|                      |
        |                             |   |                      |
        |                             |   |                      |
        |                             |   |       Dispatcher     |
        |                                             |          |
        |&lt;======= Secure group communication =========|=========&gt;|
        |                                             |          |

(*) Defined in the ACE framework
</artwork>
        </artset>
      </figure>
    </section>
    <section anchor="sec-auth" numbered="true" removeInRFC="false" toc="include" pn="section-3">
      <name slugifiedName="name-authorization-to-join-a-gro">Authorization to Join a Group</name>
      <t indent="0" pn="section-3-1">This section describes in detail the format of messages exchanged by the participants when a node requests access to a given group. This exchange is based on ACE <xref target="RFC9200" format="default" sectionFormat="of" derivedContent="RFC9200"/>.</t>
      <t indent="0" pn="section-3-2">As defined in <xref target="RFC9200" format="default" sectionFormat="of" derivedContent="RFC9200"/>, the Client asks the AS for the authorization to join the group through the KDC (see <xref target="ssec-authorization-request" format="default" sectionFormat="of" derivedContent="Section 3.1"/>). If the request is approved and authorization is granted, the AS provides the Client with a proof-of-possession access token and parameters to securely communicate with the KDC (see <xref target="ssec-authorization-response" format="default" sectionFormat="of" derivedContent="Section 3.2"/>).</t>
      <t indent="0" pn="section-3-3">Communications between the Client and the AS <bcp14>MUST</bcp14> be secured according to what is defined by the used transport profile of ACE. The Content-Format used in the message also depends on the used transport profile of ACE. 
For example, it can be "application/ace+cbor" for the first two messages and "application/cwt" for the third message, which are defined in the ACE framework.</t>
      <t indent="0" pn="section-3-4">The transport profile of ACE also defines a number of details, such as the communication and security protocols used with the KDC (see <xref target="RFC9200" sectionFormat="of" section="C" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9200#appendix-C" derivedContent="RFC9200"/>).</t>
      <t indent="0" pn="section-3-5"><xref target="fig-group-member-registration" format="default" sectionFormat="of" derivedContent="Figure 3"/> gives an overview of the exchange described above.</t>
      <figure anchor="fig-group-member-registration" align="left" suppress-title="false" pn="figure-3">
        <name slugifiedName="name-message-flow-of-join-author">Message Flow of Join Authorization</name>
        <artset pn="section-3-6.1">
          <artwork type="svg" align="center" pn="section-3-6.1.1">
<svg xmlns="http://www.w3.org/2000/svg" version="1.1" viewBox="0 0 650 176" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
              <path d="M 32,32 L 32,160" fill="none" stroke="black"/>
              <path d="M 424,32 L 424,104" fill="none" stroke="black"/>
              <path d="M 472,32 L 472,160" fill="none" stroke="black"/>
              <path d="M 40,48 L 64,48" fill="none" stroke="black"/>
              <path d="M 360,48 L 416,48" fill="none" stroke="black"/>
              <path d="M 40,80 L 64,80" fill="none" stroke="black"/>
              <path d="M 392,80 L 416,80" fill="none" stroke="black"/>
              <path d="M 40,112 L 64,112" fill="none" stroke="black"/>
              <path d="M 408,112 L 464,112" fill="none" stroke="black"/>
              <path d="M 40,144 L 64,144" fill="none" stroke="black"/>
              <path d="M 400,144 L 464,144" fill="none" stroke="black"/>
              <polygon class="arrowhead" points="472,144 460,138.4 460,149.6" fill="black" transform="rotate(0,464,144)"/>
              <polygon class="arrowhead" points="472,112 460,106.4 460,117.6" fill="black" transform="rotate(0,464,112)"/>
              <polygon class="arrowhead" points="424,48 412,42.4 412,53.6" fill="black" transform="rotate(0,416,48)"/>
              <polygon class="arrowhead" points="48,144 36,138.4 36,149.6" fill="black" transform="rotate(180,40,144)"/>
              <polygon class="arrowhead" points="48,80 36,74.4 36,85.6" fill="black" transform="rotate(180,40,80)"/>
              <g class="text">
                <text x="28" y="20">Client</text>
                <text x="420" y="20">AS</text>
                <text x="472" y="20">KDC</text>
                <text x="212" y="52">Authorization Request: POST /token</text>
                <text x="228" y="84">Authorization Response: 2.01 (Created)</text>
                <text x="236" y="116">Token Transfer Request: POST /authz-info</text>
                <text x="424" y="132">|</text>
                <text x="232" y="148">Token Transfer Response: 2.01 (Created)</text>
                <text x="424" y="164">|</text>
              </g>
            </svg>
          </artwork>
          <artwork type="ascii-art" align="center" pn="section-3-6.1.2">
Client                                             AS    KDC
   |                                                |     |
   |---- Authorization Request: POST /token -------&gt;|     |
   |                                                |     |
   |&lt;--- Authorization Response: 2.01 (Created) ----|     |
   |                                                |     |
   |---- Token Transfer Request: POST /authz-info -------&gt;|
   |                                                |     |
   |&lt;--- Token Transfer Response: 2.01 (Created) --------&gt;|
   |                                                |     |
</artwork>
        </artset>
      </figure>
      <section anchor="ssec-authorization-request" numbered="true" removeInRFC="false" toc="include" pn="section-3.1">
        <name slugifiedName="name-authorization-request">Authorization Request</name>
        <t indent="0" pn="section-3.1-1">The Authorization Request sent from the Client to the AS is defined in <xref section="5.8.1" sectionFormat="of" target="RFC9200" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9200#section-5.8.1" derivedContent="RFC9200"/> and <bcp14>MAY</bcp14> contain the following parameters, which, if included, <bcp14>MUST</bcp14> have the format and value as specified below.</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.1-2">
          <li pn="section-3.1-2.1">
            <t indent="0" pn="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.  </t>
            <t indent="0" pn="section-3.1-2.1.2">
This parameter is encoded as a CBOR byte string, which wraps a CBOR array of scope entries. All the scope entries are specified according to the same format, i.e., either the Authorization Information Format (AIF) or the textual format defined below.  </t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.1-2.1.3">
              <li pn="section-3.1-2.1.3.1">
                <t indent="0" pn="section-3.1-2.1.3.1.1">If AIF is used, each scope entry is encoded as per <xref target="RFC9237" format="default" sectionFormat="of" derivedContent="RFC9237"/>, i.e., as a CBOR array [Toid, Tperm]. If a scope entry expresses a set of roles to take in a group as per this document, the object identifier "Toid" specifies the group name and <bcp14>MUST</bcp14> be encoded as a CBOR text string, while the permission set "Tperm" specifies the roles that the Client wishes to take in the group.      </t>
                <t indent="0" pn="section-3.1-2.1.3.1.2">
AIF is the default format for application profiles of this specification and is preferable for those that aim for a compact encoding of scope. This is especially desirable for application profiles defining several roles, with the Client possibly asking for multiple roles combined.      </t>
                <t indent="0" pn="section-3.1-2.1.3.1.3"><xref target="cddl-ex-0" format="default" sectionFormat="of" derivedContent="Figure 4"/> shows an example in CDDL notation <xref target="RFC8610" format="default" sectionFormat="of" derivedContent="RFC8610"/> where scope uses AIF.</t>
              </li>
              <li pn="section-3.1-2.1.3.2">
                <t indent="0" pn="section-3.1-2.1.3.2.1">If the textual format is used, each scope entry is a CBOR array formatted as follows.      </t>
                <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.1-2.1.3.2.2">
                  <li pn="section-3.1-2.1.3.2.2.1">As the first element, the group name, encoded as a CBOR text string.</li>
                  <li pn="section-3.1-2.1.3.2.2.2">Optionally, as the second element, the role or CBOR array of roles that the Client wishes to take in the group. This element is optional since roles may have been pre-assigned to the Client, as associated with its verifiable identity credentials. Alternatively, the application may have defined a single, well-known role for the target resource(s) and audience(s).</li>
                </ul>
                <t indent="0" pn="section-3.1-2.1.3.2.3">
<xref target="cddl-ex" format="default" sectionFormat="of" derivedContent="Figure 5"/> shows an example in CDDL notation where scope uses the textual format with the group name and role identifiers encoded as CBOR text strings.</t>
              </li>
            </ul>
            <t indent="0" pn="section-3.1-2.1.4">
It is <bcp14>REQUIRED</bcp14> for application profiles of this specification to specify the exact format and encoding of scope (<xref target="req1" format="none" sectionFormat="of" derivedContent="">REQ1</xref>). This includes defining the set of possible roles and their identifiers, as well as the corresponding encoding to use in the scope entries according to the used scope format.  </t>
            <t indent="0" pn="section-3.1-2.1.5">
If the application profile uses AIF, it is also <bcp14>REQUIRED</bcp14> to register its specific instance of "Toid" and "Tperm", as well as the corresponding media type and Content-Format, as per the guidelines in <xref target="RFC9237" format="default" sectionFormat="of" derivedContent="RFC9237"/> (<xref target="req2" format="none" sectionFormat="of" derivedContent="">REQ2</xref>).  </t>
            <t indent="0" pn="section-3.1-2.1.6">
If the application profile uses the textual format, it <bcp14>MAY</bcp14> additionally specify CBOR values to use for abbreviating the role identifiers (<xref target="opt1" format="none" sectionFormat="of" derivedContent="">OPT1</xref>).</t>
          </li>
          <li pn="section-3.1-2.2">'audience': with an identifier of the KDC.</li>
        </ul>
        <t indent="0" pn="section-3.1-3">As defined in <xref target="RFC9200" format="default" sectionFormat="of" derivedContent="RFC9200"/>, other additional parameters can be included if necessary.</t>
        <figure anchor="cddl-ex-0" align="left" suppress-title="false" pn="figure-4">
          <name slugifiedName="name-example-of-scope-using-aif">Example of scope Using AIF</name>
          <sourcecode type="cddl" markers="false" pn="section-3.1-4.1">
;# include rfc9237

gname = tstr

permissions = uint .bits roles

roles = &amp;(
   Requester: 1,
   Responder: 2,
   Monitor: 3,
   Verifier: 4
)

scope_entries = AIF-Generic&lt;gname, permissions&gt;

scope = bstr .cbor scope_entries
</sourcecode>
        </figure>
        <figure anchor="cddl-ex" align="left" suppress-title="false" pn="figure-5">
          <name slugifiedName="name-example-of-scope-using-the-">Example of scope Using the Textual Format, with the Role Identifiers Encoded as Text Strings</name>
          <sourcecode type="cddl" markers="false" pn="section-3.1-5.1">
gname = tstr

role = tstr

scope_entry = [gname, ? ( role / [2* role] )]

scope_entries = [* scope_entry]

scope = bstr .cbor scope_entries
</sourcecode>
        </figure>
      </section>
      <section anchor="ssec-authorization-response" numbered="true" removeInRFC="false" toc="include" pn="section-3.2">
        <name slugifiedName="name-authorization-response">Authorization Response</name>
        <t indent="0" pn="section-3.2-1">The AS processes the Authorization Request as defined in <xref section="5.8.2" sectionFormat="of" target="RFC9200" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9200#section-5.8.2" derivedContent="RFC9200"/>, especially verifying that the Client is authorized to access the specified groups with the requested roles or possibly a subset of those.</t>
        <t indent="0" pn="section-3.2-2">In case of successful verification, the Authorization Response sent from the AS to the Client is also defined in <xref section="5.8.2" sectionFormat="of" target="RFC9200" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9200#section-5.8.2" derivedContent="RFC9200"/>. Note that the 'expires_in' parameter  <bcp14>MAY</bcp14> be omitted if the application defines how the expiration time is communicated to the Client via other means or if it establishes a default value.</t>
        <t indent="0" pn="section-3.2-3">Additionally, when included, the following parameter <bcp14>MUST</bcp14> have the corresponding values:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.2-4">
          <li pn="section-3.2-4.1">'scope' has the same format and encoding of 'scope' in the Authorization Request, as defined in <xref target="ssec-authorization-request" format="default" sectionFormat="of" derivedContent="Section 3.1"/>. If this parameter is not present, the granted scope is equal to the one requested in <xref target="ssec-authorization-request" format="default" sectionFormat="of" derivedContent="Section 3.1"/>.</li>
        </ul>
        <t indent="0" pn="section-3.2-5">The proof-of-possession access token in the 'access_token' parameter <bcp14>MUST</bcp14> contain the following:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.2-6">
          <li pn="section-3.2-6.1">a confirmation claim (for example, see 'cnf' defined in <xref section="3.1" sectionFormat="of" target="RFC8747" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8747#section-3.1" derivedContent="RFC8747"/> for CWTs)</li>
          <li pn="section-3.2-6.2">an expiration time claim (for example, see 'exp' defined in <xref section="3.1.4" sectionFormat="of" target="RFC8392" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8392#section-3.1.4" derivedContent="RFC8392"/> for CWTs)</li>
          <li pn="section-3.2-6.3">
            <t indent="0" pn="section-3.2-6.3.1">a scope claim (for example, see 'scope' registered in <xref section="8.14" sectionFormat="of" target="RFC9200" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9200#section-8.14" derivedContent="RFC9200"/> for CWTs)</t>
            <t indent="0" pn="section-3.2-6.3.2">If the 'scope' parameter is present in the Authorization Response, this claim specifies the same access control information as in the 'scope' parameter. Instead, if the 'scope' parameter is not present in the Authorization Response, this claim specifies the same access control information as in the 'scope' parameter of the Authorization Request, if the parameter is present therein, or the default scope that the AS is granting the Client otherwise.</t>
            <t indent="0" pn="section-3.2-6.3.3">
By default, this claim has the same encoding as the 'scope' parameter in the Authorization Request, as defined in <xref target="ssec-authorization-request" format="default" sectionFormat="of" derivedContent="Section 3.1"/>.  </t>
            <t indent="0" pn="section-3.2-6.3.4">
Optionally, an alternative extended format of scope defined in <xref target="sec-extended-scope" format="default" sectionFormat="of" derivedContent="Section 7"/> can be used. This format explicitly signals the semantics used to express the actual access control information, which has to be parsed. This enables a Resource Server to correctly process a received access token, also in case:  </t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.2-6.3.5">
              <li pn="section-3.2-6.3.5.1">The Resource Server implements a KDC that supports multiple application profiles of this specification using different scope semantics and/or</li>
              <li pn="section-3.2-6.3.5.2">The Resource Server implements further services beyond a KDC for group communication using different scope semantics.</li>
            </ul>
            <t indent="0" pn="section-3.2-6.3.6">
If the Authorization Server is aware that this applies to the Resource Server for which the access token is issued, the Authorization Server <bcp14>SHOULD</bcp14> use the extended format of scope defined in <xref target="sec-extended-scope" format="default" sectionFormat="of" derivedContent="Section 7"/>.</t>
          </li>
        </ul>
        <t indent="0" pn="section-3.2-7">The access token <bcp14>MAY</bcp14> additionally contain other claims that the transport profile of ACE or other optional parameters require.</t>
        <t indent="0" pn="section-3.2-8">When receiving an Authorization Request from a Client that was previously authorized and for which the AS still stores a valid non-expired access token, the AS <bcp14>MAY</bcp14> reply with that token. Note that it is up to application profiles of ACE to make sure that reposting the same access token does not cause reuse of keying material between nodes (for example, that is accomplished with the use of random nonces in <xref target="RFC9203" format="default" sectionFormat="of" derivedContent="RFC9203"/>).</t>
      </section>
      <section anchor="token-post" numbered="true" removeInRFC="false" toc="include" pn="section-3.3">
        <name slugifiedName="name-token-transferring">Token Transferring</name>
        <t indent="0" pn="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 <xref section="5.10.1" sectionFormat="of" target="RFC9200" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9200#section-5.10.1" derivedContent="RFC9200"/>).</t>
        <t indent="0" pn="section-3.3-2">Note that this request deviates from the one defined in <xref target="RFC9200" format="default" sectionFormat="of" derivedContent="RFC9200"/>, since it allows asking 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.</t>
        <t indent="0" pn="section-3.3-3">The joining node <bcp14>MAY</bcp14> ask for this information from the KDC through the same Token Transfer Request.
	In this case, the message <bcp14>MUST</bcp14> have Content-Format "application/ace+cbor" registered in <xref section="8.16" sectionFormat="of" target="RFC9200" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9200#section-8.16" derivedContent="RFC9200"/>, and the message payload <bcp14>MUST</bcp14> be formatted as a CBOR map, which <bcp14>MUST</bcp14> include the access token. The CBOR map <bcp14>MAY</bcp14> additionally include the following parameter, which, if included, <bcp14>MUST</bcp14> have the format and value as specified below.</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.3-4">
          <li pn="section-3.3-4.1">'sign_info': defined in <xref target="sign-info" format="default" sectionFormat="of" derivedContent="Section 3.3.1"/>, specifying the CBOR simple value <tt>null</tt> (0xf6) to request information about the signature algorithm, the signature algorithm parameters, the signature key parameters, and the exact format of authentication credentials used in the groups that the Client has been authorized to join.</li>
        </ul>
        <t indent="0" pn="section-3.3-5">Alternatively, such information may be pre-configured on the joining node or may be retrieved by alternative means. For example, the joining node may have performed an early group discovery process and obtained the link to the associated group-membership resource at the KDC, along with attributes that describe the group configuration (e.g., see <xref target="I-D.tiloca-core-oscore-discovery" format="default" sectionFormat="of" derivedContent="OSCORE-DISCOVERY"/>).</t>
        <t indent="0" pn="section-3.3-6">After successful verification, the Client is authorized to receive the group keying material from the KDC and join the group. Hence, the KDC replies to the Client with a Token Transfer Response, i.e., a  CoAP 2.01 (Created) response.</t>
        <t indent="0" pn="section-3.3-7">The Token Transfer Response <bcp14>MUST</bcp14> have Content-Format "application/ace+cbor", and its payload is a CBOR map. Note that this deviates from what is defined in the ACE framework, where the response from the /authz-info endpoint is defined as conveying no payload (see <xref section="5.10.1" sectionFormat="of" target="RFC9200" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9200#section-5.10.1" derivedContent="RFC9200"/>).</t>
        <t indent="0" pn="section-3.3-8">If a scope entry in the access token specifies a role that requires the Client to send its own authentication credential to the KDC when joining the related group, then the CBOR map <bcp14>MUST</bcp14> include the 'kdcchallenge' parameter defined in <xref target="kdcchallenge" format="default" sectionFormat="of" derivedContent="Section 3.3.2"/>, specifying a dedicated challenge N_S generated by the KDC.</t>
        <t indent="0" pn="section-3.3-9">Later, when joining the group (see <xref target="ssec-key-distribution-exchange" format="default" sectionFormat="of" derivedContent="Section 4.3.1.1"/>), the Client uses the 'kdcchallenge' value and additional information to build a proof-of-possession (PoP) input. In turn, this is used to compute the PoP evidence that the Client also provides to the KDC, in order to prove possession of its own private key (see the 'client_cred_verify' parameter in <xref target="gid-post" format="default" sectionFormat="of" derivedContent="Section 4.3.1"/>).</t>
        <t indent="0" pn="section-3.3-10">While storing the access token, the KDC <bcp14>MUST</bcp14> store the 'kdcchallenge' value associated with the Client at least until it receives a Join Request from the Client (see <xref target="ssec-key-distribution-exchange" format="default" sectionFormat="of" derivedContent="Section 4.3.1.1"/>) to be able to verify the PoP evidence provided during the join process and thus that the Client possesses its own private key. The KDC deletes the 'kdcchallenge' value associated with the Client upon deleting the access token (e.g., upon its expiration, see <xref section="5.10.3" sectionFormat="of" target="RFC9200" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9200#section-5.10.3" derivedContent="RFC9200"/>).</t>
        <t indent="0" pn="section-3.3-11">The same 'kdcchallenge' value <bcp14>MAY</bcp14> be reused several times by the Client to generate new PoP evidence, e.g., in case the Client provides the KDC with a new authentication credential while being a group member (see <xref target="update-pub-key" format="default" sectionFormat="of" derivedContent="Section 4.9.1.1"/>) or joins a different group where it intends to use a different authentication credential. Therefore, it is <bcp14>RECOMMENDED</bcp14> that the KDC keeps storing the 'kdcchallenge' value after the first join is processed as well. If, upon receiving a Join Request from a Client, the KDC has already discarded the 'kdcchallenge' value, that will trigger an error response with a newly generated 'kdcchallenge' value that the Client can use to restart the join process, as specified in <xref target="ssec-key-distribution-exchange" format="default" sectionFormat="of" derivedContent="Section 4.3.1.1"/>.</t>
        <t indent="0" pn="section-3.3-12">If 'sign_info' is included in the Token Transfer Request, the KDC <bcp14>SHOULD</bcp14> include the 'sign_info' parameter in the Token Transfer Response, as per the format defined in <xref target="sign-info" format="default" sectionFormat="of" derivedContent="Section 3.3.1"/>. Note that the field 'id' of each 'sign_info_entry' specifies the name or array of group names to which that 'sign_info_entry' applies. As an exception, the KDC <bcp14>MAY</bcp14> omit the 'sign_info' parameter in the Token Transfer Response even if 'sign_info' is included in the Token Transfer Request in case none of the groups that the Client is authorized to join use signatures to achieve source authentication.</t>
        <t indent="0" pn="section-3.3-13">Note that the CBOR map specified as payload of the 2.01 (Created) response may include further parameters, e.g., according to the used transport profile of ACE. Application profiles of this specification <bcp14>MAY</bcp14> define additional parameters to use within this exchange (<xref target="opt2" format="none" sectionFormat="of" derivedContent="">OPT2</xref>).</t>
        <t indent="0" pn="section-3.3-14">Application profiles of this specification <bcp14>MAY</bcp14> define alternative specific negotiations of parameter values for the signature algorithm and signature keys if 'sign_info' is not used (<xref target="opt3" format="none" sectionFormat="of" derivedContent="">OPT3</xref>).</t>
        <t indent="0" pn="section-3.3-15">If allowed by the used transport profile of ACE, the Client may provide the access token to the KDC by other means than the Token Transfer Request. An example is the DTLS transport profile of ACE, where the Client can provide the access token to the KDC during the secure session establishment (see <xref section="3.3.2" sectionFormat="of" target="RFC9202" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9202#section-3.3.2" derivedContent="RFC9202"/>).</t>
        <section anchor="sign-info" numbered="true" removeInRFC="false" toc="include" pn="section-3.3.1">
          <name slugifiedName="name-sign_info-parameter">'sign_info' Parameter</name>
          <t indent="0" pn="section-3.3.1-1">The 'sign_info' parameter is an <bcp14>OPTIONAL</bcp14> parameter of the request and response messages exchanged between the Client and the /authz-info endpoint at the RS (see <xref section="5.10.1" sectionFormat="of" target="RFC9200" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9200#section-5.10.1" derivedContent="RFC9200"/>).</t>
          <t indent="0" pn="section-3.3.1-2">This parameter allows the Client and the RS to exchange information about a signature algorithm and about authentication credentials to accordingly use for signature verification. Its exact semantics and content are application specific.</t>
          <t indent="0" pn="section-3.3.1-3">In this specification and in application profiles building on it, this parameter is used to exchange information about the signature algorithm and about authentication credentials to be used with it in the groups indicated by the transferred access token as per its 'scope' claim (see <xref target="ssec-authorization-response" format="default" sectionFormat="of" derivedContent="Section 3.2"/>).</t>
          <t indent="0" pn="section-3.3.1-4">When used in the Token Transfer Request sent to the KDC (see <xref target="token-post" format="default" sectionFormat="of" derivedContent="Section 3.3"/>), the 'sign_info' parameter specifies the CBOR simple value <tt>null</tt> (0xf6). This is done to ask for information about the signature algorithm and about the authentication credentials used in the groups that, as per the granted roles, the Client has been authorized to join or interact with (e.g., as an external signature verifier).</t>
          <t indent="0" pn="section-3.3.1-5">When used in the following Token Transfer Response from the KDC (see <xref target="token-post" format="default" sectionFormat="of" derivedContent="Section 3.3"/>), the 'sign_info' parameter is a CBOR array of one or more elements. The number of elements is at most the number of groups that the Client has been authorized to join or interact with. Each element contains information about signing parameters and about authentication credentials for one or more groups and is formatted as follows.</t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.3.1-6">
            <li pn="section-3.3.1-6.1">The first element 'id' is a group name or a CBOR array of group names, which is associated with groups for which the next four elements apply. Each specified group name is a CBOR text string and is hereafter referred to as 'gname'.</li>
            <li pn="section-3.3.1-6.2">The second element 'sign_alg' is a CBOR integer or a text string that indicates the signature algorithm used in the groups identified by the 'gname' values. It is <bcp14>REQUIRED</bcp14> for application profiles to define specific values that this parameter can take (<xref target="req3" format="none" sectionFormat="of" derivedContent="">REQ3</xref>), which are selected from the set of signing algorithms of the "COSE Algorithms" registry <xref target="COSE.Algorithms" format="default" sectionFormat="of" derivedContent="COSE.Algorithms"/>.</li>
            <li pn="section-3.3.1-6.3">The third element 'sign_parameters' is a CBOR array that indicates the parameters of the signature algorithm used in the groups identified by the 'gname' values. Its content depends on the value of 'sign_alg'. It is <bcp14>REQUIRED</bcp14> for application profiles to define the possible values and structure for the elements of this parameter (<xref target="req4" format="none" sectionFormat="of" derivedContent="">REQ4</xref>).</li>
            <li pn="section-3.3.1-6.4">The fourth element 'sign_key_parameters' is a CBOR array that indicates the parameters of the key used with the signature algorithm in the groups identified by the 'gname' values. Its content depends on the value of 'sign_alg'. It is <bcp14>REQUIRED</bcp14> for application profiles to define the possible values and structure for the elements of this parameter (<xref target="req5" format="none" sectionFormat="of" derivedContent="">REQ5</xref>).</li>
            <li pn="section-3.3.1-6.5">The fifth element 'cred_fmt' either is a CBOR integer indicating the format of authentication credentials used in the groups identified by the 'gname' values or is the CBOR simple value <tt>null</tt> (0xf6), which indicates that the KDC does not act as a repository of authentication credentials for group members. Its acceptable integer values are taken from the "Label" column of the "COSE Header Parameters" registry <xref target="COSE.Header.Parameters" format="default" sectionFormat="of" derivedContent="COSE.Header.Parameters"/>, with some of those values also indicating the type of container to use for exchanging the authentication credentials with the KDC (e.g., a chain or bag of certificates). It is <bcp14>REQUIRED</bcp14> for application profiles to define specific values to use for this parameter, consistently with the acceptable formats of authentication credentials (<xref target="req6" format="none" sectionFormat="of" derivedContent="">REQ6</xref>).</li>
          </ul>
          <t indent="0" pn="section-3.3.1-7">The CDDL notation <xref target="RFC8610" format="default" sectionFormat="of" derivedContent="RFC8610"/> of the 'sign_info' parameter is given below.</t>
          <sourcecode type="cddl" markers="false" pn="section-3.3.1-8">
sign_info = sign_info_req / sign_info_resp

sign_info_req  = null                  ; in the Token Transfer
                                       ; Request to the KDC

sign_info_resp = [+ sign_info_entry]   ; in the Token Transfer
                                       ; Response from the KDC

sign_info_entry =
[
 id: gname / [+ gname],
 sign_alg: int / tstr,
 sign_parameters: [any],
 sign_key_parameters: [+ parameter: any],
 cred_fmt: int / null
]

gname = tstr
</sourcecode>
          <t indent="0" pn="section-3.3.1-9">This format is consistent with every signature algorithm currently defined in <xref target="RFC9053" format="default" sectionFormat="of" derivedContent="RFC9053"/>, i.e., with algorithms that have only the COSE key type as their COSE capability. <xref target="sec-future-cose-algs" format="default" sectionFormat="of" derivedContent="Appendix B"/> describes how the format of each 'sign_info_entry' can be generalized for possible future registered algorithms having a different set of COSE capabilities.</t>
        </section>
        <section anchor="kdcchallenge" numbered="true" removeInRFC="false" toc="include" pn="section-3.3.2">
          <name slugifiedName="name-kdcchallenge-parameter">'kdcchallenge' Parameter</name>
          <t indent="0" pn="section-3.3.2-1">The 'kdcchallenge' parameter is an <bcp14>OPTIONAL</bcp14> parameter of the response message returned from the /authz-info endpoint at the RS, as defined in <xref section="5.10.1" sectionFormat="of" target="RFC9200" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9200#section-5.10.1" derivedContent="RFC9200"/>. This parameter contains a challenge generated by the RS and provided to the Client.</t>
          <t indent="0" pn="section-3.3.2-2">In this specification and in application profiles building on it, the Client can use this challenge to prove possession of its own private key in the Join Request (see the 'client_cred_verify' parameter in <xref target="gid-post" format="default" sectionFormat="of" derivedContent="Section 4.3.1"/>).</t>
        </section>
      </section>
    </section>
    <section anchor="key-distr" numbered="true" removeInRFC="false" toc="include" pn="section-4">
      <name slugifiedName="name-kdc-functionalities">KDC Functionalities</name>
      <t indent="0" pn="section-4-1">This section describes the functionalities provided by the KDC, as related to the provisioning of the keying material as well as to the group membership management.</t>
      <t indent="0" pn="section-4-2">In particular, this section defines the interface available at the KDC, specifies the handlers of each resource provided by the KDC interface, and describes how Clients interact with those resources to join a group and to perform additional operations as group members.</t>
      <t indent="0" pn="section-4-3">A key operation that the Client can perform after transferring the access token to the KDC is a Join Request-Response exchange with the KDC. In the Join Request, the Client specifies the group it requests to join (see <xref target="ssec-key-distribution-exchange" format="default" sectionFormat="of" derivedContent="Section 4.3.1.1"/>). The KDC will then check the stored access token associated with the Client and verify that the Client is accordingly authorized to join the specified group. In case of successful verification, the KDC provides the Client with the keying material to securely communicate with the other members of the group.</t>
      <t indent="0" pn="section-4-4">Later on as a group member, the Client can also rely on the interface at the KDC to perform additional operations consistent with the roles it has in the group.</t>
      <section anchor="kdc-if" numbered="true" removeInRFC="false" toc="include" pn="section-4.1">
        <name slugifiedName="name-interface-at-the-kdc">Interface at the KDC</name>
        <t indent="0" pn="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.</t>
        <t indent="0" pn="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 <bcp14>MUST</bcp14> have Content-Format "application/ace-groupcomm+cbor", which is registered in <xref target="content-type" format="default" sectionFormat="of" derivedContent="Section 11.2"/>. CBOR map keys used for the message parameters are defined in <xref target="params" format="default" sectionFormat="of" derivedContent="Section 8"/>.</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.1-3">
          <li pn="section-4.1-3.1">
            <t indent="0" pn="section-4.1-3.1.1">/ace-group : the path of this root resource is invariant once the resource is established. Its employment 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.  </t>
            <t indent="0" pn="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 <xref target="retrieval-gnames" format="default" sectionFormat="of" derivedContent="Section 4.2.1.1"/>.  </t>
            <t indent="0" pn="section-4.1-3.1.3">
Clients may be authorized to access this resource even without being members of any group managed by the KDC and even if they are not authorized to become group members (e.g., when authorized to be external signature verifiers).  </t>
            <t indent="0" pn="section-4.1-3.1.4">
The Interface Description (if=) Link Target Attribute value "ace.groups" is registered in <xref target="if-ace-group" format="default" sectionFormat="of" derivedContent="Section 11.5"/> and can be used to describe the interface provided by this root resource.  </t>
            <t indent="0" pn="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 <xref target="RFC6690" format="default" sectionFormat="of" derivedContent="RFC6690"/>.  </t>
            <artwork align="left" pn="section-4.1-3.1.6">
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"
</artwork>
          </li>
          <li pn="section-4.1-3.2">
            <t indent="0" pn="section-4.1-3.2.1">/ace-group/GROUPNAME : one such sub-resource to /ace-group is hosted for each group with the name GROUPNAME that the KDC manages. In particular, it is the group-membership resource associated with that group, and it contains the symmetric group keying material of that group.  </t>
            <t indent="0" pn="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 Sections <xref target="ssec-key-distribution-exchange" format="counter" sectionFormat="of" derivedContent="4.3.1.1"/> and <xref target="ssec-key-material-retrieval" format="counter" sectionFormat="of" derivedContent="4.3.2.1"/>, respectively.  </t>
            <t indent="0" pn="section-4.1-3.2.3">
The Interface Description (if=) Link Target Attribute value "ace.group" is registered in <xref target="if-ace-group" format="default" sectionFormat="of" derivedContent="Section 11.5"/> and can be used to describe the interface provided by a group-membership resource.  </t>
            <t indent="0" pn="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 <xref target="RFC6690" format="default" sectionFormat="of" derivedContent="RFC6690"/>.  </t>
            <artwork align="left" pn="section-4.1-3.2.5">
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"
</artwork>
            <t indent="0" pn="section-4.1-3.2.6">
If it is not required that the value of the GROUPNAME URI path and the group name in the access token scope ('gname' in <xref target="ssec-authorization-request" format="default" sectionFormat="of" derivedContent="Section 3.1"/>) coincide, the KDC <bcp14>MUST</bcp14> implement a mechanism to map the GROUPNAME value in the URI to the group name in order to refer to the correct group (<xref target="req7" format="none" sectionFormat="of" derivedContent="">REQ7</xref>).</t>
          </li>
          <li pn="section-4.1-3.3">
            <t indent="0" pn="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 the name GROUPNAME.  </t>
            <t indent="0" pn="section-4.1-3.3.2">
This resource is created only in case the KDC acts as a repository of authentication credentials for group members.  </t>
            <t indent="0" pn="section-4.1-3.3.3">
As a group member, a Client can access this resource in order to retrieve the authentication credentials of other group members. 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 Sections <xref target="sec-key-retrieval-all" format="counter" sectionFormat="of" derivedContent="4.4.2.1"/> and <xref target="sec-key-retrieval" format="counter" sectionFormat="of" derivedContent="4.4.1.1"/>, respectively.  </t>
            <t indent="0" pn="section-4.1-3.3.4">
Clients may be authorized to access this resource even without being group members, e.g., if authorized to be external signature verifiers for the group.</t>
          </li>
          <li pn="section-4.1-3.4">
            <t indent="0" pn="section-4.1-3.4.1">/ace-group/GROUPNAME/kdc-cred : the path of this resource is invariant once the resource is established. This resource contains the authentication credential of the KDC for the group with the name GROUPNAME.  </t>
            <t indent="0" pn="section-4.1-3.4.2">
This resource is created only in case the KDC has an associated authentication credential and this is required for the correct group operation. It is <bcp14>REQUIRED</bcp14> for application profiles to define whether the KDC has such an associated authentication credential (<xref target="req8" format="none" sectionFormat="of" derivedContent="">REQ8</xref>).  </t>
            <t indent="0" pn="section-4.1-3.4.3">
As a group member, a Client can access this resource in order to retrieve the current authentication credential of the KDC. This operation is described in   <xref target="kdc-pub-key" format="default" sectionFormat="of" derivedContent="Section 4.5.1.1"/>.</t>
            <t indent="0" pn="section-4.1-3.4.4">
Clients may be authorized to access this resource even without being group members, e.g., if authorized to be external signature verifiers for the group.</t>
          </li>
          <li pn="section-4.1-3.5">
            <t indent="0" pn="section-4.1-3.5.1">/ace-group/GROUPNAME/policies : the path of this resource is invariant once the resource is established. This resource contains the group policies of the group with the name GROUPNAME.  </t>
            <t indent="0" pn="section-4.1-3.5.2">
A Client can access this resource as a group member in order to retrieve the group policies. This operation is described in <xref target="policies" format="default" sectionFormat="of" derivedContent="Section 4.6.1.1"/>.</t>
          </li>
          <li pn="section-4.1-3.6">
            <t indent="0" pn="section-4.1-3.6.1">/ace-group/GROUPNAME/num : the path of this resource is invariant once the resource is established. This resource contains the current version number for the symmetric group keying material of the group with the name GROUPNAME.  </t>
            <t indent="0" pn="section-4.1-3.6.2">
A Client can access this resource as a group member in order to retrieve the version number of the keying material currently used in the group. This operation is described in <xref target="key-version" format="default" sectionFormat="of" derivedContent="Section 4.7.1.1"/>.</t>
          </li>
          <li pn="section-4.1-3.7">
            <t indent="0" pn="section-4.1-3.7.1">/ace-group/GROUPNAME/nodes/NODENAME : one such sub-resource of /ace-group/GROUPNAME is hosted for each group member of the group with the name GROUPNAME. Each such resource is identified by the node name NODENAME of the associated group member and contains the group keying material and the individual keying material for that group member.  </t>
            <t indent="0" pn="section-4.1-3.7.2">
A Client as a group member can access this resource in order to retrieve the current group keying material together with its individual keying material, request new individual keying material to use in the group, and leave the group. These operations are described in Sections <xref target="update-keys" format="counter" sectionFormat="of" derivedContent="4.8.1.1"/>, <xref target="new-keys" format="counter" sectionFormat="of" derivedContent="4.8.2.1"/>, and <xref target="ssec-group-leaving" format="counter" sectionFormat="of" derivedContent="4.8.3.1"/>, respectively.</t>
          </li>
          <li pn="section-4.1-3.8">
            <t indent="0" pn="section-4.1-3.8.1">/ace-group/GROUPNAME/nodes/NODENAME/cred : the path of this resource is invariant once the resource is established. This resource contains the individual authentication credential for the node with the name NODENAME as a group member of the group with the name GROUPNAME.  </t>
            <t indent="0" pn="section-4.1-3.8.2">
A Client can access this resource in order to upload at the KDC a new authentication credential to use in the group. This operation is described in <xref target="update-pub-key" format="default" sectionFormat="of" derivedContent="Section 4.9.1.1"/>.  </t>
            <t indent="0" pn="section-4.1-3.8.3">
This resource is not created if the group member does not have an authentication credential to use in the group or if the KDC does not store the authentication credentials of group members.</t>
          </li>
        </ul>
        <t indent="0" pn="section-4.1-4">The KDC is expected to fully provide the interface defined above. It is otherwise <bcp14>REQUIRED</bcp14> for  the application profiles of this specification to indicate which resources are not hosted, i.e., which parts of the interface defined in this section are not supported by the KDC (<xref target="req9" format="none" sectionFormat="of" derivedContent="">REQ9</xref>). Application profiles of this specification <bcp14>MAY</bcp14> extend the KDC interface by defining additional handlers, as well as defining additional resources and their handlers.</t>
        <t indent="0" pn="section-4.1-5">It is <bcp14>REQUIRED</bcp14> for application profiles of this specification to register a Resource Type for the group-membership resources (<xref target="req10" format="none" sectionFormat="of" derivedContent="">REQ10</xref>). This Resource Type can be used to discover the correct URL for sending a Join Request to the KDC. This Resource Type can also be used to indicate which specific application profile of this specification is used by a specific group-membership resource at the KDC.</t>
        <t indent="0" pn="section-4.1-6">It is <bcp14>REQUIRED</bcp14> for application profiles of this specification to define what specific actions (e.g., CoAP methods) are allowed on each resource provided by the KDC interface, depending on whether the Client is a current group member, the roles that a Client is authorized to take as per the obtained access token (see <xref target="ssec-authorization-request" format="default" sectionFormat="of" derivedContent="Section 3.1"/>), and the roles that the Client has as current group member (<xref target="req11" format="none" sectionFormat="of" derivedContent="">REQ11</xref>).</t>
        <section anchor="client-operations" numbered="true" removeInRFC="false" toc="include" pn="section-4.1.1">
          <name slugifiedName="name-operations-supported-by-cli">Operations Supported by Clients</name>
          <t indent="0" pn="section-4.1.1-1">It is expected that a Client minimally supports the following set of primary operations and corresponding interactions with the KDC.</t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.1.1-2">
            <li pn="section-4.1.1-2.1">FETCH request to /ace-group/ in order to retrieve group names associated with group identifiers.</li>
            <li pn="section-4.1.1-2.2">POST and GET requests to /ace-group/GROUPNAME/ in order to join a group (POST) and later retrieve the current group keying material as a group member (GET).</li>
            <li pn="section-4.1.1-2.3">GET and FETCH requests to /ace-group/GROUPNAME/creds in order to retrieve the authentication credentials of all the other group members (GET) or only some of them by filtering (FETCH). While retrieving authentication credentials remains possible by using GET requests, retrieval by filtering allows Clients to greatly limit the size of exchanged messages.</li>
            <li pn="section-4.1.1-2.4">GET request to /ace-group/GROUPNAME/num in order to retrieve the current version of the group keying material as a group member.</li>
            <li pn="section-4.1.1-2.5">DELETE request to /ace-group/GROUPNAME/nodes/NODENAME  in order to leave the group.</li>
          </ul>
          <t indent="0" pn="section-4.1.1-3">In addition, some Clients may rather not support the following set of secondary operations and corresponding interactions with the KDC. This can be specified, for instance, in compliance documents defining minimalistic Clients and their capabilities in specific deployments. In turn, these might also have to consider the used application profile of this specification.</t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.1.1-4">
            <li pn="section-4.1.1-4.1">GET request to /ace-group/GROUPNAME/kdc-cred in order to retrieve the current authentication credential of the KDC. This is relevant only if the KDC has an associated authentication credential and this is required for the correct group operation.</li>
            <li pn="section-4.1.1-4.2">GET request to /ace-group/GROUPNAME/policies in order to retrieve the current group policies as a group member.</li>
            <li pn="section-4.1.1-4.3">GET request to /ace-group/GROUPNAME/nodes/NODENAME in order to retrieve the current group keying material and individual keying material. The former can also be retrieved through a GET request to /ace-group/GROUPNAME/ (see above).</li>
            <li pn="section-4.1.1-4.4">POST request to /ace-group/GROUPNAME/nodes/NODENAME in order to ask for new individual keying material. Alternatively, the Client could obtain new individual keying material by rejoining the group through a POST request to /ace-group/GROUPNAME/ (see above). Furthermore, depending on its roles in the group or on the application profile of this specification, the Client might simply not be associated with any individual keying material.</li>
            <li pn="section-4.1.1-4.5">POST request to /ace-group/GROUPNAME/nodes/NODENAME/cred in order to provide the KDC with a new authentication credential. Alternatively, the Client could provide a new authentication credential by rejoining the group through a POST request to /ace-group/GROUPNAME/ (see above). Furthermore, depending on its roles in the group, the Client might simply not have an associated authentication credential to provide.</li>
          </ul>
          <t indent="0" pn="section-4.1.1-5">It is <bcp14>REQUIRED</bcp14> for application profiles of this specification to categorize possible newly defined operations for Clients into primary and secondary operations and to provide accompanying considerations (<xref target="req12" format="none" sectionFormat="of" derivedContent="">REQ12</xref>).</t>
        </section>
        <section anchor="kdc-if-errors" numbered="true" removeInRFC="false" toc="include" pn="section-4.1.2">
          <name slugifiedName="name-error-handling">Error Handling</name>
          <t indent="0" pn="section-4.1.2-1">Upon receiving a request from a Client, the KDC <bcp14>MUST</bcp14> check that it is storing a valid access token from that Client. If this is not the case, the KDC <bcp14>MUST</bcp14> reply with a 4.01 (Unauthorized) error response.</t>
          <t indent="0" pn="section-4.1.2-2">Unless the request targets the /ace-group resource, the KDC <bcp14>MUST</bcp14> check that it is storing a valid access token for that Client such that:</t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.1.2-3">
            <li pn="section-4.1.2-3.1">the scope specified in the access token includes a scope entry related to the group name GROUPNAME associated with the targeted resource and</li>
            <li pn="section-4.1.2-3.2">the set of roles specified in that scope entry allows the Client to perform the requested operation on the targeted resource (<xref target="req11" format="none" sectionFormat="of" derivedContent="">REQ11</xref>).</li>
          </ul>
          <t indent="0" pn="section-4.1.2-4">In case the KDC stores a valid access token but the verifications above fail, the KDC <bcp14>MUST</bcp14> reply with a 4.03 (Forbidden) error response. This response <bcp14>MAY</bcp14> be an AS Request Creation Hints, as defined in <xref section="5.3" sectionFormat="of" target="RFC9200" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9200#section-5.3" derivedContent="RFC9200"/>, in which case the Content-Format <bcp14>MUST</bcp14> be "application/ace+cbor".</t>
          <t indent="0" pn="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 KDC <bcp14>MUST</bcp14> reply with a 4.00 (Bad Request) error response.</t>
          <t indent="0" pn="section-4.1.2-6">If the request includes unknown or unexpected fields, the KDC <bcp14>MUST</bcp14> silently ignore them and continue processing the request. Application profiles of this specification <bcp14>MAY</bcp14> define optional or mandatory payload formats for specific error cases (<xref target="opt4" format="none" sectionFormat="of" derivedContent="">OPT4</xref>).</t>
          <t indent="0" pn="section-4.1.2-7">Some error responses from the KDC can convey error-specific information according to the problem-details format defined in <xref target="RFC9290" format="default" sectionFormat="of" derivedContent="RFC9290"/>. Such error responses <bcp14>MUST</bcp14> have Content-Format "application/concise-problem-details+cbor". The payload of these error responses <bcp14>MUST</bcp14> be a CBOR map specifying a Concise Problem Details data item (see <xref section="2" sectionFormat="of" target="RFC9290" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9290#section-2" derivedContent="RFC9290"/>). The CBOR map is formatted as follows.</t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.1.2-8">
            <li pn="section-4.1.2-8.1">
              <t indent="0" pn="section-4.1.2-8.1.1">It <bcp14>MUST</bcp14> include the Custom Problem Detail entry 'ace-groupcomm-error', which is registered in <xref target="iana-custom-problem-details" format="default" sectionFormat="of" derivedContent="Section 11.6"/> of this document.  </t>
              <t indent="0" pn="section-4.1.2-8.1.2">
This entry is formatted as a CBOR map including 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 that occurred at the KDC. This value is taken from the "Value" column of the "ACE Groupcomm Errors" registry defined in <xref target="iana-ace-groupcomm-errors" format="default" sectionFormat="of" derivedContent="Section 11.12"/> of this document.  </t>
              <t indent="0" pn="section-4.1.2-8.1.3">
The CDDL notation <xref target="RFC8610" format="default" sectionFormat="of" derivedContent="RFC8610"/> of the 'ace-groupcomm-error' entry is given below.</t>
              <sourcecode type="cddl" markers="false" pn="section-4.1.2-8.1.4">
   ace-groupcomm-error = {
     &amp;(error-id: 0) =&gt; int
   }
</sourcecode>
            </li>
            <li pn="section-4.1.2-8.2">
              <t indent="0" pn="section-4.1.2-8.2.1">It <bcp14>MAY</bcp14> include further Standard Problem Detail entries or Custom Problem Detail entries (see <xref target="RFC9290" format="default" sectionFormat="of" derivedContent="RFC9290"/>).  </t>
              <t indent="0" pn="section-4.1.2-8.2.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 <bcp14>SHOULD</bcp14> be logged by the KDC. The 'detail' entry is unlikely relevant in an unattended setup where human intervention is not expected.</t>
            </li>
          </ul>
          <t indent="0" pn="section-4.1.2-9">An example of an error response using the problem-details format is shown in <xref target="fig-exapmle-error-response" format="default" sectionFormat="of" derivedContent="Figure 6"/>.</t>
          <figure anchor="fig-exapmle-error-response" align="left" suppress-title="false" pn="figure-6">
            <name slugifiedName="name-example-of-an-error-respons">Example of an Error Response with Problem Details</name>
            <artwork align="left" pn="section-4.1.2-10.1">
Response:

Header: Service Unavailable (Code=5.03)
Content-Format: 257 (application/concise-problem-details+cbor)
Payload:
{
  / title /               -1: "No available individual keying material",
  / detail /              -2: "Things will change after a
                                group rekeying; try later",
  / ace-groupcomm-error /  0: {
    / error-id /  0: 4 / "No available individual keying material" /
  }
}
</artwork>
          </figure>
          <t indent="0" pn="section-4.1.2-11">The problem-details format (in general) and the Custom Problem Detail entry 'ace-groupcomm-error' (in particular) are <bcp14>OPTIONAL</bcp14> for Clients to support. A Client supporting the entry 'ace-groupcomm-error' and that can understand the specified error may use that information to determine what actions to take next.</t>
          <t indent="0" pn="section-4.1.2-12"><xref target="error-types" format="default" sectionFormat="of" derivedContent="Section 9"/> 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 <bcp14>MAY</bcp14> define additional values (<xref target="opt5" format="none" sectionFormat="of" derivedContent="">OPT5</xref>).</t>
        </section>
      </section>
      <section anchor="ace-group" numbered="true" removeInRFC="false" toc="include" pn="section-4.2">
        <name slugifiedName="name-ace-group">/ace-group</name>
        <t indent="0" pn="section-4.2-1">This resource implements the FETCH handler.</t>
        <section anchor="ace-group-fetch" numbered="true" removeInRFC="false" toc="include" pn="section-4.2.1">
          <name slugifiedName="name-fetch-handler">FETCH Handler</name>
          <t indent="0" pn="section-4.2.1-1">The FETCH handler receives group identifiers and returns the corresponding group names and GROUPNAME URIs.</t>
          <t indent="0" pn="section-4.2.1-2">The handler expects a request with the payload formatted as a CBOR map, which <bcp14>MUST</bcp14> contain the following fields:</t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.2.1-3">
            <li pn="section-4.2.1-3.1">'gid': its value is encoded as a CBOR array, containing one or more group identifiers. The exact encoding of the group identifier <bcp14>MUST</bcp14> be specified by the application profile (<xref target="req13" format="none" sectionFormat="of" derivedContent="">REQ13</xref>). The Client indicates that it wishes to receive the group names of all the groups having these identifiers.</li>
          </ul>
          <t indent="0" pn="section-4.2.1-4">The handler identifies the groups where communications are secured by using the keying material identified by those group identifiers.</t>
          <t indent="0" pn="section-4.2.1-5">If all verifications succeed, the handler replies with a 2.05 (Content) response, whose payload is formatted as a CBOR map that <bcp14>MUST</bcp14> contain the following fields:</t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.2.1-6">
            <li pn="section-4.2.1-6.1">'gid': its value is encoded as a CBOR array, containing zero or more group identifiers. The handler indicates that those are the identifiers it is sending group names for. This CBOR array is a subset of the 'gid' array in the FETCH request.</li>
            <li pn="section-4.2.1-6.2">'gname': its value is encoded as a CBOR array, containing zero or more group names. The elements of this array are encoded as text strings. Each element of index i in this CBOR array is associated with the element of index i in the 'gid' array.</li>
            <li pn="section-4.2.1-6.3">'guri': its value is encoded as a CBOR array, containing zero or more URIs, each indicating a group-membership resource. The elements of this array are encoded as text strings. Each element of index i in this CBOR array is associated with the element of index i in the 'gid' array.</li>
          </ul>
          <t indent="0" pn="section-4.2.1-7">If the KDC does not find any group associated with the specified group identifiers, the handler returns a response with the payload formatted as a CBOR byte string of zero length (0x40).</t>
          <t indent="0" pn="section-4.2.1-8">Note that the KDC only verifies that the node is authorized by the AS to access this resource. Nodes that are not members of the group but are authorized to do signature verification on the group messages may be allowed to access this resource if the application needs it.</t>
          <section anchor="retrieval-gnames" numbered="true" removeInRFC="false" toc="include" pn="section-4.2.1.1">
            <name slugifiedName="name-retrieve-group-names">Retrieve Group Names</name>
            <t indent="0" pn="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. In particular, it does so by sending a CoAP FETCH request to the /ace-group endpoint at the KDC formatted as defined in <xref target="ace-group-fetch" format="default" sectionFormat="of" derivedContent="Section 4.2.1"/>. The node can specify several group identifiers at once.</t>
            <t indent="0" pn="section-4.2.1.1-2"><xref target="fig-ace-group-fetch" format="default" sectionFormat="of" derivedContent="Figure 7"/> gives an overview of the exchanges described above, and <xref target="fig-ace-group-fetch-2" format="default" sectionFormat="of" derivedContent="Figure 8"/> shows an example.</t>
            <figure anchor="fig-ace-group-fetch" align="left" suppress-title="false" pn="figure-7">
              <name slugifiedName="name-message-flow-of-group-name-">Message Flow of Group Name and URI Retrieval Request-Response</name>
              <artset pn="section-4.2.1.1-3.1">
                <artwork type="svg" align="center" pn="section-4.2.1.1-3.1.1">
		  <svg xmlns="http://www.w3.org/2000/svg" version="1.1" viewBox="0 0 650 128" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
                    <path d="M 32,32 L 32,112" fill="none" stroke="black"/>
                    <path d="M 520,32 L 520,112" fill="none" stroke="black"/>
                    <path d="M 40,48 L 128,48" fill="none" stroke="black"/>
                    <path d="M 448,48 L 512,48" fill="none" stroke="black"/>
                    <path d="M 40,96 L 56,96" fill="none" stroke="black"/>
                    <polygon class="arrowhead" points="520,48 508,42.4 508,53.6" fill="black" transform="rotate(0,512,48)"/>
                    <polygon class="arrowhead" points="48,96 36,90.4 36,101.6" fill="black" transform="rotate(180,40,96)"/>
                    <g class="text">
                      <text x="28" y="20">Client</text>
                      <text x="520" y="20">KDC</text>
                      <text x="288" y="52">Group Name and URI Retrieval Request:</text>
                      <text x="276" y="68">FETCH /ace-group</text>
                      <text x="292" y="100">Group Name and URI Retrieval Response: 2.05 (Content) --</text>
                    </g>
                  </svg>
                </artwork>
                <artwork type="ascii-art" align="center" pn="section-4.2.1.1-3.1.2">
Client                                                         KDC
   |                                                            |
   |------------ Group Name and URI Retrieval Request: --------&gt;|
   |                      FETCH /ace-group                      |
   |                                                            |
   |&lt;-- Group Name and URI Retrieval Response: 2.05 (Content) --|
   |                                                            |
</artwork>
              </artset>
            </figure>
            <figure anchor="fig-ace-group-fetch-2" align="left" suppress-title="false" pn="figure-8">
              <name slugifiedName="name-example-of-group-name-and-u">Example of Group Name and URI Retrieval Request-Response</name>
              <artwork align="left" pn="section-4.2.1.1-4.1">

Request:

Header: FETCH (Code=0.05)
Uri-Host: "kdc.example.com"
Uri-Path: "ace-group"
Content-Format: 261 (application/ace-groupcomm+cbor)
Payload (in CBOR diagnostic notation):
{
  / gid / 0: [1, 2]
}


Response:

Header: Content (Code=2.05)
Content-Format: 261 (application/ace-groupcomm+cbor)
Payload (in CBOR diagnostic notation):
{
  / gid /   0: [1, 2],
  / gname / 1: ["group1", "group2"],
  / guri /  2: ["/ace-group/g1", "/ace-group/g2"]
}
</artwork>
            </figure>
          </section>
        </section>
      </section>
      <section anchor="ace-groupgroupname" numbered="true" removeInRFC="false" toc="include" pn="section-4.3">
        <name slugifiedName="name-ace-group-groupname">/ace-group/GROUPNAME</name>
        <t indent="0" pn="section-4.3-1">This resource implements the POST and GET handlers.</t>
        <section anchor="gid-post" numbered="true" removeInRFC="false" toc="include" pn="section-4.3.1">
          <name slugifiedName="name-post-handler">POST Handler</name>
          <t indent="0" pn="section-4.3.1-1">The POST handler processes the Join Request sent by a Client to join a group and returns a Join Response as a successful result of the joining process (see <xref target="ssec-key-distribution-exchange" format="default" sectionFormat="of" derivedContent="Section 4.3.1.1"/>). At a high level, the POST handler adds the Client to the list of current group members, adds the authentication credential of the Client to the list of the group members' authentication credentials, and returns the symmetric group keying material for the group identified by GROUPNAME.</t>
          <t indent="0" pn="section-4.3.1-2">The handler expects a request with payload formatted as a CBOR map, which <bcp14>MAY</bcp14> contain the following fields, which, if included, <bcp14>MUST</bcp14> have the format and value as specified below.</t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.3.1-3">
            <li pn="section-4.3.1-3.1">'scope': its value specifies the name of the group that the Client is attempting to join and the roles that the client wishes to have in the group. This value is encoded as a CBOR byte string wrapping one scope entry, as defined in <xref target="ssec-authorization-request" format="default" sectionFormat="of" derivedContent="Section 3.1"/>.</li>
            <li pn="section-4.3.1-3.2">
              <t indent="0" pn="section-4.3.1-3.2.1">'get_creds': it is included if the Client wishes to receive the authentication credentials of the current group members from the KDC. This parameter may be included in the Join Request if the KDC stores the authentication credentials of the group members, while it is not useful to include it if the Client obtains those authentication credentials through alternative means, e.g., from the AS. Note that including this parameter might result in a following Join Response of a large size, which can be inconvenient for resource-constrained devices.  </t>
              <t indent="0" pn="section-4.3.1-3.2.2">
If the Client wishes to retrieve the authentication credentials of all the current group members, the 'get_creds' parameter <bcp14>MUST</bcp14> encode the CBOR simple value <tt>null</tt> (0xf6). Otherwise, if the Client wishes to retrieve the authentication credentials of nodes with specific roles, the 'get_creds' parameter <bcp14>MUST</bcp14> encode a non-empty CBOR array containing the three elements 'inclusion_flag', 'role_filter', and 'id_filter', as defined below.  </t>
              <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.3.1-3.2.3">
                <li pn="section-4.3.1-3.2.3.1">The first element, namely 'inclusion_flag', encodes the CBOR simple value <tt>true</tt> (0xf5) if the Client wishes to receive the authentication credentials of the nodes having their node identifier specified in 'id_filter' (i.e., selection by inclusive filtering). Instead, this element encodes the CBOR simple value <tt>false</tt> (0xf4) if the Client wishes to receive the authentication credentials of the nodes that do not have the node identifiers specified in the third element 'id_filter' (i.e., selection by exclusive filtering). In the Join Request, this parameter encodes the CBOR simple value <tt>true</tt> (0xf5).</li>
                <li pn="section-4.3.1-3.2.3.2">
                  <t indent="0" pn="section-4.3.1-3.2.3.2.1">The second element, namely 'role_filter', is a CBOR array. Each element of the array contains one role or a combination of roles for the group identified by GROUPNAME. This parameter indicates that the Client wishes to receive the authentication credentials of all the group members having any of the specified roles or combination of roles (i.e., having any of those single roles or at least all the roles indicated in any of those combinations of roles).      </t>
                  <t indent="0" pn="section-4.3.1-3.2.3.2.2">
For example, the array ["role1", "role2+role3"] indicates that the Client wishes to receive the authentication credentials of all group members that have at least "role1" or at least both "role2" and "role3". In the Join Request, this parameter is a non-empty array.</t>
                </li>
                <li pn="section-4.3.1-3.2.3.3">
                  <t indent="0" pn="section-4.3.1-3.2.3.3.1">The third element, namely 'id_filter', is a CBOR array. Each element of the array contains a node identifier of a group member for the group identified by GROUPNAME. This parameter indicates that the Client wishes to receive the authentication credentials of the nodes that have or do not have the specified node identifiers based on the value of 'inclusion_flag' (i.e., as a selection by inclusive or exclusive filtering). In the Join Request, the Client does not filter authentication credentials based on node identifiers, so this parameter is an empty array.      </t>
                  <t indent="0" pn="section-4.3.1-3.2.3.3.2">
In fact, when first joining the group, the Client is not expected or capable to express a filter based on node identifiers of other group members. Instead, when already a group member and sending a Join Request to rejoin, the Client is not expected to include the 'get_creds' parameter in the Join Request altogether, since it can rather retrieve authentication credentials associated with specific group identifiers as defined in <xref target="sec-key-retrieval" format="default" sectionFormat="of" derivedContent="Section 4.4.1.1"/>.</t>
                </li>
              </ul>
              <t indent="0" pn="section-4.3.1-3.2.4">
The CDDL definition <xref target="RFC8610" format="default" sectionFormat="of" derivedContent="RFC8610"/> of 'get_creds' is given in <xref target="cddl-ex-getpubkeys" format="default" sectionFormat="of" derivedContent="Figure 9"/>; as an example, it uses node identifiers encoded as CBOR byte strings, role identifiers encoded as CBOR text strings, and combinations of roles encoded as CBOR arrays of role identifiers.  </t>
              <t indent="0" pn="section-4.3.1-3.2.5">
Note that, for this handler, 'inclusion_flag' is always set to true and 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.</t>
              <figure anchor="cddl-ex-getpubkeys" align="left" suppress-title="false" pn="figure-9">
                <name slugifiedName="name-cddl-definition-of-get_cred">CDDL Definition of 'get_creds', Using an Example Node Identifier Encoded as bstr and Role as tstr</name>
                <sourcecode type="cddl" markers="false" pn="section-4.3.1-3.2.6.1">
inclusion_flag = bool

role = tstr
comb_role = [2* role]
role_filter = [* ( role / comb_role )]

id = bstr
id_filter = [* id]

get_creds = null / [inclusion_flag, role_filter, id_filter]
</sourcecode>
              </figure>
            </li>
            <li pn="section-4.3.1-3.3">'client_cred': encoded as a CBOR byte string, whose value is the original binary representation of the Client's authentication credential. This parameter <bcp14>MUST</bcp14> be present if the KDC is managing (collecting from and distributing to Clients) the authentication credentials of the group members and the Client's role in the group will require the Client to send messages to one or more group members. It is <bcp14>REQUIRED</bcp14> for application profiles to define the specific formats that are acceptable to use for authentication credentials in the group (<xref target="req6" format="none" sectionFormat="of" derivedContent="">REQ6</xref>).</li>
            <li pn="section-4.3.1-3.4">'cnonce': encoded as a CBOR byte string, whose value is a dedicated nonce N_C generated by the Client. This parameter <bcp14>MUST</bcp14> be present.</li>
            <li pn="section-4.3.1-3.5">
              <t indent="0" pn="section-4.3.1-3.5.1">'client_cred_verify': encoded as a CBOR byte string. This parameter <bcp14>MUST</bcp14> be present if the 'client_cred' parameter is present and no authentication credential associated with the Client's access token can be retrieved for that group.  </t>
              <t indent="0" pn="section-4.3.1-3.5.2">
The value of the CBOR byte string is the proof-of-possession (PoP) evidence computed by the Client over the following PoP input: the scope (encoded as a CBOR byte string) concatenated with N_S (encoded as a CBOR byte string) concatenated with N_C (encoded as a CBOR byte string), where:  </t>
              <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.3.1-3.5.3">
                <li pn="section-4.3.1-3.5.3.1">scope is either specified in the 'scope' parameter above, if present, or a default scope entry that the handler is expected to know otherwise;</li>
                <li pn="section-4.3.1-3.5.3.2">N_S is the challenge received from the KDC in the 'kdcchallenge' parameter of the 2.01 (Created) response to the Token Transfer Request (see <xref target="token-post" format="default" sectionFormat="of" derivedContent="Section 3.3"/>), encoded as a CBOR byte string; and</li>
                <li pn="section-4.3.1-3.5.3.3">N_C is the nonce generated by the Client and specified in the 'cnonce' parameter above, encoded as a CBOR byte string.</li>
              </ul>
              <t indent="0" pn="section-4.3.1-3.5.4">
An example of PoP input to compute 'client_cred_verify' using CBOR encoding is given in <xref target="fig-client-cred-input" format="default" sectionFormat="of" derivedContent="Figure 10"/>.  </t>
              <t indent="0" pn="section-4.3.1-3.5.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 <bcp14>MUST</bcp14> specify the exact approaches used to compute the PoP evidence to include in 'client_cred_verify' and <bcp14>MUST</bcp14> specify which of those approaches is used in which case (<xref target="req14" format="none" sectionFormat="of" derivedContent="">REQ14</xref>).  </t>
              <t indent="0" pn="section-4.3.1-3.5.6">
If the access token was not provided to the KDC through a Token Transfer Request (e.g., the access token is instead transferred during the establishment of a secure communication association), it is <bcp14>REQUIRED</bcp14> of the specific application profile to define how the challenge N_S is generated (<xref target="req15" format="none" sectionFormat="of" derivedContent="">REQ15</xref>).</t>
            </li>
            <li pn="section-4.3.1-3.6">'creds_repo': it can be present if the format of the Client's authentication credential conveyed in the 'client_cred' parameter is a certificate. In such a case, this parameter has as its value the URI of the certificate. This parameter is encoded as a CBOR text string. Alternative specific encodings of this parameter <bcp14>MAY</bcp14> be defined in application profiles of this specification (<xref target="opt6" format="none" sectionFormat="of" derivedContent="">OPT6</xref>).</li>
            <li pn="section-4.3.1-3.7">
              <t indent="0" pn="section-4.3.1-3.7.1">'control_uri': its value is a full URI, encoded as a CBOR text string. A default url-path is /ace-group/GROUPNAME/node, although implementations can use different ones instead. The URI <bcp14>MUST NOT</bcp14> have url-path /ace-group/GROUPNAME.  </t>
              <t indent="0" pn="section-4.3.1-3.7.2">
If 'control_uri' is specified in the Join Request, the Client acts as a CoAP server and hosts a resource at this specific URI. The KDC <bcp14>MAY</bcp14> use this URI to send CoAP requests to the Client (acting as a CoAP server in this exchange), for example, for one-to-one provisioning of new group keying material when performing a group rekeying (see <xref target="point-to-point-rekeying" format="default" sectionFormat="of" derivedContent="Section 6.1"/>) or to inform the Client of its removal from the group (see <xref target="sec-node-removal" format="default" sectionFormat="of" derivedContent="Section 5"/>).  </t>
              <t indent="0" pn="section-4.3.1-3.7.3">
In particular, this resource is intended for communications exclusively concerning the group identified by GROUPNAME and whose group name is specified in the 'scope' parameter of the Join Request, if present therein. If the KDC does not implement mechanisms using this resource for that group, it can ignore this parameter. Other additional functionalities of this resource <bcp14>MAY</bcp14> be defined in application profiles of this specifications (<xref target="opt7" format="none" sectionFormat="of" derivedContent="">OPT7</xref>).</t>
            </li>
          </ul>
          <figure anchor="fig-client-cred-input" align="left" suppress-title="false" pn="figure-10">
            <name slugifiedName="name-example-of-pop-input-to-com">Example of PoP Input to Compute 'client_cred_verify' Using CBOR Encoding</name>
            <artwork align="left" pn="section-4.3.1-4.1">
scope, N_S, and N_C expressed in CBOR diagnostic notation:
  scope = h'826667726f7570316673656e646572'
  N_S   = h'018a278f7faab55a'
  N_C   = h'25a8991cd700ac01'


scope, N_S, and N_C as CBOR encoded byte strings:
  scope = 0x4f826667726f7570316673656e646572
  N_S   = 0x48018a278f7faab55a
  N_C   = 0x4825a8991cd700ac01

PoP input:
  0x4f 826667726f7570316673656e646572
    48 018a278f7faab55a 48 25a8991cd700ac01
</artwork>
          </figure>
          <t indent="0" pn="section-4.3.1-5">If the request does not include the 'scope'  parameter, the KDC is expected to understand what roles the Client is requesting to join the group with. For example, as per the access token, the Client might have been granted access to the group with only one role. If the KDC cannot determine which exact roles should be considered for the Client, it <bcp14>MUST</bcp14> reply with a 4.00 (Bad Request) error response.</t>
          <t indent="0" pn="section-4.3.1-6">The handler considers the scope specified in the access token associated with the Client and checks the scope entry related to the group identified by the GROUPNAME associated with the endpoint. In particular, the handler checks whether the set of roles specified in that scope entry includes all the roles that the Client wishes to have in the group as per the Join Request. If this is not the case, the KDC <bcp14>MUST</bcp14> reply with a 4.03 (Forbidden) error response.</t>
          <t indent="0" pn="section-4.3.1-7">If the KDC manages the group members' authentication credentials, the handler checks if one is included in the 'client_cred' parameter. If so, the KDC retrieves the authentication credential and performs the following actions.</t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.3.1-8">
            <li pn="section-4.3.1-8.1">If the access token was provided through a Token Transfer Request (see <xref target="token-post" format="default" sectionFormat="of" derivedContent="Section 3.3"/>) but the KDC cannot retrieve the 'kdcchallenge' associated with this Client (see <xref target="token-post" format="default" sectionFormat="of" derivedContent="Section 3.3"/>), the KDC <bcp14>MUST</bcp14> reply with a 4.00 (Bad Request) error response, which <bcp14>MUST</bcp14> also have Content-Format "application/ace-groupcomm+cbor". The payload of the error response is a CBOR map including a newly generated 'kdcchallenge' value, which is specified in the 'kdcchallenge' parameter. The KDC <bcp14>MUST</bcp14> store the newly generated value as the 'kdcchallenge' value associated with this Client, replacing the currently stored value (if any).</li>
            <li pn="section-4.3.1-8.2">
              <t indent="0" pn="section-4.3.1-8.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.  </t>
              <t indent="0" pn="section-4.3.1-8.2.2">
If this verification fails, the handler <bcp14>MUST</bcp14> reply with a 4.00 (Bad Request) error response. The response <bcp14>MUST</bcp14> have Content-Format "application/concise-problem-details+cbor" and is formatted as defined in <xref target="kdc-if-errors" format="default" sectionFormat="of" derivedContent="Section 4.1.2"/>. Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' field  <bcp14>MUST</bcp14> be set to 2 ("Authentication credential incompatible with the group configuration").</t>
            </li>
            <li pn="section-4.3.1-8.3">
              <t indent="0" pn="section-4.3.1-8.3.1">The KDC verifies the PoP evidence conveyed in the 'client_cred_verify' parameter. Application profiles of this specification <bcp14>MUST</bcp14> specify the exact approaches used to verify the PoP evidence and <bcp14>MUST</bcp14> specify which of those approaches is used in which case (<xref target="req14" format="none" sectionFormat="of" derivedContent="">REQ14</xref>).  </t>
              <t indent="0" pn="section-4.3.1-8.3.2">
If the PoP evidence does not pass verification, the handler <bcp14>MUST</bcp14> reply with a 4.00 (Bad Request) error response. The response <bcp14>MUST</bcp14> have Content-Format  "application/concise-problem-details+cbor" and is formatted as defined in <xref target="kdc-if-errors" format="default" sectionFormat="of" derivedContent="Section 4.1.2"/>. Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' field  <bcp14>MUST</bcp14> be set to 3 ("Invalid proof-of-possession evidence").</t>
            </li>
          </ul>
          <t indent="0" pn="section-4.3.1-9">If no authentication credential is conveyed in the 'client_cred' parameter, the handler checks if the KDC currently stores an authentication credential that is associated with the access token and with the group identified by GROUPNAME (see also <xref target="ssec-key-distribution-exchange" format="default" sectionFormat="of" derivedContent="Section 4.3.1.1"/>). 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.</t>
          <t indent="0" pn="section-4.3.1-10">If an eligible authentication credential for the Client is neither present in the 'client_cred' parameter nor retrieved from the stored ones at the KDC, it is <bcp14>RECOMMENDED</bcp14> that the handler stops the processing and replies with a 4.00 (Bad Request) error response. Application profiles <bcp14>MAY</bcp14> define alternatives (<xref target="opt8" format="none" sectionFormat="of" derivedContent="">OPT8</xref>).</t>
          <t indent="0" pn="section-4.3.1-11">If, regardless of the reason, the KDC replies with a 4.00 (Bad Request) error response, the payload of the response <bcp14>MAY</bcp14> be a CBOR map. For instance, the CBOR map can include a 'sign_info' parameter formatted as 'sign_info_resp' defined in <xref target="sign-info" format="default" sectionFormat="of" derivedContent="Section 3.3.1"/>, with the 'cred_fmt' element set to the CBOR simple value <tt>null</tt> (0xf6) if the Client sent its own authentication credential and the KDC is not set to store authentication credentials of the group members. When the response payload is a CBOR map including such parameters, the error response has Content-Format "application/ace-groupcomm+cbor".</t>
          <t indent="0" pn="section-4.3.1-12">If all the verifications above succeed, the KDC proceeds as follows.</t>
          <t indent="0" pn="section-4.3.1-13">First, only in case the Client is not already a group member, the handler performs the following actions:</t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.3.1-14">
            <li pn="section-4.3.1-14.1">The handler adds the Client to the list of current members of the group.</li>
            <li pn="section-4.3.1-14.2">The handler assigns a name NODENAME to the Client and creates a sub-resource to /ace-group/GROUPNAME at the KDC, i.e., /ace-group/GROUPNAME/nodes/NODENAME.</li>
            <li pn="section-4.3.1-14.3">The handler associates the node identifier NODENAME with the access token and the secure communication association for the Client.</li>
          </ul>
          <t indent="0" pn="section-4.3.1-15">Then, the handler performs the following actions.</t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.3.1-16">
            <li pn="section-4.3.1-16.1">
              <t indent="0" pn="section-4.3.1-16.1.1">If the KDC manages the group members' authentication credentials:  </t>
              <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.3.1-16.1.2">
                <li pn="section-4.3.1-16.1.2.1">The handler associates the retrieved Client's authentication credential with the tuple composed of the node name NODENAME, the group name GROUPNAME, and the access token.</li>
                <li pn="section-4.3.1-16.1.2.2">The handler adds the retrieved Client's authentication credential to the list of authentication credentials stored for the group identified by GROUPNAME. If such a list already includes an authentication credential for the Client, but a different authentication credential is specified in the 'client_cred' parameter, then the handler <bcp14>MUST</bcp14> replace the old authentication credential in the list with the one specified in the 'client_cred' parameter.</li>
              </ul>
            </li>
            <li pn="section-4.3.1-16.2">If backward security is prescribed by application policies installed at the KDC or by the used application profile of this specification, then the KDC <bcp14>MUST</bcp14> generate new group keying material and securely distribute it to the current group members (see <xref target="sec-group-rekeying" format="default" sectionFormat="of" derivedContent="Section 6"/>).</li>
            <li pn="section-4.3.1-16.3">The handler returns a successful Join Response, as defined below, which contains the symmetric group keying material, the group policies, and the authentication credentials of the current members of the group if the KDC manages those and the Client requested those.</li>
          </ul>
          <t indent="0" pn="section-4.3.1-17">The Join Response <bcp14>MUST</bcp14> have response code 2.01 (Created) if the Client has been added to the list of group members in this join exchange (see above) or 2.04 (Changed) otherwise, i.e., if the Client is rejoining the group without having left it.</t>
          <t indent="0" pn="section-4.3.1-18">The Join Response message <bcp14>MUST</bcp14> include the Location-Path CoAP Options, specifying the path to the sub-resource associated with the Client, i.e., /ace-group/GROUPNAME/nodes/NODENAME.</t>
          <t indent="0" pn="section-4.3.1-19">The Join Response message <bcp14>MUST</bcp14> have Content-Format "application/ace-groupcomm+cbor". The payload of the response is formatted as a CBOR map, which <bcp14>MUST</bcp14> contain the following fields with the values specified below:</t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.3.1-20">
            <li pn="section-4.3.1-20.1">'gkty': identifying the key type of the keying material specified in the 'key' parameter. This parameter is encoded as a CBOR integer or a CBOR text string. Possible values are taken from the "Key Type Value" column of the "ACE Groupcomm Key Types" registry defined in <xref target="iana-key" format="default" sectionFormat="of" derivedContent="Section 11.8"/> of this specification. Implementations <bcp14>MUST</bcp14> verify that the key type specified by this parameter matches the application profile being used and, if applicable, that such an application profile is listed in the "Profile" column of the "ACE Groupcomm Key Types" registry for the key type in question.</li>
            <li pn="section-4.3.1-20.2">'key': containing the keying material used for securing the group communication or information required to derive such keying material.</li>
            <li pn="section-4.3.1-20.3">'num': containing the current version number of the group keying material, encoded as a CBOR integer. The version number has a value that increases in a strictly monotonic way as the group keying material changes. The application profile <bcp14>MUST</bcp14> define the initial value of the version number (<xref target="req16" format="none" sectionFormat="of" derivedContent="">REQ16</xref>).</li>
          </ul>
          <t indent="0" pn="section-4.3.1-21">The format of the keying material conveyed in the 'key' parameter <bcp14>MUST</bcp14> be defined in application profiles of this specification (<xref target="req17" format="none" sectionFormat="of" derivedContent="">REQ17</xref>), together with corresponding key types to specify as value of the 'gkty' parameter and that are accepted by the application (<xref target="req18" format="none" sectionFormat="of" derivedContent="">REQ18</xref>). Additionally, documents specifying a type of keying material <bcp14>MUST</bcp14> register an entry in the "ACE Groupcomm Key Types" registry defined in <xref target="iana-key" format="default" sectionFormat="of" derivedContent="Section 11.8"/>, including its name, the corresponding key type to specify as value for the 'gkty' parameter, and the application profile to be used with.</t>
          <table anchor="fig-gkty" align="center" pn="table-1">
            <name slugifiedName="name-ace-groupcomm-key-types">ACE Groupcomm Key Types</name>
            <thead>
              <tr>
                <th align="left" colspan="1" rowspan="1">Name</th>
                <th align="left" colspan="1" rowspan="1">Key Type Value</th>
                <th align="left" colspan="1" rowspan="1">Profile</th>
                <th align="left" colspan="1" rowspan="1">Description</th>
                <th align="left" colspan="1" rowspan="1">Reference</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="left" colspan="1" rowspan="1">Reserved</td>
                <td align="left" colspan="1" rowspan="1">0</td>
                <td align="left" colspan="1" rowspan="1"/>
                <td align="left" colspan="1" rowspan="1">This value is reserved</td>
                <td align="left" colspan="1" rowspan="1">RFC 9594</td>
              </tr>
            </tbody>
          </table>
          <t indent="0" pn="section-4.3.1-23">The Join Response <bcp14>SHOULD</bcp14> contain the following fields with the values specified below:</t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.3.1-24">
            <li pn="section-4.3.1-24.1">'exp': its value specifies the expiration time of the group keying material specified in the 'key' parameter, encoded as a CBOR unsigned integer. The value is the number of seconds from 1970-01-01T00:00:00Z UTC until the specified UTC date/time, ignoring leap seconds, analogous to what is specified for NumericDate in <xref section="2" sectionFormat="of" target="RFC7519" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7519#section-2" derivedContent="RFC7519"/>. After the time indicated in this parameter, group members <bcp14>MUST NOT</bcp14> use the group keying material specified in the 'key' parameter. The group members can retrieve the latest group keying material from the KDC.</li>
            <li pn="section-4.3.1-24.2">'exi': its value specifies the residual lifetime of the group keying material, encoded as a CBOR unsigned integer. If the 'exp' parameter is included, this parameter <bcp14>MUST</bcp14> also be included. The value represents the residual lifetime of the group keying material specified in the 'key' parameter, i.e., it is the number of seconds between the current time at the KDC and the time when the keying material expires (as specified in the 'exp' parameter, if present). A Client determines the expiration time of the keying material by adding the seconds specified in the 'exi' parameter to its current time upon receiving the Join Response containing the 'exi' parameter. After such an expiration time, the Client <bcp14>MUST NOT</bcp14> use the group keying material specified in the 'key' parameter. The Client can retrieve the latest group keying material from the KDC.</li>
          </ul>
          <t indent="0" pn="section-4.3.1-25">If a Client has a reliable way to synchronize its internal clock with UTC, and both the 'exp' and 'exi' parameters are present, then the Client <bcp14>MUST</bcp14> use the 'exp' parameter value as expiration time for the group keying material. Otherwise, the Client uses the 'exi' parameter value to determine the expiration time as defined above.</t>
          <t indent="0" pn="section-4.3.1-26">When a Client relies on the 'exi' parameter, the expiration time that it computes is offset in the future with respect to the actual expiration time as intended by the KDC and specified in the 'exp' parameter (if present). Such an offset is the amount of time between when the KDC sends the response message including the 'exi' parameter and when the Client receives that message. That is, especially if the delivery of the response to the Client is delayed, the Client will believe the keying material to be valid for a longer time than the KDC actually means. However, before approaching the actual expiration time, the KDC is expected to rekey the group and distribute new keying material (see <xref target="sec-group-rekeying" format="default" sectionFormat="of" derivedContent="Section 6"/>).</t>
          <t indent="0" pn="section-4.3.1-27">Optionally, the Join Response <bcp14>MAY</bcp14> contain the following parameters, which, if included, <bcp14>MUST</bcp14> have the format and value as specified below.</t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.3.1-28">
            <li pn="section-4.3.1-28.1">
              <t indent="0" pn="section-4.3.1-28.1.1">'ace_groupcomm_profile': its value is encoded as a CBOR integer and <bcp14>MUST</bcp14> be used to uniquely identify the application profile for group communication. Applications of this specification <bcp14>MUST</bcp14> register an application profile identifier and the related value for this parameter in the "ACE Groupcomm Profiles" registry (<xref target="req19" format="none" sectionFormat="of" derivedContent="">REQ19</xref>).</t>
              <table anchor="ace-groupcomm-profile-0" align="center" pn="table-2">
                <name slugifiedName="name-ace-groupcomm-profiles">ACE Groupcomm Profiles</name>
                <thead>
                  <tr>
                    <th align="left" colspan="1" rowspan="1">Name</th>
                    <th align="left" colspan="1" rowspan="1">Description</th>
                    <th align="left" colspan="1" rowspan="1">CBOR Value</th>
                    <th align="left" colspan="1" rowspan="1">Reference</th>
                  </tr>
                </thead>
                <tbody>
                  <tr>
                    <td align="left" colspan="1" rowspan="1">Reserved</td>
                    <td align="left" colspan="1" rowspan="1">This value is reserved</td>
                    <td align="left" colspan="1" rowspan="1">0</td>
                    <td align="left" colspan="1" rowspan="1">RFC 9594</td>
                  </tr>
                </tbody>
              </table>
            </li>
            <li pn="section-4.3.1-28.2">'creds': it <bcp14>MUST</bcp14> be present if 'get_creds' was present in the Join Request; otherwise, it <bcp14>MUST NOT</bcp14> be present. Its value is encoded as 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 Join Request. In particular, each element of the array is a CBOR byte string, whose value is the original binary representation of a group member's authentication credential. It is <bcp14>REQUIRED</bcp14> for application profiles to define the specific formats of authentication credentials that are acceptable to use in the group (<xref target="req6" format="none" sectionFormat="of" derivedContent="">REQ6</xref>).</li>
            <li pn="section-4.3.1-28.3">
              <t indent="0" pn="section-4.3.1-28.3.1">'peer_roles': it <bcp14>SHOULD</bcp14> be present if 'creds' is also present; otherwise, it <bcp14>MUST NOT</bcp14> be present. Its value is encoded as a CBOR array of n elements, where n is 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 role(s) that the group member associated with the i-th authentication credential in 'creds' has in the group. In particular, each array element is encoded like the role element of a scope entry, which is consistent with the used format (see <xref target="ssec-authorization-request" format="default" sectionFormat="of" derivedContent="Section 3.1"/>).  </t>
              <t indent="0" pn="section-4.3.1-28.3.2">
This parameter <bcp14>MAY</bcp14> be omitted if the Client can rely on other means to unambiguously gain knowledge of the role of each group member whose associated authentication credential is specified in the 'creds' parameter. For example, all such group members may have the same role in the group joined by the Client, and such a role can be unambiguously assumed by the Client (e.g., based on what is defined in the used application profile of this specification). As another example, each of the authentication credentials specified in the 'creds' parameter can indicate the role(s) that the corresponding group member has in the group joined by the Client.  </t>
              <t indent="0" pn="section-4.3.1-28.3.3">
When receiving the authentication credential of a Client in the 'client_cred' parameter of a Join Request (see <xref target="ssec-key-distribution-exchange" format="default" sectionFormat="of" derivedContent="Section 4.3.1.1"/>) or of an Authentication Credential Update Request (see <xref target="update-pub-key" format="default" sectionFormat="of" derivedContent="Section 4.9.1.1"/>), 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 whether to include the 'peer_roles' parameter, depending on the specific set of authentication credentials specified in the 'creds' parameter of that Join Response.</t>
            </li>
            <li pn="section-4.3.1-28.4">'peer_identifiers': it <bcp14>MUST</bcp14> be present if 'creds' is also present; otherwise, it <bcp14>MUST NOT</bcp14> be present. Its value is encoded as a CBOR array of n elements, where n is 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, whose value is the node identifier of the group member. The specific format of node identifiers of group members is specified by the application profile (<xref target="req25" format="none" sectionFormat="of" derivedContent="">REQ25</xref>).</li>
            <li pn="section-4.3.1-28.5">
              <t indent="0" pn="section-4.3.1-28.5.1">'group_policies': its value is encoded as a CBOR map, whose elements specify how the group handles specific management aspects. These include, for instance, approaches to achieve synchronization of sequence numbers among group members. The possible elements of the CBOR map are registered in the "ACE Groupcomm Policies" registry defined in <xref target="ace-groupcomm-policies" format="default" sectionFormat="of" derivedContent="Section 11.10"/> of this specification. This specification defines the three elements "Sequence Number Synchronization Methods", "Key Update Check Interval", and "Expiration Delta", which are summarized in <xref target="fig-ACE-Groupcomm-Policies" format="default" sectionFormat="of" derivedContent="Table 3"/>. Application profiles of this specification <bcp14>MUST</bcp14> specify the format and default values for the entries of the CBOR map conveyed in the 'group_policies' parameter (<xref target="req20" format="none" sectionFormat="of" derivedContent="">REQ20</xref>).</t>
              <table anchor="fig-ACE-Groupcomm-Policies" align="center" pn="table-3">
                <name slugifiedName="name-ace-groupcomm-policies">ACE Groupcomm Policies</name>
                <thead>
                  <tr>
                    <th align="left" colspan="1" rowspan="1">Name</th>
                    <th align="left" colspan="1" rowspan="1">CBOR Label</th>
                    <th align="left" colspan="1" rowspan="1">CBOR Type</th>
                    <th align="left" colspan="1" rowspan="1">Description</th>
                    <th align="left" colspan="1" rowspan="1">Reference</th>
                  </tr>
                </thead>
                <tbody>
                  <tr>
                    <td align="left" colspan="1" rowspan="1">Sequence Number Synchronization Method</td>
                    <td align="left" colspan="1" rowspan="1">0</td>
                    <td align="left" colspan="1" rowspan="1">int or tstr</td>
                    <td align="left" colspan="1" rowspan="1"> Method for recipient group members to synchronize with sequence numbers of sender group members. Its value is taken from the "Value" column of the "Sequence Number Synchronization Method" registry.</td>
                    <td align="left" colspan="1" rowspan="1">RFC 9594</td>
                  </tr>
                  <tr>
                    <td align="left" colspan="1" rowspan="1">Key Update Check Interval</td>
                    <td align="left" colspan="1" rowspan="1">1</td>
                    <td align="left" colspan="1" rowspan="1">int</td>
                    <td align="left" colspan="1" rowspan="1">Polling interval in seconds, for group members to check at the KDC if the latest group keying material is the one that they store.</td>
                    <td align="left" colspan="1" rowspan="1">RFC 9594</td>
                  </tr>
                  <tr>
                    <td align="left" colspan="1" rowspan="1">Expiration Delta</td>
                    <td align="left" colspan="1" rowspan="1">2</td>
                    <td align="left" colspan="1" rowspan="1">uint</td>
                    <td align="left" colspan="1" rowspan="1">Number of seconds from 'exp' until a UTC date/time, after which group members <bcp14>MUST</bcp14> stop using the group keying material that they store to decrypt incoming messages.</td>
                    <td align="left" colspan="1" rowspan="1">RFC 9594</td>
                  </tr>
                </tbody>
              </table>
            </li>
            <li pn="section-4.3.1-28.6">
              <t indent="0" pn="section-4.3.1-28.6.1">'kdc_cred': its value is the original binary representation of the KDC's authentication credential, encoded as a CBOR byte string. This parameter is used if the KDC has an associated authentication credential and this is required for the correct group operation. It is <bcp14>REQUIRED</bcp14> for application profiles to define whether the KDC has an authentication credential as required for the correct group operation and if this has to be provided through the 'kdc_cred' parameter (<xref target="req8" format="none" sectionFormat="of" derivedContent="">REQ8</xref>).  </t>
              <t indent="0" pn="section-4.3.1-28.6.2">
If the KDC has an authentication credential as required for the correct group operation, the KDC's authentication credential <bcp14>MUST</bcp14> have the same format used for the authentication credentials of the group members. It is <bcp14>REQUIRED</bcp14> for application profiles to define the specific formats that are acceptable to use for the authentication credentials in the group (<xref target="req6" format="none" sectionFormat="of" derivedContent="">REQ6</xref>).</t>
            </li>
            <li pn="section-4.3.1-28.7">'kdc_nonce': its value is a dedicated nonce N_KDC generated by the KDC, encoded as a CBOR byte string. This parameter <bcp14>MUST</bcp14> be present if the 'kdc_cred' parameter is present.</li>
            <li pn="section-4.3.1-28.8">
              <t indent="0" pn="section-4.3.1-28.8.1">'kdc_cred_verify': its value is as defined below and is encoded as a CBOR byte string. This parameter <bcp14>MUST</bcp14> be present if the 'kdc_cred' parameter is present.  </t>
              <t indent="0" pn="section-4.3.1-28.8.2">
The value of this parameter is the proof-of-possession (PoP) evidence computed by the KDC over the following PoP input: the nonce N_C (encoded as a CBOR byte string) concatenated with the nonce N_KDC (encoded as a CBOR byte string), where:  </t>
              <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.3.1-28.8.3">
                <li pn="section-4.3.1-28.8.3.1">N_C is the nonce generated by the Client and specified in the 'cnonce' parameter of the Join Request.</li>
                <li pn="section-4.3.1-28.8.3.2">N_KDC is the nonce generated by the KDC and specified in the 'kdc_nonce' parameter.</li>
              </ul>
              <t indent="0" pn="section-4.3.1-28.8.4">
An example of PoP input to compute 'kdc_cred_verify' using CBOR encoding is given in <xref target="fig-kdc-cred-input" format="default" sectionFormat="of" derivedContent="Figure 11"/>.  </t>
              <t indent="0" pn="section-4.3.1-28.8.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 conveyed in the 'kdc_cred' parameter. Application profiles of this specification <bcp14>MUST</bcp14> specify the approaches used by the KDC to compute the PoP evidence to include in 'kdc_cred_verify' and <bcp14>MUST</bcp14> specify which of those approaches is used in which case (<xref target="req21" format="none" sectionFormat="of" derivedContent="">REQ21</xref>).</t>
            </li>
            <li pn="section-4.3.1-28.9">
              <t indent="0" pn="section-4.3.1-28.9.1">'rekeying_scheme': identifying the rekeying scheme that the KDC uses to provide new group keying material to the group members. The value of this parameter is encoded as a CBOR integer and is taken from the "Value" column of the "ACE Groupcomm Rekeying Schemes" registry defined in <xref target="iana-ace-groupcomm-rekeying-schemes" format="default" sectionFormat="of" derivedContent="Section 11.13"/> of this specification.</t>
              <table anchor="rekeying-scheme-0" align="center" pn="table-4">
                <name slugifiedName="name-ace-groupcomm-rekeying-sche">ACE Groupcomm Rekeying Schemes</name>
                <thead>
                  <tr>
                    <th align="left" colspan="1" rowspan="1">Value</th>
                    <th align="left" colspan="1" rowspan="1">Name</th>
                    <th align="left" colspan="1" rowspan="1">Description</th>
                    <th align="left" colspan="1" rowspan="1">Reference</th>
                  </tr>
                </thead>
                <tbody>
                  <tr>
                    <td align="left" colspan="1" rowspan="1">0</td>
                    <td align="left" colspan="1" rowspan="1">Point-to-Point</td>
                    <td align="left" colspan="1" rowspan="1">The KDC individually targets each node to rekey, using the pairwise secure communication association with that node</td>
                    <td align="left" colspan="1" rowspan="1">RFC 9594</td>
                  </tr>
                </tbody>
              </table>
              <t indent="0" pn="section-4.3.1-28.9.3">Application profiles of this specification <bcp14>MAY</bcp14> define a default group rekeying scheme to refer to in case the 'rekeying_scheme' parameter is not included in the Join Response (<xref target="opt9" format="none" sectionFormat="of" derivedContent="">OPT9</xref>).</t>
            </li>
            <li pn="section-4.3.1-28.10">
              <t indent="0" pn="section-4.3.1-28.10.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 <bcp14>MUST NOT</bcp14> 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 schemes may not require specific administrative keying material to be provided, e.g., the basic "Point-to-Point" group rekeying scheme (see <xref target="point-to-point-rekeying" format="default" sectionFormat="of" derivedContent="Section 6.1"/>).  </t>
              <t indent="0" pn="section-4.3.1-28.10.2">
In more advanced group rekeying schemes, the administrative keying material can be composed of multiple keys organized, for instance, into a logical tree hierarchy, whose root key is the only administrative key shared by all the group members. In such a case, each group member is exclusively associated with one leaf key in the hierarchy and stores only the administrative keys from the associated leaf key all the way up along the path to the root key. That is, different group members can be provided with a different subset of the overall administrative keying material.  </t>
              <t indent="0" pn="section-4.3.1-28.10.3">
		It is expected from separate documents to define how the advanced group rekeying scheme, possibly indicated in the 'rekeying_scheme' parameter, is used by an application profile of this specification. This includes defining the format of the administrative keying material to specify in 'mgt_key_material' consistently with the group rekeying scheme and the application profile in question.</t>
            </li>
            <li pn="section-4.3.1-28.11">
              <t indent="0" pn="section-4.3.1-28.11.1">'control_group_uri': its value is a full URI, encoded as a CBOR text string. The URI <bcp14>MUST</bcp14> specify addressing information intended to reach all the members in the group. For example, this can be a multicast IP address, optionally together with a port number that, if omitted, defaults to 5683, i.e., the default port number for the "coap" URI scheme (see <xref section="6.1" sectionFormat="of" target="RFC7252" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7252#section-6.1" derivedContent="RFC7252"/>). The URI <bcp14>MUST</bcp14> include GROUPNAME in the url-path. A default url-path is /ace-group/GROUPNAME, although implementations can use different ones instead. The URI <bcp14>MUST NOT</bcp14> have url-path /ace-group/GROUPNAME/nodes.  </t>
              <t indent="0" pn="section-4.3.1-28.11.2">
If 'control_group_uri' is included in the Join Response, the Clients supporting this parameter act as CoAP servers, host a resource at this specific URI, and listen to the specified addressing information.  </t>
              <t indent="0" pn="section-4.3.1-28.11.3">
The KDC <bcp14>MAY</bcp14> use this URI to send one-to-many CoAP requests to the Client group members (acting as CoAP servers in this exchange), for example, for one-to-many provisioning of new group keying material when performing a group rekeying (see <xref target="one-to-many-rekeying" format="default" sectionFormat="of" derivedContent="Section 6.2"/>) or to inform the Clients of their removal from the group (see <xref target="sec-node-removal" format="default" sectionFormat="of" derivedContent="Section 5"/>).  </t>
              <t indent="0" pn="section-4.3.1-28.11.4">
In particular, this resource is intended for communications exclusively concerning the group identified by GROUPNAME and whose group name was specified in the 'scope' parameter of the Join Request, if present. If the KDC does not implement mechanisms using this resource for that group, it can ignore this parameter. Other additional functionalities of this resource <bcp14>MAY</bcp14> be defined in application profiles of this specifications (<xref target="opt10" format="none" sectionFormat="of" derivedContent="">OPT10</xref>).</t>
            </li>
          </ul>
          <figure anchor="fig-kdc-cred-input" align="left" suppress-title="false" pn="figure-11">
            <name slugifiedName="name-example-of-pop-input-to-comp">Example of PoP Input to Compute 'kdc_cred_verify' Using CBOR Encoding</name>
            <artwork align="left" pn="section-4.3.1-29.1">
N_C and N_KDC expressed in CBOR diagnostic notation:
  N_C   = h'25a8991cd700ac01'
  N_KDC = h'cef04b2aa791bc6d'


N_C and N_KDC as CBOR encoded byte strings:
  N_C   = 0x4825a8991cd700ac01
  N_KDC = 0x48cef04b2aa791bc6d

PoP input:
  0x48 25a8991cd700ac01 48 cef04b2aa791bc6d
</artwork>
          </figure>
          <t indent="0" pn="section-4.3.1-30">After sending the Join Response, if the KDC has an associated authentication credential as required for the correct group operation, then the KDC <bcp14>MUST</bcp14> store the N_C value specified in the 'cnonce' parameter of the Join Request as a 'clientchallenge' value associated with the Client, replacing the currently stored value (if any). If, as a group member, the Client later sends a GET request to the /ace-group/GROUPNAME/kdc-cred resource for retrieving the latest KDC's authentication credential (see <xref target="kdc-pub-key-get" format="default" sectionFormat="of" derivedContent="Section 4.5.1"/>), then the KDC uses the stored 'clientchallenge' for computing the PoP evidence to include in the response sent to the Client, hence proving the possession of its own private key.</t>
          <t indent="0" pn="section-4.3.1-31">If the Join Response includes the 'kdc_cred_verify' parameter, the Client verifies the conveyed PoP evidence and considers the group joining unsuccessful in case of failed verification. Application profiles of this specification <bcp14>MUST</bcp14> specify the exact approaches used by the Client to verify the PoP evidence in 'kdc_cred_verify' and <bcp14>MUST</bcp14> specify which of those approaches is used in which case (<xref target="req21" format="none" sectionFormat="of" derivedContent="">REQ21</xref>).</t>
          <t indent="0" pn="section-4.3.1-32">Application profiles of this specification <bcp14>MUST</bcp14> specify the communication protocol that members of the group use to communicate with each other (<xref target="req22" format="none" sectionFormat="of" derivedContent="">REQ22</xref>) and the security protocol that they use to protect the group communication (<xref target="req23" format="none" sectionFormat="of" derivedContent="">REQ23</xref>).</t>
          <section anchor="ssec-key-distribution-exchange" numbered="true" removeInRFC="false" toc="include" pn="section-4.3.1.1">
            <name slugifiedName="name-join-the-group">Join the Group</name>
            <t indent="0" pn="section-4.3.1.1-1"><xref target="fig-key-distr-join" format="default" sectionFormat="of" derivedContent="Figure 12"/> gives an overview of the join exchange between the Client and the KDC when the Client first joins a group, while <xref target="fig-key-distr-join-2" format="default" sectionFormat="of" derivedContent="Figure 13"/> shows an example.</t>
            <figure anchor="fig-key-distr-join" align="left" suppress-title="false" pn="figure-12">
              <name slugifiedName="name-message-flow-of-the-join-re">Message Flow of the Join Request-Response</name>
              <artset pn="section-4.3.1.1-2.1">
                <artwork type="svg" align="center" pn="section-4.3.1.1-2.1.1">
		  <svg xmlns="http://www.w3.org/2000/svg" version="1.1" viewBox="0 0 650 112" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
                    <path d="M 32,32 L 32,96" fill="none" stroke="black"/>
                    <path d="M 488,32 L 488,96" fill="none" stroke="black"/>
                    <path d="M 40,48 L 96,48" fill="none" stroke="black"/>
                    <path d="M 432,48 L 480,48" fill="none" stroke="black"/>
                    <path d="M 40,80 L 136,80" fill="none" stroke="black"/>
                    <path d="M 392,80 L 472,80" fill="none" stroke="black"/>
                    <polygon class="arrowhead" points="488,48 476,42.4 476,53.6" fill="black" transform="rotate(0,480,48)"/>
                    <polygon class="arrowhead" points="48,80 36,74.4 36,85.6" fill="black" transform="rotate(180,40,80)"/>
                    <g class="text">
                      <text x="28" y="20">Client</text>
                      <text x="488" y="20">KDC</text>
                      <text x="264" y="52">Join Request: POST /ace-group/GROUPNAME</text>
                      <text x="264" y="84">Join Response: 2.01 (Created)</text>
                      <text x="256" y="100">Location-Path = "/ace-group/GROUPNAME/nodes/NODENAME"</text>
                    </g>
                  </svg>
                </artwork>
                <artwork type="ascii-art" align="center" pn="section-4.3.1.1-2.1.2">
Client                                                     KDC
   |                                                        |
   |-------- Join Request: POST /ace-group/GROUPNAME ------&gt;|
   |                                                        |
   |&lt;------------ Join Response: 2.01 (Created) ----------- |
   | Location-Path = "/ace-group/GROUPNAME/nodes/NODENAME"  |
</artwork>
              </artset>
            </figure>
            <figure anchor="fig-key-distr-join-2" align="left" suppress-title="false" pn="figure-13">
              <name slugifiedName="name-example-of-the-first-join-r">Example of the First Join Request-Response for Group Joining</name>
              <artwork align="left" pn="section-4.3.1.1-3.1">
Request:

Header: POST (Code=0.02)
Uri-Host: "kdc.example.com"
Uri-Path: "ace-group"
Uri-Path: "g1"
Content-Format: 261 (application/ace-groupcomm+cbor)
Payload (in CBOR diagnostic notation):
{
  / scope /               3: &lt;&lt;["group1", ["sender", "receiver"]]&gt;&gt;,
  / get_creds /           4: [true, ["sender"], []],
  / client_cred /         5: h'a2026008a101a5010202410a20012158
                               20bbc34960526ea4d32e940cad2a2341
                               48ddc21791a12afbcbac93622046dd44
                               f02258204519e257236b2a0ce2023f09
                               31f1f386ca7afda64fcde0108c224c51
                               eabf6072',
  / cnonce /              6: h'25a8991cd700ac01',
  / client_cred_verify / 24: h'66e6d9b0db009f3e105a673f88556117
                               26caed57f530f8cae9d0b168513ab949
                               fedc3e80a96ebe94ba08d3f8d3bf8348
                               7458e2ab4c2f936ff78b50e33c885e35'
}


Response:

Header: Created (Code=2.01)
Content-Format: 261 (application/ace-groupcomm+cbor)
Location-Path: "ace-group"
Location-Path: "g1"
Location-Path: "nodes"
Location-Path: "c101"
Payload (in CBOR diagnostic notation):
{
  / gkty /              7: 65600,
  / key /               8: h'73657373696f6e6b6579',
  / num /               9: 12,
  / exp /              11: 1924992000,
  / exi /              12: 2592000,
  / creds /            13: [h'a2026008a101a5010202410220012158
                              20cd4177ba62433375ede279b5e18e8b
                              91bc3ed8f1e174474a26fc0edb44ea53
                              73225820a0391de29c5c5badda610d4e
                              301eaaa18422367722289cd18cbe6624
                              e89b9cfd',
                            h'a2026008a101a5010202410320012158
                              20ac75e9ece3e50bfc8ed60399889522
                              405c47bf16df96660a41298cb4307f7e
                              b62258206e5de611388a4b8a8211334a
                              c7d37ecb52a387d257e6db3c2a93df21
                              ff3affc8'],
  / peer_roles /       14: ["sender", ["sender", "receiver"]],
  / peer_identifiers / 15: [h'01', h'02']
}
</artwork>
            </figure>
            <t indent="0" pn="section-4.3.1.1-4">If not previously established, the Client and the KDC <bcp14>MUST</bcp14> first establish a pairwise secure communication association (<xref target="req24" format="none" sectionFormat="of" derivedContent="">REQ24</xref>). This can be achieved, for instance, by using a transport profile of ACE. The join exchange <bcp14>MUST</bcp14> occur over that secure communication association. The Client and the KDC <bcp14>MAY</bcp14> use that same secure communication association to protect further pairwise communications that must be protected.</t>
            <t indent="0" pn="section-4.3.1.1-5">It is <bcp14>REQUIRED</bcp14> that the secure communication association between the Client and the KDC is established by using the proof-of-possession key bound to the access token. As a result, the proof of possession to bind the access token to the Client is performed by using the proof-of-possession key bound to the access token for establishing the pairwise secure communication association between the Client and the KDC.</t>
            <t indent="0" pn="section-4.3.1.1-6">To join the group, the Client sends a CoAP POST request to the /ace-group/GROUPNAME endpoint at the KDC, where the group to join is identified by GROUPNAME. The group name is specified in the scope entry conveyed by the 'scope' parameter of the request (if present), formatted as specified in <xref target="gid-post" format="default" sectionFormat="of" derivedContent="Section 4.3.1"/>. This group name is the same as in the scope entry corresponding to that group, specified in the 'scope' parameter of the Authorization Request/Response, or it can be determined from it. Note that, in case of successful joining, the Location-Path Options in the Join Response provide the Client with the path of the URI to use for retrieving individual keying material and for leaving the group.</t>
            <t indent="0" pn="section-4.3.1.1-7">If the node is joining a group for the first time and the KDC maintains the authentication credentials of the group members, the Client is <bcp14>REQUIRED</bcp14> to send its own authentication credential and proof-of-possession (PoP) evidence in the Join Request (see the 'client_cred' and 'client_cred_verify' parameters in <xref target="gid-post" format="default" sectionFormat="of" derivedContent="Section 4.3.1"/>). The request is accepted only if both the authentication credential is provided and the PoP evidence is successfully verified.</t>
            <t indent="0" pn="section-4.3.1.1-8">If a node rejoins a group as authorized by the same access token and using the same authentication credential, it can omit the authentication credential and the PoP evidence, or just the PoP evidence, from the Join Request. Then, the KDC will be able to retrieve the node's authentication credential associated with the access token for that group. If the authentication credential has been discarded, the KDC replies with a 4.00 (Bad Request) error response, as specified in <xref target="gid-post" format="default" sectionFormat="of" derivedContent="Section 4.3.1"/>. If a node rejoins a group but wants to update its own authentication credential, it needs to include both its authentication credential and the PoP evidence in the Join Request, like when it joined the group for the first time.</t>
          </section>
        </section>
        <section anchor="gid-get" numbered="true" removeInRFC="false" toc="include" pn="section-4.3.2">
          <name slugifiedName="name-get-handler">GET Handler</name>
          <t indent="0" pn="section-4.3.2-1">The GET handler returns the symmetric group keying material for the group identified by GROUPNAME.</t>
          <t indent="0" pn="section-4.3.2-2">The handler expects a GET request.</t>
          <t indent="0" pn="section-4.3.2-3">In addition to what is defined in <xref target="kdc-if-errors" format="default" sectionFormat="of" derivedContent="Section 4.1.2"/>, the handler verifies that the Client is a current member of the group. If the verification fails, the KDC <bcp14>MUST</bcp14> reply with a 4.03 (Forbidden) error response. The response <bcp14>MUST</bcp14> have Content-Format "application/concise-problem-details+cbor" and is formatted as defined in <xref target="kdc-if-errors" format="default" sectionFormat="of" derivedContent="Section 4.1.2"/>. Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' field  <bcp14>MUST</bcp14> be set to 0 ("Operation permitted only to group members").</t>
          <t indent="0" pn="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 that <bcp14>MUST</bcp14> contain the parameters 'gkty', 'key', and 'num', as specified in <xref target="gid-post" format="default" sectionFormat="of" derivedContent="Section 4.3.1"/>.</t>
          <t indent="0" pn="section-4.3.2-5">The payload <bcp14>MUST</bcp14> also include the parameters 'rekeying_scheme' and 'mgt_key_material' as specified in <xref target="gid-post" format="default" sectionFormat="of" derivedContent="Section 4.3.1"/>, if they are included in the payload of the Join Responses sent for the group.</t>
          <t indent="0" pn="section-4.3.2-6">The payload <bcp14>MAY</bcp14> also include the parameters 'ace_groupcomm_profile', 'exp', and 'exi', as specified in <xref target="gid-post" format="default" sectionFormat="of" derivedContent="Section 4.3.1"/>. If the 'exp' parameter is included, the 'exi' parameter <bcp14>MUST</bcp14> also be included. If the 'exi' parameter is included, its value specifies the residual lifetime of the group keying material from the current time at the KDC.</t>
          <section anchor="ssec-key-material-retrieval" numbered="true" removeInRFC="false" toc="include" pn="section-4.3.2.1">
            <name slugifiedName="name-retrieve-group-keying-mater">Retrieve Group Keying Material</name>
            <t indent="0" pn="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 the group is identified by GROUPNAME.</t>
            <t indent="0" pn="section-4.3.2.1-2"><xref target="fig-retrieve-key-material" format="default" sectionFormat="of" derivedContent="Figure 14"/> gives an overview of the key distribution exchange between the Client and the KDC, while <xref target="fig-retrieve-key-material-2" format="default" sectionFormat="of" derivedContent="Figure 15"/> shows an example.</t>
            <figure anchor="fig-retrieve-key-material" align="left" suppress-title="false" pn="figure-14">
              <name slugifiedName="name-message-flow-of-key-distrib">Message Flow of Key Distribution Request-Response</name>
              <artset pn="section-4.3.2.1-3.1">
                <artwork type="svg" align="center" pn="section-4.3.2.1-3.1.1">
		       <svg xmlns="http://www.w3.org/2000/svg" version="1.1" viewBox="0 0 650 112" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
                    <path d="M 32,32 L 32,96" fill="none" stroke="black"/>
                    <path d="M 560,32 L 560,96" fill="none" stroke="black"/>
                    <path d="M 40,48 L 80,48" fill="none" stroke="black"/>
                    <path d="M 504,48 L 552,48" fill="none" stroke="black"/>
                    <path d="M 40,80 L 128,80" fill="none" stroke="black"/>
                    <path d="M 480,80 L 544,80" fill="none" stroke="black"/>
                    <polygon class="arrowhead" points="560,48 548,42.4 548,53.6" fill="black" transform="rotate(0,552,48)"/>
                    <polygon class="arrowhead" points="48,80 36,74.4 36,85.6" fill="black" transform="rotate(180,40,80)"/>
                    <g class="text">
                      <text x="28" y="20">Client</text>
                      <text x="560" y="20">KDC</text>
                      <text x="292" y="52">Key Distribution Request: GET /ace-group/GROUPNAME</text>
                      <text x="304" y="84">Key Distribution Response: 2.05 (Content)</text>
                    </g>
                  </svg>
                </artwork>
                <artwork type="ascii-art" align="center" pn="section-4.3.2.1-3.1.2">
Client                                                              KDC
   |                                                                 |
   |------ Key Distribution Request: GET /ace-group/GROUPNAME ------&gt;|
   |                                                                 |
   |&lt;----------- Key Distribution Response: 2.05 (Content) --------- |
   |                                                                 |
</artwork>
              </artset>
            </figure>
            <figure anchor="fig-retrieve-key-material-2" align="left" suppress-title="false" pn="figure-15">
              <name slugifiedName="name-example-of-key-distribution">Example of Key Distribution Request-Response</name>
              <artwork align="left" pn="section-4.3.2.1-4.1">
Request:

Header: GET (Code=0.01)
Uri-Host: "kdc.example.com"
Uri-Path: "ace-group"
Uri-Path: "g1"


Response:

Header: Content (Code=2.05)
Content-Format: 261 (application/ace-groupcomm+cbor)
Payload (in CBOR diagnostic notation):
{
  / gkty / 7: 65600,
  / key /  8: h'73657373696f6e6b6579',
  / num /  9: 12
}
</artwork>
            </figure>
          </section>
        </section>
      </section>
      <section anchor="ace-groupgroupnamecreds" numbered="true" removeInRFC="false" toc="include" pn="section-4.4">
        <name slugifiedName="name-ace-group-groupname-creds">/ace-group/GROUPNAME/creds</name>
        <t indent="0" pn="section-4.4-1">This resource implements the GET and FETCH handlers.</t>
        <section anchor="pubkey-fetch" numbered="true" removeInRFC="false" toc="include" pn="section-4.4.1">
          <name slugifiedName="name-fetch-handler-2">FETCH Handler</name>
          <t indent="0" pn="section-4.4.1-1">The FETCH handler receives identifiers of group members for the group identified by GROUPNAME and returns the authentication credentials of such group members.</t>
          <t indent="0" pn="section-4.4.1-2">The handler expects a request with the payload formatted as a CBOR map, which <bcp14>MUST</bcp14> contain the following field.</t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.4.1-3">
            <li pn="section-4.4.1-3.1">
              <t indent="0" pn="section-4.4.1-3.1.1">'get_creds': its value is encoded as in <xref target="gid-post" format="default" sectionFormat="of" derivedContent="Section 4.3.1"/>, with the following modifications.  </t>
              <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.4.1-3.1.2">
                <li pn="section-4.4.1-3.1.2.1">
                  <t indent="0" pn="section-4.4.1-3.1.2.1.1">The arrays 'role_filter' and 'id_filter' <bcp14>MUST NOT</bcp14> both be empty, i.e., in CDDL notation: [ bool, [ ], [ ] ]. If the 'get_creds' parameter has such a format, the request <bcp14>MUST</bcp14> be considered malformed, and the KDC <bcp14>MUST</bcp14> reply with a 4.00 (Bad Request) error response.      </t>
                  <t indent="0" pn="section-4.4.1-3.1.2.1.2">
Note that a group member can retrieve the authentication credentials of all the current group members by sending a GET request to the same KDC resource instead (see <xref target="sec-key-retrieval-all" format="default" sectionFormat="of" derivedContent="Section 4.4.2.1"/>).</t>
                </li>
                <li pn="section-4.4.1-3.1.2.2">The element 'inclusion_flag' encodes the CBOR simple value <tt>true</tt> (0xf5) or <tt>false</tt> (0xf4), as defined in <xref target="gid-post" format="default" sectionFormat="of" derivedContent="Section 4.3.1"/>.</li>
                <li pn="section-4.4.1-3.1.2.3">The array 'role_filter' can be empty if the Client does not wish to filter the requested authentication credentials based on the roles of the group members.</li>
                <li pn="section-4.4.1-3.1.2.4">The array 'id_filter' contains zero or more node identifiers of group members for the group identified by GROUPNAME, as defined in <xref target="gid-post" format="default" sectionFormat="of" derivedContent="Section 4.3.1"/>. The array may be empty if the Client does not wish to filter the requested authentication credentials based on the node identifiers of the group members.</li>
              </ul>
            </li>
          </ul>
          <t indent="0" pn="section-4.4.1-4">Note that, in case the 'role_filter' array and the 'id_filter' array are both non-empty:</t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.4.1-5">
            <li pn="section-4.4.1-5.1">If the 'inclusion_flag' encodes the CBOR simple value <tt>true</tt> (0xf5), the handler returns the authentication credentials of group members whose roles match with 'role_filter' and/or have their node identifier specified in 'id_filter'.</li>
            <li pn="section-4.4.1-5.2">If the 'inclusion_flag' encodes the CBOR simple value <tt>false</tt> (0xf4), the handler returns the authentication credentials of group members whose roles match with 'role_filter' and, at the same time, do not have their node identifier specified in 'id_filter'.</li>
          </ul>
          <t indent="0" pn="section-4.4.1-6">The specific format of authentication credentials as well as the identifiers, roles, and combination of roles of group members <bcp14>MUST</bcp14> be specified by application profiles of this specification (<xref target="req1" format="none" sectionFormat="of" derivedContent="">REQ1</xref>, <xref target="req6" format="none" sectionFormat="of" derivedContent="">REQ6</xref>, <xref target="req25" format="none" sectionFormat="of" derivedContent="">REQ25</xref>).</t>
          <t indent="0" pn="section-4.4.1-7">The handler identifies the authentication credentials of the current group members for which either of the following holds:</t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.4.1-8">
            <li pn="section-4.4.1-8.1">The role identifier matches with one of those indicated in the request; note that the request can specify a combination of roles, in which case the handler selects only the group members that have all the roles included in the combination.</li>
            <li pn="section-4.4.1-8.2">The node identifier matches with one of those indicated in the request or does not match with any of those, which is consistent with the value of the element 'inclusion_flag'.</li>
          </ul>
          <t indent="0" pn="section-4.4.1-9">If all verifications succeed, the handler returns a 2.05 (Content) message response with the payload formatted as a CBOR map, containing only the following parameters from <xref target="gid-post" format="default" sectionFormat="of" derivedContent="Section 4.3.1"/>.</t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.4.1-10">
            <li pn="section-4.4.1-10.1">'num': encoding the version number of the current group keying material.</li>
            <li pn="section-4.4.1-10.2">'creds': encoding the list of authentication credentials of the selected group members.</li>
            <li pn="section-4.4.1-10.3">
              <t indent="0" pn="section-4.4.1-10.3.1">'peer_roles': encoding the role(s) that each of the selected group members has in the group.  </t>
              <t indent="0" pn="section-4.4.1-10.3.2">
This parameter <bcp14>SHOULD</bcp14> be present, and it <bcp14>MAY</bcp14> be omitted according to the same criteria defined for the Join Response (see <xref target="gid-post" format="default" sectionFormat="of" derivedContent="Section 4.3.1"/>).</t>
            </li>
            <li pn="section-4.4.1-10.4">'peer_identifiers': encoding the node identifier that each of the selected group members has in the group.</li>
          </ul>
          <t indent="0" pn="section-4.4.1-11">The specific format of authentication credentials as well as of node identifiers of group members is specified by the application profile (<xref target="req6" format="none" sectionFormat="of" derivedContent="">REQ6</xref>, <xref target="req25" format="none" sectionFormat="of" derivedContent="">REQ25</xref>).</t>
          <t indent="0" pn="section-4.4.1-12">If the KDC does not store any authentication credential associated with the specified node identifiers, the handler returns a response with the payload formatted as a CBOR byte string of zero length (0x40).</t>
          <t indent="0" pn="section-4.4.1-13">The handler <bcp14>MAY</bcp14> enforce one of the following policies in order to handle possible node identifiers that are included in the 'id_filter' element of the 'get_creds' parameter of the request but are not associated with any current group member. Such a policy <bcp14>MUST</bcp14> be specified by application profiles of this specification (<xref target="req26" format="none" sectionFormat="of" derivedContent="">REQ26</xref>).</t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.4.1-14">
            <li pn="section-4.4.1-14.1">The KDC silently ignores those node identifiers.</li>
            <li pn="section-4.4.1-14.2">
              <t indent="0" pn="section-4.4.1-14.2.1">The KDC retains authentication credentials of group members for a given amount of time after their leaving before discarding them. As long as such authentication credentials are retained, the KDC provides them to a requesting Client.  </t>
              <t indent="0" pn="section-4.4.1-14.2.2">
If the KDC adopts this policy, the application profile <bcp14>MUST</bcp14> also specify the amount of time during which the KDC retains the authentication credential of a former group member after its leaving, possibly on a per-member basis.</t>
            </li>
          </ul>
          <t indent="0" pn="section-4.4.1-15">Note that this resource handler only verifies that the node is authorized by the AS to access this resource. Nodes that are not members of the group but are authorized to do signature verifications on the group messages may be allowed to access this resource if the application needs it.</t>
          <section anchor="sec-key-retrieval" numbered="true" removeInRFC="false" toc="include" pn="section-4.4.1.1">
            <name slugifiedName="name-retrieve-a-subset-of-authen">Retrieve a Subset of Authentication Credentials in the Group</name>
            <t indent="0" pn="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, which is formatted as defined in <xref target="pubkey-fetch" format="default" sectionFormat="of" derivedContent="Section 4.4.1"/> and where GROUPNAME identifies the group.</t>
            <t indent="0" pn="section-4.4.1.1-2"><xref target="fig-public-key-1" format="default" sectionFormat="of" derivedContent="Figure 16"/> gives an overview of the exchange mentioned above, while <xref target="fig-public-key-2" format="default" sectionFormat="of" derivedContent="Figure 17"/> shows an example of such an exchange.</t>
            <figure anchor="fig-public-key-1" align="left" suppress-title="false" pn="figure-16">
              <name slugifiedName="name-message-flow-of-authenticat">Message Flow of Authentication Credential Request-Response to Obtain the Authentication Credentials of Specific Group Members</name>
              <artset pn="section-4.4.1.1-3.1">
                <artwork type="svg" align="center" pn="section-4.4.1.1-3.1.1">
		  <svg xmlns="http://www.w3.org/2000/svg" version="1.1" viewBox="0 0 650 144" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
                    <path d="M 32,32 L 32,128" fill="none" stroke="black"/>
                    <path d="M 496,32 L 496,128" fill="none" stroke="black"/>
                    <path d="M 40,64 L 488,64" fill="none" stroke="black"/>
                    <path d="M 40,112 L 56,112" fill="none" stroke="black"/>
                    <polygon class="arrowhead" points="496,64 484,58.4 484,69.6" fill="black" transform="rotate(0,488,64)"/>
                    <polygon class="arrowhead" points="48,112 36,106.4 36,117.6" fill="black" transform="rotate(180,40,112)"/>
                    <g class="text">
                      <text x="28" y="20">Client</text>
                      <text x="496" y="20">KDC</text>
                      <text x="268" y="52">Authentication Credential Request:</text>
                      <text x="268" y="84">FETCH /ace-group/GROUPNAME/creds</text>
                      <text x="280" y="116">Authentication Credential Response: 2.05 (Content) --</text>
                    </g>
                  </svg>
                </artwork>
                <artwork type="ascii-art" align="center" pn="section-4.4.1.1-3.1.2">
Client                                                      KDC
   |                                                         |
   |            Authentication Credential Request:           |
   |--------------------------------------------------------&gt;|
   |             FETCH /ace-group/GROUPNAME/creds            |
   |                                                         |
   |&lt;-- Authentication Credential Response: 2.05 (Content) --|
   |                                                         |
</artwork>
              </artset>
            </figure>
            <figure anchor="fig-public-key-2" align="left" suppress-title="false" pn="figure-17">
              <name slugifiedName="name-example-of-authentication-c">Example of Authentication Credential Request-Response to Obtain the Authentication Credentials of Specific Group Members</name>
              <artwork align="left" pn="section-4.4.1.1-4.1">
Request:

Header: FETCH (Code=0.05)
Uri-Host: "kdc.example.com"
Uri-Path: "ace-group"
Uri-Path: "g1"
Uri-Path: "creds"
Content-Format: 261 (application/ace-groupcomm+cbor)
Payload (in CBOR diagnostic notation):
{
  / get_creds / 4: [true, [], [h'02', h'03']]
}


Response:

Header: Content (Code=2.05)
Content-Format: 261 (application/ace-groupcomm+cbor)
Payload (in CBOR diagnostic notation):
{
  / creds /            13: [h'a2026008a101a5010202410320012158
                              20ac75e9ece3e50bfc8ed60399889522
                              405c47bf16df96660a41298cb4307f7e
                              b62258206e5de611388a4b8a8211334a
                              c7d37ecb52a387d257e6db3c2a93df21
                              ff3affc8',
                            h'a2026008a101a5010202410920012158
                              206f9702a66602d78f5e81bac1e0af01
                              f8b52810c502e87ebb7c926c07426fd0
                              2f225820c8d33274c71c9b3ee57d842b
                              bf2238b8283cb410eca216fb72a78ea7
                              a870f800'],
  / peer_roles /       14: [["sender", "receiver"], "receiver"],
  / peer_identifiers / 15: [h'02', h'03']
}
</artwork>
            </figure>
          </section>
        </section>
        <section anchor="pubkey-get" numbered="true" removeInRFC="false" toc="include" pn="section-4.4.2">
          <name slugifiedName="name-get-handler-2">GET Handler</name>
          <t indent="0" pn="section-4.4.2-1">The handler expects a GET request.</t>
          <t indent="0" pn="section-4.4.2-2">If all verifications succeed, the KDC replies with a 2.05 (Content) response as in the FETCH handler in <xref target="pubkey-fetch" format="default" sectionFormat="of" derivedContent="Section 4.4.1"/>, but its payload specifies the authentication credentials of all the group members, together with their roles and node identifiers.</t>
          <t indent="0" pn="section-4.4.2-3">The 'peer_roles' parameter <bcp14>SHOULD</bcp14> be present in the payload of the response, and it <bcp14>MAY</bcp14> be omitted according to the same criteria defined for the Join Response (see <xref target="gid-post" format="default" sectionFormat="of" derivedContent="Section 4.3.1"/>).</t>
          <section anchor="sec-key-retrieval-all" numbered="true" removeInRFC="false" toc="include" pn="section-4.4.2.1">
            <name slugifiedName="name-retrieve-all-authentication">Retrieve All Authentication Credentials in the Group</name>
            <t indent="0" pn="section-4.4.2.1-1">In case the KDC maintains the authentication credentials of group members, a node in the 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 the group is identified by GROUPNAME.</t>
            <t indent="0" pn="section-4.4.2.1-2"><xref target="fig-public-key-3" format="default" sectionFormat="of" derivedContent="Figure 18"/> gives an overview of the message exchange, while <xref target="fig-public-key-4" format="default" sectionFormat="of" derivedContent="Figure 19"/> shows an example of such an exchange.</t>
            <figure anchor="fig-public-key-3" align="left" suppress-title="false" pn="figure-18">
              <name slugifiedName="name-message-flow-of-authenticati">Message Flow of Authentication Credential Request-Response to Obtain the Authentication Credentials of All the Group Members</name>
              <artset pn="section-4.4.2.1-3.1">
                <artwork type="svg" align="center" pn="section-4.4.2.1-3.1.1">
		  <svg xmlns="http://www.w3.org/2000/svg" version="1.1" viewBox="0 0 650 144" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
                    <path d="M 32,32 L 32,128" fill="none" stroke="black"/>
                    <path d="M 496,32 L 496,128" fill="none" stroke="black"/>
                    <path d="M 40,64 L 488,64" fill="none" stroke="black"/>
                    <path d="M 40,112 L 56,112" fill="none" stroke="black"/>
                    <polygon class="arrowhead" points="496,64 484,58.4 484,69.6" fill="black" transform="rotate(0,488,64)"/>
                    <polygon class="arrowhead" points="48,112 36,106.4 36,117.6" fill="black" transform="rotate(180,40,112)"/>
                    <g class="text">
                      <text x="28" y="20">Client</text>
                      <text x="496" y="20">KDC</text>
                      <text x="268" y="52">Authentication Credential Request:</text>
                      <text x="268" y="84">GET /ace-group/GROUPNAME/creds</text>
                      <text x="280" y="116">Authentication Credential Response: 2.05 (Content) --</text>
                    </g>
                  </svg>
                </artwork>
                <artwork type="ascii-art" align="center" pn="section-4.4.2.1-3.1.2">
Client                                                      KDC
   |                                                         |
   |            Authentication Credential Request:           |
   |--------------------------------------------------------&gt;|
   |              GET /ace-group/GROUPNAME/creds             |
   |                                                         |
   |&lt;-- Authentication Credential Response: 2.05 (Content) --|
   |                                                         |
</artwork>
              </artset>
            </figure>
            <figure anchor="fig-public-key-4" align="left" suppress-title="false" pn="figure-19">
              <name slugifiedName="name-example-of-authentication-cr">Example of Authentication Credential Request-Response to Obtain the Authentication Credentials of All the Group Members</name>
              <artwork align="left" pn="section-4.4.2.1-4.1">
Request:

Header: GET (Code=0.01)
Uri-Host: "kdc.example.com"
Uri-Path: "ace-group"
Uri-Path: "g1"
Uri-Path: "creds"


Response:

Header: Content (Code=2.05)
Content-Format: 261 (application/ace-groupcomm+cbor)
Payload (in CBOR diagnostic notation):
{
  / num /               9: 12,
  / creds /            13: [h'a2026008a101a5010202410220012158
                              20cd4177ba62433375ede279b5e18e8b
                              91bc3ed8f1e174474a26fc0edb44ea53
                              73225820a0391de29c5c5badda610d4e
                              301eaaa18422367722289cd18cbe6624
                              e89b9cfd',
                            h'a2026008a101a5010202410320012158
                              20ac75e9ece3e50bfc8ed60399889522
                              405c47bf16df96660a41298cb4307f7e
                              b62258206e5de611388a4b8a8211334a
                              c7d37ecb52a387d257e6db3c2a93df21
                              ff3affc8',
                            h'a2026008a101a5010202410920012158
                              206f9702a66602d78f5e81bac1e0af01
                              f8b52810c502e87ebb7c926c07426fd0
                              2f225820c8d33274c71c9b3ee57d842b
                              bf2238b8283cb410eca216fb72a78ea7
                              a870f800'],
  / peer_roles /       14: ["sender", ["sender", "receiver"],
                            "receiver"],
  / peer_identifiers / 15: [h'01', h'02', h'03']
}
</artwork>
            </figure>
          </section>
        </section>
      </section>
      <section anchor="ace-groupgroupnamekdc-cred" numbered="true" removeInRFC="false" toc="include" pn="section-4.5">
        <name slugifiedName="name-ace-group-groupname-kdc-cre">/ace-group/GROUPNAME/kdc-cred</name>
        <t indent="0" pn="section-4.5-1">This resource implements a GET handler.</t>
        <section anchor="kdc-pub-key-get" numbered="true" removeInRFC="false" toc="include" pn="section-4.5.1">
          <name slugifiedName="name-get-handler-3">GET Handler</name>
          <t indent="0" pn="section-4.5.1-1">The handler expects a GET request.</t>
          <t indent="0" pn="section-4.5.1-2">If all verifications succeed, the handler returns a 2.05 (Content) message containing the KDC's authentication credential together with the proof-of-possession (PoP) evidence. The response <bcp14>MUST</bcp14> have Content-Format "application/ace-groupcomm+cbor". The payload of the response is a CBOR map, which includes the following fields.</t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.5.1-3">
            <li pn="section-4.5.1-3.1">'kdc_cred: specifying the KDC's authentication credential. This parameter is encoded like the 'kdc_cred' parameter in the Join Response (see <xref target="gid-post" format="default" sectionFormat="of" derivedContent="Section 4.3.1"/>).</li>
            <li pn="section-4.5.1-3.2">'kdc_nonce': specifying a nonce generated by the KDC. This parameter is encoded like the 'kdc_nonce' parameter in the Join Response (see <xref target="gid-post" format="default" sectionFormat="of" derivedContent="Section 4.3.1"/>).</li>
            <li pn="section-4.5.1-3.3">
              <t indent="0" pn="section-4.5.1-3.3.1">'kdc_cred_verify': specifying the PoP evidence computed by the KDC over the following PoP input: the nonce N_C (encoded as a CBOR byte string) concatenated with the nonce N_KDC (encoded as a CBOR byte string), where:  </t>
              <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.5.1-3.3.2">
                <li pn="section-4.5.1-3.3.2.1">N_C is the nonce generated by the Client group member such that: i) the nonce was specified in the 'cnonce' parameter of the latest Join Request that the Client sent to the KDC in order to join the group identified by GROUPNAME; and ii) the KDC stored the nonce as a 'clientchallenge' value associated with the Client after sending the corresponding Join Response (see <xref target="gid-post" format="default" sectionFormat="of" derivedContent="Section 4.3.1"/>).</li>
                <li pn="section-4.5.1-3.3.2.2">N_KDC is the nonce generated by the KDC and specified in the 'kdc_nonce' parameter.</li>
              </ul>
              <t indent="0" pn="section-4.5.1-3.3.3">
An example of PoP input to compute 'kdc_cred_verify' using CBOR encoding is given in <xref target="fig-kdc-cred-input-2" format="default" sectionFormat="of" derivedContent="Figure 20"/>.  </t>
              <t indent="0" pn="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 <xref target="gid-post" format="default" sectionFormat="of" derivedContent="Section 4.3.1"/>).  </t>
              <t indent="0" pn="section-4.5.1-3.3.5">
Application profiles of this specification <bcp14>MUST</bcp14> specify the exact approaches used by the KDC to compute the PoP evidence to include in the 'kdc_cred_verify' parameter and <bcp14>MUST</bcp14> specify which of those approaches is used in which case (<xref target="req21" format="none" sectionFormat="of" derivedContent="">REQ21</xref>).  </t>
              <t indent="0" pn="section-4.5.1-3.3.6">
If an application profile supports the presence of external signature verifiers that send GET requests to this resource, then the application profile <bcp14>MUST</bcp14> specify how external signature verifiers provide the KDC with a self-generated nonce to use as N_C (<xref target="req21" format="none" sectionFormat="of" derivedContent="">REQ21</xref>).</t>
            </li>
          </ul>
          <figure anchor="fig-kdc-cred-input-2" align="left" suppress-title="false" pn="figure-20">
            <name slugifiedName="name-example-of-pop-input-to-compu">Example of PoP Input to Compute 'kdc_cred_verify' Using CBOR Encoding</name>
            <artwork align="left" pn="section-4.5.1-4.1">
N_C and N_KDC expressed in CBOR diagnostic notation:
  N_C   = h'25a8991cd700ac01'
  N_KDC = h'0b7db12aaff56da3'


N_C and N_KDC as CBOR encoded byte strings:
  N_C   = 0x4825a8991cd700ac01
  N_KDC = 0x480b7db12aaff56da3

PoP input:
  0x48 25a8991cd700ac01 48 0b7db12aaff56da3
</artwork>
          </figure>
          <section anchor="kdc-pub-key" numbered="true" removeInRFC="false" toc="include" pn="section-4.5.1.1">
            <name slugifiedName="name-retrieve-the-kdcs-authentic">Retrieve the KDC's Authentication Credential</name>
            <t indent="0" pn="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 identifies the group.</t>
            <t indent="0" pn="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 <bcp14>MUST</bcp14> 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 <bcp14>MUST</bcp14> store the obtained KDC's authentication credential and replace the currently stored one.</t>
            <t indent="0" pn="section-4.5.1.1-3">The PoP evidence is verified by means of the same method used when processing the Join Response (see <xref target="gid-post" format="default" sectionFormat="of" derivedContent="Section 4.3.1"/>). Application profiles of this specification <bcp14>MUST</bcp14> specify the exact approaches used by the Client to verify the PoP evidence in 'kdc_cred_verify' and <bcp14>MUST</bcp14> specify which of those approaches is used in which case (<xref target="req21" format="none" sectionFormat="of" derivedContent="">REQ21</xref>).</t>
            <t indent="0" pn="section-4.5.1.1-4"><xref target="fig-kdc-pub-key-req-resp" format="default" sectionFormat="of" derivedContent="Figure 21"/> gives an overview of the exchange described above, while <xref target="fig-kdc-pub-key-req-resp-ex" format="default" sectionFormat="of" derivedContent="Figure 22"/> shows an example.</t>
            <figure anchor="fig-kdc-pub-key-req-resp" align="left" suppress-title="false" pn="figure-21">
              <name slugifiedName="name-message-flow-of-kdc-authent">Message Flow of KDC Authentication Credential Request-Response to Obtain the Authentication Credential of the KDC</name>
              <artset pn="section-4.5.1.1-5.1">
                <artwork type="svg" align="center" pn="section-4.5.1.1-5.1.1">
		  <svg xmlns="http://www.w3.org/2000/svg" version="1.1" viewBox="0 0 650 160" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
                    <path d="M 24,48 L 24,144" fill="none" stroke="black"/>
                    <path d="M 520,48 L 520,144" fill="none" stroke="black"/>
                    <path d="M 32,80 L 512,80" fill="none" stroke="black"/>
                    <path d="M 32,128 L 48,128" fill="none" stroke="black"/>
                    <polygon class="arrowhead" points="520,80 508,74.4 508,85.6" fill="black" transform="rotate(0,512,80)"/>
                    <polygon class="arrowhead" points="40,128 28,122.4 28,133.6" fill="black" transform="rotate(180,32,128)"/>
                    <g class="text">
                      <text x="24" y="20">Group</text>
                      <text x="28" y="36">Member</text>
                      <text x="520" y="36">KDC</text>
                      <text x="280" y="68">KDC Authentication Credential Request</text>
                      <text x="280" y="100">GET /ace-group/GROUPNAME/kdc-cred</text>
                      <text x="288" y="132">KDC Authentication Credential Response: 2.05 (Content) --</text>
                    </g>
                  </svg>
                </artwork>
                <artwork type="ascii-art" align="center" pn="section-4.5.1.1-5.1.2">
Group
Member                                                         KDC
  |                                                             |
  |             KDC Authentication Credential Request           |
  |------------------------------------------------------------&gt;|
  |               GET /ace-group/GROUPNAME/kdc-cred             |
  |                                                             |
  |&lt;-- KDC Authentication Credential Response: 2.05 (Content) --|
  |                                                             |
</artwork>
              </artset>
            </figure>
            <figure anchor="fig-kdc-pub-key-req-resp-ex" align="left" suppress-title="false" pn="figure-22">
              <name slugifiedName="name-example-of-kdc-authenticati">Example of KDC Authentication Credential Request-Response to Obtain the Authentication Credential of the KDC</name>
              <artwork align="left" pn="section-4.5.1.1-6.1">
Request:

Header: GET (Code=0.01)
Uri-Host: "kdc.example.com"
Uri-Path: "ace-group"
Uri-Path: "g1"
Uri-Path: "kdc-cred"


Response:

Header: Content (Code=2.05)
Content-Format: 261 (application/ace-groupcomm+cbor)
Payload (in CBOR diagnostic notation):
{
  / kdc_cred /        17: h'a2026008a101a5010202419920012158
                            2065eda5a12577c2bae829437fe33870
                            1a10aaa375e1bb5b5de108de439c0855
                            1d2258201e52ed75701163f7f9e40ddf
                            9f341b3dc9ba860af7e0ca7ca7e9eecd
                            0084d19c',
  / kdc_nonce /       18: h'0b7db12aaff56da3',
  / kdc_cred_verify / 19: h'3fc54702aa56e1b2cb20284294c9106a
                            63f91bac658d69351210a031d8fc7c5f
                            f3e4be39445b1a3e83e1510d1aca2f2e
                            8a7c081c7645042b18aba9d1fad1bd9c'
}
</artwork>
            </figure>
          </section>
        </section>
      </section>
      <section anchor="ace-groupgroupnamepolicies" numbered="true" removeInRFC="false" toc="include" pn="section-4.6">
        <name slugifiedName="name-ace-group-groupname-policie">/ace-group/GROUPNAME/policies</name>
        <t indent="0" pn="section-4.6-1">This resource implements the GET handler.</t>
        <section anchor="policies-get" numbered="true" removeInRFC="false" toc="include" pn="section-4.6.1">
          <name slugifiedName="name-get-handler-4">GET Handler</name>
          <t indent="0" pn="section-4.6.1-1">The handler expects a GET request.</t>
          <t indent="0" pn="section-4.6.1-2">In addition to what is defined in <xref target="kdc-if-errors" format="default" sectionFormat="of" derivedContent="Section 4.1.2"/>, the handler verifies that the Client is a current member of the group. If the verification fails, the KDC <bcp14>MUST</bcp14> reply with a 4.03 (Forbidden) error response. The response <bcp14>MUST</bcp14> have Content-Format "application/concise-problem-details+cbor" and is formatted as defined in <xref target="kdc-if-errors" format="default" sectionFormat="of" derivedContent="Section 4.1.2"/>. Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' field  <bcp14>MUST</bcp14> be set to 0 ("Operation permitted only to group members").</t>
          <t indent="0" pn="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 'group_policies' parameter defined in <xref target="gid-post" format="default" sectionFormat="of" derivedContent="Section 4.3.1"/> and specifying the current policies in the group. If the KDC does not store any policy, the payload is formatted as a CBOR byte string of zero length (0x40).</t>
          <t indent="0" pn="section-4.6.1-4">The specific format and meaning of group policies <bcp14>MUST</bcp14> be specified in application profiles of this specification (<xref target="req20" format="none" sectionFormat="of" derivedContent="">REQ20</xref>).</t>
          <section anchor="policies" numbered="true" removeInRFC="false" toc="include" pn="section-4.6.1.1">
            <name slugifiedName="name-retrieve-the-group-policies">Retrieve the Group Policies</name>
            <t indent="0" pn="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, which is formatted as defined in <xref target="policies-get" format="default" sectionFormat="of" derivedContent="Section 4.6.1"/> and where GROUPNAME identifies the group.</t>
            <t indent="0" pn="section-4.6.1.1-2"><xref target="fig-policies" format="default" sectionFormat="of" derivedContent="Figure 23"/> gives an overview of the exchange described above, while <xref target="fig-policies-2" format="default" sectionFormat="of" derivedContent="Figure 24"/> shows an example.</t>
            <figure anchor="fig-policies" align="left" suppress-title="false" pn="figure-23">
              <name slugifiedName="name-message-flow-of-policies-re">Message Flow of Policies Request-Response</name>
              <artset pn="section-4.6.1.1-3.1">
                <artwork type="svg" align="center" pn="section-4.6.1.1-3.1.1">
		  <svg xmlns="http://www.w3.org/2000/svg" version="1.1" viewBox="0 0 650 112" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
                    <path d="M 32,32 L 32,96" fill="none" stroke="black"/>
                    <path d="M 504,32 L 504,96" fill="none" stroke="black"/>
                    <path d="M 480,48 L 496,48" fill="none" stroke="black"/>
                    <path d="M 40,80 L 128,80" fill="none" stroke="black"/>
                    <path d="M 416,80 L 496,80" fill="none" stroke="black"/>
                    <polygon class="arrowhead" points="504,48 492,42.4 492,53.6" fill="black" transform="rotate(0,496,48)"/>
                    <polygon class="arrowhead" points="48,80 36,74.4 36,85.6" fill="black" transform="rotate(180,40,80)"/>
                    <g class="text">
                      <text x="28" y="20">Client</text>
                      <text x="504" y="20">KDC</text>
                      <text x="252" y="52">-- Policies Request: GET /ace-group/GROUPNAME/policies</text>
                      <text x="272" y="84">Policies Response: 2.05 (Content)</text>
                    </g>
                  </svg>
                </artwork>
                <artwork type="ascii-art" align="center" pn="section-4.6.1.1-3.1.2">
Client                                                       KDC
   |                                                          |
   |-- Policies Request: GET /ace-group/GROUPNAME/policies --&gt;|
   |                                                          |
   |&lt;----------- Policies Response: 2.05 (Content) -----------|
   |                                                          |
</artwork>
              </artset>
            </figure>
            <figure anchor="fig-policies-2" align="left" suppress-title="false" pn="figure-24">
              <name slugifiedName="name-example-of-policies-request">Example of Policies Request-Response</name>
              <artwork align="left" pn="section-4.6.1.1-4.1">
Request:

Header: GET (Code=0.01)
Uri-Host: "kdc.example.com"
Uri-Path: "ace-group"
Uri-Path: "g1"
Uri-Path: "policies"


Response:

Header: Content (Code=2.05)
Content-Format: 261 (application/ace-groupcomm+cbor)
Payload(in CBOR diagnostic notation):
{
  / group_policies / 16: {
    / Expiration Delta / 2: 120
  }
}
</artwork>
            </figure>
          </section>
        </section>
      </section>
      <section anchor="ace-groupgroupnamenum" numbered="true" removeInRFC="false" toc="include" pn="section-4.7">
        <name slugifiedName="name-ace-group-groupname-num">/ace-group/GROUPNAME/num</name>
        <t indent="0" pn="section-4.7-1">This resource implements the GET handler.</t>
        <section anchor="num-get" numbered="true" removeInRFC="false" toc="include" pn="section-4.7.1">
          <name slugifiedName="name-get-handler-5">GET Handler</name>
          <t indent="0" pn="section-4.7.1-1">The handler expects a GET request.</t>
          <t indent="0" pn="section-4.7.1-2">In addition to what is defined in <xref target="kdc-if-errors" format="default" sectionFormat="of" derivedContent="Section 4.1.2"/>, the handler verifies that the Client is a current member of the group. If the verification fails, the KDC <bcp14>MUST</bcp14> reply with a 4.03 (Forbidden) error response. The response <bcp14>MUST</bcp14> have Content-Format "application/concise-problem-details+cbor" and is formatted as defined in <xref target="kdc-if-errors" format="default" sectionFormat="of" derivedContent="Section 4.1.2"/>. Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' field  <bcp14>MUST</bcp14> be set to 0 ("Operation permitted only to group members").</t>
          <t indent="0" pn="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.</t>
          <t indent="0" pn="section-4.7.1-4">The payload of the response is formatted as a CBOR integer.</t>
          <section anchor="key-version" numbered="true" removeInRFC="false" toc="include" pn="section-4.7.1.1">
            <name slugifiedName="name-retrieve-the-keying-materia">Retrieve the Keying Material Version</name>
            <t indent="0" pn="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, which is formatted as defined in <xref target="num-get" format="default" sectionFormat="of" derivedContent="Section 4.7.1"/> and where GROUPNAME identifies the group. In particular, the version is incremented by the KDC every time the group keying material is renewed before it is distributed to the group members.</t>
            <t indent="0" pn="section-4.7.1.1-2"><xref target="fig-version" format="default" sectionFormat="of" derivedContent="Figure 25"/> gives an overview of the exchange described above, while <xref target="fig-version-2" format="default" sectionFormat="of" derivedContent="Figure 26"/> shows an example.</t>
            <figure anchor="fig-version" align="left" suppress-title="false" pn="figure-25">
              <name slugifiedName="name-message-flow-of-version-req">Message Flow of Version Request-Response</name>
              <artset pn="section-4.7.1.1-3.1">
                <artwork type="svg" align="center" pn="section-4.7.1.1-3.1.1">
		<svg xmlns="http://www.w3.org/2000/svg" version="1.1" viewBox="0 0 650 112" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
                    <path d="M 32,32 L 32,96" fill="none" stroke="black"/>
                    <path d="M 488,32 L 488,96" fill="none" stroke="black"/>
                    <path d="M 40,48 L 64,48" fill="none" stroke="black"/>
                    <path d="M 448,48 L 480,48" fill="none" stroke="black"/>
                    <path d="M 40,80 L 120,80" fill="none" stroke="black"/>
                    <path d="M 400,80 L 480,80" fill="none" stroke="black"/>
                    <polygon class="arrowhead" points="488,48 476,42.4 476,53.6" fill="black" transform="rotate(0,480,48)"/>
                    <polygon class="arrowhead" points="48,80 36,74.4 36,85.6" fill="black" transform="rotate(180,40,80)"/>
                    <g class="text">
                      <text x="28" y="20">Client</text>
                      <text x="488" y="20">KDC</text>
                      <text x="256" y="52">Version Request: GET /ace-group/GROUPNAME/num</text>
                      <text x="260" y="84">Version Response: 2.05 (Content)</text>
                    </g>
                  </svg>
                </artwork>
                <artwork type="ascii-art" align="center" pn="section-4.7.1.1-3.1.2">
Client                                                     KDC
   |                                                        |
   |---- Version Request: GET /ace-group/GROUPNAME/num ----&gt;|
   |                                                        |
   |&lt;---------- Version Response: 2.05 (Content) -----------|
   |                                                        |
</artwork>
              </artset>
            </figure>
            <figure anchor="fig-version-2" align="left" suppress-title="false" pn="figure-26">
              <name slugifiedName="name-example-of-version-request-">Example of Version Request-Response</name>
              <artwork align="left" pn="section-4.7.1.1-4.1">
Request:

Header: GET (Code=0.01)
Uri-Host: "kdc.example.com"
Uri-Path: "ace-group"
Uri-Path: "g1"
Uri-Path: "num"


Response:

Header: Content (Code=2.05)
Content-Format: 60 (application/cbor)
Payload (in CBOR diagnostic notation):
  13
  </artwork>
            </figure>
          </section>
        </section>
      </section>
      <section anchor="node-subresource" numbered="true" removeInRFC="false" toc="include" pn="section-4.8">
        <name slugifiedName="name-ace-group-groupname-nodes-n">/ace-group/GROUPNAME/nodes/NODENAME</name>
        <t indent="0" pn="section-4.8-1">This resource implements the GET, POST, and DELETE handlers.</t>
        <t indent="0" pn="section-4.8-2">In addition to what is defined in <xref target="kdc-if-errors" format="default" sectionFormat="of" derivedContent="Section 4.1.2"/>, each of the handlers performs the following two verifications.</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.8-3">
          <li pn="section-4.8-3.1">The handler verifies that the Client is a current member of the group. If the verification fails, the KDC <bcp14>MUST</bcp14> reply with a 4.03 (Forbidden) error response. The response <bcp14>MUST</bcp14> have Content-Format "application/concise-problem-details+cbor" and is formatted as defined in <xref target="kdc-if-errors" format="default" sectionFormat="of" derivedContent="Section 4.1.2"/>. Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' field  <bcp14>MUST</bcp14> be set to 0 ("Operation permitted only to group members").</li>
          <li pn="section-4.8-3.2">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.</li>
        </ul>
        <section anchor="node-get" numbered="true" removeInRFC="false" toc="include" pn="section-4.8.1">
          <name slugifiedName="name-get-handler-6">GET Handler</name>
          <t indent="0" pn="section-4.8.1-1">The handler expects a GET request.</t>
          <t indent="0" pn="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.</t>
          <t indent="0" pn="section-4.8.1-3">The payload of the response is formatted as a CBOR map, which includes the same fields of the response defined in <xref target="gid-get" format="default" sectionFormat="of" derivedContent="Section 4.3.2"/>. In particular, the format for the group keying material is the same as defined in the response of <xref target="gid-get" format="default" sectionFormat="of" derivedContent="Section 4.3.2"/>. If the 'exp' parameter is included, the 'exi' parameter <bcp14>MUST</bcp14> also be included. If the parameter 'exi' is included, its value specifies the residual lifetime of the group keying material from the current time at the KDC.</t>
          <t indent="0" pn="section-4.8.1-4">The CBOR map can include additional parameters that specify the individual keying material for the Client. The specific format of individual keying material for group members or of the information to derive such keying material <bcp14>MUST</bcp14> be defined in application profiles of this specification (<xref target="req27" format="none" sectionFormat="of" derivedContent="">REQ27</xref>), together with the corresponding CBOR map key that has to be registered in the "ACE Groupcomm Parameters" registry defined in <xref target="iana-reg" format="default" sectionFormat="of" derivedContent="Section 11.7"/>.</t>
          <t indent="0" pn="section-4.8.1-5">Optionally, the KDC can make the sub-resource at /ace-group/GROUPNAME/nodes/NODENAME also observable <xref target="RFC7641" format="default" sectionFormat="of" derivedContent="RFC7641"/> 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 <xref target="sec-node-removal" format="default" sectionFormat="of" derivedContent="Section 5"/>).</t>
          <t indent="0" pn="section-4.8.1-6">Note that the node could have also been observing the resource at /ace-group/GROUPNAME in order to be informed of changes in the group 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.</t>
          <t indent="0" pn="section-4.8.1-7">In order to mitigate this, a node that supports the CoAP No-Response Option <xref target="RFC7967" format="default" sectionFormat="of" derivedContent="RFC7967"/> 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).</t>
          <section anchor="update-keys" numbered="true" removeInRFC="false" toc="include" pn="section-4.8.1.1">
            <name slugifiedName="name-retrieve-group-and-individu">Retrieve Group and Individual Keying Material</name>
            <t indent="0" pn="section-4.8.1.1-1">When any of the following happens, a node <bcp14>MUST</bcp14> stop using the stored group keying material to protect outgoing messages and <bcp14>SHOULD</bcp14> stop using it to decrypt and verify incoming messages.</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.8.1.1-2">
              <li pn="section-4.8.1.1-2.1">Upon expiration of the keying material, according to what is indicated by the KDC through the 'exp' and/or 'exi' parameter (e.g., in a Join Response) or to a pre-configured value.</li>
              <li pn="section-4.8.1.1-2.2">Upon receiving a notification of revoked/renewed keying material from the KDC, possibly as part of an update of the keying material (rekeying) triggered by the KDC.</li>
              <li pn="section-4.8.1.1-2.3">Upon receiving messages from other group members without being able to retrieve the keying material to correctly decrypt them. This may be due to rekeying messages previously sent by the KDC that the Client was not able to receive or decrypt.</li>
            </ul>
            <t indent="0" pn="section-4.8.1.1-3">In either case, if it wants to continue participating in the group communication, the Client has to request the latest keying material from the KDC. To this end, the Client sends a CoAP GET request to the /ace-group/GROUPNAME/nodes/NODENAME endpoint at the KDC, formatted as specified in <xref target="node-get" format="default" sectionFormat="of" derivedContent="Section 4.8.1"/>. The Client can request the latest keying material from the KDC before the currently stored, old keying material reaches its expiration time.</t>
            <t indent="0" pn="section-4.8.1.1-4">Note that policies can be set up so that the Client sends a Key Distribution Request to the KDC only after a given number of received messages could not be decrypted (because of failed decryption processing or the inability to retrieve the necessary keying material).</t>
            <t indent="0" pn="section-4.8.1.1-5">It is application dependent and pertaining to the used secure message exchange (e.g., <xref target="I-D.ietf-core-oscore-groupcomm" format="default" sectionFormat="of" derivedContent="GROUP-OSCORE"/>) to set up these policies for instructing Clients to retain incoming messages and for how long (<xref target="opt11" format="none" sectionFormat="of" derivedContent="">OPT11</xref>). This allows Clients to possibly decrypt such messages after getting updated keying material, rather than just consider them invalid messages to discard right away.</t>
            <t indent="0" pn="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 Sections <xref target="sec-key-retrieval" format="counter" sectionFormat="of" derivedContent="4.4.1.1"/> and <xref target="sec-key-retrieval-all" format="counter" sectionFormat="of" derivedContent="4.4.2.1"/>) and a KDC Authentication Credential Request (see <xref target="kdc-pub-key" format="default" sectionFormat="of" derivedContent="Section 4.5.1.1"/>), respectively.</t>
            <t indent="0" pn="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.</t>
            <t indent="0" pn="section-4.8.1.1-8"><xref target="fig-key-redistr-req-resp" format="default" sectionFormat="of" derivedContent="Figure 27"/> gives an overview of the exchange described above, while <xref target="fig-key-redistr-req-resp-2" format="default" sectionFormat="of" derivedContent="Figure 28"/> shows an example.</t>
            <figure anchor="fig-key-redistr-req-resp" align="left" suppress-title="false" pn="figure-27">
              <name slugifiedName="name-message-flow-of-key-distribu">Message Flow of Key Distribution Request-Response</name>
              <artset pn="section-4.8.1.1-9.1">
                <artwork type="svg" align="center" pn="section-4.8.1.1-9.1.1">
		  <svg xmlns="http://www.w3.org/2000/svg" version="1.1" viewBox="0 0 650 128" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
                    <path d="M 32,32 L 32,112" fill="none" stroke="black"/>
                    <path d="M 528,32 L 528,112" fill="none" stroke="black"/>
                    <path d="M 40,48 L 176,48" fill="none" stroke="black"/>
                    <path d="M 400,48 L 520,48" fill="none" stroke="black"/>
                    <path d="M 40,96 L 104,96" fill="none" stroke="black"/>
                    <path d="M 456,96 L 520,96" fill="none" stroke="black"/>
                    <polygon class="arrowhead" points="528,48 516,42.4 516,53.6" fill="black" transform="rotate(0,520,48)"/>
                    <polygon class="arrowhead" points="48,96 36,90.4 36,101.6" fill="black" transform="rotate(180,40,96)"/>
                    <g class="text">
                      <text x="28" y="20">Client</text>
                      <text x="528" y="20">KDC</text>
                      <text x="288" y="52">Key Distribution Request:</text>
                      <text x="280" y="68">GET /ace-group/GROUPNAME/nodes/NODENAME</text>
                      <text x="280" y="100">Key Distribution Response: 2.05 (Content)</text>
                    </g>
                  </svg>
                </artwork>
                <artwork type="ascii-art" align="center" pn="section-4.8.1.1-9.1.2">
Client                                                          KDC
   |                                                             |
   |------------------ Key Distribution Request: ---------------&gt;|
   |           GET /ace-group/GROUPNAME/nodes/NODENAME           |
   |                                                             |
   |&lt;-------- Key Distribution Response: 2.05 (Content) ---------|
   |                                                             |
</artwork>
              </artset>
            </figure>
            <figure anchor="fig-key-redistr-req-resp-2" align="left" suppress-title="false" pn="figure-28">
              <name slugifiedName="name-example-of-key-distribution-">Example of Key Distribution Request-Response</name>
              <artwork align="left" pn="section-4.8.1.1-10.1">
Request:

Header: GET (Code=0.01)
Uri-Host: "kdc.example.com"
Uri-Path: "ace-group"
Uri-Path: "g1"
Uri-Path: "nodes"
Uri-Path: "c101"


Response:

Header: Content (Code=2.05)
Content-Format: 261 (application/ace-groupcomm+cbor)
Payload (in CBOR diagnostic notation, with "ind-key" being the
         profile-specified label for individual keying material):
{
  / gkty / 7: 65600,
  / key /  8: h'73657373696f6e6b6579',
  / num /  9: 12,
   "ind-key": h'fcae9023'
}
</artwork>
            </figure>
          </section>
        </section>
        <section anchor="node-put" numbered="true" removeInRFC="false" toc="include" pn="section-4.8.2">
          <name slugifiedName="name-post-handler-2">POST Handler</name>
          <t indent="0" pn="section-4.8.2-1">The POST handler processes requests from a Client that asks for new individual keying material, as required to process messages exchanged in the group.</t>
          <t indent="0" pn="section-4.8.2-2">The handler expects a POST request with an empty payload.</t>
          <t indent="0" pn="section-4.8.2-3">In addition to what is defined in <xref target="kdc-if-errors" format="default" sectionFormat="of" derivedContent="Section 4.1.2"/> and at the beginning of <xref target="node-subresource" format="default" sectionFormat="of" derivedContent="Section 4.8"/>, the handler verifies that this operation is consistent with the set of roles that the Client has in the group (<xref target="req11" format="none" sectionFormat="of" derivedContent="">REQ11</xref>). If the verification fails, the KDC <bcp14>MUST</bcp14> reply with a 4.00 (Bad Request) error response. The response <bcp14>MUST</bcp14> have Content-Format "application/concise-problem-details+cbor" and is formatted as defined in <xref target="kdc-if-errors" format="default" sectionFormat="of" derivedContent="Section 4.1.2"/>. Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' field  <bcp14>MUST</bcp14> be set to 1 ("Request inconsistent with the current roles").</t>
          <t indent="0" pn="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 <bcp14>MUST</bcp14> reply with a 5.03 (Service unavailable) error response. The response <bcp14>MUST</bcp14> have Content-Format "application/concise-problem-details+cbor" and is formatted as defined in <xref target="kdc-if-errors" format="default" sectionFormat="of" derivedContent="Section 4.1.2"/>. Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' field  <bcp14>MUST</bcp14> be set to 4 ("No available individual keying material").</t>
          <t indent="0" pn="section-4.8.2-5">If all verifications succeed, the handler replies with a 2.04 (Changed) 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 such keying material <bcp14>MUST</bcp14> be defined in application profiles of this specification (<xref target="req27" format="none" sectionFormat="of" derivedContent="">REQ27</xref>), together with the corresponding CBOR map key that has to be registered in the "ACE Groupcomm Parameters" registry defined in <xref target="iana-reg" format="default" sectionFormat="of" derivedContent="Section 11.7"/>.</t>
          <t indent="0" pn="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 <bcp14>MAY</bcp14> also extend this handler in order to achieve different akin outcomes (<xref target="opt12" format="none" sectionFormat="of" derivedContent="">OPT12</xref>), for instance:</t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.8.2-7">
            <li pn="section-4.8.2-7.1">Not providing the Client with newly generated individual keying material, but rather rekeying the whole group, i.e., providing all the current group members with newly generated group keying material.</li>
            <li pn="section-4.8.2-7.2">Both providing the Client with newly generated individual keying material, as well as rekeying the whole group, i.e., providing all the current group members with newly generated group keying material.</li>
          </ul>
          <t indent="0" pn="section-4.8.2-8">In either case, the handler may specify the new group keying material as part of the 2.04 (Changed) response.</t>
          <t indent="0" pn="section-4.8.2-9">Note that this handler is not intended to accommodate requests from a group member to trigger a group rekeying, whose scheduling and execution is an exclusive prerogative of the KDC (also see related security considerations in <xref target="sec-cons-rekeying" format="default" sectionFormat="of" derivedContent="Section 10.2"/>).</t>
          <section anchor="new-keys" numbered="true" removeInRFC="false" toc="include" pn="section-4.8.2.1">
            <name slugifiedName="name-request-to-change-individua">Request to Change Individual Keying Material</name>
            <t indent="0" pn="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 Authenticated Encryption with Associated Data (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.</t>
            <t indent="0" pn="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 POST request to the /ace-group/GROUPNAME/nodes/NODENAME endpoint at the KDC, which is formatted as defined in  <xref target="node-get" format="default" sectionFormat="of" derivedContent="Section 4.8.1"/>, where GROUPNAME identifies the group and NODENAME is the node name of the Client.</t>
            <t indent="0" pn="section-4.8.2.1-3"><xref target="fig-renewal-req-resp" format="default" sectionFormat="of" derivedContent="Figure 29"/> gives an overview of the exchange described above, while <xref target="fig-renewal-req-resp-2" format="default" sectionFormat="of" derivedContent="Figure 30"/> shows an example.</t>
            <figure anchor="fig-renewal-req-resp" align="left" suppress-title="false" pn="figure-29">
              <name slugifiedName="name-message-flow-of-key-renewal">Message Flow of Key Renewal Request-Response</name>
              <artset pn="section-4.8.2.1-4.1">
                <artwork type="svg" align="center" pn="section-4.8.2.1-4.1.1">
		  <svg xmlns="http://www.w3.org/2000/svg" version="1.1" viewBox="0 0 650 128" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
                    <path d="M 32,32 L 32,112" fill="none" stroke="black"/>
                    <path d="M 480,32 L 480,112" fill="none" stroke="black"/>
                    <path d="M 40,48 L 160,48" fill="none" stroke="black"/>
                    <path d="M 344,48 L 472,48" fill="none" stroke="black"/>
                    <path d="M 40,96 L 104,96" fill="none" stroke="black"/>
                    <path d="M 416,96 L 472,96" fill="none" stroke="black"/>
                    <polygon class="arrowhead" points="480,48 468,42.4 468,53.6" fill="black" transform="rotate(0,472,48)"/>
                    <polygon class="arrowhead" points="48,96 36,90.4 36,101.6" fill="black" transform="rotate(180,40,96)"/>
                    <g class="text">
                      <text x="28" y="20">Client</text>
                      <text x="480" y="20">KDC</text>
                      <text x="252" y="52">Key Renewal Request:</text>
                      <text x="252" y="68">POST /ace-group/GROUPNAME/nodes/NODENAME</text>
                      <text x="260" y="100">Key Renewal Response: 2.04 (Changed)</text>
                    </g>
                  </svg>
                </artwork>
                <artwork type="ascii-art" align="center" pn="section-4.8.2.1-4.1.2">
Client                                                    KDC
   |                                                       |
   |---------------- Key Renewal Request: ----------------&gt;|
   |        POST /ace-group/GROUPNAME/nodes/NODENAME       |
   |                                                       |
   |&lt;-------- Key Renewal Response: 2.04 (Changed) --------|
   |                                                       |
</artwork>
              </artset>
            </figure>
            <figure anchor="fig-renewal-req-resp-2" align="left" suppress-title="false" pn="figure-30">
              <name slugifiedName="name-example-of-key-renewal-requ">Example of Key Renewal Request-Response</name>
              <artwork align="left" pn="section-4.8.2.1-5.1">
Request:

Header: POST (Code=0.02)
Uri-Host: "kdc.example.com"
Uri-Path: "ace-group"
Uri-Path: "g1"
Uri-Path: "nodes"
Uri-Path: "c101"


Response:

Header: Changed (Code=2.04)
Content-Format: 261 (application/ace-groupcomm+cbor)
Payload (in CBOR diagnostic notation, with "ind-key" being the
         profile-specified label for individual keying material):
{
  "ind-key": h'b71acc28'
}
</artwork>
            </figure>
            <t indent="0" pn="section-4.8.2.1-6">Note that there is a difference between the Key Renewal Request in this section and the Key Distribution Request in <xref target="update-keys" format="default" sectionFormat="of" derivedContent="Section 4.8.1.1"/>. The former asks the KDC for new individual keying material, while the latter asks the KDC for the current group keying material together with the current individual keying material.</t>
            <t indent="0" pn="section-4.8.2.1-7">As discussed in <xref target="node-put" format="default" sectionFormat="of" derivedContent="Section 4.8.2"/>, application profiles of this specification may define alternative outcomes for the Key Renewal Request-Response exchange (<xref target="opt12" format="none" sectionFormat="of" derivedContent="">OPT12</xref>), where the provisioning of new individual keying material is replaced by or combined with the execution of a whole group rekeying.</t>
          </section>
        </section>
        <section anchor="node-delete" numbered="true" removeInRFC="false" toc="include" pn="section-4.8.3">
          <name slugifiedName="name-delete-handler">DELETE Handler</name>
          <t indent="0" pn="section-4.8.3-1">The DELETE handler removes the node identified by NODENAME from the group identified by GROUPNAME.</t>
          <t indent="0" pn="section-4.8.3-2">The handler expects a DELETE request with an empty payload.</t>
          <t indent="0" pn="section-4.8.3-3">In addition to what is defined in <xref target="kdc-if-errors" format="default" sectionFormat="of" derivedContent="Section 4.1.2"/>, the handler verifies that the Client is a current member of the group. If the verification fails, the KDC <bcp14>MUST</bcp14> reply with a 4.03 (Forbidden) error response. The response <bcp14>MUST</bcp14> have Content-Format "application/concise-problem-details+cbor" and is formatted as defined in <xref target="kdc-if-errors" format="default" sectionFormat="of" derivedContent="Section 4.1.2"/>. Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' field  <bcp14>MUST</bcp14> be set to 0 ("Operation permitted only to group members").</t>
          <t indent="0" pn="section-4.8.3-4">If all verification succeeds, the handler performs the actions defined in <xref target="sec-node-removal" format="default" sectionFormat="of" derivedContent="Section 5"/> and replies with a 2.02 (Deleted) response with an empty payload.</t>
          <section anchor="ssec-group-leaving" numbered="true" removeInRFC="false" toc="include" pn="section-4.8.3.1">
            <name slugifiedName="name-leave-the-group">Leave the Group</name>
            <t indent="0" pn="section-4.8.3.1-1">A Client can actively request to leave the group. In this case, the Client sends a CoAP DELETE request to the endpoint /ace-group/GROUPNAME/nodes/NODENAME at the KDC, where GROUPNAME identifies the group and NODENAME is the Client's node name.</t>
            <t indent="0" pn="section-4.8.3.1-2">Note that, after having left the group, the Client may wish to join it again. Then, as long as the Client is still authorized to join the group, i.e., the associated access token is still valid, the Client can request to rejoin the group directly to the KDC (see <xref target="ssec-key-distribution-exchange" format="default" sectionFormat="of" derivedContent="Section 4.3.1.1"/>) without having to retrieve a new access token from the AS.</t>
          </section>
        </section>
      </section>
      <section anchor="ace-groupgroupnamenodesnodenamecred" numbered="true" removeInRFC="false" toc="include" pn="section-4.9">
        <name slugifiedName="name-ace-group-groupname-nodes-no">/ace-group/GROUPNAME/nodes/NODENAME/cred</name>
        <t indent="0" pn="section-4.9-1">This resource implements the POST handler.</t>
        <section anchor="node-pub-key-post" numbered="true" removeInRFC="false" toc="include" pn="section-4.9.1">
          <name slugifiedName="name-post-handler-3">POST Handler</name>
          <t indent="0" pn="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.</t>
          <t indent="0" pn="section-4.9.1-2">The handler expects a POST request with the payload as specified in <xref target="gid-post" format="default" sectionFormat="of" derivedContent="Section 4.3.1"/>, with the difference that the payload includes only the parameters 'client_cred', 'cnonce', and 'client_cred_verify'.</t>
          <t indent="0" pn="section-4.9.1-3">The PoP evidence included in the 'client_cred_verify' parameter is computed in the same way considered in <xref target="gid-post" format="default" sectionFormat="of" derivedContent="Section 4.3.1"/> and defined by the specific application profile (<xref target="req14" format="none" sectionFormat="of" derivedContent="">REQ14</xref>) by using the following to build the PoP input: i) the same scope entry specified by the Client in the 'scope' parameter of the latest Join Request that the Client sent to the KDC in order to join the group identified by GROUPNAME; ii) the latest N_S value stored by the Client; and iii) a new N_C nonce generated by the Client and specified in the parameter 'cnonce' of this request.</t>
          <t indent="0" pn="section-4.9.1-4">An example of PoP input to compute 'client_cred_verify' using CBOR encoding is given in <xref target="fig-client-cred-input-2" format="default" sectionFormat="of" derivedContent="Figure 31"/>.</t>
          <t indent="0" pn="section-4.9.1-5">It is <bcp14>REQUIRED</bcp14> for application profiles to define the specific formats of authentication credentials that are acceptable to use in the group (<xref target="req6" format="none" sectionFormat="of" derivedContent="">REQ6</xref>).</t>
          <t indent="0" pn="section-4.9.1-6">In addition to what is defined in <xref target="kdc-if-errors" format="default" sectionFormat="of" derivedContent="Section 4.1.2"/> and at the beginning of <xref target="node-subresource" format="default" sectionFormat="of" derivedContent="Section 4.8"/>, 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 <bcp14>MUST</bcp14> reply with a 4.00 (Bad Request) error response. The response <bcp14>MUST</bcp14> have Content-Format "application/concise-problem-details+cbor" and is formatted as defined in <xref target="kdc-if-errors" format="default" sectionFormat="of" derivedContent="Section 4.1.2"/>. Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' field  <bcp14>MUST</bcp14> be set to 1 ("Request inconsistent with the current roles").</t>
          <t indent="0" pn="section-4.9.1-7">If the KDC cannot retrieve the 'kdcchallenge' associated with this Client (see <xref target="token-post" format="default" sectionFormat="of" derivedContent="Section 3.3"/>), the KDC <bcp14>MUST</bcp14> reply with a 4.00 (Bad Request) error response, which <bcp14>MUST</bcp14> also have Content-Format "application/ace-groupcomm+cbor". The payload of the error response is a CBOR map including the 'kdcchallenge' parameter, which specifies a newly generated 'kdcchallenge' value. In such a case, the KDC <bcp14>MUST</bcp14> store the newly generated value as the 'kdcchallenge' value associated with this Client, replacing the currently stored value (if any).</t>
          <t indent="0" pn="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 <bcp14>MUST</bcp14> reply with a 4.00 (Bad Request) error response. The response <bcp14>MUST</bcp14> have Content-Format  "application/concise-problem-details+cbor" and is formatted as defined in <xref target="kdc-if-errors" format="default" sectionFormat="of" derivedContent="Section 4.1.2"/>. Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' field  <bcp14>MUST</bcp14> be set to 2 ("Authentication credential incompatible with the group configuration").</t>
          <t indent="0" pn="section-4.9.1-9">Otherwise, the handler verifies the PoP evidence conveyed in the 'client_cred_verify' parameter of the request, by using the authentication credential specified in the 'client_cred' parameter as well as the same way considered in <xref target="gid-post" format="default" sectionFormat="of" derivedContent="Section 4.3.1"/> and defined by the specific application profile (<xref target="req14" format="none" sectionFormat="of" derivedContent="">REQ14</xref>). If the PoP evidence does not pass verification, the handler <bcp14>MUST</bcp14> reply with a 4.00 (Bad Request) error response. The response <bcp14>MUST</bcp14> have Content-Format "application/concise-problem-details+cbor" and is formatted as defined in <xref target="kdc-if-errors" format="default" sectionFormat="of" derivedContent="Section 4.1.2"/>. Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' field  <bcp14>MUST</bcp14> be set to 3 ("Invalid proof-of-possession evidence").</t>
          <t indent="0" pn="section-4.9.1-10">If all verifications succeed, the handler performs the following actions.</t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.9.1-11">
            <li pn="section-4.9.1-11.1">The handler associates the authentication credential from the 'client_cred' parameter of the request with the node identifier NODENAME, as well as with the access token associated with the node identified by NODENAME.</li>
            <li pn="section-4.9.1-11.2">In the stored list of group members' authentication credentials for the group identified by GROUPNAME, the handler replaces the authentication credential of the node identified by NODENAME with the authentication credential specified in the 'client_cred' parameter of the request.</li>
          </ul>
          <t indent="0" pn="section-4.9.1-12">Then, the handler replies with a 2.04 (Changed) response, which does not include a payload.</t>
          <figure anchor="fig-client-cred-input-2" align="left" suppress-title="false" pn="figure-31">
            <name slugifiedName="name-example-of-pop-input-to-comput">Example of PoP Input to Compute 'client_cred_verify' Using CBOR Encoding</name>
            <artwork align="left" pn="section-4.9.1-13.1">
scope, N_S, and N_C expressed in CBOR diagnostic notation:
  scope = h'826667726f7570316673656e646572'
  N_S   = h'018a278f7faab55a'
  N_C   = h'0446baefc56111bf'


scope, N_S, and N_C as CBOR encoded byte strings:
  scope = 0x4f826667726F7570316673656E646572
  N_S   = 0x48018a278f7faab55a
  N_C   = 0x480446baefc56111bf

PoP input:
  0x4f 826667726f7570316673656e646572
    48 018a278f7faab55a 48 0446baefc56111bf
</artwork>
          </figure>
          <section anchor="update-pub-key" numbered="true" removeInRFC="false" toc="include" pn="section-4.9.1.1">
            <name slugifiedName="name-uploading-an-authentication">Uploading an Authentication Credential</name>
            <t indent="0" pn="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.</t>
            <t indent="0" pn="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 identifies the group and NODENAME is the Client's node name.</t>
            <t indent="0" pn="section-4.9.1.1-3">The request is formatted as specified in <xref target="node-pub-key-post" format="default" sectionFormat="of" derivedContent="Section 4.9.1"/>.</t>
            <t indent="0" pn="section-4.9.1.1-4"><xref target="fig-pub-key-update-req-resp" format="default" sectionFormat="of" derivedContent="Figure 32"/> gives an overview of the exchange described above, while <xref target="fig-pub-key-update-req-resp-2" format="default" sectionFormat="of" derivedContent="Figure 33"/> shows an example.</t>
            <figure anchor="fig-pub-key-update-req-resp" align="left" suppress-title="false" pn="figure-32">
              <name slugifiedName="name-message-flow-of-authenticatio">Message Flow of Authentication Credential Update Request-Response</name>
              <artset pn="section-4.9.1.1-5.1">
                <artwork type="svg" align="center" pn="section-4.9.1.1-5.1.1">
		  <svg xmlns="http://www.w3.org/2000/svg" version="1.1" viewBox="0 0 650 128" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
                    <path d="M 8,32 L 8,112" fill="none" stroke="black"/>
                    <path d="M 528,32 L 528,112" fill="none" stroke="black"/>
                    <path d="M 16,48 L 96,48" fill="none" stroke="black"/>
                    <path d="M 448,48 L 520,48" fill="none" stroke="black"/>
                    <path d="M 16,96 L 32,96" fill="none" stroke="black"/>
                    <polygon class="arrowhead" points="528,48 516,42.4 516,53.6" fill="black" transform="rotate(0,520,48)"/>
                    <polygon class="arrowhead" points="24,96 12,90.4 12,101.6" fill="black" transform="rotate(180,16,96)"/>
                    <g class="text">
                      <text x="28" y="20">Client</text>
                      <text x="528" y="20">KDC</text>
                      <text x="272" y="52">Authentication Credential Update Request:</text>
                      <text x="264" y="68">POST /ace-group/GROUPNAME/nodes/NODENAME/cred</text>
                      <text x="284" y="100">Authentication Credential Update Response: 2.04 (Changed) --</text>
                    </g>
                  </svg>
                </artwork>
                <artwork type="ascii-art" align="center" pn="section-4.9.1.1-5.1.2">
Client                                                          KDC
|                                                                |
|----------- Authentication Credential Update Request: ---------&gt;|
|         POST /ace-group/GROUPNAME/nodes/NODENAME/cred          |
|                                                                |
|&lt;-- Authentication Credential Update Response: 2.04 (Changed) --|
|                                                                |
</artwork>
              </artset>
            </figure>
            <figure anchor="fig-pub-key-update-req-resp-2" align="left" suppress-title="false" pn="figure-33">
              <name slugifiedName="name-example-of-authentication-cre">Example of Authentication Credential Update Request-Response</name>
              <artwork align="left" pn="section-4.9.1.1-6.1">
Request:

Header: POST (Code=0.02)
Uri-Host: "kdc.example.com"
Uri-Path: "ace-group"
Uri-Path: "g1"
Uri-Path: "nodes"
Uri-Path: "c101"
Uri-Path: "cred"
Content-Format: 261 (application/ace-groupcomm+cbor)
Payload (in CBOR diagnostic notation):
{
  / client_cred /         5: h'a2026008a101a501020241fc20012158
                               20bac5b11cad8f99f9c72b05cf4b9e26
                               d244dc189f745228255a219a86d6a09e
                               ff22582020138bf82dc1b6d562be0fa5
                               4ab7804a3a64b6d72ccfed6b6fb6ed28
                               bbfc117e',
  / cnonce /              6: h'0446baefc56111bf',
  / client_cred_verify / 24: h'e2aeafd40d69d19dfe6e52077c5d7ff4
                               e408282cbefb5d06cbf414af2e19d982
                               ac45ac98b8544c908b4507de1e90b717
                               c3d34816fe926a2b98f53afd2fa0f30a'
}


Response:

Header: Changed (Code=2.04)
</artwork>
            </figure>
            <t indent="0" pn="section-4.9.1.1-7">Additionally, after updating its own authentication credential, a group member <bcp14>MAY</bcp14> send to the group a number of requests, including an identifier of the updated authentication credential, to notify other group members that they have to retrieve it. How this is done depends on the group communication protocol used and therefore is application profile specific (<xref target="opt13" format="none" sectionFormat="of" derivedContent="">OPT13</xref>).</t>
          </section>
        </section>
      </section>
    </section>
    <section anchor="sec-node-removal" numbered="true" removeInRFC="false" toc="include" pn="section-5">
      <name slugifiedName="name-removal-of-a-group-member">Removal of a Group Member</name>
      <t indent="0" pn="section-5-1">A Client identified by NODENAME may be removed from a group identified by GROUPNAME where it is a member, for example, due to the following reasons.</t>
      <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-5-2">
	<li pn="section-5-2.1" derivedCounter="1.">The Client explicitly asks to leave the group, as defined in <xref target="ssec-group-leaving" format="default" sectionFormat="of" derivedContent="Section 4.8.3.1"/>.</li>
        <li pn="section-5-2.2" derivedCounter="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.</li>
        <li pn="section-5-2.3" derivedCounter="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 has been revoked. If the AS provides token introspection (see <xref section="5.9" sectionFormat="of" target="RFC9200" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9200#section-5.9" derivedContent="RFC9200"/>), the KDC can optionally use it and check whether the Client is still authorized.</li>
      </ol>
      <t indent="0" pn="section-5-3">In all cases, the KDC performs the following actions.</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5-4">
        <li pn="section-5-4.1">The KDC removes the Client from the list of current members of the group. When doing so, the KDC deletes the currently stored value of 'clientchallenge' for that Client, which was specified in the latest Join Request that the Client sent to the KDC in order to join the group (see <xref target="gid-post" format="default" sectionFormat="of" derivedContent="Section 4.3.1"/>).</li>
        <li pn="section-5-4.2">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.</li>
        <li pn="section-5-4.3">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.</li>
        <li pn="section-5-4.4">
          <t indent="0" pn="section-5-4.4.1">If the sub-resource /nodes/NODENAME was created for the removed Client, the KDC deletes that sub-resource.  </t>
          <t indent="0" pn="section-5-4.4.2">
In case of forced eviction, i.e., for cases 2 and 3 above, the KDC <bcp14>MAY</bcp14> explicitly inform the removed Client by means of the following methods.  </t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5-4.4.3">
            <li pn="section-5-4.4.3.1">If the evicted Client implements the 'control_uri' resource (see <xref target="gid-post" format="default" sectionFormat="of" derivedContent="Section 4.3.1"/>), the KDC sends a DELETE request to that resource, targeting the URI specified in the 'control_uri' parameter of the Join Request (see <xref target="gid-post" format="default" sectionFormat="of" derivedContent="Section 4.3.1"/>).</li>
            <li pn="section-5-4.4.3.2">
              <t indent="0" pn="section-5-4.4.3.2.1">If the evicted Client is observing its associated sub-resource at /ace-group/GROUPNAME/nodes/NODENAME (see <xref target="node-get" format="default" sectionFormat="of" derivedContent="Section 4.8.1"/>), 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 <xref section="3.2" sectionFormat="of" target="RFC7641" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7641#section-3.2" derivedContent="RFC7641"/>).      </t>
              <t indent="0" pn="section-5-4.4.3.2.2">
The response <bcp14>MUST</bcp14> have Content-Format "application/concise-problem-details+cbor" and is formatted as defined in <xref target="kdc-if-errors" format="default" sectionFormat="of" derivedContent="Section 4.1.2"/>. Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' field  <bcp14>MUST</bcp14> be set to 5 ("Group membership terminated").</t>
            </li>
          </ul>
        </li>
        <li pn="section-5-4.5">If forward security is prescribed by application policies installed at the KDC or by the used application profile of this specification, then the KDC <bcp14>MUST</bcp14> generate new group keying material and securely distribute it to all the current group members except the leaving node (see <xref target="sec-group-rekeying" format="default" sectionFormat="of" derivedContent="Section 6"/>).</li>
      </ul>
    </section>
    <section anchor="sec-group-rekeying" numbered="true" removeInRFC="false" toc="include" pn="section-6">
      <name slugifiedName="name-group-rekeying-process">Group Rekeying Process</name>
      <t indent="0" pn="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.
      Some reasons that can trigger a group rekeying include 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.</t>
      <t indent="0" pn="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 needs 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.</t>
      <t indent="0" pn="section-6-3">The KDC <bcp14>MUST</bcp14> 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 the group rekeying is completed, the KDC <bcp14>MUST</bcp14> delete the old keying material and <bcp14>SHOULD</bcp14> store the newly distributed keying material in persistent storage.</t>
      <t indent="0" pn="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 for one or multiple group members, hereafter referred to as target group members. The KDC <bcp14>MUST</bcp14> support at least the "Point-to-Point" group rekeying scheme described in <xref target="point-to-point-rekeying" format="default" sectionFormat="of" derivedContent="Section 6.1"/> and <bcp14>MAY</bcp14> support additional ones.</t>
      <t indent="0" pn="section-6-5">Each rekeying message <bcp14>MUST</bcp14> have Content-Format  "application/ace-groupcomm+cbor" and its payload is formatted as a CBOR map, which <bcp14>MUST</bcp14> include at least the information specified in the Key Distribution Response message (see <xref target="gid-get" format="default" sectionFormat="of" derivedContent="Section 4.3.2"/>), i.e., the parameters 'gkty', 'key', and 'num' defined in <xref target="gid-post" format="default" sectionFormat="of" derivedContent="Section 4.3.1"/>. The CBOR map <bcp14>SHOULD</bcp14> also include the parameters 'exp' and 'exi'. If the 'exp' parameter is included, the 'exi' parameter <bcp14>MUST</bcp14> also be included. The CBOR map <bcp14>MAY</bcp14> include the parameter 'mgt_key_material' to specify new administrative keying material for the target group members if it is relevant for the used rekeying scheme.</t>
      <t indent="0" pn="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 <bcp14>MAY</bcp14> also include the authentication credentials that those Clients use in the group, together with the roles and node identifier that each of such Clients has in the group. It is <bcp14>RECOMMENDED</bcp14> to specify this information by means of the parameters 'creds', 'peer_roles', and 'peer_identifiers', like it is done in the Join Response message (see <xref target="gid-post" format="default" sectionFormat="of" derivedContent="Section 4.3.1"/>).</t>
      <t indent="0" pn="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 <bcp14>MAY</bcp14> define additional information to include in rekeying messages for the "Point-to-Point" group rekeying scheme defined in <xref target="point-to-point-rekeying" format="default" sectionFormat="of" derivedContent="Section 6.1"/> (<xref target="opt14" format="none" sectionFormat="of" derivedContent="">OPT14</xref>).</t>
      <t indent="0" pn="section-6-8">Consistently with the used group rekeying scheme, the actual delivery of rekeying messages can occur through different approaches, as discussed in Sections <xref target="point-to-point-rekeying" format="counter" sectionFormat="of" derivedContent="6.1"/> and <xref target="one-to-many-rekeying" format="counter" sectionFormat="of" derivedContent="6.2"/>.</t>
      <t indent="0" pn="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 <xref target="sec-misalignment-keying-material" format="default" sectionFormat="of" derivedContent="Section 6.3"/>. Further security considerations related to the group rekeying process are compiled in <xref target="sec-cons-rekeying" format="default" sectionFormat="of" derivedContent="Section 10.2"/>.</t>
      <section anchor="point-to-point-rekeying" numbered="true" removeInRFC="false" toc="include" pn="section-6.1">
        <name slugifiedName="name-point-to-point-group-rekeyi">Point-to-Point Group Rekeying</name>
        <t indent="0" pn="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 secure communication 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.</t>
        <t indent="0" pn="section-6.1-2">This is the approach taken by the basic "Point-to-Point" group rekeying scheme, which the KDC can explicitly indicate in the Join Response (see <xref target="gid-post" format="default" sectionFormat="of" derivedContent="Section 4.3.1"/>), through the 'rekeying_scheme' parameter specifying the value 0.</t>
        <t indent="0" pn="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, coexisting ways.</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.1-4">
          <li pn="section-6.1-4.1">
            <t indent="0" pn="section-6.1-4.1.1">The KDC <bcp14>SHOULD</bcp14> make the /ace-group/GROUPNAME resource observable <xref target="RFC7641" format="default" sectionFormat="of" derivedContent="RFC7641"/>. 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.  </t>
            <t indent="0" pn="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 <bcp14>MUST</bcp14> have Content-Format "application/concise-problem-details+cbor" and is formatted as defined in <xref target="kdc-if-errors" format="default" sectionFormat="of" derivedContent="Section 4.1.2"/>. Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' field  <bcp14>MUST</bcp14> be set to 6 ("Group deleted").</t>
          </li>
          <li pn="section-6.1-4.2">
            <t indent="0" pn="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 <xref target="gid-post" format="default" sectionFormat="of" derivedContent="Section 4.3.1"/>), the KDC can provide that group member with the new group keying material by sending a unicast POST request to that URI.  </t>
            <t indent="0" pn="section-6.1-4.2.2">
A Client that does not plan to observe the /ace-group/GROUPNAME resource at the KDC <bcp14>SHOULD</bcp14> specify a URI in the 'control_uri' parameter of the Join Request upon joining the group.</t>
          </li>
        </ul>
        <t indent="0" pn="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 will not be able to participate in 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 the /ace-group/GROUPNAME or /ace-group/GROUPNAME/nodes/NODENAME resource at the KDC (see Sections <xref target="gid-get" format="counter" sectionFormat="of" derivedContent="4.3.2"/> and <xref target="node-get" format="counter" sectionFormat="of" derivedContent="4.8.1"/>, respectively).</t>
        <t indent="0" pn="section-6.1-6"><xref target="fig-rekeying-example-1" format="default" sectionFormat="of" derivedContent="Figure 34"/> provides an example of point-to-point group rekeying. In particular, the example makes the following assumptions:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.1-7">
          <li pn="section-6.1-7.1">The group currently consists of four group members, namely C1, C2, C3, and C4.</li>
          <li pn="section-6.1-7.2">Each group member, when joining the group, provided the KDC with a URI in the 'control_uri' parameter with url-path "grp-rek".</li>
          <li pn="section-6.1-7.3">Before the group rekeying is performed, the keying material used in the group has version number num=5.</li>
          <li pn="section-6.1-7.4">The KDC performs the group rekeying in such a way to evict the group member C3, which has been found to be compromised.</li>
        </ul>
        <t indent="0" pn="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.</t>
        <figure anchor="fig-rekeying-example-1" align="left" suppress-title="false" pn="figure-34">
          <name slugifiedName="name-example-of-message-exchange">Example of Message Exchanges for a Point-to-Point Group Rekeying</name>
          <artset pn="section-6.1-9.1">
            <artwork type="svg" align="center" pn="section-6.1-9.1.1"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" viewBox="0 0 700 384" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px">
                <path d="M 32,32 L 32,64" fill="none" stroke="black"/>
                <path d="M 40,256 L 40,288" fill="none" stroke="black"/>
                <path d="M 80,72 L 80,208" fill="none" stroke="black"/>
                <path d="M 112,256 L 112,288" fill="none" stroke="black"/>
                <path d="M 184,256 L 184,288" fill="none" stroke="black"/>
                <path d="M 224,72 L 224,208" fill="none" stroke="black"/>
                <path d="M 256,256 L 256,288" fill="none" stroke="black"/>
                <path d="M 328,256 L 328,288" fill="none" stroke="black"/>
                <path d="M 400,256 L 400,288" fill="none" stroke="black"/>
                <path d="M 480,256 L 480,288" fill="none" stroke="black"/>
                <path d="M 520,72 L 520,208" fill="none" stroke="black"/>
                <path d="M 552,32 L 552,64" fill="none" stroke="black"/>
                <path d="M 552,256 L 552,288" fill="none" stroke="black"/>
                <path d="M 32,32 L 552,32" fill="none" stroke="black"/>
                <path d="M 32,64 L 552,64" fill="none" stroke="black"/>
                <path d="M 40,256 L 112,256" fill="none" stroke="black"/>
                <path d="M 184,256 L 256,256" fill="none" stroke="black"/>
                <path d="M 328,256 L 400,256" fill="none" stroke="black"/>
                <path d="M 480,256 L 552,256" fill="none" stroke="black"/>
                <path d="M 40,288 L 112,288" fill="none" stroke="black"/>
                <path d="M 184,288 L 256,288" fill="none" stroke="black"/>
                <path d="M 328,288 L 400,288" fill="none" stroke="black"/>
                <path d="M 480,288 L 552,288" fill="none" stroke="black"/>
                <path d="M 44,344 L 140,344" fill="none" stroke="black"/>
                <path d="M 444,344 L 548,344" fill="none" stroke="black"/>
                <polygon class="arrowhead" points="528,208 516,202.4 516,213.6" fill="black" transform="rotate(90,520,208)"/>
                <polygon class="arrowhead" points="232,208 220,202.4 220,213.6" fill="black" transform="rotate(90,224,208)"/>
                <polygon class="arrowhead" points="88,208 76,202.4 76,213.6" fill="black" transform="rotate(90,80,208)"/>
                <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>
            </artwork>
            <artwork type="ascii-art" align="center" pn="section-6.1-9.1.2">
    .----------------------------------------------------------------.
    |                              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) _____________/
</artwork>
          </artset>
        </figure>
      </section>
      <section anchor="one-to-many-rekeying" numbered="true" removeInRFC="false" toc="include" pn="section-6.2">
        <name slugifiedName="name-one-to-many-group-rekeying">One-to-Many Group Rekeying</name>
        <t indent="0" pn="section-6.2-1">This section provides high-level recommendations on how the KDC can rekey a group by means of a more efficient and scalable group rekeying scheme, e.g., <xref target="RFC2093" format="default" sectionFormat="of" derivedContent="RFC2093"/>, <xref target="RFC2094" format="default" sectionFormat="of" derivedContent="RFC2094"/>, and <xref target="RFC2627" format="default" sectionFormat="of" derivedContent="RFC2627"/>. That is, each rekeying message might be, and likely is, intended for multiple target group members, and thus can be delivered to the whole group, although possible to decrypt only for the actual target group members.</t>
        <t indent="0" pn="section-6.2-2">This yields an overall lower number of rekeying messages, thus potentially reducing the overall time required to rekey the group. On the other hand, it requires the KDC to provide and use additional administrative keying material to protect the rekeying messages and to additionally sign them to ensure source authentication (see <xref target="one-to-many-rekeying-protection" format="default" sectionFormat="of" derivedContent="Section 6.2.1"/>).</t>
        <t indent="0" pn="section-6.2-3">Compared to a group rekeying performed in a point-to-point fashion (see <xref target="point-to-point-rekeying" format="default" sectionFormat="of" derivedContent="Section 6.1"/>), a one-to-many group rekeying typically pays off in large-scale groups due to the reduced time for completing the rekeying, a more efficient utilization of network resources, and a reduced performance overhead at the KDC. To different extents, it also requires individual group members to locally perform additional operations in order to handle the administrative keying material and verify source authentication of rekeying messages. Therefore, one-to-many group rekeying schemes and their employment ought to ensure that the experienced performance overhead on the group members also remains bearable for resource-constrained devices.</t>
        <t indent="0" pn="section-6.2-4">The exact set of rekeying messages to send, their content and format, the administrative keying material to use to protect them, as well as the set of target group members depend on the specific group rekeying scheme and are typically affected by the reason that has triggered the group rekeying. Details about the data content and format of rekeying messages have to be defined by separate documents profiling the use of the group rekeying scheme in the context of the used application profile of this specification.</t>
        <t indent="0" pn="section-6.2-5">When one of these group rekeying schemes is used, the KDC provides related information to a Client joining the group in the Join Response message (see <xref target="gid-post" format="default" sectionFormat="of" derivedContent="Section 4.3.1"/>). In particular, the 'rekeying_scheme' parameter indicates the rekeying scheme used in the group (if no default scheme can be assumed); the 'control_group_uri' parameter, if present, specifies a URI whose addressing information is, e.g., a multicast IP address where the KDC will send the rekeying messages for that group as intended to reach all the group members; and the 'mgt_key_material' parameter specifies a subset of the administrative keying material intended for that particular joining Client to have, as used to protect the rekeying messages sent to the group when also intended for that joining Client.</t>
        <t indent="0" pn="section-6.2-6">Rekeying messages can be protected at the application layer by using COSE <xref target="RFC9052" format="default" sectionFormat="of" derivedContent="RFC9052"/> and the administrative keying material as prescribed by the specific group rekeying scheme (see <xref target="one-to-many-rekeying-protection" format="default" sectionFormat="of" derivedContent="Section 6.2.1"/>). After that, the delivery of protected rekeying messages to the intended target group members can occur in different ways, such as the following ones.</t>
        <dl newline="false" spacing="normal" indent="3" pn="section-6.2-7">
          <dt pn="section-6.2-7.1">Over multicast -</dt>
          <dd pn="section-6.2-7.2">
            <t indent="0" pn="section-6.2-7.2.1">In this case, the KDC simply sends a rekeying message as a CoAP request addressed to the URI specified in the 'control_group_uri' parameter of the Join Response (see <xref target="gid-post" format="default" sectionFormat="of" derivedContent="Section 4.3.1"/>).  </t>
            <t indent="0" pn="section-6.2-7.2.2">
If a particular rekeying message is intended for a single target group member, the KDC may alternatively protect the message using the secure communication association with that group member and deliver the message like when using the "Point-to-Point" group rekeying scheme (see <xref target="point-to-point-rekeying" format="default" sectionFormat="of" derivedContent="Section 6.1"/>).</t>
          </dd>
          <dt pn="section-6.2-7.3">Through a pub-sub communication model -</dt>
          <dd pn="section-6.2-7.4">
            <t indent="0" pn="section-6.2-7.4.1">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.  </t>
            <t indent="0" pn="section-6.2-7.4.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).  </t>
            <t indent="0" pn="section-6.2-7.4.3">
The setup of rekeying topics at the Broker as well as the discovery of the topics at the Broker for group members are application specific. A possible way is for the KDC to provide such information in the Join Response message (see <xref target="gid-post" format="default" sectionFormat="of" derivedContent="Section 4.3.1"/>) by means of a new parameter analogous to 'control_group_uri' and specifying the URI(s) of the rekeying topic(s) that a group member has to subscribe to at the Broker.</t>
          </dd>
        </dl>
        <t indent="0" pn="section-6.2-8">Regardless of the specifically used delivery method, the group rekeying scheme can perform a possible rollover of the administrative keying material through the same sent rekeying messages. Actually, such a rollover occurs every time a group rekeying is performed upon the leaving of group members, which have to be excluded from future communications in the group.</t>
        <t indent="0" pn="section-6.2-9">From a high-level point of view, each group member stores only a subset of the overall administrative keying material, which is obtained upon joining the group. Then, when a group rekeying occurs:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.2-10">
          <li pn="section-6.2-10.1">Each rekeying message is protected by using a (most convenient) key from the administrative keying material such that: i) the used key is not stored by any node leaving the group, i.e., the key is safe to use and does not have to be renewed; and ii) the used key is stored by all the target group members that indeed have to be provided with new group keying material to protect communications in the group.</li>
          <li pn="section-6.2-10.2">Each rekeying message includes not only the new group keying material intended for all the rekeyed group members but also any new administrative keys that: i) are pertaining to and supposed to be stored by the target group members; and ii) had to be updated because leaving group members do store the previous version.</li>
        </ul>
        <t indent="0" pn="section-6.2-11">Further details depend on the specific rekeying scheme used in the group.</t>
        <t indent="0" pn="section-6.2-12"><xref target="fig-rekeying-example-2" format="default" sectionFormat="of" derivedContent="Figure 35"/> provides an example of a one-to-many group rekeying over multicast. In particular, the example makes the following assumptions:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.2-13">
          <li pn="section-6.2-13.1">The group currently consists of four group members, namely C1, C2, C3, and C4.</li>
          <li pn="section-6.2-13.2">Each group member, when joining the group, provided the KDC with a URI in the 'control_uri' parameter with url-path "grp-rek".</li>
          <li pn="section-6.2-13.3">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".</li>
          <li pn="section-6.2-13.4">Before the group rekeying is performed, the keying material used in the group has version number num=5.</li>
          <li pn="section-6.2-13.5">The KDC performs the group rekeying in such a way to evict the group member C3, which has been found to be compromised.</li>
        </ul>
        <t indent="0" pn="section-6.2-14">In the example, the KDC determines that the most convenient way to perform a group rekeying that evicts C3 is as follows.</t>
        <t indent="0" pn="section-6.2-15">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 solid arrows. 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.</t>
        <t indent="0" pn="section-6.2-16">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 arrow. 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.</t>
        <figure anchor="fig-rekeying-example-2" align="left" suppress-title="false" pn="figure-35">
          <name slugifiedName="name-example-of-message-exchanges">Example of Message Exchanges for a One-to-Many Group Rekeying</name>
          <artset pn="section-6.2-17.1">
            <artwork type="svg" align="center" pn="section-6.2-17.1.1"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" viewBox="0 0 700 400" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px">
                <path d="M 8,32 L 8,64" fill="none" stroke="black"/>
                <path d="M 8,288 L 8,320" fill="none" stroke="black"/>
                <path d="M 56,192 L 56,240" fill="none" stroke="black"/>
                <path d="M 80,288 L 80,320" fill="none" stroke="black"/>
                <path d="M 112,288 L 112,320" fill="none" stroke="black"/>
                <path d="M 160,192 L 160,240" fill="none" stroke="black"/>
                <path d="M 184,288 L 184,320" fill="none" stroke="black"/>
                <path d="M 216,288 L 216,320" fill="none" stroke="black"/>
                <path d="M 272,72 L 272,240" fill="none" stroke="black"/>
                <path d="M 312,288 L 312,320" fill="none" stroke="black"/>
                <path d="M 344,288 L 344,320" fill="none" stroke="black"/>
                <path d="M 392,192 L 392,240" fill="none" stroke="black"/>
                <path d="M 568,32 L 568,64" fill="none" stroke="black"/>
                <path d="M 568,288 L 568,320" fill="none" stroke="black"/>
                <path d="M 8,32 L 568,32" fill="none" stroke="black"/>
                <path d="M 8,64 L 568,64" fill="none" stroke="black"/>
                <path d="M 56,192 L 392,192" fill="none" stroke="black"/>
                <path d="M 8,288 L 80,288" fill="none" stroke="black"/>
                <path d="M 112,288 L 184,288" fill="none" stroke="black"/>
                <path d="M 216,288 L 312,288" fill="none" stroke="black"/>
                <path d="M 344,288 L 568,288" fill="none" stroke="black"/>
                <path d="M 8,320 L 80,320" fill="none" stroke="black"/>
                <path d="M 112,320 L 184,320" fill="none" stroke="black"/>
                <path d="M 216,320 L 312,320" fill="none" stroke="black"/>
                <path d="M 344,320 L 568,320" fill="none" stroke="black"/>
                <path d="M 12,376 L 132,376" fill="none" stroke="black"/>
                <path d="M 436,376 L 564,376" fill="none" stroke="black"/>
                <polygon class="arrowhead" points="400,240 388,234.4 388,245.6" fill="black" transform="rotate(90,392,240)"/>
                <polygon class="arrowhead" points="280,240 268,234.4 268,245.6" fill="black" transform="rotate(90,272,240)"/>
                <polygon class="arrowhead" points="168,240 156,234.4 156,245.6" fill="black" transform="rotate(90,160,240)"/>
                <polygon class="arrowhead" points="64,240 52,234.4 52,245.6" fill="black" transform="rotate(90,56,240)"/>
                <circle cx="8" cy="96" r="6" class="closeddot" fill="black"/>
                <circle cx="8" cy="112" r="6" class="closeddot" fill="black"/>
                <circle cx="336" cy="96" r="6" class="closeddot" fill="black"/>
                <circle cx="336" cy="128" r="6" class="closeddot" fill="black"/>
                <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>
            </artwork>
            <artwork type="ascii-art" align="center" pn="section-6.2-17.1.2">
.---------------------------------------------------------------------.
|                               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) ________________/
</artwork>
          </artset>
        </figure>
        <section anchor="one-to-many-rekeying-protection" numbered="true" removeInRFC="false" toc="include" pn="section-6.2.1">
          <name slugifiedName="name-protection-of-rekeying-mess">Protection of Rekeying Messages</name>
          <t indent="0" pn="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.</t>
          <t indent="0" pn="section-6.2.1-2">The following describes one possible method for the KDC to protect the rekeying messages when using the administrative keying material.</t>
          <t indent="0" pn="section-6.2.1-3">The method assumes that the following holds for the administrative keying material specified in the 'mgt_key_material' parameter of the Join Response (see <xref target="gid-post" format="default" sectionFormat="of" derivedContent="Section 4.3.1"/>).</t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.2.1-4">
            <li pn="section-6.2.1-4.1">The encryption algorithm <bcp14>SHOULD</bcp14> be the same one used to protect communications in the group.</li>
            <li pn="section-6.2.1-4.2">The included symmetric encryption keys are accompanied by a corresponding and unique key identifier assigned by the KDC.</li>
            <li pn="section-6.2.1-4.3">A Base IV is also included with the same size of the AEAD nonce considered by the encryption algorithm to use.</li>
          </ul>
          <t indent="0" pn="section-6.2.1-5">First, the KDC computes a COSE_Encrypt0 object as follows.</t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.2.1-6">
            <li pn="section-6.2.1-6.1">The encryption key to use is selected from the administrative keying material, as defined by the rekeying scheme used in the group.</li>
            <li pn="section-6.2.1-6.2">The plaintext is the actual data content of the current rekeying message.</li>
            <li pn="section-6.2.1-6.3">The Additional Authenticated Data (AAD) is empty unless otherwise specified by separate documents profiling the use of the group rekeying scheme.</li>
            <li pn="section-6.2.1-6.4">
              <t indent="0" pn="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.  </t>
              <t indent="0" pn="section-6.2.1-6.4.2">
The KDC considers the following values.  </t>
              <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.2.1-6.4.3">
                <li pn="section-6.2.1-6.4.3.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.</li>
                <li pn="section-6.2.1-6.4.3.2">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.</li>
              </ul>
              <t indent="0" pn="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.  </t>
              <t indent="0" pn="section-6.2.1-6.4.5">
In order to comply with the security requirements of AEAD encryption algorithms, the KDC <bcp14>MUST NOT</bcp14> reuse 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<sup>16</sup> times during the same rekeying instance.</t>
            </li>
            <li pn="section-6.2.1-6.5">
              <t indent="0" pn="section-6.2.1-6.5.1">The protected header of the COSE_Encrypt0 object <bcp14>MUST</bcp14> include the following parameters.  </t>
              <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.2.1-6.5.2">
                <li pn="section-6.2.1-6.5.2.1">'alg': specifying the used encryption algorithm.</li>
                <li pn="section-6.2.1-6.5.2.2">'kid': specifying the identifier of the encryption key from the administrative keying material used to protect the current rekeying message.</li>
              </ul>
            </li>
            <li pn="section-6.2.1-6.6">The unprotected header of the COSE_Encrypt0 object <bcp14>MUST</bcp14> include the 'Partial IV' parameter with the value of the Partial IV computed above.</li>
          </ul>
          <t indent="0" pn="section-6.2.1-7">In order to ensure source authentication, each rekeying message protected with the administrative keying material <bcp14>MUST</bcp14> be signed by the KDC. To this end, the KDC computes a countersignature of the COSE_Encrypt0 object, as described in Sections <xref target="RFC9338" section="3.2" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9338#section-3.2" derivedContent="RFC9338"/> and <xref target="RFC9338" section="3.3" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9338#section-3.3" derivedContent="RFC9338"/> of <xref target="RFC9338" format="default" sectionFormat="of" derivedContent="RFC9338"/>. In particular, the following applies when computing the countersignature.</t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.2.1-8">
            <li pn="section-6.2.1-8.1">The Countersign_structure contains the context text string "CounterSignature0".</li>
            <li pn="section-6.2.1-8.2">The private key of the KDC is used as the signing key.</li>
            <li pn="section-6.2.1-8.3">The payload is the ciphertext of the COSE_Encrypt0 object.</li>
            <li pn="section-6.2.1-8.4">The Additional Authenticated Data (AAD) is empty, unless otherwise specified by separate documents profiling the use of a group rekeying scheme.</li>
            <li pn="section-6.2.1-8.5">The protected header of the signing object <bcp14>MUST</bcp14> include the parameter 'alg', which specifies the used signature algorithm.</li>
          </ul>
          <t indent="0" pn="section-6.2.1-9">If the source authentication of messages exchanged in the group is also ensured by means of signatures, then rekeying messages <bcp14>MUST</bcp14> 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 <bcp14>MUST</bcp14> 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.</t>
          <t indent="0" pn="section-6.2.1-10">If source authentication of messages exchanged in the group is not ensured by means of signatures, then the administrative keying material conveyed in the 'mgt_key_material' parameter of the Join Response sent by KDC (see <xref target="gid-post" format="default" sectionFormat="of" derivedContent="Section 4.3.1"/>) <bcp14>MUST</bcp14> also comprise a KDC's authentication credential including the public key to use for signature verification, together with the corresponding PoP evidence. Within the 'mgt_key_material' parameter, it is <bcp14>RECOMMENDED</bcp14> 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.</t>
          <t indent="0" pn="section-6.2.1-11">After that, the KDC specifies the computed countersignature in the 'Countersignature0 version 2' header parameter of the COSE_Encrypt0 object.</t>
          <t indent="0" pn="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.</t>
        </section>
      </section>
      <section anchor="sec-misalignment-keying-material" numbered="true" removeInRFC="false" toc="include" pn="section-6.3">
        <name slugifiedName="name-misalignment-of-group-keyin">Misalignment of Group Keying Material</name>
        <t indent="0" pn="section-6.3-1">A group member can receive a message shortly after the group has been rekeyed and new keying material has been distributed by the KDC. In the following two cases, this may result in misaligned keying material between the group members.</t>
        <t indent="0" pn="section-6.3-2">In the first case, the sender protects a message using the old group keying material. However, the recipient receives the message after having received the new group keying material, hence it is not able to correctly process the message. A possible way to limit the impact of this issue is to preserve the old, retained group keying material for a maximum amount of time defined by the application, during which such group keying material is used solely for processing incoming messages. By doing so, the recipient can still temporarily process received messages also by using the old, retained group keying material. Note that a former (compromised) group member can take advantage of this by sending messages protected with the old, retained group keying material. Therefore, a conservative application policy should not admit the storage of old group keying material. Eventually, the sender will have obtained the new group keying material too and can possibly resend the message protected with such keying material.</t>
        <t indent="0" pn="section-6.3-3">In the second case, the sender protects a message using the new group keying material, but the recipient receives that message before having received the new group keying material. Therefore, the recipient will not be able to correctly process the message and hence will discard it. If the recipient receives the new group keying material shortly after that and the application at the sender endpoint performs retransmissions, the former will still be able to receive and correctly process the message. In any case, the recipient should actively ask the KDC for the latest group keying material according to an application-defined policy, for instance, after a given number of unsuccessfully decrypted incoming messages.</t>
      </section>
    </section>
    <section anchor="sec-extended-scope" numbered="true" removeInRFC="false" toc="include" pn="section-7">
      <name slugifiedName="name-extended-scope-format">Extended Scope Format</name>
      <t indent="0" pn="section-7-1">This section defines an extended format of binary-encoded scope, which additionally specifies the semantics used to express the same access control information from the corresponding original scope.</t>
      <t indent="0" pn="section-7-2">As also discussed in <xref target="ssec-authorization-response" format="default" sectionFormat="of" derivedContent="Section 3.2"/>, this enables a Resource Server to unambiguously process a received access token, also in case the Resource Server runs multiple applications or application profiles that involve different scope semantics.</t>
      <t indent="0" pn="section-7-3">The extended format is intended only for the 'scope' claim of access tokens for the cases where the claim takes a CBOR byte string as the value. 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 <xref target="RFC9200" section="5.8.1" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9200#section-5.8.1" derivedContent="RFC9200"/> and <xref target="RFC9200" section="5.8.2" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9200#section-5.8.2" derivedContent="RFC9200"/> of <xref target="RFC9200" format="default" sectionFormat="of" derivedContent="RFC9200"/>), the AS Request Creation Hints message from the Resource Server (see <xref section="5.3" sectionFormat="of" target="RFC9200" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9200#section-5.3" derivedContent="RFC9200"/>), and the Introspection Response from the Authorization Server (see <xref section="5.9.2" sectionFormat="of" target="RFC9200" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9200#section-5.9.2" derivedContent="RFC9200"/>).</t>
      <t indent="0" pn="section-7-4">The value of the 'scope' claim following the extended format is composed as follows. Given the original scope using 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 <xref target="RFC8949" format="default" sectionFormat="of" derivedContent="RFC8949"/>, whose tag number identifies the semantics SEM.</t>
      <t indent="0" pn="section-7-5">The resulting tagged CBOR byte string is used as the value of the 'scope' claim of the access token.</t>
      <t indent="0" pn="section-7-6">Figures <xref target="cddl-ex-0-ext" format="counter" sectionFormat="of" derivedContent="36"/> and <xref target="cddl-ex-ext" format="counter" sectionFormat="of" derivedContent="37"/> build on the examples in <xref target="ssec-authorization-request" format="default" sectionFormat="of" derivedContent="Section 3.1"/> and show the corresponding extended scopes.</t>
      <figure anchor="cddl-ex-0-ext" align="left" suppress-title="false" pn="figure-36">
        <name slugifiedName="name-example-of-extended-scope-u">Example of Extended scope Using AIF</name>
        <sourcecode type="cddl" markers="false" pn="section-7-7.1">
;# include rfc9237

gname = tstr

permissions = uint .bits roles

roles = &amp;(
   Requester: 1,
   Responder: 2,
   Monitor: 3,
   Verifier: 4
)

scope_entries = AIF-Generic&lt;gname, permissions&gt;

scope = bstr .cbor scope_entries

extended_scope = #6.&lt;TAG_FOR_THIS_SEMANTICS&gt;(scope)

TAG_FOR_THIS_SEMANTICS = uint
</sourcecode>
      </figure>
      <figure anchor="cddl-ex-ext" align="left" suppress-title="false" pn="figure-37">
        <name slugifiedName="name-example-of-extended-scope-us">Example of Extended scope Using the Textual Format, with the Role Identifiers Encoded as Text Strings</name>
        <sourcecode type="cddl" markers="false" pn="section-7-8.1">
gname = tstr

role = tstr

scope_entry = [ gname , ? ( role / [ 2*role ] ) ]

scope_entries = [ * scope_entry ]

scope = bstr .cbor scope_entries

extended_scope = #6.&lt;TAG_FOR_THIS_SEMANTICS&gt;(scope)

TAG_FOR_THIS_SEMANTICS = uint
</sourcecode>
      </figure>
      <t indent="0" pn="section-7-9">The usage of the extended scope format is not limited to application profiles of this specification or to applications based on group communication. Rather, it is generally applicable to any application and application profile where access control information in the access token is expressed as a binary-encoded scope.</t>
      <t indent="0" pn="section-7-10">Applications and application profiles using the extended format of scope have to specify which CBOR tag from <xref target="CBOR.Tags" format="default" sectionFormat="of" derivedContent="CBOR.Tags"/> is used for identifying the scope semantics or to register a new CBOR tag if a suitable one does not exist already (<xref target="req28" format="none" sectionFormat="of" derivedContent="">REQ28</xref>). In case there is an already existing, suitable CBOR tag, a new CBOR tag should not be registered in order to avoid code point squatting.</t>
      <t indent="0" pn="section-7-11">If the binary-encoded scope uses semantics associated with a registered CoAP Content-Format <xref target="RFC7252" format="default" sectionFormat="of" derivedContent="RFC7252"/> <xref target="CoAP.Content.Formats" format="default" sectionFormat="of" derivedContent="CoAP.Content.Formats"/>, then a suitable CBOR tag associated with that CoAP Content-Format would already be registered, as defined in <xref section="4.3" sectionFormat="of" target="RFC9277" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9277#section-4.3" derivedContent="RFC9277"/>.</t>
      <t indent="0" pn="section-7-12">This is especially relevant when the binary encoded scope uses AIF. That is, it is expected that the definition of an AIF-specific data model comes together with the registration of CoAP Content-Formats for the relevant combinations of its Toid and Tperm values. As discussed above, this yields the automatic registration of the CBOR tags associated with those CoAP Content-Formats.</t>
    </section>
    <section anchor="params" numbered="true" removeInRFC="false" toc="include" pn="section-8">
      <name slugifiedName="name-ace-groupcomm-parameters">ACE Groupcomm Parameters</name>
      <t indent="0" pn="section-8-1">This specification defines a number of parameters used during the second phase of the key provisioning process, i.e., after the exchange after the exchange of Token Transfer Request and Response. The table below summarizes them and specifies the CBOR map keys to use instead of the full descriptive names.</t>
      <t indent="0" pn="section-8-2">Note that the media type "application/ace-groupcomm+cbor" <bcp14>MUST</bcp14> be used when these parameters are transported in the respective CBOR map entries.</t>
      <table anchor="fig-ACE-Groupcomm-Parameters" align="center" pn="table-5">
        <name slugifiedName="name-ace-groupcomm-parameters-2">ACE Groupcomm Parameters</name>
        <thead>
          <tr>
            <th align="left" colspan="1" rowspan="1">Name</th>
            <th align="left" colspan="1" rowspan="1">CBOR Key</th>
            <th align="left" colspan="1" rowspan="1">CBOR Type</th>
            <th align="left" colspan="1" rowspan="1">Reference</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left" colspan="1" rowspan="1">gid</td>
            <td align="left" colspan="1" rowspan="1">0</td>
            <td align="left" colspan="1" rowspan="1">array</td>
            <td align="left" colspan="1" rowspan="1">RFC 9594</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">gname</td>
            <td align="left" colspan="1" rowspan="1">1</td>
            <td align="left" colspan="1" rowspan="1">array of tstr</td>
            <td align="left" colspan="1" rowspan="1">RFC 9594</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">guri</td>
            <td align="left" colspan="1" rowspan="1">2</td>
            <td align="left" colspan="1" rowspan="1">array of tstr</td>
            <td align="left" colspan="1" rowspan="1">RFC 9594</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">scope</td>
            <td align="left" colspan="1" rowspan="1">3</td>
            <td align="left" colspan="1" rowspan="1">bstr</td>
            <td align="left" colspan="1" rowspan="1">RFC 9594</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">get_creds</td>
            <td align="left" colspan="1" rowspan="1">4</td>
            <td align="left" colspan="1" rowspan="1">Null or array</td>
            <td align="left" colspan="1" rowspan="1">RFC 9594</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">client_cred</td>
            <td align="left" colspan="1" rowspan="1">5</td>
            <td align="left" colspan="1" rowspan="1">bstr</td>
            <td align="left" colspan="1" rowspan="1">RFC 9594</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">cnonce</td>
            <td align="left" colspan="1" rowspan="1">6</td>
            <td align="left" colspan="1" rowspan="1">bstr</td>
            <td align="left" colspan="1" rowspan="1">RFC 9594</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">gkty</td>
            <td align="left" colspan="1" rowspan="1">7</td>
            <td align="left" colspan="1" rowspan="1">int or tstr</td>
            <td align="left" colspan="1" rowspan="1">RFC 9594</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">key</td>
            <td align="left" colspan="1" rowspan="1">8</td>
            <td align="left" colspan="1" rowspan="1">See the "ACE Groupcomm Key Types" registry</td>
            <td align="left" colspan="1" rowspan="1">RFC 9594</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">num</td>
            <td align="left" colspan="1" rowspan="1">9</td>
            <td align="left" colspan="1" rowspan="1">int</td>
            <td align="left" colspan="1" rowspan="1">RFC 9594</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">ace_groupcomm_profile</td>
            <td align="left" colspan="1" rowspan="1">10</td>
            <td align="left" colspan="1" rowspan="1">int</td>
            <td align="left" colspan="1" rowspan="1">RFC 9594</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">exp</td>
            <td align="left" colspan="1" rowspan="1">11</td>
            <td align="left" colspan="1" rowspan="1">uint</td>
            <td align="left" colspan="1" rowspan="1">RFC 9594</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">exi</td>
            <td align="left" colspan="1" rowspan="1">12</td>
            <td align="left" colspan="1" rowspan="1">uint</td>
            <td align="left" colspan="1" rowspan="1">RFC 9594</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">creds</td>
            <td align="left" colspan="1" rowspan="1">13</td>
            <td align="left" colspan="1" rowspan="1">array</td>
            <td align="left" colspan="1" rowspan="1">RFC 9594</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">peer_roles</td>
            <td align="left" colspan="1" rowspan="1">14</td>
            <td align="left" colspan="1" rowspan="1">array</td>
            <td align="left" colspan="1" rowspan="1">RFC 9594</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">peer_identifiers</td>
            <td align="left" colspan="1" rowspan="1">15</td>
            <td align="left" colspan="1" rowspan="1">array</td>
            <td align="left" colspan="1" rowspan="1">RFC 9594</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">group_policies</td>
            <td align="left" colspan="1" rowspan="1">16</td>
            <td align="left" colspan="1" rowspan="1">map</td>
            <td align="left" colspan="1" rowspan="1">RFC 9594</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">kdc_cred</td>
            <td align="left" colspan="1" rowspan="1">17</td>
            <td align="left" colspan="1" rowspan="1">bstr</td>
            <td align="left" colspan="1" rowspan="1">RFC 9594</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">kdc_nonce</td>
            <td align="left" colspan="1" rowspan="1">18</td>
            <td align="left" colspan="1" rowspan="1">bstr</td>
            <td align="left" colspan="1" rowspan="1">RFC 9594</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">kdc_cred_verify</td>
            <td align="left" colspan="1" rowspan="1">19</td>
            <td align="left" colspan="1" rowspan="1">bstr</td>
            <td align="left" colspan="1" rowspan="1">RFC 9594</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">rekeying_scheme</td>
            <td align="left" colspan="1" rowspan="1">20</td>
            <td align="left" colspan="1" rowspan="1">int</td>
            <td align="left" colspan="1" rowspan="1">RFC 9594</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">client_cred_verify</td>
            <td align="left" colspan="1" rowspan="1">24</td>
            <td align="left" colspan="1" rowspan="1">bstr</td>
            <td align="left" colspan="1" rowspan="1">RFC 9594</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">creds_repo</td>
            <td align="left" colspan="1" rowspan="1">25</td>
            <td align="left" colspan="1" rowspan="1">tstr</td>
            <td align="left" colspan="1" rowspan="1">RFC 9594</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">control_uri</td>
            <td align="left" colspan="1" rowspan="1">26</td>
            <td align="left" colspan="1" rowspan="1">tstr</td>
            <td align="left" colspan="1" rowspan="1">RFC 9594</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">mgt_key_material</td>
            <td align="left" colspan="1" rowspan="1">27</td>
            <td align="left" colspan="1" rowspan="1">bstr</td>
            <td align="left" colspan="1" rowspan="1">RFC 9594</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">control_group_uri</td>
            <td align="left" colspan="1" rowspan="1">28</td>
            <td align="left" colspan="1" rowspan="1">tstr</td>
            <td align="left" colspan="1" rowspan="1">RFC 9594</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">sign_info</td>
            <td align="left" colspan="1" rowspan="1">29</td>
            <td align="left" colspan="1" rowspan="1">Null or array</td>
            <td align="left" colspan="1" rowspan="1">RFC 9594 </td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">kdcchallenge</td>
            <td align="left" colspan="1" rowspan="1">30</td>
            <td align="left" colspan="1" rowspan="1">bstr</td>
            <td align="left" colspan="1" rowspan="1">RFC 9594</td>
          </tr>
        </tbody>
      </table>
      <t indent="0" pn="section-8-4">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.</t>
      <t indent="0" pn="section-8-5">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 <bcp14>REQUIRED</bcp14> of application profiles of this specification to sort their newly defined parameters according to the same categorization (<xref target="req29" format="none" sectionFormat="of" derivedContent="">REQ29</xref>).</t>
      <t indent="0" pn="section-8-6">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.</t>
      <t indent="0" pn="section-8-7">A Client <bcp14>MUST</bcp14> support the following parameters.</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-8-8">
        <li pn="section-8-8.1">'scope'</li>
        <li pn="section-8-8.2">'cnonce'</li>
        <li pn="section-8-8.3">'gkty'</li>
        <li pn="section-8-8.4">'key'</li>
        <li pn="section-8-8.5">'num'</li>
        <li pn="section-8-8.6">'exp'</li>
        <li pn="section-8-8.7">'exi'</li>
        <li pn="section-8-8.8">'gid'</li>
        <li pn="section-8-8.9">'gname'</li>
        <li pn="section-8-8.10">'guri'</li>
        <li pn="section-8-8.11">'creds'</li>
        <li pn="section-8-8.12">'peer_identifiers'</li>
        <li pn="section-8-8.13">'ace_groupcomm_profile'</li>
        <li pn="section-8-8.14">'control_uri'</li>
        <li pn="section-8-8.15">'rekeying_scheme'</li>
      </ul>
      <t indent="0" pn="section-8-9">A Client <bcp14>SHOULD</bcp14> support the following parameter.</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-8-10">
        <li pn="section-8-10.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 <xref target="ssec-key-distribution-exchange" format="default" sectionFormat="of" derivedContent="Section 4.3.1.1"/>); and ii) later on as a group member, the Client only retrieves the authentication credentials of all group members (see <xref target="sec-key-retrieval-all" format="default" sectionFormat="of" derivedContent="Section 4.4.2.1"/>).</li>
      </ul>
      <t indent="0" pn="section-8-11">The following conditional parameters are relevant only if specific conditions hold. It is <bcp14>REQUIRED</bcp14> of application profiles of this specification to define whether Clients must, should, or may support these parameters and under which circumstances (<xref target="req30" format="none" sectionFormat="of" derivedContent="">REQ30</xref>).</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-8-12">
        <li pn="section-8-12.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.</li>
        <li pn="section-8-12.2">'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 <xref target="token-post" format="default" sectionFormat="of" derivedContent="Section 3.3"/>).</li>
        <li pn="section-8-12.3">'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.</li>
        <li pn="section-8-12.4">'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.</li>
        <li pn="section-8-12.5">'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.</li>
        <li pn="section-8-12.6">'kdc_nonce', 'kdc_cred', and '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.</li>
        <li pn="section-8-12.7">'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.</li>
        <li pn="section-8-12.8">'control_group_uri': This parameter is relevant for a Client that also acts as a CoAP server supporting: i) the hosting of a dedicated resource for each group that the Client is interested to be a part of; and ii) the reception of one-to-many requests sent to those resources by the KDC (e.g., over IP multicast), as 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.</li>
      </ul>
    </section>
    <section anchor="error-types" numbered="true" removeInRFC="false" toc="include" pn="section-9">
      <name slugifiedName="name-ace-groupcomm-error-identif">ACE Groupcomm Error Identifiers</name>
      <t indent="0" pn="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 <xref target="kdc-if-errors" format="default" sectionFormat="of" derivedContent="Section 4.1.2"/>).</t>
      <table anchor="fig-ACE-Groupcomm-Error-Identifiers" align="center" pn="table-6">
        <name slugifiedName="name-ace-groupcomm-error-identifi">ACE Groupcomm Error Identifiers</name>
        <thead>
          <tr>
            <th align="left" colspan="1" rowspan="1">Value</th>
            <th align="left" colspan="1" rowspan="1">Description</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left" colspan="1" rowspan="1">0</td>
            <td align="left" colspan="1" rowspan="1">Operation permitted only to group members</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">1</td>
            <td align="left" colspan="1" rowspan="1">Request inconsistent with the current roles</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">2</td>
            <td align="left" colspan="1" rowspan="1">Authentication credential incompatible with the group configuration</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">3</td>
            <td align="left" colspan="1" rowspan="1">Invalid proof-of-possession evidence</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">4</td>
            <td align="left" colspan="1" rowspan="1">No available individual keying material</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">5</td>
            <td align="left" colspan="1" rowspan="1">Group membership terminated</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">6</td>
            <td align="left" colspan="1" rowspan="1">Group deleted</td>
          </tr>
        </tbody>
      </table>
      <t indent="0" pn="section-9-3">If a Client supports the problem-details format <xref target="RFC9290" format="default" sectionFormat="of" derivedContent="RFC9290"/> and the Custom Problem Detail entry 'ace-groupcomm-error' defined in <xref target="kdc-if-errors" format="default" sectionFormat="of" derivedContent="Section 4.1.2"/> of this document and is able to understand the error specified in the 'error-id' field therein, then the Client can 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.</t>
      <t indent="0" pn="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.</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-9-5">
        <li pn="section-9-5.1">In case of error 0, the Client should stop sending the request in question to the KDC. Rather, the Client should first join the targeted group. If it has not happened already, this first requires the Client to obtain an appropriate access token authorizing access to the group and provide it to the KDC.</li>
        <li pn="section-9-5.2">In case of error 1, the Client as a group member should rejoin the group with all the roles needed to perform the operation in question. This might require the Client to first obtain a new access token and provide it to the KDC, if the current access token does not authorize the Client to take those roles in the group. For operations admitted to a Client that is not a group member (e.g., an external signature verifier), the Client should first obtain a new access token authorizing to also have the missing roles.</li>
        <li pn="section-9-5.3">In case of error 2, the Client has to obtain or self-generate a different asymmetric key pair, as aligned to the public key algorithm and parameters used in the targeted group. After that, the Client should provide the KDC with its new authentication credential, which is consistent with the format used in the targeted group and including the new public key.</li>
        <li pn="section-9-5.4">In case of error 3, the Client should ensure to compute its proof-of-possession evidence by correctly using the parameters and procedures defined in the used application profile of this specification. In an unattended setup, it might not be possible for a Client to autonomously diagnose the error and take an effective next action to address it.</li>
        <li pn="section-9-5.5">In case of error 4, the Client should wait for a certain (pre-configured) amount of time before trying to resend its request to the KDC.</li>
        <li pn="section-9-5.6">In case of error 5, the Client may try joining the group again. This might require the Client to first obtain a new access token and provide it to the KDC, e.g., if the current access token has expired.</li>
        <li pn="section-9-5.7">In case of error 6, the Client should clean up its state regarding the group, just like if it has left the group with no intention to rejoin it.</li>
      </ul>
    </section>
    <section anchor="sec-cons" numbered="true" removeInRFC="false" toc="include" pn="section-10">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-10-1">Security considerations are inherited from the ACE framework <xref target="RFC9200" format="default" sectionFormat="of" derivedContent="RFC9200"/> and from the specific transport profile of ACE used between the Clients and the KDC, e.g., <xref target="RFC9202" format="default" sectionFormat="of" derivedContent="RFC9202"/> and <xref target="RFC9203" format="default" sectionFormat="of" derivedContent="RFC9203"/>.</t>
      <t indent="0" pn="section-10-2">When using the problem-details format defined in <xref target="RFC9290" format="default" sectionFormat="of" derivedContent="RFC9290"/> for error responses, then the privacy and security considerations from Sections <xref target="RFC9290" section="4" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9290#section-4" derivedContent="RFC9290"/> and <xref target="RFC9290" section="5" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9290#section-5" derivedContent="RFC9290"/> of <xref target="RFC9290" format="default" sectionFormat="of" derivedContent="RFC9290"/> also apply.</t>
      <t indent="0" pn="section-10-3">Furthermore, the following security considerations apply.</t>
      <section anchor="sec-cons-communication" numbered="true" removeInRFC="false" toc="include" pn="section-10.1">
        <name slugifiedName="name-secure-communication-in-the">Secure Communication in the Group</name>
        <t indent="0" pn="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., as described in <xref section="B.1.2" sectionFormat="of" target="RFC8613" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8613#appendix-B.1.2" derivedContent="RFC8613"/> or <xref section="10" sectionFormat="of" target="I-D.ietf-core-oscore-groupcomm" format="default" derivedLink="https://datatracker.ietf.org/doc/html/draft-ietf-core-oscore-groupcomm-22#section-10" derivedContent="GROUP-OSCORE"/>. Such a mechanism also aids the recipient group member in case it has rebooted and lost the security state used to protect previous group communications with that sender.</t>
        <t indent="0" pn="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.</t>
        <t indent="0" pn="section-10.1-3">A compromised KDC would thus put the attacker in the same position, which also means that:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-10.1-4">
          <li pn="section-10.1-4.1">The attacker can generate and control new group keying material, hence possibly rekeying the group and evicting certain group members as part of a broader attack.</li>
          <li pn="section-10.1-4.2">The attacker can actively participate in communications in a group, even without having been authorized to join it, and can allow further unauthorized entities to do so.</li>
          <li pn="section-10.1-4.3">The attacker can build erroneous associations between node identifiers and group members' authentication credentials.</li>
        </ul>
        <t indent="0" pn="section-10.1-5">On the other hand, as long as the security protocol used in the group ensures source authentication of messages (e.g., by means of signatures), the KDC is not able to impersonate group members since it does not have their private keys.</t>
        <t indent="0" pn="section-10.1-6">Further security considerations are specific to the communication and security protocols used in the group, and thus have to be provided by those protocols and complemented by the application profiles of this specification using them.</t>
      </section>
      <section anchor="sec-cons-rekeying" numbered="true" removeInRFC="false" toc="include" pn="section-10.2">
        <name slugifiedName="name-update-of-group-keying-mate">Update of Group Keying Material</name>
        <t indent="0" pn="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 <xref target="sec-group-rekeying" format="default" sectionFormat="of" derivedContent="Section 6"/>.</t>
        <t indent="0" pn="section-10.2-2">In particular, the KDC must renew the latest group keying material upon its expiration. Before then, the KDC <bcp14>MAY</bcp14> also renew the group keying material on a regular or periodical fashion.</t>
        <t indent="0" pn="section-10.2-3">Unless otherwise defined by an application profile of this specification, the KDC <bcp14>SHOULD</bcp14> 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 takes into account the expected rate of group membership changes and the duration of a group rekeying.</t>
        <t indent="0" pn="section-10.2-4">Since the minimum number of group members is one, the KDC <bcp14>SHOULD</bcp14> provide even a Client joining an empty group with new keying material never used before in that group. Similarly, the KDC <bcp14>SHOULD</bcp14> also provide new group keying material to a Client that remains the only member in the group after the leaving of other group members.</t>
        <t indent="0" pn="section-10.2-5">Note that the considerations in <xref target="sec-cons-communication" format="default" sectionFormat="of" derivedContent="Section 10.1"/> 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.</t>
        <t indent="0" pn="section-10.2-6">Once a joining node has obtained the new, latest keying material through a Join Response from the KDC (see <xref target="ssec-key-distribution-exchange" format="default" sectionFormat="of" derivedContent="Section 4.3.1.1"/>), 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.</t>
        <t indent="0" pn="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 occurring before the message reception.</t>
        <t indent="0" pn="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, after a maximum amount of time since the last group rekeying was completed, or yet during predictable network inactivity periods.</t>
        <t indent="0" pn="section-10.2-9">However, this would result in the KDC not constantly preserving backward and forward security in the group. That is:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-10.2-10">
          <li pn="section-10.2-10.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.</li>
          <li pn="section-10.2-10.2">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 impact or compromise the security properties of the protocols used in the group to protect messages exchanged among the group members.</li>
        </ul>
        <t indent="0" pn="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 communication associations with the current group members as well as any administrative keying material required to rekey the group are also stored in persistent storage.</t>
        <t indent="0" pn="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 rely on each group member asking for the new group keying material (see Sections <xref target="ssec-key-material-retrieval" format="counter" sectionFormat="of" derivedContent="4.3.2.1"/> and <xref target="update-keys" format="counter" sectionFormat="of" derivedContent="4.8.1.1"/>) or perform a group rekeying by actively sending rekeying messages to group members as discussed in <xref target="sec-group-rekeying" format="default" sectionFormat="of" derivedContent="Section 6"/>.</t>
        <t indent="0" pn="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 rejoining the group at high rates or often asking the KDC for new individual keying material. Ultimately, the KDC can resort to removing these nodes from the group and (temporarily) preventing them from joining the group again.</t>
        <t indent="0" pn="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 <xref section="4.7" sectionFormat="of" target="RFC7252" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7252#section-4.7" derivedContent="RFC7252"/> and <xref section="4.5.1" sectionFormat="of" target="RFC7641" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7641#section-4.5.1" derivedContent="RFC7641"/>.</t>
      </section>
      <section anchor="block-wise-considerations" numbered="true" removeInRFC="false" toc="include" pn="section-10.3">
        <name slugifiedName="name-block-wise-considerations">Block-Wise Considerations</name>
        <t indent="0" pn="section-10.3-1">If the Block-Wise CoAP options <xref target="RFC7959" format="default" sectionFormat="of" derivedContent="RFC7959"/> are used and the keying material is updated in the middle of a Block-Wise transfer, the sender of the blocks just changes the group keying material to the updated one and continues the transfer. As long as both sides get the new group keying material, updating the group keying material in the middle of a transfer will not cause any issue. Otherwise, the sender will have to transmit the message again when receiving an error message from the recipient.</t>
        <t indent="0" pn="section-10.3-2">Compared to a scenario where the transfer does not use Block-Wise, and depending on how fast the group keying material is changed, the group members might consume a larger amount of the network bandwidth by repeatedly resending the same blocks, which might be problematic.</t>
      </section>
    </section>
    <section anchor="iana-considerations" numbered="true" removeInRFC="false" toc="include" pn="section-11">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-11-1">Per this document, IANA has completed the following actions.</t>
      <section anchor="media-type" numbered="true" removeInRFC="false" toc="include" pn="section-11.1">
        <name slugifiedName="name-media-type-registrations">Media Type Registrations</name>
        <t indent="0" pn="section-11.1-1">This specification has registered the "application/ace-groupcomm+cbor" media type for messages of the protocols defined in this document following the ACE exchange and carrying parameters encoded in CBOR. This registration follows the procedures specified in <xref target="RFC6838" format="default" sectionFormat="of" derivedContent="RFC6838"/>.</t>
        <dl newline="false" indent="3" spacing="normal" pn="section-11.1-2">
          <dt pn="section-11.1-2.1">Type name:</dt>
          <dd pn="section-11.1-2.2">application</dd>
          <dt pn="section-11.1-2.3">Subtype name:</dt>
          <dd pn="section-11.1-2.4"> ace-groupcomm+cbor</dd>
          <dt pn="section-11.1-2.5">Required parameters:</dt>
          <dd pn="section-11.1-2.6"> N/A</dd>
          <dt pn="section-11.1-2.7">Optional parameters:</dt>
          <dd pn="section-11.1-2.8"> N/A</dd>
          <dt pn="section-11.1-2.9">Encoding considerations:</dt>
          <dd pn="section-11.1-2.10"> Must be encoded as a CBOR map containing the parameters defined in RFC 9594.</dd>
          <dt pn="section-11.1-2.11">Security considerations:</dt>
          <dd pn="section-11.1-2.12"> See <xref target="sec-cons" format="default" sectionFormat="of" derivedContent="Section 10"/> of RFC 9594.</dd>
          <dt pn="section-11.1-2.13">Interoperability considerations:</dt>
          <dd pn="section-11.1-2.14"> N/A</dd>
          <dt pn="section-11.1-2.15">Published specification:</dt>
          <dd pn="section-11.1-2.16"> RFC 9594</dd>
          <dt pn="section-11.1-2.17">Applications that use this media type:</dt>
          <dd pn="section-11.1-2.18"> The type is used by Authorization Servers, Clients, and Resource Servers that support the ACE groupcomm framework as specified in RFC 9594.</dd>
          <dt pn="section-11.1-2.19">Fragment identifier considerations:</dt>
          <dd pn="section-11.1-2.20"> N/A</dd>
          <dt pn="section-11.1-2.21">Additional information:</dt>
          <dd pn="section-11.1-2.22"> N/A</dd>
          <dt pn="section-11.1-2.23">Person &amp; email address to contact for further information:</dt>
          <dd pn="section-11.1-2.24"> ACE WG mailing list (ace@ietf.org) or IETF Applications and Real-Time Area (art@ietf.org)</dd>
          <dt pn="section-11.1-2.25">Intended usage:</dt>
          <dd pn="section-11.1-2.26"> COMMON</dd>
          <dt pn="section-11.1-2.27">Restrictions on usage:</dt>
          <dd pn="section-11.1-2.28"> None</dd>
          <dt pn="section-11.1-2.29">Author/Change controller:</dt>
          <dd pn="section-11.1-2.30"> IETF</dd>
          <dt pn="section-11.1-2.31">Provisional registration:</dt>
          <dd pn="section-11.1-2.32"> No</dd>
        </dl>
      </section>
      <section anchor="content-type" numbered="true" removeInRFC="false" toc="include" pn="section-11.2">
        <name slugifiedName="name-coap-content-formats">CoAP Content-Formats</name>
        <t indent="0" pn="section-11.2-1">IANA has registered the following entry in the "CoAP Content-Formats" registry within the "CoRE Parameters" registry group.</t>
        <dl newline="false" spacing="compact" indent="3" pn="section-11.2-2">
          <dt pn="section-11.2-2.1">Content Type:</dt>
          <dd pn="section-11.2-2.2"> application/ace-groupcomm+cbor</dd>
          <dt pn="section-11.2-2.3">Content Coding:</dt>
          <dd pn="section-11.2-2.4"> -</dd>
          <dt pn="section-11.2-2.5">ID:</dt>
          <dd pn="section-11.2-2.6"> 261</dd>
          <dt pn="section-11.2-2.7">Reference:</dt>
          <dd pn="section-11.2-2.8"> RFC 9594</dd>
        </dl>
      </section>
      <section anchor="iana-kinfo" numbered="true" removeInRFC="false" toc="include" pn="section-11.3">
        <name slugifiedName="name-oauth-parameters">OAuth Parameters</name>
        <t indent="0" pn="section-11.3-1">IANA has registered the following entries in the "OAuth Parameters" registry, following the procedure specified in <xref section="11.2" sectionFormat="of" target="RFC6749" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6749#section-11.2" derivedContent="RFC6749"/>.</t>
        <dl spacing="compact" indent="3" newline="false" pn="section-11.3-2">
          <dt pn="section-11.3-2.1">Name:</dt>
          <dd pn="section-11.3-2.2"> sign_info</dd>
          <dt pn="section-11.3-2.3">Parameter Usage Location:</dt>
          <dd pn="section-11.3-2.4"> client-rs request, rs-client response</dd>
          <dt pn="section-11.3-2.5">Change Controller:</dt>
          <dd pn="section-11.3-2.6"> IETF</dd>
          <dt pn="section-11.3-2.7">Reference:</dt>
          <dd pn="section-11.3-2.8"> RFC 9594</dd>
        </dl>
        <dl spacing="compact" indent="3" newline="false" pn="section-11.3-3">
          <dt pn="section-11.3-3.1">Name:</dt>
          <dd pn="section-11.3-3.2"> kdcchallenge</dd>
          <dt pn="section-11.3-3.3">Parameter Usage Location:</dt>
          <dd pn="section-11.3-3.4"> rs-client response</dd>
          <dt pn="section-11.3-3.5">Change Controller:</dt>
          <dd pn="section-11.3-3.6"> IETF</dd>
          <dt pn="section-11.3-3.7">Reference:</dt>
          <dd pn="section-11.3-3.8"> RFC 9594</dd>
        </dl>
      </section>
      <section anchor="iana-kinfo-map" numbered="true" removeInRFC="false" toc="include" pn="section-11.4">
        <name slugifiedName="name-oauth-parameters-cbor-mappi">OAuth Parameters CBOR Mappings</name>
        <t indent="0" pn="section-11.4-1">IANA has registered the following entries in the "OAuth Parameters CBOR
Mappings" registry, following the procedure specified in <xref section="8.10" sectionFormat="of" target="RFC9200" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9200#section-8.10" derivedContent="RFC9200"/>.</t>
        <dl spacing="compact" indent="3" newline="false" pn="section-11.4-2">
          <dt pn="section-11.4-2.1">Name:</dt>
          <dd pn="section-11.4-2.2">sign_info</dd>
          <dt pn="section-11.4-2.3">CBOR Key:</dt>
          <dd pn="section-11.4-2.4">45</dd>
          <dt pn="section-11.4-2.5">Value Type:</dt>
          <dd pn="section-11.4-2.6">Null or array</dd>
          <dt pn="section-11.4-2.7">Reference:</dt>
          <dd pn="section-11.4-2.8">RFC 9594</dd>
        </dl>
        <dl spacing="compact" indent="3" newline="false" pn="section-11.4-3">
          <dt pn="section-11.4-3.1">Name:</dt>
          <dd pn="section-11.4-3.2">kdcchallenge</dd>
          <dt pn="section-11.4-3.3">CBOR Key:</dt>
          <dd pn="section-11.4-3.4">46</dd>
          <dt pn="section-11.4-3.5">Value Type:</dt>
          <dd pn="section-11.4-3.6">byte string</dd>
          <dt pn="section-11.4-3.7">Reference:</dt>
          <dd pn="section-11.4-3.8">RFC 9594</dd>
        </dl>
      </section>
      <section anchor="if-ace-group" numbered="true" removeInRFC="false" toc="include" pn="section-11.5">
        <name slugifiedName="name-interface-description-if-li">Interface Description (if=) Link Target Attribute Values</name>
        <t indent="0" pn="section-11.5-1">IANA has registered the following entry in the "Interface Description (if=) Link Target Attribute Values" registry within the "Constrained RESTful Environments (CoRE) Parameters" registry group.</t>
        <dl spacing="compact" indent="3" newline="false" pn="section-11.5-2">
          <dt pn="section-11.5-2.1">Value:</dt>
          <dd pn="section-11.5-2.2"> ace.groups</dd>
          <dt pn="section-11.5-2.3">Description:</dt>
          <dd pn="section-11.5-2.4"> The KDC interface at the parent resource of group-membership resources is used to retrieve names of security groups using the ACE framework.</dd>
          <dt pn="section-11.5-2.5">Reference:</dt>
          <dd pn="section-11.5-2.6">
            <xref target="kdc-if" format="default" sectionFormat="of" derivedContent="Section 4.1"/> of RFC 9594</dd>
        </dl>
        <dl spacing="compact" indent="3" newline="false" pn="section-11.5-3">
          <dt pn="section-11.5-3.1">Value:</dt>
          <dd pn="section-11.5-3.2"> ace.group</dd>
          <dt pn="section-11.5-3.3">Description:</dt>
          <dd pn="section-11.5-3.4"> 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.</dd>
          <dt pn="section-11.5-3.5">Reference:</dt>
          <dd pn="section-11.5-3.6">
            <xref target="kdc-if" format="default" sectionFormat="of" derivedContent="Section 4.1"/> of RFC 9594</dd>
        </dl>
      </section>
      <section anchor="iana-custom-problem-details" numbered="true" removeInRFC="false" toc="include" pn="section-11.6">
        <name slugifiedName="name-custom-problem-detail-keys-">Custom Problem Detail Keys Registry</name>
        <t indent="0" pn="section-11.6-1">IANA has registered the following entry in the "Custom Problem Detail Keys" registry within the "Constrained RESTful Environments (CoRE) Parameters" registry group.</t>
        <dl spacing="compact" indent="3" newline="false" pn="section-11.6-2">
          <dt pn="section-11.6-2.1">Key Value:</dt>
          <dd pn="section-11.6-2.2">0</dd>
          <dt pn="section-11.6-2.3">Name:</dt>
          <dd pn="section-11.6-2.4"> ace-groupcomm-error</dd>
          <dt pn="section-11.6-2.5">Brief Description:</dt>
          <dd pn="section-11.6-2.6">Carry RFC 9594 problem details in a Concise Problem Details data item.</dd>
          <dt pn="section-11.6-2.7">Change Controller:</dt>
          <dd pn="section-11.6-2.8"> IETF</dd>
          <dt pn="section-11.6-2.9">Reference:</dt>
          <dd pn="section-11.6-2.10">RFC 9594, <xref target="kdc-if-errors" format="default" sectionFormat="of" derivedContent="Section 4.1.2"/></dd>
        </dl>
      </section>
      <section anchor="iana-reg" numbered="true" removeInRFC="false" toc="include" pn="section-11.7">
        <name slugifiedName="name-ace-groupcomm-parameters-3">ACE Groupcomm Parameters</name>
        <t indent="0" pn="section-11.7-1">This specification has established the "ACE Groupcomm Parameters" IANA registry within the "Authentication and Authorization for Constrained Environments (ACE)" registry group.</t>
        <t indent="0" pn="section-11.7-2">Values in this registry are covered by different registration policies as indicated below. Some policies require Expert Review; guidelines are provided in <xref target="review" format="default" sectionFormat="of" derivedContent="Section 11.14"/></t>
        <t indent="0" pn="section-11.7-3">The columns of this registry are:</t>
        <dl spacing="normal" indent="3" newline="false" pn="section-11.7-4">
          <dt pn="section-11.7-4.1">Name:</dt>
          <dd pn="section-11.7-4.2"> This is a descriptive name that enables easier reference to
the item. The name <bcp14>MUST</bcp14> be unique. It is not used in the encoding.</dd>
          <dt pn="section-11.7-4.3">CBOR Key:</dt>
          <dd pn="section-11.7-4.4"> This is the value used as the CBOR map key of the item. These values <bcp14>MUST</bcp14> be unique. The value can be a positive integer, a negative integer, or a text string. Different ranges of values use different registration policies <xref target="RFC8126" format="default" sectionFormat="of" derivedContent="RFC8126"/>. 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".</dd>
          <dt pn="section-11.7-4.5">CBOR Type:</dt>
          <dd pn="section-11.7-4.6"> This field contains the CBOR type of the item or a pointer to the registry that defines its type when that depends on another item.</dd>
          <dt pn="section-11.7-4.7">Reference:</dt>
          <dd pn="section-11.7-4.8"> This field contains a pointer to the public specification for the item.</dd>
        </dl>
        <t indent="0" pn="section-11.7-5">This registry has been initially populated with the values in <xref target="fig-ACE-Groupcomm-Parameters" format="default" sectionFormat="of" derivedContent="Table 5"/>.</t>
      </section>
      <section anchor="iana-key" numbered="true" removeInRFC="false" toc="include" pn="section-11.8">
        <name slugifiedName="name-ace-groupcomm-key-types-2">ACE Groupcomm Key Types</name>
        <t indent="0" pn="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.</t>
        <t indent="0" pn="section-11.8-2">Values in this registry are covered by different registration policies as indicated below. Some policies require Expert Review; guidelines are provided in <xref target="review" format="default" sectionFormat="of" derivedContent="Section 11.14"/>.</t>
        <t indent="0" pn="section-11.8-3">The columns of this registry are:</t>
        <dl spacing="normal" indent="3" newline="false" pn="section-11.8-4">
          <dt pn="section-11.8-4.1">Name:</dt>
          <dd pn="section-11.8-4.2"> This is a descriptive name that enables easier reference to
the item. The name <bcp14>MUST</bcp14> be unique. It is not used in the encoding.</dd>
          <dt pn="section-11.8-4.3">Key Type Value:</dt>
          <dd pn="section-11.8-4.4"> This is the value used to identify the keying material. These values <bcp14>MUST</bcp14> be unique. The value can be a positive integer, a negative integer, or a text string. Different ranges of values use different registration policies <xref target="RFC8126" format="default" sectionFormat="of" derivedContent="RFC8126"/>. 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".</dd>
          <dt pn="section-11.8-4.5">Profile:</dt>
          <dd pn="section-11.8-4.6"> 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.</dd>
          <dt pn="section-11.8-4.7">Description:</dt>
          <dd pn="section-11.8-4.8"> This field contains a brief description of the keying material.</dd>
          <dt pn="section-11.8-4.9">Reference:</dt>
          <dd pn="section-11.8-4.10"> This field contains a pointer to the public specification for the format of the keying material, if one exists.</dd>
        </dl>
        <t indent="0" pn="section-11.8-5">This registry has been initially populated with the value in <xref target="fig-gkty" format="default" sectionFormat="of" derivedContent="Table 1"/>.</t>
      </section>
      <section anchor="ace-groupcomm-profiles" numbered="true" removeInRFC="false" toc="include" pn="section-11.9">
        <name slugifiedName="name-ace-groupcomm-profiles-2">ACE Groupcomm Profiles</name>
        <t indent="0" pn="section-11.9-1">This specification establishes the "ACE Groupcomm Profiles" IANA registry within the "Authentication and Authorization for Constrained Environments (ACE)" registry group.</t>
        <t indent="0" pn="section-11.9-2">Values in this registry are covered by different registration policies as indicated below. Some policies require Expert Review; guidelines are provided in <xref target="review" format="default" sectionFormat="of" derivedContent="Section 11.14"/>.</t>
        <t indent="0" pn="section-11.9-3">The columns of this registry are:</t>
        <dl spacing="normal" indent="3" newline="false" pn="section-11.9-4">
          <dt pn="section-11.9-4.1">Name:</dt>
          <dd pn="section-11.9-4.2"> The name of the application profile.</dd>
          <dt pn="section-11.9-4.3">Description:</dt>
          <dd pn="section-11.9-4.4"> Text giving an overview of the application profile and the context it is developed for.</dd>
          <dt pn="section-11.9-4.5">CBOR Value:</dt>
          <dd pn="section-11.9-4.6"> CBOR abbreviation for the name of this application profile. These values <bcp14>MUST</bcp14> be unique. The value can be a positive integer or a negative integer. Different ranges of values use different registration policies <xref target="RFC8126" format="default" sectionFormat="of" derivedContent="RFC8126"/>. 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".</dd>
          <dt pn="section-11.9-4.7">Reference:</dt>
          <dd pn="section-11.9-4.8"> This field contains a pointer to the public specification for this application profile, if one exists.</dd>
        </dl>
        <t indent="0" pn="section-11.9-5">This registry has been initially populated with the value in <xref target="ace-groupcomm-profile-0" format="default" sectionFormat="of" derivedContent="Table 2"/>.</t>
      </section>
      <section anchor="ace-groupcomm-policies" numbered="true" removeInRFC="false" toc="include" pn="section-11.10">
        <name slugifiedName="name-ace-groupcomm-policies-2">ACE Groupcomm Policies</name>
        <t indent="0" pn="section-11.10-1">This specification establishes the "ACE Groupcomm Policies" IANA registry within the "Authentication and Authorization for Constrained Environments (ACE)" registry group.</t>
        <t indent="0" pn="section-11.10-2">Values in this registry are covered by different registration policies as indicated below. Some policies require Expert Review; guidelines are provided in <xref target="review" format="default" sectionFormat="of" derivedContent="Section 11.14"/>.</t>
        <t indent="0" pn="section-11.10-3">The columns of this registry are:</t>
        <dl spacing="normal" indent="3" newline="false" pn="section-11.10-4">
          <dt pn="section-11.10-4.1">Name:</dt>
          <dd pn="section-11.10-4.2"> The name of the group communication policy.</dd>
          <dt pn="section-11.10-4.3">CBOR Label:</dt>
          <dd pn="section-11.10-4.4"> The value to be used to identify this group communication policy. These values <bcp14>MUST</bcp14> be unique. The value can be a positive integer, a negative integer, or a text string. Different ranges of values use different registration policies <xref target="RFC8126" format="default" sectionFormat="of" derivedContent="RFC8126"/>. 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".</dd>
          <dt pn="section-11.10-4.5">CBOR Type:</dt>
          <dd pn="section-11.10-4.6"> The CBOR type used to encode the value of this group communication policy.</dd>
          <dt pn="section-11.10-4.7">Description:</dt>
          <dd pn="section-11.10-4.8"> This field contains a brief description for this group communication policy.</dd>
          <dt pn="section-11.10-4.9">Reference:</dt>
          <dd pn="section-11.10-4.10"> This field contains a pointer to the public specification for this group communication policy and its format, if one exists.</dd>
        </dl>
        <t indent="0" pn="section-11.10-5">This registry has been initially populated with the values in <xref target="fig-ACE-Groupcomm-Policies" format="default" sectionFormat="of" derivedContent="Table 3"/>.</t>
      </section>
      <section anchor="sequence-number-synchronization-methods" numbered="true" removeInRFC="false" toc="include" pn="section-11.11">
        <name slugifiedName="name-sequence-number-synchroniza">Sequence Number Synchronization Methods</name>
        <t indent="0" pn="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.</t>
        <t indent="0" pn="section-11.11-2">Values in this registry are covered by different registration policies as indicated below. Some policies require Expert Review; guidelines are provided in <xref target="review" format="default" sectionFormat="of" derivedContent="Section 11.14"/>.</t>
        <t indent="0" pn="section-11.11-3">The columns of this registry are:</t>
        <dl spacing="normal" indent="3" newline="false" pn="section-11.11-4">
          <dt pn="section-11.11-4.1">Name:</dt>
          <dd pn="section-11.11-4.2"> The name of the sequence number synchronization method.</dd>
          <dt pn="section-11.11-4.3">Value:</dt>
          <dd pn="section-11.11-4.4"> The value to be used to identify this sequence number synchronization method. These values <bcp14>MUST</bcp14> be unique. The value can be a positive integer, a negative integer, or a text string. Different ranges of values use different registration policies <xref target="RFC8126" format="default" sectionFormat="of" derivedContent="RFC8126"/>. 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".</dd>
          <dt pn="section-11.11-4.5">Description:</dt>
          <dd pn="section-11.11-4.6"> This field contains a brief description for this sequence number synchronization method.</dd>
          <dt pn="section-11.11-4.7">Reference:</dt>
          <dd pn="section-11.11-4.8"> This field contains a pointer to the public specification describing the sequence number synchronization method.</dd>
        </dl>
      </section>
      <section anchor="iana-ace-groupcomm-errors" numbered="true" removeInRFC="false" toc="include" pn="section-11.12">
        <name slugifiedName="name-ace-groupcomm-errors">ACE Groupcomm Errors</name>
        <t indent="0" pn="section-11.12-1">This specification establishes the "ACE Groupcomm Errors" IANA registry within the "Authentication and Authorization for Constrained Environments (ACE)" registry group.</t>
        <t indent="0" pn="section-11.12-2">Values in this registry are covered by different registration policies as indicated below. Some policies require Expert Review; guidelines are provided in <xref target="review" format="default" sectionFormat="of" derivedContent="Section 11.14"/>.</t>
        <t indent="0" pn="section-11.12-3">The columns of this registry are:</t>
        <dl spacing="normal" indent="3" newline="false" pn="section-11.12-4">
          <dt pn="section-11.12-4.1">Value:</dt>
          <dd pn="section-11.12-4.2"> The value to be used to identify the error. These values <bcp14>MUST</bcp14> be unique. The value can be a positive integer or a negative integer. Different ranges of values use different registration policies <xref target="RFC8126" format="default" sectionFormat="of" derivedContent="RFC8126"/>. 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".</dd>
          <dt pn="section-11.12-4.3">Description:</dt>
          <dd pn="section-11.12-4.4"> This field contains a brief description of the error.</dd>
          <dt pn="section-11.12-4.5">Reference:</dt>
          <dd pn="section-11.12-4.6"> This field contains a pointer to the public specification defining the error, if one exists.</dd>
        </dl>
        <t indent="0" pn="section-11.12-5">This registry has been initially populated with the values in <xref target="fig-ACE-Groupcomm-Error-Identifiers" format="default" sectionFormat="of" derivedContent="Table 6"/>. The "Reference" column for all of these entries refers to this document.</t>
      </section>
      <section anchor="iana-ace-groupcomm-rekeying-schemes" numbered="true" removeInRFC="false" toc="include" pn="section-11.13">
        <name slugifiedName="name-ace-groupcomm-rekeying-schem">ACE Groupcomm Rekeying Schemes</name>
        <t indent="0" pn="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.</t>
        <t indent="0" pn="section-11.13-2">Values in this registry are covered by different registration policies as indicated below. Some policies require Expert Review; guidelines are provided in <xref target="review" format="default" sectionFormat="of" derivedContent="Section 11.14"/>.</t>
        <t indent="0" pn="section-11.13-3">The columns of this registry are:</t>
        <dl spacing="normal" indent="3" newline="false" pn="section-11.13-4">
          <dt pn="section-11.13-4.1">Value:</dt>
          <dd pn="section-11.13-4.2"> The value to be used to identify the group rekeying scheme. These values <bcp14>MUST</bcp14> be unique. The value can be a positive integer or a negative integer. Different ranges of values use different registration policies <xref target="RFC8126" format="default" sectionFormat="of" derivedContent="RFC8126"/>. 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".</dd>
          <dt pn="section-11.13-4.3">Name:</dt>
          <dd pn="section-11.13-4.4"> The name of the group rekeying scheme.</dd>
          <dt pn="section-11.13-4.5">Description:</dt>
          <dd pn="section-11.13-4.6"> This field contains a brief description of the group rekeying scheme.</dd>
          <dt pn="section-11.13-4.7">Reference:</dt>
          <dd pn="section-11.13-4.8"> This field contains a pointer to the public specification defining the group rekeying scheme, if one exists.</dd>
        </dl>
        <t indent="0" pn="section-11.13-5">This registry has been initially populated with the value in <xref target="rekeying-scheme-0" format="default" sectionFormat="of" derivedContent="Table 4"/>.</t>
      </section>
      <section anchor="review" numbered="true" removeInRFC="false" toc="include" pn="section-11.14">
        <name slugifiedName="name-expert-review-instructions">Expert Review Instructions</name>
        <t indent="0" pn="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.</t>
        <t indent="0" pn="section-11.14-2">Expert Reviewers should take into consideration the following points:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-11.14-3">
          <li pn="section-11.14-3.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.</li>
          <li pn="section-11.14-3.2">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.</li>
          <li pn="section-11.14-3.3">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 the device it will be used on, and the number of code points left that encode to that size.</li>
        </ul>
      </section>
    </section>
  </middle>
  <back>
    <displayreference target="I-D.ietf-core-groupcomm-bis" to="GROUP-CoAP"/>
    <displayreference target="I-D.ietf-core-oscore-groupcomm" to="GROUP-OSCORE"/>
    <displayreference target="I-D.ietf-core-coap-pubsub" to="CoAP-PUBSUB"/>
    <displayreference target="I-D.ietf-cose-cbor-encoded-cert" to="C509-CERT"/>
    <displayreference target="I-D.tiloca-core-oscore-discovery" to="OSCORE-DISCOVERY"/>
    <references pn="section-12">
      <name slugifiedName="name-references">References</name>
      <references pn="section-12.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="CBOR.Tags" target="https://www.iana.org/assignments/cbor-tags/" quoteTitle="true" derivedAnchor="CBOR.Tags">
          <front>
            <title>Concise Binary Object Representation (CBOR) Tags</title>
            <author>
              <organization showOnFrontPage="true">IANA</organization>
            </author>
          </front>
        </reference>
        <reference anchor="CoAP.Content.Formats" target="https://www.iana.org/assignments/core-parameters/" quoteTitle="true" derivedAnchor="CoAP.Content.Formats">
          <front>
            <title>CoAP Content-Formats</title>
            <author>
              <organization showOnFrontPage="true">IANA</organization>
            </author>
          </front>
        </reference>
        <reference anchor="COSE.Algorithms" target="https://www.iana.org/assignments/cose/" quoteTitle="true" derivedAnchor="COSE.Algorithms">
          <front>
            <title>COSE Algorithms</title>
            <author>
              <organization showOnFrontPage="true">IANA</organization>
            </author>
          </front>
        </reference>
        <reference anchor="COSE.Header.Parameters" target="https://www.iana.org/assignments/cose/" quoteTitle="true" derivedAnchor="COSE.Header.Parameters">
          <front>
            <title>COSE Header Parameters</title>
            <author>
              <organization showOnFrontPage="true">IANA</organization>
            </author>
          </front>
        </reference>
        <reference anchor="COSE.Key.Types" target="https://www.iana.org/assignments/cose/" quoteTitle="true" derivedAnchor="COSE.Key.Types">
          <front>
            <title>COSE Key Types</title>
            <author>
              <organization showOnFrontPage="true">IANA</organization>
            </author>
          </front>
        </reference>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t indent="0">In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC3629" target="https://www.rfc-editor.org/info/rfc3629" quoteTitle="true" derivedAnchor="RFC3629">
          <front>
            <title>UTF-8, a transformation format of ISO 10646</title>
            <author fullname="F. Yergeau" initials="F." surname="Yergeau"/>
            <date month="November" year="2003"/>
            <abstract>
              <t indent="0">ISO/IEC 10646-1 defines a large character set called the Universal Character Set (UCS) which encompasses most of the world's writing systems. The originally proposed encodings of the UCS, however, were not compatible with many current applications and protocols, and this has led to the development of UTF-8, the object of this memo. UTF-8 has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values. This memo obsoletes and replaces RFC 2279.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="63"/>
          <seriesInfo name="RFC" value="3629"/>
          <seriesInfo name="DOI" value="10.17487/RFC3629"/>
        </reference>
        <reference anchor="RFC6690" target="https://www.rfc-editor.org/info/rfc6690" quoteTitle="true" derivedAnchor="RFC6690">
          <front>
            <title>Constrained RESTful Environments (CoRE) Link Format</title>
            <author fullname="Z. Shelby" initials="Z." surname="Shelby"/>
            <date month="August" year="2012"/>
            <abstract>
              <t indent="0">This specification defines Web Linking using a link format for use by constrained web servers to describe hosted resources, their attributes, and other relationships between links. Based on the HTTP Link Header field defined in RFC 5988, the Constrained RESTful Environments (CoRE) Link Format is carried as a payload and is assigned an Internet media type. "RESTful" refers to the Representational State Transfer (REST) architecture. A well-known URI is defined as a default entry point for requesting the links hosted by a server. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6690"/>
          <seriesInfo name="DOI" value="10.17487/RFC6690"/>
        </reference>
        <reference anchor="RFC6749" target="https://www.rfc-editor.org/info/rfc6749" quoteTitle="true" derivedAnchor="RFC6749">
          <front>
            <title>The OAuth 2.0 Authorization Framework</title>
            <author fullname="D. Hardt" initials="D." role="editor" surname="Hardt"/>
            <date month="October" year="2012"/>
            <abstract>
              <t indent="0">The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6749"/>
          <seriesInfo name="DOI" value="10.17487/RFC6749"/>
        </reference>
        <reference anchor="RFC6838" target="https://www.rfc-editor.org/info/rfc6838" quoteTitle="true" derivedAnchor="RFC6838">
          <front>
            <title>Media Type Specifications and Registration Procedures</title>
            <author fullname="N. Freed" initials="N." surname="Freed"/>
            <author fullname="J. Klensin" initials="J." surname="Klensin"/>
            <author fullname="T. Hansen" initials="T." surname="Hansen"/>
            <date month="January" year="2013"/>
            <abstract>
              <t indent="0">This document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols. This memo documents an Internet Best Current Practice.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="13"/>
          <seriesInfo name="RFC" value="6838"/>
          <seriesInfo name="DOI" value="10.17487/RFC6838"/>
        </reference>
        <reference anchor="RFC7252" target="https://www.rfc-editor.org/info/rfc7252" quoteTitle="true" derivedAnchor="RFC7252">
          <front>
            <title>The Constrained Application Protocol (CoAP)</title>
            <author fullname="Z. Shelby" initials="Z." surname="Shelby"/>
            <author fullname="K. Hartke" initials="K." surname="Hartke"/>
            <author fullname="C. Bormann" initials="C." surname="Bormann"/>
            <date month="June" year="2014"/>
            <abstract>
              <t indent="0">The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation.</t>
              <t indent="0">CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7252"/>
          <seriesInfo name="DOI" value="10.17487/RFC7252"/>
        </reference>
        <reference anchor="RFC7967" target="https://www.rfc-editor.org/info/rfc7967" quoteTitle="true" derivedAnchor="RFC7967">
          <front>
            <title>Constrained Application Protocol (CoAP) Option for No Server Response</title>
            <author fullname="A. Bhattacharyya" initials="A." surname="Bhattacharyya"/>
            <author fullname="S. Bandyopadhyay" initials="S." surname="Bandyopadhyay"/>
            <author fullname="A. Pal" initials="A." surname="Pal"/>
            <author fullname="T. Bose" initials="T." surname="Bose"/>
            <date month="August" year="2016"/>
            <abstract>
              <t indent="0">There can be machine-to-machine (M2M) scenarios where server responses to client requests are redundant. This kind of open-loop exchange (with no response path from the server to the client) may be desired to minimize resource consumption in constrained systems while updating many resources simultaneously or performing high-frequency updates. CoAP already provides Non-confirmable (NON) messages that are not acknowledged by the recipient. However, the request/response semantics still require the server to respond with a status code indicating "the result of the attempt to understand and satisfy the request", per RFC 7252.</t>
              <t indent="0">This specification introduces a CoAP option called 'No-Response'. Using this option, the client can explicitly express to the server its disinterest in all responses against the particular request. This option also provides granular control to enable expression of disinterest to a particular response class or a combination of response classes. The server MAY decide to suppress the response by not transmitting it back to the client according to the value of the No-Response option in the request. This option may be effective for both unicast and multicast requests. This document also discusses a few examples of applications that benefit from this option.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7967"/>
          <seriesInfo name="DOI" value="10.17487/RFC7967"/>
        </reference>
        <reference anchor="RFC8126" target="https://www.rfc-editor.org/info/rfc8126" quoteTitle="true" derivedAnchor="RFC8126">
          <front>
            <title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
            <author fullname="M. Cotton" initials="M." surname="Cotton"/>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <author fullname="T. Narten" initials="T." surname="Narten"/>
            <date month="June" year="2017"/>
            <abstract>
              <t indent="0">Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).</t>
              <t indent="0">To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.</t>
              <t indent="0">This is the third edition of this document; it obsoletes RFC 5226.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="26"/>
          <seriesInfo name="RFC" value="8126"/>
          <seriesInfo name="DOI" value="10.17487/RFC8126"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t indent="0">RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="RFC8610" target="https://www.rfc-editor.org/info/rfc8610" quoteTitle="true" derivedAnchor="RFC8610">
          <front>
            <title>Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures</title>
            <author fullname="H. Birkholz" initials="H." surname="Birkholz"/>
            <author fullname="C. Vigano" initials="C." surname="Vigano"/>
            <author fullname="C. Bormann" initials="C." surname="Bormann"/>
            <date month="June" year="2019"/>
            <abstract>
              <t indent="0">This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8610"/>
          <seriesInfo name="DOI" value="10.17487/RFC8610"/>
        </reference>
        <reference anchor="RFC8747" target="https://www.rfc-editor.org/info/rfc8747" quoteTitle="true" derivedAnchor="RFC8747">
          <front>
            <title>Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs)</title>
            <author fullname="M. Jones" initials="M." surname="Jones"/>
            <author fullname="L. Seitz" initials="L." surname="Seitz"/>
            <author fullname="G. Selander" initials="G." surname="Selander"/>
            <author fullname="S. Erdtman" initials="S." surname="Erdtman"/>
            <author fullname="H. Tschofenig" initials="H." surname="Tschofenig"/>
            <date month="March" year="2020"/>
            <abstract>
              <t indent="0">This specification describes how to declare in a CBOR Web Token (CWT) (which is defined by RFC 8392) that the presenter of the CWT possesses a particular proof-of-possession key. Being able to prove possession of a key is also sometimes described as being the holder-of-key. This specification provides equivalent functionality to "Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)" (RFC 7800) but using Concise Binary Object Representation (CBOR) and CWTs rather than JavaScript Object Notation (JSON) and JSON Web Tokens (JWTs).</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8747"/>
          <seriesInfo name="DOI" value="10.17487/RFC8747"/>
        </reference>
        <reference anchor="RFC8949" target="https://www.rfc-editor.org/info/rfc8949" quoteTitle="true" derivedAnchor="RFC8949">
          <front>
            <title>Concise Binary Object Representation (CBOR)</title>
            <author fullname="C. Bormann" initials="C." surname="Bormann"/>
            <author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
            <date month="December" year="2020"/>
            <abstract>
              <t indent="0">The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack.</t>
              <t indent="0">This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="94"/>
          <seriesInfo name="RFC" value="8949"/>
          <seriesInfo name="DOI" value="10.17487/RFC8949"/>
        </reference>
        <reference anchor="RFC9052" target="https://www.rfc-editor.org/info/rfc9052" quoteTitle="true" derivedAnchor="RFC9052">
          <front>
            <title>CBOR Object Signing and Encryption (COSE): Structures and Process</title>
            <author fullname="J. Schaad" initials="J." surname="Schaad"/>
            <date month="August" year="2022"/>
            <abstract>
              <t indent="0">Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR.</t>
              <t indent="0">This document, along with RFC 9053, obsoletes RFC 8152.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="96"/>
          <seriesInfo name="RFC" value="9052"/>
          <seriesInfo name="DOI" value="10.17487/RFC9052"/>
        </reference>
        <reference anchor="RFC9053" target="https://www.rfc-editor.org/info/rfc9053" quoteTitle="true" derivedAnchor="RFC9053">
          <front>
            <title>CBOR Object Signing and Encryption (COSE): Initial Algorithms</title>
            <author fullname="J. Schaad" initials="J." surname="Schaad"/>
            <date month="August" year="2022"/>
            <abstract>
              <t indent="0">Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines a set of algorithms that can be used with the CBOR Object Signing and Encryption (COSE) protocol (RFC 9052).</t>
              <t indent="0">This document, along with RFC 9052, obsoletes RFC 8152.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9053"/>
          <seriesInfo name="DOI" value="10.17487/RFC9053"/>
        </reference>
        <reference anchor="RFC9200" target="https://www.rfc-editor.org/info/rfc9200" quoteTitle="true" derivedAnchor="RFC9200">
          <front>
            <title>Authentication and Authorization for Constrained Environments Using the OAuth 2.0 Framework (ACE-OAuth)</title>
            <author fullname="L. Seitz" initials="L." surname="Seitz"/>
            <author fullname="G. Selander" initials="G." surname="Selander"/>
            <author fullname="E. Wahlstroem" initials="E." surname="Wahlstroem"/>
            <author fullname="S. Erdtman" initials="S." surname="Erdtman"/>
            <author fullname="H. Tschofenig" initials="H." surname="Tschofenig"/>
            <date month="August" year="2022"/>
            <abstract>
              <t indent="0">This specification defines a framework for authentication and authorization in Internet of Things (IoT) environments called ACE-OAuth. The framework is based on a set of building blocks including OAuth 2.0 and the Constrained Application Protocol (CoAP), thus transforming a well-known and widely used authorization solution into a form suitable for IoT devices. Existing specifications are used where possible, but extensions are added and profiles are defined to better serve the IoT use cases.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9200"/>
          <seriesInfo name="DOI" value="10.17487/RFC9200"/>
        </reference>
        <reference anchor="RFC9237" target="https://www.rfc-editor.org/info/rfc9237" quoteTitle="true" derivedAnchor="RFC9237">
          <front>
            <title>An Authorization Information Format (AIF) for Authentication and Authorization for Constrained Environments (ACE)</title>
            <author fullname="C. Bormann" initials="C." surname="Bormann"/>
            <date month="August" year="2022"/>
            <abstract>
              <t indent="0">Information about which entities are authorized to perform what operations on which constituents of other entities is a crucial component of producing an overall system that is secure. Conveying precise authorization information is especially critical in highly automated systems with large numbers of entities, such as the Internet of Things.</t>
              <t indent="0">This specification provides a generic information model and format for representing such authorization information, as well as two variants of a specific instantiation of that format for use with Representational State Transfer (REST) resources identified by URI path.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9237"/>
          <seriesInfo name="DOI" value="10.17487/RFC9237"/>
        </reference>
        <reference anchor="RFC9290" target="https://www.rfc-editor.org/info/rfc9290" quoteTitle="true" derivedAnchor="RFC9290">
          <front>
            <title>Concise Problem Details for Constrained Application Protocol (CoAP) APIs</title>
            <author fullname="T. Fossati" initials="T." surname="Fossati"/>
            <author fullname="C. Bormann" initials="C." surname="Bormann"/>
            <date month="October" year="2022"/>
            <abstract>
              <t indent="0">This document defines a concise "problem detail" as a way to carry machine-readable details of errors in a Representational State Transfer (REST) response to avoid the need to define new error response formats for REST APIs for constrained environments. The format is inspired by, but intended to be more concise than, the problem details for HTTP APIs defined in RFC 7807.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9290"/>
          <seriesInfo name="DOI" value="10.17487/RFC9290"/>
        </reference>
        <reference anchor="RFC9338" target="https://www.rfc-editor.org/info/rfc9338" quoteTitle="true" derivedAnchor="RFC9338">
          <front>
            <title>CBOR Object Signing and Encryption (COSE): Countersignatures</title>
            <author fullname="J. Schaad" initials="J." surname="Schaad"/>
            <date month="December" year="2022"/>
            <abstract>
              <t indent="0">Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. CBOR Object Signing and Encryption (COSE) defines a set of security services for CBOR. This document defines a countersignature algorithm along with the needed header parameters and CBOR tags for COSE. This document updates RFC 9052.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="96"/>
          <seriesInfo name="RFC" value="9338"/>
          <seriesInfo name="DOI" value="10.17487/RFC9338"/>
        </reference>
      </references>
      <references pn="section-12.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="I-D.ietf-cose-cbor-encoded-cert" target="https://datatracker.ietf.org/doc/html/draft-ietf-cose-cbor-encoded-cert-11" quoteTitle="true" derivedAnchor="C509-CERT">
          <front>
            <title>CBOR Encoded X.509 Certificates (C509 Certificates)</title>
            <author initials="J." surname="Preuß Mattsson" fullname="John Preuß Mattsson">
              <organization showOnFrontPage="true">Ericsson AB</organization>
            </author>
            <author initials="G." surname="Selander" fullname="Göran Selander">
              <organization showOnFrontPage="true">Ericsson AB</organization>
            </author>
            <author initials="S." surname="Raza" fullname="Shahid Raza">
              <organization showOnFrontPage="true">RISE AB</organization>
            </author>
            <author initials="J." surname="Höglund" fullname="Joel Höglund">
              <organization showOnFrontPage="true">RISE AB</organization>
            </author>
            <author initials="M." surname="Furuhed" fullname="Martin Furuhed">
              <organization showOnFrontPage="true">Nexus Group</organization>
            </author>
            <date month="July" day="8" year="2024"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-cose-cbor-encoded-cert-11"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="I-D.ietf-core-coap-pubsub" target="https://datatracker.ietf.org/doc/html/draft-ietf-core-coap-pubsub-14" quoteTitle="true" derivedAnchor="CoAP-PUBSUB">
          <front>
            <title>A publish-subscribe architecture for the Constrained Application Protocol (CoAP)</title>
            <author initials="J." surname="Jimenez" fullname="Jaime Jimenez">
              <organization showOnFrontPage="true">Ericsson</organization>
            </author>
            <author initials="M." surname="Koster" fullname="Michael Koster">
              <organization showOnFrontPage="true">Dogtiger Labs</organization>
            </author>
            <author initials="A." surname="Keränen" fullname="Ari Keränen">
              <organization showOnFrontPage="true">Ericsson</organization>
            </author>
            <date month="April" day="18" year="2024"/>
            <abstract>
              <t indent="0">   This document describes a publish-subscribe architecture for the
   Constrained Application Protocol (CoAP), extending the capabilities
   of CoAP communications for supporting endpoints with long breaks in
   connectivity and/or up-time.  CoAP clients publish on and subscribe
   to a topic via a corresponding topic resource at a CoAP server acting
   as broker.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-core-coap-pubsub-14"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="I-D.ietf-core-groupcomm-bis" target="https://datatracker.ietf.org/doc/html/draft-ietf-core-groupcomm-bis-11" quoteTitle="true" derivedAnchor="GROUP-CoAP">
          <front>
            <title>Group Communication for the Constrained Application Protocol (CoAP)</title>
            <author initials="E." surname="Dijk" fullname="Esko Dijk">
              <organization showOnFrontPage="true">IoTconsultancy.nl</organization>
            </author>
            <author initials="C." surname="Wang" fullname="Chonggang Wang">
              <organization showOnFrontPage="true">InterDigital</organization>
            </author>
            <author initials="M." surname="Tiloca" fullname="Marco Tiloca">
              <organization showOnFrontPage="true">RISE AB</organization>
            </author>
            <date month="April" day="24" year="2024"/>
            <abstract>
              <t indent="0">   This document specifies the use of the Constrained Application
   Protocol (CoAP) for group communication, including the use of UDP/IP
   multicast as the default underlying data transport.  Both unsecured
   and secured CoAP group communication are specified.  Security is
   achieved by use of the Group Object Security for Constrained RESTful
   Environments (Group OSCORE) protocol.  The target application area of
   this specification is any group communication use cases that involve
   resource-constrained devices or networks that support CoAP.  This
   document replaces and obsoletes RFC 7390, while it updates RFC 7252
   and RFC 7641.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-core-groupcomm-bis-11"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="I-D.ietf-core-oscore-groupcomm" target="https://datatracker.ietf.org/doc/html/draft-ietf-core-oscore-groupcomm-22" quoteTitle="true" derivedAnchor="GROUP-OSCORE">
          <front>
            <title>Group Object Security for Constrained RESTful Environments (Group OSCORE)</title>
            <author initials="M." surname="Tiloca" fullname="Marco Tiloca">
              <organization showOnFrontPage="true">RISE AB</organization>
            </author>
            <author initials="G." surname="Selander" fullname="Göran Selander">
              <organization showOnFrontPage="true">Ericsson AB</organization>
            </author>
            <author initials="F." surname="Palombini" fullname="Francesca Palombini">
              <organization showOnFrontPage="true">Ericsson AB</organization>
            </author>
            <author initials="J." surname="Preuß Mattsson" fullname="John Preuß Mattsson">
              <organization showOnFrontPage="true">Ericsson AB</organization>
            </author>
            <author initials="R." surname="Höglund" fullname="Rikard Höglund">
              <organization showOnFrontPage="true">RISE AB</organization>
            </author>
            <date month="August" day="28" year="2024"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-core-oscore-groupcomm-22"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="I-D.tiloca-core-oscore-discovery" target="https://datatracker.ietf.org/doc/html/draft-tiloca-core-oscore-discovery-16" quoteTitle="true" derivedAnchor="OSCORE-DISCOVERY">
          <front>
            <title>Discovery of OSCORE Groups with the CoRE Resource Directory</title>
            <author initials="M." surname="Tiloca" fullname="Marco Tiloca">
              <organization showOnFrontPage="true">RISE AB</organization>
            </author>
            <author initials="C." surname="Amsüss" fullname="Christian Amsüss">
         </author>
            <author initials="P." surname="Van der Stok" fullname="Peter Van der Stok">
         </author>
            <date month="September" day="4" year="2024"/>
            <abstract>
              <t indent="0">   Group communication over the Constrained Application Protocol (CoAP)
   can be secured by means of Group Object Security for Constrained
   RESTful Environments (Group OSCORE).  At deployment time, devices may
   not know the exact security groups to join, the respective Group
   Manager, or other information required to perform the joining
   process.  This document describes how a CoAP endpoint can use
   descriptions and links of resources registered at the CoRE Resource
   Directory to discover security groups and to acquire information for
   joining them through the respective Group Manager.  A given security
   group may protect multiple application groups, which are separately
   announced in the Resource Directory as sets of endpoints sharing a
   pool of resources.  This approach is consistent with, but not limited
   to, the joining of security groups based on the ACE framework for
   Authentication and Authorization in constrained environments.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-tiloca-core-oscore-discovery-16"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="RFC2093" target="https://www.rfc-editor.org/info/rfc2093" quoteTitle="true" derivedAnchor="RFC2093">
          <front>
            <title>Group Key Management Protocol (GKMP) Specification</title>
            <author fullname="H. Harney" initials="H." surname="Harney"/>
            <author fullname="C. Muckenhirn" initials="C." surname="Muckenhirn"/>
            <date month="July" year="1997"/>
            <abstract>
              <t indent="0">This specification proposes a protocol to create grouped symmetric keys and distribute them amongst communicating peers. This memo defines an Experimental Protocol for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2093"/>
          <seriesInfo name="DOI" value="10.17487/RFC2093"/>
        </reference>
        <reference anchor="RFC2094" target="https://www.rfc-editor.org/info/rfc2094" quoteTitle="true" derivedAnchor="RFC2094">
          <front>
            <title>Group Key Management Protocol (GKMP) Architecture</title>
            <author fullname="H. Harney" initials="H." surname="Harney"/>
            <author fullname="C. Muckenhirn" initials="C." surname="Muckenhirn"/>
            <date month="July" year="1997"/>
            <abstract>
              <t indent="0">This specification proposes a protocol to create grouped symmetric keys and distribute them amongst communicating peers. This memo defines an Experimental Protocol for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2094"/>
          <seriesInfo name="DOI" value="10.17487/RFC2094"/>
        </reference>
        <reference anchor="RFC2627" target="https://www.rfc-editor.org/info/rfc2627" quoteTitle="true" derivedAnchor="RFC2627">
          <front>
            <title>Key Management for Multicast: Issues and Architectures</title>
            <author fullname="D. Wallner" initials="D." surname="Wallner"/>
            <author fullname="E. Harder" initials="E." surname="Harder"/>
            <author fullname="R. Agee" initials="R." surname="Agee"/>
            <date month="June" year="1999"/>
            <abstract>
              <t indent="0">This report contains a discussion of the difficult problem of key management for multicast communication sessions. It focuses on two main areas of concern with respect to key management, which are, initializing the multicast group with a common net key and rekeying the multicast group. This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2627"/>
          <seriesInfo name="DOI" value="10.17487/RFC2627"/>
        </reference>
        <reference anchor="RFC3986" target="https://www.rfc-editor.org/info/rfc3986" quoteTitle="true" derivedAnchor="RFC3986">
          <front>
            <title>Uniform Resource Identifier (URI): Generic Syntax</title>
            <author fullname="T. Berners-Lee" initials="T." surname="Berners-Lee"/>
            <author fullname="R. Fielding" initials="R." surname="Fielding"/>
            <author fullname="L. Masinter" initials="L." surname="Masinter"/>
            <date month="January" year="2005"/>
            <abstract>
              <t indent="0">A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="66"/>
          <seriesInfo name="RFC" value="3986"/>
          <seriesInfo name="DOI" value="10.17487/RFC3986"/>
        </reference>
        <reference anchor="RFC5280" target="https://www.rfc-editor.org/info/rfc5280" quoteTitle="true" derivedAnchor="RFC5280">
          <front>
            <title>Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</title>
            <author fullname="D. Cooper" initials="D." surname="Cooper"/>
            <author fullname="S. Santesson" initials="S." surname="Santesson"/>
            <author fullname="S. Farrell" initials="S." surname="Farrell"/>
            <author fullname="S. Boeyen" initials="S." surname="Boeyen"/>
            <author fullname="R. Housley" initials="R." surname="Housley"/>
            <author fullname="W. Polk" initials="W." surname="Polk"/>
            <date month="May" year="2008"/>
            <abstract>
              <t indent="0">This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5280"/>
          <seriesInfo name="DOI" value="10.17487/RFC5280"/>
        </reference>
        <reference anchor="RFC7519" target="https://www.rfc-editor.org/info/rfc7519" quoteTitle="true" derivedAnchor="RFC7519">
          <front>
            <title>JSON Web Token (JWT)</title>
            <author fullname="M. Jones" initials="M." surname="Jones"/>
            <author fullname="J. Bradley" initials="J." surname="Bradley"/>
            <author fullname="N. Sakimura" initials="N." surname="Sakimura"/>
            <date month="May" year="2015"/>
            <abstract>
              <t indent="0">JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7519"/>
          <seriesInfo name="DOI" value="10.17487/RFC7519"/>
        </reference>
        <reference anchor="RFC7641" target="https://www.rfc-editor.org/info/rfc7641" quoteTitle="true" derivedAnchor="RFC7641">
          <front>
            <title>Observing Resources in the Constrained Application Protocol (CoAP)</title>
            <author fullname="K. Hartke" initials="K." surname="Hartke"/>
            <date month="September" year="2015"/>
            <abstract>
              <t indent="0">The Constrained Application Protocol (CoAP) is a RESTful application protocol for constrained nodes and networks. The state of a resource on a CoAP server can change over time. This document specifies a simple protocol extension for CoAP that enables CoAP clients to "observe" resources, i.e., to retrieve a representation of a resource and keep this representation updated by the server over a period of time. The protocol follows a best-effort approach for sending new representations to clients and provides eventual consistency between the state observed by each client and the actual resource state at the server.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7641"/>
          <seriesInfo name="DOI" value="10.17487/RFC7641"/>
        </reference>
        <reference anchor="RFC7959" target="https://www.rfc-editor.org/info/rfc7959" quoteTitle="true" derivedAnchor="RFC7959">
          <front>
            <title>Block-Wise Transfers in the Constrained Application Protocol (CoAP)</title>
            <author fullname="C. Bormann" initials="C." surname="Bormann"/>
            <author fullname="Z. Shelby" initials="Z." role="editor" surname="Shelby"/>
            <date month="August" year="2016"/>
            <abstract>
              <t indent="0">The Constrained Application Protocol (CoAP) is a RESTful transfer protocol for constrained nodes and networks. Basic CoAP messages work well for small payloads from sensors and actuators; however, applications will need to transfer larger payloads occasionally -- for instance, for firmware updates. In contrast to HTTP, where TCP does the grunt work of segmenting and resequencing, CoAP is based on datagram transports such as UDP or Datagram Transport Layer Security (DTLS). These transports only offer fragmentation, which is even more problematic in constrained nodes and networks, limiting the maximum size of resource representations that can practically be transferred.</t>
              <t indent="0">Instead of relying on IP fragmentation, this specification extends basic CoAP with a pair of "Block" options for transferring multiple blocks of information from a resource representation in multiple request-response pairs. In many important cases, the Block options enable a server to be truly stateless: the server can handle each block transfer separately, with no need for a connection setup or other server-side memory of previous block transfers. Essentially, the Block options provide a minimal way to transfer larger representations in a block-wise fashion.</t>
              <t indent="0">A CoAP implementation that does not support these options generally is limited in the size of the representations that can be exchanged, so there is an expectation that the Block options will be widely used in CoAP implementations. Therefore, this specification updates RFC 7252.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7959"/>
          <seriesInfo name="DOI" value="10.17487/RFC7959"/>
        </reference>
        <reference anchor="RFC8259" target="https://www.rfc-editor.org/info/rfc8259" quoteTitle="true" derivedAnchor="RFC8259">
          <front>
            <title>The JavaScript Object Notation (JSON) Data Interchange Format</title>
            <author fullname="T. Bray" initials="T." role="editor" surname="Bray"/>
            <date month="December" year="2017"/>
            <abstract>
              <t indent="0">JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data.</t>
              <t indent="0">This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="90"/>
          <seriesInfo name="RFC" value="8259"/>
          <seriesInfo name="DOI" value="10.17487/RFC8259"/>
        </reference>
        <reference anchor="RFC8392" target="https://www.rfc-editor.org/info/rfc8392" quoteTitle="true" derivedAnchor="RFC8392">
          <front>
            <title>CBOR Web Token (CWT)</title>
            <author fullname="M. Jones" initials="M." surname="Jones"/>
            <author fullname="E. Wahlstroem" initials="E." surname="Wahlstroem"/>
            <author fullname="S. Erdtman" initials="S." surname="Erdtman"/>
            <author fullname="H. Tschofenig" initials="H." surname="Tschofenig"/>
            <date month="May" year="2018"/>
            <abstract>
              <t indent="0">CBOR Web Token (CWT) is a compact means of representing claims to be transferred between two parties. The claims in a CWT are encoded in the Concise Binary Object Representation (CBOR), and CBOR Object Signing and Encryption (COSE) is used for added application-layer security protection. A claim is a piece of information asserted about a subject and is represented as a name/value pair consisting of a claim name and a claim value. CWT is derived from JSON Web Token (JWT) but uses CBOR rather than JSON.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8392"/>
          <seriesInfo name="DOI" value="10.17487/RFC8392"/>
        </reference>
        <reference anchor="RFC8613" target="https://www.rfc-editor.org/info/rfc8613" quoteTitle="true" derivedAnchor="RFC8613">
          <front>
            <title>Object Security for Constrained RESTful Environments (OSCORE)</title>
            <author fullname="G. Selander" initials="G." surname="Selander"/>
            <author fullname="J. Mattsson" initials="J." surname="Mattsson"/>
            <author fullname="F. Palombini" initials="F." surname="Palombini"/>
            <author fullname="L. Seitz" initials="L." surname="Seitz"/>
            <date month="July" year="2019"/>
            <abstract>
              <t indent="0">This document defines Object Security for Constrained RESTful Environments (OSCORE), a method for application-layer protection of the Constrained Application Protocol (CoAP), using CBOR Object Signing and Encryption (COSE). OSCORE provides end-to-end protection between endpoints communicating using CoAP or CoAP-mappable HTTP. OSCORE is designed for constrained nodes and networks supporting a range of proxy operations, including translation between different transport protocols.</t>
              <t indent="0">Although an optional functionality of CoAP, OSCORE alters CoAP options processing and IANA registration. Therefore, this document updates RFC 7252.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8613"/>
          <seriesInfo name="DOI" value="10.17487/RFC8613"/>
        </reference>
        <reference anchor="RFC9202" target="https://www.rfc-editor.org/info/rfc9202" quoteTitle="true" derivedAnchor="RFC9202">
          <front>
            <title>Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE)</title>
            <author fullname="S. Gerdes" initials="S." surname="Gerdes"/>
            <author fullname="O. Bergmann" initials="O." surname="Bergmann"/>
            <author fullname="C. Bormann" initials="C." surname="Bormann"/>
            <author fullname="G. Selander" initials="G." surname="Selander"/>
            <author fullname="L. Seitz" initials="L." surname="Seitz"/>
            <date month="August" year="2022"/>
            <abstract>
              <t indent="0">This specification defines a profile of the Authentication and Authorization for Constrained Environments (ACE) framework that allows constrained servers to delegate client authentication and authorization. The protocol relies on DTLS version 1.2 or later for communication security between entities in a constrained network using either raw public keys or pre-shared keys. A resource-constrained server can use this protocol to delegate management of authorization information to a trusted host with less-severe limitations regarding processing power and memory.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9202"/>
          <seriesInfo name="DOI" value="10.17487/RFC9202"/>
        </reference>
        <reference anchor="RFC9203" target="https://www.rfc-editor.org/info/rfc9203" quoteTitle="true" derivedAnchor="RFC9203">
          <front>
            <title>The Object Security for Constrained RESTful Environments (OSCORE) Profile of the Authentication and Authorization for Constrained Environments (ACE) Framework</title>
            <author fullname="F. Palombini" initials="F." surname="Palombini"/>
            <author fullname="L. Seitz" initials="L." surname="Seitz"/>
            <author fullname="G. Selander" initials="G." surname="Selander"/>
            <author fullname="M. Gunnarsson" initials="M." surname="Gunnarsson"/>
            <date month="August" year="2022"/>
            <abstract>
              <t indent="0">This document specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework. It utilizes Object Security for Constrained RESTful Environments (OSCORE) to provide communication security and proof-of-possession for a key owned by the client and bound to an OAuth 2.0 access token.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9203"/>
          <seriesInfo name="DOI" value="10.17487/RFC9203"/>
        </reference>
        <reference anchor="RFC9277" target="https://www.rfc-editor.org/info/rfc9277" quoteTitle="true" derivedAnchor="RFC9277">
          <front>
            <title>On Stable Storage for Items in Concise Binary Object Representation (CBOR)</title>
            <author fullname="M. Richardson" initials="M." surname="Richardson"/>
            <author fullname="C. Bormann" initials="C." surname="Bormann"/>
            <date month="August" year="2022"/>
            <abstract>
              <t indent="0">This document defines a stored ("file") format for Concise Binary Object Representation (CBOR) data items that is friendly to common systems that recognize file types, such as the Unix file(1) command.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9277"/>
          <seriesInfo name="DOI" value="10.17487/RFC9277"/>
        </reference>
        <reference anchor="RFC9431" target="https://www.rfc-editor.org/info/rfc9431" quoteTitle="true" derivedAnchor="RFC9431">
          <front>
            <title>Message Queuing Telemetry Transport (MQTT) and Transport Layer Security (TLS) Profile of Authentication and Authorization for Constrained Environments (ACE) Framework</title>
            <author fullname="C. Sengul" initials="C." surname="Sengul"/>
            <author fullname="A. Kirby" initials="A." surname="Kirby"/>
            <date month="July" year="2023"/>
            <abstract>
              <t indent="0">This document specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework to enable authorization in a publish-subscribe messaging system based on Message Queuing Telemetry Transport (MQTT). Proof-of-Possession keys, bound to OAuth 2.0 access tokens, are used to authenticate and authorize MQTT Clients. The protocol relies on TLS for confidentiality and MQTT server (Broker) authentication.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9431"/>
          <seriesInfo name="DOI" value="10.17487/RFC9431"/>
        </reference>
      </references>
    </references>
    <section anchor="req" numbered="true" removeInRFC="false" toc="include" pn="section-appendix.a">
      <name slugifiedName="name-requirements-for-applicatio">Requirements for Application Profiles</name>
      <t indent="0" pn="section-appendix.a-1">This section lists the requirements for application profiles of this specification for the convenience of application profile designers.</t>
      <section anchor="req-mandatory" numbered="true" removeInRFC="false" toc="include" pn="section-appendix.a.1">
        <name slugifiedName="name-mandatory-to-address-requir">Mandatory-to-Address Requirements</name>
        <ol type="REQ%d:" indent="adaptive" spacing="normal" start="1" pn="section-appendix.a.1-1">
          <li anchor="req1" pn="section-appendix.a.1-1.1" derivedCounter="REQ1:">Specify the format and encoding of scope. This includes defining the set of possible roles and their identifiers, as well as the corresponding encoding to use in the scope entries according to the used scope format (see <xref target="ssec-authorization-request" format="default" sectionFormat="of" derivedContent="Section 3.1"/>).</li>
          <li anchor="req2" pn="section-appendix.a.1-1.2" derivedCounter="REQ2:">If scope uses AIF, register its specific instance of "Toid" and "Tperm" as media type parameters and a corresponding Content-Format, as per the guidelines in <xref target="RFC9237" format="default" sectionFormat="of" derivedContent="RFC9237"/>.</li>
          <li anchor="req3" pn="section-appendix.a.1-1.3" derivedCounter="REQ3:">If used, specify the acceptable values for the 'sign_alg' parameter (see <xref target="sign-info" format="default" sectionFormat="of" derivedContent="Section 3.3.1"/>).</li>
          <li anchor="req4" pn="section-appendix.a.1-1.4" derivedCounter="REQ4:">If used, specify the acceptable values and structure for the 'sign_parameters' parameter (see <xref target="sign-info" format="default" sectionFormat="of" derivedContent="Section 3.3.1"/>).</li>
          <li anchor="req5" pn="section-appendix.a.1-1.5" derivedCounter="REQ5:">If used, specify the acceptable values and structure for the 'sign_key_parameters' parameter (see <xref target="sign-info" format="default" sectionFormat="of" derivedContent="Section 3.3.1"/>).</li>
          <li anchor="req6" pn="section-appendix.a.1-1.6" derivedCounter="REQ6:">Specify the acceptable formats for authentication credentials and, if applicable, the acceptable values for the 'cred_fmt' parameter (see <xref target="sign-info" format="default" sectionFormat="of" derivedContent="Section 3.3.1"/>).</li>
          <li anchor="req7" pn="section-appendix.a.1-1.7" derivedCounter="REQ7:">If the value of the GROUPNAME URI path and the group name in the access token scope ('gname' in <xref target="ssec-authorization-request" format="default" sectionFormat="of" derivedContent="Section 3.1"/>) are not required to coincide, specify the mechanism to map the GROUPNAME value in the URI to the group name (see <xref target="kdc-if" format="default" sectionFormat="of" derivedContent="Section 4.1"/>).</li>
          <li anchor="req8" pn="section-appendix.a.1-1.8" derivedCounter="REQ8:">Define whether the KDC has an authentication credential as required for the correct group operation and if this has to be provided through the 'kdc_cred' parameter (see Sections <xref target="kdc-if" format="counter" sectionFormat="of" derivedContent="4.1"/> and <xref target="gid-post" format="counter" sectionFormat="of" derivedContent="4.3.1"/>).</li>
          <li anchor="req9" pn="section-appendix.a.1-1.9" derivedCounter="REQ9:">Specify if any part of the KDC interface as defined in this document is not supported by the KDC (see <xref target="kdc-if" format="default" sectionFormat="of" derivedContent="Section 4.1"/>).</li>
          <li anchor="req10" pn="section-appendix.a.1-1.10" derivedCounter="REQ10:">Register a Resource Type for the group-membership resources, which is used to discover the correct URL for sending a Join Request to the KDC (see <xref target="kdc-if" format="default" sectionFormat="of" derivedContent="Section 4.1"/>).</li>
          <li anchor="req11" pn="section-appendix.a.1-1.11" derivedCounter="REQ11:">Define what specific actions (e.g., CoAP methods) are allowed on each resource that are accessible through the KDC interface, depending on: whether the Client is a current group member; the roles that a Client is authorized to take as per the obtained access token (see <xref target="ssec-authorization-request" format="default" sectionFormat="of" derivedContent="Section 3.1"/>); and the roles that the Client has as a current group member.</li>
          <li anchor="req12" pn="section-appendix.a.1-1.12" derivedCounter="REQ12:">Categorize possible newly defined operations for Clients into primary operations expected to be minimally supported and secondary operations, and provide accompanying considerations (see <xref target="client-operations" format="default" sectionFormat="of" derivedContent="Section 4.1.1"/>).</li>
          <li anchor="req13" pn="section-appendix.a.1-1.13" derivedCounter="REQ13:">Specify the encoding of group identifiers (see <xref target="ace-group-fetch" format="default" sectionFormat="of" derivedContent="Section 4.2.1"/>).</li>
          <li anchor="req14" pn="section-appendix.a.1-1.14" derivedCounter="REQ14:">Specify the approaches used to compute and verify the PoP evidence to include in the 'client_cred_verify' parameter and which of those approaches is used in which case (see <xref target="gid-post" format="default" sectionFormat="of" derivedContent="Section 4.3.1"/>).</li>
          <li anchor="req15" pn="section-appendix.a.1-1.15" derivedCounter="REQ15:">Specify how the nonce N_S is generated, if the access token is not provided to the KDC through the Token Transfer Request sent to the /authz-info endpoint (e.g., the access token is instead transferred during the establishment of a secure communication association).</li>
          <li anchor="req16" pn="section-appendix.a.1-1.16" derivedCounter="REQ16:">Define the initial value of the version number for the group keying material (see <xref target="gid-post" format="default" sectionFormat="of" derivedContent="Section 4.3.1"/>).</li>
          <li anchor="req17" pn="section-appendix.a.1-1.17" derivedCounter="REQ17:">Specify the format of the group keying material that is conveyed in the 'key' parameter (see <xref target="gid-post" format="default" sectionFormat="of" derivedContent="Section 4.3.1"/>).</li>
          <li anchor="req18" pn="section-appendix.a.1-1.18" derivedCounter="REQ18:">Specify the acceptable values of the 'gkty' parameter (see <xref target="gid-post" format="default" sectionFormat="of" derivedContent="Section 4.3.1"/>). For each of them, register a corresponding entry in the "ACE Groupcomm Key Types" IANA registry if such an entry does not exist already.</li>
          <li anchor="req19" pn="section-appendix.a.1-1.19" derivedCounter="REQ19:">Specify and register the application profile identifier (see <xref target="gid-post" format="default" sectionFormat="of" derivedContent="Section 4.3.1"/>).</li>
          <li anchor="req20" pn="section-appendix.a.1-1.20" derivedCounter="REQ20:">If used, specify the format and default values of the entries of the CBOR map to include in the 'group_policies' parameter (see <xref target="gid-post" format="default" sectionFormat="of" derivedContent="Section 4.3.1"/>).</li>
          <li anchor="req21" pn="section-appendix.a.1-1.21" derivedCounter="REQ21:">Specify the approaches used to compute and verify the PoP evidence to include in the 'kdc_cred_verify' parameter and which of those approaches is used in which case (see Sections <xref target="gid-post" format="counter" sectionFormat="of" derivedContent="4.3.1"/> and <xref target="kdc-pub-key-get" format="counter" sectionFormat="of" derivedContent="4.5.1"/>). If external signature verifiers are supported, specify how those provide a nonce to the KDC to be used for computing the PoP evidence (see <xref target="kdc-pub-key-get" format="default" sectionFormat="of" derivedContent="Section 4.5.1"/>).</li>
          <li anchor="req22" pn="section-appendix.a.1-1.22" derivedCounter="REQ22:">Specify the communication protocol that members of the group use to communicate with each other (e.g., CoAP for group communication).</li>
          <li anchor="req23" pn="section-appendix.a.1-1.23" derivedCounter="REQ23:">Specify the security protocol that members of the group use to protect the group communication (e.g., Group OSCORE). This must provide encryption, integrity, and replay protection.</li>
          <li anchor="req24" pn="section-appendix.a.1-1.24" derivedCounter="REQ24:">Specify how the communication is secured between the Client and the KDC. Optionally, specify a transport profile of ACE <xref target="RFC9200" format="default" sectionFormat="of" derivedContent="RFC9200"/> to use between the Client and the KDC (see <xref target="ssec-key-distribution-exchange" format="default" sectionFormat="of" derivedContent="Section 4.3.1.1"/>).</li>
          <li anchor="req25" pn="section-appendix.a.1-1.25" derivedCounter="REQ25:">Specify the format of the node identifiers of group members (see Sections <xref target="gid-post" format="counter" sectionFormat="of" derivedContent="4.3.1"/> and <xref target="pubkey-fetch" format="counter" sectionFormat="of" derivedContent="4.4.1"/>).</li>
          <li anchor="req26" pn="section-appendix.a.1-1.26" derivedCounter="REQ26:">Specify policies at the KDC to handle node identifiers that are included in the 'get_creds' parameter but are not associated with any current group member (see <xref target="pubkey-fetch" format="default" sectionFormat="of" derivedContent="Section 4.4.1"/>).</li>
          <li anchor="req27" pn="section-appendix.a.1-1.27" derivedCounter="REQ27:">Specify the format of (newly generated) individual keying material for group members or of the information to derive such keying material, as well as the corresponding CBOR map key that has to be registered in the "ACE Groupcomm Parameters" registry (see Sections <xref target="node-get" format="counter" sectionFormat="of" derivedContent="4.8.1"/> and <xref target="node-put" format="counter" sectionFormat="of" derivedContent="4.8.2"/>).</li>
          <li anchor="req28" pn="section-appendix.a.1-1.28" derivedCounter="REQ28:">Specify which CBOR tag is used for identifying the semantics of binary scopes, or register a new CBOR tag if a suitable one does not exist already (see <xref target="sec-extended-scope" format="default" sectionFormat="of" derivedContent="Section 7"/>).</li>
          <li anchor="req29" pn="section-appendix.a.1-1.29" derivedCounter="REQ29:">Categorize newly defined parameters according to the same criteria of <xref target="params" format="default" sectionFormat="of" derivedContent="Section 8"/>.</li>
          <li anchor="req30" pn="section-appendix.a.1-1.30" derivedCounter="REQ30:">Define whether Clients must, should, or may support the conditional parameters defined in <xref target="params" format="default" sectionFormat="of" derivedContent="Section 8"/> and under which circumstances.</li>
        </ol>
      </section>
      <section anchor="req-optional" numbered="true" removeInRFC="false" toc="include" pn="section-appendix.a.2">
        <name slugifiedName="name-optional-to-address-require">Optional-to-Address Requirements</name>
        <ol type="OPT%d:" indent="adaptive" spacing="normal" start="1" pn="section-appendix.a.2-1">
          <li anchor="opt1" pn="section-appendix.a.2-1.1" derivedCounter="OPT1:">Optionally, if the textual format of scope is used, specify CBOR values to use for abbreviating the role identifiers in the group (see <xref target="ssec-authorization-request" format="default" sectionFormat="of" derivedContent="Section 3.1"/>).</li>
          <li anchor="opt2" pn="section-appendix.a.2-1.2" derivedCounter="OPT2:">Optionally, specify the additional parameters used in the exchange of Token Transfer Request and Response (see <xref target="token-post" format="default" sectionFormat="of" derivedContent="Section 3.3"/>).</li>
          <li anchor="opt3" pn="section-appendix.a.2-1.3" derivedCounter="OPT3:">Optionally, specify the negotiation of parameter values for signature algorithm and signature keys, if the 'sign_info' parameter is not used (see <xref target="token-post" format="default" sectionFormat="of" derivedContent="Section 3.3"/>).</li>
          <li anchor="opt4" pn="section-appendix.a.2-1.4" derivedCounter="OPT4:">Optionally, specify possible or required payload formats for specific error cases (see <xref target="kdc-if-errors" format="default" sectionFormat="of" derivedContent="Section 4.1.2"/>).</li>
          <li anchor="opt5" pn="section-appendix.a.2-1.5" derivedCounter="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 <xref target="kdc-if-errors" format="default" sectionFormat="of" derivedContent="Section 4.1.2"/>).</li>
          <li anchor="opt6" pn="section-appendix.a.2-1.6" derivedCounter="OPT6:">Optionally, specify the encoding of the 'creds_repo' parameter if the default one is not used (see <xref target="gid-post" format="default" sectionFormat="of" derivedContent="Section 4.3.1"/>).</li>
          <li anchor="opt7" pn="section-appendix.a.2-1.7" derivedCounter="OPT7:">Optionally, specify the functionalities implemented at the resource hosted by the Client at the URI indicated in the 'control_uri' parameter, including the encoding of exchanged messages and other details (see <xref target="gid-post" format="default" sectionFormat="of" derivedContent="Section 4.3.1"/>).</li>
          <li anchor="opt8" pn="section-appendix.a.2-1.8" derivedCounter="OPT8:">Optionally, specify the behavior of the POST handler of group-membership resources, for the case when it fails to retrieve an authentication credential for the specific Client (see <xref target="gid-post" format="default" sectionFormat="of" derivedContent="Section 4.3.1"/>).</li>
          <li anchor="opt9" pn="section-appendix.a.2-1.9" derivedCounter="OPT9:">Optionally, define a default group rekeying scheme to refer to in case the 'rekeying_scheme' parameter is not included in the Join Response (see <xref target="gid-post" format="default" sectionFormat="of" derivedContent="Section 4.3.1"/>).</li>
          <li anchor="opt10" pn="section-appendix.a.2-1.10" derivedCounter="OPT10:">Optionally, specify the functionalities implemented at the resource hosted by the Client at the URI indicated in the 'control_group_uri' parameter, including the encoding of exchanged messages and other details (see <xref target="gid-post" format="default" sectionFormat="of" derivedContent="Section 4.3.1"/>).</li>
          <li anchor="opt11" pn="section-appendix.a.2-1.11" derivedCounter="OPT11:">Optionally, specify policies that instruct Clients to retain messages and for how long, if those are unsuccessfully decrypted (see <xref target="update-keys" format="default" sectionFormat="of" derivedContent="Section 4.8.1.1"/>). This makes it possible for Clients to decrypt such messages after obtaining updated keying material.</li>
          <li anchor="opt12" pn="section-appendix.a.2-1.12" derivedCounter="OPT12:">Optionally, specify for the KDC to perform a group rekeying when receiving a Key Renewal Request, together with or instead of renewing individual keying material (see <xref target="new-keys" format="default" sectionFormat="of" derivedContent="Section 4.8.2.1"/>).</li>
          <li anchor="opt13" pn="section-appendix.a.2-1.13" derivedCounter="OPT13:">Optionally, specify how the identifier of a group member's authentication credential is included in requests sent to other group members (see <xref target="update-pub-key" format="default" sectionFormat="of" derivedContent="Section 4.9.1.1"/>).</li>
          <li anchor="opt14" pn="section-appendix.a.2-1.14" derivedCounter="OPT14:">Optionally, specify additional information to include in rekeying messages for the "Point-to-Point" group rekeying scheme (see <xref target="sec-group-rekeying" format="default" sectionFormat="of" derivedContent="Section 6"/>).</li>
        </ol>
      </section>
    </section>
    <section anchor="sec-future-cose-algs" numbered="true" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-extensibility-for-future-co">Extensibility for Future COSE Algorithms</name>
      <t indent="0" pn="section-appendix.b-1">As defined in <xref section="8.1" sectionFormat="of" target="RFC9053" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9053#section-8.1" derivedContent="RFC9053"/>, future algorithms can be registered in the "COSE Algorithms" registry <xref target="COSE.Algorithms" format="default" sectionFormat="of" derivedContent="COSE.Algorithms"/> as specifying none or multiple COSE capabilities.</t>
      <t indent="0" pn="section-appendix.b-2">To enable the seamless use of such future registered algorithms, this section defines a general, agile format for each 'sign_info_entry' of the 'sign_info' parameter in the Token Transfer Response; see <xref target="sign-info" format="default" sectionFormat="of" derivedContent="Section 3.3.1"/>.</t>
      <t indent="0" pn="section-appendix.b-3">If any of the currently registered COSE algorithms are considered, using this general format yields the same structure of 'sign_info_entry' defined in this document, thus ensuring backward compatibility.</t>
      <section anchor="sec-future-cose-algs-sign-info-entry" numbered="true" removeInRFC="false" toc="include" pn="section-appendix.b.1">
        <name slugifiedName="name-format-of-sign_info_entry">Format of 'sign_info_entry'</name>
        <t indent="0" pn="section-appendix.b.1-1">The format of each 'sign_info_entry' (see <xref target="sign-info" format="default" sectionFormat="of" derivedContent="Section 3.3.1"/>) is generalized as follows.</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-appendix.b.1-2">
          <li pn="section-appendix.b.1-2.1">
            <t indent="0" pn="section-appendix.b.1-2.1.1">'sign_parameters' includes N &gt;= 0 elements, each of which is a COSE capability of the signature algorithm indicated in 'sign_alg'.  </t>
            <t indent="0" pn="section-appendix.b.1-2.1.2">
In particular, 'sign_parameters' has the same format and value of the COSE capabilities array for the signature algorithm indicated in 'sign_alg', as specified for that algorithm in the "Capabilities" column of the "COSE Algorithms" registry <xref target="COSE.Algorithms" format="default" sectionFormat="of" derivedContent="COSE.Algorithms"/>.</t>
          </li>
          <li pn="section-appendix.b.1-2.2">
            <t indent="0" pn="section-appendix.b.1-2.2.1">'sign_key_parameters' is replaced by N elements 'sign_capab', each of which is a CBOR array.  </t>
            <t indent="0" pn="section-appendix.b.1-2.2.2">
The i-th 'sign_capab' array (i = 0, ..., N-1) is the array of COSE capabilities for the algorithm capability specified in 'sign_parameters'[i].  </t>
            <t indent="0" pn="section-appendix.b.1-2.2.3">
In particular, each 'sign_capab' array has the same format and value of the COSE capabilities array for the algorithm capability specified in 'sign_parameters'[i].  </t>
            <t indent="0" pn="section-appendix.b.1-2.2.4">
Such a COSE capabilities array is currently defined for the algorithm capability COSE key type in the "Capabilities" column of the "COSE Key Types" registry <xref target="COSE.Key.Types" format="default" sectionFormat="of" derivedContent="COSE.Key.Types"/>.</t>
          </li>
        </ul>
        <figure anchor="fig-sign-info-entry-general" align="left" suppress-title="false" pn="figure-38">
          <name slugifiedName="name-sign_info_entry-with-a-gene">'sign_info_entry' with a General Format</name>
          <sourcecode type="cddl" markers="false" pn="section-appendix.b.1-3.1">
sign_info_entry =
[
    id : gname / [+ gname],
    sign_alg : int / tstr,
    sign_parameters : [* alg_capab : any],
  * sign_capab : [* capab : any],
    cred_fmt : int / null
]

gname = tstr
</sourcecode>
        </figure>
      </section>
    </section>
    <section numbered="false" anchor="acknowledgments" removeInRFC="false" toc="include" pn="section-appendix.c">
      <name slugifiedName="name-acknowledgments">Acknowledgments</name>
      <t indent="0" pn="section-appendix.c-1">The following individuals were helpful in shaping this document: <contact fullname="Christian Amsüss"/>, <contact fullname="Carsten Bormann"/>, <contact fullname="Roman Danyliw"/>, <contact fullname="Martin Duke"/>, <contact fullname="Thomas Fossati"/>, <contact fullname="Vidhi Goel"/>, <contact fullname="Rikard Höglund"/>, <contact fullname="Ben Kaduk"/>, <contact fullname="Erik Kline"/>, <contact fullname="Warren Kumari"/>, <contact fullname="Watson Ladd"/>, <contact fullname="Daniel Migault"/>, <contact fullname="John Preuß Mattsson"/>, <contact fullname="Zaheduzzaman Sarker"/>, <contact fullname="Jim Schaad"/>, <contact fullname="Ludwig Seitz"/>, <contact fullname="Göran Selander"/>, <contact fullname="Cigdem Sengul"/>, <contact fullname="Dave Thaler"/>, <contact fullname="Henry Thompson"/>, <contact fullname="Peter van der Stok"/>, and <contact fullname="Paul Wouters"/>.</t>
      <t indent="0" pn="section-appendix.c-2">The work on this document has been partly supported by the Sweden's Innovation Agency 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.</t>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.d">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author initials="F." surname="Palombini" fullname="Francesca Palombini">
        <organization showOnFrontPage="true">Ericsson AB</organization>
        <address>
          <postal>
            <street>Torshamnsgatan 23</street>
            <city>Kista</city>
            <code>164 40</code>
            <country>Sweden</country>
          </postal>
          <email>francesca.palombini@ericsson.com</email>
        </address>
      </author>
      <author initials="M." surname="Tiloca" fullname="Marco Tiloca">
        <organization showOnFrontPage="true">RISE AB</organization>
        <address>
          <postal>
            <street>Isafjordsgatan 22</street>
            <city>Kista</city>
            <code>164 40</code>
            <country>Sweden</country>
          </postal>
          <email>marco.tiloca@ri.se</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
