Key Management for Group Object Security for Constrained RESTful Environments (Group OSCORE) Using Authentication and Authorization for Constrained Environments (ACE)

Key Management for Group Object Security for Constrained RESTful Environments (Group OSCORE) Using Authentication and Authorization for Constrained Environments (ACE) RISE AB

Isafjordsgatan 22 Kista 164 29 Stockholm Sweden marco.tiloca@ri.se

Ericsson AB

Torshamnsgatan 23 Kista 16440 Stockholm Sweden francesca.palombini@ericsson.com

Security ACE Working Group Internet-Draft 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 for a key owned by the Client and bound to an OAuth 2.0 access token.

Introduction The secure communication protocol Object Security for Constrained RESTful Environments (OSCORE) provides application-layer protection for the Constrained Application Protocol (CoAP) , using CBOR Object Signing and Encryption (COSE) and enabling end-to-end security of CoAP messages. As defined in , Group Object Security for Constrained RESTful Environments (Group OSCORE) enables end-to-end security for CoAP group communication , which can employ, for example, IP multicast as underlying data transport. Group OSCORE relies on an entity called Group Manager, which is responsible for managing an OSCORE group and enables the group members to exchange CoAP messages secured with Group OSCORE. The Group Manager can be responsible for multiple groups, coordinates the joining process of new group members, and is entrusted with the distribution and renewal of group keying material. Building on the Authentication and Authorization for Constrained Environments (ACE) framework , the document defines how to request, distribute, and renew keying material and configuration parameters to protect message exchanges in a group communication environment. That is, candidate group members that act as ACE Clients and are authorized to join a group can interact with a Key Distribution Center (KDC) that acts as ACE Resource Server and is responsible for the group. The KDC provides the necessary keying material and parameters to communicate with other group members. While defines the operations and interface available at the KDC, as well as general message formats for the interactions between Clients and the KDC, it delegates details on the communication and security approaches used in a group to separate application profiles. These are specialized instances of that target a particular group communication approach and define how communications in the group are protected, as well as the specific keying material and configuration parameters provided to group members. This document specifies an application profile of . Message exchanges among the participants as well as message formats and processing follow what is specified in , and enable the provisioning and renewing of keying material in group communication scenarios, where Group OSCORE is used to protect CoAP group communication. In particular, network nodes that wish to join an OSCORE group act as ACE Clients, while the Group Manager responsible for managing the OSCORE group is the KDC acting as ACE Resource Server. This application profile leverages protocol-specific transport profiles of ACE (e.g., ), in order to achieve communication security, server authentication, and proof of possession for a key owned by the Client and bound to an OAuth 2.0 access token. overviews the relationships between this document and other related documents mentioned above.

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 described in the ACE framework for authentication and authorization and in the Authorization Information Format (AIF) to express authorization information. The terminology for entities in the considered architecture is defined in OAuth 2.0 . This includes Client (C), Resource Server (RS), and Authorization Server (AS).
The terms and concepts related to the message formats and processing specified in , for provisioning and renewing keying material in group communication scenarios. These include the abbreviations REQx and OPTx denoting the numbered mandatory-to-address and optional-to-address requirements, respectively.
The terms and concepts related to Concise Data Definition Language (CDDL) , Concise Binary Object Representation (CBOR) , and COSE .
The terms and concepts related to CoAP and group communication for CoAP . Unless otherwise indicated, the term "endpoint" is used here following its OAuth definition , aimed at denoting resources such as /token and /introspect at the AS, and /authz-info at the RS. The CoAP definition, which is "[a]n entity participating in the CoAP protocol" , is not used in this document.
The terms and concepts for protection and processing of CoAP messages through OSCORE and through Group OSCORE in group communication scenarios. These especially include:
- Group Manager, as the entity responsible for a set of groups where communications are secured with Group OSCORE. In this document, the Group Manager acts as Resource Server.
- Group Identifier (Gid): identifier assigned to an OSCORE group, unique within the set of groups of a given Group Manager. The Gid value changes every time the OSCORE group is rekeyed.
- Birth Gid: with respect to a group member, the Gid obtained by that group member upon (re-)joining the OSCORE group.
- 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 .

Additionally, this document makes use of the following terminology:

Requester: member of an OSCORE group that sends request messages to other members of the group.
Responder: member of an OSCORE group that receives request messages from other members of the group. A responder may reply back, by sending a response message to the requester which has sent the request message.
Monitor: member of an OSCORE group that is configured as responder and never sends response messages protected with Group OSCORE. This corresponds to the term "silent server" used in .
Signature verifier: entity external to the OSCORE group and intended to verify the signature of messages exchanged in the group that are protected with the group mode (see Sections , , and of ). An authorized signature verifier does not join the OSCORE group as an actual member. However, it can interact with the Group Manager in order to retrieve what is needed to perform signature verifications, e.g., the authentication credentials of the current group members and of the Group Manager.
Signature-only group: an OSCORE group that uses only the group mode (see ).
Pairwise-only group: an OSCORE group that uses only the pairwise mode (see ).

Throughout this document, examples for CBOR data items 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 parameters' keys 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'gp_enc_alg': 10, e'sign_alg': -8} stands for {9: 10, 10: -8}. 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.

Protocol Overview Group communication for CoAP is defined in and can be secured by using Group OSCORE . A network node can join an OSCORE group by interacting with the responsible Group Manager. Once registered in the group, the new node can securely exchange messages with other group members. This document describes how to use and to perform a number of authentication, authorization, and key distribution actions as overviewed in , when the considered group is specifically an OSCORE group. After joining the group as defined in this application profile, a group member communicate with other other group members using CoAP as well as CoAP for group communication (REQ22). Such communications are protected using the security protocol Group OSCORE (REQ23). With reference to :

The node wishing to join the OSCORE group, i.e., the joining node, is the Client.
The Group Manager is the KDC, acting as a Resource Server.
The Authorization Server associated with the Group Manager is the AS.

A node performs the steps described in Sections and of in order to obtain an authorization for joining an OSCORE group and then to join that group. The format and processing of messages exchanged during such steps are further specified in and of this document. All communications between the involved entities (Client, Group Manager, Authorization Server) MUST occur and be secured in accordance with the protocol-specific transport profile of ACE used. In particular, communications between the Client and the Group Manager leverage transport profiles of ACE to achieve communication security, proof of possession, and server authentication (REQ24). It is expected that, in the commonly referred base-case of this document, the transport profile to use is pre-configured and well-known to nodes participating in constrained applications. With respect to what is defined in :

The interface provided by the Group Manager extends the original interface defined in for the KDC, as specified in of this document.
In addition to those defined in , additional parameters are defined in this document and summarized in .
In addition to those defined in , additional error identifiers are defined in this document and summarized in .

Finally, compiles the list of requirements for this application profile of ACE and how they are fulfilled, consistently with the list of requirements defined in .

Format of Scope Building on the definition in considered in the ACE framework , scope denotes: the permissions that the Client seeks to obtain from the AS for accessing resources at a Resource Server; and the permissions that the AS actually issues to the Client following its request. This process is detailed in Sections and of . Consistent with the above and building on , this section defines the exact format and encoding of scope that is used in this profile. To this end, this profile uses the Authorization Information Format (AIF) . 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. This document defines the new AIF data model AIF-OSCORE-GROUPCOMM, which this profile MUST use to format and encode scope entries. For each scope entry:

The object identifier ("Toid") is specialized as a CBOR data item specifying the names of the groups pertaining to the scope entry.
The permission set ("Tperm") is specialized as a CBOR unsigned integer with value R, specifying the permissions that the Client wishes to have in the groups indicated by "Toid".

For the application profile of defined in this document, a scope entry includes the name of an OSCORE group and the set of roles to take in that OSCORE group as a set of permissions. Specifically:

The object identifier ("Toid") is a CBOR text string, specifying the group name for the scope entry.
The permission set ("Tperm") is a CBOR unsigned integer with value R, specifying the role(s) that the Client wishes to take in the group (REQ1). The value R is computed as follows.
- Each role in the permission set is converted into the corresponding numeric identifier X from the "Value" column of the "Group OSCORE Roles" registry defined in of this document, for which the initial entries are specified in .
- The set of N numbers is converted into the single value R, 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.

Numeric Identifier of Roles in an OSCORE Group

Name	Value	Description
Reserved	0	This value is reserved
Requester	1	Send protected requests; receive protected responses
Responder	2	Send protected responses; receive protected requests
Monitor	3	Receive protected requests; never send protected messages
Verifier	4	Verify signature of intercepted messages protected with the group mode

The following CDDL notation defines a scope entry that uses the AIF-OSCORE-GROUPCOMM data model and expresses a set of Group OSCORE roles from those in . oscore-gname = tstr ; Group name oscore-gperm = uint .bits group-oscore-roles group-oscore-roles = &( Requester: 1, Responder: 2, Monitor: 3, Verifier: 4 ) scope_entry = [oscore-gname, oscore-gperm] ]]> Future specifications that define new Group OSCORE roles MUST register a corresponding numeric identifier in the "Group OSCORE Roles" registry. Note that the value 0 is not available to use as numeric identifier to specify a Group OSCORE role. It follows that, when expressing Group OSCORE roles to take in a group as per this document, a scope entry has the least significant bit of "Tperm" always set to 0. This is an explicit feature of the AIF-OSCORE-GROUPCOMM data model. That is, for each scope entry, the least significant bit of "Tperm" set to 0 explicitly identifies the scope entry as exactly expressing a set of Group OSCORE roles ("Tperm"), which pertains to a single group whose name is specified by the string literal in "Toid". Instead, by relying on the same AIF-OSCORE-GROUPCOMM data model, defines the format of scope entries for Administrator Clients that wish to access an admin interface at the Group Manager. In such scope entries, the least significant bit of "Tperm" is always set to 1. As per the guidelines in , and register the specific instance of "Toid" and "Tperm" as media type parameters and a corresponding Content-Format (REQ2).

Authentication Credentials Source authentication of a message sent within the group and protected with Group OSCORE is ensured by means of a digital signature embedded in the message (in group mode), or by integrity-protecting the message with pairwise keying material derived from the asymmetric keys of the sender and recipient (in pairwise mode). Therefore, group members must be able to retrieve each other's authentication credentials from a trusted repository, in order to verify source authenticity of incoming group messages. As discussed in , the Group Manager acts as trusted repository of the authentication credentials of the group members, and provides those authentication credentials to group members if requested to. Upon joining an OSCORE group, a joining node is thus expected to provide its authentication credential to the Group Manager (see ). Later on as a group member, that node can provide the Group Manager with a different authentication credential that replaces the old one (see ). In either situation, the authentication credential can be provided within a chain or a bag (e.g., as the end-entity certificate in a chain of certificates), in which case the Group Manager stores the whole chain or bag. Consistently, the Group Manager specifies the whole chain or bag when providing that authentication credential, within the 'creds' parameter of a Join Response (see ) or of an Authentication Credential Response (see ). In the following circumstances, a joining node is not required to provide its authentication credential to the Group Manager when joining an OSCORE group.

The joining node is going to join the group exclusively as monitor, i.e., it is not going to send protected messages to the group. In this case, the joining node is not required to provide its own authentication credential to the Group Manager, which thus does not have to perform any check related to the format of the authentication credential, to a signature or ECDH algorithm, and to possible parameters associated with the algorithm and the public key. If the joining node still provides an authentication credential in the 'client_cred' parameter of the Join Request (see ), the Group Manager silently ignores that parameter and the related parameter 'client_cred_verify'.
The joining node is currently a group member acting not exclusively as monitor, and it is re-joining the group not exclusively as monitor. In this case, if the joining node intends to use the same authentication credential that it is currently using in the group, i.e., its latest authentication credential provided to the Group Manager (in a previous Join Request or Authentication Credential Update Request, see ), then the joining node MAY choose to omit its current authentication credential in the Join Request. As defined in , this is achieved by setting the value of the 'client_cred' parameter in the Join Request to the empty CBOR byte string (0x40) and omitting the 'client_cred_verify' parameter in the Join Request (see ).

Authorization to Join a Group This section builds on and is organized as follows. First, and describe how the joining node interacts with the AS, in order to be authorized to join an OSCORE group under a given Group Manager and to obtain an access token. Then, describes how the joining node transfers the obtained access token to the Group Manager. This section considers a joining node that intends to contact the Group Manager for the first time. Note that what is defined in applies, and only additions or modifications to that specification are defined in this document.

Authorization Request The Authorization Request message is as defined in , with the following additions.

If the 'scope' parameter is present:
- The value of the CBOR byte string encodes a CBOR array, whose format MUST follow the data model AIF-OSCORE-GROUPCOMM defined in of this document. For each OSCORE group to join:
  - The group name is encoded as a CBOR text string.
  - The set of requested roles is expressed as a single CBOR unsigned integer. This is computed as defined in of this document, from the numerical abbreviations of each requested role defined in the "Group OSCORE Roles" registry (REQ1).

The textual format specified in is not used in this application profile (OPT1).

Authorization Response The Authorization Response message is as defined in , with the following additions:

The AS MUST include the 'expires_in' parameter.
The AS MUST include the 'scope' parameter, when the value included in the access token differs from the one specified by the joining node in the Authorization Request. In such a case, the second element of each scope entry MUST be present and specifies the set of roles that the joining node is actually authorized to take in the OSCORE group for that scope entry, encoded as specified in of this document.

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 of this document (REQ28). 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 registered in of this document. 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 defined for this application profile in of this document.

Token Transferring The exchange of Token Transfer Request and Token Transfer Response is defined in . In addition to that, the following applies.

The Token Transfer Request MAY additionally contain the following parameters, which, if included, MUST have the corresponding values defined below (OPT2):
- 'ecdh_info' defined in of this document, with value the CBOR simple value null (0xf6) to request information about the ECDH algorithm, the ECDH algorithm parameters, the ECDH key parameters, and the exact format of authentication credentials used in the OSCORE groups that the Client has been authorized to join. This is relevant in case the joining node supports the pairwise mode of Group OSCORE .
- 'kdc_dh_creds' defined in of this document, with value the CBOR simple value null (0xf6) to request the Diffie-Hellman authentication credentials of the Group Manager for the OSCORE groups that the Client has been authorized to join. That is, each of such authentication credentials includes a Diffie-Hellman public key of the Group Manager. This is relevant in case the joining node supports the pairwise mode of Group OSCORE and the access token authorizes to join pairwise-only groups.
Alternatively, the joining node may retrieve this information by other means.
In the Token Transfer Response, the 'kdcchallenge' parameter contains a dedicated nonce N_S generated by the Group Manager. As to the N_S value, it is RECOMMENDED to be at least 8-byte long and it is RECOMMENDED to be a random value. The joining node can use this nonce in order to prove the possession of its own private key upon joining the group (see of this document). The 'kdcchallenge' parameter MAY be omitted from the Token Transfer Response, if the 'scope' of the access token specifies only the role "monitor", or only the role "verifier", or only the two roles combined, for each and every of the specified groups.
If the 'sign_info' parameter is present in the Token Transfer Response, the following applies for each element 'sign_info_entry'.
- 'id' is associated exclusively with OSCORE groups that are not pairwise-only groups.
- 'sign_alg' takes value from the "Value" column of the "COSE Algorithms" registry (REQ3).
- 'sign_parameters' has the same format and value of the COSE capabilities array for the algorithm indicated in 'sign_alg', as specified for that algorithm in the "Capabilities" column of the "COSE Algorithms" registry (REQ4).
- 'sign_key_parameters' has the same format and value of the COSE capabilities array for the COSE key type of the keys used with the algorithm indicated in 'sign_alg', as specified for that key type in the "Capabilities" column of the "COSE Key Types" registry (REQ5).
- 'cred_fmt' takes value from the "Label" column of the "COSE Header Parameters" registry (REQ6). To align with , acceptable values denote a format of authentication credential that provides the public key as well as a comprehensive set of information related to the public key algorithm, including, e.g., the elliptic curve used. At the time of writing this specification, acceptable formats of authentication credentials are CBOR Web Tokens (CWTs) and CWT Claims Sets (CCSs) , X.509 certificates , and C509 certificates . Further formats may be available in the future, and they would be acceptable to use as long as they comply with the criteria defined above.
This format is consistent with every signature algorithm currently considered in , i.e., with algorithms that have only the COSE key type as their COSE capability. describes how the format of each 'sign_info_entry' can be generalized for possible future registered algorithms that have a different set of COSE capabilities.
If the 'ecdh_info' parameter is present in the Token Transfer Response, the following applies for each element 'ecdh_info_entry'.
- 'id' is associated exclusively with OSCORE groups that are not signature-only groups.
- 'ecdh_alg' takes value from the "Value" column of the "COSE Algorithms" registry .
- 'ecdh_parameters' has the same format and value of the COSE capabilities array for the algorithm indicated in 'ecdh_alg', as specified for that algorithm in the "Capabilities" column of the "COSE Algorithms" registry .
- 'ecdh_key_parameters' has the same format and value of the COSE capabilities array for the COSE key type of the keys used with the algorithm indicated in 'ecdh_alg', as specified for that key type in the "Capabilities" column of the "COSE Key Types" registry .
- 'cred_fmt' takes value from the "Label" column of the "COSE Header Parameters" registry . To align with , acceptable values denote a format of authentication credential that provides the public key as well as a comprehensive set of information related to the public key algorithm, including, e.g., the elliptic curve used. The same considerations provided above on acceptable formats currently available for the 'cred_fmt' element of 'sign_info' apply.
The Group Manager omits the 'ecdh_info' parameter in the Token Transfer Response even if 'ecdh_info' is included in the Token Transfer Request, in case all the OSCORE groups that the Client is authorized to join are signature-only groups.
If the 'kdc_dh_creds' parameter is present in the Token Transfer Response, the following applies for each element 'kdc_dh_creds_entry'.
- 'id' is associated exclusively with OSCORE groups that are pairwise-only groups.
- 'cred_fmt' takes value from the "Label" column of the "COSE Header Parameters" registry . To align with , acceptable values denote a format of authentication credential that provides the public key as well as a comprehensive set of information related to the public key algorithm, including, e.g., the elliptic curve used. The same considerations provided above on acceptable formats currently available for the 'cred_fmt' element of 'sign_info' apply.
The Group Manager omits the 'kdc_dh_creds' parameter in the Token Transfer Response even if 'ecdh_info' is included in the Token Transfer Request, in case none of the OSCORE groups that the Client is authorized to join is a pairwise-only group.

Note that, other than through the above parameters as defined in , the joining node may have obtained such information by alternative means. For example, information conveyed in the 'sign_info' and 'ecdh_info' parameters may have been pre-configured, or the joining node may early retrieve it, e.g., by using the approach described in to discover the OSCORE group and the link to the associated group-membership resource at the Group Manager (OPT3).

