]> RISE AB

Isafjordsgatan 22 Kista 164 40 Sweden marco.tiloca@ri.se

RISE AB

Isafjordsgatan 22 Kista 164 40 Sweden rikard.hoglund@ri.se

stokcons@kpnmail.nl

Ericsson AB

Torshamnsgatan 23 Kista 164 40 Sweden francesca.palombini@ericsson.com

Security ACE Working Group Internet-Draft Group communication for the Constrained Application Protocol (CoAP) can be secured using Group Object Security for Constrained RESTful Environments (Group OSCORE). A Group Manager is responsible for handling the joining of new group members, as well as for managing and distributing the group keying material. This document defines a RESTful admin interface at the Group Manager that allows an Administrator entity to create and delete OSCORE groups, as well as to retrieve and update their configuration. The Authentication and Authorization for Constrained Environments (ACE) framework is used to enforce authentication and authorization of the Administrator at the Group Manager. Protocol-specific transport profiles of ACE are used to achieve communication security, proof of possession, and server authentication. Discussion Venues Discussion of this document takes place on the Authentication and Authorization for Constrained Environments Working Group mailing list (ace@ietf.org), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction The Constrained Application Protocol (CoAP) can be used for group communication where messages are exchanged between members of a group, e.g., over IP multicast. Applications relying on CoAP can achieve end-to-end security at the application layer by using Object Security for Constrained RESTful Environments (OSCORE) , and especially Group OSCORE in group communication scenarios. When group communication for CoAP is protected with Group OSCORE, nodes are required to join the correct OSCORE group explicitly. To this end, a joining node interacts with a Group Manager (GM) entity responsible for that group, and retrieves the required keying material to securely communicate with other group members using Group OSCORE. specifies how nodes can join an OSCORE group through the respective Group Manager. That method builds on the ACE framework for Authentication and Authorization , ensuring a secure joining process as well as authentication and authorization of joining nodes (clients) at the Group Manager (resource server). In some deployments, the application running on the Group Manager may know when a new OSCORE group has to be created, how the group should be configured upon creation, and later on how the group should be updated or deleted, e.g., based on the current application state or pre-installed policies. In this case, the Group Manager application can create and configure OSCORE groups when needed, by using a local application interface. However, this requires the Group Manager to be application-specific, which in turn may lead to error-prone deployments and is not very flexible. In other deployments, a separate Administrator entity, such as a Commissioning Tool, is directly responsible for creating and configuring the OSCORE groups at a Group Manager, as well as for maintaining their configurations during their whole lifetime until their deletion. This allows the Group Manager to be agnostic of the specific applications using secure group communication. This document specifies a RESTful admin interface at the Group Manager, intended for an Administrator as a separate entity external to the Group Manager and its application. The interface allows the Administrator to create and delete OSCORE groups, as well as to specify and update their configuration. The ACE framework is used to ensure authentication and authorization of the Administrator (client) at the Group Manager (resource server). In order to achieve communication security, proof of possession, and server authentication, the Administrator and the Group Manager leverage protocol-specific transport profiles of ACE, such as . These include also possible forthcoming transport profiles that comply with the requirements in .

Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. Readers are expected to be familiar with the terms and concepts from the following specifications:

• CDDL , CBOR , and COSE .
• CoAP , also in group communication scenarios . These especially include the following concepts.
  • "application group", as a set of CoAP nodes that share a common set of resources.
  • "security group", as a set of CoAP nodes that share the same security material and use it to protect and verify exchanged messages.
• The security protocols OSCORE and Group OSCORE . These especially include the following concepts:
  • Group Manager, as the entity responsible for a set of OSCORE groups where communications among members are secured using Group OSCORE. An OSCORE group is used as a security group for one or many application groups.
  • Authentication credential, as the set of information associated with an entity, including that entity's public key and parameters associated with the public key. Examples of authentication credentials are CBOR Web Tokens (CWTs) and CWT Claims Sets (CCSs) , X.509 certificates , and C509 certificates .
• The ACE framework for Authentication and Authorization . The terminology for entities in the considered architecture is defined in OAuth 2.0 . In particular, this includes Client (C), Resource Server (RS), and Authorization Server (AS).
• The management of keying material for groups in ACE and specifically for OSCORE groups . These include the concept of group-membership resource hosted by the Group Manager that new members access to join the OSCORE group, and that current members can access to retrieve updated keying material.

Note that 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. The CoAP definition, which is "[a]n entity participating in the CoAP protocol" , is not used in this document. This document also refers to the following terminology:

• Administrator: entity responsible for creating, configuring, and deleting OSCORE groups at a Group Manager.
• Group name: stable and invariant name of an OSCORE group. The group name MUST be unique under the same Group Manager and MUST be consistent with the ABNF rule "segment = *pchar" defined in .
• Group-collection resource: a single-instance resource hosted by the Group Manager. An Administrator accesses a group-collection resource to retrieve a list of existing OSCORE groups or to create a new OSCORE group, under that Group Manager. When defining operations at the Group Manager and providing examples, this document uses /manage as the url-path of the group-collection resource; implementations can use a different url-path.
• Group-configuration resource: a resource hosted by the Group Manager and associated with an OSCORE group under that Group Manager. A group-configuration resource is identifiable with the invariant group name of the respective OSCORE group. An Administrator accesses a group-configuration resource to retrieve or change the configuration of the respective OSCORE group, or to delete that group. The url-path to a group-configuration resource has GROUPNAME as last segment, with GROUPNAME the invariant group name assigned upon its creation. Aligned with that, a group name has to be consistent with the semantics of URI path segments (see ). Building on the considered url-path of the group-collection resource, this document uses /manage/GROUPNAME as the url-path of a group-configuration resource; implementations are not required to use this same construct and can define their own instead.
• Admin resource: a group-collection resource or a group-configuration resource hosted by the Group Manager.
• Secure communication association: a security association established between any two of the Administrator, the AS, and the Group Manager and used for protecting their message exchanges. For example, depending on the transport profile of ACE used, this can rely on DTLS as per or on OSCORE as per .

Notations Interaction examples are provided in the CoRE Link Format and in CBOR . The examples in CBOR are expressed in CBOR extended diagnostic notation as defined in and ("diagnostic notation"). Diagnostic notation comments are often used to provide a textual representation of the numeric parameter names and values. In the CBOR diagnostic notation used in this document, constructs of the form e'SOME_NAME' are replaced by the value assigned to SOME_NAME in the CDDL model shown in of . For example, {e'group_name': "gp1", e'gp_enc_alg': 10} stands for {-13: "gp1", -4: 10}. Note to RFC Editor: Please delete the paragraph immediately preceding this note. Also, in the CBOR diagnostic notation used in this document, please replace the constructs of the form e'SOME_NAME' with the value assigned to SOME_NAME in the CDDL model shown in of . Finally, please delete this note.

Group Administration With reference to the ACE framework and the terminology defined in OAuth 2.0 :

• The Group Manager acts as Resource Server (RS). The Group Manager provides one single group-collection resource and one group-configuration resource per existing OSCORE group.
• The Administrator acts as Client (C) and requests to access the group-collection resource and group-configuration resources at the Group Manager.
• The Authorization Server (AS) authorizes the Administrator to access the group-collection resource and group-configuration resources at a Group Manager. Multiple Group Managers can be associated with the same AS. The authorized access for an Administrator can be limited to performing only a subset of operations, according to what is allowed by the authorization information in the access token issued to that Administrator (see and ). The AS can authorize multiple Administrators to access the group-collection resource and the (same) group-configuration resources at the Group Manager. The AS MAY issue access tokens to the Administrator for other purposes than accessing admin resources of registered Group Managers. For example, an access token can specify authorization information for joining OSCORE groups at a Group Manager (see ), possibly combined with authorization information for accessing admin resources at the same Group Manager (see ). Also, an AS can of course issue an access token that specifies authorization information unrelated to OSCORE groups, but instead pertaining to the access of other resources hosted by the Group Manager or other Resource Servers.

Managing OSCORE Groups shows the resources of a Group Manager that are available to an Administrator.

Admin Resources of a Group Manager

The Group Manager exports a single group-collection resource, with resource type "core.osc.gcoll" registered in of this document. The interface for the group-collection resource defined in allows the Administrator, if permitted, to:

• Retrieve a list of existing OSCORE groups.
• Retrieve a list of existing OSCORE groups matching with specified filter criteria.
• Create a new OSCORE group, specifying its invariant group name and, optionally, its configuration.

The Group Manager exports one group-configuration resource for each of its OSCORE groups. Each group-configuration resource has resource type "core.osc.gconf" registered in of this document, and is identified by the group name specified upon creating the OSCORE group. The interface for a group-configuration resource defined in allows the Administrator, if permitted, to:

• Retrieve the complete current configuration of the OSCORE group.
• Retrieve part of the current configuration of the OSCORE group, by applying filter criteria.
• Overwrite the current configuration of the OSCORE group.
• Selectively update only part of the current configuration of the OSCORE group.
• Delete the OSCORE group.

Collection Representation A collection of group configurations is represented as a CoRE Link Format document containing the list of corresponding group-configuration resources. Each group configuration is represented as a link, which specifies the URI of the group-configuration resource as link target, as well as the link target attribute 'rt' (Resource Type) with value "core.osc.gconf".

Discovery The Administrator can discover group-collection resources from a Resource Directory or from the resource /.well-known/core hosted by the Group Manager, by using the resource type "core.osc.gcoll". The Administrator can discover group-configuration resources for the group-collection resource as specified in and .

Format of Scope Building on the definition in considered in the ACE framework , scope denotes: the permissions that the Client (i.e., the Administrator) seeks to obtain from the AS for accessing resources at a Resource Server (i.e., the Group Manager); and the permissions that the AS actually issues to the Client following its request. This process is detailed in Sections and of . This section defines the exact format and encoding of scope to use, in order to express authorization information for the Administrator (see ). To this end, this document uses the Authorization Information Format (AIF) . In particular, it uses and extends the AIF data model AIF-OSCORE-GROUPCOMM defined in . The original definition of the data model AIF-OSCORE-GROUPCOMM specifies a scope as structured into scope entries, which express authorization information for users of an OSCORE group, i.e., actual group members or external signature verifiers. Hereafter, these are referred to as "user scope entries". This document extends the same AIF data model AIF-OSCORE-GROUPCOMM as defined below. In particular, it defines how the same scope can (also) include scope entries that express authorization information for Administrators of OSCORE groups. Hereafter, these are referred to as "admin scope entries", or simply as "scope entries" unless otherwise indicated. Like in the original definition of the data model AIF-OSCORE-GROUPCOMM, and with reference to the generic AIF model = [* [Toid, Tperm]] ]]> the value of the CBOR byte string used as scope encodes the CBOR array [* [Toid, Tperm]], where each [Toid, Tperm] element corresponds to one scope entry. Then, the following applies for each admin scope entry intended to express authorization information for an Administrator, as defined in this document.

• The object identifier ("Toid") is specialized as either of the following and specifies a group name pattern P for the admin scope entry.
  • Wildcard pattern: "Toid" is specialized as the CBOR simple value true (0xf5), specifying the wildcard pattern. That is, any group name matches with this group name pattern.
  • Literal pattern: "Toid" is specialized as a CBOR text string, whose value specifies an exact group name as a literal string. That is, only one specific group name expressed as a literal text string matches with this group name pattern. Consistent with the definition of group-configuration resource (see ), the specified group name has to be consistent with the semantics of URI path segments (see ).
  • Complex pattern: "Toid" is specialized as a tagged CBOR data item, specifying a more complex group name pattern with the semantics signaled by the CBOR tag. That is, multiple group names expressed as a literal text string match with this group name pattern. For example, and as typically expected, the data item can be a CBOR text string marked with the CBOR tag of number 21065. This indicates that the group name pattern specified as the value of the CBOR text string is a regular expression in the I-Regexp flavor . In case the AIF data model AIF-OSCORE-GROUPCOMM is used in a JSON payload, the semantics information conveyed by the CBOR tag can be equivalently conveyed, for example, in a nested JSON object. The AS and the Group Manager are expected to have agreed on commonly supported semantics for group name patterns. This can happen, for instance, as part of the registration process of the Group Manager at the AS.
• The permission set ("Tperm") is specialized as a CBOR unsigned integer with value Q. This specifies the permissions that the Administrator has with respect to performing operations on the admin resources at the Group Manager, as pertaining to any OSCORE group whose name matches with the group name pattern P specified by the object identifier ("Toid") of the same admin scope entry. The value Q is computed as follows.
  • Each permission in the permission set is converted into the corresponding numeric identifier X from the "Value" column of the "Group OSCORE Admin Permissions" registry defined in , for which this document defines the entries in .
  • The set of N numbers is converted into the single value Q, by taking two to the power of each numeric identifier X_1, X_2, ..., X_N, and then computing the inclusive OR of the binary representations of all the power values.
  In general, a single permission can be associated with multiple different operations that are possible to be performed when interacting with the Group Manager. For example, the "List" permission allows the Administrator to retrieve a list of group configurations (see ) or only a subset of that according to specified filter criteria (see ), by issuing a GET or FETCH request to the group-collection resource, respectively.

Numeric identifier of permissions on the admin resources at a Group Manager

Name	Value	Description
List	0	Retrieve list of group configurations
Create	1	Create new group configurations
Read	2	Retrieve group configurations
Write	3	Change group configurations
Delete	4	Delete group configurations

The following CDDL notation defines an admin scope entry that uses the data model AIF-OSCORE-GROUPCOMM and expresses a set of permissions from those in . oscore-gname = true / tstr / #6.(any) ; Group name pattern oscore-gperm = uint .bits admin-permissions admin-permissions = &( List: 0, Create: 1, Read: 2, Write: 3, Delete: 4 ) scope_entry = [oscore-gname, oscore-gperm] ]]> The following example in CBOR diagnostic notation shows a CBOR array including five scope entries as its elements. Future specifications that define new permissions on the admin resources at the Group Manager must register a corresponding numeric identifier in the "Group OSCORE Admin Permissions" registry defined in of this document. When using the scope format as defined in this section, the permission set ("Tperm") of each admin scope entry MUST include the "List" permission. It follows that, when expressing permissions for Administrators of OSCORE groups as defined in this document, an admin scope entry has the least significant bit of "Tperm" always set to 1. Therefore, an Administrator is always allowed to retrieve a list of existing group configurations. The exact elements included in the returned list are determined by the Group Manager, based on the group name patterns specified in the admin scope entries of the Administrator's access token, as well as on possible filter criteria specified in the request from the Administrator (see and ). Building on the above, the same single scope can include user scope entries as well as admin scope entries, whose specific format is defined in and earlier in this section, respectively. The two types of scope entries can be unambiguously distinguished by means of the least significant bit of their permission set "Tperm", which has value 0 for the user scope entries and 1 for the admin scope entries. The coexistence of user scope entries and admin scope entries within the same scope makes it possible to issue a single access token, in case the requesting Client wishes to be a user for some OSCORE groups and at the same time Administrator for some (other) OSCORE groups under the same Group Manager.