'ecdh_info' Parameter The 'ecdh_info' parameter is an OPTIONAL parameter of the request and response messages exchanged between the Client and the /authz-info endpoint at the RS (see ). This parameter allows the Client and the RS to exchange information about an ECDH algorithm as well as about the authentication credentials and public keys to accordingly use for deriving Diffie-Hellman secrets. Its exact semantics and content are application specific. In application profiles that build on , this parameter is used to exchange information about the ECDH algorithm as well as about the authentication credentials and public keys to be used with it, in the groups indicated by the transferred access token as per its 'scope' claim (see ). When used in the Token Transfer Request sent to the KDC (see ), the 'ecdh_info' parameter specifies the CBOR simple value null (0xf6). This is done to ask for information about the ECDH algorithm and about the authentication credentials used to compute static-static Diffie-Hellman shared secrets , in the groups that the Client has been authorized to join or interact with. When used in the following Token Transfer Response from the KDC (see ), the 'ecdh_info' parameter is a CBOR array of one or more elements. The number of elements is at most the number of groups that the Client has been authorized to join or interact with. Each element contains information about ECDH parameters and about authentication credentials for one or more groups and is formatted as follows.

The first element 'id' is a group name or a CBOR array of group names, which is associated with groups for which the next four elements apply. Each specified group name is a CBOR text string and is hereafter referred to as 'gname'.
The second element 'ecdh_alg' is a CBOR integer or a text string that indicates the ECDH algorithm used in the groups identified by the 'gname' values. For application profiles of that use the 'ecdh_info' parameter, it is REQUIRED to define specific values that 'ecdh_alg' can take, which are selected from the set of signing algorithms of the "COSE Algorithms" registry .
The third element 'ecdh_parameters' is a CBOR array that indicates the parameters of the ECDH algorithm used in the groups identified by the 'gname' values. Its content depends on the value of 'ecdh_alg'. For application profiles of that use the 'ecdh_info' parameter, it is REQUIRED to define the possible values and structure for the elements of 'ecdh_parameters'.
The fourth element 'ecdh_key_parameters' is a CBOR array that indicates the parameters of the key used with the ECDH algorithm in the groups identified by the 'gname' values. Its content depends on the value of 'ecdh_alg'. For application profiles of that use the 'ecdh_info' parameter, it is REQUIRED to define the possible values and structure for the elements of 'ecdh_key_parameters'.
The fifth element 'cred_fmt' either is a CBOR integer indicating the format of authentication credentials used in the groups identified by the 'gname' values or is the CBOR simple value null (0xf6), which indicates that the KDC does not act as a repository of authentication credentials for group members. Its acceptable integer values are taken from the "Label" column of the "COSE Header Parameters" registry , with some of those values also indicating the type of container to use for exchanging the authentication credentials with the KDC (e.g., a chain or bag of certificates). For application profiles of that use the 'ecdh_info' parameter, it is REQUIRED to define specific values to use for 'cred_fmt', consistently with the acceptable formats of authentication credentials.

If 'ecdh_info' is included in the Token Transfer Request, the KDC SHOULD include the 'ecdh_info' parameter in the Token Transfer Response, as per the format defined above. Note that the field 'id' of each 'ecdh_info_entry' specifies the name or array of group names to which that 'ecdh_info_entry' applies. As an exception, the KDC MAY omit the 'ecdh_info' parameter in the Token Transfer Response even if 'ecdh_info' is included in the Token Transfer Request, in case none of the groups that the Client is authorized to join uses an ECDH algorithm to derive Diffie-Hellman secrets. The CDDL notation of the 'ecdh_info' parameter is given below. This format is consistent with every ECDH algorithm currently defined in , i.e., with algorithms that have only the COSE key type as their COSE capability. of this document describes how the format of each 'ecdh_info_entry' can be generalized for possible future registered algorithms that have a different set of COSE capabilities.

'kdc_dh_creds' Parameter The 'kdc_dh_creds' parameter is an OPTIONAL parameter of the request and response messages exchanged between the Client and the /authz-info endpoint at the RS (see ). This parameter allows the Client to request and retrieve the Diffie-Hellman authentication credentials of the RS, i.e., authentication credentials including a Diffie-Hellman public key of the RS. In application profiles that build on , this parameter is used to request and retrieve from the KDC its Diffie-Hellman authentication credentials to use, in the groups indicated by the transferred access token as per its 'scope' claim (see ). When used in the Token Transfer Request sent to the KDC (see ), the 'kdc_dh_creds' parameter specifies the CBOR simple value null (0xf6). This is done to ask for the Diffie-Hellman authentication credentials that the KDC uses in the groups that the Client has been authorized to join or interact with. When used in the following Token Transfer Response from the KDC (see ), the 'kdc_dh_creds' parameter is a CBOR array of one or more elements. The number of elements is at most the number of groups that the Client has been authorized to join or interact with. Each element contains information about the KDC's Diffie-Hellman authentication credentials for one or more groups and is formatted as follows.

The first element 'id' is a group name or a CBOR array of group names, which is associated with groups for which the next two elements apply. Each specified group name is a CBOR text string and is hereafter referred to as 'gname'.
The second element 'cred_fmt' is a CBOR integer indicating the format of the KDC's authentication credential used in the groups identified by the 'gname' values and specified by the following element 'cred'. Its acceptable integer values are taken from the "Label" column of the "COSE Header Parameters" registry , with some of those values also indicating the type of container to use for exchanging the authentication credentials with the KDC (e.g., a chain or bag of certificates). For application profiles of that use the 'kdc_dh_creds' parameter, it is REQUIRED to define specific values to use for 'cred_fmt', consistently with the acceptable formats of the KDC's authentication credentials.
The third element 'cred' is a CBOR byte string encoding the original binary representation of the Diffie-Hellman authentication credential that the KDC uses in the groups identified by the 'gname' values. The authentication credential complies with the format specified by the 'cred_fmt' element.

If 'kdc_dh_creds' is included in the Token Transfer Request, the KDC SHOULD include the 'kdc_dh_creds' parameter in the Token Transfer Response, as per the format defined above. Note that the field 'id' of each 'kdc_dh_creds_entry' specifies the name or array of group names to which that 'kdc_dh_creds_entry' applies. As an exception, the KDC MAY omit the 'kdc_dh_creds' parameter in the Token Transfer Response even if 'kdc_dh_creds' is included in the Token Transfer Request, in case the KDC does not use a Diffie-Hellman authentication credential in any of the groups that the Client is authorized to join. The CDDL notation of the 'kdc_dh_creds' parameter is given below.

Group Joining This section describes the interactions between the joining node and the Group Manager to join an OSCORE group. The message exchange between the joining node and the Group Manager consists of the messages defined in . Note that what is defined in applies, and only additions or modifications to that specification are defined in this document.

Send the Join Request The joining node requests to join the OSCORE group by sending a Join Request message to the related group-membership resource at the Group Manager, as per . Additionally to what is defined in , the following applies.

The 'scope' parameter MUST be included. Its value encodes one scope entry with the format defined in , indicating the group name and the role(s) that the joining node wants to take in the group. The 'scope' parameter MUST NOT specify any of the following sets of roles: ("requester", "monitor") and ("responder", "monitor"). Future specifications that define a new role for members of OSCORE groups MUST define possible sets of roles (including the new role and existing roles) that are not acceptable to specify in the 'scope' parameter of a Join Request.
The 'get_creds' parameter is present only if the joining node wants to retrieve the authentication credentials of the group members from the Group Manager during the joining process (see ). Otherwise, this parameter MUST NOT be present. If this parameter is present and its value is not the CBOR simple value null (0xf6), each element of the inner CBOR array 'role_filter' is encoded as a CBOR unsigned integer, with the same value of a permission set ("Tperm") indicating that role or combination of roles in a scope entry, as defined in .
The 'cnonce' parameter contains a dedicated nonce N_C generated by the joining node. As to the N_C value, it is RECOMMENDED to be at least 8-byte long and it is RECOMMENDED to be a random value.
If the joining node intends to join the group exclusively as a monitor, then the 'client_cred' parameter and the 'client_cred_verify' parameter MUST be omitted.
If the joining node is currently a group member and intends to use the same authentication credential that it is currently using in the group, then the 'client_cred_verify' parameter MAY be omitted. In case the 'client_cred_verify' parameter is omitted, the value of the 'client_cred' parameter MAY specify an empty authentication credential, i.e., its value is set to the empty CBOR byte string (0x40).
If the 'client_cred_verify' parameter is present, then the proof-of-possession (PoP) evidence included therein is computed as defined below (REQ14).
- Specifically in the case where the joining node is not a current member of the group, the Group Manager might already have achieved proof of possession of the joining node's private key associated with the authentication credential AUTH_CRED_C that the joining node intends to use in the group. That is, the joining node might have already proven the possession of its own private key to the Group Manager. For example, proof-of-possession could have been achieved upon completing the establishment of the secure communication association that is used to protect the Join Request, if the joining node used AUTH_CRED_C to authenticate itself with the Group Manager. Under these circumstances, the joining node MAY specify an empty PoP evidence, i.e., it sets the value of the 'client_cred_verify' parameter to the empty CBOR byte string (0x40).
- If the conditions above do not hold or the joining node prefers to compute a non-empty PoP evidence, then the joining node proceeds as follows to prove the possession of its own private key. In either case, the N_S used to build the PoP input is as defined in .
  - If the group is not a pairwise-only group, the PoP evidence MUST be a signature. The joining node computes the signature by using the same private key and signature algorithm that it intends to use for signing messages in the OSCORE group.
  - If the group is a pairwise-only group, the PoP evidence MUST be a MAC computed as follows, by using the HKDF Algorithm HKDF SHA-256, which consists of composing the HKDF-Extract and HKDF-Expand steps . MAC = HKDF(salt, IKM, info, L) The input parameters of HKDF are as follows:
    - salt takes as value the empty byte string.
    - IKM is computed as a cofactor Diffie-Hellman shared secret, see Section 5.7.1.2 of , using the ECDH algorithm used in the OSCORE group. The joining node uses its own Diffie-Hellman private key and the Diffie-Hellman public key of the Group Manager. For X25519 and X448, the procedure is described in .
    - info takes as value the PoP input.
    - L is equal to 8, i.e., the size of the MAC, in bytes.

Value of the N_S Challenge The value of the N_S challenge is determined as follows.

If the joining node has provided the access token to the Group Manager by means of a Token Transfer Request to the /authz-info endpoint as in , then N_S takes the same value of the most recent 'kdcchallenge' parameter received by the joining node from the Group Manager. This can be either the one specified in the Token Transfer Response, or the one possibly specified in a 4.00 (Bad Request) error response to a following Join Request (see ).
If the provisioning of the access token to the Group Manager has relied on the DTLS profile of ACE and the access token was specified in the "psk_identity" field of the ClientKeyExchange message when using DTLS 1.2 , then N_S is an exporter value computed as defined in (REQ15). Specifically, N_S is exported from the DTLS session between the joining node and the Group Manager, using an empty context value (i.e., a context value of zero-length), 32 as length value in bytes, and the exporter label "EXPORTER-ACE-Pop-Input-coap-group-oscore-app" registered in of this document. The same as above holds if TLS 1.2 was used instead of DTLS 1.2, as per .
If the provisioning of the access token to the Group Manager has relied on the DTLS profile of ACE and the access token was specified in the "identity" field of a PskIdentity within the PreSharedKeyExtension of the ClientHello message when using DTLS 1.3 , then N_S is an exporter value computed as defined in (REQ15). Specifically, N_S is exported from the DTLS session between the joining node and the Group Manager, using an empty 'context_value' (i.e., a 'context_value' of zero length), 32 as 'key_length' in bytes, and the exporter label "EXPORTER-ACE-Pop-Input-coap-group-oscore-app" registered in of this document. The same as above holds if TLS 1.3 was used instead of DTLS 1.3, as per .

It is up to applications or future specifications to define how N_S is computed in further alternative settings. provides security considerations on the reuse of the N_S challenge.

Receive the Join Request The Group Manager processes the Join Request as defined in , with the following additions. Note that the Group Manager can determine whether the joining node is a current group member, e.g., based on the ongoing secure communication association that is used to protect the Join Request. In case the joining node is going to join the group exclusively as monitor, then the Group Manager silently ignores the parameters 'client_cred' and 'client_cred_verify', if present. In case the joining node is not going to join the group exclusively as monitor, it is a current member of the group, and the 'client_cred_verify' parameter is not present, then the following applies:

If the 'client_cred' parameter does not specify the empty CBOR byte string (0x40), the Group Manager verifies that it is already storing the authentication credential specified by the parameter, as associated with the joining node in the group. If the verification fails, the Group Manager MUST reply with a 4.00 (Bad Request) error response (OPT8).
If the 'client_cred' parameter specifies the empty CBOR byte string (0x40), the Group Manager verifies that it is already storing an authentication credential, as associated with the joining node in the group. If the verification fails, the Group Manager MUST reply with a 4.00 (Bad Request) error response (OPT8).

In case the joining node is not going to join the group exclusively as monitor and the 'client_cred_verify' parameter specifies the empty CBOR byte string (0x40), the Group Manager checks whether it has already achieved proof of possession of the joining node's private key associated with the authentication credential that is specified in the 'client_cred' parameter. If such verification fails, then the Group Manager MUST reply with a 4.00 (Bad Request) error response. The response MUST have Content-Format set to "application/concise-problem-details+cbor" and is formatted as defined in . Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' field MUST be set to 3 ("Invalid proof-of-possession evidence"). After receiving that response, the client MUST NOT specify an empty PoP evidence in the 'client_cred_verify' parameter of a follow-up Join Request for joining the same group. Note to RFC Editor: Please make sure that "application/concise-problem-details+cbor" is on one line (no line wrapping) on every occurrence and delete this note. In case the joining node is not going to join the group exclusively as monitor and the 'client_cred_verify' parameter specifies a value different from the empty CBOR byte string (0x40), then the Group Manager verifies the PoP evidence therein as follows:

As PoP input, the Group Manager uses the value of the 'scope' parameter from the Join Request as a CBOR byte string, concatenated with N_S encoded as a CBOR byte string, concatenated with N_C encoded as a CBOR byte string. The value of N_S is determined as described in , while N_C is the nonce provided in the 'cnonce' parameter of the Join Request.
As public key of the joining node, the Group Manager uses the one included in the authentication credential retrieved from the 'client_cred' parameter of the Join Request.
If the group is not a pairwise-only group, the PoP evidence is a signature. The Group Manager verifies it by using the public key of the joining node, as well as the signature algorithm used in the OSCORE group and possible corresponding parameters.
If the group is a pairwise-only group, the PoP evidence is a MAC. The Group Manager recomputes the MAC through the same process that is taken by the joining node when preparing the value of the 'client_cred_verify' parameter for the Join Request (see ), with the difference that the Group Manager uses its own Diffie-Hellman private key and the Diffie-Hellman public key of the joining node. The verification succeeds if and only if the recomputed MAC is equal to the MAC conveyed as PoP evidence in the Join Request.

The Group Manager MUST reply with a 5.03 (Service Unavailable) error response in the following cases:

There are currently no OSCORE Sender IDs available to assign in the OSCORE group and, at the same time, the joining node is not going to join the group exclusively as monitor. 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 4 ("No available individual keying material").
The OSCORE group that the joining node has been trying to join is currently inactive (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 9 ("Group currently not active").

The Group Manager MUST reply with a 4.00 (Bad Request) error response in the following cases:

The 'scope' parameter is not present in the Join Request, or it is present and specifies any of the following sets of roles: ("requester", "monitor") and ("responder", "monitor").
The joining node is not going to join the group exclusively as monitor, and any of the following holds:
- The joining node is not a current member of the group, and the 'client_cred' parameter and the 'client_cred_verify' parameter are not both present in the Join Request.
- The 'client_cred_verify' parameter is present in the Join Request, and the value of the 'client_cred' parameter in the Join Request is not an eligible authentication credential (e.g., it is not of the format accepted in the group).
- The 'client_cred_verify' parameter is not present in the Join Request, and the value of the 'client_cred' parameter in the Join Request is neither set to the empty CBOR byte string (0x40) nor an eligible authentication credential (e.g., it is not of the format accepted in the group).

If the Group Manager wants to prevent the acceptance and use of Ed25519 and Ed448 public keys that cannot be successfully converted to Montgomery coordinates, and thus cannot be used for the derivation of pairwise keys (see ), the Group Manager MUST reply with a 4.00 (Bad Request) error response in case all the following conditions hold:

The OSCORE group uses the pairwise mode of Group OSCORE.
The OSCORE group uses EdDSA public keys .
The authentication credential of the joining node from the 'client_cred' parameter includes a public key which:
- Is for the elliptic curve Ed25519 and has its Y coordinate equal to -1 or 1 (mod p), with p = (2²⁵⁵ - 19), see ; or
- Is for the elliptic curve Ed448 and has its Y coordinate equal to -1 or 1 (mod p), with p = (2⁴⁴⁸ - 2²²⁴ - 1), see .

For example, this situation can occur if the joining node does not support the pairwise mode of Group OSCORE or does not intend to use the pairwise mode within the OSCORE group. Unless it is already intended to use Content-Format "application/concise-problem-details+cbor", a 4.00 (Bad Request) error response from the Group Manager to the joining node MUST have Content-Format "application/ace-groupcomm+cbor". In such a case, the response payload is a CBOR map formatted as follows (OPT4):

If the group uses (also) the group mode of Group OSCORE, then the CBOR map MUST contain the 'sign_info' parameter, whose CBOR label is defined in . This parameter has the same format of 'sign_info_res' defined in and includes a single element 'sign_info_entry', which pertains to the OSCORE group that the joining node has tried to join with the Join Request.
If the group uses (also) the pairwise mode of Group OSCORE, then the CBOR map MUST contain the 'ecdh_info' parameter, whose CBOR label is registered in . This parameter has the same format of 'ecdh_info_res' defined in and includes a single element 'ecdh_info_entry', which pertains to the OSCORE group that the joining node has tried to join with the Join Request.
If the group is a pairwise-only group, the CBOR map MUST contain the 'kdc_dh_creds' parameter, whose CBOR label is registered in . This parameter has the same format of 'kdc_dh_creds_res' defined in and includes a single element 'kdc_dh_creds_entry', which pertains to the OSCORE group that the joining node has tried to join with the Join Request.
The CBOR map MAY include the 'kdcchallenge' parameter, whose CBOR label is defined in . If present, this parameter is a CBOR byte string, which encodes a newly generated 'kdcchallenge' value that the Client can use when preparing a new Join Request (see ). In such a case, the Group Manager MUST store the newly generated value as the 'kdcchallenge' value associated with the joining node, thus replacing the currently stored value, if any.

The information conveyed in such a 4.00 (Bad Request) error response with Content-Format "application/ace-groupcomm+cbor" can be especially useful for the joining node, in case the provisioning of the access token to the Group Manager has not relied on a Token Transfer Request to the /authz-info endpoint (see ). Furthermore, specifically if the group is a pairwise-only group, the error response allows the joining node to obtain the Diffie-Hellman authentication credential that the Group Manager uses in the group, as encoded by the 'kdc_dh_creds' parameter. Consequently, the joining node remains able to prove possession of its own private key upon joining the group, through a MAC used as PoP evidence and encoded by the 'client_cred_verify' parameter of the Join Request (see ). Irrespective of the particular case, a joining node can trigger the Group Manager to send such an error response by simply sending an empty Join Request, i.e., a POST request targeting the group-membership resource at the Group Manager and conveying no payload. As per , the Group Manager replies with a 4.00 (Bad Request) error response, having received a request that does not include required fields and thus is not formatted correctly.

Follow-up to a 4.00 (Bad Request) Error Response When receiving a 4.00 (Bad Request) error response, the joining node MAY send a new Join Request to the Group Manager. In such a case:

The 'cnonce' parameter contains a new dedicated nonce N_C generated by the joining node. As to the N_C value, it is RECOMMENDED to be at least 8-byte long and it is RECOMMENDED to be a random value.
In case the joining node is not going to join the group exclusively as monitor, then the following applies:
- The 'client_cred' parameter MUST include an authentication credential in the format indicated by the Group Manager. Also, the authentication credential as well as the included public key MUST be compatible with the signature or ECDH algorithm, and with possible associated parameters.
- If present, the 'client_cred_verify' parameter MUST include a PoP evidence computed as described in . The private key to use is the one associated with the authentication credential specified in the current 'client_cred' parameter, with the signature or ECDH algorithm, and with possible associated parameters indicated by the Group Manager. If the error response from the Group Manager includes the 'kdcchallenge' parameter, the joining node MUST use its content as new N_S challenge to compute the PoP evidence.

Send the Join Response If the processing of the Join Request described in is successful, the Group Manager updates the group membership by registering the joining node NODENAME as a new member of the OSCORE group GROUPNAME, as described in . If the joining node has not taken exclusively the role of monitor, the Group Manager performs also the following actions.

The Group Manager selects an available OSCORE Sender ID in the OSCORE group, and exclusively assigns it to the joining node. The Group Manager MUST NOT assign an OSCORE Sender ID to the joining node if this joins the group exclusively with the role of monitor, according to what is specified in the access token (see ). Consistently with , the Group Manager MUST assign an OSCORE Sender ID that has not been used in the OSCORE group since the latest time when the current Gid value was assigned to the group. The maximum length of a Sender ID in bytes is determined as defined in . If the joining node is recognized as a current group member, e.g., through the ongoing secure communication association that is used to protect the Join Request, then the following also applies:
- The Group Manager MUST assign a new OSCORE Sender ID different from the one currently used by the joining node in the OSCORE group.
- The Group Manager MUST add the old, relinquished OSCORE Sender ID of the joining node to the set of stale Sender IDs associated with the current version of the group keying material for the group (see ).
The Group Manager stores the association between: i) the authentication credential of the joining node; and ii) the Group Identifier (Gid), i.e., the OSCORE ID Context associated with the OSCORE group, together with the OSCORE Sender ID assigned to the joining node in the group. The Group Manager MUST keep this association updated over time.

Then, the Group Manager replies to the joining node, providing the updated security parameters and keying material necessary to participate in the group communication. This success Join Response is formatted as defined in , with the following additions:

The 'gkty' parameter identifies a key of type "Group_OSCORE_Input_Material object", which is registered in of this document (REQ18).
The 'key' parameter includes what the joining node needs in order to set up the Group OSCORE Security Context as per . This parameter has as value a Group_OSCORE_Input_Material object (REQ17), which is defined in this document and extends the OSCORE_Input_Material object encoded in CBOR as defined in . In particular, it contains the additional parameters 'group_senderId', 'cred_fmt', 'gp_enc_alg', 'sign_alg', 'sign_params', 'ecdh_alg', and 'ecdh_params', which are registered in of this document. More specifically, the 'key' parameter is composed as follows.
- The 'hkdf' parameter, if present, specifies the HKDF Algorithm that is used in the OSCORE group. 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 MAY be omitted, if the HKDF Algorithm used in the group is HKDF SHA-256. Otherwise, this parameter MUST be present.
- The 'salt' parameter, if present, has as value the OSCORE Master Salt that is used in the OSCORE group. This parameter MAY be omitted, if the Master Salt used in the group is the empty byte string. Otherwise, this parameter MUST be present.
- The 'ms' parameter has as value the OSCORE Master Secret that is used in the OSCORE group. This parameter MUST be present.
- The 'contextId' parameter has as value the Group Identifier (Gid), i.e., the OSCORE ID Context of the OSCORE group. This parameter MUST be present.
- The 'group_senderId' parameter has as value the OSCORE Sender ID that the Group Manager has assigned to the joining node in the OSCORE group, as described above. This parameter MUST be present if the node does not join the OSCORE group exclusively with the role of monitor, according to what is specified in the access token (see ). Otherwise, this parameter MUST NOT be present.
- The 'cred_fmt' parameter specifies the Authentication Credential Format used in the OSCORE group (see ). This parameter MUST be present and it takes value from the "Label" column of the "COSE Header Parameters" registry (REQ6), with some of those values also indicating the type of container to use for exchanging the authentication credentials with the Group Manager (e.g., a chain or bag of certificates). To align with , acceptable values denote a format that provides the public key as well as a comprehensive set of information related to the public key algorithm. This information includes, e.g., the elliptic curve used. At the time of writing this specification, acceptable formats of authentication credentials are CBOR Web Tokens (CWTs) and CWT Claims Sets (CCSs) , X.509 certificates , and C509 certificates . Further formats may be available in the future, and they would be acceptable to use as long as they comply with the criteria defined above.
The 'key' parameter MUST also include the following parameters, if and only if the OSCORE group is not a pairwise-only group.
- The 'gp_enc_alg' parameter, specifying the Group Encryption Algorithm that is used in the OSCORE group to encrypt messages protected with the group mode. This parameter takes values from the "Value" column of the "COSE Algorithms" registry .
- The 'sign_alg' parameter, specifying the Signature Algorithm that is used in the OSCORE group to sign messages protected with the group mode. This parameter takes values from the "Value" column of the "COSE Algorithms" registry .
- The 'sign_params' parameter, specifying the parameters of the Signature Algorithm. This parameter is a CBOR array, which includes the following two elements:
  - 'sign_alg_capab': a CBOR array, with the same format and value of the COSE capabilities array for the Signature Algorithm indicated in 'sign_alg', as specified for that algorithm in the "Capabilities" column of the "COSE Algorithms" registry .
  - 'sign_key_type_capab': a CBOR array, with the same format and value of the COSE capabilities array for the COSE key type of the keys used with the Signature Algorithm indicated in 'sign_alg', as specified for that key type in the "Capabilities" column of the "COSE Key Types" registry .
The 'key' parameter MUST also include the following parameters, if and only if the OSCORE group is not a signature-only group.
- The 'alg' parameter, specifying the AEAD Algorithm used in the OSCORE group to encrypt messages protected with the pairwise mode.
- The 'ecdh_alg' parameter, specifying the Pairwise Key Agreement Algorithm used in the OSCORE group to derive the pairwise keys for the pairwise mode. This parameter takes values from the "Value" column of the "COSE Algorithms" registry .
- The 'ecdh_params' parameter, specifying the parameters of the Pairwise Key Agreement Algorithm. This parameter is a CBOR array, which includes the following two elements:
  - 'ecdh_alg_capab': a CBOR array, with the same format and value of the COSE capabilities array for the algorithm indicated in 'ecdh_alg', as specified for that algorithm in the "Capabilities" column of the "COSE Algorithms" registry .
  - 'ecdh_key_type_capab': a CBOR array, with the same format and value of the COSE capabilities array for the COSE key type of the keys used with the algorithm indicated in 'ecdh_alg', as specified for that key type in the "Capabilities" column of the "COSE Key Types" registry .
The format of 'key' defined above is consistent with every signature algorithm and ECDH algorithm currently considered in , i.e., with algorithms that have only the COSE key type as their COSE capability. of this document describes how the format of the 'key' parameter can be generalized for possible future registered algorithms that have a different set of COSE capabilities.

Furthermore, the following applies.

The 'exi' parameter MUST be present.
The 'ace_groupcomm_profile' parameter MUST be present and has value coap_group_oscore_app (PROFILE_TBD), which is registered in of this document (REQ19).
The 'creds' parameter, if present, specifies the authentication credentials requested by the joining node by means of the 'get_creds' parameter that was specified in the Join Request. If the joining node has asked for the authentication credentials of all the group members, i.e., the 'get_creds' parameter in the Join Request had as value the CBOR Simple Value null (0xf6), then the Group Manager provides only the authentication credentials of the group members that are relevant to the joining node. That is, in such a case, the 'creds' parameter specifies only: i) the authentication credentials of the responders currently in the OSCORE group, in case the joining node is configured (also) as requester; and ii) the authentication credentials of the requesters currently in the OSCORE group, in case the joining node is configured (also) as responder or monitor.
The 'peer_identifiers' parameter, if present, specifies the OSCORE Sender ID of each group member whose authentication credential is specified in the 'creds' parameter. That is, a group member's Sender ID is used as identifier for that group member (REQ25).
The 'group_policies' parameter SHOULD be present, and SHOULD include the following elements (REQ20):
- "Key Update Check Interval" (see ), with default value 3600;
- "Expiration Delta" (see ), with default value 0.
The 'kdc_cred' parameter MUST be present, specifying the Group Manager's authentication credential in its original binary representation (REQ8). The Group Manager's authentication credential MUST be in the format used in the OSCORE group. Also, the authentication credential as well as the included public key MUST be compatible with the signature or ECDH algorithm, and with possible associated parameters used in the OSCORE group.
The 'kdc_nonce' parameter MUST be present, specifying the dedicated nonce N_KDC generated by the Group Manager. As to the N_KDC value, it is RECOMMENDED to be at least 8-byte long and it is RECOMMENDED to be a random value.
The 'kdc_cred_verify' parameter MUST be present, specifying the proof-of-possession (PoP) evidence computed by the Group Manager to prove the possession of its own private key. The PoP evidence is computed as defined below (REQ21).
- If the group is not a pairwise-only group, then the PoP evidence MUST be a signature. The Group Manager computes the signature by using the signature algorithm used in the OSCORE group, as well as its own private key associated with the authentication credential specified in the 'kdc_cred' parameter.
- If the group is a pairwise-only group, then the PoP evidence MUST be a MAC computed as follows, by using the HKDF Algorithm HKDF SHA-256, which consists of composing the HKDF-Extract and HKDF-Expand steps . MAC = HKDF(salt, IKM, info, L) The input parameters of HKDF are as follows.
  - salt takes as value the empty byte string.
  - IKM is computed as a cofactor Diffie-Hellman shared secret, see Section 5.7.1.2 of , using the ECDH algorithm used in the OSCORE group. The Group Manager uses its own Diffie-Hellman private key and the Diffie-Hellman public key of the joining node. For X25519 and X448, the procedure is described in .
  - info takes as value the PoP input.
  - L is equal to 8, i.e., the size of the MAC, in bytes.
The 'group_rekeying' parameter MAY be omitted, if the Group Manager uses the "Point-to-Point" group rekeying scheme registered in as rekeying scheme in the OSCORE group (OPT9). Its detailed use for this profile is defined in of this document. In any other case, the 'group_rekeying' parameter MUST be included.

As a last action, if the Group Manager reassigns Gid values during the group's lifetime (see ), then the Group Manager MUST store the Gid specified in the 'contextId' parameter of the 'key' parameter, as the Birth Gid of the joining node in the joined group (see ). This applies also in case the joining node is in fact re-joining the group; in such a case, the newly determined Birth Gid overwrites the one currently stored.

Receive the Join Response Upon receiving the Join Response, the joining node retrieves the Group Manager's authentication credential from the 'kdc_cred' parameter. The joining node MUST verify the proof-of-possession (PoP) evidence specified in the 'kdc_cred_verify' parameter of the Join Response as defined below (REQ21).

If the group is not a pairwise-only group, the PoP evidence is a signature. The joining node verifies it by using the public key of the Group Manager from the received authentication credential, as well as the signature algorithm used in the OSCORE group and possible corresponding parameters.
If the group is a pairwise-only group, the PoP evidence is a MAC. The joining node recomputes the MAC through the same process that is taken by the Group Manager when computing the value of the 'kdc_cred_verify' parameter (see ), with the difference that the joining node uses its own Diffie-Hellman private key and the Diffie-Hellman public key of the Group Manager from the received authentication credential. The verification succeeds if and only if the recomputed MAC is equal to the MAC conveyed as PoP evidence in the Join Response.

In case of failed verification of the PoP evidence, the joining node MUST stop processing the Join Response and MAY send a new Join Request to the Group Manager (see ). In case of successful verification of the PoP evidence, the joining node uses the information received in the Join Response to set up the Group OSCORE Security Context, as described in . In particular, the following applies. If the following parameters were not included in the 'key' parameter of the Join Response, then the joining node performs the following actions.

Absent the 'gp_enc_alg' parameter, the parameter Group Encryption Algorithm in the Common Context of the Group OSCORE Security Context is not set.
Absent the 'sign_alg' parameter, the parameter Signature Algorithm in the Common Context of the Group OSCORE Security Context is not set.
Absent the 'alg' parameter, the parameter AEAD Algorithm in the Security Context of the Group OSCORE Security Context is not set.
Absent the 'ecdh_alg' parameter, the parameter Pairwise Key Agreement Algorithm in the Common Context of the Group OSCORE Security Context is not set.

If the following parameters were not included in the 'key' parameter of the Join Response, then the joining node considers the default values specified below, consistently with .

Absent the 'hkdf' parameter, the joining node considers HKDF SHA-256 as the HKDF Algorithm to use in the OSCORE group.
Absent the 'salt' parameter, the joining node considers the empty byte string as the Master Salt to use in the OSCORE group.
Absent the 'group_rekeying' parameter, the joining node considers the "Point-to-Point" group rekeying scheme registered in as the rekeying scheme used in the OSCORE group (OPT9). The detailed use of that rekeying scheme for this profile is defined in of this document.

In addition, the joining node maintains an association between each authentication credential retrieved from the 'creds' parameter and the role(s) that the corresponding group member has in the OSCORE group. From then on, the joining node can exchange group messages secured with Group OSCORE as described in . When doing so:

The joining node MUST NOT process an incoming request message, if protected by a group member whose authentication credential is not associated with the role "Requester".
The joining node MUST NOT process an incoming response message, if protected by a group member whose authentication credential is not associated with the role "Responder".
The joining node MUST NOT use the group mode of Group OSCORE to process messages in the group, if the Join Response did not include both the 'gp_enc_alg' parameter and the 'sign_alg' parameter.
The joining node MUST NOT use the pairwise mode of Group OSCORE to process messages in the group, if the Join Response did not include both the 'alg' parameter and the 'ecdh_alg' parameter.

If the application requires backward security, the Group Manager MUST generate updated security parameters and group keying material, and provide it to the current group members, upon the new node's joining (see ). In such a case, the joining node is not able to access secure communication in the OSCORE group that occurred prior to its joining.

Overview of the Group Rekeying Process In a number of cases, the Group Manager has to generate new keying material and distribute it to the group (rekeying), as also discussed in . To this end the Group Manager MUST support the Group Rekeying Process described in of this document, as an instance of the "Point-to-Point" rekeying scheme defined in and whose identifier is registered in . Future documents may define the use of alternative group rekeying schemes for this application profile, together with the corresponding rekeying message formats. The resulting group rekeying process MUST comply with the functional steps defined in . The initial value of the version number of the group keying material MUST be set to 0 when creating the group (REQ16), e.g., as in . Upon generating the new group keying material and before starting its distribution, the Group Manager MUST increment the version number of the group keying material. When rekeying a group, the Group Manager MUST preserve the current value of the OSCORE Sender ID of each member in that group. The data distributed to a group through a rekeying MUST include:

The new version number of the group keying material for the group.
A new Group Identifier (Gid) for the group as introduced in , which is used as ID Context parameter of the Group OSCORE Common Security Context of that group (see ). Note that the Gid differs from the group name also introduced in , which is a plain, stable, and invariant identifier, with no cryptographic relevance and meaning.
A new value for the Master Secret parameter of the Group OSCORE Common Security Context of that group (see ).
A set of stale Sender IDs, which allows each rekeyed node to purge authentication credentials and Recipient Contexts used in the group and associated with those Sender IDs. This in turn allows every group member to rely on stored authentication credentials, in order to confidently verify the group membership of other sender nodes, when receiving protected messages in the group (see ). More details on the maintenance of stale Sender IDs are provided in .

The data distributed through a group rekeying MAY also include a new value for the Master Salt parameter of the Group OSCORE Common Security Context of that group. The Group Manager MUST rekey the group in the following cases.

The application requires backward security - In this case, the group is rekeyed when a node joins the group as a new member. Therefore, a joining node cannot access communications in the group prior to its joining.
One or more nodes leave the group - That is, the group is rekeyed when one or more current members spontaneously request to leave the group (see ), or when the Group Manager forcibly evicts them from the group, e.g., due to expired or revoked authorization (see ). Therefore, a leaving node cannot access communications in the group after its leaving, thus ensuring forward security in the group. Due to the set of stale Sender IDs distributed through the rekeying, this ensures that a node storing the latest group keying material does not store the authentication credentials of former group members (see Sections and of ).

When the expiration time for the group keying material approaches or has passed, the Group Manager may want to extend the secure group operation, as considered appropriate. If the Group Manager does so, the Group Manager MUST rekey the group. The Group Manager MAY rekey the group for other reasons, e.g., according to an application-specific rekeying period or scheduling.

Stale OSCORE Sender IDs For each OSCORE group, the Group Manager MUST maintain N > 1 sets of "stale" OSCORE Sender IDs. It is up to the application to specify the value of N, possibly on a per-group basis. Each set is uniquely associated with one version of the group keying material, and includes the OSCORE Sender IDs that have become "stale" in the OSCORE group under that version of the group keying material. In the following cases, the Group Manager MUST add an element to the set X associated with the current version of the group keying material.

When a current group member obtains a new Sender ID, its old Sender ID is added to X. This happens when the Group Manager assigns a new Sender ID upon request from the group member (see ), or in case the group member re-joins the group (see and ), thus also obtaining a new Sender ID.
When a current group member leaves the group, its current Sender ID is added to X. This happens when a group member requests to leave the group (see ) or is forcibly evicted from the group (see ).

The value of N can change during the lifetime of the group. If the new value N' is smaller than N, then the Group Manager MUST preserve the sets associated with the (up to) N' most recent versions of the group keying material. When performing a group rekeying (see ) for switching from an old version V of the group keying material to a new version V' = (V + 1), the Group Manager MUST perform the following actions.

Before creating the new group keying material with version V', if the number of sets of stale Sender IDs for the group is equal to N, then the Group Manager deletes the oldest set.
The Group Manager rekeys the group. This includes also distributing the set of stale Sender IDs associated with the version V of the group keying material (see ).
After completing the group rekeying, the Group Manager creates an empty set of stale Sender IDs, as associated with the version V' of the group keying material.

Interface at the Group Manager The Group Manager provides the interface defined in in its entirety (REQ9), with the following additions:

The new FETCH handler is defined for the sub-resource /ace-group/GROUPNAME/kdc-cred (see of this document).
Three new sub-resources are defined (see , , and of this document).