On Using Group Name Patterns Having the object identifier ("Toid") specialized as a pattern confers a number of advantages:

• When relying on wildcard patterns and complex patterns, the encoded scope can have a small size while allowing the Administrator to operate on large pools of group names.
• When relying on wildcard patterns and complex patterns, the Administrator and the AS do not need to know the exact group names for requesting and issuing an access token, respectively (see ). In turn, the Group Manager can effectively take the final decision about the name to assign to an OSCORE group when creating it (see ).

Getting Access to the Group Manager All communications between the involved entities (Administrator, Group Manager, Authorization Server) rely on CoAP, and they MUST occur and be secured in accordance with the protocol-specific transport profile of ACE used. In particular, communications between the Administrator and the Group Manager leverage protocol-specific transport profiles of ACE to achieve communication security, proof of possession, and server authentication. To this end, the AS may explicitly signal the specific transport profile to use, consistently with requirements and assumptions defined in the ACE framework . With reference to the AS, communications between the Administrator and the AS (/token endpoint) as well as between the Group Manager and the AS (/introspect endpoint) can be secured by different means, for instance using DTLS or OSCORE . Further details on how the AS secures communications (with the Administrator and the Group Manager) depend on the transport profile of ACE used, and are out of the scope of this document. In order to specify authorization information for Administrators, the format and encoding of scope defined in of this document MUST be used, for both the 'scope' claim in the access token and the 'scope' parameter in the Authorization Request and Authorization Response exchanged with the AS (see Sections and of ). If the 'scope' parameter in the Authorization Request includes scope entries whose "Toid" specifies a complex pattern (see ), then all such scope entries MUST adhere to the same pattern semantics. Also, in the 'scope' claim of the access token issued by the AS, that semantics MUST be used for all the scope entries that specify a complex pattern. Furthermore, the AS MAY use the extended format of scope defined in for the 'scope' claim of the access token. In such a case, the AS MUST use the CBOR tag with tag number TAG_NUMBER, associated with the CoAP Content-Format CF_ID for the media type "application/aif+cbor" registered in . Note to RFC Editor: In the previous paragraph, please replace "TAG_NUMBER" with the CBOR tag number computed as TN(ct) in , where ct is the ID assigned to the CoAP Content-Format CF_ID registered in . Then, please replace "CF_ID" with the ID assigned to that CoAP Content-Format. Finally, please delete this paragraph. This indicates that the binary encoded scope, as conveying the actual access control information, follows the scope semantics of the AIF data model AIF-OSCORE-GROUPCOMM defined in and extended as per of this document. In order to get access to the Group Manager for managing OSCORE groups, an Administrator performs the following steps:

1. The Administrator requests an access token from the AS, in order to access the group-collection and group-configuration resources on the Group Manager. To this end, the Administrator sends to the AS an Authorization Request as defined in . The Administrator will start or continue using a secure communication association with the Group Manager, according to the response from the AS and the transport profile of ACE used.
2. The AS processes the Authorization Request as defined in , especially verifying that the Administrator is authorized to obtain the requested permissions, or possibly a subset of those. The AS specifies the information on the authorization granted to the Administrator as the value of the 'scope' claim to include in the access token, in accordance with the scope format specified in . It is implementation specific which particular approach the AS takes to evaluate the requested permissions against the access policies pertaining to the Administrator for the Group Manager in question. provides an example of such an approach that the AS can use. The AS MUST include the 'scope' parameter in the Authorization Response defined in , when the value included in the access token differs from the one specified by the Administrator in the Authorization Request. In such a case, scope specifies the set of permissions that the Administrator actually has been granted with respect to performing operations at the Group Manager, encoded as specified in . If the 'scope' parameter in the Authorization Request includes scope entries whose "Toid" specifies a complex pattern and any of the following conditions holds, then the AS MUST reply with a 4.00 (Bad Request) error response (see ). The 'error_description' parameter carried out in the response payload MUST specify the CBOR value 1 (invalid_scope).
   • The "Toid" of the different scope entries that specify a complex pattern do not all adhere to the same pattern semantics.
   • The "Toid" of the different scope entries that specify a complex pattern adhere to the same pattern semantics, but this is not supported by the AS or by the Group Manager.
   Finally, as discussed in , the authorization information included in the Authorization Request or specified by the AS might also include permissions for the same Client as a user of an OSCORE group, i.e., as an actual group member or an external signature verifier. As per , such authorization information is expressed by "user scope entries", whose format and processing is specified in .
3. The Administrator transfers authentication and authorization information to the Group Manager through the uploading of the access token, according to the profile of ACE used, such as and . After that, the Administrator must have a secure communication association established with the Group Manager, before performing any administrative operation on that Group Manager. Possible ways to provide secure communication are DTLS and OSCORE . The Administrator and the Group Manager maintain the secure association, to support possible future communications.
4. Consistently with what is allowed by the authorization information in the access token, the Administrator performs administrative operations at the Group Manager, as described in . These include retrieving a list of existing OSCORE groups, creating new OSCORE groups, retrieving and changing OSCORE group configurations, and removing OSCORE groups. Messages exchanged among the Administrator and the Group Manager are specified in . Upon receiving a request from the Administrator targeting the group-collection resource or a group-configuration resource, the Group Manager MUST check that it is storing a valid access token for that Administrator, and that the access token includes at least one admin scope entry. If this is not the case, the Group Manager MUST reply with a 4.01 (Unauthorized) error response. If the request targets the group-collection resource for creating a new group with name GROUPNAME or it targets the group-configuration resource associated with an existing group with name GROUPNAME, then the Group Manager MUST check that it is storing a valid access token for that Administrator, such that the 'scope' claim specified in the access token: i) expresses authorization information through scope entries as defined in ; and ii) specifically includes a scope entry where:
   • The group name GROUPNAME matches with the pattern specified by the "Toid" of the scope entry; and
   • The permission set specified by the "Tperm" of the scope entry allows the Administrator to perform the requested administrative operation on the targeted resource.
   Note that the checks defined above only consider scope entries expressing permissions for administrative operations, namely "admin scope entries" as defined in , while the alternative "user scope entries" defined in are not considered. Further detailed checks to perform are defined separately for each operation at the Group Manager, when specified in . In case the Group Manager stores a valid access token but the verifications above fail, the Group Manager MUST reply with a 4.03 (Forbidden) error response. This response MAY be an AS Request Creation Hints, as defined in , in which case the Content-Format MUST be set to "application/ace+cbor" (i.e., ID: 19). If the request is not formatted correctly (e.g., required fields are not present or are not encoded as expected), the Group Manager MUST reply with a 4.00 (Bad Request) error response.

Multiple Administrators for the Same OSCORE Group It is possible that multiple Administrators are authorized to operate on the same Group Manager in the interest of the same OSCORE group, while also taking different responsibilities. For example, in addition to a "main" primary Administrator responsible for an OSCORE group at the Group Manager, it is also possible to have "assistant" secondary Administrators that are effectively authorized to perform some operations on the same OSCORE group. With respect to the main Administrator, such assistant Administrators are expected to have fewer permissions to perform administrative operations related to the OSCORE group at the Group Manager. For example, they may not be authorized to create an OSCORE group, or to delete an OSCORE group and its configuration. In case the main Administrator of an OSCORE group is dismissed or relinquishes its role, one of the assistant Administrators can be "promoted" and become main Administrator for that OSCORE group. Practically, this requires that the access policies associated with the promoted Administrator are updated accordingly at the Authorization Server. Also, the promoted Administrator has to request from the Authorization Server a new access token that has to be uploaded to the Group Manager. If allowed by the transport profile of ACE used, this process can efficiently enforce a dynamic update of access rights, thus preserving the current secure association between the promoted Administrator and the Group Manager. If an Administrator is not sure about being the only Administrator responsible for an OSCORE group, then it is RECOMMENDED that the Administrator regularly obtains a recent representation of the group-configuration resource associated with the OSCORE group before overwriting (see ), updating (see ), or deleting (see ) the group configuration. This can be achieved in the following ways.

• The Administrator performs a regular polling of the group configuration, by sending a GET request to the corresponding group-configuration resource (see ).
• If the group-configuration resource associated with the OSCORE group is Observable, then the Administrator subscribes to that resource by using CoAP Observe . The Observation request is a GET request sent to the group-configuration resource (see ). In such a case, the Group Manager will also send a 4.04 (Not Found) response in case another Administrator deletes the group-configuration resource, as a result of deleting the associated OSCORE group and its configuration.

If the Administrator gains knowledge that the group configuration has changed compared to the latest known representation, then the Administrator might hold the execution of writing or deletion operation on the group-configuration resource, and first attempt checking with other Administrators responsible for the same OSCORE group about the changes that they have made. In order to avoid race conditions due to possible concurrent updates of the group-configuration resource (i.e., the "lost update" problem), the Group Manager can include the ETag Option in the responses to the GET requests sent to the group-configuration resource (see ). Then, when sending to the Group Manager a request for overwriting or updating the group-configuration resource, the Administrator includes an If-Match Option with value the most recent ETag that the Administrator knows for that resource (see ).

Group Configurations A group configuration consists of information related to an OSCORE group, as organized into configuration parameters and status parameters. In particular, configuration parameters specify how members of the OSCORE group use the Group OSCORE protocol to protect their communications (e.g., by using which algorithms). Instead, status parameters specify information concerning the management of the OSCORE group and its current setting at the Group Manager (e.g., for handling identifiers and the joining of group members).

Group Configuration Representation The group configuration representation is a CBOR map, which includes the configuration parameters specified in and the status parameters specified in . Unless stated otherwise, these parameters are defined in this document and their CBOR abbreviations are defined in .

Configuration Parameters The CBOR map includes the following configuration parameters:

• 'hkdf', which specifies the HKDF Algorithm used in the OSCORE group (see ), encoded as a CBOR text string or a CBOR integer. The HKDF Algorithm is specified by the HMAC Algorithm value. For example, the HKDF Algorithm HKDF SHA-256 is specified as the HMAC Algorithm HMAC 256/256. This parameter can take the same values as the 'hkdf' parameter of the Group_OSCORE_Input_Material object, defined in .
• 'cred_fmt', which specifies the Authentication Credential Format used in the OSCORE group (see ), encoded as a CBOR integer. This parameter can take the same values as the 'cred_fmt' parameter of the Group_OSCORE_Input_Material object, defined in .
• 'group_mode', encoded as a CBOR simple value. Its value is true (0xf5) if the OSCORE group uses the group mode of Group OSCORE (see ), or false (0xf4) otherwise.
• 'gp_enc_alg', which is formatted as follows. If the configuration parameter 'group_mode' has value false (0xf4), this parameter has as value the CBOR simple value null (0xf6). Otherwise, this parameter specifies the Group Encryption Algorithm used in the OSCORE group to encrypt messages protected with the group mode (see ), encoded as a CBOR text string or a CBOR integer. This parameter can take the same values as the 'gp_enc_alg' parameter of the Group_OSCORE_Input_Material object, defined in .
• 'sign_alg', which is formatted as follows. If the configuration parameter 'group_mode' has value false (0xf4), this parameter has as value the CBOR simple value null (0xf6). Otherwise, this parameter specifies the Signature Algorithm used in the OSCORE group (see ), encoded as a CBOR text string or a CBOR integer. This parameter can take the same values as the 'sign_alg' parameter of the Group_OSCORE_Input_Material object, defined in .
• 'sign_params', which is formatted as follows. If the configuration parameter 'group_mode' has value false (0xf4), this parameter has as value the CBOR simple value null (0xf6). Otherwise, this parameter specifies the additional parameters for the Signature Algorithm used in the OSCORE group, encoded as a CBOR array. This parameter can take the same values as the 'sign_params' parameter of the Group_OSCORE_Input_Material object, defined in .
• 'pairwise_mode', encoded as a CBOR simple value. Its value is true (0xf5) if the OSCORE group uses the pairwise mode of Group OSCORE (see ), or false (0xf4) otherwise.
• 'alg', which is formatted as follows. If the configuration parameter 'pairwise_mode' has value false (0xf4), this parameter has as value the CBOR simple value null (0xf6). Otherwise, this parameter specifies the AEAD Algorithm used in the OSCORE group to encrypt messages protected with the pairwise mode (see ), encoded as a CBOR text string or a CBOR integer. This parameter can take the same values as the 'alg' parameter of the Group_OSCORE_Input_Material object, defined in .
• 'ecdh_alg', which is formatted as follows. If the configuration parameter 'pairwise_mode' has value false (0xf4), this parameter has as value the CBOR simple value null (0xf6). Otherwise, this parameter specifies the Pairwise Key Agreement Algorithm used in the OSCORE group (see ), encoded as a CBOR text string or a CBOR integer. This parameter can take the same values as the 'ecdh_alg' parameter of the Group_OSCORE_Input_Material object, defined in .
• 'ecdh_params', which is formatted as follows. If the configuration parameter 'pairwise_mode' has value false (0xf4), this parameter has as value the CBOR simple value null (0xf6). Otherwise, this parameter specifies the parameters for the Pairwise Key Agreement Algorithm used in the OSCORE group, encoded as a CBOR array. This parameter can take the same values as the 'ecdh_params' parameter of the Group_OSCORE_Input_Material object, defined in .
• 'det_req', encoded as a CBOR simple value. Its value is true (0xf5) if the OSCORE group uses deterministic requests (see ), or false (0xf4) otherwise. This parameter can be present only if both the configuration parameters 'group_mode' and 'pairwise_mode' have value true (0xf5), and it MUST NOT be present otherwise.
• 'det_hash_alg', encoded as a CBOR integer or text string. If present, this parameter specifies the Hash Algorithm used in the OSCORE group when producing deterministic requests (see ). This parameter takes values from the "Value" column of the "COSE Algorithms" Registry . This parameter MUST NOT be present if the configuration parameter 'det_req' is not present or if it is present with value false (0xf4). If the configuration parameter 'det_req' is present with value true (0xf5) and 'det_hash_alg' is not present, the choice of the Hash Algorithm to use when producing deterministic requests is left to the Group Manager.

Status Parameters The CBOR map includes the following status parameters:

• 'rt', which specifies the resource type "core.osc.gconf" associated with group-configuration resources, encoded as a CBOR text string.
• 'active', which specifies whether the OSCORE group is currently active, encoded as the CBOR simple value true (0xf5) of false (0xf4).
• 'group_name', which specifies the group name of the OSCORE group encoded as a CBOR text string.
• 'group_description', which specifies either a human-readable description of the OSCORE group encoded as a CBOR text string, or the CBOR simple value null (0xf6) if no description is specified.
• 'ace_groupcomm_profile', defined in , with value "coap_group_oscore_app" registered in , encoded as a CBOR integer.
• 'max_stale_sets', encoding a CBOR unsigned integer with value strictly greater than 1. With reference to , this parameter specifies N, i.e., the maximum number of sets of stale OSCORE Sender IDs that the Group Manager stores for the group.
• 'exp', defined in .
• 'gid_reuse', encoding the CBOR simple value true (0xf5) if, upon rekeying the OSCORE group, the Group Manager can reassign the values of the OSCORE Group ID used as OSCORE ID Context, as per and . Otherwise, this parameter encodes the CBOR simple value false (0xf4).
• 'app_groups', with value a list of names of application groups, encoded as a CBOR array. Each element of the array is a CBOR text string, specifying the name of an application group using the OSCORE group as security group (see ).
• 'joining_uri', with value the URI of the group-membership resource for joining the newly created OSCORE group as per , encoded as a CBOR text string.
• 'group_policies', defined in , and consistent with the format and content defined in .
• 'as_uri', with value the URI of the Authorization Server associated with the Group Manager for the OSCORE group, encoded as a CBOR text string. Candidate group members will have to obtain an access token from that Authorization Server, before starting the joining process with the Group Manager to join the OSCORE group (see Sections and of ).

Default Values This section defines the default values that the Group Manager refers to for the configuration and status parameters. In particular, and define the default values that are RECOMMENDED to use for the configuration and status parameters, respectively. Exceptionally, the Group Manager MAY choose different default values instead of those recommended in and . A possible reason is to ensure that each of those are consistent with what the Group Manager supports, e.g., in terms of signature algorithm and format of authentication credentials used in the OSCORE group. This ensures that the Group Manager is able to perform the operations defined in , as to its interactions with joining nodes and current group members for an OSCORE group (see ).

Configuration Parameters For each of the configuration parameters listed below, the Group Manager uses the following pre-configured default value, if that parameter is not specified by the Administrator:

• 'group_mode' - The Group Manager SHOULD use the CBOR simple value true (0xf5).
• 'pairwise_mode' - The Group Manager SHOULD use the CBOR simple value true (0xf5).
• 'gp_enc_alg', 'sign_alg', and 'sign_params' - If the value of 'group_mode' is determined to be the CBOR simple value true (0xf5), the Group Manager SHOULD use the same default values defined in for the parameters 'gp_enc_alg', 'sign_alg', and 'sign_params' specified in that document, respectively.
• 'alg', 'ecdh_alg', and 'ecdh_params' - If the value of 'pairwise_mode' is determined to be the CBOR simple value true (0xf5), the Group Manager SHOULD use the same default values defined in for the parameters 'alg', 'ecdh_alg', and 'ecdh_params' specified in that document, respectively.
• 'det_req' - If the value of both 'group_mode' and 'pairwise_mode' is determined to be the CBOR simple value true (0xf5), the Group Manager SHOULD add the 'det_req' parameter to the group configuration and SHOULD set its value to the CBOR simple value false (0xf4).
• 'det_hash_alg' - If the value of 'det_req' is determined to be the CBOR simple value true (0xf5), the Group Manager SHOULD add the 'det_hash_alg' parameter to the group configuration and SHOULD set its value to -16 (COSE algorithm encoding for SHA-256).

For any other configuration parameter, the Group Manager SHOULD use the same default values defined in for the parameter with the same name specified in that document.

Status Parameters For each of the status parameters listed below, the Group Manager uses the following pre-configured default value, if that parameter is not specified by the Administrator:

• 'active' - The Group Manager SHOULD use the CBOR simple value false (0xf4).
• 'group_description' - The Group Manager SHOULD use the CBOR simple value null (0xf6).
• 'max_stale_sets' - The Group Manager SHOULD use the CBOR unsigned integer with value 3, consistent with what is defined in .
• 'gid_reuse' - The Group Manager SHOULD use the CBOR simple value false (0xf4).
• 'app_groups' - The Group Manager SHOULD use the empty CBOR array.
• 'group_policies' - The Group Manager SHOULD use the default values defined in .

Interactions with the Group Manager This section describes the operations that are possible to perform on the group-collection resource and the group-configuration resources at the Group Manager. For each operation, it is defined whether that operation is required or optional to support for the Group Manager. If the Group Manager supports an operation, then the Group Manager must be able to correctly handle authorized and valid requests sent by the Administrator to carry out that operation. If the Group Manager receives an authorized and valid request to perform an operation that it does not support (i.e., the CoAP method used in the request is not supported by the targeted resource), then the Group Manager replies with a 4.05 (Method Not Allowed) response (see ). When checking the scope claim of a stored access token to verify that any of the requests defined in the following is authorized, the Group Manager only considers scope entries expressing permissions for administrative operations, namely "admin scope entries" as defined in . The alternative "user scope entries" defined in are not considered. That is, when handling any of the requests for administrative operations defined in the following, the Group Manager ignores possible "user scope entries" specified in the scope of a stored access token. Upon receiving from the Administrator a POST request to the group-collection resource or a request to a group-configuration resource, the Group Manager performs the following authorization checks, consistently with what is defined at Step 4 of :

• The Group Manager MUST check whether the group name TARGETNAME pertaining to the request matches with the group name pattern specified in any scope entry of the 'scope' claim in the stored access token for the Administrator.
• In case of a positive match, the Group Manager MUST check whether the permission set in the found scope entry specifies the permission PERMISSION required to perform the requested administrative operation.

If there are no matching scope entries specifying the permission PERMISSION, the Group Manager MUST reply with a 4.03 (Forbidden) error response. Further details on TARGETNAME and PERMISSION are defined separately for each operation at the Group Manager. The Content-Format "application/ace-groupcomm+cbor" defined in is used in requests including a payload and in successful responses including a payload, except for successful responses sent in reply to GET and FETCH requests targeting the group-collection resource (for which the Content-Format "application/link-format" is used). Furthermore, the CBOR abbreviations defined in of this document MUST be used when specifying the corresponding configuration and status parameters.

Retrieve a List of Group Configurations This operation MUST be supported by the Group Manager. The Administrator can send a GET request to the group-collection resource, in order to retrieve a list of the existing OSCORE groups at the Group Manager. This list is returned as a list of links to the corresponding group-configuration resources. In particular, a successful 2.05 (Content) response MUST have Content-Format set to "application/link-format" and its payload specifies the list of links in the CoRE Link Format . The Group Manager MUST prepare the list L to include in the response as follows. For each group-configuration resource R:

1. The Group Manager considers the group name GROUPNAME of the OSCORE group associated with R.
2. The Group Manager retrieves the stored access token for the Administrator. Then, it checks whether GROUPNAME matches with the group name pattern specified in any scope entry of the 'scope' claim in the access token.
3. The link to the group-configuration resource R is added to the list L only in case of a positive match.

An example of message exchange is shown below. 0.01 GET Uri-Path: "manage" <= 2.05 Content Content-Format: 40 (application/link-format) Payload: ;rt="core.osc.gconf", ;rt="core.osc.gconf", ;rt="core.osc.gconf" ]]>

Retrieve a List of Group Configurations by Filters This operation MUST be supported by the Group Manager. The Administrator can send a FETCH request to the group-collection resource, in order to retrieve a list of the existing OSCORE groups that fully match a set of specified filter criteria. This list is returned as a list of links to the corresponding group-configuration resources. In particular, the request MUST have Content-Format set to "application/ace-groupcomm+cbor", while a successful 2.05 (Content) response MUST have Content-Format set to "application/link-format" and its payload specifies the list of links in the CoRE Link Format . The request payload is a CBOR map, whose entries specify the filter criteria. The possible entries of the CBOR map are specified in . Entry values are the ones admitted for the corresponding labels in the POST request for creating a group configuration (see ), with the exception that the 'group_name' parameter (if present) can also be encoded as a tagged CBOR data item, specifying a group name pattern with the semantics signaled by the CBOR tag. In such a case, the 'group_name' parameter expresses a group name pattern in the same way as a complex pattern Toid does in a scope entry (see ). In particular, the filter criterion is satisfied by any group name that matches with the group name pattern specified by the 'group_name' parameter in the payload of the FETCH request. The Group Manager MUST prepare the list L to include in the response as follows:

1. The Group Manager prepares a preliminary version of the list L, as specified in for the processing of a GET request to the group-collection resource.
2. The Group Manager applies the filter criteria specified in the FETCH request to the list L from the previous step. The result is the list L to include in the response.

An example of message exchange is shown below. In particular, the following is assumed:

• The Group Manager hosts three group-configuration resources, for the OSCORE groups with names "gp1", "gp2", and "gp3".
• All the OSCORE groups use the group mode of Group OSCORE, the AEAD Algorithm AES-CCM-16-64-128 (COSE algorithm encoding: 10), and the HKDF Algorithm HKDF SHA-256 (specified as the HMAC Algorithm HMAC 256/256, COSE algorithm encoding: 5).
• The OSCORE groups "gp1" and "gp3" use the Signature Algorithm EdDSA (COSE algorithm encoding: -8), while the OSCORE group "gp2" uses the Signature Algorithm ES256 (COSE algorithm encoding: -7).

0.05 FETCH Uri-Path: "manage" Content-Format: 261 (application/ace-groupcomm+cbor) Payload: { e'group_mode': true, e'gp_enc_alg': 10 / AES-CCM-16-64-128 /, e'sign_alg': -8 / EdDSA /, e'hkdf': 5 / HMAC with SHA-256 / } <= 2.05 Content Content-Format: 40 (application/link-format) Payload: ;rt="core.osc.gconf", ;rt="core.osc.gconf" ]]> The following, additional example considers a request payload that uses both configuration parameters and status parameters as filter criteria. In particular, the following is assumed:

• In the URI of every group-configuration resource, the path component is /manage/GROUPNAME, where GROUPNAME is the group name of the associated OSCORE group.
• The Group Manager hosts four group-configuration resources, for the OSCORE groups with names "gp4", "gp5", "gp6", and "foo". All the OSCORE groups use the AEAD Algorithm AES-CCM-16-64-128 (COSE algorithm encoding: 10). Also, all the OSCORE groups are currently active, except for "gp6".

0.05 FETCH Uri-Path: "manage" Content-Format: 261 (application/ace-groupcomm+cbor) Payload: { e'gp_enc_alg': 10 / AES-CCM-16-64-128 /, e'group_name': 21065("gp[0-9]*"), e'active': true } <= 2.05 Content Content-Format: 40 (application/link-format) Payload: ;rt="core.osc.gconf", ;rt="core.osc.gconf" ]]>

Create a New Group Configuration This operation MUST be supported by the Group Manager. The Administrator can send a POST request to the group-collection resource, in order to create a new OSCORE group at the Group Manager. In particular, the request MUST have Content-Format set to "application/ace-groupcomm+cbor". The request MUST specify the intended group name GROUPNAME and MAY specify the intended group description together with pieces of information concerning the group configuration. The request payload is a CBOR map, whose possible entries are specified in . In particular:

• The payload MAY include any of the configuration parameters defined in .
• The payload MUST include the status parameter 'group_name' defined in and specifying the intended group name encoded as a CBOR text string. As defined later in this section, the group name specified in this parameter is simply a suggestion to the Group Manager, which makes the final decision about the name to assign to the new group.
• The payload MAY include any of the status parameters 'active', 'group_description', 'max_stale_sets', 'exp', 'gid_reuse', 'app_groups', 'group_policies', and 'as_uri' defined in .
• The payload MUST NOT include any of the status parameters 'rt', 'ace_groupcomm_profile', and 'joining_uri' defined in .

When performing the authorization checks, the Group Manager uses the value of the 'group_name' parameter from the request as TARGETNAME, and "Create" as PERMISSION. If the group configuration to be created would include parameter values that prevent the Group Manager from performing the operations defined in (e.g., due to the Group Manager not supporting a format of authentication credentials), the Group Manager MUST reply with a 5.03 (Service Unavailable) response. The response MUST have Content-Format set to "application/concise-problem-details+cbor" and is formatted as defined in . Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' field MUST be set to 12 ("Unsupported group configuration") and the 'detail' field SHOULD be included in order to provide additional context. Note to RFC Editor: Please make sure that "application/concise-problem-details+cbor" is on one line (no line wrapping), on every occurrence throughout the document. Then, please delete this note. Otherwise, if any of the following occurs, the Group Manager MUST reply with a 4.00 (Bad Request) response.

• Any of the received parameters is not recognized, or not valid, or not consistent with respect to other related parameters. In particular, the value of the status parameter 'exp' (if present) is not valid if the indicated expiration date is not in the future.
• The Group Manager does not trust or deem acceptable the Authorization Server with URI specified in the 'as_uri' parameter, and it has no alternative Authorization Server to consider for the OSCORE group to create.

After a successful processing of the POST request, the Group Manager performs the following actions.

1. The Group Manager selects the name to actually assign to the new OSCORE group. If the 'group_name' parameter specifies the group name of an already existing OSCORE group, the Group Manager MUST try to determine an alternative name for the new OSCORE group to create. In general, the final decision about the name assigned to the new OSCORE group is always of the Group Manager, which may have more constraints than the Administrator can be aware of, possibly beyond the availability of suggested names. For example, the Group Manager may specifically want to use a randomized character string as the name of a newly created group. If the Group Manager has selected a name GROUPNAME different from the name GROUPNAME* indicated in the 'group_name' parameter of the request, then the following conditions MUST hold.
   • The chosen name GROUPNAME is available to assign; and
   • With reference to the 'scope' claim in the stored access token for the Administrator, let us define PERM* as the union of the permission sets associated with the scope entries such that GROUPNAME* matches with the specified group name pattern. Also, let us define PERM as the union of the permission sets associated with the scope entries such that GROUPNAME matches with the specified group name pattern. Then, PERM and PERM* MUST be equal.
   If the Group Manager does not manage to determine a group name for which both the above conditions hold, the Group Manager MUST reply with a 5.03 (Service Unavailable) response. The response MUST have Content-Format set to "application/concise-problem-details+cbor" and is formatted as defined in . Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' field MUST be set to 11 ("Unable to determine a group name").
2. If the previous step has succeeded, the Group Manager creates a new group-configuration resource accessible to the Administrator at /manage/GROUPNAME, where GROUPNAME is the final name given to the OSCORE group, as either the one indicated in the 'group_name' parameter of the request and confirmed by the Group Manager, or the alternative one that has been determined and uniquely assigned by the Group Manager. The group-collection resource is also updated accordingly. The operation of creating the new group-configuration resource and accordingly updating the group-collection resource MUST be atomic. That is, until the request processing fails, or the group-configuration resource is fully created and the values of its parameters are set, the following applies.
   • The group-configuration resource MUST NOT be accessible through other operations.
   • The group-collection resource MUST NOT be updated to reflect the presence of the new group-configuration resource.
   When the group-collection resource is eventually updated to reflect the presence of the new group-configuration resource, this update MUST NOT be interrupted by other updates to the group-collection resource due to the creation or deletion of group-configuration resources. In the newly created group-configuration resource, the value of the status parameter 'rt' is set to "core.osc.gconf". The values of other parameters specified in the request are used as group configuration information for the newly created OSCORE group. If the request specifies the 'gid_reuse' parameter encoding the CBOR simple value true (0xf5) and the Group Manager does not support the reassignment of OSCORE Group ID values (see and ), then the Group Manager sets the value of the 'gid_reuse' status parameter in the group-configuration resource to the CBOR simple value false (0xf4). For each parameter not specified in the POST request, the Group Manager refers to default values as specified in .