provides a summary of the CoAP methods that are admitted to use for accessing different resources at the Group Manager, for nodes with different roles in the group or as non members (REQ11). The GROUPNAME segment of the URI path MUST match with the group name specified in the scope entry of the scope in the access token (i.e., 'gname' in ) (REQ7). The Resource Type (rt=) Link Target Attribute value "core.osc.gm" is registered in (REQ10), and can be used to describe group-membership resources and its sub-resources at a Group Manager, e.g., by using a CoRE link-format document . Applications can use this common resource type to discover links to group-membership resources for joining OSCORE groups, e.g., by using the approach described in .

/ace-group/GROUPNAME/kdc-cred In addition to what is defined in , this resource also implements a FETCH handler.

FETCH Handler The handler expects a FETCH request, whose payload is a CBOR map including a nonce N_C (see ). In addition to what is defined in , the Group Manager performs the following checks. In case the requesting Client is a current group member or is not authorized to be signature verifier for the group, the Group Manager MUST reply with a 4.03 (Forbidden) error response. The response MUST have Content-Format set to "application/concise-problem-details+cbor" and is formatted as defined in . Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' field MUST be set to 8 ("Operation permitted only to signature verifiers"). In case GROUPNAME denotes a pairwise-only group, the Group Manager MUST reply with a 4.00 (Bad Request) error response. The response MUST have Content-Format set to "application/concise-problem-details+cbor" and is formatted as defined in . Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' field MUST be set to 7 ("Signatures not used in the group"). If all verifications succeed, the handler replies with a 2.05 (Content) response, specifying the authentication credential of the Group Manager together with a proof-of-possession (PoP) evidence as a proof that the Group Manager possesses its own private key. The payload of the response is formatted as defined in .

/ace-group/GROUPNAME/active This resource implements a GET handler.

GET Handler The handler expects a GET request. In addition to what is defined in , the handler verifies that the requesting Client is a current member of the group. If the verification fails, the KDC MUST reply with a 4.03 (Forbidden) error response. The response MUST have Content-Format set to "application/concise-problem-details+cbor" and is formatted as defined in . Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' field MUST be set to 0 ("Operation permitted only to group members"). If all verifications succeed, the handler replies with a 2.05 (Content) response, specifying the current status of the group, i.e., active or inactive. The payload of the response is formatted as defined in . The method to set the current group status is out of the scope of this document, and is defined for the administrator interface of the Group Manager specified in .

/ace-group/GROUPNAME/verif-data This resource implements a GET handler.

GET Handler The handler expects a GET request. In addition to what is defined in , the handler performs the following actions. In case the requesting Client is a current group member or is not authorized to be signature verifier for the group, the Group Manager MUST reply with a 4.03 (Forbidden) error response. The response MUST have Content-Format set to "application/concise-problem-details+cbor" and is formatted as defined in . Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' field MUST be set to 8 ("Operation permitted only to signature verifiers"). In case GROUPNAME denotes a pairwise-only group, the Group Manager MUST reply with a 4.00 (Bad Request) error response. The response MUST have Content-Format set to "application/concise-problem-details+cbor" and is formatted as defined in . Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' field MUST be set to 7 ("Signatures not used in the group"). If all verifications succeed, the handler replies with a 2.05 (Content) response, specifying data that allow also an external signature verifier to verify signatures of messages protected with the group mode of Group OSCORE and sent to the group (see Sections and of ). The response MUST have Content-Format set to "application/ace-groupcomm+cbor". The payload of the response is a CBOR map, which is formatted as defined in .

/ace-group/GROUPNAME/stale-sids This resource implements a FETCH handler.

FETCH Handler The handler expects a FETCH request, whose payload specifies a version number of the group keying material, encoded as an unsigned CBOR integer (see ). In addition to what is defined in , the handler verifies that the requesting Client is a current member of the group. If the verification fails, the Group Manager MUST reply with a 4.03 (Forbidden) error response. The response MUST have Content-Format set to "application/concise-problem-details+cbor" and is formatted as defined in . Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' field MUST be set to 0 ("Operation permitted only to group members"). If all verifications succeed, the handler replies with a 2.05 (Content) response, specifying data that allow the requesting Client to delete the Recipient Contexts and authentication credentials associated with former members of the group (see . The payload of the response is formatted as defined in .

Admitted Methods summarizes the CoAP methods that are admitted for accessing different resources at the Group Manager, for (non-)members of a group with group name GROUPNAME, and considering different roles. The last two rows of the table apply to a node with node name NODENAME. The table uses the following abbreviations.

G = CoAP method GET
F = CoAP method FETCH
P = CoAP method POST
D = CoAP method DELETE
Type1 = Member as Requester and/or Responder
Type2 = Member as Monitor
Type3 = Non-member (authorized to be signature verifier)
Type4 = Non-member (not authorized to be signature verifier)
* = Cannot join the group as signature verifier

Admitted CoAP Methods on the Group Manager Resources

Resource	Type1	Type2	Type3	Type4
/ace-group	F	F	F	F
/ace-group/GROUPNAME	G P	G P	P *	P
/ace-group/GROUPNAME/active	G	G	-	-
/ace-group/GROUPNAME/verif-data	-	-	G	-
/ace-group/GROUPNAME/creds	G F	G F	G F	-
/ace-group/GROUPNAME/kdc-cred	G	G	F	-
/ace-group/GROUPNAME/stale-sids	F	F	-	-
/ace-group/GROUPNAME/policies	G	G	-	-
/ace-group/GROUPNAME/num	G	G	-	-
/ace-group/GROUPNAME/nodes/NODENAME	G P D	G D	-	-
/ace-group/GROUPNAME/nodes/NODENAME/cred	P	-	-	-

Signature Verifiers Just like any candidate group member, a signature verifier provides the Group Manager with an access token, as described in . However, unlike candidate group members, it does not join any OSCORE group, i.e., it does not perform the joining process defined in . After successfully transferring an access token to the Group Manager, a signature verifier is allowed to perform only some operations as non-member of a group, and only for the OSCORE groups specified in the validated access token. These are the operations specified in , , , and . Consistently, in case a node is not a member of the group with group name GROUPNAME and is authorized to be only signature verifier for that group, the Group Manager MUST reply with a 4.03 (Forbidden) error response if that node attempts to access any other endpoint than the following ones:

/ace-group
/ace-group/GROUPNAME/verif-data
/ace-group/GROUPNAME/creds
/ace-group/GROUPNAME/kdc-cred

Operations Supported by Clients Building on what is defined in and with reference to the additional resources at the Group Manager defined in of this document, it is expected that a Client minimally supports also the following set of operations and corresponding interactions with the Group Manager (REQ12).

GET request to /ace-group/GROUPNAME/active, in order to check the current status of the OSCORE group.
GET request to /ace-group/GROUPNAME/verif-data, in order for a signature verifier to retrieve data required to verify signatures of messages protected with the group mode of Group OSCORE and sent to a group (see Sections and of ). Note that this operation is relevant to support only to signature verifiers.
FETCH request to /ace-group/GROUPNAME/stale-sids, in order to retrieve from the Group Manager the data required to delete some of the stored group members' authentication credentials and associated Recipient Contexts (see ). This data is provided as an aggregated set of stale Sender IDs, which are used as specified in .

Additional Interactions with the Group Manager This section defines the possible interactions with the Group Manager, in addition to the group joining specified in .

Retrieve Updated Keying Material At some point, it can happen that a group member considers the Group OSCORE Security Context invalid and to be renewed. This happens, for instance, after a number of unsuccessful security processing of incoming messages from other group members, or when the Security Context expires as specified by the 'exp' or 'exi' parameter of the Join Response. When this happens, the group member retrieves updated security parameters and group keying material. This can occur in the two different ways described below.

Get Group Keying Material If the group member wants to retrieve only the latest group keying material, it sends a Key Distribution Request to the Group Manager. That is, it sends a CoAP GET request to the endpoint /ace-group/GROUPNAME at the Group Manager. The Group Manager processes the Key Distribution Request according to . The Key Distribution Response is formatted as defined in , with the following additions.

The 'key' parameter is formatted as defined in of this document, with the difference that it does not include the 'group_SenderId' parameter.
The 'exi' parameter MUST be present.
The 'exp' parameter SHOULD be present. Omitting the parameter is not desirable for a requesting group member that has a reliable way to synchronize its internal clock with UTC. That is, if the 'exp' parameter is not present, such a requesting group member falls back on using the 'exi' parameter value to less accurately determine the expiration time of the group keying material conveyed by the 'key' parameter.
The 'ace_groupcomm_profile' parameter MUST be present and has value coap_group_oscore_app.

Upon receiving the Key Distribution Response, the group member retrieves the updated security parameters and group keying material, and, if they differ from the current ones, uses them to set up the new Group OSCORE Security Context as described in . This application profile does not specify policies that instruct group members to retain messages and for how long, if those messages are unsuccessfully decrypted (OPT11).

Get Group Keying Material and OSCORE Sender ID If the group member wants to retrieve the latest group keying material as well as the OSCORE Sender ID that it has in the OSCORE group, it sends a Key Distribution Request to the Group Manager. That is, it sends a CoAP GET request to the endpoint /ace-group/GROUPNAME/nodes/NODENAME at the Group Manager. The Group Manager processes the Key Distribution Request according to . The Key Distribution Response is formatted as defined in , with the following additions.

The 'key' parameter is formatted as defined in of this document. If the requesting group member has exclusively the role of monitor, then the 'key' parameter does not include the 'group_SenderId' parameter. Note that, in any other case, the current Sender ID of the group member is not specified as a separate parameter, but instead by the 'group_SenderId' parameter within the 'key' parameter.
The 'exi' parameter MUST be present.
The 'exp' parameter SHOULD be present. Omitting the parameter is not desirable for a requesting group member that has a reliable way to synchronize its internal clock with UTC. That is, if the 'exp' parameter is not present, such a requesting group member falls back on using the 'exi' parameter value to less accurately determine the expiration time of the group keying material conveyed by the 'key' parameter.

Upon receiving the Key Distribution Response, the group member retrieves the updated security parameters, group keying material, and Sender ID, and, if they differ from the current ones, uses them to set up the new Group OSCORE Security Context as described in . This application profile does not specify policies that instruct group members to retain messages and for how long, if those messages are unsuccessfully decrypted (OPT11).

Request to Change Individual Keying Material As discussed in , a group member could at some point exhaust its Sender Sequence Numbers in the OSCORE group. When this happens, the group member MUST send a Key Renewal Request message to the Group Manager, as per . That is, it sends a CoAP POST request to the endpoint /ace-group/GROUPNAME/nodes/NODENAME at the Group Manager. Upon receiving the Key Renewal Request, the Group Manager processes it as defined in , with the following additions. The Group Manager MUST return a 5.03 (Service Unavailable) response in case the OSCORE group identified by GROUPNAME is currently inactive (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 9 ("Group currently not active"). Otherwise, the Group Manager performs one of the following actions.

If the requesting group member has exclusively the role of monitor, the Group Manager replies with a 4.00 (Bad Request) error response. The response MUST have Content-Format set to "application/concise-problem-details+cbor" and is formatted as defined in . Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' field MUST be set to 1 ("Request inconsistent with the current roles").
Otherwise, the Group Manager takes one of the following actions.
- The Group Manager rekeys the OSCORE group. That is, the Group Manager generates new group keying material for that group (see ), and replies to the group member with a group rekeying message as defined in , providing the new group keying material. Then, the Group Manager rekeys the rest of the OSCORE group, as discussed in . The Group Manager SHOULD perform a group rekeying if one is already scheduled to occur within a time frame that is acceptably short, as per application-specific policies at the Group Manager. For instance, a group rekeying could be already upcoming in accordance with an application-specific rekeying period or scheduling, or as a reaction to a recent change in the group membership. If a group rekeying is not already scheduled to occur within an acceptably short time frame, the Group Manager SHOULD NOT rekey the OSCORE group when receiving a Key Renewal Request (OPT12).
- The Group Manager selects and assigns a new OSCORE Sender ID for that group member (REQ27), according to the same criteria defined in for selecting and assigning an OSCORE Sender ID to include in a Join Response. Then, the Group Manager replies with a Key Renewal Response formatted as defined in . The CBOR map in the response payload only includes the 'group_SenderId' parameter registered in of this document, specifying the new Sender ID of the group member encoded as a CBOR byte string (REQ27). Consistently with , the Group Manager MUST assign a new Sender ID that has not been used in the OSCORE group since the latest time when the current Gid value was assigned to the group. Furthermore, the Group Manager MUST add the old, relinquished Sender ID of the group member to the most recent set of stale Sender IDs for the group (see ). The Group Manager MUST return a 5.03 (Service Unavailable) response in case there are currently no Sender IDs available to assign in the OSCORE group. 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 4 ("No available individual keying material").

Retrieve Authentication Credentials of Group Members A group member or a signature verifier may need to retrieve the authentication credentials of (other) group members. To this end, the group member or signature verifier sends an Authentication Credential Request message to the Group Manager, as per Sections and of . That is, it sends the request to the endpoint /ace-group/GROUPNAME/creds at the Group Manager. If the Authentication Credential Request uses the method FETCH, then the Authentication Credential Request is formatted as defined in . That is:

Each element (if any) of the inner CBOR array 'role_filter' is formatted as in the inner CBOR array 'role_filter' of the 'get_creds' parameter of the Join Request when the parameter value is not the CBOR simple value null (0xf6) (see ).
Each element (if any) of the inner CBOR array 'id_filter' is a CBOR byte string, which encodes the OSCORE Sender ID of the group member for which the associated authentication credential is requested (REQ25).

Upon receiving the Authentication Credential Request, the Group Manager processes it as per or , depending on the request method being FETCH or GET, respectively. Additionally, if the Authentication Credential Request uses the method FETCH, the Group Manager silently ignores node identifiers included in the ’get_creds’ parameter of the request that are not associated with any current group member (REQ26). The success Authentication Credential Response is formatted as defined in or , depending on the request method being FETCH or GET, respectively.

Upload a New Authentication Credential A group member may need to provide the Group Manager with its new authentication credential to use in the group from then on, hence replacing the current one. This can be the case, for instance, if the signature or ECDH algorithm and possible associated parameters used in the OSCORE group have been changed, and the current authentication credential is not compatible with them. To this end, the group member sends an Authentication Credential Update Request message to the Group Manager, as per , with the following addition.

To prove the possession of its own private key, the group member computes the proof-of-possession (PoP) evidence included in 'client_cred_verify' in the same way defined in when preparing a Join Request for the OSCORE group in question (REQ14), with the difference that the 'client_cred_verify' parameter MUST NOT specify an empty PoP evidence.

That is, the group member sends a CoAP POST request to the endpoint /ace-group/GROUPNAME/nodes/NODENAME/cred at the Group Manager. Upon receiving the Authentication Credential Update Request, the Group Manager processes it as per , with the following additions.

The N_S challenge that is used to build the proof-of-possession input is computed as defined in (REQ15).
The Group Manager verifies the PoP evidence included in the 'client_cred_verify' parameter in the same way defined in when processing a Join Request for the OSCORE group in question (REQ14), with the difference that the verification MUST fail if the 'client_cred_verify' parameter specifies an empty PoP evidence.
According to the same criteria defined in when processing a Join Request for the OSCORE group in question, the Group Manager MUST return a 4.00 (Bad Request) error response if it wants to prevent the acceptance and use of Ed25519 and Ed448 public keys that cannot be successfully converted to Montgomery coordinates.
The Group Manager MUST return a 5.03 (Service Unavailable) response in case the OSCORE group identified by GROUPNAME is currently inactive (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 9 ("Group currently not active").
If the requesting group member has exclusively the role of monitor, the Group Manager replies with a 4.00 (Bad request) error response. The response MUST have Content-Format set to "application/concise-problem-details+cbor" and is formatted as defined in . Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' field MUST be set to 1 ("Request inconsistent with the current roles").
If the request is successfully processed, the Group Manager stores the association between: i) the new authentication credential of the group member; and ii) the Group Identifier (Gid), i.e., the OSCORE ID Context associated with the OSCORE group, together with the OSCORE Sender ID assigned to the group member in the group. The Group Manager MUST keep this association updated over time.

This application profile does not specify a method for the group member to provide other group members with the identifier of its new authentication credential (OPT13).

Retrieve the Group Manager's Authentication Credential A group member or a signature verifier may need to retrieve the authentication credential of the Group Manager. To this end, the requesting Client sends a KDC Authentication Credential Request message to the Group Manager. defines how this operation is performed by a group member, building on . defines how this operation is performed by a signature verifier, by relying on the additional FETCH handler defined in of this document.

Retrieval for Group Members A group member sends a CoAP GET request to the endpoint /ace-group/GROUPNAME/kdc-cred at the Group Manager as per , where GROUPNAME is the name of the OSCORE group. In addition to what is defined in , the Group Manager MUST respond with a 4.03 (Forbidden) error response, if the requesting Client is not a current group member. 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 0 ("Operation permitted only to group members"). The payload of the 2.05 (Content) KDC Authentication Credential Response is a CBOR map, which is formatted as defined in . The Group Manager specifies the parameters 'kdc_cred', 'kdc_nonce', and 'kdc_cred_verify' as defined for the Join Response in of this document. This especially applies to the computing of the proof-of-possession (PoP) evidence included in 'kdc_cred_verify' (REQ21) that the Group Manager uses to prove the possession of its own private key. Upon receiving a 2.05 (Content) KDC Authentication Credential Response, the requesting Client retrieves the Group Manager's authentication credential from the 'kdc_cred' parameter, and proceeds as defined in . The requesting Client verifies the PoP evidence included in 'kdc_cred_verify' by means of the same method used when processing the Join Response, as defined in of this document (REQ21).

Retrieval for Signature Verifiers A Client signature verifier sends a CoAP FETCH request to the endpoint /ace-group/GROUPNAME/kdc-cred at the Group Manager defined in , where GROUPNAME is the name of the OSCORE group. The request MUST have Content-Format "application/ace-groupcomm+cbor". The payload of the request is formatted as a CBOR map, which MUST contain the following field with the value specified below:

'cnonce': encoded as a CBOR byte string, whose value is a dedicated nonce N_C generated by the Client. As to the N_C value, it is RECOMMENDED to be at least 8-byte long and it is RECOMMENDED to be a random value.

The payload of the 2.05 (Content) KDC Authentication Credential Response is a CBOR map, which is formatted as defined in , with the following difference:

The 'kdc_cred_verify' field specifies the PoP evidence computed by the Group Manager to prove the possession of its own private key. The Group Manager computes the PoP evidence over the following PoP input: the nonce N_C (encoded as a CBOR byte string) concatenated with the nonce N_KDC (encoded as a CBOR byte string), where:
- N_C is the nonce generated by the Client signature verifier and specified in the 'cnonce' field of the received KDC Authentication Credential Request.
- N_KDC is the nonce generated by the Group Manager and specified in the 'kdc_nonce' field of the KDC Authentication Credential Response.