3. The Group Manager creates a new group-membership resource accessible at /ace-group/GROUPNAME to nodes that want to join the OSCORE group, as specified in . Note that such group membership-resource comprises a number of sub-resources intended to current group members, as defined in and . From then on, the Group Manager will rely on the current group configuration to build the Join Response message defined in , when handling the joining of a new group member. Furthermore, the Group Manager generates the following pieces of information and assigns them to the newly created OSCORE group:
   • The OSCORE Master Secret.
   • The OSCORE Master Salt (optionally).
   • The Group ID, used as OSCORE ID Context, which MUST be unique within the set of OSCORE groups under the Group Manager.
4. The Group Manager replies to the Administrator with a 2.01 (Created) response, which MUST have Content-Format set to "application/ace-groupcomm+cbor". One or more Location-Path options MUST be included in the response, indicating the location of the just created group-configuration resource. The response MUST NOT include a Location-Query option. The response payload is a CBOR map, whose possible entries are specified in . In particular, the following applies. The response payload specifies the parameters 'group_name', 'joining_uri', and 'as_uri' from the status parameters of the newly created OSCORE group (see ), as detailed below.
   • 'group_name', specifying the group name of the OSCORE group. This value can be different from the group name specified by the Administrator in the POST request, and it reflects the final choice of the Group Manager, as the value of the 'group_name' status parameter for the OSCORE group. This parameter MUST be included.
   • 'joining_uri', specifying the URI of the group-membership resource for joining the newly created OSCORE group. This parameter MUST be included.
   • 'as_uri', specifying the URI of the Authorization Server associated with the Group Manager for the newly created OSCORE group. This parameter MUST be included. Its value can be different from the URI possibly specified by the Administrator in the POST request, and it reflects the final choice of the Group Manager, as the value of the 'as_uri' status parameter for the OSCORE group.
   If the POST request specified the 'gid_reuse' parameter encoding the CBOR simple value true (0xf5) but the Group Manager has set the value of the 'gid_reuse' status parameter in the group-configuration resource to the CBOR simple value false (0xf4), then the response payload MUST also include the 'gid_reuse' parameter encoding the CBOR simple value false (0xf4). If the POST request did not specify certain parameters and the Group Manager used default values different from the ones recommended in and , then the response payload MUST also include those parameters, specifying the values chosen by the Group Manager for the current group configuration.
5. The Group Manager can register the link to the group-membership resource with URI specified in 'joining_uri' to a Resource Directory , e.g., by using the approach described in . The Group Manager considers the current group configuration when specifying additional information for the link to register. It is also possible that the Administrator performs the registration in the Resource Directory on behalf of the Group Manager, acting as Commissioning Tool. The Administrator considers the following when specifying additional information for the link to register.
   • The name of the OSCORE group MUST take the value specified in the 'group_name' parameter from the 2.01 (Created) response.
   • The names of the application groups using the OSCORE group MUST take the values possibly specified by the elements of the 'app_groups' parameter in the POST request.
   • If also registering a related link to the Authorization Server associated with the OSCORE group, the related link MUST have as link target the URI specified in the 'as_uri' parameter from the 2.01 (Created) response.
   • As to every other information element describing the current group configuration, the following applies.
   • If a certain parameter was specified in the POST request, the Administrator MUST use either the value specified in the 2.01 (Created) response, if the Group Manager specified one, or the value specified in the POST request otherwise.
   • If a certain parameter was not specified in the POST request, the Administrator MUST use either the value specified in the 2.01 (Created) response, if the Group Manager specified one, or the corresponding default value recommended in or otherwise.
   Note that, compared to the Group Manager, the Administrator is less likely to remain closely aligned with possible changes and updates that would require a prompt update to the registration in the Resource Directory. This applies especially to the address of the Group Manager, as well as the URI of the group-membership resource or of the Authorization Server associated with the Group Manager. Therefore, it is RECOMMENDED that registrations of links to group-membership resources in the Resource Directory are made (and possibly updated) directly by the Group Manager, rather than by the Administrator.

An example of message exchange is shown below. 0.02 POST Uri-Path: "manage" Content-Format: 261 (application/ace-groupcomm+cbor) Payload: { e'gp_enc_alg': 10 / AES-CCM-16-64-128 /, e'hkdf': 5 / HMAC with SHA-256 /, e'pairwise_mode': true, e'active': true, e'group_name': "gp4", e'group_description': "rooms 1 and 2", e'app_groups': ["room1", "room2"], e'as_uri': "coap://as.example.com/token" } <= 2.01 Created Location-Path: "manage" Location-Path: "gp4" Content-Format: 261 (application/ace-groupcomm+cbor) Payload: { e'group_name': "gp4", e'joining_uri': "coap://[2001:db8::ab]/ace-group/gp4/", e'as_uri': "coap://as.example.com/token" } ]]>

Retrieve a Group Configuration This operation MUST be supported by the Group Manager. The Administrator can send a GET request to the group-configuration resource /manage/GROUPNAME associated with an OSCORE group with group name GROUPNAME, in order to retrieve the complete current configuration of that group. When performing the authorization checks, the Group Manager uses GROUPNAME as TARGETNAME, and "Read" as PERMISSION. After a successful processing of the GET request, the Group Manager replies to the Administrator with a 2.05 (Content) response, which MUST have Content-Format set to "application/ace-groupcomm+cbor". The response payload is a CBOR map, whose possible entries are specified in . In particular, the response has as payload the representation of the group configuration as specified in . The exact content of the payload reflects the current configuration of the OSCORE group. This includes both configuration parameters and status parameters. An example of message exchange is shown below. 0.01 GET Uri-Path: "manage" Uri-Path: "gp4" <= 2.05 Content Content-Format: 261 (application/ace-groupcomm+cbor) Payload: { e'hkdf': 5 / HMAC with SHA-256 /, e'cred_fmt': 33 / x5chain /, e'group_mode': true, e'gp_enc_alg': 10 / AES-CCM-16-64-128 /, e'sign_alg': -8 / EdDSA /, e'sign_params': [[1], [1, 6]] / [[OKP], [OKP, Ed25519]] /, e'pairwise_mode': true, e'alg': 10 / AES-CCM-16-64-128 /, e'ecdh_alg': -27 / ECDH-SS-HKDF-256 /, e'ecdh_params': [[1], [1, 4]] / [[OKP], [OKP, X25519]] /, e'det_req': false, e'rt': "core.osc.gconf", e'active': true, e'group_name': "gp4", e'group_description': "rooms 1 and 2", / ace_groupcomm_profile / 10: e'coap_group_oscore_app', e'max_stale_sets': 3, / exp / 11: 1360289224, e'gid_reuse': false, e'app_groups': ["room1", "room2"], e'joining_uri': "coap://[2001:db8::ab]/ace-group/gp4/", e'as_uri': "coap://as.example.com/token" } ]]>

Retrieve Part of a Group Configuration by Filters This operation MUST be supported by the Group Manager. The Administrator can send a FETCH request to the group-configuration resource /manage/GROUPNAME associated with an OSCORE group with group name GROUPNAME, in order to retrieve part of the current configuration of that group. The request MUST have Content-Format set to "application/ace-groupcomm+cbor" and its payload is a CBOR map, which contains the following field:

• 'conf_filter', encoded as a CBOR array. Each element of the array specifies one requested configuration parameter or status parameter of the current group configuration (see ), encoded with the corresponding CBOR abbreviation defined in .

When performing the authorization checks, the Group Manager uses GROUPNAME as TARGETNAME, and "Read" as PERMISSION. After a successful processing of the FETCH request, the Group Manager replies to the Administrator with a 2.05 (Content) response, which MUST have Content-Format set to "application/ace-groupcomm+cbor". The response payload is a CBOR map, whose possible entries are specified in . In particular, the response has as payload a partial representation of the group configuration (see ). The exact content of the payload reflects the current configuration of the OSCORE group, and it is limited to the configuration parameters and status parameters requested by the Administrator in the FETCH request. The response payload includes the requested configuration parameters and status parameters, and is formatted as in the response payload of a GET request to a group-configuration resource (see ). If the request payload specifies a parameter that is not included in the group configuration of the OSCORE group, then the response payload MUST NOT include a corresponding parameter. An example of message exchange is shown below. 0.05 FETCH Uri-Path: "manage" Uri-Path: "gp4" Content-Format: 261 (application/ace-groupcomm+cbor) Payload: { e'conf_filter': [e'gp_enc_alg', e'hkdf', e'pairwise_mode', e'active', e'group_description', e'app_groups'] } <= 2.05 Content Content-Format: 261 (application/ace-groupcomm+cbor) Payload: { e'gp_enc_alg': 10 / AES-CCM-16-64-128 /, e'hkdf': 5 / HMAC with SHA-256 /, e'pairwise_mode': true, e'active': true, e'group_description': "rooms 1 and 2", e'app_groups': ["room1", "room2"] } ]]>

Overwrite a Group Configuration This operation MAY be supported by the Group Manager. The Administrator can send a POST request to the group-configuration resource /manage/GROUPNAME associated with an OSCORE group with group name GROUPNAME, in order to overwrite the current configuration of that group with a new one. The request MUST have Content-Format set to "application/ace-groupcomm+cbor" and its payload is a CBOR map. In particular, the request payload has the same format as that of the POST request defined in , with the exception that the configuration parameters 'group_mode' and 'pairwise_mode' as well as the status parameters 'group_name' and 'gid_reuse' MUST NOT be included. The error handling for the POST request is the same as for the POST request defined in , with the following difference in terms of authorization checks. When performing the authorization checks, the Group Manager uses GROUPNAME as TARGETNAME, and "Write" as PERMISSION. If the group-configuration resource targeted by the POST request does not currently exist, then the Group Manager MUST NOT create the resource and MUST reply with a 4.04 (Not Found) error response. If the updated group configuration would include parameter values that prevent the Group Manager from performing the operations defined in (e.g., due to the Group Manager not supporting a format of authentication credentials), the Group Manager MUST reply with a 5.03 (Service Unavailable) response. The response MUST have Content-Format set to "application/concise-problem-details+cbor" and is formatted as defined in . Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' field MUST be set to 12 ("Unsupported group configuration") and the 'detail' field SHOULD be included in order to provide additional context. If no error occurs and the POST request is successfully processed, the Group Manager performs the following actions.

1. The Group Manager updates the group-configuration resource, consistently with the values indicated in the POST request from the Administrator. When doing so, the configuration parameters 'group_mode' and 'pairwise_mode' as well as the status parameters 'group_name' and 'gid_reuse' MUST remain unchanged. For each parameter not specified in the POST request, the Group Manager refers to default values as specified in . Note that the default value recommended for the status parameter 'active' is the CBOR simple value false (0xf4). Therefore, if the Administrator intends to preserve the current status of the group as active, then the payload of the POST request has to include the 'active' parameter specifying the CBOR simple value true (0xf5). When updating the group-configuration resource, the corresponding group-membership resource is also updated accordingly. The operation of overwriting such two resources MUST be atomic. That is, until the request processing fails, or the group-configuration resource has been fully updated and the values of its parameters are set, the following applies:
   • The group-configuration resource MUST NOT be accessible through other operations.
   • The group-membership resource MUST NOT be updated to reflect the new group configuration.
   • The filter criteria specified in a FETCH request to the group-collection resource (see ) MUST be compared against the representation that the group-configuration resource had before its update started.
   When the group-membership resource is eventually updated to reflect the new group configuration, this update MUST NOT be interrupted by other operations performed on the group-membership resource. If a new value N' is specified for the 'max_stale_sets' status parameter and N' is smaller than the current value N, the Group Manager preserves the (up to) N' most recent sets of stale OSCORE Sender IDs associated with the group, and it deletes any possible older set (see ). From then on, the Group Manager relies on the latest updated configuration to build the Join Response message defined in , when handling the joining of a new group member. Similarly, the Group Manager relies on the new group configuration when building responses specifying (part of) the group configuration to a current group member. For instance, this applies when a group member retrieves from the Group Manager the updated group keying material (see ) or the current group status (see ).
2. The Group Manager replies to the Administrator with a 2.04 (Changed) response, which MUST have Content-Format set to "application/ace-groupcomm+cbor". The payload of the response is a CBOR map and it has the same format as that of the 2.01 (Created) response defined in . If the POST request did not specify certain parameters and the Group Manager used default values different from the ones recommended in and , then the response payload MUST also include those parameters, specifying the values chosen by the Group Manager for the current group configuration.
3. If the link to the group-membership resource was registered in the Resource Directory , the Group Manager is responsible to refresh the registration. It is also possible that the Administrator updates the registration in the Resource Directory on behalf of the Group Manager, acting as Commissioning Tool. The Administrator considers the following when specifying additional information for the link to update.
   • The name of the OSCORE group MUST take the value specified in the 'group_name' parameter from the 2.04 (Changed) response.
   • The names of the application groups using the OSCORE group MUST take the values possibly specified by the elements of the 'app_groups' parameter in the POST request.
   • If also registering a related link to the Authorization Server associated with the OSCORE group, the related link MUST have as link target the URI specified in the 'as_uri' parameter from the 2.04 (Changed) response.
   • As to every other information element describing the current group configuration, the following applies.
     • If a certain parameter was specified in the POST request, the Administrator MUST use either the value specified in the 2.04 (Changed) response, if the Group Manager specified one, or the value specified in the POST request otherwise.
     • If a certain parameter was not specified in the POST request, the Administrator MUST use either the value specified in the 2.04 (Changed) response, if the Group Manager specified one, or the corresponding default value recommended in or otherwise.
   As discussed in , it is RECOMMENDED that registrations of links to group-membership resources in the Resource Directory are made (and possibly updated) directly by the Group Manager, rather than by the Administrator.

An example of message exchange is shown below. 0.02 POST Uri-Path: "manage" Uri-Path: "gp4" Content-Format: 261 (application/ace-groupcomm+cbor) Payload: { e'gp_enc_alg': 11 / AES-CCM-16-64-256 /, e'hkdf': 5 / HMAC with SHA-256 / } <= 2.04 Changed Content-Format: 261 (application/ace-groupcomm+cbor) Payload: { e'group_name': "gp4", e'joining_uri': "coap://[2001:db8::ab]/ace-group/gp4/", e'as_uri': "coap://as.example.com/token" } ]]>

Effects on Joining Nodes After having overwritten a group configuration, if the value of the status parameter 'active' is changed from true (0xf5) to false (0xf4) and thus the group becomes inactive, the Group Manager stops admitting new members in the OSCORE group. In particular, until the status parameter 'active' is changed back to true (0xf5) and thus the group becomes active again, the Group Manager replies to a Join Request with a 5.03 (Service Unavailable) response, as defined in . If the value of the status parameter 'active' is changed from false (0xf4) to true (0xf5), the Group Manager resumes admitting new members in the OSCORE group, by processing their Join Requests (see ).