The Group Manager specifies the 'kdc_cred' field and 'kdc_nonce' field as defined for the Join Response in of this document. The computed PoP evidence included in the 'kdc_cred_verify' field is always a signature computed over the PoP input defined above (REQ21). Upon receiving a 2.05 (Content) KDC Authentication Credential Response, the requesting Client retrieves the Group Manager's authentication credential from the 'kdc_cred' parameter. Then, it proceeds as defined in , with the difference that it verifies the PoP evidence included in 'kdc_cred_verify' field by verifying a signature and using the PoP input defined above (REQ21) Note that a signature verifier would not receive a successful response from the Group Manager, in case GROUPNAME denotes a pairwise-only group (see ). gives an overview of the exchange described above, while shows an example of Signature Verification Data Request-Response.

Message Flow of KDC Authentication Credential Request-Response, with a Signature Verifier as Requesting Client | | FETCH /ace-group/GROUPNAME/kdc-cred | | | |<--- KDC Authentication Credential Response: 2.05 (Content) ---| | | ]]>

Example of KDC Authentication Credential Request-Response, with a Signature Verifier as Requesting Client

Retrieve Signature Verification Data A signature verifier may need to retrieve data required to verify signatures of messages protected with the group mode of Group OSCORE and sent to a group (see Sections and of ). To this end, the signature verifier sends a Signature Verification Data Request message to the Group Manager. That is, it sends a CoAP GET request to the endpoint /ace-group/GROUPNAME/verif-data at the Group Manager defined in of this document, where GROUPNAME is the name of the OSCORE group. The payload of the 2.05 (Content) Signature Verification Data Response is a CBOR map, which has the format used for the Join Response message in , with the following differences.

Of the parameters present in the Join Response message, only the parameters 'gkty', 'key', 'num', 'exp', 'exi', and 'ace_groupcomm_profile' are present in the Signature Verification Data Response. The 'key' parameter includes only the following data.
- The parameters 'hkdf', 'contextId', 'cred_fmt', 'gp_enc_alg', 'sign_alg', and 'sign_params'. These parameters MUST be present.
- The parameters 'alg' and 'ecdh_alg'. These parameters MUST NOT be present if the group is a signature-only group. Otherwise, they MUST be present.
The 'sign_enc_key' parameter is also included, with CBOR label registered in . This parameter specifies the Signature Encryption Key of the OSCORE Group, encoded as a CBOR byte string. The Group Manager derives the Signature Encryption Key from the group keying material, as per . This parameter MUST be present.

In order to verify signatures in the group (see ), the signature verifier relies on: the data retrieved from the 2.05 (Content) Signature Verification Data Response; the public keys of the group members signing the messages to verify, retrieved from those members' authentication credentials that can be obtained as defined in ; and the public key of the Group Manager, retrieved from the Group Manager's authentication credential that can be obtained as defined in . gives an overview of the exchange described above, while shows an example of Signature Verification Data Request-Response.

Message Flow of Signature Verification Data Request-Response | | GET /ace-group/GROUPNAME/verif-data | | | |<--- Signature Verification Data Response: 2.05 (Content) ---| | | ]]>

Example of Signature Verification Data Request-Response

Retrieve the Group Policies A group member can request the current policies used in the OSCORE group. To this end, the group member sends a Policies Request, as per . That is, it sends a CoAP GET request to the endpoint /ace-group/GROUPNAME/policies at the Group Manager, where GROUPNAME is the name of the OSCORE group. Upon receiving the Policies Request, the Group Manager processes it as per . The success Policies Response is formatted as defined in .

Retrieve the Keying Material Version A group member can request the current version of the keying material used in the OSCORE group. To this end, the group member sends a Version Request, as per . That is, it sends a CoAP GET request to the endpoint /ace-group/GROUPNAME/num at the Group Manager, where GROUPNAME is the name of the OSCORE group. Upon receiving the Version Request, the Group Manager processes it as per . The success Version Response is formatted as defined in .

Retrieve the Group Status A group member can request the current status of the OSCORE group, i.e., active or inactive. To this end, the group member sends a Group Status Request to the Group Manager. That is, the group member sends a CoAP GET request to the endpoint /ace-group/GROUPNAME/active at the Group Manager defined in of this document, where GROUPNAME is the name of the OSCORE group. The payload of the 2.05 (Content) Group Status Response includes the CBOR Simple Value true (0xf5) if the group is currently active, or the CBOR Simple Value false (0xf4) otherwise. The group is considered active if it is set to allow new members to join, and if communication within the group is fine to occur. Upon learning from a 2.05 (Content) Group Status Response that the group is currently inactive, the group member SHOULD stop sending messages to other group members and MUST stop 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. Upon learning from a 2.05 (Content) Group Status Response that the group has become active again, the group member can resume taking part in communications with other group members (i.e., sending messages and processing incoming messages). gives an overview of the exchange described above, while shows an example of Group Status Request-Response.

Message Flow of Group Status Request-Response | | | |<----------- Group Status Response: 2.05 (Content) -----------| | | ]]>

Example of Group Status Request-Response

Retrieve Group Names A node may want to retrieve from the Group Manager the group name and the URI of the group-membership resource of a group. This is relevant in the following cases.

Before joining a group, a joining node may know only the current Group Identifier (Gid) of that group, but not the group name and the URI of the group-membership resource.
As a current group member in several groups, the node has missed a previous group rekeying in one of them (see ). Hence, it retains stale keying material and fails to decrypt received messages exchanged in that group. Such messages do not provide a direct hint to the correct group name, which the node would need in order to retrieve the latest keying material and authentication credentials from the Group Manager (see , , and ). However, such messages could specify the current Gid of the group, as the value of the 'kid_context' field of the OSCORE CoAP option (see and ).
As a signature verifier, the node also refers to a group name for retrieving the required authentication credentials from the Group Manager (see ). As discussed above, intercepted messages do not provide a direct hint to the correct group name, while they could specify the current Gid of the group, as the value of the 'kid_context' field of the OSCORE CoAP option. In such a case, upon intercepting a message in the group, the node requires to correctly map the Gid currently used in the group with the invariant group name. Since it is not a group member, the node does not take part to a possible group rekeying. Thus, following a group rekeying and the consequent change of Gid in a group, the node would retain the old Gid value and cannot correctly associate intercepted messages with the right group, especially if acting as a signature verifier in several groups. This in turn prevents the efficient verification of signatures, and especially the retrieval of required, new authentication credentials from the Group Manager.

In either case, the node only knows the current Gid of the group, as learned from received or intercepted messages exchanged in the group. As detailed below, the node can contact the Group Manager, and request the group name and URI of the group-membership resource corresponding to that Gid. Then, it can use that information to join the group, or get the latest keying material as a current group member, or retrieve authentication credentials used in the group as a signature verifier. To this end, the node sends a Group Name and URI Retrieval Request, as per . That is, the node sends a CoAP FETCH request to the endpoint /ace-group at the Group Manager formatted as defined in . Each element of the CBOR array 'gid' is a CBOR byte string (REQ13), which encodes the Gid of the group for which the group name and the URI of the group-membership resource are requested. Upon receiving the Group Name and URI Retrieval Request, the Group Manager processes it as per . The success Group Name and URI Retrieval Response is formatted as defined in . Each element of the CBOR array 'gid' is a CBOR byte string (REQ13), which encodes the Gid of the group for which the group name and the URI of the group-membership resource are provided. For each of its groups, the Group Manager maintains an association between the group name and the URI of the group-membership resource on one hand, and only the current Gid for that group on the other hand. That is, the Group Manager does not maintain an association between the former pair and any other Gid for that group than the current, most recent one. gives an overview of the exchanges described above, while shows an example of Group Name and URI Retrieval Request-Response.

Message Flow of Group Name and URI Retrieval Request-Response | | | |<--- Group Name and URI Retrieval Response: 2.05 (Content) -----| | | ]]>

Example of Group Name and URI Retrieval Request-Response

Leave the Group A group member may request to leave the OSCORE group. To this end, the group member sends a Group Leaving Request, as per . That is, it sends a CoAP DELETE request to the endpoint /ace-group/GROUPNAME/nodes/NODENAME at the Group Manager. Upon receiving the Group Leaving Request, the Group Manager processes it as per . Then, the Group Manager performs the follow-up actions defined in of this document.

Removal of a Group Member Other than after a spontaneous request to the Group Manager as described in , a node could be forcibly removed from the OSCORE group, e.g., due to expired or revoked authorization. In either case, if the Group Manager reassigns Gid values during the group's lifetime (see ), the Group Manager "forgets" the Birth Gid currently associated with the leaving node in the OSCORE group. This was stored following the Join Response sent to that node, after its latest (re-)joining of the OSCORE group (see ). If any of the two conditions below holds, the Group Manager MUST inform the leaving node of its eviction as follows. If both conditions hold, the Group Manager MUST inform the leaving node by using only the method corresponding to one of either conditions.

If, upon joining the group (see ), the leaving node specified a URI in the 'control_uri' parameter defined in , then the Group Manager sends a DELETE request targeting the URI specified in the 'control_uri' parameter (OPT7).
If the leaving node has been observing the associated resource at /ace-group/GROUPNAME/nodes/NODENAME, then the Group Manager sends an unsolicited 4.04 (Not Found) error response to the leaving node, as specified in .

Furthermore, the Group Manager might intend to evict all the current group members from the group at once. In such a case, if the Join Responses sent by the Group Manager to nodes joining the group (see ) specify a URI in the 'control_group_uri' parameter defined in , then the Group Manager MUST additionally send a DELETE request targeting the URI specified in the 'control_group_uri' parameter (OPT10). If the leaving node has not exclusively the role of monitor, then the Group Manager performs the following actions.

The Group Manager frees the OSCORE Sender ID value of the leaving node. This value MUST NOT become available for possible upcoming joining nodes in the same group, until the group has been rekeyed and assigned a new Group Identifier (Gid).
The Group Manager MUST add the relinquished Sender ID of the leaving node to the most recent set of stale Sender IDs for the group (see ).
The Group Manager cancels the association between, on one hand, the authentication credential of the leaving node and, on the other hand, the Gid associated with the OSCORE group together with the freed Sender ID value.
The Group Manager deletes the authentication credential of the leaving node, if that authentication credential has no remaining association with any pair (Gid, Sender ID).

Then, the Group Manager MUST generate updated security parameters and group keying material, and provide it to the remaining group members (see ). As a consequence, the leaving node is not able to acquire the new security parameters and group keying material distributed after its leaving. The same considerations from apply here as well, considering the Group Manager acting as KDC.

Group Rekeying Process In order to rekey an OSCORE group, the Group Manager distributes the following information for that group:

A new Group Identifier (Gid), i.e., a new OSCORE ID Context.
A new OSCORE Master Secret.
Optionally, a new OSCORE Master Salt.

Before starting such distribution, the Group Manager MUST increment the version number of the group keying material used in the group. As per , the Group Manager MAY reassign a Gid to the same group over that group's lifetime, e.g., once the whole space of Gid values has been used for the group in question. If the Group Manager supports reassignment of Gid values and performs it in a group, then the Group Manager additionally takes the following actions.

Before rekeying the group, the Group Manager MUST check if the new Gid to be distributed coincides with the Birth Gid of any of the current group members (see ).
If any of such "elder members" is found in the group, then the Group Manager MUST evict them from the 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 elder members. This also includes adding their relinquished Sender IDs to the most recent set of stale Sender IDs for the group (see ), before rekeying the group. Until a further following group rekeying, the Group Manager MUST store the list of those latest-evicted elder members. If any of those nodes re-joins the group before a further following group rekeying occurs, the Group Manager MUST NOT rekey the group upon their re-joining. When one of those nodes re-joins the group, the Group Manager can rely, e.g., on the ongoing secure communication association to recognize the node as included in the stored list.

Throughout the rekeying execution, the Group Manager MUST preserve the same unchanged OSCORE Sender IDs for all group members that are intended to remain in the group. This avoids affecting the retrieval of authentication credentials from the Group Manager and the verification of group messages. The Group Manager MUST support the "Point-to-Point" group rekeying scheme registered in , as per the detailed use defined in of this document. Future specifications may define how this application profile can use alternative group rekeying schemes, which MUST comply with the functional steps defined in . The Group Manager MUST indicate the use of such an alternative group rekeying scheme to joining nodes, by means of the 'group_rekeying' parameter included in Join Response messages (see ). It is RECOMMENDED that the Group Manager gets confirmation of successful distribution from the group members, and admits a maximum number of individual retransmissions to non-confirming group members. Once the group rekeying process has completed, the Group Manager creates a new empty set of stale Sender IDs associated with the version of the newly distributed group keying material (see ). In case the rekeying terminates and some group members have not received the new keying material, such group members will not be able to correctly process following secured messages exchanged in the group. These group members will eventually contact the Group Manager, in order to retrieve the current keying material and its version. Some of these group members may be in multiple groups, each associated with a different Group Manager. When failing to correctly process messages secured with the new keying material, these group members may not have sufficient information to determine which exact Group Manager to contact, in order to retrieve the current keying material that they are missing. If the Gid is formatted as described in , then the Group Prefix can be used as a hint to determine the right Group Manager, as long as no collisions among Group Prefixes are experienced. Otherwise, a group member needs to contact the Group Manager of each group, e.g., by first requesting only the version of the current group keying material (see ) and then possibly requesting the current keying material (see ). Furthermore, some of these group members can be in multiple groups, all of which are associated with the same Group Manager. In this case, these group members may also not have sufficient information to determine which exact group to refer to, when contacting the right Group Manager. Hence, these group members need to contact a Group Manager multiple times, i.e., separately for each group they belong to and associated with that Group Manager. defines the actions performed by a group member upon receiving the new group keying material. discusses how a group member can realize that it has missed one or more rekeying instances, and the actions that it is accordingly required to take.

Sending Rekeying Messages When using the "Point-to-Point" group rekeying scheme, the group rekeying messages MUST have Content-Format set to "application/ace-groupcomm+cbor" and have the same format used for the Join Response message in , with the following differences. Note that this extends the minimal content of a rekeying message as defined in (OPT14).

Of the parameters present in the Join Response message, only the parameters 'gkty', 'key', 'num', 'exp', 'exi', and 'ace_groupcomm_profile' are present. The 'key' parameter includes only the following data.
- The 'ms' parameter, specifying the new OSCORE Master Secret value. This parameter MUST be present.
- The 'contextId' parameter, specifying the new Gid to use as OSCORE ID Context value. This parameter MUST be present.
- The 'salt' value, specifying the new OSCORE Master Salt value. This parameter MAY be present.
The 'stale_node_ids' parameter MUST also be included, with CBOR label registered in . This parameter is encoded as a CBOR array, where each element is encoded as a CBOR byte string. The order of elements in the CBOR array is irrelevant. The parameter is populated as follows.
- The Group Manager creates an empty CBOR array ARRAY.
- The Group Manager considers the most recent set of stale Sender IDs for the group (see ), i.e., the set X associated with the current version of the group keying material that is about to be relinquished.
- For each Sender ID in X, the Group Manager encodes it as a CBOR byte string and adds the result to ARRAY.
- The 'stale_node_ids' parameter takes ARRAY as value.
The parameters 'creds', 'peer_roles', and 'peer_identifiers' SHOULD be present, if the group rekeying is performed due to one or multiple Clients that have requested to join the group. Following the same semantics used in the Join Response message (see ), the three parameters specify the authentication credential, roles in the group, and node identifier of each of the Clients that have requested to join the group. The Group Manager MUST NOT include a non-empty subset of these three parameters.

The Group Manager separately sends a group rekeying message formatted as defined above to each group member to be rekeyed. Each rekeying message MUST be secured with the pairwise secure communication association between the Group Manager and the group member used during the joining process. Each rekeying message can target the 'control_uri' URI path defined in (OPT7), if provided by the intended recipient upon joining the group (see ). This distribution approach requires group members to act (also) as servers, in order to correctly handle unsolicited group rekeying messages from the Group Manager. If a group member and the Group Manager use OSCORE to secure their pairwise communications, then the group member MUST create a Replay Window in its own Recipient Context upon establishing the OSCORE Security Context with the Group Manager, e.g., by means of the OSCORE profile of ACE . Group members and the Group Manager SHOULD additionally support alternative distribution approaches that do not require group members to act (also) as servers. A number of such approaches are defined in . In particular, a group member may use CoAP Observe and subscribe for updates to the group-membership resource of the group, at the endpoint /ace-group/GROUPNAME of the Group Manager (see ). Alternatively, a full-fledged Pub-Sub model can be considered , where the Group Manager publishes to a rekeying topic hosted at a Broker, while the group members subscribe to such topic (see ).

Receiving Rekeying Messages After having received the new group keying material, a group member proceeds as follows. Unless otherwise specified, the following is independent of the group rekeying scheme specifically used. The group member considers the stale Sender IDs received from the Group Manager. If the "Point-to-Point" group rekeying scheme as detailed in is used, the stale Sender IDs are specified by the 'stale_node_ids' parameter. After that, as per , the group member MUST remove every authentication credential associated with a stale Sender ID from its list of group members' authentication credentials used in the group, and MUST delete each of its Recipient Contexts used in the group whose corresponding Recipient ID is a stale Sender ID. Then, the following cases can occur, based on the version number V' of the new group keying material distributed through the rekeying process. If the "Point-to-Point" group rekeying scheme as detailed in is used, this information is specified by the 'num' parameter.

The group member has not missed any group rekeying. That is, the old keying material stored by the group member has version number V, while the received new keying material has version number V' = (V + 1). In such a case, the group member simply installs the new keying material and derives the corresponding new Security Context.
The group member has missed one or more group rekeying instances. That is, the old keying material stored by the group member has version number V, while the received new keying material has version number V' > (V + 1). In such a case, the group member MUST proceed as defined in .
The group member has received keying material not newer than the stored one. That is, the old keying material stored by the group member has version number V, while the received keying material has version number V' < (V + 1). In such a case, the group member MUST ignore the received rekeying messages and MUST NOT install the received keying material.

Missed Rekeying Instances A group member can realize to have missed one or more rekeying instances in one of the ways discussed below. In the following, V denotes the version number of the old keying material stored by the group member, while V' denotes the version number of the latest, possibly just distributed, keying material. a. The group member has participated to a rekeying process that has distributed new keying material with version number V' > (V + 1), as discussed in . b. The group member has obtained the latest keying material from the Group Manager, as a response to a Key Distribution Request (see ) or to a Join Request when re-joining the group (see ). That is, V is different than V' specified by the 'num' parameter in the response. c. The group member has obtained the authentication credentials of other group members, through an Authentication Credential Request-Response exchange with the Group Manager (see ). That is, V is different than V' specified by the 'num' parameter in the response. d. The group member has performed a Version Request-Response exchange with the Group Manager (see ). That is, V is different than V' specified by the 'num' parameter in the response. In either case, the group member MUST delete the stored keying material with version number V. If case (a) or case (b) applies, the group member MUST perform the following actions.

The group member MUST NOT install the latest keying material yet, in case that was already obtained.
The group member sends a Stale Sender IDs Request to the Group Manager (see ), specifying the version number V as payload of the request. If the Stale Sender IDs Response from the Group Manager has no payload, the group member MUST remove all the authentication credentials from its list of group members' authentication credentials used in the group, and MUST delete all its Recipient Contexts used in the group. Otherwise, the group member considers the stale Sender IDs specified in the Stale Sender IDs Response from the Group Manager. Then, the group member MUST remove every authentication credential associated with a stale Sender ID from its list of group members' authentication credentials used in the group, and MUST delete each of its Recipient Contexts used in the group whose corresponding Recipient ID is a stale Sender ID.
The group member installs the latest keying material with version number V' and derives the corresponding new Security Context.

If case (c) or case (d) applies, the group member SHOULD perform the following actions.

The group member sends a Stale Sender IDs Request to the Group Manager (see ), specifying the version number V as payload of the request. If the Stale Sender IDs Response from the Group Manager has no payload, the group member MUST remove all the authentication credentials from its list of group members' authentication credentials used in the group, and MUST delete all its Recipient Contexts used in the group. Otherwise, the group member considers the stale Sender IDs specified in the Stale Sender IDs Response from the Group Manager. Then, the group member MUST remove every authentication credential associated with a stale Sender ID from its list of group members' authentication credentials used in the group, and MUST delete each of its Recipient Contexts used in the group whose corresponding Recipient ID is a stale Sender ID.
The group member retrieves the latest keying material with version number V' from the Group Manager. This can happen by sending a Key Distribution Request to the Group Manager (see ) and ).
The group member installs the latest keying material with version number V' and derives the corresponding new Security Context.

If case (c) or case (d) applies, the group member can alternatively perform the following actions.

The group member re-joins the group (see ). When doing so, the group member MUST re-join with the same roles that it currently has in the group, and MUST request from the Group Manager the authentication credentials of all the current group members. That is, the 'get_creds' parameter of the Join Request MUST be present and MUST be set to the CBOR Simple Value null (0xf6).
When receiving the Join Response (see ), the group member retrieves the set Z of authentication credentials specified in the 'creds' parameter. Then, the group member MUST remove every authentication credential that is not in Z from its list of group members' authentication credentials used in the group, and MUST delete each of its Recipient Contexts used in the group that does not include any of the authentication credentials in Z.
The group member installs the latest keying material with version number V' and derives the corresponding new Security Context.

Retrieve Stale Sender IDs When realizing to have missed one or more group rekeying instances (see ), a node needs to retrieve from the Group Manager the data required to delete some of its stored group members' authentication credentials and Recipient Contexts (see ). These data are provided as an aggregated set of stale Sender IDs, which are used as specified in . That is, the node sends a CoAP FETCH request to the endpoint /ace-group/GROUPNAME/stale-sids at the Group Manager defined in of this document, where GROUPNAME is the name of the OSCORE group. The payload of the Stale Sender IDs Request MUST include a CBOR unsigned integer. This encodes the version number V of the most recent group keying material stored and installed by the requesting Client, which is older than the latest, possibly just distributed, keying material with version number V'. The handler MUST reply with a 4.00 (Bad Request) error response, if the request is not formatted correctly. Also, the handler MUST respond with a 4.00 (Bad Request) error response, if the specified version number V is greater or equal than the version number V' associated with the latest keying material in the group, i.e., in case V >= V'. Otherwise, the handler responds with a 2.05 (Content) Stale Sender IDs Response. The payload of the response is formatted as defined below, where SKEW = (V' - V + 1).

The Group Manager considers ITEMS as the current number of sets of stale Sender IDs for the group (see ).
If SKEW > ITEMS, the Stale Sender IDs Response MUST NOT have a payload.
Otherwise, the payload of the Stale Sender IDs Response MUST include a CBOR array, where each element is encoded as a CBOR byte string. The order of elements in the CBOR array is irrelevant. The Group Manager populates the CBOR array as follows.
- The Group Manager creates an empty CBOR array ARRAY and an empty set X.
- The Group Manager considers the SKEW most recent sets of stale Sender IDs for the group. Note that the most recent set is the one associated with the latest version of the group keying material.
- The Group Manager copies all the Sender IDs from the selected sets into X. When doing so, the Group Manager MUST discard duplicates. That is, the same Sender ID MUST NOT be present more than once in the final content of X.
- For each Sender ID in X, the Group Manager encodes it as a CBOR byte string and adds the result to ARRAY.
- Finally, ARRAY is specified as payload of the Stale Sender IDs Response. Note that ARRAY might result in the empty CBOR array.

gives an overview of the exchange described above, while shows an example of Stale Sender IDs Request-Response.

Message Flow of Stale Sender IDs Request-Response | | FETCH /ace-group/GROUPNAME/stale-sids | | | |<---------- Stale Sender IDs Response: 2.05 (Content) -------| | | ]]>

Example of Stale Sender IDs Request-Response

ACE Groupcomm Parameters In addition to what is defined in , this application profile defines additional parameters used during the second part of the message exchange with the Group Manager, i.e., after the exchange of Token Transfer Request and Response (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
group_senderId	21	bstr	[RFC-XXXX]
ecdh_info	31	array	[RFC-XXXX]
kdc_dh_creds	32	array	[RFC-XXXX]
sign_enc_key	33	bstr	[RFC-XXXX]
stale_node_ids	34	array	[RFC-XXXX]

Note to RFC Editor: Please replace all occurrences of "[RFC-XXXX]" with the RFC number of this specification and delete this paragraph. The Group Manager is expected to support all the parameters above. Instead, a Client is required to support the new parameters defined in this application profile as specified below (REQ29).

'group_senderId' MUST be supported by a Client that intends to join an OSCORE group with the role of Requester and/or Responder.
'ecdh_info' MUST be supported by a Client that intends to join a group which uses the pairwise mode of Group OSCORE.
'kdc_dh_creds' MUST be supported by a Client that intends to join a group which uses the pairwise mode of Group OSCORE and that does not plan to or cannot rely on an early retrieval of the Group Manager's Diffie-Hellman authentication credential.
'sign_enc_key' MUST be supported by a Client that intends to join a group which uses the group mode of Group OSCORE or to be signature verifier for that group.
'stale_node_ids' MUST be supported.

When the conditional parameters defined in are used with this application profile, a Client must, should, or may support them as specified below (REQ30).

'client_cred' and 'client_cred_verify'. A Client that has an own authentication credential to use in a group MUST support these parameters.
'kdcchallenge'. A Client that has an own authentication credential to use in a group and that provides the access token to the Group Manager through a Token Transfer Request (see ) MUST support this parameter.
'creds_repo'. This parameter is not relevant for this application profile, since the Group Manager always acts as repository of the group members' authentication credentials. Consequently, no encoding is defined for this parameter (OPT6).
'group_policies'. A Client that is interested in the specific policies used in a group, but that does not know them or cannot become aware of them before joining that group, SHOULD support this parameter.
'peer_roles'. A Client MUST support this parameter, since in this application profile it is relevant for Clients to know the roles of the group member associated with each authentication credential.
'kdc_nonce', 'kdc_cred', and 'kdc_cred_verify'. A Client MUST support these parameters, since the Group Manager's authentication credential is required to process messages protected with Group OSCORE (see ).
'mgt_key_material'. A Client that supports an advanced rekeying scheme possibly used in the group, such as based on one-to-many rekeying messages sent by the Group Manager (e.g., over IP multicast), MUST support this parameter.
'control_group_uri'. A Client that supports the hosting of local resources each associated with a group (hence acting as CoAP server) and the reception of one-to-many requests sent to those resources by the Group Manager (e.g., over IP multicast) MUST support this parameter.

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 (OPT5). 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
7	Signatures not used in the group
8	Operation permitted only to signature verifiers
9	Group currently not active

If the Client 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 Client may use that information to determine what actions to take next. If the Concise Problem Details data item specified in the error response includes the 'detail' entry and the Client supports it, such an entry may provide additional context.

In case of error 7, the Client should stop sending the request in question to the Group Manager. In this application profile, this error is relevant only for a signature verifier, in case it tries to access resources related to a pairwise-only group.
In case of error 8, the Client should stop sending the request in question to the Group Manager.
In case of error 9, the Client should wait for a certain (pre-configured) amount of time, before trying to re-send its request to the Group Manager.

Default Values for Group Configuration Parameters This section defines the default values that the Group Manager assumes for the configuration parameters of an OSCORE group, unless differently specified when creating and configuring the group (for example, by means of the admin interface specified in ). A possible reason for the Group Manager to consider default values different from those recommended in this section 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 this document, e.g., to achieve proof of possession of a joining node's private key (see ), as well as to provide a joining node with its own authentication credential and the associated proof-of-possession challenge (see ). The following builds on the "COSE Header Parameters" registry , the "COSE Algorithms" registry , the "COSE Key Types" registry , and the "COSE Elliptic Curves" registry .

Common This section always applies, as related to common configuration parameters.

For the HKDF Algorithm 'hkdf', the Group Manager SHOULD use HKDF SHA-256, defined as default in . In the 'hkdf' parameter, this HKDF Algorithm is specified by the HMAC Algorithm HMAC 256/256 (COSE algorithm encoding: 5).
For the Authentication Credential Format 'cred_fmt', the Group Manager SHOULD use CBOR Web Token Claims Set (CCS) , i.e., the COSE Header Parameter 'kccs' (COSE header parameter encoding: 14).
For 'max_stale_sets', the Group Manager SHOULD consider N = 3 as the maximum number of stored sets of stale Sender IDs for the group (see ).

Group Mode This section applies if the group uses (also) the group mode of Group OSCORE.

For the Group Encryption Algorithm 'gp_enc_alg' used to encrypt messages protected with the group mode, the Group Manager SHOULD use AES-CCM-16-64-128 (COSE algorithm encoding: 10).
For the Signature Algorithm 'sign_alg' used to sign messages protected with the group mode, the Group Manager SHOULD use EdDSA .
For the parameters 'sign_params' of the Signature Algorithm, the Group Manager SHOULD use the following:
- The array [[OKP], [OKP, Ed25519]], in case EdDSA is assumed or specified for 'sign_alg'. This indicates to use the COSE key type OKP and the elliptic curve Ed25519 .
- The array [[EC2], [EC2, P-256]], in case ES256 is specified for 'sign_alg'. This indicates to use the COSE key type EC2 and the elliptic curve P-256.
- The array [[EC2], [EC2, P-384]], in case ES384 is specified for 'sign_alg'. This indicates to use the COSE key type EC2 and the elliptic curve P-384.
- The array [[EC2], [EC2, P-521]], in case ES512 is specified for 'sign_alg'. This indicates to use the COSE key type EC2 and the elliptic curve P-521.
- The array [[RSA], [RSA]], in case PS256, PS384, or PS512 is specified for 'sign_alg'. This indicates to use the COSE key type RSA.

Pairwise Mode This section applies if the group uses (also) the pairwise mode of Group OSCORE.

For the AEAD Algorithm 'alg' used to encrypt messages protected with the pairwise mode, the Group Manager SHOULD use the same default value defined in , i.e., AES-CCM-16-64-128 (COSE algorithm encoding: 10).
For the Pairwise Key Agreement Algorithm 'ecdh_alg' used to compute static-static Diffie-Hellman shared secrets, the Group Manager SHOULD use the following:
- The ECDH algorithm ECDH-SS + HKDF-256 (COSE algorithm encoding: -27), in case the HKDF Algorithm assumed or specified for 'hkdf' is HKDF SHA-256 (specified by the HMAC Algorithm HMAC 256/256).
- The ECDH algorithm ECDH-SS + HKDF-512 (COSE algorithm encoding: -28), in case the HKDF Algorithm specified for 'hkdf' is HKDF SHA-512 (specified by the HMAC Algorithm HMAC HMAC 512/512).
For the parameter 'ecdh_params' of the Pairwise Key Agreement Algorithm, the Group Manager SHOULD use the following:
- The array [[OKP], [OKP, X25519]], in case EdDSA is assumed or specified for 'sign_alg', or in case the group is a pairwise-only group. This indicates to use the COSE key type OKP and the elliptic curve X25519 .
- The array [[EC2], [EC2, P-256]], in case ES256 is specified for 'sign_alg'. This indicates to use the COSE key type EC2 and the elliptic curve P-256.
- The array [[EC2], [EC2, P-384]], in case ES384 is specified for 'sign_alg'. This indicates to use the COSE key type EC2 and the elliptic curve P-384.
- The array [[EC2], [EC2, P-521]], in case ES512 is specified for 'sign_alg'. This indicates to use the COSE key type EC2 and the elliptic curve P-521.

Operational Considerations This section compiles the operational considerations that hold for this document.

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 present application profile, together with a description of the event related to the error and relevant metadata about the Client that has sent the request. For instance, possible metadata include: addressing information of the Client; when applicable (an identifier of) the authentication credential of the Client and the OSCORE Sender ID that is currently assigned to the Client in the group. Note that, if the error response uses the format problem-details defined in , then the optional "details" 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. This is consistent with , which says that the diagnostic description of the error should be logged.
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:
- The (re-)joining of a group.
- The uploading of a new authentication credential to use in the group.
- The obtainment of a new OSCORE Sender ID to use in the group.
- The leaving of a group.
The logged information contains a description of the operation performed in the context of the present application profile, together with relevant metadata about the Client that has sent the request. For instance, possible metadata include: addressing information of the Client; when applicable (an identifier of) the authentication credential of the Client and the OSCORE Sender ID that is currently assigned to the Client in the group.
The execution and successful/unsuccessful completion of a group rekeying instance. The logged information includes:
- The reason that has triggered the group rekeying (e.g., scheduled/periodic occurrence, group joining of a new member, group leaving of a current member).
- A description of the group rekeying operations performed (e.g., a list of steps performed throughout the rekeying process).
- The outcome of the group rekeying instance.
- In case of success, the version number of the newly established group keying material and the newly established Group Identifier (Gid).
The addition of a group member to the group or the eviction of a group member from the group. The logged information also contains relevant metadata about the Client that has been added to or removed from the group. For instance, possible metadata include: addressing information of the Client; when applicable (an identifier of) the authentication credential of the Client and the OSCORE Sender ID that is currently assigned to the Client that has been added to the group or latest assigned to the Client that has been removed from the group.
The creation, (re-)configuration, or termination of a group.

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, such as:

The OSCORE Master Secret used in the group.
The symmetric keying material derived from the OSCORE Master Secret and used in the group, i.e., the Sender/Recipient Keys.
The Signature Encryption Key used in the group, if the group uses the group mode.
The private key associated with the Group Manager’s authentication credential used in the group.
Rekeying messages that are exchanged in the group.
If applicable, administrative keying material used to protect the group rekeying process.

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. Specific semantics and data models can be defined by applications and future specifications. The Group Manager is expected to make the logs produced available to securely access for 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 a Client, i.e., addressing information of the Client and, when applicable, (an identifier of) the authentication credential of the Client. If external management applications and operators obtain such metadata, they become able to track a given Client, as to its interactions with one or multiple Group Managers and its membership in groups under such Group Manager(s). 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 Clients' privacy, e.g., by tracking Clients across different groups and different Group Managers. Exceptions 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.

Administration of Groups With respect to the creation, (re-)configuration, or termination of a group at the Group Manager, the following applies:

Default values for the group configuration parameters are specified in .
The specific method, tools, and data model used to create, (re-)configure, and delete OSCORE groups are out of the scope of this document. A possible method relies on the RESTful admin interface specified in , which also uses the ACE framework for Authentication and Authorization and its transport profiles. Also, it relies on a data model based on CBOR and thus enables multiple administrators to perform administrative operations at the same Group Manager in an interoperable way.

Access Control Building on the ACE framework and the foundation provided in , this application profile enforces access control for 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 role(s) that the requesting Client is authorized to have according to its corresponding access token. Furthermore, the interactions between a Client and the Group Manager are secured as per the specific transport profile of ACE used (e.g., and ).

Security Considerations Security considerations for this profile are inherited from , the ACE framework for Authentication and Authorization , and the specific transport profile of ACE signaled by the AS, such as and . The following security considerations also apply for this profile.

Management of OSCORE Groups This profile leverages the following management aspects related to OSCORE groups and discussed in the sections of referred below.

Management of group keying material (see ). The Group Manager is responsible for the renewal and re-distribution of the keying material in the groups of its competence (rekeying). As defined in , the Group Manager performs a rekeying when one or more members leave the group, thus preserving forward security and ensuring that the security properties of Group OSCORE are fulfilled. According to the specific application requirements, the Group Manager can also rekey the group upon a new node's joining, in case backward security has also to be preserved. The Group Manager can also rekey the group for further reasons, e.g., according to an application-specific rekeying period or scheduling.
Provisioning and retrieval of authentication credentials (see ). The Group Manager acts as repository of authentication credentials of group members, and provides them upon request.
Freshness of messages (see ). This concerns how a recipient node can verify freshness of messages received within the group.

Before sending the Join Response, the Group Manager MUST verify that the joining node actually owns the associated private key. To this end, the Group Manager relies on the proof-of-possession challenge-response defined in . A node may have joined multiple OSCORE groups under different non-synchronized Group Managers. Therefore, it can happen that those OSCORE groups have the same Group Identifier (Gid). It follows that, upon receiving a Group OSCORE message addressed to one of those groups, the node would have multiple Security Contexts matching with the Gid in the incoming message. It is up to the application to decide how to handle such collisions of Group Identifiers, e.g., by trying to process the incoming message using one Security Context at the time until the right one is found (i.e., the incoming message is successfully decrypted and verified).

Size of Nonces as Proof-of-Possesion Challenge With reference to the Join Request message in , the proof-of-possession (PoP) evidence included in 'client_cred_verify' is computed over an input including also N_C | N_S, where | denotes concatenation. As to the N_C value, it is RECOMMENDED to be at least 8-byte long and it is RECOMMENDED to be a random value. Furthermore, N_C is always conveyed in the 'cnonce' parameter of the Join Request, which is always sent over the secure communication association between the joining node and the Group Manager. As defined in , the way the N_S value is computed depends on the particular way the joining node provides the Group Manager with the access token, as well as on following interactions between the two.

If the access token has not been provided to the Group Manager by means of a Token Transfer Request to the /authz-info endpoint as in , then N_S is computed as a 32-byte long challenge. For an example, see points (2) and (3) in .
If the access token has been provided to the Group Manager by means of a Token Transfer Request to the /authz-info endpoint as in , then N_S takes the most recent value provided to the Client by the Group Manager in the 'kdcchallenge' parameter, as specified in point (1) of . This value is provided either in the Token Transfer Response (see ), or in a 4.00 (Bad Request) error response to a following Join Request (see ). The N_S value is RECOMMENDED to be at least 8-byte long and it is RECOMMENDED to be a random value.

If we consider both N_C and N_S to take 8-byte random values, the following considerations hold.

Let us consider the case where the Group Manager never changes the value of the N_S provided to a Client during the lifetime of an access token. Then, as per the birthday paradox, the average collision for N_S will happen after 2³² new transferred access tokens, while the average collision for N_C will happen after 2³² new Join Requests. This amounts to considerably more token provisionings than the expected new joinings to OSCORE groups under a same Group Manager, as well as to considerably more requests to join OSCORE groups from a same Client using a same access token under a same Group Manager.
and recommend the use of 8-byte random values as well. Unlike in those cases, the values of N_C and N_S considered in this document are not used for as sensitive operations as the derivation of a Security Context, and thus do not have possible implications in the security of AEAD ciphers.

Reuse of Nonces for Proof-of-Possession Input When a party A provides a nonce to the other party B, it is beneficial that A does not offer a nonce previously used with B. By doing so, A can verify the freshness of the PoP evidence computed by B. This is practically ensured if parties generate nonces as recommended in this document. If a party generates nonces that are not random values (e.g., by using a counter), the party ought to ensure that values are not reused, even in case of reboot and loss of state. As long as the Group Manager preserves the same N_S value currently associated with an access token, i.e., the latest value provided to a Client in a 'kdcchallenge' parameter, the Client is able to successfully reuse the same proof-of-possession (PoP) input for multiple Join Requests to that Group Manager. In particular, a misbehaving Client can reuse the same N_C value for every Join Request to the Group Manager, and combine it with the same unchanged N_S value. This results in reusing the same PoP input for producing the PoP evidence to include in the 'client_cred_verify' parameter of the Join Requests. Unless the Group Manager maintains a list of N_C values already used by that Client since the latest update to the N_S value associated with the access token, the Group Manager can be forced to falsely believe that the Client possesses its own private key at that point in time, upon verifying the PoP evidence in the 'client_cred_verify' parameter.

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.

OAuth Parameters IANA is asked to register the following entries in the "OAuth Parameters" registry, following the procedure specified in .

Entry #1
- Name: ecdh_info
- Parameter Usage Location: client-rs request, rs-client response
- Change Controller: IETF
- Reference: [RFC-XXXX]
Entry #2
- Name: kdc_dh_creds
- Parameter Usage Location: client-rs request, rs-client response
- Change Controller: IETF
- Reference: [RFC-XXXX]

OAuth Parameters CBOR Mappings IANA is asked to register the following entries in the "OAuth Parameters CBOR Mappings" registry, following the procedure specified in .

Entry #1
- Name: ecdh_info
- CBOR Key: 47 (suggested)
- Value Type: Null or array
- Reference: [RFC-XXXX]
- Original Specification: [RFC-XXXX]
Entry #2
- Name: kdc_dh_creds
- CBOR Key: 48 (suggested)
- Value Type: Null or array
- Reference: [RFC-XXXX]
- Original Specification: [RFC-XXXX]

ACE Groupcomm Parameters IANA is asked to register the following entries to the "ACE Groupcomm Parameters" registry defined in .

Entry #1
- Name: group_senderId
- CBOR Key: 21 (suggested)
- CBOR Type: bstr
- Reference: [RFC-XXXX]
Entry #2
- Name: ecdh_info
- CBOR Key: 31 (suggested)
- CBOR Type: array
- Reference: [RFC-XXXX]
Entry #3
- Name: kdc_dh_creds
- CBOR Key: 32 (suggested)
- CBOR Type: array
- Reference: [RFC-XXXX]
Entry #4
- Name: sign_enc_key
- CBOR Key: 33 (suggested)
- CBOR Type: bstr
- Reference: [RFC-XXXX]
Entry #5
- Name: stale_node_ids
- CBOR Key: 34 (suggested)
- CBOR Type: array
- Reference: [RFC-XXXX]

ACE Groupcomm Key Types IANA is asked to register the following entry in the "ACE Groupcomm Key Types" registry defined in .

Name: Group_OSCORE_Input_Material object
Key Type Value: GROUPCOMM_KEY_TBD (suggested value: 1)
Profile: "coap_group_oscore_app", registered in of [RFC-XXXX].
Description: A Group_OSCORE_Input_Material object encoded as described in of [RFC-XXXX].
Reference: [RFC-XXXX]

ACE Groupcomm Profiles IANA is asked to register the following entry in the "ACE Groupcomm Profiles" registry defined in .

Name: coap_group_oscore_app
Description: Application profile to provision keying material for participating in group communication protected with Group OSCORE as per .
CBOR Value: PROFILE_TBD (suggested value: 1)
Reference: [RFC-XXXX]

OSCORE Security Context Parameters IANA is asked to register the following entries in the "OSCORE Security Context Parameters" registry defined in .

Entry #1
- Name: group_SenderId
- CBOR Label: 7 (suggested)
- CBOR Type: byte string
- Registry: -
- Description: OSCORE Sender ID assigned to a member of an OSCORE group
- Reference: [RFC-XXXX]
Entry #2
- Name: cred_fmt
- CBOR Label: 8 (suggested)
- CBOR Type: integer
- Registry: Labels (integer)
- Description: Format of authentication credentials to be used in the OSCORE group
- Reference: [RFC-XXXX]
Entry #3
- Name: gp_enc_alg
- CBOR Label: 9 (suggested)
- CBOR Type: text string / integer
- Registry: Values
- Description: OSCORE Group Encryption Algorithm Value
- Reference: [RFC-XXXX]
Entry #4
- Name: sign_alg
- CBOR Label: 10 (suggested)
- CBOR Type: text string / integer
- Registry: Values
- Description: OSCORE Signature Algorithm Value
- Reference: [RFC-XXXX]
Entry #5
- Name: sign_params
- CBOR Label: 11 (suggested)
- CBOR Type: array
- Registry: Capabilities, Capabilities, Values
- Description: OSCORE Signature Algorithm Parameters
- Reference: [RFC-XXXX]
Entry #6
- Name: ecdh_alg
- CBOR Label: 12 (suggested)
- CBOR Type: text string / integer
- Registry: Values
- Description: OSCORE Pairwise Key Agreement Algorithm Value
- Reference: [RFC-XXXX]
Entry #7
- Name: ecdh_params
- CBOR Label: 13 (suggested)
- CBOR Type: array
- Registry: Capabilities, Capabilities, Values
- Description: OSCORE Pairwise Key Agreement Algorithm Parameters
- Reference: [RFC-XXXX]

TLS Exporter Labels IANA is asked to register the following entry in the "TLS Exporter Labels" registry defined in and updated in .

Value: EXPORTER-ACE-Pop-Input-coap-group-oscore-app
DTLS-OK: Y
Recommended: N
Reference: [RFC-XXXX]

AIF Media-Type Sub-Parameters For the media-types "application/aif+cbor" and "application/aif+json" defined in , IANA is requested to register the following entries for the two media-type parameters Toid and Tperm, in the respective sub-registry defined in within the "MIME Media Type Sub-Parameter" registry group.

Entry #1
- Parameter: Toid
- Name: oscore-gname
- Description/Specification: OSCORE group name
- Reference: [RFC-XXXX]
Entry #2
- Parameter: Tperm
- Name: oscore-gperm
- Description/Specification: permissions pertaining OSCORE groups
- Reference: [RFC-XXXX]

CoAP Content-Formats IANA is asked to register the following entries in the "CoAP Content-Formats" registry within the "Constrained RESTful Environments (CoRE) Parameters" registry group.

Entry #1
- Content Type: application/aif+cbor;toid=oscore-gname;tperm=oscore-gperm
- Content Coding: -
- ID: 292 (suggested)
- Reference: [RFC-XXXX]
Entry #2
- Content Type: application/aif+json;toid=oscore-gname;tperm=oscore-gperm
- Content Coding: -
- ID: 293 (suggested)
- Reference: [RFC-XXXX]

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

Value: "core.osc.gm"
Description: Group-membership resource of an OSCORE Group Manager.
Reference: [RFC-XXXX]

Client applications can use this resource type to discover a group-membership resource at an OSCORE Group Manager, where to send a request for joining the corresponding OSCORE group.

ACE Groupcomm Errors IANA is asked to register the following entries in the "ACE Groupcomm Errors" registry defined in .

Entry #1
- Value: 7 (suggested)
- Description: Signatures not used in the group.
- Reference: [RFC-XXXX]
Entry #2
- Value: 8 (suggested)
- Description: Operation permitted only to signature verifiers.
- Reference: [RFC-XXXX]
Entry #3
- Value: 9 (suggested)
- Description: Group currently not active.
- Reference: [RFC-XXXX]

Group OSCORE Roles This document establishes the IANA "Group OSCORE Roles" 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 roles that nodes can take in an OSCORE group, each in combination with a numeric identifier. These numeric identifiers are used to express authorization information about joining OSCORE groups, 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 role that nodes can take in an OSCORE group.
Value: The numeric identifier for this role. Integer values greater than 65535 are marked as "Private Use", all other values use the registration policy "Expert Review" .
Description: This field contains a brief description of the role.
Reference: This field contains a pointer to the public specification for the role, 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 role, to verify the correctness of its description against the role as intended in the specification that defined it. Experts 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 objectives 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 roles when approving point assignments. 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 The Transport Layer Security (TLS) Protocol Version 1.2 This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK] Keying Material Exporters for Transport Layer Security (TLS) A number of protocols wish to leverage Transport Layer Security (TLS) to perform key establishment but then use some of the keying material for their own purposes. This document describes a general mechanism for allowing that. [STANDARDS-TRACK] Datagram Transport Layer Security Version 1.2 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] Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA) This document defines a deterministic digital signature generation procedure. Such signatures are compatible with standard Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA) digital signatures and can be processed with unmodified verifiers, which need not be aware of the procedure described therein. Deterministic signatures retain the cryptographic security features associated with digital signatures but can be more easily implemented in various environments, since they do not need access to a source of high-quality randomness. The Constrained Application Protocol (CoAP) 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. Elliptic Curves for Security This memo specifies two elliptic curves over prime fields that offer a high level of practical security in cryptographic applications, including Transport Layer Security (TLS). These curves are intended to operate at the ~128-bit and ~224-bit security level, respectively, and are generated deterministically based on a list of required properties. PKCS #1: RSA Cryptography Specifications Version 2.2 This document provides recommendations for the implementation of public-key cryptography based on the RSA algorithm, covering cryptographic primitives, encryption schemes, signature schemes with appendix, and ASN.1 syntax for representing keys and for identifying the schemes. This document represents a republication of PKCS #1 v2.2 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series. By publishing this RFC, change control is transferred to the IETF. This document also obsoletes RFC 3447. Edwards-Curve Digital Signature Algorithm (EdDSA) This document describes elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA). The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example implementation and test vectors are provided. Guidelines for Writing an IANA Considerations Section in RFCs 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 Transport Layer Security (TLS) Protocol Version 1.3 This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. IANA Registry Updates for TLS and DTLS This document describes a number of changes to TLS and DTLS IANA registries that range from adding notes to the registry all the way to changing the registration policy. These changes were mostly motivated by WG review of the TLS- and DTLS-related registries undertaken as part of the TLS 1.3 development process. This document updates the following RFCs: 3749, 5077, 4680, 5246, 5705, 5878, 6520, and 7301. Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures 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. Object Security for Constrained RESTful Environments (OSCORE) 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. Concise Binary Object Representation (CBOR) 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. CBOR Object Signing and Encryption (COSE): Structures and Process 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. CBOR Object Signing and Encryption (COSE): Initial Algorithms 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. The Datagram Transport Layer Security (DTLS) Protocol Version 1.3 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. Authentication and Authorization for Constrained Environments Using the OAuth 2.0 Framework (ACE-OAuth) 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. Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE) 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. The Object Security for Constrained RESTful Environments (OSCORE) Profile of the Authentication and Authorization for Constrained Environments (ACE) Framework 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. An Authorization Information Format (AIF) for Authentication and Authorization for Constrained Environments (ACE) 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. On Stable Storage for Items in Concise Binary Object Representation (CBOR) 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. Concise Problem Details for Constrained Application Protocol (CoAP) APIs 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. Extension of the Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE) to Transport Layer Security (TLS) This document updates "Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE)" (RFC 9202) by specifying that the profile applies to TLS as well as DTLS. Key Provisioning for Group Communication Using Authentication and Authorization for Constrained Environments (ACE) 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. Group Object Security for Constrained RESTful Environments (Group OSCORE) 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. Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography - NIST Special Publication 800-56A, Revision 3 COSE Algorithms IANA COSE Key Types IANA COSE Elliptic Curves IANA COSE Header Parameters IANA Key words for use in RFCs to Indicate Requirement Levels 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. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words 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 Group Communication for the Constrained Application Protocol (CoAP) 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 publish-subscribe architecture for the Constrained Application Protocol (CoAP) Ericsson Dogtiger Labs Ericsson This document describes a publish-subscribe architecture for the Constrained Application Protocol (CoAP), extending the capabilities of CoAP communications for supporting endpoints with long breaks in connectivity and/or up-time. CoAP clients publish on and subscribe to a topic via a corresponding topic resource at a CoAP server acting as broker. Discovery of OSCORE Groups with the CoRE Resource Directory 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 describes how a CoAP endpoint can use descriptions and links of resources registered at the CoRE Resource Directory to discover security groups and to acquire information for joining them through the respective Group Manager. A given security group may protect multiple application groups, which are separately announced in the Resource Directory as sets of endpoints sharing a pool of resources. This approach is consistent with, but not limited to, the joining of security groups based on the ACE framework for Authentication and Authorization in constrained environments. Admin Interface for the OSCORE Group Manager RISE AB RISE AB Ericsson AB Group communication for 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 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 ACE framework for Authentication and Authorization 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. CBOR Encoded X.509 Certificates (C509 Certificates) Ericsson AB Ericsson AB RISE AB 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 and all certificates compatible with the RFC 7925, IEEE 802.1AR (DevID), CNSA 1.0, RPKI, GSMA eUICC, and CA/Browser Forum Baseline Requirements profiles. C509 is deployed in different settings including, in-vehicle and vehicle-to-cloud communication, Unmanned Aircraft Systems (UAS), and Global Navigation Satellite System (GNSS). When used to re-encode DER encoded X.509 certificates, the CBOR encoding can in many cases reduce the size of RFC 7925 profiled certificates by over 50% while also significantly reducing memory and code size compared to ASN.1. The CBOR encoded structure can alternatively be signed directly ("natively signed"), which does not require re-encoding for the signature to be verified. The TLSA selectors registry defined in RFC 6698 is extended to include C509 certificates. The document also specifies C509 Certificate Requests, C509 COSE headers, a C509 TLS certificate type, and a C509 file format. Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile 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] HMAC-based Extract-and-Expand Key Derivation Function (HKDF) This document specifies a simple Hashed Message Authentication Code (HMAC)-based key derivation function (HKDF), which can be used as a building block in various protocols and applications. The key derivation function (KDF) is intended to support a wide range of applications and requirements, and is conservative in its use of cryptographic hash functions. This document is not an Internet Standards Track specification; it is published for informational purposes. Constrained RESTful Environments (CoRE) Link Format 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 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] Observing Resources in the Constrained Application Protocol (CoAP) 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. CBOR Web Token (CWT) 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.