Effects on the Group Members After having overwritten a group configuration, the Group Manager informs the members of the OSCORE group, over the pairwise secure communication channels established when joining the group (see ). To this end, the Group Manager can individually target the 'control_uri' URI of each group member (see ), if provided by the intended recipient upon joining the OSCORE group (see ). Such messages sent by the Group Manager to each group member MUST have Content-Format set to "application/ace-groupcomm+cbor", and MUST be formatted as the Join Response defined in , with the following differences.

• Only the parameters 'gkty', 'key', 'num', 'exp', and 'ace_groupcomm_profile' are present.
• The 'key' parameter includes only the following parameters, with values reflecting the new configuration of the OSCORE group.
  • 'hkdf' and 'cred_fmt'.
  • 'gp_enc_alg', 'sign_alg', and 'sign_params', only in case the configuration parameter 'group_mode' in the group-configuration resource has value true (0xf5), i.e., the OSCORE group uses the group mode of Group OSCORE.
  • 'alg', 'ecdh_alg', and 'ecdh_params', only in case the configuration parameter 'pairwise_mode' in the group-configuration resource has value true (0xf5), i.e., the OSCORE group uses the pairwise mode of Group OSCORE.
  • 'det_hash_alg' defined in , only in case the configuration parameter 'det_req' is present with value true (0xf5), and specifying the Hash Algorithm used in the OSCORE group when producing deterministic requests (see ).

Alternatively, group members can obtain the information above by accessing the group-membership resource associated with the OSCORE group (see ), optionally by subscribing for updates to such a resource, e.g., by using CoAP Observe . When receiving such information, each group member uses it to update the corresponding parameters in the Group OSCORE Security Context of the group in question (see . If any of 'gp_enc_alg', 'sign_alg', 'alg', and 'ecdh_alg' has as value the CBOR simple value null (0xf6), then the corresponding parameter in the Group OSCORE Security Context becomes unset if it is not already. According to the new parameter values, each group member derives new Sender/Recipient Keys, a new Common IV, and new Pairwise Keys. When doing so, a group member MUST NOT reset the Sender Sequence Number in its Sender Context or re-initialize the Replay Window in its Recipient Contexts. The following holds when the value of specific parameters is updated:

• If the value of the status parameter 'active' is changed from true (0xf5) to false (0xf4) and thus the group becomes inactive:
  • The Group Manager stops accepting requests for new individual keying material from current group members (see ), until the status parameter 'active' is changed back to true (0xf5) and thus the group becomes active again. Until then, the Group Manager replies to a Key Renewal Request with a 5.03 (Service Unavailable) response, as defined in .
  • The Group Manager stops accepting updated authentication credentials uploaded by current group members (see ), until the status parameter 'active' is changed back to true (0xf5) and thus the group becomes active again. Until then, the Group Manager replies to an Authentication Credential Update Request with a 5.03 (Service Unavailable) response, as defined in .
• Every group member, upon learning that the OSCORE group has been deactivated (i.e., 'active' has value false (0xf4)), stops sending messages to other group members and stops processing messages from other group members, until the group becomes active again. In the meantime, the group member can still interact with the Group Manager, e.g., in order to check whether the group has become active again. Every group member, upon learning that the OSCORE group has been reactivated (i.e., 'active' has value true (0xf5) again), can resume taking part in communications with other group members (i.e., sending messages and processing incoming messages). A group member can learn about the current group status of a group with group name GROUPNAME by accessing the /ace-group/GROUPNAME/active resource at the Group Manager, as specified in . Optionally, the group member may subscribe for updates to such a resource, e.g., by using CoAP Observe .
• If the value of 'gp_enc_alg' and/or 'alg' is changed, the Group Manager determines the new maximum size NEW_MAX_SIZE that can be used for the OSCORE Sender IDs of the group members, based on the size of the AEAD nonce of such algorithms (see ). In case NEW_MAX_SIZE is strictly smaller than the old, maximum size of the OSCORE Sender IDs used in the OSCORE group, the Group Manager MUST proceed as follows.
  • The Group Manager checks if any of the current group members has an OSCORE Sender ID whose size is strictly larger than NEW_MAX_SIZE.
  • If any such group members are found, the Group Manager MUST evict them from the OSCORE group. That is, the Group Manager MUST terminate their membership and MUST rekey the group in such a way that the new keying material is not provided to those evicted members. This also includes adding their relinquished Sender IDs to the most recent set of stale Sender IDs for the OSCORE group (see ), before rekeying the group. Such evicted group members can rejoin the OSCORE group, thus obtaining the new group keying material together with a new, valid OSCORE Sender ID.
• Every group member, upon receiving updated values for 'hkdf', 'gp_enc_alg', and 'alg', MUST either:
  • Leave the OSCORE group (see ), e.g., if not supporting the indicated new algorithms; or
  • Remain in the OSCORE group and use the Group OSCORE Security Context after having updated it as defined above.
• Every group member, upon receiving updated values for 'cred_fmt', 'sign_alg', 'sign_params', 'ecdh_alg', and 'ecdh_params' MUST either:
  • Leave the OSCORE group, e.g., if not supporting the indicated new format, algorithms, parameters, and encoding; or
  • Leave the OSCORE group and rejoin it (see ). When rejoining the group, an authentication credential in the indicated format used in the OSCORE group MUST be provided to the Group Manager. The authentication credential as well as the included public key MUST be compatible with the indicated algorithms and parameters.
  • Remain in the OSCORE group and use the Group OSCORE Security Context after having updated it as defined above, and, if required, perform the following actions.
    • Provide the Group Manager with a new authentication credential to use in the OSCORE group (see ). The new authentication credential MUST be in the indicated format used in the OSCORE group. The new authentication credential as well as the included public key MUST be compatible with the indicated algorithms and parameters. Consistently, the group member has to retrieve the new authentication credentials of other group members as they are uploaded to the Group Manager (see ). In order to ensure the retrieval of latest authentication credentials that are consistent with the new group configuration, it is preferable that the group member retrieves such authentication credentials after a pre-configured time interval has elapsed since uploading its own authentication credential. Later on, the group member will need to retrieve other group members' authentication credentials that it is still missing and that it needs for processing messages exchanged in the OSCORE group.
    • Retrieve from the Group Manager the Group Manager's new authentication credential (see ). The new Group Manager's authentication credential is in the indicated format used in the OSCORE group. The new authentication credential as well as the included public key are compatible with the indicated algorithms and parameters.

As discussed above, after the group configuration has been updated, some group members may leave the OSCORE group and rejoin it. Shortly following an update of the group configuration, the Group Manager SHOULD prioritize the re-join of such current group members before processing Join Requests from other, new group members.

Selective Update of a Group Configuration This operation MAY be supported by the Group Manager. The Administrator can send a PATCH/iPATCH request to the group-configuration resource /manage/GROUPNAME associated with an OSCORE group with group name GROUPNAME, in order to update the value of only part of the group configuration. The request MUST have Content-Format set to "application/ace-groupcomm+cbor" and its payload is a CBOR map. In particular, the request payload has the same format as that of the POST request defined in , with the difference that it MAY also specify names of application groups to be removed from or added to the 'app_groups' status parameter. Within the CBOR map conveyed as request payload, the names of such application groups are specified by the 'app_groups_diff' field, which is encoded as a CBOR array that includes the following two elements.

• The first element is a CBOR array, namely 'app_groups_del'. Each of its elements is a CBOR text string, with value the name of an application group to remove from the 'app_groups' status parameter.
• The second element is a CBOR array, namely 'app_groups_add'. Each of its elements is a CBOR text string, with value the name of an application group to add to the 'app_groups' status parameter.

The CDDL definition of the CBOR array 'app_groups_diff' formatted as in the request from the Administrator is provided below.

CDDL definition of the 'app_groups_diff' field

The Group Manager MUST reply with a 4.00 (Bad Request) response in case: both the inner CBOR arrays 'app_groups_del' and 'app_groups_add' are empty; or the CBOR map in the request payload includes both the 'app_groups' field and the 'app_groups_diff' field. The error handling for the PATCH/iPATCH request is the same as that for the POST request defined in , with the following additions:

• The set of group configuration parameters to update MUST NOT be empty. The Group Manager MUST reply with a 4.00 (Bad Request) response, if the request payload includes an empty CBOR map.
• If the request URI does not identify an existing group-configuration resource, the Group Manager MUST NOT create a new resource and MUST reply with a 4.04 (Not Found) response.
• If applying the specified updated values would yield an inconsistent group configuration, the Group Manager MUST reply with a 4.09 (Conflict) response. As an example, this is the case if the resulting group configuration would include the 'sign_alg' parameter specifying the signature algorithm EdDSA (COSE algorithm encoding: -8) and, at the same time, the 'sign_params' parameter specifying EC2 as COSE key type and P-256 as COSE elliptic curve (i.e., as the CBOR array [[2], [2, 1]]). The 4.09 (Conflict) response MAY include the current representation of the group configuration resource, like when replying with a 2.05 (Content) response to a GET request as defined in . Otherwise, the 4.09 (Conflict) response SHOULD include a diagnostic payload with additional information for the Administrator to recognize the source of the conflict.
• When the request uses specifically the iPATCH method, the Group Manager MUST reply with a 4.00 (Bad Request) response, in case the CBOR map conveyed as request payload includes the 'app_groups_diff' parameter and the name of an application group is specified both in the 'app_groups_del' and 'app_groups_add' inner arrays.

When performing the authorization checks, the Group Manager uses GROUPNAME as TARGETNAME, and "Write" as PERMISSION. If the updated group configuration would include parameter values that prevent the Group Manager from performing the operations defined in (e.g., due to the Group Manager not supporting a format of authentication credentials), the Group Manager MUST reply with a 5.03 (Service Unavailable) response. The response MUST have Content-Format set to "application/concise-problem-details+cbor" and is formatted as defined in . Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' field MUST be set to 12 ("Unsupported group configuration") and the 'detail' field SHOULD be included in order to provide additional context. If no error occurs and the PATCH/iPATCH request is successfully processed, the Group Manager performs the following actions:

1. The Group Manager updates the group-configuration resource, consistently with the values indicated in the PATCH/iPATCH request from the Administrator. The corresponding group-membership resource is also updated accordingly. The operation of updating the group-configuration resource and accordingly updating the group-membership resource MUST be atomic. That is, the same as defined in when atomically overwriting a group-configuration resource applies. Unlike for the POST request defined in , the Group Manager does not alter the value of configuration parameters and status parameters for which updated values are not specified in the request payload. In particular, the Group Manager does not assign possible default values to those parameters. Special processing occurs when updating the 'app_groups' status parameter by difference, as defined below. The Administrator should not expect the Group Manager to add or delete names of application group names according to any particular order.
   • If the name of an application group to add (delete) is specified multiple times, the Group Manager considers it only once for addition to (deletion from) the 'app_groups' status parameter.
   • If the name of an application group to delete is not present in the 'app_groups' status parameter before any change is applied, the Group Manager ignores that name.
   • If the name of an application group to add is already present in the 'app_groups' status parameter before any change is applied, the Group Manager ignores that name.
   • The Group Manager deletes from the 'app_groups' status parameter the names of the application groups specified in the inner 'app_groups_del' CBOR array of the 'app_groups_diff' field.
   • The Group Manager adds to the 'app_groups' status parameter the names of the application groups specified in the inner 'app_groups_add' CBOR array of the 'app_groups_diff' field.
   After having updated the group-configuration resource, from then on the Group Manager relies on the new group configuration to build the Join Response message defined in , when handling the joining of a new group member. Similarly, the Group Manager relies on the new group configuration when building responses specifying (part of) the group configuration to a current group member. For instance, this applies when a group member retrieves from the Group Manager the updated group keying material (see ) or the current group status (see ).
2. The Group Manager replies to the Administrator with a 2.04 (Changed) response, which MUST have Content-Format set to "application/ace-groupcomm+cbor". The payload of the response is a CBOR map and it has the same format as that of the 2.01 (Created) response defined in .
3. The same considerations as for the POST request defined in hold also in this case, with respect to refreshing a possible registration of the link to the group-membership resource in the Resource Directory .

An example of message exchange is shown below. 0.06 PATCH Uri-Path: "manage" Uri-Path: "gp4" Content-Format: 261 (application/ace-groupcomm+cbor) Payload: { e'gp_enc_alg': 10 / AES-CCM-16-64-128 /, e'app_groups_diff': [["room1"], ["room3", "room4"]] } <= 2.04 Changed Content-Format: 261 (application/ace-groupcomm+cbor) Payload: { e'group_name': "gp4", e'joining_uri': "coap://[2001:db8::ab]/ace-group/gp4/", e'as_uri': "coap://as.example.com/token" } ]]>

Effects on Joining Nodes After having selectively updated part of a group configuration, the effects on candidate joining nodes are the same as defined in for the case of group configuration overwriting.

Effects on the Group Members After having selectively updated part of a group configuration, the effects on the current group members are the same as defined in for the case of group configuration overwriting.

Delete a Group Configuration This operation MUST be supported by the Group Manager. The Administrator can send a DELETE request to the group-configuration resource /manage/GROUPNAME associated with an OSCORE group with group name GROUPNAME, in order to delete that OSCORE group. When performing the authorization checks, the Group Manager uses GROUPNAME as TARGETNAME, and "Delete" as PERMISSION. If the OSCORE group is active, i.e., the current value of the status parameter 'active' is true (0xf5), then the request MUST fail and the Group Manager MUST reply with a 4.00 (Bad Request) response. The response MUST have Content-Format set to "application/concise-problem-details+cbor" and is formatted as defined in . Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' field MUST be set to 10 ("Group currently active"). That is, the request yields the deletion of the OSCORE group only if the OSCORE group is inactive, i.e., the corresponding status parameter 'active' has current value false (0xf4). The Administrator can ensure that, by first performing an update of the group-configuration resource associated with the OSCORE group (see and ) and setting the corresponding status parameter 'active' to false (0xf4). After a successful processing of the DELETE request, the Group Manager performs the following actions. First, the Group Manager deletes the OSCORE group, deallocates both the group-configuration resource as well as the group-membership resource associated with that group, and accordingly updates the group-collection resource. The operation of deleting the group-configuration resource and the corresponding group-membership resource, as well as of accordingly updating the group-collection resource MUST be atomic. That is, until the request processing fails or the group-configuration resource is deleted, the following applies:

• The group-configuration resource MUST NOT be accessible through other operations.
• The group-membership resource MUST NOT be deleted.
• The group-collection resource MUST NOT be updated to reflect the deletion of the group-configuration resource.

When the group-membership resource is eventually deleted, this deletion MUST NOT be interrupted by other operations performed on the group-membership resource. When the group-collection resource is eventually updated to reflect the deletion of the group-configuration resource, this update MUST NOT be interrupted by other updates to the group-collection resource due to the creation or deletion of group-configuration resources, or to other operations performed on those. After deleting the group-configuration resource, the Group Manager replies to the Administrator with a 2.02 (Deleted) response. An example of message exchange is shown below. 0.04 DELETE Uri-Path: "manage" Uri-Path: "gp4" <= 2.02 Deleted ]]>

Effects on the Group Members After having deleted an OSCORE group, the Group Manager can inform the group members by means of the following two methods. When contacting a group member, the Group Manager uses the pairwise secure communication association established with that member during its joining process (see ).