Profile Requirements This section lists how this application profile of ACE addresses the requirements defined in .

Mandatory-to-Address Requirements

REQ1: Specify the format and encoding of scope. This includes defining the set of possible roles and their identifiers, as well as the corresponding encoding to use in the scope entries according to the used scope format: see and .
REQ2: If scope uses AIF, register its specific instance of "Toid" and "Tperm" as media type parameters and a corresponding Content-Format, as per the guidelines in : see and .
REQ3: If used, specify the acceptable values for the 'sign_alg' parameter: values from the "Value" column of the "COSE Algorithms" registry .
REQ4: If used, specify the acceptable values and structure for the 'sign_parameters' parameter: values and structure from the COSE algorithm capabilities as specified in the "COSE Algorithms" registry .
REQ5: If used, specify the acceptable values and structure for the 'sign_key_parameters' parameter: values and structure from the COSE key type capabilities as specified in the "COSE Key Types" registry .
REQ6: Specify the acceptable formats for authentication credentials and, if applicable, the acceptable values for the 'cred_fmt' parameter: acceptable formats explicitly provide the public key as well as the comprehensive set of information related to the public key algorithm (see and ). Consistent acceptable values for 'cred_fmt' are taken from the "Label" column of the "COSE Header Parameters" registry , with some of those values also indicating the type of container to use for exchanging the authentication credentials with the Group Manager (e.g., a chain or bag of certificates).
REQ7: If the value of the GROUPNAME URI path and the group name in the access token scope ('gname') are not required to coincide, specify the mechanism to map the GROUPNAME value in the URI to the group name: not applicable, since a perfect matching is required.
REQ8: Define whether the KDC has an authentication credential as required for the correct group operation and if this has to be provided through the 'kdc_cred' parameter: yes, as required by the Group OSCORE protocol , see of this document.
REQ9: Specify if any part of the KDC interface as defined in is not supported by the KDC: not applicable.
REQ10: Register a Resource Type for the group-membership resources, which is used to discover the correct URL for sending a Join Request to the KDC: the Resource Type (rt=) Link Target Attribute value "core.osc.gm" is registered in .
REQ11: Define what specific actions (e.g., CoAP methods) are allowed on each resource accessible through the KDC interface, depending on: whether the Client is a current group member; the roles that a Client is authorized to take as per the obtained access token; and the roles that the Client has as a current group member: see .
REQ12: Categorize possible newly defined operations for Clients into primary operations expected to be minimally supported and secondary operations, and provide accompanying considerations: see .
REQ13: Specify the encoding of group identifiers: CBOR byte string (see ).
REQ14: Specify the approaches used to compute and verify the PoP evidence to include in the 'client_cred_verify' parameter and which of those approaches is used in which case: see and .
REQ15: Specify how the nonce N_S is generated, if the access token is not provided to the KDC through the Token Transfer Request sent to the /authz-info endpoint (e.g., the access token is instead transferred during the establishment of a secure communication association): see .
REQ16: Define the initial value of the version number for the group keying material: the initial value MUST be set to 0 when creating the OSCORE group, e.g., as in .
REQ17: Specify the format of the group keying material that is conveyed in the 'key' parameter: see .
REQ18: Specify the acceptable values of the 'gkty' parameter. For each of them, register a corresponding entry in the "ACE Groupcomm Key Types" IANA registry if such an entry does not exist already: Group_OSCORE_Input_Material object (see ).
REQ19: Specify and register the application profile identifier: coap_group_oscore_app (see ).
REQ20: If used, specify the format and default values of the entries of the CBOR map to include in the 'group_policies' parameter: see .
REQ21: Specify the approaches used to compute and verify the PoP evidence to include in the 'kdc_cred_verify' parameter and which of those approaches is used in which case. If external signature verifiers are supported, specify how those provide a nonce to the KDC to be used for computing the PoP evidence: see , and .
REQ22: Specify the communication protocol that members of the group use to communicate with each other (e.g., CoAP for group communication): CoAP , also for group communication .
REQ23: Specify the security protocol that members of the group use to protect the group communication (e.g., Group OSCORE). This must provide encryption, integrity, and replay protection: Group OSCORE .
REQ24: Specify how the communication is secured between the Client and the KDC. Optionally, specify a transport profile of ACE to use between the Client and the KDC: by means of any transport profile of ACE between Client and Group Manager that complies with the requirements in .
REQ25: Specify the format of the node identifiers of group members: the Sender ID used in the OSCORE group (see and ).
REQ26: Specify policies at the KDC to handle node identifiers that are included in the 'get_creds' parameter but are not associated with any current group member: see .
REQ27: Specify the format of (newly generated) individual keying material for group members or of the information to derive such keying material, as well as the corresponding CBOR map key that has to be registered in the "ACE Groupcomm Parameters" registry: see .
REQ28: Specify which CBOR tag is used for identifying the semantics of binary scopes, or register a new CBOR tag if a suitable one does not exist already: see .
REQ29: Categorize newly defined parameters according to the same criteria of : see .
REQ30: Define whether Clients must, should, or may support the conditional parameters defined in and under which circumstances: see .