• The Group Manager sends an individual request message to each group member, targeting the respective resource used to perform the group rekeying process (see ). The Group Manager uses the same format of the Join Response message in , where only the parameters 'gkty', 'key', and 'ace_groupcomm_profile' are present, and the value of the 'key' parameter encodes the empty CBOR map.
• A group member may subscribe for updates to the group-membership resource associated with the OSCORE group. In particular, if this relies on CoAP Observe , a group member would receive a 4.04 (Not Found) notification response from the Group Manager, since the group-configuration resource has been deallocated upon deleting the OSCORE group (see ). The response MUST have Content-Format set to "application/concise-problem-details+cbor" and is formatted as defined in . Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' field MUST be set to 6 ("Group deleted").

When being informed about the deletion of the OSCORE group, a group member deletes the OSCORE Security Context that it stores as associated with that group, and possibly deallocates any dedicated control resource intended for the Group Manager that it has for that group.

ACE Groupcomm Parameters In addition to what is defined in , this document defines additional parameters used in the messages exchanged between the Administrator and the Group Manager (see ). The table below summarizes them and specifies the CBOR key to use instead of the full descriptive name. Note that the media type "application/ace-groupcomm+cbor" MUST be used when these parameters are transported in the respective message fields. ACE Groupcomm Parameters

Name	CBOR Key	CBOR Type	Reference
hkdf	-1	tstr or int	[RFC-XXXX]
cred_fmt	-2	int	[RFC-XXXX]
group_mode	-3	True or False	[RFC-XXXX]
gp_enc_alg	-4	Null or tstr or int	[RFC-XXXX]
sign_alg	-5	Null or tstr or int	[RFC-XXXX]
sign_params	-6	Null or array	[RFC-XXXX]
pairwise_mode	-7	True or False	[RFC-XXXX]
alg	-8	Null or tstr or int	[RFC-XXXX]
ecdh_alg	-9	Null or tstr or int	[RFC-XXXX]
ecdh_params	-10	Null or array	[RFC-XXXX]
det_req	-25	True or False	[RFC-XXXX]
det_hash_alg	-26	tstr or int	[RFC-XXXX]
rt	-11	tstr	[RFC-XXXX]
active	-12	True or False	[RFC-XXXX]
group_name	-13	tstr or #6.<uint>(any)	[RFC-XXXX]
group_description	-14	Null or tstr	[RFC-XXXX]
max_stale_sets	-15	uint	[RFC-XXXX]
gid_reuse	-16	True or False	[RFC-XXXX]
app_groups	-17	array	[RFC-XXXX]
joining_uri	-18	tstr	[RFC-XXXX]
as_uri	-19	tstr	[RFC-XXXX]
conf_filter	-27	array	[RFC-XXXX]
app_groups_diff	-28	array	[RFC-XXXX]

The following holds for the Group Manager:

• It MUST support the parameters 'ace_groupcomm_profile', 'exp', and 'group_policies', which are defined in . This is consistent with what is defined in for the Key Distribution Center (KDC), of which the Group Manager defined in is a specific instance.
• It MUST support all the parameters listed in , with the exception of the 'app_groups_diff' parameter that MUST be supported only if the Group Manager supports the selective update of a group configuration (see ).

The following holds for an Administrator.

• It MUST support the parameters 'ace_groupcomm_profile', 'exp', and 'group_policies', which are defined in .
• It MUST support all the parameters listed in , with the following exceptions.
  • 'conf_filter', which MUST be supported only if the Administrator supports the partial retrieval of a group configuration by filters (see ).
  • 'app_groups_diff' parameter, which MUST be supported only if the Administrator supports the selective update of a group configuration (see ).

ACE Groupcomm Error Identifiers In addition to what is defined in , this document defines new values that the Group Manager 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 ). ACE Groupcomm Error Identifiers

Value	Description	Reference
10	Group currently active	[RFC-XXXX]
11	Unable to determine a group name	[RFC-XXXX]
12	Unsupported group configuration	[RFC-XXXX]

If the Administrator supports the problem-details format and the Custom Problem Detail entry 'ace-groupcomm-error' defined in , and is able to understand the error specified in the 'error-id' field therein, then the Administrator may use that information to determine what actions to take next. If the Concise Problem Details data item specified in the error response includes the 'detail' entry and the Administrator supports it, such an entry may provide additional context. In particular, the following guidelines apply.

• In case of error 10, the Administrator should stop sending the DELETE request to the Group Manager (see ), until the group becomes inactive. As per this document, this error is relevant only for the Administrator, if it tries to delete a group without having set its status to inactive first (see ). In such a case, the Administrator should take the expected course of actions and set the group status to inactive first (see and ), before sending a new request of group deletion to the Group Manager.
• In case of error 11, the Administrator has the following options.
  • The Administrator simply tries again later on. The new POST request to the group-collection resource specifies the same group name originally suggested in the previous request that triggered the error response (see ). This option fundamentally relies on the Group Manager making the group name available again before the Administrator sends the new POST request. Hence, this option is not viable if it is unacceptable for the Administrator to considerably or indefinitely postpone the creation of the new group.
  • The Administrator sends a new POST request to the group-collection resource right away, specifying a different group name than the one suggested in the previous request that triggered the error response. In order to not inadvertently suggest a new group name that is already assigned to an existing OSCORE group, the Administrator can first retrieve a list of existing groups from the Group Manager, as defined in . In the payload of the response from the Group Manager, each specified link indicates the name of an existing OSCORE group as the last segment of its url-path. The Administrator should choose the new group name GROUPNAME to suggest, in such a way that it does not renounce permissions that were granted per the old group name GROUPNAME*. This is the case if the following holds. With reference to the 'scope' claim of the Administrator's access token, let us define PERM* as the union of the permission sets associated with the scope entries such that GROUPNAME* matches with the specified group name pattern. Also, let us define PERM as the union of the permission sets associated with the scope entries such that GROUPNAME matches with the specified group name pattern. Then, PERM specifies no fewer permissions than PERM*.
  • The Administrator requests a new access token to the Authorization Server, in order to update its access rights and have a new granted scope, whose scope entries specify more and/or different group name patterns than the old access token. After uploading the new access token to the Group Manager, the Administrator can send a new POST request to the group-collection resource. When doing so, the Administrator suggests a new group name to the Group Manager, according to the same criteria discussed for the previous option.
• In case of error 12, the Administrator has the following options.
  • If the Administrator has attempted to create a new group configuration (see ), the Administrator can take into account what the Group Manager specifies in the 'detail' entry of the Concise Problem Details data item specified in the error response, and send a new request to the Group Manager for creating the group configuration accordingly. This requires that the Administrator finds acceptable to create a group configuration different from the originally intended one.
  • If the Administrator has attempted to overwrite (see ) or selectively update (see ) an existing group configuration, the Administrator can take into account what the Group Manager specifies in the 'detail' entry of the Concise Problem Details data item specified in the error response, and send a new request to the Group Manager for accordingly overwriting or selectively updating the group configuration. This requires that the Administrator finds acceptable to overwrite or update the current group configuration differently than how it was originally intended. If this is not attainable, the Administrator may decide to not take further actions and keep the current group configuration as is, or instead to delete the group configuration altogether (see ).

Operational Considerations In addition to the considerations already discussed in this document (e.g., regarding default values), this section compiles additional operational considerations that hold for this document. The operational considerations from also apply, with respect to the operations and RESTful interface at the Group Manager that are defined in that document for the management of keying material in OSCORE groups.

Administration of Groups The RESTful admin interface at the Group Manager defined in this document is specifically intended for the administration of OSCORE groups. To this end, it provides the set of operations specified in for interacting with the group-collection resource and the group-configuration resources at the Group Manager (see ). By relying on a data model based on CBOR for the representation of group configurations and their parameters (see ), the admin interface enables multiple Administrators to perform administrative operations at the same Group Manager in an interoperable way. discusses the case where multiple Administrators operate on the same Group Manager in the interest of the same OSCORE group. Except for the status parameters 'rt', 'ace_groupcomm_profile', and 'joining_uri', the group configuration parameters defined in this document are configurable by authorized Administrators. Notably, the Group Manager takes the final decision about:

• The name given to a newly created OSCORE group, specified by the 'group_name' status parameter.
• The URI of the group-membership resource for joining a newly created group, specified by the 'joining_uri' status parameter.
• The URI of the Authorization Server associated with the Group Manager for an OSCORE group, specified by the 'as_uri' status parameter.

Furthermore, the configuration parameters 'group_mode' and 'pairwise_mode' as well as the status parameters 'group_name' and 'gid_reuse' cannot be updated after the group has been created with its initial configuration. Default values for the group configuration parameters are specified in , building on the default values specified in when applicable. As defined in , it is recommended that the default values used by the Group Manager are the specified ones, but the Group Manager may choose to use different ones. Given a group, its configuration is available to retrieve to Administrators that are authorized to access the corresponding group-configuration resource at the Group Manager, by means of a GET request (see ) or a FETCH request (see ). In practice, most of the information specified in the group configuration will also be provided to authorized Clients that interact with the Group Manager through the RESTful interface defined in , e.g., when joining the group and later on as current group members. Creating a new group and the corresponding configuration at the Group Manager yields the expectation that traffic will occur between the Group Manager and (candidate) group members, as well as between nodes that have become group members. Conversely, the deletion of a group and of the corresponding configuration anticipates that the traffic mentioned above will cease. In either case, this information can be used to accordingly plan and adjust the allocation of network resources. In particular, this information can be acquired by Administrators that are authorized to access the group-collection resource at the Group Manager, by means of a GET request (see ) or a FETCH request (see ). Alternatively, it can be acquired by authorized, external management applications and operators, by retrieving relevant log entries about the creation and deletion of groups (see ). Certain operations at the Group Manager could result in side effects on network nodes, in terms of communications with the Group Manager and with one another as members of the same OSCORE group. These side effects are compiled in and with respect to the overwriting of an existing group configuration, in and with respect to the selective update of an existing group configuration, and in with respect to the deletion of an OSCORE group and of its corresponding configuration. By delegating the creation, (re)-configuration, and deletion of OSCORE groups to an Administrator, the Group Manager can be agnostic of the specific applications using secure group communication. Nonetheless, even when providing the admin interface defined in this document, the Group Manager could additionally take the initiative in creating, (re-)configuring, and deleting some of its OSCORE groups through a local application interface, i.e., without the involvement of an Administrator.

Logging When performing its normal operations, the Group Manager is expected to produce and store timestamped logs about the following:

• Any event that has resulted in the Group Manager sending an error response, as a reply to a request received at any of the resources exported by the interface specified in this document. The logged information contains a description of the error occurred in the context of the interface defined in the present document, together with a description of the event related to the error and relevant metadata about the Administrator that has sent the request. For instance, possible metadata include: addressing information of the Administrator; when applicable, (an identifier of) the authentication credential that the Administrator has used to authenticate itself to the Group Manager when establishing their secure communication association. Note that, if the error response uses the format problem-details defined in , then the "detail" entry in the response payload is meant to convey the diagnostic description of the error, which is meant to be part of the log entry for this event.
• Any event consisting in a successfully performed operation that is triggered by a request received at any of the resources exported by the interface specified in this document. Such events include:
  • An Administrator retrieving a list of existing OSCORE groups.
  • An Administrator creating a new OSCORE group. This results in the creation of a group-configuration resource and the corresponding group-membership resource.
  • An Administrator retrieving (part of) a group configuration.
  • An Administrator overwriting or selectively updating a group configuration.
  • An Administrator deleting an OSCORE group and thus the corresponding group configuration. This results in the deletion of a group-configuration resource and of the corresponding group-membership resource.
  The logged information contains a description of the operation performed in the context of the interface defined in the present document, together with relevant metadata about the Administrator that has sent the request. For instance, possible metadata include: addressing information of the Administrator; when applicable, (an identifier of) the authentication credential that the Administrator has used to authenticate itself to the Group Manager when establishing their secure communication association.
• For each OSCORE group, the evolution of the corresponding group configuration, i.e., starting from the initial configuration that is established when creating the group, and tracking the result of possible overwriting and selective updates. In practice, this can be achieved by readily creating and storing dedicated log entries, or instead by producing those when needed, leveraging the logged events that pertain to the group-configuration resource for the group in question. The Group Manager is also expected to log the evolution of group configurations that are created, overwritten, updated, and deleted at its own initiative through a local application interface, i.e., without the involvement of an Administrator.

In addition to what is compiled above, the Group Manager could log additional information. Further details about what the Group Manager logs, with what granularity, and based on what triggering events and conditions are application-specific and left to operators to define. The Group Manager MUST NOT log any secret or confidential information pertaining to a group and its configuration. Although the configuration parameters and status parameters defined in of this document do not specify secret or confidential information, this requirement is set in preparation for possible new parameters that can be defined in the future. It is up to the application to specify for how long a log entry is retained from the time of its creation and until its deletion. Different retention policies could be enforced for different groups. For a given group, the oldest log entries are expected to be those deleted first, and different retention policies could be enforced depending on whether the group currently exists or has been deleted. It is out of the scope of this document what specific semantics and data model are used by the Group Manager for producing and processing the logs. Nonetheless, log entries could use the data model defined in to represent group configurations. Specific semantics and data models can be defined by applications and future specifications. The Group Manager is expected to make the logs that it produces available for secure access by authorized external management applications and operators. In particular, logged information could be retrieved in the following ways:

• By accessing logs at the Group Manager through polling. This can occur in an occasional, regular, or event-driven way.
• Through notifications sent by the Group Manager according to an operator-defined frequency.
• Through notifications asynchronously sent by the Group Manager, throttling them in order to prevent congestion and duplication and to not create attack vectors.

Some of the logged information can be privacy-sensitive. This especially holds for the metadata about an Administrator, i.e., addressing information of the Administrator and, when applicable, (an identifier of) the authentication credential that the Administrator has used to authenticate itself to the Group Manager when establishing their secure communication association. If external management applications and operators obtain such metadata, they become able to track a given Administrator, as to its interactions with one or multiple Group Managers and its performed operations at those Group Managers. Therefore, the logged information that is effectively provided to external management applications and operators SHOULD be redacted by the Group Manager, by omitting any privacy-sensitive information element that could enable or facilitate the impairment of Administrators' privacy, e.g., by tracking Administrators across different Group Managers. Furthermore, within a group configuration, the status parameters 'group_description' and 'app_groups' specify information that can be privacy-sensitive. Therefore, the logged information that is effectively provided to external management applications and operators SHOULD be redacted by the Group Manager, by omitting the information specified in the status parameters 'group_description' and 'app_groups'. The same applies with respect to privacy-sensitive information specified by configuration parameters or status parameters that can be defined in the future. Exceptions to the omission of logged information could apply, e.g., if the Group Manager can verify that the management application or operator in question is specifically authorized to obtain such privacy-sensitive information and appropriately entitled to obtain it according to enforced privacy policies.

Access Control Building on the ACE framework , access control is enforced for Administrators acting as Clients that interact with the interface at the Group Manager specified in this document. In particular, the granularity of such access control takes into account the resource specifically targeted at the Group Manager, the operation requested by sending a request to that resource, and the specific permission(s) that the requesting Administrator is authorized to have according to its corresponding access token. Furthermore, the interactions between an Administrator and the Group Manager are secured as per the specific transport profile of ACE used (e.g., and ).

Security Considerations Security considerations are inherited from the ACE framework for Authentication and Authorization and from the specific transport profile of ACE used between the Administrator and the Group Manager, such as and . The same security considerations from and also apply, with particular reference to the process of rekeying OSCORE groups. Further security considerations are compiled below.

Change of Group Configuration With respect to changing group configurations, the following security considerations hold.

• A change of the current group configuration (see and ) might result in generating and distributing new group keying material, consistently with the newly enforced algorithms and related parameters. In such a case, the Group Manager can perform a group rekeying as per , or provide the new group keying material together with the new group configuration as per and of this document. After gaining knowledge of the new group configuration, current group members may also leave the OSCORE group and rejoin it, hence obtaining the new group configuration parameters and the up-to-date group keying material. When this happens, the Group Manager SHOULD NOT repeatedly rekey the group upon the re-join of every current group member, each of which is identifiable by means of the secure association that it has with the Group Manager.
• Following the enforcement of a new group configuration, a group member might not deem it conducive to a sufficient security level (e.g., in terms of security algorithms and related parameters). In such a case, it is RECOMMENDED that the group member leaves the group.
• A change of the current group configuration, possibly also requiring a group rekeying, might result in temporarily preventing communications among some group members altogether, until they have aligned themselves to the new group configuration. This is especially the case for a change of group configuration affecting the security algorithms and related parameters used in the group. Furthermore, a change of group configuration might interfere with ongoing, extended exchanges between group members, especially Block-Wise transfers and the transmission of Observe notifications for ongoing Observations . A group configuration (possibly together with the group keying material) may have been updated while a Block-Wise transfer is ongoing between two group members. This will result in blocks being resent, if the block sender and recipient are not yet both aligned with the new group configuration (and group keying material), in which case the block recipient would reply with an error message. After a change of group configuration, a group member MUST terminate an ongoing Observation if the new group configuration would not have allowed to compute exactly the Observe request associated with the ongoing Observation. This occurs, for example, when the new group configuration specifies a signature algorithm different from the one used in the group when the Observe request was protected.

Group Manager In addition to what is discussed in , a compromised Group Manager would allow an adversary to monitor the group configurations specified by an Administrator, or to enforce group configurations different from the specified ones, which can result in communications in the OSCORE groups not attaining the originally intended security level. Although this is undesirable, it is not worse than the control that the adversary would gain on the group keying material through the compromised Group Manager (see ). Unlike what is defined in with respect to renewing the group keying material, the Group Manager does not have to change the group configurations of the OSCORE groups it is responsible for after having experienced a reboot.

Administrators and define exchanges where the Administrator sends a GET or FETCH request to the group-collection resource at the Group Manager. The payload of a successful response to those requests can include links to group-configuration resources at the Group Manager. When processing the response, the Administrator MUST NOT accept any of such links whose URI specified as link target does not point to the Group Manager that has sent the response. In particular, the Administrator MUST NOT consider those links as pointing to the alleged group-configuration resources. From to , other exchanges are defined where the Administrator sends different requests to the group-collection resource or a group-configuration resource at the Group Manager. The payload of a successful response to those requests has to or can include the 'joining_uri' status parameter. When processing the response, the Administrator SHOULD NOT accept the URI encoded by the 'joining_uri' parameter if the URI does not point to the Group Manager that has sent the response. In particular, the Administrator SHOULD NOT consider that URI as pointing to the alleged group-membership resource. Exceptions in accepting URIs that allegedly point to group-membership resources ought to be carefully understood and vetted by the Administrator. As a notable example, a trusted CoAP reverse-proxy might stand in for the Group Manager, in such a way that candidate group members can reach the Group Manager by actually interacting with the reverse-proxy. In this case, the host subcomponent of the URI does not refer to the Group Manager, but instead to the reverse-proxy. The Administrator can verify that a URI retrieved from a response sent by the Group Manager points to the same Group Manager by comparing the host subcomponent of the URI with the host subcomponent of the corresponding request URI. If one host subcomponent consists of an IP literal and the other host subcomponent consists of a hostname, the comparison could require resolving the hostname to an IP address. If the Administrator determines that a URI pointing to an alleged group-membership resource cannot be accepted, the following applies:

• Aligned with what is allowed by the granted authorization, the Administrator can attempt to retrieve the correct URI pointing to the group-membership resource in question, by sending a GET or FETCH request to the corresponding group-configuration resource (see and ). Also aligned with what is allowed by the granted authorization, the Administrator could ultimately delete the group configuration in question by deleting the corresponding group-configuration resource (see ) and then create a new group configuration (see ).
• The Administrator MUST NOT register the link to the group-membership resource with URI specified in the 'joining_uri' parameter to a Resource Directory on behalf of the Group Manager.

If the Administrator determines that a URI pointing to an alleged group-configuration resource or group-membership resource cannot be accepted, the Administrator ought to report it as appropriate. If multiple Administrators are responsible for the same OSCORE group, they are expected to be aware of each other and of their shared responsibility, as well as to be aligned on what is in the best interest of the OSCORE group and its secure operation. It is out of the scope of this document to define how different Administrators are appointed as responsible for an OSCORE group, and how they achieve and maintain such an alignment with each other. A compromised Administrator could collude with unauthorized parties. Within the extent of the granted access rights, the compromised Administrator may leak group configurations, change them in such a way that communications in the OSCORE groups do not attain the originally intended security level, or delete OSCORE groups altogether thus impeding their secure operation. When an Administrator is found compromised, the pertaining access tokens MUST be revoked by the Authorization Server. A possible way for the Authorization Server to notify the affected Group Managers about such revoked access tokens is defined in .

IANA Considerations This document has the following actions for IANA. Note to RFC Editor: Please replace all occurrences of "[RFC-XXXX]" with the RFC number of this specification and delete this paragraph.

ACE Groupcomm Parameters IANA is asked to register the following entries in the "ACE Groupcomm Parameters" registry within the "Authentication and Authorization for Constrained Environments (ACE)" registry group:

• Name: hkdf
• CBOR Key: -1 (suggested)
• CBOR Type: tstr or int
• Reference: [RFC-XXXX]

• Name: cred_fmt
• CBOR Key: -2 (suggested)
• CBOR Type: int
• Reference: [RFC-XXXX]

• Name: group_mode
• CBOR Key: -3 (suggested)
• CBOR Type: True or False
• Reference: [RFC-XXXX]

• Name: gp_enc_alg
• CBOR Key: -4 (suggested)
• CBOR Type: Null or tstr or int
• Reference: [RFC-XXXX]

• Name: sign_alg
• CBOR Key: -5 (suggested)
• CBOR Type: Null or tstr or int
• Reference: [RFC-XXXX]

• Name: sign_params
• CBOR Key: -6 (suggested)
• CBOR Type: Null or array
• Reference: [RFC-XXXX]

• Name: pairwise_mode
• CBOR Key: -7 (suggested)
• CBOR Type: True or False
• Reference: [RFC-XXXX]

• Name: alg
• CBOR Key: -8 (suggested)
• CBOR Type: Null or tstr or int
• Reference: [RFC-XXXX]

• Name: ecdh_alg
• CBOR Key: -9 (suggested)
• CBOR Type: Null or tstr or int
• Reference: [RFC-XXXX]

• Name: ecdh_params
• CBOR Key: -10 (suggested)
• CBOR Type: Null or array
• Reference: [RFC-XXXX]

• Name: det_req
• CBOR Key: -25 (suggested)
• CBOR Type: True or False
• Reference: [RFC-XXXX]

• Name: det_hash_alg
• CBOR Key: -26 (suggested)
• CBOR Type: tstr or int
• Reference: [RFC-XXXX]

• Name: rt
• CBOR Key: -11 (suggested)
• CBOR Type: tstr
• Reference: [RFC-XXXX]

• Name: active
• CBOR Key: -12 (suggested)
• CBOR Type: True or False
• Reference: [RFC-XXXX]

• Name: group_name
• CBOR Key: -13 (suggested)
• CBOR Type: tstr or #6.<uint>(any)
• Reference: [RFC-XXXX]

• Name: group_description
• CBOR Key: -14 (suggested)
• CBOR Type: Null or tstr
• Reference: [RFC-XXXX]

• Name: max_stale_sets
• CBOR Key: -15 (suggested)
• CBOR Type: uint
• Reference: [RFC-XXXX]

• Name: gid_reuse
• CBOR Key: -16 (suggested)
• CBOR Type: True or False
• Reference: [RFC-XXXX]

• Name: app_groups
• CBOR Key: -17 (suggested)
• CBOR Type: array
• Reference: [RFC-XXXX]

• Name: joining_uri
• CBOR Key: -18 (suggested)
• CBOR Type: tstr
• Reference: [RFC-XXXX]

• Name: as_uri
• CBOR Key: -19 (suggested)
• CBOR Type: tstr
• Reference: [RFC-XXXX]

• Name: conf_filter
• CBOR Key: -27 (suggested)
• CBOR Type: array
• Reference: [RFC-XXXX]

• Name: app_groups_diff
• CBOR Key: -28 (suggested)
• CBOR Type: array
• Reference: [RFC-XXXX]

ACE Groupcomm Errors IANA is asked to register the following entries in the "ACE Groupcomm Errors" registry within the "Authentication and Authorization for Constrained Environments (ACE)" registry group:

• Value: 10 (suggested)
• Description: Group currently active
• Reference: [RFC-XXXX]

• Value: 11 (suggested)
• Description: Unable to determine a group name
• Reference: [RFC-XXXX]

• Value: 12 (suggested)
• Description: Unsupported group configuration
• Reference: [RFC-XXXX]

Resource Types IANA is asked to register the following entries in the "Resource Type (rt=) Link Target Attribute Values" registry within the "Constrained Restful Environments (CoRE) Parameters" registry group:

• Value: core.osc.gcoll
• Description: Group-collection resource of an OSCORE Group Manager
• Reference: [RFC-XXXX]

• Value: core.osc.gconf
• Description: Group-configuration resource of an OSCORE Group Manager
• Reference: [RFC-XXXX]

Group OSCORE Admin Permissions This document establishes the IANA "Group OSCORE Admin Permissions" registry within the "Authentication and Authorization for Constrained Environments (ACE)" registry group. The registry has been created to use the "Expert Review" registration procedure . Expert review guidelines are provided in . This registry includes the possible permissions that Administrators can have to perform operations on an OSCORE Group Manager, each in combination with a numeric identifier. These numeric identifiers are used to express authorization information about performing administrative operations concerning OSCORE groups under the control of the Group Manager, as specified in of [RFC-XXXX]. The columns of this registry are:

• Name: A value that can be used in documents for easier comprehension, to identify a possible permission that Administrators can perform when interacting with an OSCORE Group Manager.
• Value: The numeric identifier for this permission. These values MUST be unique. The value can be an integer greater than or equal to 0. Integer values greater than 65535 are marked as "Private Use" (see ). All other values use the registration policy "Expert Review" (see ). Note that, in general, a single permission can be associated with multiple different operations that are possible to be performed when interacting with the Group Manager.
• Description: This field contains a brief description of the permission.
• Reference: This contains a pointer to the public specification for the permission, if one exists.

This registry will be initially populated by the values in . The Reference column for all of these entries will be [RFC-XXXX].

Expert Review Instructions The IANA registry established in this document is 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. Expert reviewers should take into consideration the following points:

• Clarity and correctness of registrations. Experts are expected to check the clarity of purpose and use of the requested entries. Experts should inspect the entry for the considered permission, to verify the correctness of its description against the permission as intended in the specification that defined it. Expert should consider requesting an opinion on the correctness of registered parameters from the Authentication and Authorization for Constrained Environments (ACE) Working Group and the Constrained RESTful Environments (CoRE) Working Group. Entries that do not meet these objective of clarity and completeness should not be registered.
• Duplicated registration and 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.
• Experts should take into account the expected usage of permissions when approving point assignment. Given a 'Value' V as code point, the length of the encoding of (2^V+1 - 1) should be weighed against the usage of the entry, considering the resources and capabilities of devices it will be used on. Additionally, given a 'Value' V as code point, the length of the encoding of (2^V+1 - 1) should be weighed against how many code points resulting in that encoding length are left, and the resources and capabilities of devices it will be used on.
• Specifications are recommended. When specifications are not provided, the description provided needs to have sufficient information to verify the points above.