Optional-to-Address Requirements

OPT1: Optionally, if the textual format of scope is used, specify CBOR values to use for abbreviating the role identifiers in the group: not applicable.
OPT2: Optionally, specify the additional parameters used in the exchange of Token Transfer Request and Response:
- 'ecdh_info', to negotiate the ECDH algorithm, ECDH algorithm parameters, ECDH key parameters, and exact format of authentication credentials used in the group, in case the joining node supports the pairwise mode of Group OSCORE (see ).
- 'kdc_dh_creds', to ask for and retrieve the Group Manager's Diffie-Hellman authentication credentials, in case the joining node supports the pairwise mode of Group OSCORE and the access token authorizes to join pairwise-only groups (see ).
OPT3: Optionally, specify the negotiation of parameter values for signature algorithm and signature keys, if the 'sign_info' parameter is not used: possible early discovery by using the approach based on the CoRE Resource Directory and described in .
OPT4: Optionally, specify possible or required payload formats for specific error cases: send a 4.00 (Bad Request) error response to a Join Request (see ).
OPT5: Optionally, specify additional identifiers of error types as values of the 'error-id' field within the Custom Problem Detail entry 'ace-groupcomm-error': see and .
OPT6: Optionally, specify the encoding of the 'creds_repo' parameter if the default one is not used: no encoding is defined.
OPT7: Optionally, specify the functionalities implemented at the resource hosted by the Client at the URI indicated in the 'control_uri' parameter, including the encoding of exchanged messages and other details: see for the eviction of a group member; see for the group rekeying process.
OPT8: Optionally, specify the behavior of the POST handler of group-membership resources, for the case when it fails to retrieve an authentication credential for the specific Client: send a 4.00 (Bad Request) error response to a Join Request (see ).
OPT9: Optionally, define a default group rekeying scheme to refer to in case the 'rekeying_scheme' parameter is not included in the Join Response: the "Point-to-Point" rekeying scheme registered in , whose detailed use for this profile is defined in of this document.
OPT10: Optionally, specify the functionalities implemented at the resource hosted by the Client at the URI indicated in the 'control_group_uri' parameter, including the encoding of exchanged messages and other details: see for the eviction of multiple group members.
OPT11: Optionally, specify policies that instruct Clients to retain messages and for how long, if those are unsuccessfully decrypted: no such policies are specified.
OPT12: Optionally, specify for the KDC to perform a group rekeying when receiving a Key Renewal Request, together with or instead of renewing individual keying material: the Group Manager SHOULD perform a group rekeying if one is already scheduled to occur within an acceptably short time frame, otherwise it SHOULD NOT (see ).
OPT13: Optionally, specify how the identifier of a group member's authentication credential is included in requests sent to other group members: no such method is defined.
OPT14: Optionally, specify additional information to include in rekeying messages for the "Point-to-Point" group rekeying scheme (see ): see .

Extensibility for Future COSE Algorithms As defined in , future algorithms can be registered in the "COSE Algorithms" registry as specifying none or multiple COSE capabilities. To enable the seamless use of such future registered algorithms, this section defines a general, agile format for:

Each 'ecdh_info_entry' of the 'ecdh_info' parameter in the Token Transfer Response (see ). describes the analogous general format for each 'sign_info_entry' of the 'sign_info' parameter in the Token Transfer Response (see of this document).
The 'sign_params' and 'ecdh_params' parameters within the 'key' parameter (see ), as part of the response payloads used in , , , and .

If any of the currently registered COSE algorithms is considered, using this general format yields the same structure defined in this document for the items above, thus ensuring backward compatibility.

Format of 'ecdh_info_entry' The format of each 'ecdh_info_entry' (see and ) is generalized as follows.

'ecdh_parameters' includes N >= 0 elements, each of which is a COSE capability of the ECDH algorithm indicated in 'ecdh_alg'. In particular, 'ecdh_parameters' has the same format and value of the COSE capabilities array for the ECDH algorithm indicated in 'ecdh_alg', as specified for that algorithm in the 'Capabilities' column of the "COSE Algorithms" registry .
'ecdh_key_parameters' is replaced by N elements 'ecdh_capab', each of which is a CBOR array. The i-th 'ecdh_capab' array (i = 0, ..., N-1) is the array of COSE capabilities for the algorithm capability specified in 'ecdh_parameters'[i]. In particular, each 'ecdh_capab' array has the same format and value of the COSE capabilities array for the algorithm capability specified in 'ecdh_parameters'[i]. Such a COSE capabilities array is currently defined for the algorithm capability COSE key type, in the "Capabilities" column of the "COSE Key Types" registry .

The CDDL notation of the 'ecdh_info_entry' parameter is given below.

'ecdh_info_entry' with General Format

Format of 'key' The format of 'key' (see ) is generalized as follows.

The 'sign_params' array includes N+1 elements, whose exact structure and value depend on the value of the signature algorithm specified in 'sign_alg'.
- The first element, i.e., 'sign_params'[0], is the array of the N COSE capabilities for the signature algorithm, as specified for that algorithm in the "Capabilities" column of the "COSE Algorithms" registry (see ).
- Each following element 'sign_params'[i], i.e., with index i > 0, is the array of COSE capabilities for the algorithm capability specified in 'sign_params'[0][i-1].
For example, if 'sign_params'[0][0] specifies the key type as capability of the algorithm, then 'sign_params'[1] is the array of COSE capabilities for the COSE key type associated with the signature algorithm, as specified for that key type in the "Capabilities" column of the "COSE Key Types" registry (see ).
The 'ecdh_params' array includes M+1 elements, whose exact structure and value depend on the value of the ECDH algorithm specified in 'ecdh_alg'.
- The first element, i.e., 'ecdh_params'[0], is the array of the M COSE capabilities for the ECDH algorithm, as specified for that algorithm in the "Capabilities" column of the "COSE Algorithms" registry (see ).
- Each following element 'ecdh_params'[i], i.e., with index i > 0, is the array of COSE capabilities for the algorithm capability specified in 'ecdh_params'[0][i-1].
For example, if 'ecdh_params'[0][0] specifies the key type as capability of the algorithm, then 'ecdh_params'[1] is the array of COSE capabilities for the COSE key type associated with the ECDH algorithm, as specified for that key type in the "Capabilities" column of the "COSE Key Types" registry (see ).

CDDL Model

Document Updates

Version -18 to -19

Extended introduction: clarified relationships between this document and related documents.
Two more terms mentioned upfront in the terminology section.
Ensured consistency with RFC 9594 when using an optimized Join Request for re-joining a group if already a member (presence of the 'client_cred' parameter).
Mentioned also periodic/scheduled group rekeying in the security considerations.
Added the "Operational Considerations" section.
Clarifications:
- Clearer wording about recommended randomness and size of nonces.
- Rejection of Ed25519/Ed448 authentication credentials in corner cases.
- Nonce used in a retry Join Request after an error response.
- Secure communications required as per the transport profile of ACE used.
- Consequences of not including a parameter in two response messages from the Group Manager.
- Explicitly mentioned the rationale for computing a proof-of-possession (PoP) evidence.
IANA considerations:
- Suggested values for two registrations.
- Improved readability of registration requests.
- Definition of the new registry
  - Mentioned the registry group including the new registry.
  - Specifications are not required for Expert Review and one might not exist for a registry entry.
- Fixed content types in the CoAP Content-Formats registrations.
Minor fixes and editorial improvements.

Version -17 to -18

Avoid unnecessary normative language.
Added missing optional check at the Group Manager when receiving a group member's updated authentication credential.
Clarified the origin of the latest client's authentication credential.
Clarified meaning of the group becoming inactive and active again.
Clarified usefulness of error responses to the Join Request.
Clarified relation between a group rekeying and a Key Renewal Request.
Clarified checks on requests from a signature verifier.
Refer to all the REQ and OPT profile requirements.
Clarifications and editorial improvements.

Version -16 to -17

CBOR diagnostic notation uses placeholders from a CDDL model.
Fixes in the CDDL definitions.
Fixes in the examples in CBOR diagnostic notation.
Updated author list.
Updated references and section numbers of referred documents.
Use actual tables.
Add high-level recap of the concept of scope.
Fixed name of the error with error code 4.
Renamed parameters to align with RFC 9594
- "Group Encryption Key" becomes "Signature Encryption Key"
- 'group_enc_key' becomes 'sign_enc_key'
- "Signature Encryption Algorithm" becomes "Group Encryption Algorithm"
- 'sign_enc_alg' becomes 'gp_enc_alg'
Added CBOR integer abbreviations for ACE Groupcomm Parameters.
Considerations on authentication credentials consistent with RFC 9594.
Revised alternative computing of N_S challenge when DTLS is used.
Generalized definition of ecdh_info.
Generalized definition of kdc_dh_creds.
Clarified maximum size of the OSCORE Sender ID.
Clarified parameters left "not set" in the Security Context.
Clarified meaning of 'cred_fmt'.
Consistent mandatory use of 'cnonce'.
Relation between 'cred_fmt' and Authentication Credential Format.
Implicit PoP evidence of the Client's authentication credential.
Process of 'client_cred' and 'client_cred_verify' consistent with RFC 9594.
GET to ace-group/GROUPNAME/kdc-cred only for group members.
Added FETCH handler for /ace-group/GROUPNAME/kdc-cred.
PUT becomes POST for ace-group/GROUPNAME/nodes/NODENAME.
Fixed error response code from /ace-group/GROUPNAME/nodes/NODENAME.
Consistent use of the 'exi' ACE Groupcomm Parameter.
Use concise problem details (RFC9290) for error responses.
Revised default values on group configuration parameters.
Revised future-ready generalization of 'ecdh_info_entry'.
CCS is used as default format of authentication credential.
Updated name of TLS exporter label.
Revised IANA considerations.
Aligned requirement formulation with that in RFC 9594.
Use of AASVG in message diagrams.
Clarifications and editorial fixes.

Version -15 to -16

Early mentioning of invalid combinations of roles.
Revised presentation of handling of stale Sender IDs.
Fixed CDDL notation.
Fixed diagnostic notation in examples.
Possible reason to deviate from default parameter values.
Clarifications and editorial fixes.

Version -14 to -15

Alignment with renaming in draft-ietf-ace-key-groupcomm.
Updated signaling of semantics for binary encoded scopes.
Considered the upload of access tokens in the DTLS 1.3 Handshake.
Fixes in IANA registrations.
Editorial fixes.

Version -13 to -14

Major reordering of the document sections.
The HKDF Algorithm is specified by the HMAC Algorithm.
Group communication does not necessarily use IP multicast.
Generalized AIF data model, also for draft-ace-oscore-gm-admin.
Clarifications and editorial improvements.

Version -12 to -13

Renamed parameters about authentication credentials.
It is optional for the Group Manager to reassign Gids by tracking "Birth Gids".
Distinction between authentication credentials and public keys.
Updated IANA considerations related to AIF.
Updated textual description of registered ACE Scope Semantics value.

Version -11 to -12

Clarified semantics of 'ecdh_info' and 'kdc_dh_creds'.
Definition of /ace-group/GROUPNAME/kdc-pub-key moved to draft-ietf-ace-key-groupcomm.
/ace-group accessible also to non-members that are not Verifiers.
Clarified what resources are accessible to Verifiers.
Revised error handling for the newly defined resources.
Revised use of CoAP error codes.
Use of "Token Transfer Request" and "Token Transfer Response".
New parameter 'rekeying_scheme'.
Categorization of new parameters and inherited conditional parameters.
Clarifications on what to do in case of enhanced error responses.
Changed UCCS to CCS.
Authentication credentials of just joined Clients can be in rekeying messages.
Revised names of new IANA registries.
Clarified meaning of registered CoRE resource type.
Alignment to new requirements from draft-ietf-ace-key-groupcomm.
Fixes and editorial improvements.

Version -10 to -11

Removed redundancy of key type capabilities, from 'sign_info', 'ecdh_info' and 'key'.
New resource to retrieve the Group Manager's authentication credential.
New resource to retrieve material for Signature Verifiers.
New parameter 'gp_enc_alg' related to the group mode.
'cred_fmt' takes value from the COSE Header Parameters registry.
Improved alignment of the Join Response payload with the Group OSCORE Security Context parameters.
Recycling Group IDs by tracking "Birth GIDs".
Error handling in case of non available Sender IDs upon joining.
Error handling in case EdDSA public keys with invalid Y coordinate when the pairwise mode of Group OSCORE is supported.
Generalized proof-of-possession (PoP) for the joining node's private key; defined Diffie-Hellman based PoP for OSCORE groups using only the pairwise mode.
Proof of possession of the Group Manager's private key in the Join Response.
Always use 'peer_identifiers' to convey Sender IDs as node identifiers.
Stale Sender IDs provided when rekeying the group.
New resource for late retrieval of stale Sender IDs.
Added examples of message exchanges.
Revised default values of group configuration parameters.
Fixes to IANA registrations.
General format of parameters related to COSE capabilities, supporting future registered COSE algorithms (new Appendix).

Version -09 to -10

Updated non-recycling policy of Sender IDs.
Removed policies about Sender Sequence Number synchronization.
'control_path' renamed to 'control_uri'.
Format of 'get_pub_keys' aligned with draft-ietf-ace-key-groupcomm.
Additional way to inform of group eviction.
Registered semantics identifier for extended scope format.
Extended error handling, with error type specified in some error responses.
Renumbered requirements.

Version -08 to -09

The url-path "ace-group" is used.
Added overview of admitted methods on the Group Manager resources.
Added exchange of parameters relevant for the pairwise mode of Group OSCORE.
The signed value for 'client_cred_verify' includes also the scope.
Renamed the key material object as Group_OSCORE_Input_Material object.
Replaced 'clientId' with 'group_SenderId'.
Added message exchange for Group Names request-response.
No reassignment of Sender ID and Gid in the same OSCORE group.
Updates on group rekeying contextual with request of new Sender ID.
Signature verifiers can also retrieve Group Names and URIs.
Removed group policy about supporting Group OSCORE in pairwise mode.
Registration of the resource type rt="core.osc.gm".
Update list of requirements.
Clarifications and editorial revision.

Version -07 to -08

AIF data model to express scope entries.
A set of roles is checked as valid when processing the Join Request.
Updated format of 'get_pub_keys' in the Join Request.
Payload format and default values of group policies in the Join Response.
Updated payload format of the FETCH request to retrieve authentication credentials.
Default values for group configuration parameters.
IANA registrations to support the AIF data model.

Version -06 to -07

Alignments with draft-ietf-core-oscore-groupcomm.
New format of 'sign_info', using the COSE capabilities.
New format of Join Response parameters, using the COSE capabilities.
Considerations on group rekeying.
Editorial revision.

Version -05 to -06

Added role of external signature verifier.
Parameter 'rsnonce' renamed to 'kdcchallenge'.
Parameter 'kdcchallenge' may be omitted in some cases.
Clarified difference between group name and OSCORE Gid.
Removed the role combination ["requester", "monitor"].
Admit implicit scope and audience in the Authorization Request.
New format for the 'sign_info' parameter.
Scope not mandatory to include in the Join Request.
Group policy about supporting Group OSCORE in pairwise mode.
Possible individual rekeying of a single requesting node combined with a group rekeying.
Security considerations on reuse of signature challenges.
Addressing optional requirement OPT12 from draft-ietf-ace-key-groupcomm
Editorial improvements.

Version -04 to -05

Nonce N_S also in error responses to the Join Requests.
Supporting single access token for multiple groups/topics.
Supporting legal requesters/responders using the 'peer_roles' parameter.
Registered and used dedicated label for TLS Exporter.
Added method for uploading a new authentication credential to the Group Manager.
Added resource and method for retrieving the current group status.
Fixed inconsistency in retrieving group keying material only.
Clarified retrieval of keying material for monitor-only members.
Clarification on incrementing version number when rekeying the group.
Clarification on what is re-distributed with the group rekeying.
Security considerations on the size of the nonces used for the signature challenge.
Added CBOR values to abbreviate role identifiers in the group.

Version -03 to -04

New abstract.
Moved general content to draft-ietf-ace-key-groupcomm
Terminology: node name; node resource.
Creation and pointing at node resource.
Updated Group Manager API (REST methods and offered services).
Size of challenges 'cnonce' and 'rsnonce'.
Value of 'rsnonce' for reused or non-traditionally-posted tokens.
Removed reference to RFC 7390.
New requirements from draft-ietf-ace-key-groupcomm
Editorial improvements.

Version -02 to -03

New sections, aligned with the interface of ace-key-groupcomm .
Exchange of information on the signature algorithm and related parameters, during the Token POST (Section 4.1).
Nonce 'rsnonce' from the Group Manager to the Client (Section 4.1).
Client PoP signature in the Key Distribution Request upon joining (Section 4.2).
Local actions on the Group Manager, upon a new node's joining (Section 4.2).
Local actions on the Group Manager, upon a node's leaving (Section 12).
IANA registration in ACE Groupcomm Parameters registry.
More fulfilled profile requirements (Appendix A).

Version -01 to -02

Editorial fixes.
Changed: "listener" to "responder"; "pure listener" to "monitor".
Changed profile name to "coap_group_oscore_app", to reflect it is an application profile.
Added the 'type' parameter for all requests to a Join Resource.
Added parameters to indicate the encoding of authentication credentials.
Challenge-response for proof of possession of signature keys (Section 4).
Renamed 'key_info' parameter to 'sign_info'; updated its format; extended to include also parameters of the signature key (Section 4.1).
Code 4.00 (Bad request), in responses to joining nodes providing an invalid authentication credential (Section 4.3).
Clarifications on provisioning and checking of authentication credentials (Sections 4 and 6).
Extended discussion on group rekeying and possible different approaches (Section 7).
Extended security considerations: proof of possession of signature keys; collision of OSCORE Group Identifiers (Section 8).
Registered three entries in the IANA registry "Sequence Number Synchronization Method" (Section 9).
Registered one public key encoding in the "ACE Public Key Encoding" IANA registry (Section 9).

Version -00 to -01

Changed name of 'req_aud' to 'audience' in the Authorization Request (Section 3.1).
Added negotiation of signature algorithm/parameters between Client and Group Manager (Section 4).
Updated format of the Key Distribution Response as a whole (Section 4.3).
Added parameter 'cs_params' in the 'key' parameter of the Key Distribution Response (Section 4.3).
New IANA registrations in the "ACE Authorization Server Request Creation Hints" registry, "ACE Groupcomm Key" registry, "OSCORE Security Context Parameters" registry and "ACE Groupcomm Profile" registry (Section 9).

Acknowledgments Jiye Park contributed as a co-author of initial versions of this document. 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; by the H2020 project SIFIS-Home (Grant agreement 952652); and by the EIT-Digital High Impact Initiative ACTIVE.