References Normative References RISE AB Ericsson AB Ericsson AB Ericsson AB RISE AB This document defines the security protocol Group Object Security for Constrained RESTful Environments (Group OSCORE), providing end-to-end security of messages exchanged with the Constrained Application Protocol (CoAP) between members of a group, e.g., sent over IP multicast. In particular, the described protocol defines how OSCORE is used in a group communication setting to provide source authentication for CoAP group requests, sent by a client to multiple servers, and for protection of the corresponding CoAP responses. Group OSCORE also defines a pairwise mode where each member of the group can efficiently derive a symmetric pairwise key with each other member of the group for pairwise OSCORE communication. Group OSCORE can be used between endpoints communicating with CoAP or CoAP- mappable HTTP. RISE AB Ericsson AB This document defines an application profile of the Authentication and Authorization for Constrained Environments (ACE) framework, to request and provision keying material in group communication scenarios that are based on the Constrained Application Protocol (CoAP) and are secured with Group Object Security for Constrained RESTful Environments (Group OSCORE). This application profile delegates the authentication and authorization of Clients, which join an OSCORE group through a Resource Server acting as Group Manager for that group. This application profile leverages protocol-specific transport profiles of ACE to achieve communication security, server authentication, and proof of possession of a key owned by the Client and bound to an OAuth 2.0 access token. IoTconsultancy.nl RISE AB The Constrained Application Protocol (CoAP) is a web transfer protocol for constrained devices and constrained networks. In a number of use cases, constrained devices often naturally operate in groups (e.g., in a building automation scenario, all lights in a given room may need to be switched on/off as a group). This document specifies the use of 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. 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] 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] 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] 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. 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. 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. 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). 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. This is the third edition of this document; it obsoletes RFC 5226. The methods defined in RFC 7252 for the Constrained Application Protocol (CoAP) only allow access to a complete resource, not to parts of a resource. In case of resources with larger or complex data, or in situations where resource continuity is required, replacing or requesting the whole resource is undesirable. Several applications using CoAP need to access parts of the resources. This specification defines the new CoAP methods, FETCH, PATCH, and iPATCH, which are used to access and update parts of a resource. 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. 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. Although an optional functionality of CoAP, OSCORE alters CoAP options processing and IANA registration. Therefore, this document updates RFC 7252. 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. 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. 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. This document, along with RFC 9053, obsoletes RFC 8152. 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). This document, along with RFC 9052, obsoletes RFC 8152. In many Internet of Things (IoT) applications, direct discovery of resources is not practical due to sleeping nodes or networks where multicast traffic is inefficient. These problems can be solved by employing an entity called a Resource Directory (RD), which contains information about resources held on other servers, allowing lookups to be performed for those resources. The input to an RD is composed of links, and the output is composed of links constructed from the information stored in the RD. This document specifies the web interfaces that an RD supports for web servers to discover the RD and to register, maintain, look up, and remove information on resources. Furthermore, new target attributes useful in conjunction with an RD are defined. 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. 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. 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. 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. 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. 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. 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. This document specifies I-Regexp, a flavor of regular expression that is limited in scope with the goal of interoperation across many different regular expression libraries. 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. IANA IANA IANA IANA 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. 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. Informative References RISE AB 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 defines 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 can be used to protect communications in 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. RISE AB When using the Constrained Application Protocol (CoAP), exchanged messages can be protected end-to-end also across untrusted intermediary proxies. This can be achieved with Object Security for Constrained RESTful Environments (OSCORE) or, in the case of group communication, with Group Object Security for Constrained RESTful Environments (Group OSCORE). However, this sidesteps the proxies' abilities to cache responses from the origin server(s). This document restores cacheability of end-end protected responses at proxies, by using Group OSCORE and introducing consensus requests, which any client in an OSCORE group can send to one server or multiple servers in the same group. Ericsson AB Ericsson AB University of Glasgow RISE AB IN Groupe This document specifies a CBOR encoding of X.509 certificates. The resulting certificates are called C509 certificates. The CBOR encoding supports a large subset of RFC 5280, common certificate profiles and is extensible. Two types of C509 certificates are defined. One type is an invertible CBOR re-encoding of DER-encoded X.509 certificates with the signature field copied from the DER encoding. The other type is identical except that the signature is over the CBOR encoding instead of the DER encoding, avoiding the use of ASN.1. Both types of certificates have the same semantics as X.509 and the same reduced size compared to X.509. The document also specifies CBOR encoded data structures for certificate (signing) requests and certificate request templates, new COSE headers, as well as a TLS certificate type and a file format for C509. This document updates RFC 6698; the TLSA selectors registry is extended to include C509 certificates. 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] 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. 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. 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. 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. This document specifies version 1.2 of the Datagram Transport Layer Security (DTLS) protocol. The DTLS protocol provides communications privacy for datagram protocols. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document updates DTLS 1.0 to work with TLS version 1.2. [STANDARDS-TRACK] This document specifies version 1.3 of the Datagram Transport Layer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. The DTLS 1.3 protocol is based on the Transport Layer Security (TLS) 1.3 protocol and provides equivalent security guarantees with the exception of order protection / non-replayability. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document obsoletes RFC 6347. This document specifies alternative Constrained Application Protocol (CoAP) block-wise transfer options: Q-Block1 and Q-Block2. These options are similar to, but distinct from, the CoAP Block1 and Block2 options defined in RFC 7959. The Q-Block1 and Q-Block2 options are not intended to replace the Block1 and Block2 options but rather have the goal of supporting Non-confirmable (NON) messages for large amounts of data with fewer packet interchanges. Also, the Q-Block1 and Q-Block2 options support faster recovery should any of the blocks get lost in transmission. This document specifies a method of the Authentication and Authorization for Constrained Environments (ACE) framework, which allows an authorization server to notify clients and resource servers (i.e., registered devices) about revoked access tokens. As specified in this document, the method allows clients and resource servers (RSs) to access a Token Revocation List (TRL) on the authorization server by using the Constrained Application Protocol (CoAP), with the possible additional use of resource observation. Resulting (unsolicited) notifications of revoked access tokens complement alternative approaches such as token introspection, while not requiring additional endpoints on clients and RSs.

Processing of Group Name Patterns at the AS When processing an Authorization Request from an Administrator (see ), the AS builds the authorization information expressing granted permissions as scope entries, according to the AIF data model AIF-OSCORE-GROUPCOMM and to its extension specified in . These scope entries are in turn specified as the value of the 'scope' claim to include in the access token. This appendix provides an example of how the AS can evaluate the requested permissions against the access policies pertaining to the Administrator for the Group Manager in question. The following specifically refers only to "admin scope entries", i.e., scope entries that express authorization information for Administrators of OSCORE groups. Also, it is assumed that the AS stores the access policies as a set of "admin policy entries", which have the same format of the scope entries according to the AIF data model AIF-OSCORE-GROUPCOMM (see ). The following specifically considers only "admin policy entries", i.e., policy entries for Administrators of OSCORE groups hereafter shortly referred to as "policy entries". The AS performs the following steps:

1. The AS initializes an empty set of scope entries, namely S_OUT.
2. For each scope entry E_S in the 'scope' parameter of the Authorization Request, the AS performs the following actions. a. The AS initializes an empty set of policy entries, namely S_AUX. b. The AS considers all the policy entries related to the Administrator and the Group Manager in question. For each policy entry E_P among those policy entries, the AS determines whether every group name matching with the Toid of E_S would also match with the Toid of E_P. If that is the case, then the AS adds E_P to the set S_AUX. The particular way that the AS uses to make a determination is implementation specific. c. If the set S_AUX is empty, the AS proceeds to the next scope entry, if any. Otherwise, the AS computes TPERM_AUX as the union of the permission sets associated with the policy entries in the set S_AUX. That is, TPERM_AUX is the inclusive OR of the binary representations of the Tperm values in the policy entries within the set S_AUX. d. The AS adds to the set S_OUT one scope entry, such that its Toid is the same as in the scope entry E_S, while its Tperm is the AND of TPERM_AUX with the Tperm in the scope entry E_S.
3. For each scope entry E_S in the 'scope' parameter of the Authorization Request, the AS performs the following actions. a. The AS initializes an empty set of policy entries, namely S_AUX. b. The AS considers all the policy entries related to the Administrator and the Group Manager in question. For each policy entry E_P among those policy entries, and such that the Toid of E_P is different from the Toid of E_S, the AS determines whether every group name matching with the Toid of E_P would also match with the Toid of E_S. If that is the case, then the AS adds E_P to the set S_AUX. The particular way that the AS uses to make a determination is implementation specific. c. If the set S_AUX is empty, the AS proceeds to the next scope entry, if any. Otherwise, for each policy entry E_P in S_AUX, the AS adds to the set S_OUT one scope entry, such that its Toid is the same as in the policy entry E_P, while its Tperm is the AND of the Tperm in the policy entry E_P with the Tperm in the scope entry E_S.
4. For each scope entry E_S in the 'scope' parameter of the Authorization Request, the AS performs the following actions. a. The AS considers all the policy entries related to the Administrator and the Group Manager in question, such that they were never added to the set S_AUX during the previous Steps 2 and 3. For each policy entry E_P among those policy entries, the AS attempts to determine a group name pattern TOID_AUX such that every group name matching with TOID_AUX would also match with the Toid of E_P as well as with the Toid of E_S. The particular way that the AS uses to make a determination is implementation specific. b. If the AS could not determine a group name pattern TOID_AUX for a given policy entry E_P, then the AS proceeds to the next policy entry E_P identified at the previous Step 4a, if any. Otherwise, the AS adds to the set S_OUT one scope entry, such that its Toid is TOID_AUX, while its Tperm is the AND of the Tperm in the policy entry E_P with the Tperm in the scope entry E_S.
5. If the set S_OUT is empty, the Authorization Request has not been successfully verified, and the AS returns an error response as per . Otherwise, the AS uses the scope entries in the set S_OUT as the scope entries for the 'scope' claim to include in the access token, as per the format defined in .

CDDL Model

CDDL model

Document Updates

Version -16 to -17

• Clarified that group names are consistent with the semantics of URI path segments.
• Removed unnecessary normative language.
• Ensured that sourcecode snippets are marked as CDDL in the XML file.
• Fixed nits.

Version -15 to -16

• Removed requirements on operations to be supported by the Administrator.
• More details in the definition of a column in the new IANA registry.
• Added reference to Section 4.1 of RFC 8126.
• Added references to IANA registries.
• Minor fixes and editorial improvements.

Version -14 to -15

• Updated section title (removed "full").
• Updated example of FETCH request to group-configuration resource.
• Used numbered steps to describe operations of some resource handlers.
• Security considerations: handling of URIs that should point to the Group Manager but do not.
• Minor fixes and editorial improvements.

Version -13 to -14

• Aligned with draft-ietf-ace-key-groupcomm-oscore, 'sign_enc_alg' from that document is renamed as 'gp_enc_alg'.
• Fixed error response codes in two error response messages.
• Added the "Operational Considerations" section.
• Clarifications:
  • Secure communications required as per the transport profile of ACE used.
  • Explicitly mentioned the Content-Format used for each message.
  • Effects of overwriting a group configuration on joining nodes and group members.
  • Improved readability of error handling for the DELETE handler.
  • Intended use of default values for configuration/status parameters.
• Fixed examples: spacing and registered/placeholder codepoints.
• Minor fixes in the IANA considerations:
  • Mentioned the registry group including the new registry.
  • Specifications are not required for Expert Review and one might not exist for a registry entry.
• Fixes in the example algorithm in the appendix.
• Updated references.
• Minor fixes and editorial improvements.

Version -12 to -13

• Uri-Path and Location-Path as text strings in examples.
• Removed moot reference to Section 3.4.5.3 of RFC 8949.
• Fixed example to correctly use the I-Regexp flavor from RFC 9485.
• Highlighted that values to register for IANA are suggested.
• Updated references.
• Editorial fixes.

Version -11 to -12

• CBOR diagnostic notation uses placeholders from a CDDL model.
• Clarified relation between group name and URI path segment.
• /manage is a url-path chosen as an example, but not a default one.
• Recapped concepts of scope and secure communication association.
• Main/optional Administrator is presented more as an example.
• The use of CBOR Tag 35 is not mentioned anymore.
• Added considerations on race conditions with multiple Administrators.
• Clarified requirement for some operations to be atomic.
• Early centralization of what it means to have permissions.
• Improved presentation of default values for the parameters.
• POST (instead of PUT) for overwriting a group-configuration resource.
• Example of inconsistent configuration following a PATCH request.
• Clarified invalid semantics of an iPATCH request.
• Repositioned text from security to operational considerations.
• Revised appendix with an example of name pattern processing at the AS.
• Minor clarifications and editorial improvements.

Version -10 to -11

• Early mentioned that issued access tokens can have other purposes.
• Added example of array of scope entries.
• Removed moot paragraph about the benefits of group name patterns.
• Use of CBOR tag 21065 to indicate a regular expression.
• Renamed 'group_title' as 'group_description'.
• Added a second example of FETCH to the group-collection resource.
• Avoiding accidental deactivation of a group when updating it.
• Avoid alternative ways to create a group configuration resource.
• RFC 9290 is used instead of the custom format for error responses.
• Added integer abbreviations for the new entries in the "ACE Groupcomm Parameters" registry.
• Editorial fixes and improvements.

Version -09 to -10

• Consistent use of 4.03 (Forbidden) error responses.
• Removed moot, remnant statements from when CoRAL was used.
• Clarified how the Group Manager may attempt to determine an alternative group name upon creating a new group.
• Made explicit what parameters cannot change when overwriting a group configuration.
• Improved guidelines to the Group Manager on selecting an alternative group name.
• Improved guidelines to Administrators receiving an error after trying to create a new group.
• Changed description of error 11 from "No available group names" to "Unable to determine a group name".
• Editorial fixes and improvements.

Version -08 to -09

• Removed use of CoRAL.
• Use of the pairwise mode changed to true by default.
• Clarified effects on group members after a group configuration change.
• Renamed "Signature Encryption Algorithm" to "Group Encryption Algorithm".
• Renamed "sign_enc_alg" to "gp_enc_alg".
• Fixes and editorial improvements.

Version -07 to -08

• Consistency of parameter names.
• More details on consistency of message payload.
• New section on multiple, concurrent Administrators.
• Specified atomicity of write operations.
• Clarified effects of configuration overwriting on group members.
• New ACE Groupcomm Error on unsupported configuration.
• Possible reason to deviate from default parameter values.
• Added security considerations.
• CoRAL examples use CBOR diagnostic notation and Packed CBOR.
• Various clarifications and editorial improvements.

Version -06 to -07

• Alignment with renaming in draft-ietf-ace-key-groupcomm.
• Updated signaling of semantics for binary encoded scopes.
• Split between parameter registration and their CBOR abbreviations.
• Classified parameters as must/should/may be supported.
• New error code "No available group names" and related guidelines.
• Fixes in the examples.
• Editorial improvements.

Version -05 to -06

• Use and extend the same AIF data model AIF-OSCORE-GROUPCOMM defined in .
• Revised Client-AS interaction, based on the used AIF data model.
• Categorized operations at the Group Manager as required and optional to support.
• Added status parameter 'gid_reuse', on reassigning OSCORE Group IDs upon group rekeying.
• Clarifications on the group name ultimately chosen by the Group Manager.
• Moved the detailed processing of group name patterns at the AS to an Appendix, as an example.
• Editorial improvements.

Version -04 to -05

• Defined format of scope based on a new AIF data model.
• Specified authorization checks at the Group Manager.
• Revised resource handlers based on the new scope format.
• Renamed 'pub_key_enc' to 'cred_fmt'.
• Mandatory to include 'group_name' in the group creation request.
• Suggesting a used 'group_name' results in a new name, not in an error.
• Distinction between authentication credentials and public keys.
• More details on informing group members about changes in the group configuration.
• Revised order of sections; editorial improvements.

Version -03 to -04

• Clarifications on what to do in case of enhanced error responses.
• Clarifications on handling default values for group parameters.
• New configuration parameters to support OSCORE deterministic requests.
• IANA considerations - Use RFC8126 terminology.
• Author's change of address.
• Editorial improvements.

Version -02 to -03

• Aligned new and old parameters to core-groupcomm-oscore and ace-key-groupcomm-oscore.
• Removed 'cs_key_params' and 'ecdh_key_params' to avoid redundant COSE capabilities of key types, consistently with draft-ietf-ace-key-groupcomm-oscore.
• Revised examples and side effects due to parameter changes.
• New error type "Group currently active".

Version -01 to -02

• Admit multiple Administrators and limited access to admin resources.
• Early design considerations for defining the format of scope.
• Additional error handling, using also error types.
• Selective update of group-configuration resources with PATCH/iPATCH.
• Editorial improvements.

Version -00 to -01

• Names of application groups as status parameter.
• Parameters related to the pairwise mode of Group OSCORE.
• Defined FETCH for group-configuration resources.
• Policies on registration of links to the Resource Directory.
• Added resource type for group-configuration resources.
• Fixes, clarifications and editorial improvements.

Acknowledgments Klaus Hartke provided substantial contribution in defining the resource model based on group collection and group configurations. The authors sincerely thank , , , , , , , , , , , and for their comments and feedback. The work on this document has been partly supported by the Sweden's Innovation Agency VINNOVA and the Celtic-Next projects CRITISEC and CYPRESS; and by the H2020 project SIFIS-Home (Grant agreement 952652).