rfc9594v2.txt		rfc9594.txt
	skipping to change at line 223 ¶		skipping to change at line 223 ¶
	Readers are expected to be familiar with the following:		Readers are expected to be familiar with the following:
	* The terms and concepts described in the ACE framework [RFC9200]		* The terms and concepts described in the ACE framework [RFC9200]
	and in the Authorization Information Format (AIF) [RFC9237] to		and in the Authorization Information Format (AIF) [RFC9237] to
	express authorization information. The terminology for entities		express authorization information. The terminology for entities
	in the considered architecture is defined in OAuth 2.0 [RFC6749].		in the considered architecture is defined in OAuth 2.0 [RFC6749].
	In particular, this includes Client (C), Resource Server (RS), and		In particular, this includes Client (C), Resource Server (RS), and
	Authorization Server (AS).		Authorization Server (AS).
	* The terms and concepts described in the Constrained Application		* The terms and concepts described in the Constrained Application
	Protocol (CoAP) [RFC7252]. Unless otherwise indicated, the term		Protocol (CoAP) [RFC7252]. The term "endpoint" is used here
	"endpoint" is used here following its OAuth definition, aimed at		following its OAuth definition, aimed at denoting resources such
	denoting resources such as /token and /introspect at the AS and		as /token and /introspect at the AS and /authz-info at the RS.
	/authz-info at the RS. This document does not use the CoAP		This document does not use the CoAP definition of "endpoint",
	definition of "endpoint", which is "An entity participating in the		which is "An entity participating in the CoAP protocol".
	CoAP protocol".
	* The terms and concepts described in Concise Data Definition		* The terms and concepts described in Concise Data Definition
	Language (CDDL) [RFC8610], CBOR [RFC8949], and CBOR Object Signing		Language (CDDL) [RFC8610], CBOR [RFC8949], and CBOR Object Signing
	and Encryption (COSE) [RFC9052] [RFC9053] [RFC9338].		and Encryption (COSE) [RFC9052] [RFC9053] [RFC9338].
	A node interested in participating in group communication, as well as		A node interested in participating in group communication, as well as
	one that is already participating as a group member, is		one that is already participating as a group member, is
	interchangeably denoted as "Client".		interchangeably denoted as "Client".
	This document also uses the following terms.		This document also uses the following terms.
	skipping to change at line 258 ¶		skipping to change at line 257 ¶
	or the set of nodes registered to a pub-sub topic.		or the set of nodes registered to a pub-sub topic.
	This term is also not to be confused with a "multicast group",		This term is also not to be confused with a "multicast group",
	which has relevance at the network level and whose members all		which has relevance at the network level and whose members all
	listen to a group network address for receiving messages sent to		listen to a group network address for receiving messages sent to
	that group. An example of a multicast group is the set of nodes		that group. An example of a multicast group is the set of nodes
	that are configured to receive messages that are sent to the		that are configured to receive messages that are sent to the
	group's associated IP multicast address.		group's associated IP multicast address.
	The same security group might be associated with multiple		The same security group might be associated with multiple
	application groups. Also, the same application group can be		application groups. Also, the same application group might be
	associated with multiple security groups. Further details and		associated with multiple security groups. Further details and
	considerations on the mapping between the three types of groups		considerations on the mapping between the three types of groups
	are out of the scope of this document.		are out of the scope of this document.
	Key Distribution Center (KDC): The entity responsible for managing		Key Distribution Center (KDC): The entity responsible for managing
	one or multiple groups, with particular reference to the group		one or multiple groups, with particular reference to the group
	membership and the keying material to use for protecting group		membership and the keying material to use for protecting group
	communications.		communications.
	Furthermore, this document uses "names" or "identifiers" for groups		Furthermore, this document uses "names" or "identifiers" for groups
	skipping to change at line 316 ¶		skipping to change at line 315 ¶
	Application profile: A profile that defines how applications enforce		Application profile: A profile that defines how applications enforce
	and use supporting security services they require. These services		and use supporting security services they require. These services
	may include, for instance, provisioning, revocation, and		may include, for instance, provisioning, revocation, and
	distribution of keying material. An application profile may		distribution of keying material. An application profile may
	define specific procedures and message formats.		define specific procedures and message formats.
	Authentication credential: The set of information associated with an		Authentication credential: The set of information associated with an
	entity, including that entity's public key and parameters		entity, including that entity's public key and parameters
	associated with the public key. Examples of authentication		associated with the public key. Examples of authentication
	credentials are CBOR Web Tokens (CWTs), CWT Claims Sets (CCSs)		credentials are CBOR Web Tokens (CWTs) and CWT Claims Sets (CCSs)
	[RFC8392], X.509 certificates [RFC5280], and C509 certificates		[RFC8392], X.509 certificates [RFC5280], and C509 certificates
	[C509-CERT].		[C509-CERT].
	Individual keying material: Information pertaining exclusively to a		Individual keying material: Information pertaining exclusively to a
	group member, as associated with its group membership and related		group member, as associated with its group membership and related
	to other keying material and parameters used in the group. For		to other keying material and parameters used in the group. For
	example, this can be an identifier that the secure communication		example, this can be an identifier that the secure communication
	protocol employs to uniquely identify a node as a group member		protocol employs to uniquely identify a node as a group member
	(e.g., a cryptographic key identifier uniquely associated with the		(e.g., a cryptographic key identifier uniquely associated with the
	group member in question). The specific nature and format of		group member in question). The specific nature and format of
	individual keying material used in a group is defined in the		individual keying material used in a group is defined in the
	application profiles of this specification. The individual keying		application profiles of this specification. The individual keying
	material of a group member is not related to the secure		material of a group member is not related to the secure
	association between that group member and the KDC.		association between that group member and the KDC.
	Examples throughout this document are expressed in CBOR diagnostic		Throughout this document, examples for CBOR data items are expressed
	notation without the tag and value abbreviations.		in CBOR extended diagnostic notation as defined in Section 8 of
			[RFC8949] and Appendix G of [RFC8610] ("diagnostic notation"), unless
			noted otherwise. We often use diagnostic notation comments to
			provide a textual representation of the numeric parameter names and
			values.
	2. Overview		2. Overview
	At a high level, the key provisioning process is separated in two		At a high level, the key provisioning process is separated in two
	phases: the first one follows the ACE framework between the Client,		phases: the first one follows the ACE framework between the Client,
	AS, and KDC and the second one is the actual key distribution between		AS, and KDC, while the second one is the actual key distribution
	the Client and KDC. After the two phases are completed, the Client		between the Client and KDC. After the two phases are completed, the
	is able to participate in the group communication via a Dispatcher		Client is able to participate in the group communication via a
	entity.		Dispatcher entity.
	.------------. .------------.		.------------. .------------.
	| AS | .----->| KDC |		| AS | .----->| KDC |
	'------------' | '------------'		'------------' | '------------'
	^ |		^ |
	| |		| |
	v |		v |
	.------------. | .-----------.		.------------. | .-----------.
	| Client |<-------' .------------. | .---------+-.		| Client |<-------' .------------. | .---------+-.
	| |<------------->| Dispatcher |<----->| | .---------+-.		| |<------------->| Dispatcher |<----->| | .---------+-.
	skipping to change at line 373 ¶		skipping to change at line 376 ¶
	group communication with other group members. Within the group,		group communication with other group members. Within the group,
	the Client can have different roles.		the Client can have different roles.
	* Authorization Server (AS): As per the AS defined in the ACE		* Authorization Server (AS): As per the AS defined in the ACE
	framework [RFC9200], it enforces access policies that prescribe		framework [RFC9200], it enforces access policies that prescribe
	whether a node is allowed to join a given group or not and with		whether a node is allowed to join a given group or not and with
	what roles and rights (e.g., write and/or read).		what roles and rights (e.g., write and/or read).
	* Key Distribution Center (KDC): An entity that maintains the keying		* Key Distribution Center (KDC): An entity that maintains the keying
	material to protect group communications and provides it to		material to protect group communications and provides it to
	Clients authorized to join a given group. During the first part		Clients authorized to join a given group. During the first phase
	of the exchange (Section 3), the KDC takes the role of the RS in		of the process (Section 3), the KDC takes the role of the RS in
	the ACE framework. During the second part (Section 4), which is		the ACE framework. During the second phase of the process
	not based on the ACE framework, the KDC distributes the keying		(Section 4), which is not based on the ACE framework, the KDC
	material. In addition, the KDC provides the latest keying		distributes the keying material. In addition, the KDC provides
	material to group members when requested or, if required by the		the latest keying material to group members when requested or, if
	application, when group membership changes.		required by the application, when group membership changes.
	* Group members: Nodes that have joined a group where they take part		* Group members: Nodes that have joined a group where they take part
	in group communication with one another, protecting it with the		in group communication with one another, protecting it with the
	group keying material obtained from the KDC.		group keying material obtained from the KDC.
	* Dispatcher: An entity through which the Clients communicate with		* Dispatcher: An entity through which the Clients communicate with
	the group when sending a message intended for multiple group		the group when sending a message intended for multiple group
	members. That is, the Dispatcher distributes such a one-to-many		members. That is, the Dispatcher distributes such a one-to-many
	message to the group members as intended recipients. The		message to the group members as intended recipients. The
	Dispatcher does not have access to the group keying material. A		Dispatcher does not have access to the group keying material. A
	skipping to change at line 409 ¶		skipping to change at line 412 ¶
	transport channel.		transport channel.
	If it consists of an explicit entity, such as a pub-sub Broker or		If it consists of an explicit entity, such as a pub-sub Broker or
	a message relayer, the Dispatcher is comparable to an untrusted		a message relayer, the Dispatcher is comparable to an untrusted
	on-path intermediary; as such, it is able to see the messages sent		on-path intermediary; as such, it is able to see the messages sent
	by Clients in the group but not able to decrypt them and read		by Clients in the group but not able to decrypt them and read
	their plain content.		their plain content.
	This document specifies a mechanism for:		This document specifies a mechanism for:
	* authorizing a Client to join the group (Section 3) and providing		* Authorizing a Client to join the group (Section 3) and providing
	it with the group keying material to communicate with the other		it with the group keying material to communicate with the other
	group members (Section 4),		group members (Section 4),
	* allowing a group member to retrieve group keying material		* Allowing a group member to retrieve group keying material
	(Sections 4.3.2.1 and 4.8.1.1),		(Sections 4.3.2.1 and 4.8.1.1),
	* allowing a group member to retrieve authentication credentials of		* Allowing a group member to retrieve authentication credentials of
	other group members (Section 4.4.1.1) and to provide an updated		other group members (Section 4.4.1.1) and to provide an updated
	authentication credential (Section 4.9.1.1),		authentication credential (Section 4.9.1.1),
	* allowing a group member to leave the group (Section 4.8.3.1),		* Allowing a group member to leave the group (Section 4.8.3.1),
	* evicting a group member from the group (Section 5), and		* Evicting a group member from the group (Section 5), and
	* renewing and redistributing the group keying material (rekeying),		* Renewing and redistributing the group keying material (rekeying),
	e.g., upon a membership change in the group (Section 6).		e.g., upon a membership change in the group (Section 6).
	Rekeying the group may result in a temporary misalignment of the		Rekeying the group may result in a temporary misalignment of the
	keying material stored by the different group members. Different		keying material stored by the different group members. Different
	situations where this can happen and how they can be handled are		situations where this can happen and how they can be handled are
	discussed in Section 6.3.		discussed in Section 6.3.
	Figure 2 provides a high-level overview of the message flow for a		Figure 2 provides a high-level overview of the message flow for a
	node joining a group. The message flow can be expanded as follows.		node joining a group. The message flow can be expanded as follows.
	skipping to change at line 457 ¶		skipping to change at line 460 ¶
	This is typically achieved by including the access token in a		This is typically achieved by including the access token in a
	request sent to the /authz-info endpoint at the KDC.		request sent to the /authz-info endpoint at the KDC.
	Once this exchange is completed, the joining node MUST have a		Once this exchange is completed, the joining node MUST have a
	secure communication association established with the KDC before		secure communication association established with the KDC before
	joining a group under that KDC.		joining a group under that KDC.
	This exchange and the following secure communications between the		This exchange and the following secure communications between the
	Client and the KDC MUST occur in accordance with the transport		Client and the KDC MUST occur in accordance with the transport
	profile of ACE used between the Client and KDC, such as the DTLS		profile of ACE used between the Client and KDC, such as the DTLS
	transport profile [RFC9202] and OSCORE transport profile		transport profile of ACE [RFC9202] or the OSCORE transport
	[RFC9203] of ACE.		profile of ACE [RFC9203].
	3. The joining node starts the joining process to become a member of		3. The joining node starts the joining process to become a member of
	the group by sending a request to the related group-membership		the group by sending a request to the related group-membership
	resource at the KDC. Based on the application requirements and		resource at the KDC. Based on the application requirements and
	policies, the KDC may perform a group rekeying by generating new		policies, the KDC may perform a group rekeying by generating new
	group keying material and distributing it to the current group		group keying material and distributing it to the current group
	members through the rekeying scheme used in the group.		members through the rekeying scheme used in the group.
	At the end of the joining process, the joining node has received		At the end of the joining process, the joining node has received
	the parameters and group keying material from the KDC to securely		the parameters and group keying material from the KDC to securely
	communicate with the other group members. Also, the KDC has		communicate with the other group members. Also, the KDC has
	stored the association between the authorization information from		stored the association between the authorization information from
	the access token and the secure session with the joining node.		the access token and the secure communication association with
			the joining node.
	4. The joining node and the KDC maintain the secure association to		4. The joining node and the KDC maintain the secure communication
	support possible future communications. These especially include		association to support possible future communications. These
	key management operations, such as the retrieval of updated		especially include key management operations, such as the
	keying material or participation of a group rekeying process.		retrieval of updated keying material or the participation in a
			group rekeying process.
	5. The joining node can communicate securely with the other group		5. The joining node can communicate securely with the other group
	members by using the keying material provided in step 3.		members by using the keying material obtained in step 3.
	C AS KDC Group		C AS KDC Group
	| | | Members		| | | Members
	/ | | | |		/ | | | |
	| |--- Authorization Request -->| | |		| |--- Authorization Request -->| | |
	| | | | |		| | | | |
	| |<-- Authorization Response --| | |		| |<-- Authorization Response --| | |
	(*) < | | | |		(*) < | | | |
	| | | | |		| | | | |
	| |--- Token Transfer Request ---->| |		| |--- Token Transfer Request ---->| |
	skipping to change at line 660 ¶		skipping to change at line 665 ¶
	3.2. Authorization Response		3.2. Authorization Response
	The AS processes the Authorization Request as defined in		The AS processes the Authorization Request as defined in
	Section 5.8.2 of [RFC9200], especially verifying that the Client is		Section 5.8.2 of [RFC9200], especially verifying that the Client is
	authorized to access the specified groups with the requested roles or		authorized to access the specified groups with the requested roles or
	possibly a subset of those.		possibly a subset of those.
	In case of successful verification, the Authorization Response sent		In case of successful verification, the Authorization Response sent
	from the AS to the Client is also defined in Section 5.8.2 of		from the AS to the Client is also defined in Section 5.8.2 of
	[RFC9200]. Note that the parameter 'expires_in' MAY be omitted if		[RFC9200]. Note that the 'expires_in' parameter MAY be omitted if
	the application defines how the expiration time is communicated to		the application defines how the expiration time is communicated to
	the Client via other means or if it establishes a default value.		the Client via other means or if it establishes a default value.
	Additionally, when included, the following parameter MUST have the		Additionally, when included, the following parameter MUST have the
	corresponding values:		corresponding values:
	* 'scope' has the same format and encoding of 'scope' in the		* 'scope' has the same format and encoding of 'scope' in the
	Authorization Request, as defined in Section 3.1. If this		Authorization Request, as defined in Section 3.1. If this
	parameter is not present, the granted scope is equal to the one		parameter is not present, the granted scope is equal to the one
	requested in Section 3.1.		requested in Section 3.1.
	The proof-of-possession access token in the 'access_token' parameter		The proof-of-possession access token in the 'access_token' parameter
	MUST contain the following:		MUST contain the following:
	* a confirmation claim (for example, see 'cnf' defined in		* a confirmation claim (for example, see 'cnf' defined in
	Section 3.1 of [RFC8747] for CWT);		Section 3.1 of [RFC8747] for CWTs);
	* an expiration time claim (for example, see 'exp' defined in		* an expiration time claim (for example, see 'exp' defined in
	Section 3.1.4 of [RFC8392] for CWT); and		Section 3.1.4 of [RFC8392] for CWTs); and
	* a scope claim (for example, see 'scope' registered in Section 8.14		* a scope claim (for example, see 'scope' registered in Section 8.14
	of [RFC9200] for CWT).		of [RFC9200] for CWTs).
	If the 'scope' parameter is present in the Authorization Response,		If the 'scope' parameter is present in the Authorization Response,
	this claim specifies the same access control information as in the		this claim specifies the same access control information as in the
	'scope' parameter. Instead, if the 'scope' parameter is not		'scope' parameter. Instead, if the 'scope' parameter is not
	present in the Authorization Response, this claim specifies the		present in the Authorization Response, this claim specifies the
	same access control information as in the 'scope' parameter of the		same access control information as in the 'scope' parameter of the
	Authorization Request, if the parameter is present therein, or the		Authorization Request, if the parameter is present therein, or the
	default scope that the AS is granting the Client otherwise.		default scope that the AS is granting the Client otherwise.
	By default, this claim has the same encoding as the 'scope'		By default, this claim has the same encoding as the 'scope'
	parameter in the Authorization Request, as defined in Section 3.1.		parameter in the Authorization Request, as defined in Section 3.1.
	Optionally, an alternative extended format of scope defined in		Optionally, an alternative extended format of scope defined in
	Section 7 can be used. This format explicitly signals the		Section 7 can be used. This format explicitly signals the
	semantics used to express the actual access control information,		semantics used to express the actual access control information,
	which has to be parsed. This enables a Resource Server to		which has to be parsed. This enables a Resource Server to
	correctly process a received access token, also in case:		correctly process a received access token, also in case:
	- the Resource Server implements a KDC that supports multiple		- The Resource Server implements a KDC that supports multiple
	application profiles of this specification using different		application profiles of this specification using different
	scope semantics and/or		scope semantics and/or
	- the Resource Server implements further services beyond a KDC		- The Resource Server implements further services beyond a KDC
	for group communication using different scope semantics.		for group communication using different scope semantics.
	If the Authorization Server is aware that this applies to the		If the Authorization Server is aware that this applies to the
	Resource Server for which the access token is issued, the		Resource Server for which the access token is issued, the
	Authorization Server SHOULD use the extended format of scope		Authorization Server SHOULD use the extended format of scope
	defined in Section 7.		defined in Section 7.
	The access token MAY additionally contain other claims that the		The access token MAY additionally contain other claims that the
	transport profile of ACE or other optional parameters require.		transport profile of ACE or other optional parameters require.
	skipping to change at line 727 ¶		skipping to change at line 732 ¶
	previously authorized and for which the AS still stores a valid non-		previously authorized and for which the AS still stores a valid non-
	expired access token, the AS MAY reply with that token. Note that it		expired access token, the AS MAY reply with that token. Note that it
	is up to application profiles of ACE to make sure that reposting the		is up to application profiles of ACE to make sure that reposting the
	same access token does not cause reuse of keying material between		same access token does not cause reuse of keying material between
	nodes (for example, that is accomplished with the use of random		nodes (for example, that is accomplished with the use of random
	nonces in [RFC9203]).		nonces in [RFC9203]).
	3.3. Token Transferring		3.3. Token Transferring
	The Client sends a Token Transfer Request to the KDC, i.e., a CoAP		The Client sends a Token Transfer Request to the KDC, i.e., a CoAP
	POST request including the access token and targeting the authz-info		POST request including the access token and targeting the /authz-info
	endpoint (see Section 5.10.1 of [RFC9200]).		endpoint (see Section 5.10.1 of [RFC9200]).
	Note that this request deviates from the one defined in [RFC9200],		Note that this request deviates from the one defined in [RFC9200],
	since it allows asking the KDC for additional information concerning		since it allows asking the KDC for additional information concerning
	the authentication credentials used in the group to ensure source		the authentication credentials used in the group to ensure source
	authentication, as well as for possible additional group parameters.		authentication, as well as for possible additional group parameters.
	The joining node MAY ask for this information from the KDC through		The joining node MAY ask for this information from the KDC through
	the same Token Transfer Request. In this case, the message MUST have		the same Token Transfer Request. In this case, the message MUST have
	Content-Format "application/ace+cbor" as defined in Section 8.16 of		Content-Format "application/ace+cbor" registered in Section 8.16 of
	[RFC9200], and the message payload MUST be formatted as a CBOR map,		[RFC9200], and the message payload MUST be formatted as a CBOR map,
	which MUST include the access token. The CBOR map MAY additionally		which MUST include the access token. The CBOR map MAY additionally
	include the following parameter, which, if included, MUST have the		include the following parameter, which, if included, MUST have the
	format and value as specified below.		format and value as specified below.
	* 'sign_info': defined in Section 3.3.1, specifying the CBOR simple		* 'sign_info': defined in Section 3.3.1, specifying the CBOR simple
	value "null" (0xf6) to request information about the signature		value null (0xf6) to request information about the signature
	algorithm, the signature algorithm parameters, the signature key		algorithm, the signature algorithm parameters, the signature key
	parameters, and the exact format of authentication credentials		parameters, and the exact format of authentication credentials
	used in the groups that the Client has been authorized to join.		used in the groups that the Client has been authorized to join.
	Alternatively, such information may be pre-configured on the joining		Alternatively, such information may be pre-configured on the joining
	node or may be retrieved by alternative means. For example, the		node or may be retrieved by alternative means. For example, the
	joining node may have performed an early group discovery process and		joining node may have performed an early group discovery process and
	obtained the link to the associated group-membership resource at the		obtained the link to the associated group-membership resource at the
	KDC, along with attributes that describe the group configuration		KDC, along with attributes that describe the group configuration
	(e.g., see [OSCORE-DISCOVERY]).		(e.g., see [OSCORE-DISCOVERY]).
	After successful verification, the Client is authorized to receive		After successful verification, the Client is authorized to receive
	the group keying material from the KDC and join the group. Hence,		the group keying material from the KDC and join the group. Hence,
	the KDC replies to the Client with a Token Transfer Response, i.e., a		the KDC replies to the Client with a Token Transfer Response, i.e., a
	CoAP 2.01 (Created) response.		CoAP 2.01 (Created) response.
	The Token Transfer Response MUST have Content-Format "application/		The Token Transfer Response MUST have Content-Format "application/
	ace+cbor", and its payload is a CBOR map. Note that this deviates		ace+cbor", and its payload is a CBOR map. Note that this deviates
	from what is defined in the ACE framework, where the response from		from what is defined in the ACE framework, where the response from
	the authz-info endpoint is defined as conveying no payload (see		the /authz-info endpoint is defined as conveying no payload (see
	Section 5.10.1 of [RFC9200]).		Section 5.10.1 of [RFC9200]).
	If a scope entry in the access token specifies a role that requires		If a scope entry in the access token specifies a role that requires
	the Client to send its own authentication credential to the KDC when		the Client to send its own authentication credential to the KDC when
	joining the related group, then the CBOR map MUST include the		joining the related group, then the CBOR map MUST include the
	parameter 'kdcchallenge' defined in Section 3.3.2, specifying a		'kdcchallenge' parameter defined in Section 3.3.2, specifying a
	dedicated challenge N_S generated by the KDC.		dedicated challenge N_S generated by the KDC.
	Later, when joining the group (see Section 4.3.1.1), the Client uses		Later, when joining the group (see Section 4.3.1.1), the Client uses
	the 'kdcchallenge' value and additional information to build a proof-		the 'kdcchallenge' value and additional information to build a proof-
	of-possession (PoP) input. In turn, this is used to compute PoP		of-possession (PoP) input. In turn, this is used to compute a PoP
	evidence, which the Client also provides to the KDC in order to prove		evidence, which the Client also provides to the KDC in order to prove
	possession of its own private key (see the 'client_cred_verify'		possession of its own private key (see the 'client_cred_verify'
	parameter in Section 4.3.1).		parameter in Section 4.3.1).
	While storing the access token, the KDC MUST store the 'kdcchallenge'		While storing the access token, the KDC MUST store the 'kdcchallenge'
	value associated with the Client at least until it receives a Join		value associated with the Client at least until it receives a Join
	Request from the Client (see Section 4.3.1.1) to be able to verify		Request from the Client (see Section 4.3.1.1) to be able to verify
	the PoP evidence provided during the join process and thus that the		the PoP evidence provided during the join process and thus that the
	Client possesses its own private key. The KDC deletes the		Client possesses its own private key. The KDC deletes the
	'kdcchallenge' value associated with the Client upon deleting the		'kdcchallenge' value associated with the Client upon deleting the
	skipping to change at line 821 ¶		skipping to change at line 826 ¶
	Note that the CBOR map specified as payload of the 2.01 (Created)		Note that the CBOR map specified as payload of the 2.01 (Created)
	response may include further parameters, e.g., according to the used		response may include further parameters, e.g., according to the used
	transport profile of ACE. Application profiles of this specification		transport profile of ACE. Application profiles of this specification
	MAY define additional parameters to use within this exchange (OPT2).		MAY define additional parameters to use within this exchange (OPT2).
	Application profiles of this specification MAY define alternative		Application profiles of this specification MAY define alternative
	specific negotiations of parameter values for the signature algorithm		specific negotiations of parameter values for the signature algorithm
	and signature keys if 'sign_info' is not used (OPT3).		and signature keys if 'sign_info' is not used (OPT3).
	If allowed by the used transport profile of ACE, the Client may		If allowed by the used transport profile of ACE, the Client may
	provide the Access Token to the KDC by other means than the Token		provide the access token to the KDC by other means than the Token
	Transfer Request. An example is the DTLS transport profile of ACE,		Transfer Request. An example is the DTLS transport profile of ACE,
	where the Client can provide the access token to the KDC during the		where the Client can provide the access token to the KDC during the
	secure session establishment (see Section 3.3.2 of [RFC9202]).		secure session establishment (see Section 3.3.2 of [RFC9202]).
	3.3.1. 'sign_info' Parameter		3.3.1. 'sign_info' Parameter
	The 'sign_info' parameter is an OPTIONAL parameter of the request and		The 'sign_info' parameter is an OPTIONAL parameter of the request and
	response messages exchanged between the Client and the authz-info		response messages exchanged between the Client and the /authz-info
	endpoint at the RS (see Section 5.10.1 of [RFC9200]).		endpoint at the RS (see Section 5.10.1 of [RFC9200]).
	This parameter allows the Client and the RS to exchange information		This parameter allows the Client and the RS to exchange information
	about a signature algorithm and about authentication credentials to		about a signature algorithm and about authentication credentials to
	accordingly use for signature verification. Its exact semantics and		accordingly use for signature verification. Its exact semantics and
	content are application specific.		content are application specific.
	In this specification and in application profiles building on it,		In this specification and in application profiles building on it,
	this parameter is used to exchange information about the signature		this parameter is used to exchange information about the signature
	algorithm and about authentication credentials to be used with it in		algorithm and about authentication credentials to be used with it in
	the groups indicated by the transferred access token as per its		the groups indicated by the transferred access token as per its
	'scope' claim (see Section 3.2).		'scope' claim (see Section 3.2).
	When used in the Token Transfer Request sent to the KDC (see		When used in the Token Transfer Request sent to the KDC (see
	Section 3.3), the 'sign_info' parameter specifies the CBOR simple		Section 3.3), the 'sign_info' parameter specifies the CBOR simple
	value "null" (0xf6). This is done to ask for information about the		value null (0xf6). This is done to ask for information about the
	signature algorithm and about the authentication credentials used in		signature algorithm and about the authentication credentials used in
	the groups that, as per the granted roles, the Client has been		the groups that, as per the granted roles, the Client has been
	authorized to join or interact with (e.g., as an external signature		authorized to join or interact with (e.g., as an external signature
	verifier).		verifier).
	When used in the following Token Transfer Response from the KDC (see		When used in the following Token Transfer Response from the KDC (see
	Section 3.3), the 'sign_info' parameter is a CBOR array of one or		Section 3.3), the 'sign_info' parameter is a CBOR array of one or
	more elements. The number of elements is at most the number of		more elements. The number of elements is at most the number of
	groups that the Client has been authorized to join or interact with.		groups that the Client has been authorized to join or interact with.
	Each element contains information about signing parameters and about		Each element contains information about signing parameters and about
	skipping to change at line 887 ¶		skipping to change at line 892 ¶
	* The fourth element 'sign_key_parameters' is a CBOR array that		* The fourth element 'sign_key_parameters' is a CBOR array that
	indicates the parameters of the key used with the signature		indicates the parameters of the key used with the signature
	algorithm in the groups identified by the 'gname' values. Its		algorithm in the groups identified by the 'gname' values. Its
	content depends on the value of 'sign_alg'. It is REQUIRED for		content depends on the value of 'sign_alg'. It is REQUIRED for
	application profiles to define the possible values and structures		application profiles to define the possible values and structures
	for the elements of this parameter (REQ5).		for the elements of this parameter (REQ5).
	* The fifth element 'cred_fmt' is either a CBOR integer indicating		* The fifth element 'cred_fmt' is either a CBOR integer indicating
	the format of authentication credentials used in the groups		the format of authentication credentials used in the groups
	identified by the 'gname' values or has the CBOR simple value		identified by the 'gname' values or has the CBOR simple value null
	"null" (0xf6), which indicates that the KDC does not act as a		(0xf6), which indicates that the KDC does not act as a repository
	repository of authentication credentials for group members. Its		of authentication credentials for group members. Its acceptable
	acceptable integer values are taken from the "Label" column of the		integer values are taken from the "Label" column of the "COSE
	"COSE Header Parameters" registry [COSE.Header.Parameters], with		Header Parameters" registry [COSE.Header.Parameters], with some of
	some of those values also indicating the type of container to use		those values also indicating the type of container to use for
	for exchanging the authentication credentials with the KDC (e.g.,		exchanging the authentication credentials with the KDC (e.g., a
	a chain or bag of certificates). It is REQUIRED for application		chain or bag of certificates). It is REQUIRED for application
	profiles to define specific values to use for this parameter		profiles to define specific values to use for this parameter,
	consistently with the acceptable formats of authentication		consistently with the acceptable formats of authentication
	credentials (REQ6).		credentials (REQ6).
	The CDDL notation [RFC8610] of the 'sign_info' parameter is given		The CDDL notation [RFC8610] of the 'sign_info' parameter is given
	below.		below.
	sign_info = sign_info_req / sign_info_resp		sign_info = sign_info_req / sign_info_resp
	sign_info_req = null ; in the Token Transfer		sign_info_req = null ; in the Token Transfer
	; Request to the KDC		; Request to the KDC
	skipping to change at line 931 ¶		skipping to change at line 936 ¶
	This format is consistent with every signature algorithm currently		This format is consistent with every signature algorithm currently
	defined in [RFC9053], i.e., with algorithms that have only the COSE		defined in [RFC9053], i.e., with algorithms that have only the COSE
	key type as their COSE capability. Appendix B describes how the		key type as their COSE capability. Appendix B describes how the
	format of each 'sign_info_entry' can be generalized for possible		format of each 'sign_info_entry' can be generalized for possible
	future registered algorithms having a different set of COSE		future registered algorithms having a different set of COSE
	capabilities.		capabilities.
	3.3.2. 'kdcchallenge' Parameter		3.3.2. 'kdcchallenge' Parameter
	The 'kdcchallenge' parameter is an OPTIONAL parameter of the response		The 'kdcchallenge' parameter is an OPTIONAL parameter of the response
	message returned from the authz-info endpoint at the RS, as defined		message returned from the /authz-info endpoint at the RS, as defined
	in Section 5.10.1 of [RFC9200]. This parameter contains a challenge		in Section 5.10.1 of [RFC9200]. This parameter contains a challenge
	generated by the RS and provided to the Client.		generated by the RS and provided to the Client.
	In this specification and in application profiles building on it, the		In this specification and in application profiles building on it, the
	Client can use this challenge to prove possession of its own private		Client can use this challenge to prove possession of its own private
	key in the Join Request (see the 'client_cred_verify' parameter in		key in the Join Request (see the 'client_cred_verify' parameter in
	Section 4.3.1).		Section 4.3.1).
	4. KDC Functionalities		4. KDC Functionalities
	skipping to change at line 954 ¶		skipping to change at line 959 ¶
	group membership management.		group membership management.
	In particular, this section defines the interface available at the		In particular, this section defines the interface available at the
	KDC, specifies the handlers of each resource provided by the KDC		KDC, specifies the handlers of each resource provided by the KDC
	interface, and describes how Clients interact with those resources to		interface, and describes how Clients interact with those resources to
	join a group and to perform additional operations as group members.		join a group and to perform additional operations as group members.
	A key operation that the Client can perform after transferring the		A key operation that the Client can perform after transferring the
	access token to the KDC is a Join Request-Response exchange with the		access token to the KDC is a Join Request-Response exchange with the
	KDC. In the Join Request, the Client specifies the group it requests		KDC. In the Join Request, the Client specifies the group it requests
	to join (see Section 4.3.1.1). The KDC will then verify the access		to join (see Section 4.3.1.1). The KDC will then check the stored
	token and that the Client is authorized to join the specified group.		access token associated with the Client and verify that the Client is
	If so, the KDC provides the Client with the keying material to		accordingly authorized to join the specified group. In case of
	securely communicate with the other members of the group.		successful verification, the KDC provides the Client with the keying
			material to securely communicate with the other members of the group.
	Later on as a group member, the Client can also rely on the interface		Later on as a group member, the Client can also rely on the interface
	at the KDC to perform additional operations consistent with the roles		at the KDC to perform additional operations consistent with the roles
	it has in the group.		it has in the group.
	4.1. Interface at the KDC		4.1. Interface at the KDC
	The KDC provides its interface by hosting the following resources.		The KDC provides its interface by hosting the following resources.
	Note that the root url-path "ace-group" used hereafter is a default		Note that the root url-path "ace-group" used hereafter is a default
	name; implementations are not required to use this name and can		name; implementations are not required to use this name and can
	define their own instead.		define their own instead.
	If request messages sent to the KDC as well as success response		If request messages sent to the KDC as well as success response
	messages from the KDC include a payload and specify a Content-Format,		messages from the KDC include a payload and specify a Content-Format,
	those messages MUST have Content-Format "application/ace-		those messages MUST have Content-Format "application/ace-
	groupcomm+cbor", as defined in Section 11.2. CBOR labels for the		groupcomm+cbor", which is registered in Section 11.2. CBOR map keys
	message parameters are defined in Section 8.		used for the message parameters are defined in Section 8.
	* /ace-group : the path of this root resource is invariant once the		* /ace-group : the path of this root resource is invariant once the
	resource is established and indicates that this specification is		resource is established and indicates that this specification is
	used. If other applications run on a KDC implementing this		used. If other applications run on a KDC implementing this
	specification and use this same path, those applications will		specification and use this same path, those applications will
	collide, and a mechanism will be needed to differentiate the		collide, and a mechanism will be needed to differentiate the
	endpoints.		endpoints.
	A Client can access this resource in order to retrieve a set of		A Client can access this resource in order to retrieve a set of
	group names, each corresponding to one of the specified group		group names, each corresponding to one of the specified group
	identifiers. This operation is described in Section 4.2.1.1.		identifiers. This operation is described in Section 4.2.1.1.
	Clients may be authorized to access this resource even without		Clients may be authorized to access this resource even without
	being members of any group at the KDC and even if they are not		being members of any group managed by the KDC and even if they are
	authorized to become group members (e.g., when authorized to be		not authorized to become group members (e.g., when authorized to
	external signature verifiers).		be external signature verifiers).
	The Interface Description (if=) Link Target Attribute value		The Interface Description (if=) Link Target Attribute value
	"ace.groups" is registered in Section 11.5 and can be used to		"ace.groups" is registered in Section 11.5 and can be used to
	describe the interface provided by this root resource.		describe the interface provided by this root resource.
	The example below shows an exchange with a KDC with address		The example below shows an exchange with a KDC with address
	2001:db8::ab that hosts the resource /ace-group and returns a link		2001:db8::ab that hosts the resource /ace-group and returns a link
	to such a resource in link-format [RFC6690].		to such a resource in link-format [RFC6690].
	Request:		Request:
	Header: GET (Code=0.01)		Header: GET (Code=0.01)
	Uri-Host: "kdc.example.com"		Uri-Host: "kdc.example.com"
	Uri-Path: ".well-known"		Uri-Path: ".well-known"
	Uri-Path: "core"		Uri-Path: "core"
	Uri-Query: "if=ace.groups"		Uri-Query: "if=ace.groups"
	Response:		Response:
	Header: Content (Code=2.05)		Header: Content (Code=2.05)
	Content-Format: 40 (application/link-format)		Content-Format: application/link-format
	Payload:		Payload:
	<coap://[2001:db8::ab]/ace-group>;if="ace.groups"		<coap://[2001:db8::ab]/ace-group>;if="ace.groups"
	* /ace-group/GROUPNAME : one such sub-resource to /ace-group is		* /ace-group/GROUPNAME : one such sub-resource to /ace-group is
	hosted for each group with the name GROUPNAME that the KDC		hosted for each group with the name GROUPNAME that the KDC
	manages. In particular, it is the group-membership resource		manages. In particular, it is the group-membership resource
	associated with that group, and it contains the symmetric group		associated with that group, and it contains the symmetric group
	keying material of that group.		keying material of that group.
	A Client can access this resource in order to join the group with		A Client can access this resource in order to join the group with
	skipping to change at line 1046 ¶		skipping to change at line 1052 ¶
	Header: GET (Code=0.01)		Header: GET (Code=0.01)
	Uri-Host: "kdc.example.com"		Uri-Host: "kdc.example.com"
	Uri-Path: ".well-known"		Uri-Path: ".well-known"
	Uri-Path: "core"		Uri-Path: "core"
	Uri-Query: "if=ace.group"		Uri-Query: "if=ace.group"
	Response:		Response:
	Header: Content (Code=2.05)		Header: Content (Code=2.05)
	Content-Format: 40 (application/link-format)		Content-Format: application/link-format
	Payload:		Payload:
	<coap://[2001:db8::ab]/ace-group/gp1>;if="ace.group"		<coap://[2001:db8::ab]/ace-group/gp1>;if="ace.group"
	If it is not required that the value of the GROUPNAME URI path and		If it is not required that the value of the GROUPNAME URI path and
	the group name in the access token scope ('gname' in Section 3.2)		the group name in the access token scope ('gname' in Section 3.1)
	coincide, the KDC MUST implement a mechanism to map the GROUPNAME		coincide, the KDC MUST implement a mechanism to map the GROUPNAME
	value in the URI to the group name in order to refer to the		value in the URI to the group name in order to refer to the
	correct group (REQ7).		correct group (REQ7).
	* /ace-group/GROUPNAME/creds : the path of this resource is		* /ace-group/GROUPNAME/creds : the path of this resource is
	invariant once the resource is established. This resource		invariant once the resource is established. This resource
	contains the authentication credentials of all the members of the		contains the authentication credentials of all the members of the
	group with the name GROUPNAME.		group with the name GROUPNAME.
	This resource is created only in case the KDC acts as a repository		This resource is created only in case the KDC acts as a repository
	skipping to change at line 1087 ¶		skipping to change at line 1093 ¶
	contains the authentication credential of the KDC for the group		contains the authentication credential of the KDC for the group
	with the name GROUPNAME.		with the name GROUPNAME.
	This resource is created only in case the KDC has an associated		This resource is created only in case the KDC has an associated
	authentication credential and this is required for the correct		authentication credential and this is required for the correct
	group operation. It is REQUIRED for application profiles to		group operation. It is REQUIRED for application profiles to
	define whether the KDC has such an associated authentication		define whether the KDC has such an associated authentication
	credential (REQ8).		credential (REQ8).
	As a group member, a Client can access this resource in order to		As a group member, a Client can access this resource in order to
	retrieve the current authentication credential of the KDC.		retrieve the current authentication credential of the KDC. This
			operation is described in Section 4.5.1.1.
	Clients may be authorized to access this resource even without		Clients may be authorized to access this resource even without
	being group members, e.g., if authorized to be external signature		being group members, e.g., if authorized to be external signature
	verifiers for the group.		verifiers for the group.
	* /ace-group/GROUPNAME/policies : the path of this resource is		* /ace-group/GROUPNAME/policies : the path of this resource is
	invariant once the resource is established. This resource		invariant once the resource is established. This resource
	contains the group policies of the group with the name GROUPNAME.		contains the group policies of the group with the name GROUPNAME.
	A Client can access this resource as a group member in order to		A Client can access this resource as a group member in order to
	skipping to change at line 1146 ¶		skipping to change at line 1153 ¶
	The KDC is expected to fully provide the interface defined above. It		The KDC is expected to fully provide the interface defined above. It
	is otherwise REQUIRED for the application profiles of this		is otherwise REQUIRED for the application profiles of this
	specification to indicate which resources are not hosted, i.e., which		specification to indicate which resources are not hosted, i.e., which
	parts of the interface defined in this section are not supported by		parts of the interface defined in this section are not supported by
	the KDC (REQ9). Application profiles of this specification MAY		the KDC (REQ9). Application profiles of this specification MAY
	extend the KDC interface by defining additional handlers, as well as		extend the KDC interface by defining additional handlers, as well as
	defining additional resources and their handlers.		defining additional resources and their handlers.
	It is REQUIRED for application profiles of this specification to		It is REQUIRED for application profiles of this specification to
	register a Resource Type for the group-membership resource (REQ10),		register a Resource Type for the group-membership resources (REQ10).
	i.e., the group-membership resource at /ace-group/GROUPNAME. This		This Resource Type can be used to discover the correct URL for
	Resource Type can be used to discover the correct URL for sending a		sending a Join Request to the KDC. This Resource Type can also be
	Join Request to the KDC. This Resource Type can also be used to		used to indicate which specific application profile of this
	indicate which specific application profile of this specification is		specification is used by a specific group-membership resource at the
	used by a specific group-membership resource at the KDC.		KDC.
	It is REQUIRED for application profiles of this specification to		It is REQUIRED for application profiles of this specification to
	define what specific actions (e.g., CoAP methods) are allowed on each		define what specific actions (e.g., CoAP methods) are allowed on each
	resource provided by the KDC interface, depending on whether the		resource provided by the KDC interface, depending on whether the
	Client is a current group member, the roles that a Client is		Client is a current group member, the roles that a Client is
	authorized to take as per the obtained access token (see		authorized to take as per the obtained access token (see
	Section 3.1), and the roles that the Client has as current group		Section 3.1), and the roles that the Client has as current group
	member (REQ11).		member (REQ11).
	4.1.1. Operations Supported by Clients		4.1.1. Operations Supported by Clients
	It is expected that a Client minimally supports the following set of		It is expected that a Client minimally supports the following set of
	primary operations and corresponding interactions with the KDC.		primary operations and corresponding interactions with the KDC.
	* FETCH request to /ace-group/ in order to retrieve group names		* FETCH request to /ace-group/ in order to retrieve group names
	associated with group identifiers.		associated with group identifiers.
	* POST and GET requests to /ace-group/GROUPNAME/ in order to join a		* POST and GET requests to /ace-group/GROUPNAME/ in order to join a
	group (POST) and later retrieve the current group key material as		group (POST) and later retrieve the current group keying material
	a group member (GET).		as a group member (GET).
	* GET and FETCH requests to /ace-group/GROUPNAME/creds in order to		* GET and FETCH requests to /ace-group/GROUPNAME/creds in order to
	retrieve the authentication credentials of all the other group		retrieve the authentication credentials of all the other group
	members (GET) or only some of them by filtering (FETCH). While		members (GET) or only some of them by filtering (FETCH). While
	retrieving authentication credentials remains possible by using		retrieving authentication credentials remains possible by using
	GET requests, retrieval by filtering allows Clients to greatly		GET requests, retrieval by filtering allows Clients to greatly
	limit the size of exchanged messages.		limit the size of exchanged messages.
	* GET request to /ace-group/GROUPNAME/num in order to retrieve the		* GET request to /ace-group/GROUPNAME/num in order to retrieve the
	current version of the group key material as a group member.		current version of the group keying material as a group member.
	* DELETE request to /ace-group/GROUPNAME/nodes/NODENAME in order to		* DELETE request to /ace-group/GROUPNAME/nodes/NODENAME in order to
	leave the group.		leave the group.
	In addition, some Clients may rather not support the following set of		In addition, some Clients may rather not support the following set of
	secondary operations and corresponding interactions with the KDC.		secondary operations and corresponding interactions with the KDC.
	This can be specified, for instance, in compliance documents defining		This can be specified, for instance, in compliance documents defining
	minimalistic Clients and their capabilities in specific deployments.		minimalistic Clients and their capabilities in specific deployments.
	In turn, these might also have to consider the used application		In turn, these might also have to consider the used application
	profile of this specification.		profile of this specification.
	skipping to change at line 1234 ¶		skipping to change at line 1241 ¶
	and secondary operations and to provide accompanying considerations		and secondary operations and to provide accompanying considerations
	(REQ12).		(REQ12).
	4.1.2. Error Handling		4.1.2. Error Handling
	Upon receiving a request from a Client, the KDC MUST check that it is		Upon receiving a request from a Client, the KDC MUST check that it is
	storing a valid access token from that Client. If this is not the		storing a valid access token from that Client. If this is not the
	case, the KDC MUST reply with a 4.01 (Unauthorized) error response.		case, the KDC MUST reply with a 4.01 (Unauthorized) error response.
	Unless the request targets the /ace-group resource, the KDC MUST		Unless the request targets the /ace-group resource, the KDC MUST
	check that it is storing a valid access token from that Client such		check that it is storing a valid access token for that Client such
	that:		that:
	* the scope specified in the access token includes a scope entry		* the scope specified in the access token includes a scope entry
	related to the group name GROUPNAME associated with the targeted		related to the group name GROUPNAME associated with the targeted
	resource and		resource and
	* the set of roles specified in that scope entry allows the Client		* the set of roles specified in that scope entry allows the Client
	to perform the requested operation on the targeted resource		to perform the requested operation on the targeted resource
	(REQ11).		(REQ11).
	In case the KDC stores a valid access token but the verifications		In case the KDC stores a valid access token but the verifications
	above fail, the KDC MUST reply with a 4.03 (Forbidden) error		above fail, the KDC MUST reply with a 4.03 (Forbidden) error
	response. This response MAY be an AS Request Creation Hints, as		response. This response MAY be an AS Request Creation Hints, as
	defined in Section 5.3 of [RFC9200], in which case the Content-Format		defined in Section 5.3 of [RFC9200], in which case the Content-Format
	MUST be set to "application/ace+cbor".		MUST be "application/ace+cbor".
	If the request is not formatted correctly (e.g., required fields are		If the request is not formatted correctly (e.g., required fields are
	not present or are not encoded as expected), the handler MUST reply		not present or are not encoded as expected), the KDC MUST reply with
	with a 4.00 (Bad Request) error response.		a 4.00 (Bad Request) error response.
	If the request includes unknown or unexpected fields, the handler		If the request includes unknown or unexpected fields, the KDC MUST
	MUST silently ignore them and continue processing the request.		silently ignore them and continue processing the request.
	Application profiles of this specification MAY define optional or		Application profiles of this specification MAY define optional or
	mandatory payload formats for specific error cases (OPT4).		mandatory payload formats for specific error cases (OPT4).
	Some error responses from the KDC can convey error-specific		Some error responses from the KDC can convey error-specific
	information according to the problem-details format defined in		information according to the problem-details format defined in
	[RFC9290]. Such error responses MUST have Content-Format		[RFC9290]. Such error responses MUST have Content-Format
	"application/concise-problem-details+cbor". The payload of these		"application/concise-problem-details+cbor". The payload of these
	error responses MUST be a CBOR map specifying a Concise Problem		error responses MUST be a CBOR map specifying a Concise Problem
	Details data item (see Section 2 of [RFC9290]). The CBOR map is		Details data item (see Section 2 of [RFC9290]). The CBOR map is
	formatted as follows.		formatted as follows.
	skipping to change at line 1318 ¶		skipping to change at line 1325 ¶
	/ detail / -2: "Things will change after a		/ detail / -2: "Things will change after a
	group rekeying; try later",		group rekeying; try later",
	/ ace-groupcomm-error / 0: {		/ ace-groupcomm-error / 0: {
	/ error-id / 0: 4 / "No available node identifiers" /,		/ error-id / 0: 4 / "No available node identifiers" /,
	}		}
	}		}
	Figure 6: Example of an Error Response with Problem Details		Figure 6: Example of an Error Response with Problem Details
	The problem-details format (in general) and the Custom Problem Detail		The problem-details format (in general) and the Custom Problem Detail
	entry 'ace-groupcomm-error' (in particular) are OPTIONAL support for		entry 'ace-groupcomm-error' (in particular) are OPTIONAL to support
	Clients. A Client supporting the entry 'ace-groupcomm-error' and		for Clients. A Client supporting the entry 'ace-groupcomm-error' and
	that can understand the specified error may use that information to		that can understand the specified error may use that information to
	determine what actions to take next.		determine what actions to take next.
	Section 9 of this specification defines an initial set of error		Section 9 of this specification defines an initial set of error
	identifiers as possible values for the 'error-id' field. Application		identifiers as possible values for the 'error-id' field. Application
	profiles of this specification inherit this initial set of error		profiles of this specification inherit this initial set of error
	identifiers and MAY define additional values (OPT5).		identifiers and MAY define additional values (OPT5).
	4.2. /ace-group		4.2. /ace-group
	This resource implements the FETCH handler.		This resource implements the FETCH handler.
	4.2.1. FETCH Handler		4.2.1. FETCH Handler
	The FETCH handler receives group identifiers and returns the		The FETCH handler receives group identifiers and returns the
	corresponding group names and GROUPNAME URIs.		corresponding group names and GROUPNAME URIs.
	The handler expects a request with the payload formatted as a CBOR		The handler expects a request with the payload formatted as a CBOR
	map, which MUST contain the following fields:		map, which MUST contain the following fields:
	* 'gid': whose value is encoded as a CBOR array, containing one or		* 'gid': its value is encoded as a CBOR array, containing one or
	more group identifiers. The exact encoding of the group		more group identifiers. The exact encoding of the group
	identifier MUST be specified by the application profile (REQ13).		identifier MUST be specified by the application profile (REQ13).
	The Client indicates that it wishes to receive the group names of		The Client indicates that it wishes to receive the group names of
	all the groups having these identifiers.		all the groups having these identifiers.
	The handler identifies the groups where communications are secured by		The handler identifies the groups where communications are secured by
	using the keying material identified by those group identifiers.		using the keying material identified by those group identifiers.
	If all verifications succeed, the handler replies with a 2.05		If all verifications succeed, the handler replies with a 2.05
	(Content) response, whose payload is formatted as a CBOR map that		(Content) response, whose payload is formatted as a CBOR map that
	MUST contain the following fields:		MUST contain the following fields:
	* 'gid': whose value is encoded as a CBOR array, containing zero or		* 'gid': its value is encoded as a CBOR array, containing zero or
	more group identifiers. The handler indicates that those are the		more group identifiers. The handler indicates that those are the
	identifiers it is sending group names for. This CBOR array is a		identifiers it is sending group names for. This CBOR array is a
	subset of the 'gid' array in the FETCH request.		subset of the 'gid' array in the FETCH request.
	* 'gname': whose value is encoded as a CBOR array, containing zero		* 'gname': its value is encoded as a CBOR array, containing zero or
	or more group names. The elements of this array are encoded as		more group names. The elements of this array are encoded as text
	text strings. Each element of index i in this CBOR array is		strings. Each element of index i in this CBOR array is associated
	associated with the element of index i in the 'gid' array.		with the element of index i in the 'gid' array.
	* 'guri': whose value is encoded as a CBOR array, containing zero or		* 'guri': its value is encoded as a CBOR array, containing zero or
	more URIs, each indicating a group-membership resource. The		more URIs, each indicating a group-membership resource. The
	elements of this array are encoded as text strings. Each element		elements of this array are encoded as text strings. Each element
	of index i in this CBOR array is associated with the element of		of index i in this CBOR array is associated with the element of
	index i in the 'gid' array.		index i in the 'gid' array.
	If the KDC does not find any group associated with the specified		If the KDC does not find any group associated with the specified
	group identifiers, the handler returns a response with the payload		group identifiers, the handler returns a response with the payload
	formatted as a CBOR byte string of zero length.		formatted as a CBOR byte string of zero length (0x40).
	Note that the KDC only verifies that the node is authorized by the AS		Note that the KDC only verifies that the node is authorized by the AS
	to access this resource. Nodes that are not members of the group but		to access this resource. Nodes that are not members of the group but
	are authorized to do signature verification on the group messages may		are authorized to do signature verification on the group messages may
	be allowed to access this resource if the application needs it.		be allowed to access this resource if the application needs it.
	4.2.1.1. Retrieve Group Names		4.2.1.1. Retrieve Group Names
	In case the joining node only knows the group identifier of the group		In case the joining node only knows the group identifier of the group
	it wishes to join or about which it wishes to get updated information		it wishes to join or about which it wishes to get updated information
	from the KDC, the node can contact the KDC to request the		from the KDC, the node can contact the KDC to request the
	corresponding group name and group-membership resource URI. The node		corresponding group name and group-membership resource URI. In
	can request several group identifiers at once. It does so by sending		particular, it does so by sending a CoAP FETCH request to the /ace-
	a CoAP FETCH request to the /ace-group endpoint at the KDC formatted		group endpoint at the KDC formatted as defined in Section 4.2.1. The
	as defined in Section 4.2.1.		node can specify several group identifiers at once.
	Figure 7 gives an overview of the exchanges described above, and		Figure 7 gives an overview of the exchanges described above, and
	Figure 8 shows an example.		Figure 8 shows an example.
	Client KDC		Client KDC
	| |		| |
	|------------ Group Name and URI Retrieval Request: -------->|		|------------ Group Name and URI Retrieval Request: -------->|
	| FETCH /ace-group |		| FETCH /ace-group |
	| |		| |
	|<-- Group Name and URI Retrieval Response: 2.05 (Content) --|		|<-- Group Name and URI Retrieval Response: 2.05 (Content) --|
	| |		| |
	Figure 7: Message Flow of Group Name and URI Retrieval Request-		Figure 7: Message Flow of Group Name and URI Retrieval Request-
	Response		Response
	Request:		Request:
	Header: FETCH (Code=0.05)		Header: FETCH (Code=0.05)
	Uri-Host: "kdc.example.com"		Uri-Host: "kdc.example.com"
	Uri-Path: "ace-group"		Uri-Path: "ace-group"
	Content-Format: "application/ace-groupcomm+cbor"		Content-Format: application/ace-groupcomm+cbor
	Payload (in CBOR diagnostic notation):		Payload (in CBOR diagnostic notation):
	{ "gid": [1, 2] }		{
			/ gid / 0: [1, 2]
			}
	Response:		Response:
	Header: Content (Code=2.05)		Header: Content (Code=2.05)
	Content-Format: "application/ace-groupcomm+cbor"		Content-Format: application/ace-groupcomm+cbor
	Payload (in CBOR diagnostic notation):		Payload (in CBOR diagnostic notation):
	{ "gid": [1, 2], "gname": ["group1", "group2"],		{
	"guri": ["/ace-group/g1", "/ace-group/g2"] }		/ gid / 0: [1, 2],
			/ gname / 1: ["group1", "group2"],
			/ guri / 2: ["/ace-group/g1", "/ace-group/g2"]
			}
	Figure 8: Example of Group Name and URI Retrieval Request-Response		Figure 8: Example of Group Name and URI Retrieval Request-Response
	4.3. /ace-group/GROUPNAME		4.3. /ace-group/GROUPNAME
	This resource implements the POST and GET handlers.		This resource implements the POST and GET handlers.
	4.3.1. POST Handler		4.3.1. POST Handler
	The POST handler processes the Join Request sent by a Client to join		The POST handler processes the Join Request sent by a Client to join
	skipping to change at line 1439 ¶		skipping to change at line 1451 ¶
	joining process (see Section 4.3.1.1). At a high level, the POST		joining process (see Section 4.3.1.1). At a high level, the POST
	handler adds the Client to the list of current group members, adds		handler adds the Client to the list of current group members, adds
	the authentication credential of the Client to the list of the group		the authentication credential of the Client to the list of the group
	members' authentication credentials, and returns the symmetric group		members' authentication credentials, and returns the symmetric group
	keying material for the group identified by GROUPNAME.		keying material for the group identified by GROUPNAME.
	The handler expects a request with payload formatted as a CBOR map,		The handler expects a request with payload formatted as a CBOR map,
	which MAY contain the following fields, which, if included, MUST have		which MAY contain the following fields, which, if included, MUST have
	the format and value as specified below.		the format and value as specified below.
	* 'scope': with the value the specific group that the Client is		* 'scope': its value specifies the name of the group that the Client
	attempting to join, i.e., the group name, and the roles it wishes		is attempting to join and the roles that the client wishes to have
	to have in the group. This value is a CBOR byte string wrapping		in the group. This value is encoded as a CBOR byte string
	one scope entry, as defined in Section 3.1.		wrapping one scope entry, as defined in Section 3.1.
	* 'get_creds': if the Client wishes to receive the authentication		* 'get_creds': it is included if the Client wishes to receive the
	credentials of the current group members from the KDC. This		authentication credentials of the current group members from the
	parameter may be included in the Join Request if the KDC stores		KDC. This parameter may be included in the Join Request if the
	the authentication credentials of the group members, while it is		KDC stores the authentication credentials of the group members,
	not useful to include it if the Client obtains those		while it is not useful to include it if the Client obtains those
	authentication credentials through alternative means, e.g., from		authentication credentials through alternative means, e.g., from
	the AS. Note that including this parameter might result in a		the AS. Note that including this parameter might result in a
	following Join Response of a large size, which can be inconvenient		following Join Response of a large size, which can be inconvenient
	for resource-constrained devices.		for resource-constrained devices.
	If the Client wishes to retrieve the authentication credentials of		If the Client wishes to retrieve the authentication credentials of
	all the current group members, the 'get_creds' parameter MUST		all the current group members, the 'get_creds' parameter MUST
	encode the CBOR simple value "null" (0xf6). Otherwise, if the		encode the CBOR simple value null (0xf6). Otherwise, if the
	Client wishes to retrieve the authentication credentials of nodes		Client wishes to retrieve the authentication credentials of nodes
	with specific roles, the 'get_creds' parameter MUST encode a non-		with specific roles, the 'get_creds' parameter MUST encode a non-
	empty CBOR array containing the three elements 'inclusion_flag',		empty CBOR array containing the three elements 'inclusion_flag',
	'role_filter', and 'id_filter', as defined below.		'role_filter', and 'id_filter', as defined below.
	- The first element, namely 'inclusion_flag', encodes the CBOR		- The first element, namely 'inclusion_flag', encodes the CBOR
	simple value "true" (0xf5) if the Client wishes to receive the		simple value true (0xf5) if the Client wishes to receive the
	authentication credentials of the nodes having their node		authentication credentials of the nodes having their node
	identifier specified in 'id_filter' (i.e., selection by		identifier specified in 'id_filter' (i.e., selection by
	inclusive filtering). Instead, this element encodes the CBOR		inclusive filtering). Instead, this element encodes the CBOR
	simple value "false" (0xf4) if the Client wishes to receive the		simple value false (0xf4) if the Client wishes to receive the
	authentication credentials of the nodes that don't have the		authentication credentials of the nodes that do not have the
	node identifiers specified in the third element 'id_filter'		node identifiers specified in the third element 'id_filter'
	(i.e., selection by exclusive filtering). In the Join Request,		(i.e., selection by exclusive filtering). In the Join Request,
	this parameter encodes the CBOR simple value "true" (0xf5).		this parameter encodes the CBOR simple value true (0xf5).
	- The second element, namely 'role_filter', is a CBOR array.		- The second element, namely 'role_filter', is a CBOR array.
	Each element of the array contains one role or a combination of		Each element of the array contains one role or a combination of
	roles for the group identified by GROUPNAME. This parameter		roles for the group identified by GROUPNAME. This parameter
	indicates that the Client wishes to receive the authentication		indicates that the Client wishes to receive the authentication
	credentials of all the group members having any of the		credentials of all the group members having any of the
	specified roles or combination of roles (i.e., having any of		specified roles or combination of roles (i.e., having any of
	those single roles or at least all the roles indicated in any		those single roles or at least all the roles indicated in any
	of those combinations of roles).		of those combinations of roles).
	skipping to change at line 1543 ¶		skipping to change at line 1555 ¶
	* 'client_cred': encoded as a CBOR byte string, whose value is the		* 'client_cred': encoded as a CBOR byte string, whose value is the
	original binary representation of the Client's authentication		original binary representation of the Client's authentication
	credential. This parameter MUST be present if the KDC is managing		credential. This parameter MUST be present if the KDC is managing
	(collecting from and distributing to Clients) the authentication		(collecting from and distributing to Clients) the authentication
	credentials of the group members and the Client's role in the		credentials of the group members and the Client's role in the
	group will require the Client to send messages to one or more		group will require the Client to send messages to one or more
	group members. It is REQUIRED for application profiles to define		group members. It is REQUIRED for application profiles to define
	the specific formats that are acceptable to use for authentication		the specific formats that are acceptable to use for authentication
	credentials in the group (REQ6).		credentials in the group (REQ6).
	* 'cnonce': encoded as a CBOR byte string and including a dedicated		* 'cnonce': encoded as a CBOR byte string, whose value is a
	nonce N_C generated by the Client. This parameter MUST be		dedicated nonce N_C generated by the Client. This parameter MUST
	present.		be present.
	* 'client_cred_verify': encoded as a CBOR byte string. This		* 'client_cred_verify': encoded as a CBOR byte string. This
	parameter MUST be present if the 'client_cred' parameter is		parameter MUST be present if the 'client_cred' parameter is
	present and no authentication credential associated with the		present and no authentication credential associated with the
	Client's token can be retrieved for that group.		Client's access token can be retrieved for that group.
	This parameter contains proof-of-possession (PoP) evidence		The value of the CBOR byte string is a proof-of-possession (PoP)
	computed by the Client over the following PoP input: the scope		evidence computed by the Client over the following PoP input: the
	(encoded as a CBOR byte string) concatenated with N_S (encoded as		scope (encoded as a CBOR byte string) concatenated with N_S
	a CBOR byte string) concatenated with N_C (encoded as a CBOR byte		(encoded as a CBOR byte string) concatenated with N_C (encoded as
	string), where:		a CBOR byte string), where:
	- scope is the CBOR byte string either specified in the 'scope'		- scope is either specified in the 'scope' parameter above, if
	parameter above, if present, or encoding a default scope entry		present, or a default scope entry that the handler is expected
	that the handler is expected to know, if omitted;		to know otherwise;
	- N_S is the challenge received from the KDC in the		- N_S is the challenge received from the KDC in the
	'kdcchallenge' parameter of the 2.01 (Created) response to the		'kdcchallenge' parameter of the 2.01 (Created) response to the
	Token Transfer Request (see Section 3.3), encoded as a CBOR		Token Transfer Request (see Section 3.3), encoded as a CBOR
	byte string; and		byte string; and
	- N_C is the nonce generated by the Client and specified in the		- N_C is the nonce generated by the Client and specified in the
	'cnonce' parameter above, encoded as a CBOR byte string.		'cnonce' parameter above, encoded as a CBOR byte string.
	An example of PoP input to compute 'client_cred_verify' using CBOR		An example of PoP input to compute 'client_cred_verify' using CBOR
	encoding is given in Figure 10.		encoding is given in Figure 10.
	A possible type of PoP evidence is a signature that the Client		A possible type of PoP evidence is a signature that the Client
	computes by using its own private key, whose corresponding public		computes by using its own private key, whose corresponding public
	key is specified in the authentication credential carried in the		key is specified in the authentication credential carried in the
	'client_cred' parameter. Application profiles of this		'client_cred' parameter. Application profiles of this
	specification MUST specify the exact approaches used to compute		specification MUST specify the exact approaches used to compute
	the PoP evidence to include in 'client_cred_verify' and MUST		the PoP evidence to include in 'client_cred_verify' and MUST
	specify which of those approaches is used in which case (REQ14).		specify which of those approaches is used in which case (REQ14).
	If the token was not provided to the KDC through a Token Transfer		If the access token was not provided to the KDC through a Token
	Request (e.g., it is used directly to validate TLS instead), it is		Transfer Request (e.g., the access token is instead transferred
	REQUIRED of the specific application profile to define how the		during the establishment of a secure communication association),
	challenge N_S is generated (REQ15).		it is REQUIRED of the specific application profile to define how
			the challenge N_S is generated (REQ15).
	* 'creds_repo': which can be present if the format of the Client's		* 'creds_repo': it can be present if the format of the Client's
	authentication credential in the 'client_cred' parameter is a		authentication credential conveyed in the 'client_cred' parameter
	certificate. In such a case, this parameter has as its value the		is a certificate. In such a case, this parameter has as its value
	URI of the certificate. This parameter is encoded as a CBOR text		the URI of the certificate. This parameter is encoded as a CBOR
	string. Alternative specific encodings of this parameter MAY be		text string. Alternative specific encodings of this parameter MAY
	defined in application profiles of this specification (OPT6).		be defined in application profiles of this specification (OPT6).
	* 'control_uri': whose value is a full URI, encoded as a CBOR text		* 'control_uri': its value is a full URI, encoded as a CBOR text
	string. A default url-path is /ace-group/GROUPNAME/node, although		string. A default url-path is /ace-group/GROUPNAME/node, although
	implementations can use different ones instead. The URI MUST NOT		implementations can use different ones instead. The URI MUST NOT
	have url-path /ace-group/GROUPNAME.		have url-path /ace-group/GROUPNAME.
	If 'control_uri' is specified in the Join Request, the Client acts		If 'control_uri' is specified in the Join Request, the Client acts
	as a CoAP server and hosts a resource at this specific URI. The		as a CoAP server and hosts a resource at this specific URI. The
	KDC MAY use this URI to send CoAP requests to the Client (acting		KDC MAY use this URI to send CoAP requests to the Client (acting
	as a CoAP server in this exchange), for example, for one-to-one		as a CoAP server in this exchange), for example, for one-to-one
	provisioning of new group keying material when performing a group		provisioning of new group keying material when performing a group
	rekeying (see Section 4.8.1.1) or to inform the Client of its		rekeying (see Section 6.1) or to inform the Client of its removal
	removal from the group (see Section 5).		from the group (see Section 5).
	In particular, this resource is intended for communications		In particular, this resource is intended for communications
	exclusively concerning the group identified by GROUPNAME and whose		exclusively concerning the group identified by GROUPNAME and whose
	group name is specified in the 'scope' parameter, if present. If		group name is specified in the 'scope' parameter of the Join
	the KDC does not implement mechanisms using this resource for that		Request, if present therein. If the KDC does not implement
	group, it can ignore this parameter. Other additional		mechanisms using this resource for that group, it can ignore this
	functionalities of this resource MAY be defined in application		parameter. Other additional functionalities of this resource MAY
	profiles of this specifications (OPT7).		be defined in application profiles of this specifications (OPT7).
	scope, N_S, and N_C expressed in CBOR diagnostic notation:		scope, N_S, and N_C expressed in CBOR diagnostic notation:
	scope = h'826667726f7570316673656e646572'		scope = h'826667726f7570316673656e646572'
	N_S = h'018a278f7faab55a'		N_S = h'018a278f7faab55a'
	N_C = h'25a8991cd700ac01'		N_C = h'25a8991cd700ac01'
	scope, N_S, and N_C as CBOR encoded byte strings:		scope, N_S, and N_C as CBOR encoded byte strings:
	scope = 0x4f826667726f7570316673656e646572		scope = 0x4f826667726f7570316673656e646572
	N_S = 0x48018a278f7faab55a		N_S = 0x48018a278f7faab55a
	N_C = 0x4825a8991cd700ac01		N_C = 0x4825a8991cd700ac01
	PoP input:		PoP input:
	0x4f 826667726f7570316673656e646572		0x4f 826667726f7570316673656e646572
	48 018a278f7faab55a 48 25a8991cd700ac01		48 018a278f7faab55a 48 25a8991cd700ac01
	Figure 10: Example of PoP Input to Compute 'client_cred_verify'		Figure 10: Example of PoP Input to Compute 'client_cred_verify'
	Using CBOR Encoding		Using CBOR Encoding
	If the request does not include a 'scope' field, the KDC is expected		If the request does not include the 'scope' parameter, the KDC is
	to understand what roles the Client is requesting to join the group		expected to understand what roles the Client is requesting to join
	with. For example, as per the access token, the Client might have		the group with. For example, as per the access token, the Client
	been granted access to the group with only one role. If the KDC		might have been granted access to the group with only one role. If
	cannot determine which exact roles should be considered for the		the KDC cannot determine which exact roles should be considered for
	Client, it MUST reply with a 4.00 (Bad Request) error response.		the Client, it MUST reply with a 4.00 (Bad Request) error response.
	The handler considers the scope specified in the access token		The handler considers the scope specified in the access token
	associated with the Client and checks the scope entry related to the		associated with the Client and checks the scope entry related to the
	group identified by the GROUPNAME associated with the endpoint. In		group identified by the GROUPNAME associated with the endpoint. In
	particular, the handler checks whether the set of roles specified in		particular, the handler checks whether the set of roles specified in
	that scope entry includes all the roles that the Client wishes to		that scope entry includes all the roles that the Client wishes to
	have in the group as per the Join Request. If this is not the case,		have in the group as per the Join Request. If this is not the case,
	the KDC MUST reply with a 4.03 (Forbidden) error response.		the KDC MUST reply with a 4.03 (Forbidden) error response.
	If the KDC manages the group members' authentication credentials, the		If the KDC manages the group members' authentication credentials, the
	handler checks if one is included in the 'client_cred' field. If so,		handler checks if one is included in the 'client_cred' parameter. If
	the KDC retrieves the authentication credential and performs the		so, the KDC retrieves the authentication credential and performs the
	following actions.		following actions.
	* If the access token was provided through a Token Transfer Request		* If the access token was provided through a Token Transfer Request
	(see Section 3.3) but the KDC cannot retrieve the 'kdcchallenge'		(see Section 3.3) but the KDC cannot retrieve the 'kdcchallenge'
	associated with this Client (see Section 3.3), the KDC MUST reply		associated with this Client (see Section 3.3), the KDC MUST reply
	with a 4.00 (Bad Request) error response, which MUST also have		with a 4.00 (Bad Request) error response, which MUST also have
	Content-Format "application/ace-groupcomm+cbor". The payload of		Content-Format "application/ace-groupcomm+cbor". The payload of
	the error response is a CBOR map including a newly generated		the error response is a CBOR map including a newly generated
	'kdcchallenge' value, which is specified in the 'kdcchallenge'		'kdcchallenge' value, which is specified in the 'kdcchallenge'
	parameter. The KDC MUST store the newly generated value as the		parameter. The KDC MUST store the newly generated value as the
	skipping to change at line 1676 ¶		skipping to change at line 1689 ¶
	aligned with the possible associated parameters used in the group.		aligned with the possible associated parameters used in the group.
	If this verification fails, the handler MUST reply with a 4.00		If this verification fails, the handler MUST reply with a 4.00
	(Bad Request) error response. The response MUST have Content-		(Bad Request) error response. The response MUST have Content-
	Format "application/concise-problem-details+cbor" and is formatted		Format "application/concise-problem-details+cbor" and is formatted
	as defined in Section 4.1.2. Within the Custom Problem Detail		as defined in Section 4.1.2. Within the Custom Problem Detail
	entry 'ace-groupcomm-error', the value of the 'error-id' field		entry 'ace-groupcomm-error', the value of the 'error-id' field
	MUST be set to 2 ("Authentication credential incompatible with the		MUST be set to 2 ("Authentication credential incompatible with the
	group configuration").		group configuration").
	* The KDC verifies the PoP evidence contained in the		* The KDC verifies the PoP evidence conveyed in the
	'client_cred_verify' field. Application profiles of this		'client_cred_verify' parameter. Application profiles of this
	specification MUST specify the exact approaches used to verify the		specification MUST specify the exact approaches used to verify the
	PoP evidence and MUST specify which of those approaches is used in		PoP evidence and MUST specify which of those approaches is used in
	which case (REQ14).		which case (REQ14).
	If the PoP evidence does not pass verification, the handler MUST		If the PoP evidence does not pass verification, the handler MUST
	reply with a 4.00 (Bad Request) error response. The response MUST		reply with a 4.00 (Bad Request) error response. The response MUST
	have Content-Format "application/concise-problem-details+cbor" and		have Content-Format "application/concise-problem-details+cbor" and
	is formatted as defined in Section 4.1.2. Within the Custom		is formatted as defined in Section 4.1.2. Within the Custom
	Problem Detail entry 'ace-groupcomm-error', the value of the		Problem Detail entry 'ace-groupcomm-error', the value of the
	'error-id' field MUST be set to 3 ("Invalid Proof-of-Possession		'error-id' field MUST be set to 3 ("Invalid proof-of-possession
	evidence").		evidence").
	If no authentication credential is included in the 'client_cred'		If no authentication credential is conveyed in the 'client_cred'
	field, the handler checks if an authentication credential is already		parameter, the handler checks if the KDC currently stores an
	associated with the received access token and to the group identified		authentication credential that is associated with the access token
	by GROUPNAME (see also Section 4.3.1.1). Note that the same joining		and with the group identified by GROUPNAME (see also
	node may use different authentication credentials in different		Section 4.3.1.1). Note that the same joining node may use different
	groups, and all those authentication credentials would be associated		authentication credentials in different groups, and all those
	with the same access token.		authentication credentials would be associated with the same access
			token.
	If an eligible authentication credential for the Client is neither		If an eligible authentication credential for the Client is neither
	present in the 'client_cred' field nor retrieved from the stored ones		present in the 'client_cred' parameter nor retrieved from the stored
	at the KDC, it is RECOMMENDED that the handler stops the processing		ones at the KDC, it is RECOMMENDED that the handler stops the
	and replies with a 4.00 (Bad Request) error response. Application		processing and replies with a 4.00 (Bad Request) error response.
	profiles MAY define alternatives (OPT8).		Application profiles MAY define alternatives (OPT8).
	If, regardless of the reason, the KDC replies with a 4.00 (Bad		If, regardless of the reason, the KDC replies with a 4.00 (Bad
	Request) error response, the payload of the response MAY be a CBOR		Request) error response, the payload of the response MAY be a CBOR
	map. For instance, the CBOR map can include a 'sign_info' parameter		map. For instance, the CBOR map can include a 'sign_info' parameter
	formatted as 'sign_info_res' defined in Section 3.3.1, with the		formatted as 'sign_info_resp' defined in Section 3.3.1, with the
	'cred_fmt' element set to the CBOR simple value "null" (0xf6) if the		'cred_fmt' element set to the CBOR simple value null (0xf6) if the
	Client sent its own authentication credential and the KDC is not set		Client sent its own authentication credential and the KDC is not set
	to store authentication credentials of the group members. When the		to store authentication credentials of the group members. When the
	response payload is a CBOR map including such parameters, the error		response payload is a CBOR map including such parameters, the error
	response has Content-Format "application/ace-groupcomm+cbor".		response has Content-Format "application/ace-groupcomm+cbor".
	If all the verifications above succeed, the KDC proceeds as follows.		If all the verifications above succeed, the KDC proceeds as follows.
	First, only in case the Client is not already a group member, the		First, only in case the Client is not already a group member, the
	handler performs the following actions:		handler performs the following actions:
	* The handler adds the Client to the list of current members of the		* The handler adds the Client to the list of current members of the
	group.		group.
	* The handler assigns a name NODENAME to the Client and creates a		* The handler assigns a name NODENAME to the Client and creates a
	sub-resource to /ace-group/GROUPNAME at the KDC, i.e., "/ace-		sub-resource to /ace-group/GROUPNAME at the KDC, i.e., /ace-
	group/GROUPNAME/nodes/NODENAME".		group/GROUPNAME/nodes/NODENAME.
	* The handler associates the node identifier NODENAME with the		* The handler associates the node identifier NODENAME with the
	access token and the secure communication association for the		access token and the secure communication association for the
	Client.		Client.
	Then, the handler performs the following actions.		Then, the handler performs the following actions.
	* If the KDC manages the group members' authentication credentials:		* If the KDC manages the group members' authentication credentials:
	- The handler associates the retrieved Client's authentication		- The handler associates the retrieved Client's authentication
	credential to the tuple composed of the node name NODENAME, the		credential with the tuple composed of the node name NODENAME,
	group name GROUPNAME, and the received access token.		the group name GROUPNAME, and the access token.
	- The handler adds the retrieved Client's authentication		- The handler adds the retrieved Client's authentication
	credential to the stored list of authentication credentials		credential to the list of authentication credentials stored for
	stored for the group identified by GROUPNAME. If such a list		the group identified by GROUPNAME. If such a list already
	already includes an authentication credential for the Client,		includes an authentication credential for the Client, but a
	but a different authentication credential is specified in the		different authentication credential is specified in the
	'client_cred' field, then the handler MUST replace the old		'client_cred' parameter, then the handler MUST replace the old
	authentication credential in the list with the one specified in		authentication credential in the list with the one specified in
	the 'client_cred' field.		the 'client_cred' parameter.
	* If backward security is prescribed by application policies		* If backward security is prescribed by application policies
	installed at the KDC or by the used application profile of this		installed at the KDC or by the used application profile of this
	specification, then the KDC MUST generate new group keying		specification, then the KDC MUST generate new group keying
	material and securely distribute it to the current group members		material and securely distribute it to the current group members
	(see Section 6).		(see Section 6).
	* The handler returns a successful Join Response, as defined below,		* The handler returns a successful Join Response, as defined below,
	containing the symmetric group keying material; the group		which contains the symmetric group keying material, the group
	policies; and the authentication credentials of the current		policies, and the authentication credentials of the current
	members of the group if the KDC manages those and the Client		members of the group if the KDC manages those and the Client
	requested them.		requested those.
	The Join Response MUST have response code 2.01 (Created) if the		The Join Response MUST have response code 2.01 (Created) if the
	Client has been added to the list of group members in this join		Client has been added to the list of group members in this join
	exchange (see above) or 2.04 (Changed) otherwise, i.e., if the Client		exchange (see above) or 2.04 (Changed) otherwise, i.e., if the Client
	is rejoining the group without having left it.		is rejoining the group without having left it.
	The Join Response message MUST include the Location-Path CoAP option,		The Join Response message MUST include the Location-Path CoAP
	specifying the URI path to the sub-resource associated with the		Options, specifying the path to the sub-resource associated with the
	Client, i.e., "/ace-group/GROUPNAME/nodes/NODENAME".		Client, i.e., /ace-group/GROUPNAME/nodes/NODENAME.
	The Join Response message MUST have Content-Format "application/ace-		The Join Response message MUST have Content-Format "application/ace-
	groupcomm+cbor". The payload of the response is formatted as a CBOR		groupcomm+cbor". The payload of the response is formatted as a CBOR
	map, which MUST contain the following fields and values.		map, which MUST contain the following fields with the values
			specified below:
	* 'gkty': identifying the key type of the keying material specified		* 'gkty': identifying the key type of the keying material specified
	in the 'key' parameter. This parameter is encoded as a CBOR		in the 'key' parameter. This parameter is encoded as a CBOR
	integer or a CBOR text string. The set of values can be found in		integer or a CBOR text string. Possible values are taken from the
	the "Key Type" column of the "ACE Groupcomm Key Types" registry.		"Key Type Value" column of the "ACE Groupcomm Key Types" registry
	Implementations MUST verify that the key type matches the		defined in Section 11.8 of this specification. Implementations
	application profile being used, if present, as registered in the		MUST verify that the key type specified by this parameter matches
	"ACE Groupcomm Key Types" registry.		the application profile being used and, if applicable, that such
			an application profile is listed in the "Profile" column of the
			"ACE Groupcomm Key Types" registry for the key type in question.
	* 'key': containing the keying material for the group communication		* 'key': containing the keying material used for securing the group
	or information required to derive it.		communication or information required to derive such keying
			material.
	* 'num': containing the version number of the keying material for		* 'num': containing the current version number of the group keying
	the group communication, formatted as a CBOR integer. This is a		material, encoded as a CBOR integer. The version number has a
	strictly monotonic increasing field. The application profile MUST		value that increases in a strictly monotonic way as the group
	define the initial version number (REQ16).		keying material changes. The application profile MUST define the
			initial value of the version number (REQ16).
	The exact type of the keying material specified in the 'key'		The format of the keying material conveyed in the 'key' parameter
	parameter MUST be defined in application profiles of this		MUST be defined in application profiles of this specification
	specification (REQ17), together with values of 'gkty' accepted by the		(REQ17), together with corresponding key types to specify as value of
	application (REQ18). Additionally, documents specifying a type of		the 'gkty' parameter and that are accepted by the application
	keying material MUST register an entry in the "ACE Groupcomm Key		(REQ18). Additionally, documents specifying a type of keying
	Types" registry defined in Section 11.8, including its name, the		material MUST register an entry in the "ACE Groupcomm Key Types"
	corresponding value for the 'gkty parameter', and the application		registry defined in Section 11.8, including its name, the
	profile to be used with.		corresponding key type to specify as value for the 'gkty' parameter,
			and the application profile to be used with.
	+==========+================+=========+=============+===========+		+==========+================+=========+=============+===========+
	| Name | Key Type Value | Profile | Description | Reference |		| Name | Key Type Value | Profile | Description | Reference |
	+==========+================+=========+=============+===========+		+==========+================+=========+=============+===========+
	| Reserved | 0 | | This value | RFC 9594 |		| Reserved | 0 | | This value | RFC 9594 |
	| | | | is reserved | |		| | | | is reserved | |
	+----------+----------------+---------+-------------+-----------+		+----------+----------------+---------+-------------+-----------+
	Table 1: ACE Groupcomm Key Types		Table 1: ACE Groupcomm Key Types
	The Join Response SHOULD contain the following parameters:		The Join Response SHOULD contain the following fields with the values
			specified below:
	* 'exp': with the value of the expiration time of the keying		* 'exp': its value specifies the expiration time of the group keying
	material for the group communication, encoded as a CBOR unsigned		material specified in the 'key' parameter, encoded as a CBOR
	integer. This field contains a numeric value representing the		unsigned integer. The value is the number of seconds from
	number of seconds from 1970-01-01T00:00:00Z UTC until the		1970-01-01T00:00:00Z UTC until the specified UTC date/time,
	specified UTC date/time, ignoring leap seconds, analogous to what		ignoring leap seconds, analogous to what is specified for
	is specified for NumericDate in Section 2 of [RFC7519]. Group		NumericDate in Section 2 of [RFC7519]. After the time indicated
	members MUST NOT use the keying material after the time indicated		in this parameter, group members MUST NOT use the group keying
	in this field, and they can retrieve the new group keying material		material specified in the 'key' parameter. The group members can
	from the KDC.		retrieve the latest group keying material from the KDC.
	* 'exi': with the value of the residual lifetime of the keying		* 'exi': its value specifies the residual lifetime of the group
	material for the group communication, encoded as a CBOR unsigned		keying material, encoded as a CBOR unsigned integer. If the 'exp'
	integer. If the 'exp' parameter is included, this parameter MUST		parameter is included, this parameter MUST also be included. The
	also be included. This field contains a numeric value		value represents the residual lifetime of the group keying
	representing the residual lifetime of the keying material in		material specified in the 'key' parameter, i.e., it is the number
	seconds, i.e., the number of seconds between the current time at		of seconds between the current time at the KDC and the time when
	the KDC and the time when the keying material expires (as		the keying material expires (as specified in the 'exp' parameter,
	specified in the 'exp' parameter, if present). A Client		if present). A Client determines the expiration time of the
	determines the expiration time of the keying material by adding		keying material by adding the seconds specified in the 'exi'
	the seconds specified in the 'exi' parameter to its current time		parameter to its current time upon receiving the Join Response
	upon receiving the response containing the 'exi' parameter. The		containing the 'exi' parameter. After such an expiration time,
	Client MUST NOT use the keying material after such an expiration		the Client MUST NOT use the group keying material specified in the
	time, and it can retrieve the new group keying material from the		'key' parameter. The Client can retrieve the latest group keying
	KDC.		material from the KDC.
	If a Client has a reliable way to synchronize its internal clock with		If a Client has a reliable way to synchronize its internal clock with
	UTC, and both the 'exp' and 'exi' parameters are present, then the		UTC, and both the 'exp' and 'exi' parameters are present, then the
	Client MUST use the 'exp' parameter value as expiration time for the		Client MUST use the 'exp' parameter value as expiration time for the
	group keying material. Otherwise, the Client uses the 'exi'		group keying material. Otherwise, the Client uses the 'exi'
	parameter value.		parameter value to determine the expiration time as defined above.
	When a Client relies on the 'exi' parameter, the expiration time that		When a Client relies on the 'exi' parameter, the expiration time that
	it computes is offset in the future with respect to the actual		it computes is offset in the future with respect to the actual
	expiration time as intended by the KDC and specified in the 'exp'		expiration time as intended by the KDC and specified in the 'exp'
	parameter (if present). Such an offset is the amount of time between		parameter (if present). Such an offset is the amount of time between
	when the KDC sends the response message including the 'exi' parameter		when the KDC sends the response message including the 'exi' parameter
	and when the Client receives that message. That is, especially if		and when the Client receives that message. That is, especially if
	the delivery of the response to the Client is delayed, the Client		the delivery of the response to the Client is delayed, the Client
	will believe the keying material to be valid for a longer time than		will believe the keying material to be valid for a longer time than
	the KDC actually means. However, before approaching the actual		the KDC actually means. However, before approaching the actual
	expiration time, the KDC is expected to rekey the group and		expiration time, the KDC is expected to rekey the group and
	distribute new keying material (see Section 6).		distribute new keying material (see Section 6).
	Optionally, the Join Response MAY contain the following parameters,		Optionally, the Join Response MAY contain the following parameters,
	which, if included, MUST have the format and value as specified		which, if included, MUST have the format and value as specified
	below.		below.
	* 'ace_groupcomm_profile': with the value of a CBOR integer that		* 'ace_groupcomm_profile': its value is encoded as a CBOR integer
	MUST be used to uniquely identify the application profile for		and MUST be used to uniquely identify the application profile for
	group communication. Applications of this specification MUST		group communication. Applications of this specification MUST
	register an application profile identifier and the related value		register an application profile identifier and the related value
	for this parameter in the "ACE Groupcomm Profiles" registry		for this parameter in the "ACE Groupcomm Profiles" registry
	(REQ19).		(REQ19).
	+==========+========================+============+===========+		+==========+========================+============+===========+
	| Name | Description | CBOR Value | Reference |		| Name | Description | CBOR Value | Reference |
	+==========+========================+============+===========+		+==========+========================+============+===========+
	| Reserved | This value is reserved | 0 | [RFC-XXXX |		| Reserved | This value is reserved | 0 | RFC 9594 |
	+----------+------------------------+------------+-----------+		+----------+------------------------+------------+-----------+
	Table 2: ACE Groupcomm Profiles		Table 2: ACE Groupcomm Profiles
	* 'creds': which MUST be present if 'get_creds' was present in the		* 'creds': it MUST be present if 'get_creds' was present in the Join
	request; otherwise, it MUST NOT be present. This parameter is a		Request; otherwise, it MUST NOT be present. Its value is an
	CBOR array specifying the authentication credentials of the group		encoded CBOR array specifying the authentication credentials of
	members, i.e., of all of them or of the ones selected according to		the group members, i.e., of all of them or of the ones selected
	the 'get_creds' parameter in the request. In particular, each		according to the 'get_creds' parameter in the Join Request. In
	element of the array is a CBOR byte string, whose value is the		particular, each element of the array is a CBOR byte string, whose
	original binary representation of a group member's authentication		value is the original binary representation of a group member's
	credential. It is REQUIRED for application profiles to define the		authentication credential. It is REQUIRED for application
	specific formats of authentication credentials that are acceptable		profiles to define the specific formats of authentication
	to use in the group (REQ6).		credentials that are acceptable to use in the group (REQ6).
	* 'peer_roles': which SHOULD be present if 'creds' is also present;		* 'peer_roles': it SHOULD be present if 'creds' is also present;
	otherwise, it MUST NOT be present. This parameter is a CBOR array		otherwise, it MUST NOT be present. Its value is encoded as a CBOR
	of n elements, where n is the number of authentication credentials		array of n elements, where n is the number of authentication
	included in the 'creds' parameter (at most, the number of members		credentials included in the 'creds' parameter (at most, the number
	in the group). The i-th element of the array specifies the		of members in the group). The i-th element of the array specifies
	role(s) that the group member associated with the i-th		the role(s) that the group member associated with the i-th
	authentication credential in 'creds' has in the group. In		authentication credential in 'creds' has in the group. In
	particular, each array element is encoded like the role element of		particular, each array element is encoded like the role element of
	a scope entry, which is consistent with the used format (see		a scope entry, which is consistent with the used format (see
	Section 3.1).		Section 3.1).
	This parameter MAY be omitted if the Client can rely on other		This parameter MAY be omitted if the Client can rely on other
	means to unambiguously gain knowledge of the role of each group		means to unambiguously gain knowledge of the role of each group
	member whose associated authentication credential is specified in		member whose associated authentication credential is specified in
	the 'creds' parameter. For example, all such group members may		the 'creds' parameter. For example, all such group members may
	have the same role in the group joined by the Client, and such a		have the same role in the group joined by the Client, and such a
	skipping to change at line 1915 ¶		skipping to change at line 1936 ¶
	'client_cred' parameter of a Join Request (see Section 4.3.1.1) or		'client_cred' parameter of a Join Request (see Section 4.3.1.1) or
	of an Authentication Credential Update Request (see		of an Authentication Credential Update Request (see
	Section 4.9.1.1), the KDC is not expected to check that the		Section 4.9.1.1), the KDC is not expected to check that the
	authentication credential indicates the role(s) that the Client		authentication credential indicates the role(s) that the Client
	can have or has in the group in question. When preparing a Join		can have or has in the group in question. When preparing a Join
	Response, the KDC can decide whether to include the 'peer_roles'		Response, the KDC can decide whether to include the 'peer_roles'
	parameter, depending on the specific set of authentication		parameter, depending on the specific set of authentication
	credentials specified in the 'creds' parameter of that Join		credentials specified in the 'creds' parameter of that Join
	Response.		Response.
	* 'peer_identifiers': which MUST be present if 'creds' is also		* 'peer_identifiers': it MUST be present if 'creds' is also present;
	present; otherwise, it MUST NOT be present. This parameter is a		otherwise, it MUST NOT be present. Its value is encoded as a CBOR
	CBOR array of n elements, where n is the number of authentication		array of n elements, where n is the number of authentication
	credentials included in the 'creds' parameter (at most, the number		credentials included in the 'creds' parameter (at most, the number
	of members in the group). The i-th element of the array specifies		of members in the group). The i-th element of the array specifies
	the node identifier that the group member associated with the i-th		the node identifier that the group member associated with the i-th
	authentication credential in 'creds' has in the group. In		authentication credential in 'creds' has in the group. In
	particular, the i-th array element is encoded as a CBOR byte		particular, the i-th array element is encoded as a CBOR byte
	string, whose value is the node identifier of the group member.		string, whose value is the node identifier of the group member.
	The specific format of node identifiers of group members is		The specific format of node identifiers of group members is
	specified by the application profile (REQ25).		specified by the application profile (REQ25).
	* 'group_policies': with the value of a CBOR map, whose entries		* 'group_policies': its value is encoded as a CBOR map, whose
	specify how the group handles specific management aspects. These		elements specify how the group handles specific management
	include, for instance, approaches to achieve synchronization of		aspects. These include, for instance, approaches to achieve
	sequence numbers among group members. The elements of this field		synchronization of sequence numbers among group members. The
	are registered in the "ACE Groupcomm Policies" registry. This		possible elements of the CBOR map are registered in the "ACE
	specification defines the three elements "Sequence Number		Groupcomm Policies" registry defined in Section 11.10 of this
	Synchronization Methods", "Key Update Check Interval", and		specification. This specification defines the three elements
	"Expiration Delta", which are summarized in Table 3. Application		"Sequence Number Synchronization Methods", "Key Update Check
	profiles that build on this document MUST specify the exact		Interval", and "Expiration Delta", which are summarized in
	Content-Format and default value of included map entries (REQ20).		Table 3. Application profiles of this specification MUST specify
			the format, content, and default values for the entries of the
			CBOR map conveyed in the 'group_policies' parameter (REQ20).
	+=================+=======+======+===================+===========+		+=================+=======+======+===================+===========+
	| Name | CBOR | CBOR | Description | Reference |		| Name | CBOR | CBOR | Description | Reference |
	| | Label | Type | | |		| | Label | Type | | |
	+=================+=======+======+===================+===========+		+=================+=======+======+===================+===========+
	| Sequence Number | 0 | int | Method for | RFC 9594 |		| Sequence Number | 0 | int | Method for | RFC 9594 |
	| Synchronization | | or | recipient group | |		| Synchronization | | or | recipient group | |
	| Method | | tstr | members to | |		| Method | | tstr | members to | |
	| | | | synchronize with | |		| | | | synchronize with | |
	| | | | sequence numbers | |		| | | | sequence numbers | |
	skipping to change at line 1958 ¶		skipping to change at line 1981 ¶
	| | | | members. Its | |		| | | | members. Its | |
	| | | | value is taken | |		| | | | value is taken | |
	| | | | from the "Value" | |		| | | | from the "Value" | |
	| | | | column of the | |		| | | | column of the | |
	| | | | "Sequence Number | |		| | | | "Sequence Number | |
	| | | | Synchronization | |		| | | | Synchronization | |
	| | | | Method" | |		| | | | Method" | |
	| | | | registry. | |		| | | | registry. | |
	+-----------------+-------+------+-------------------+-----------+		+-----------------+-------+------+-------------------+-----------+
	| Key Update | 1 | int | Polling interval | RFC 9594 |		| Key Update | 1 | int | Polling interval | RFC 9594 |
	| Check Interval | | | in seconds for | |		| Check Interval | | | in seconds, for | |
	| | | | group members to | |		| | | | group members to | |
	| | | | check at the KDC | |		| | | | check at the KDC | |
	| | | | if the latest | |		| | | | if the latest | |
	| | | | group keying | |		| | | | group keying | |
	| | | | material is the | |		| | | | material is the | |
	| | | | one that they | |		| | | | one that they | |
	| | | | store. | |		| | | | store. | |
	+-----------------+-------+------+-------------------+-----------+		+-----------------+-------+------+-------------------+-----------+
	| Expiration | 2 | uint | Number of | RFC 9594 |		| Expiration | 2 | uint | Number of | RFC 9594 |
	| Delta | | | seconds from | |		| Delta | | | seconds from | |
	skipping to change at line 1983 ¶		skipping to change at line 2006 ¶
	| | | | MUST stop using | |		| | | | MUST stop using | |
	| | | | the group keying | |		| | | | the group keying | |
	| | | | material that | |		| | | | material that | |
	| | | | they store to | |		| | | | they store to | |
	| | | | decrypt incoming | |		| | | | decrypt incoming | |
	| | | | messages. | |		| | | | messages. | |
	+-----------------+-------+------+-------------------+-----------+		+-----------------+-------+------+-------------------+-----------+
	Table 3: ACE Groupcomm Policies		Table 3: ACE Groupcomm Policies
	* 'kdc_cred': encoded as a CBOR byte string, whose value is the		* 'kdc_cred': its value is the original binary representation of the
	original binary representation of the KDC's authentication		KDC's authentication credential, encoded as a CBOR byte string.
	credential. This parameter is used if the KDC has an associated		This parameter is used if the KDC has an associated authentication
	authentication credential and this is required for the correct		credential and this is required for the correct group operation.
	group operation. It is REQUIRED for application profiles to		It is REQUIRED for application profiles to define whether the KDC
	define whether the KDC has an authentication credential or not and		has an authentication credential as required for the correct group
	if this has to be provided through the 'kdc_cred' parameter		operation and if this has to be provided through the 'kdc_cred'
	(REQ8).		parameter (REQ8).
	In such a case, the KDC's authentication credential MUST have the		If the KDC has an authentication credential as required for the
	same format used for the authentication credentials of the group		correct group operation, the KDC's authentication credential MUST
	members. It is REQUIRED for application profiles to define the		have the same format used for the authentication credentials of
	specific formats that are acceptable to use for the authentication		the group members. It is REQUIRED for application profiles to
	credentials in the group (REQ6).		define the specific formats that are acceptable to use for the
			authentication credentials in the group (REQ6).
	* 'kdc_nonce': encoded as a CBOR byte string and including a		* 'kdc_nonce': its value is a dedicated nonce N_KDC generated by the
	dedicated nonce N_KDC generated by the KDC. This parameter MUST		KDC, encoded as a CBOR byte string. This parameter MUST be
	be present if the 'kdc_cred' parameter is present.		present if the 'kdc_cred' parameter is present.
	* 'kdc_cred_verify': encoded as a CBOR byte string. This parameter		* 'kdc_cred_verify': its value is as defined below and is encoded as
	MUST be present if the 'kdc_cred' parameter is present.		a CBOR byte string. This parameter MUST be present if the
			'kdc_cred' parameter is present.
	This parameter contains proof-of-possession (PoP) evidence		The value of this parameter is a proof-of-possession (PoP)
	computed by the KDC over the following PoP input: the nonce N_C		evidence computed by the KDC over the following PoP input: the
	(encoded as a CBOR byte string) concatenated with the nonce N_KDC		nonce N_C (encoded as a CBOR byte string) concatenated with the
	(encoded as a CBOR byte string), where:		nonce N_KDC (encoded as a CBOR byte string), where:
	- N_C is the nonce generated by the Client and specified in the		- N_C is the nonce generated by the Client and specified in the
	'cnonce' parameter of the Join Request, encoded as a CBOR byte		'cnonce' parameter of the Join Request.
	string.
	- N_KDC is the nonce generated by the KDC and specified in the		- N_KDC is the nonce generated by the KDC and specified in the
	'kdc_nonce' parameter, encoded as a CBOR byte string.		'kdc_nonce' parameter.
	An example of PoP input to compute 'kdc_cred_verify' using CBOR		An example of PoP input to compute 'kdc_cred_verify' using CBOR
	encoding is given in Figure 11.		encoding is given in Figure 11.
	A possible type of PoP evidence is a signature that the KDC		A possible type of PoP evidence is a signature that the KDC
	computes by using its own private key, whose corresponding public		computes by using its own private key, whose corresponding public
	key is specified in the authentication credential carried in the		key is specified in the authentication credential conveyed in the
	'kdc_cred' parameter. Application profiles of this specification		'kdc_cred' parameter. Application profiles of this specification
	MUST specify the exact approaches used by the KDC to compute the		MUST specify the approaches used by the KDC to compute the PoP
	PoP evidence to include in 'kdc_cred_verify' and MUST specify		evidence to include in 'kdc_cred_verify' and MUST specify which of
	which of those approaches is used in which case (REQ21).		those approaches is used in which case (REQ21).
	* 'rekeying_scheme': identifying the rekeying scheme that the KDC		* 'rekeying_scheme': identifying the rekeying scheme that the KDC
	uses to provide new group keying material to the group members.		uses to provide new group keying material to the group members.
	This parameter is encoded as a CBOR integer, whose value is taken		The value of this parameter is encoded as a CBOR integer and is
	from the "Value" column of the "ACE Groupcomm Rekeying Schemes"		taken from the "Value" column of the "ACE Groupcomm Rekeying
	registry defined in Section 11.13 of this specification.		Schemes" registry defined in Section 11.13 of this specification.
	+=======+================+===========================+===========+		+=======+================+===========================+===========+
	| Value | Name | Description | Reference |		| Value | Name | Description | Reference |
	+=======+================+===========================+===========+		+=======+================+===========================+===========+
	| 0 | Point-to-Point | The KDC individually | RFC 9594 |		| 0 | Point-to-Point | The KDC individually | RFC 9594 |
	| | | targets each node to | |		| | | targets each node to | |
	| | | rekey, using the | |		| | | rekey, using the | |
	| | | pairwise secure | |		| | | pairwise secure | |
	| | | communication | |		| | | communication | |
	| | | association with | |		| | | association with | |
	skipping to change at line 2080 ¶		skipping to change at line 2104 ¶
	different subset of the overall administrative keying material.		different subset of the overall administrative keying material.
	It is expected from separate documents to define how the advanced		It is expected from separate documents to define how the advanced
	group rekeying scheme, possibly indicated in the 'rekeying_scheme'		group rekeying scheme, possibly indicated in the 'rekeying_scheme'
	parameter, is used by an application profile of this		parameter, is used by an application profile of this
	specification. This includes defining the format of the		specification. This includes defining the format of the
	administrative keying material to specify in 'mgt_key_material'		administrative keying material to specify in 'mgt_key_material'
	consistently with the group rekeying scheme and the application		consistently with the group rekeying scheme and the application
	profile in question.		profile in question.
	* 'control_group_uri': with a full URI as the value, encoded as a		* 'control_group_uri': its value is a full URI, encoded as a CBOR
	CBOR text string. The URI MUST specify addressing information		text string. The URI MUST specify addressing information intended
	intended to reach all the members in the group. For example, this		to reach all the members in the group. For example, this can be a
	can be a multicast IP address, optionally together with a port		multicast IP address, optionally together with a port number that,
	number that, if omitted, defaults to 5683, i.e., the default port		if omitted, defaults to 5683, i.e., the default port number for
	number for the "coap" URI scheme (see Section 6.1 of [RFC7252]).		the "coap" URI scheme (see Section 6.1 of [RFC7252]). The URI
	The URI MUST include GROUPNAME in the url-path. A default url-		MUST include GROUPNAME in the url-path. A default url-path is
	path is /ace-group/GROUPNAME, although implementations can use		/ace-group/GROUPNAME, although implementations can use different
	different ones instead. The URI MUST NOT have url-path /ace-		ones instead. The URI MUST NOT have url-path /ace-
	group/GROUPNAME/node.		group/GROUPNAME/nodes.
	If 'control_group_uri' is included in the Join Response, the		If 'control_group_uri' is included in the Join Response, the
	Clients supporting this parameter act as CoAP servers, host a		Clients supporting this parameter act as CoAP servers, host a
	resource at this specific URI, and listen to the specified		resource at this specific URI, and listen to the specified
	addressing information.		addressing information.
	The KDC MAY use this URI to send one-to-many CoAP requests to the		The KDC MAY use this URI to send one-to-many CoAP requests to the
	Client group members (acting as CoAP servers in this exchange),		Client group members (acting as CoAP servers in this exchange),
	for example, for one-to-many provisioning of new group keying		for example, for one-to-many provisioning of new group keying
	material when performing a group rekeying (see Section 4.8.1.1) or		material when performing a group rekeying (see Section 6.2) or to
	to inform the Clients of their removal from the group (see		inform the Clients of their removal from the group (see
	Section 5).		Section 5).
	In particular, this resource is intended for communications		In particular, this resource is intended for communications
	exclusively concerning the group identified by GROUPNAME and whose		exclusively concerning the group identified by GROUPNAME and whose
	group name was specified in the 'scope' parameter of the Join		group name was specified in the 'scope' parameter of the Join
	Request, if present. If the KDC does not implement mechanisms		Request, if present. If the KDC does not implement mechanisms
	using this resource for that group, it can ignore this parameter.		using this resource for that group, it can ignore this parameter.
	Other additional functionalities of this resource MAY be defined		Other additional functionalities of this resource MAY be defined
	in application profiles of this specifications (OPT10).		in application profiles of this specifications (OPT10).
	skipping to change at line 2126 ¶		skipping to change at line 2150 ¶
	N_C = 0x4825a8991cd700ac01		N_C = 0x4825a8991cd700ac01
	N_KDC = 0x48cef04b2aa791bc6d		N_KDC = 0x48cef04b2aa791bc6d
	PoP input:		PoP input:
	0x48 25a8991cd700ac01 48 cef04b2aa791bc6d		0x48 25a8991cd700ac01 48 cef04b2aa791bc6d
	Figure 11: Example of PoP Input to Compute 'kdc_cred_verify'		Figure 11: Example of PoP Input to Compute 'kdc_cred_verify'
	Using CBOR Encoding		Using CBOR Encoding
	After sending the Join Response, if the KDC has an associated		After sending the Join Response, if the KDC has an associated
	authentication credential, the KDC MUST store the N_C value specified		authentication credential as required for the correct group
	in the 'cnonce' parameter of the Join Request as a 'clientchallenge'		operation, then the KDC MUST store the N_C value specified in the
	value associated with the Client, replacing the currently stored		'cnonce' parameter of the Join Request as a 'clientchallenge' value
	value (if any). If, as a group member, the Client later sends a GET		associated with the Client, replacing the currently stored value (if
	request to the /ace-group/GROUPNAME/kdc-cred resource for retrieving		any). If, as a group member, the Client later sends a GET request to
	the latest KDC's authentication credential (see Section 4.5.1), then		the /ace-group/GROUPNAME/kdc-cred resource for retrieving the latest
	the KDC is able to use the stored 'clientchallenge' for computing PoP		KDC's authentication credential (see Section 4.5.1), then the KDC
	evidence to include in the response sent to the Client, hence proving		uses the stored 'clientchallenge' for computing a PoP evidence to
	the possession of its own private key.		include in the response sent to the Client, hence proving the
			possession of its own private key.
	If the Join Response includes the 'kdc_cred_verify' parameter, the		If the Join Response includes the 'kdc_cred_verify' parameter, the
	Client verifies the conveyed PoP evidence and considers the group		Client verifies the conveyed PoP evidence and considers the group
	joining unsuccessful in case of failed verification. Application		joining unsuccessful in case of failed verification. Application
	profiles of this specification MUST specify the exact approaches used		profiles of this specification MUST specify the exact approaches used
	by the Client to verify the PoP evidence in 'kdc_cred_verify' and		by the Client to verify the PoP evidence in 'kdc_cred_verify' and
	MUST specify which of those approaches is used in which case (REQ21).		MUST specify which of those approaches is used in which case (REQ21).
	Specific application profiles that build on this document MUST		Application profiles of this specification MUST specify the
	specify the communication protocol that members of the group use to		communication protocol that members of the group use to communicate
	communicate with each other (REQ22) and how exactly the keying		with each other (REQ22) and the security protocol that they use to
	material is used to protect the group communication (REQ23).		protect the group communication (REQ23).
	4.3.1.1. Join the Group		4.3.1.1. Join the Group
	Figure 12 gives an overview of the join exchange between the Client		Figure 12 gives an overview of the join exchange between the Client
	and the KDC when the Client first joins a group, while Figure 13		and the KDC when the Client first joins a group, while Figure 13
	shows an example.		shows an example.
	Client KDC		Client KDC
	| |		| |
	|-------- Join Request: POST /ace-group/GROUPNAME ------>|		|-------- Join Request: POST /ace-group/GROUPNAME ------>|
	| |		| |
	|<------------ Join Response: 2.01 (Created) ----------- |		|<------------ Join Response: 2.01 (Created) ----------- |
	| Location-Path = "/ace-group/GROUPNAME/nodes/NODENAME" |		| Location-Path = "/ace-group/GROUPNAME/nodes/NODENAME" |
	Figure 12: Message Flow of the Join Request-Response		Figure 12: Message Flow of the Join Request-Response
	Request:		Request:
	Header: POST (Code=0.02)		Header: POST (Code=0.02)
	Uri-Host: "kdc.example.com"		Uri-Host: "kdc.example.com"
	Uri-Path: "ace-group"		Uri-Path: "ace-group"
	Uri-Path: "g1"		Uri-Path: "g1"
	Content-Format: "application/ace-groupcomm+cbor"		Content-Format: application/ace-groupcomm+cbor
	Payload (in CBOR diagnostic notation,		Payload (in CBOR diagnostic notation):
	with AUTH_CRED and POP_EVIDENCE being CBOR byte strings):		{
	{ "scope": << [ "group1", ["sender", "receiver"] ] >> ,		/ scope / 3: <<["group1", ["sender", "receiver"> ,
	"get_creds": [true, ["sender"], []], "client_cred": AUTH_CRED,		/ get_creds / 4: [true, ["sender"], []],
	"cnonce": h'25a8991cd700ac01', "client_cred_verify": POP_EVIDENCE }		/ client_cred / 5: h'a2026008a101a5010202410a20012158
			20bbc34960526ea4d32e940cad2a2341
			48ddc21791a12afbcbac93622046dd44
			f02258204519e257236b2a0ce2023f09
			31f1f386ca7afda64fcde0108c224c51
			eabf6072',
			/ cnonce / 6: h'25a8991cd700ac01',
			/ client_cred_verify / 24: h'66e6d9b0db009f3e105a673f88556117
			26caed57f530f8cae9d0b168513ab949
			fedc3e80a96ebe94ba08d3f8d3bf8348
			7458e2ab4c2f936ff78b50e33c885e35'
			}
	Response:		Response:
	Header: Created (Code=2.01)		Header: Created (Code=2.01)
	Content-Format: "application/ace-groupcomm+cbor"		Content-Format: application/ace-groupcomm+cbor
	Location-Path: "kdc.example.com"		Location-Path: "g1"
	Location-Path: "g1"		Location-Path: "nodes"
	Location-Path: "nodes"		Location-Path: "c101"
	Location-Path: "c101"		Payload (in CBOR diagnostic notation):
	Payload (in CBOR diagnostic notation,		{
	with KEY, AUTH_CRED_1, AUTH_CRED_2,		/ gkty / 7: 65600,
	ID_1, and ID_2 being CBOR byte strings):		/ key / 8: h'73657373696f6e6b6579',
	{ "gkty": 13, "key": KEY, "num": 12, "exp": 1924992000,		/ num / 9: 12,
	"exi": 2592000, "creds": [ AUTH_CRED_1, AUTH_CRED_2 ],		/ exp / 11: 1924992000,
	"peer_roles": ["sender", ["sender", "receiver"]],		/ exi / 12: 2592000,
	"peer_identifiers": [ ID1, ID2 ] }		/ creds / 13: [h'a2026008a101a5010202410220012158
			20cd4177ba62433375ede279b5e18e8b
			91bc3ed8f1e174474a26fc0edb44ea53
			73225820a0391de29c5c5badda610d4e
			301eaaa18422367722289cd18cbe6624
			e89b9cfd',
			h'a2026008a101a5010202410320012158
			20ac75e9ece3e50bfc8ed60399889522
			405c47bf16df96660a41298cb4307f7e
			b62258206e5de611388a4b8a8211334a
			c7d37ecb52a387d257e6db3c2a93df21
			ff3affc8'],
			/ peer_roles / 14: ["sender", ["sender", "receiver"]],
			/ peer_identifiers / 15: [h'01', h'02']
			}
	Figure 13: Example of the First Join Request-Response for Group		Figure 13: Example of the First Join Request-Response for Group
	Joining		Joining
	If not previously established, the Client and the KDC MUST first		If not previously established, the Client and the KDC MUST first
	establish a pairwise-secure communication association (REQ24). This		establish a pairwise secure communication association (REQ24). This
	can be achieved, for instance, by using a transport profile of ACE.		can be achieved, for instance, by using a transport profile of ACE.
	The join exchange MUST occur over that secure communication		The join exchange MUST occur over that secure communication
	association. The Client and the KDC MAY use that same secure		association. The Client and the KDC MAY use that same secure
	communication association to protect further pairwise communications		communication association to protect further pairwise communications
	that must be protected.		that must be protected.
	It is REQUIRED that the secure communication association between the		It is REQUIRED that the secure communication association between the
	Client and the KDC is established by using the proof-of-possession		Client and the KDC is established by using the proof-of-possession
	key bound to the access token. As a result, the proof of possession		key bound to the access token. As a result, the proof of possession
	to bind the access token to the Client is performed by using the		to bind the access token to the Client is performed by using the
	proof-of-possession key bound to the access token for establishing		proof-of-possession key bound to the access token for establishing
	secure communication between the Client and the KDC.		the pairwise secure communication association between the Client and
			the KDC.
	To join the group, the Client sends a CoAP POST request to the /ace-		To join the group, the Client sends a CoAP POST request to the /ace-
	group/GROUPNAME endpoint at the KDC, where the group to join is		group/GROUPNAME endpoint at the KDC, where the group to join is
	identified by GROUPNAME. The group name is specified in the scope		identified by GROUPNAME. The group name is specified in the scope
	entry conveyed by the 'scope' parameter of the request (if present),		entry conveyed by the 'scope' parameter of the request (if present),
	formatted as specified in Section 4.3.1. This group name is the same		formatted as specified in Section 4.3.1. This group name is the same
	as in the scope entry corresponding to that group, specified in the		as in the scope entry corresponding to that group, specified in the
	'scope' parameter of the Authorization Request/Response, or it can be		'scope' parameter of the Authorization Request/Response, or it can be
	retrieved from it. Note that, in case of successful joining, the		determined from it. Note that, in case of successful joining, the
	Client will receive the URI to retrieve individual keying material		Location-Path Options in the Join Response provide the Client with
	and to leave the group in the Location-Path option of the response.		the path of the URI to use for retrieving individual keying material
			and for leaving the group.
	If the node is joining a group for the first time and the KDC		If the node is joining a group for the first time and the KDC
	maintains the authentication credentials of the group members, the		maintains the authentication credentials of the group members, the
	Client is REQUIRED to send its own authentication credential and		Client is REQUIRED to send its own authentication credential and
	proof-of-possession (PoP) evidence in the Join Request (see the		proof-of-possession (PoP) evidence in the Join Request (see the
	'client_cred' and 'client_cred_verify' parameters in Section 4.3.1).		'client_cred' and 'client_cred_verify' parameters in Section 4.3.1).
	The request is accepted only if both the authentication credential is		The request is accepted only if both the authentication credential is
	provided and the PoP evidence is successfully verified.		provided and the PoP evidence is successfully verified.
	If a node rejoins a group as authorized by the same access token and		If a node rejoins a group as authorized by the same access token and
	using the same authentication credential, it can omit the		using the same authentication credential, it can omit the
	authentication credential and the PoP evidence, or just the PoP		authentication credential and the PoP evidence, or just the PoP
	evidence, from the Join Request. Then, the KDC will be able to		evidence, from the Join Request. Then, the KDC will be able to
	retrieve the node's authentication credential associated with the		retrieve the node's authentication credential associated with the
	access token for that group. If the authentication credential has		access token for that group. If the authentication credential has
	been discarded, the KDC replies with a 4.00 (Bad Request) error		been discarded, the KDC replies with a 4.00 (Bad Request) error
	response, as specified in Section 4.3.1. If a node rejoins a group		response, as specified in Section 4.3.1. If a node rejoins a group
	but wants to update its own authentication credential, it needs to		but wants to update its own authentication credential, it needs to
	include both its authentication credential and the PoP evidence in		include both its authentication credential and the PoP evidence in
	the Join Request like when it joined the group for the first time.		the Join Request, like when it joined the group for the first time.
	4.3.2. GET Handler		4.3.2. GET Handler
	The GET handler returns the symmetric group keying material for the		The GET handler returns the symmetric group keying material for the
	group identified by GROUPNAME.		group identified by GROUPNAME.
	The handler expects a GET request.		The handler expects a GET request.
	In addition to what is defined in Section 4.1.2, the handler verifies		In addition to what is defined in Section 4.1.2, the handler verifies
	that the Client is a current member of the group. If the		that the Client is a current member of the group. If the
	skipping to change at line 2263 ¶		skipping to change at line 2315 ¶
	Section 4.1.2. Within the Custom Problem Detail entry 'ace-		Section 4.1.2. Within the Custom Problem Detail entry 'ace-
	groupcomm-error', the value of the 'error-id' field MUST be set to 0		groupcomm-error', the value of the 'error-id' field MUST be set to 0
	("Operation permitted only to group members").		("Operation permitted only to group members").
	If all verifications succeed, the handler replies with a 2.05		If all verifications succeed, the handler replies with a 2.05
	(Content) response containing the symmetric group keying material.		(Content) response containing the symmetric group keying material.
	The payload of the response is formatted as a CBOR map that MUST		The payload of the response is formatted as a CBOR map that MUST
	contain the parameters 'gkty', 'key', and 'num', as specified in		contain the parameters 'gkty', 'key', and 'num', as specified in
	Section 4.3.1.		Section 4.3.1.
	Each of the following parameters specified in Section 4.3.1 MUST also		The payload MUST also include the parameters 'rekeying_scheme' and
	be included in the payload of the response if they are included in		'mgt_key_material' as specified in Section 4.3.1, if they are
	the payload of the Join Responses sent for the group:		included in the payload of the Join Responses sent for the group.
	'rekeying_scheme' and 'mgt_key_material'.
	The payload MAY also include the parameters 'ace_groupcomm_profile',		The payload MAY also include the parameters 'ace_groupcomm_profile',
	'exp', and 'exi', as specified in Section 4.3.1. If the 'exp'		'exp', and 'exi', as specified in Section 4.3.1. If the 'exp'
	parameter is included, the 'exi' parameter MUST also be included. If		parameter is included, the 'exi' parameter MUST also be included. If
	the parameter 'exi' is included, its value specifies the residual		the 'exi' parameter is included, its value specifies the residual
	lifetime of the group keying material from the current time at the		lifetime of the group keying material from the current time at the
	KDC.		KDC.
	4.3.2.1. Retrieve Group Keying Material		4.3.2.1. Retrieve Group Keying Material
	A node in the group can contact the KDC to retrieve the current group		A node in the group can contact the KDC to retrieve the current group
	keying material by sending a CoAP GET request to the /ace-group/		keying material by sending a CoAP GET request to the /ace-group/
	GROUPNAME endpoint at the KDC, where the group is identified by		GROUPNAME endpoint at the KDC, where the group is identified by
	GROUPNAME.		GROUPNAME.
	Figure 14 gives an overview of the key distribution exchange between		Figure 14 gives an overview of the key distribution exchange between
	the Client and the KDC when the Client first joins a group, while		the Client and the KDC, while Figure 15 shows an example.
	Figure 15 shows an example.
	Client KDC		Client KDC
	| |		| |
	|------ Key Distribution Request: GET /ace-group/GROUPNAME ------>|		|------ Key Distribution Request: GET /ace-group/GROUPNAME ------>|
	| |		| |
	|<----------- Key Distribution Response: 2.05 (Content) --------- |		|<----------- Key Distribution Response: 2.05 (Content) --------- |
	| |		| |
	Figure 14: Message Flow of Key Distribution Request-Response		Figure 14: Message Flow of Key Distribution Request-Response
	skipping to change at line 2306 ¶		skipping to change at line 2356 ¶
	Header: GET (Code=0.01)		Header: GET (Code=0.01)
	Uri-Host: "kdc.example.com"		Uri-Host: "kdc.example.com"
	Uri-Path: "ace-group"		Uri-Path: "ace-group"
	Uri-Path: "g1"		Uri-Path: "g1"
	Payload: -		Payload: -
	Response:		Response:
	Header: Content (Code=2.05)		Header: Content (Code=2.05)
	Content-Format: "application/ace-groupcomm+cbor"		Content-Format: application/ace-groupcomm+cbor
	Payload (in CBOR diagnostic notation,		Payload (in CBOR diagnostic notation):
	with KEY being a CBOR byte strings):		{
	{ "gkty": 13, "key": KEY, "num": 12 }		/ gkty / 7: 65600,
			/ key / 8: h'73657373696f6e6b6579',
			/ num / 9: 12
			}
	Figure 15: Example of Key Distribution Request-Response		Figure 15: Example of Key Distribution Request-Response
	4.4. /ace-group/GROUPNAME/creds		4.4. /ace-group/GROUPNAME/creds
	This resource implements the GET and FETCH handlers.		This resource implements the GET and FETCH handlers.
	4.4.1. FETCH Handler		4.4.1. FETCH Handler
	The FETCH handler receives identifiers of group members for the group		The FETCH handler receives identifiers of group members for the group
	identified by GROUPNAME and returns the authentication credentials of		identified by GROUPNAME and returns the authentication credentials of
	such group members.		such group members.
	The handler expects a request with the payload formatted as a CBOR		The handler expects a request with the payload formatted as a CBOR
	map, which MUST contain the following field.		map, which MUST contain the following field.
	* 'get_creds': whose value is encoded as in Section 4.3.1 with the		* 'get_creds': its value is encoded as in Section 4.3.1, with the
	following modifications.		following modifications.
	- The arrays 'role_filter' and 'id_filter' MUST NOT both be		- The arrays 'role_filter' and 'id_filter' MUST NOT both be
	empty, i.e., in CDDL notation: [ bool, [ ], [ ] ]. If the		empty, i.e., in CDDL notation: [ bool, [ ], [ ] ]. If the
	'get_creds' parameter has such a format, the request MUST be		'get_creds' parameter has such a format, the request MUST be
	considered malformed, and the KDC MUST reply with a 4.00 (Bad		considered malformed, and the KDC MUST reply with a 4.00 (Bad
	Request) error response.		Request) error response.
	Note that a group member can retrieve the authentication		Note that a group member can retrieve the authentication
	credentials of all the current group members by sending a GET		credentials of all the current group members by sending a GET
	request to the same KDC resource instead (see Section 4.4.2.1).		request to the same KDC resource instead (see Section 4.4.2.1).
	- The element 'inclusion_flag' encodes the CBOR simple value		- The element 'inclusion_flag' encodes the CBOR simple value true
	"true" (0xf5) or "false" (0xf4), as defined in Section 4.3.1.		(0xf5) or false (0xf4), as defined in Section 4.3.1.
	- The array 'role_filter' can be empty if the Client does not		- The array 'role_filter' can be empty if the Client does not
	wish to filter the requested authentication credentials based		wish to filter the requested authentication credentials based
	on the roles of the group members.		on the roles of the group members.
	- The array 'id_filter' contains zero or more node identifiers of		- The array 'id_filter' contains zero or more node identifiers of
	group members for the group identified by GROUPNAME, as defined		group members for the group identified by GROUPNAME, as defined
	in Section 4.3.1. The array may be empty if the Client does		in Section 4.3.1. The array may be empty if the Client does
	not wish to filter the requested authentication credentials		not wish to filter the requested authentication credentials
	based on the node identifiers of the group members.		based on the node identifiers of the group members.
	Note that, in case the 'role_filter' array and the 'id_filter' array		Note that, in case the 'role_filter' array and the 'id_filter' array
	are both non-empty:		are both non-empty:
	* If the 'inclusion_flag' encodes the CBOR simple value "true"		* If the 'inclusion_flag' encodes the CBOR simple value true (0xf5),
	(0xf5), the handler returns the authentication credentials of		the handler returns the authentication credentials of group
	group members whose roles match with 'role_filter' and/or have		members whose roles match with 'role_filter' and/or have their
	their node identifier specified in 'id_filter'.		node identifier specified in 'id_filter'.
	* If the 'inclusion_flag' encodes the CBOR simple value "false"		* If the 'inclusion_flag' encodes the CBOR simple value false
	(0xf4), the handler returns the authentication credentials of		(0xf4), the handler returns the authentication credentials of
	group members whose roles match with 'role_filter' and, at the		group members whose roles match with 'role_filter' and, at the
	same time, do not have their node identifier specified in		same time, do not have their node identifier specified in
	'id_filter'.		'id_filter'.
	The specific format of authentication credentials as well as the		The specific format of authentication credentials as well as the
	identifiers, roles, and combination of roles of group members MUST be		identifiers, roles, and combination of roles of group members MUST be
	specified by application profiles of this specification (REQ1, REQ6,		specified by application profiles of this specification (REQ1, REQ6,
	REQ25).		REQ25).
	The handler identifies the authentication credentials of the current		The handler identifies the authentication credentials of the current
	group members for which either of the following holds:		group members for which either of the following holds:
	* The role identifier matches with one of those indicated in the		* The role identifier matches with one of those indicated in the
	request; note that the request can specify a combination of roles,		request; note that the request can specify a combination of roles,
	in which case, the handler selects only the group members that		in which case the handler selects only the group members that have
	have all the roles included in the combination.		all the roles included in the combination.
	* The node identifier matches with one of those indicated in the		* The node identifier matches with one of those indicated in the
	request or does not match with any of those, which is consistent		request or does not match with any of those, which is consistent
	with the value of the element 'inclusion_flag'.		with the value of the element 'inclusion_flag'.
	If all verifications succeed, the handler returns a 2.05 (Content)		If all verifications succeed, the handler returns a 2.05 (Content)
	message response with the payload formatted as a CBOR map, containing		message response with the payload formatted as a CBOR map, containing
	only the following parameters from Section 4.3.1.		only the following parameters from Section 4.3.1.
	* 'num': which encodes the version number of the current group		* 'num': encoding the version number of the current group keying
	keying material.		material.
	* 'creds': which encodes the list of authentication credentials of		* 'creds': encoding the list of authentication credentials of the
	the selected group members.		selected group members.
	* 'peer_roles': which encodes the role(s) that each of the selected		* 'peer_roles': encoding the role(s) that each of the selected group
	group members has in the group.		members has in the group.
	This parameter SHOULD be present, and it MAY be omitted, according		This parameter SHOULD be present, and it MAY be omitted according
	to the same criteria defined for the Join Response (see		to the same criteria defined for the Join Response (see
	Section 4.3.1).		Section 4.3.1).
	* 'peer_identifiers': which encodes the node identifier that each of		* 'peer_identifiers': encoding the node identifier that each of the
	the selected group members has in the group.		selected group members has in the group.
	The specific format of authentication credentials as well as of node		The specific format of authentication credentials as well as of node
	identifiers of group members is specified by the application profile		identifiers of group members is specified by the application profile
	(REQ6, REQ25).		(REQ6, REQ25).
	If the KDC does not store any authentication credential associated		If the KDC does not store any authentication credential associated
	with the specified node identifiers, the handler returns a response		with the specified node identifiers, the handler returns a response
	with the payload formatted as a CBOR byte string of zero length.		with the payload formatted as a CBOR byte string of zero length
			(0x40).
	The handler MAY enforce one of the following policies in order to		The handler MAY enforce one of the following policies in order to
	handle possible node identifiers that are included in the 'id_filter'		handle possible node identifiers that are included in the 'id_filter'
	element of the 'get_creds' parameter of the request but are not		element of the 'get_creds' parameter of the request but are not
	associated with any current group member. Such a policy MUST be		associated with any current group member. Such a policy MUST be
	specified by the application profile (REQ26).		specified by application profiles of this specification (REQ26).
	* The KDC silently ignores those node identifiers.		* The KDC silently ignores those node identifiers.
	* The KDC retains authentication credentials of group members for a		* The KDC retains authentication credentials of group members for a
	given amount of time after their leaving before discarding them.		given amount of time after their leaving before discarding them.
	As long as such authentication credentials are retained, the KDC		As long as such authentication credentials are retained, the KDC
	provides them to a requesting Client.		provides them to a requesting Client.
	If the KDC adopts this policy, the application profile MUST also		If the KDC adopts this policy, the application profile MUST also
	specify the amount of time during which the KDC retains the		specify the amount of time during which the KDC retains the
	skipping to change at line 2441 ¶		skipping to change at line 2495 ¶
	members of the group but are authorized to do signature verifications		members of the group but are authorized to do signature verifications
	on the group messages may be allowed to access this resource if the		on the group messages may be allowed to access this resource if the
	application needs it.		application needs it.
	4.4.1.1. Retrieve a Subset of Authentication Credentials in the Group		4.4.1.1. Retrieve a Subset of Authentication Credentials in the Group
	In case the KDC maintains the authentication credentials of group		In case the KDC maintains the authentication credentials of group
	members, a node in the group can contact the KDC to request the		members, a node in the group can contact the KDC to request the
	authentication credentials, roles, and node identifiers of a		authentication credentials, roles, and node identifiers of a
	specified subset of group members by sending a CoAP FETCH request to		specified subset of group members by sending a CoAP FETCH request to
	the /ace-group/GROUPNAME/creds endpoint at the KDC, where the group		the /ace-group/GROUPNAME/creds endpoint at the KDC, which is
	is identified by GROUPNAME and formatted as defined in Section 4.4.1.		formatted as defined in Section 4.4.1 and with the group identified
			by GROUPNAME.
	Figure 16 gives an overview of the exchange mentioned above, while		Figure 16 gives an overview of the exchange mentioned above, while
	Figure 17 shows an example of such an exchange.		Figure 17 shows an example of such an exchange.
	Client KDC		Client KDC
	| |		| |
	| Authentication Credential Request: |		| Authentication Credential Request: |
	|-------------------------------------------------------->|		|-------------------------------------------------------->|
	| FETCH /ace-group/GROUPNAME/creds |		| FETCH /ace-group/GROUPNAME/creds |
	| |		| |
	skipping to change at line 2467 ¶		skipping to change at line 2522 ¶
	Response to Obtain the Authentication Credentials of Specific		Response to Obtain the Authentication Credentials of Specific
	Group Members		Group Members
	Request:		Request:
	Header: FETCH (Code=0.05)		Header: FETCH (Code=0.05)
	Uri-Host: "kdc.example.com"		Uri-Host: "kdc.example.com"
	Uri-Path: "ace-group"		Uri-Path: "ace-group"
	Uri-Path: "g1"		Uri-Path: "g1"
	Uri-Path: "creds"		Uri-Path: "creds"
	Content-Format: "application/ace-groupcomm+cbor"		Content-Format: application/ace-groupcomm+cbor
	Payload (in CBOR diagnostic notation):		Payload (in CBOR diagnostic notation):
	{ "get_creds": [true, [], [ ID_2, ID_3 ]] }		{
			/ get_creds / 4: [true, [], [h'02', h'03']]
			}
	Response:		Response:
	Header: Content (Code=2.05)		Header: Content (Code=2.05)
	Content-Format: "application/ace-groupcomm+cbor"		Content-Format: application/ace-groupcomm+cbor
	Payload (in CBOR diagnostic notation,		Payload (in CBOR diagnostic notation):
	with AUTH_CRED_2, AUTH_CRED_3,		{
	ID_2, and ID_3 being CBOR byte strings):		/ creds / 13: [h'a2026008a101a5010202410320012158
	{ "creds": [ AUTH_CRED_2, AUTH_CRED_3, ],		20ac75e9ece3e50bfc8ed60399889522
	"peer_roles": [ ["sender", "receiver"], "receiver" ],		405c47bf16df96660a41298cb4307f7e
	"peer_identifiers": [ ID_2, ID_3 ] }		b62258206e5de611388a4b8a8211334a
			c7d37ecb52a387d257e6db3c2a93df21
			ff3affc8',
			h'a2026008a101a5010202410920012158
			206f9702a66602d78f5e81bac1e0af01
			f8b52810c502e87ebb7c926c07426fd0
			2f225820c8d33274c71c9b3ee57d842b
			bf2238b8283cb410eca216fb72a78ea7
			a870f800'],
			/ peer_roles / 14: [ ["sender", "receiver"], "receiver" ],
			/ peer_identifiers / 15: [h'02', h'03']
			}
	Figure 17: Example of Authentication Credential Request-Response		Figure 17: Example of Authentication Credential Request-Response
	to Obtain the Authentication Credentials of Specific Group		to Obtain the Authentication Credentials of Specific Group
	Members		Members
	4.4.2. GET Handler		4.4.2. GET Handler
	The handler expects a GET request.		The handler expects a GET request.
	If all verifications succeed, the KDC replies with a 2.05 (Content)		If all verifications succeed, the KDC replies with a 2.05 (Content)
	response as in the FETCH handler in Section 4.4.1 but specifies the		response as in the FETCH handler in Section 4.4.1, but its payload
	authentication credentials of all the group members, together with		specifies the authentication credentials of all the group members,
	their roles and node identifiers, in the payload.		together with their roles and node identifiers.
	The parameter 'peer_roles' SHOULD be present in the payload of the		The 'peer_roles' parameter SHOULD be present in the payload of the
	response, and it MAY be omitted, according to the same criteria		response, and it MAY be omitted according to the same criteria
	defined for the Join Response (see Section 4.3.1).		defined for the Join Response (see Section 4.3.1).
	4.4.2.1. Retrieve All Authentication Credentials in the Group		4.4.2.1. Retrieve All Authentication Credentials in the Group
	In case the KDC maintains the authentication credentials of group		In case the KDC maintains the authentication credentials of group
	members, a group or an external signature verifier can contact the		members, a node in the group or an external signature verifier can
	KDC to request the authentication credentials, roles, and node		contact the KDC to request the authentication credentials, roles, and
	identifiers of all the current group members by sending a CoAP GET		node identifiers of all the current group members, by sending a CoAP
	request to the /ace-group/GROUPNAME/creds endpoint at the KDC, where		GET request to the /ace-group/GROUPNAME/creds endpoint at the KDC,
	the group is identified by GROUPNAME.		where the group is identified by GROUPNAME.
	Figure 18 gives an overview of the message exchange, while Figure 19		Figure 18 gives an overview of the message exchange, while Figure 19
	shows an example of such an exchange.		shows an example of such an exchange.
	Client KDC		Client KDC
	| |		| |
	| Authentication Credential Request: |		| Authentication Credential Request: |
	|-------------------------------------------------------->|		|-------------------------------------------------------->|
	| GET /ace-group/GROUPNAME/creds |		| GET /ace-group/GROUPNAME/creds |
	| |		| |
	skipping to change at line 2536 ¶		skipping to change at line 2604 ¶
	Header: GET (Code=0.01)		Header: GET (Code=0.01)
	Uri-Host: "kdc.example.com"		Uri-Host: "kdc.example.com"
	Uri-Path: "ace-group"		Uri-Path: "ace-group"
	Uri-Path: "g1"		Uri-Path: "g1"
	Uri-Path: "creds"		Uri-Path: "creds"
	Payload: -		Payload: -
	Response:		Response:
	Header: Content (Code=2.05)		Header: Content (Code=2.05)
	Content-Format: "application/ace-groupcomm+cbor"		Content-Format: application/ace-groupcomm+cbor
	Payload (in CBOR diagnostic notation,		Payload (in CBOR diagnostic notation):
	with AUTH_CRED_1, AUTH_CRED_2, AUTH_CRED_3,		{
	ID_1, ID_2, and ID_3 being CBOR byte strings):		/ num / 9: 12,
	{ "num": 5,		/ creds / 13: [h'a2026008a101a5010202410220012158
	"creds": [ AUTH_CRED_1, AUTH_CRED_2, AUTH_CRED_3 ],		20cd4177ba62433375ede279b5e18e8b
	"peer_roles": ["sender", ["sender", "receiver"], "receiver"],		91bc3ed8f1e174474a26fc0edb44ea53
	"peer_identifiers": [ ID_1, ID_2, ID_3 ] }		73225820a0391de29c5c5badda610d4e
			301eaaa18422367722289cd18cbe6624
			e89b9cfd',
			h'a2026008a101a5010202410320012158
			20ac75e9ece3e50bfc8ed60399889522
			405c47bf16df96660a41298cb4307f7e
			b62258206e5de611388a4b8a8211334a
			c7d37ecb52a387d257e6db3c2a93df21
			ff3affc8',
			h'a2026008a101a5010202410920012158
			206f9702a66602d78f5e81bac1e0af01
			f8b52810c502e87ebb7c926c07426fd0
			2f225820c8d33274c71c9b3ee57d842b
			bf2238b8283cb410eca216fb72a78ea7
			a870f800'],
			/ peer_roles / 14: ["sender", ["sender", "receiver"],
			"receiver"],
			/ peer_identifiers / 15: [h'01', h'02', h'03']
			}
	Figure 19: Example of Authentication Credential Request-Response		Figure 19: Example of Authentication Credential Request-Response
	to Obtain the Authentication Credentials of All the Group Members		to Obtain the Authentication Credentials of All the Group Members
	4.5. /ace-group/GROUPNAME/kdc-cred		4.5. /ace-group/GROUPNAME/kdc-cred
	This resource implements a GET handler.		This resource implements a GET handler.
	4.5.1. GET Handler		4.5.1. GET Handler
	The handler expects a GET request.		The handler expects a GET request.
	If all verifications succeed, the handler returns a 2.05 (Content)		If all verifications succeed, the handler returns a 2.05 (Content)
	message containing the KDC's authentication credential together with		message containing the KDC's authentication credential together with
	proof-of-possession (PoP) evidence. The response MUST have Content-		a proof-of-possession (PoP) evidence. The response MUST have
	Format "application/ace-groupcomm+cbor". The payload of the response		Content-Format "application/ace-groupcomm+cbor". The payload of the
	is a CBOR map, which includes the following fields.		response is a CBOR map, which includes the following fields.
	* 'kdc_cred: specifying the KDC's authentication credential. This		* 'kdc_cred: specifying the KDC's authentication credential. This
	parameter is encoded like the 'kdc_cred' parameter in the Join		parameter is encoded like the 'kdc_cred' parameter in the Join
	Response (see Section 4.3.1).		Response (see Section 4.3.1).
	* 'kdc_nonce': specifying a nonce generated by the KDC. This		* 'kdc_nonce': specifying a nonce generated by the KDC. This
	parameter is encoded like the 'kdc_nonce' parameter in the Join		parameter is encoded like the 'kdc_nonce' parameter in the Join
	Response (see Section 4.3.1).		Response (see Section 4.3.1).
	* 'kdc_cred_verify': specifying PoP evidence computed by the KDC		* 'kdc_cred_verify': specifying a PoP evidence computed by the KDC
	over the following PoP input: the nonce N_C (encoded as a CBOR		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) concatenated with the nonce N_KDC (encoded as a CBOR
	byte string), where:		byte string), where:
	- N_C is the nonce generated by the Client group member such		- N_C is the nonce generated by the Client group member such
	that: i) the nonce was specified in the 'cnonce' parameter of		that: i) the nonce was specified in the 'cnonce' parameter of
	the latest Join Request that the Client sent to the KDC in		the latest Join Request that the Client sent to the KDC in
	order to join the group identified by GROUPNAME and ii) the KDC		order to join the group identified by GROUPNAME; and ii) the
	stored the nonce as a 'clientchallenge' value associated with		KDC stored the nonce as a 'clientchallenge' value associated
	the Client after sending the corresponding Join Response (see		with the Client after sending the corresponding Join Response
	Section 4.3.1). This nonce is encoded as a CBOR byte string.		(see Section 4.3.1).
	- N_KDC is the nonce generated by the KDC and specified in the		- N_KDC is the nonce generated by the KDC and specified in the
	'kdc_nonce' parameter, encoded as a CBOR byte string.		'kdc_nonce' parameter.
	An example of PoP input to compute 'kdc_cred_verify' using CBOR		An example of PoP input to compute 'kdc_cred_verify' using CBOR
	encoding is given in Figure 20.		encoding is given in Figure 20.
	The PoP evidence is computed by means of the same method used for		The PoP evidence is computed by means of the same method used for
	computing the PoP evidence that was included in the Join Response		computing the PoP evidence that was included in the Join Response
	for this Client (see Section 4.3.1).		for this Client (see Section 4.3.1).
	Application profiles of this specification MUST specify the exact		Application profiles of this specification MUST specify the exact
	approaches used by the KDC to compute the PoP evidence to include		approaches used by the KDC to compute the PoP evidence to include
	in 'kdc_cred_verify' and MUST specify which of those approaches is		in the 'kdc_cred_verify' parameter and MUST specify which of those
	used in which case (REQ21).		approaches is used in which case (REQ21).
	If an application profile supports the presence of external		If an application profile supports the presence of external
	signature verifiers that send GET requests to this resource, then		signature verifiers that send GET requests to this resource, then
	the application profile MUST specify how external signature		the application profile MUST specify how external signature
	verifiers provide the KDC with a self-generated nonce to use as		verifiers provide the KDC with a self-generated nonce to use as
	N_C (REQ21).		N_C (REQ21).
	N_C and N_KDC expressed in CBOR diagnostic notation:		N_C and N_KDC expressed in CBOR diagnostic notation:
	N_C = h'25a8991cd700ac01'		N_C = h'25a8991cd700ac01'
	N_KDC = h'0b7db12aaff56da3'		N_KDC = h'0b7db12aaff56da3'
	skipping to change at line 2668 ¶		skipping to change at line 2754 ¶
	Header: GET (Code=0.01)		Header: GET (Code=0.01)
	Uri-Host: "kdc.example.com"		Uri-Host: "kdc.example.com"
	Uri-Path: "ace-group"		Uri-Path: "ace-group"
	Uri-Path: "g1"		Uri-Path: "g1"
	Uri-Path: "kdc-cred"		Uri-Path: "kdc-cred"
	Payload: -		Payload: -
	Response:		Response:
	Header: Content (Code=2.05)		Header: Content (Code=2.05)
	Content-Format: "application/ace-groupcomm+cbor"		Content-Format: application/ace-groupcomm+cbor
	Payload (in CBOR diagnostic notation, with AUTH_CRED_KDC		Payload (in CBOR diagnostic notation):
	and POP_EVIDENCE being CBOR byte strings):		{
	{		/ kdc_cred / 17: h'a2026008a101a5010202419920012158
	"kdc_nonce": h'0b7db12aaff56da3',		2065eda5a12577c2bae829437fe33870
	"kdc_cred": AUTH_CRED_KDC,		1a10aaa375e1bb5b5de108de439c0855
	"kdc_cred_verify": POP_EVIDENCE		1d2258201e52ed75701163f7f9e40ddf
	}		9f341b3dc9ba860af7e0ca7ca7e9eecd
			0084d19c',
			/ kdc_nonce / 18: h'0b7db12aaff56da3',
			/ kdc_cred_verify / 19: h'3fc54702aa56e1b2cb20284294c9106a
			63f91bac658d69351210a031d8fc7c5f
			f3e4be39445b1a3e83e1510d1aca2f2e
			8a7c081c7645042b18aba9d1fad1bd9c'
			}
	Figure 22: Example of KDC Authentication Credential Request-		Figure 22: Example of KDC Authentication Credential Request-
	Response to Obtain the Authentication Credential of the KDC		Response to Obtain the Authentication Credential of the KDC
	4.6. /ace-group/GROUPNAME/policies		4.6. /ace-group/GROUPNAME/policies
	This resource implements the GET handler.		This resource implements the GET handler.
	4.6.1. GET Handler		4.6.1. GET Handler
	skipping to change at line 2700 ¶		skipping to change at line 2793 ¶
	verification fails, the KDC MUST reply with a 4.03 (Forbidden) error		verification fails, the KDC MUST reply with a 4.03 (Forbidden) error
	response. The response MUST have Content-Format "application/		response. The response MUST have Content-Format "application/
	concise-problem-details+cbor" and is formatted as defined in		concise-problem-details+cbor" and is formatted as defined in
	Section 4.1.2. Within the Custom Problem Detail entry 'ace-		Section 4.1.2. Within the Custom Problem Detail entry 'ace-
	groupcomm-error', the value of the 'error-id' field MUST be set to 0		groupcomm-error', the value of the 'error-id' field MUST be set to 0
	("Operation permitted only to group members").		("Operation permitted only to group members").
	If all verifications succeed, the handler replies with a 2.05		If all verifications succeed, the handler replies with a 2.05
	(Content) response containing the list of policies for the group		(Content) response containing the list of policies for the group
	identified by GROUPNAME. The payload of the response is formatted as		identified by GROUPNAME. The payload of the response is formatted as
	a CBOR map including only the parameter 'group_policies' defined in		a CBOR map including only the 'group_policies' parameter defined in
	Section 4.3.1 and specifying the current policies in the group. If		Section 4.3.1 and specifying the current policies in the group. If
	the KDC does not store any policy, the payload is formatted as a		the KDC does not store any policy, the payload is formatted as a CBOR
	zero-length CBOR byte string.		byte string of zero length (0x40).
	The specific format and meaning of group policies MUST be specified		The specific format and meaning of group policies MUST be specified
	in the application profile (REQ20).		in application profiles of this specification (REQ20).
	4.6.1.1. Retrieve the Group Policies		4.6.1.1. Retrieve the Group Policies
	A node in the group can contact the KDC to retrieve the current group		A node in the group can contact the KDC to retrieve the current group
	policies by sending a CoAP GET request to the /ace-group/GROUPNAME/		policies by sending a CoAP GET request to the /ace-group/GROUPNAME/
	policies endpoint at the KDC, where GROUPNAME identifies the group,		policies endpoint at the KDC, which is formatted as defined in
	and is formatted as defined in Section 4.6.1		Section 4.6.1 and with the group identified by GROUPNAME.
	Figure 23 gives an overview of the exchange described above, while		Figure 23 gives an overview of the exchange described above, while
	Figure 24 shows an example.		Figure 24 shows an example.
	Client KDC		Client KDC
	| |		| |
	|-- Policies Request: GET /ace-group/GROUPNAME/policies -->|		|-- Policies Request: GET /ace-group/GROUPNAME/policies -->|
	| |		| |
	|<----------- Policies Response: 2.05 (Content) -----------|		|<----------- Policies Response: 2.05 (Content) -----------|
	| |		| |
	skipping to change at line 2739 ¶		skipping to change at line 2832 ¶
	Header: GET (Code=0.01)		Header: GET (Code=0.01)
	Uri-Host: "kdc.example.com"		Uri-Host: "kdc.example.com"
	Uri-Path: "ace-group"		Uri-Path: "ace-group"
	Uri-Path: "g1"		Uri-Path: "g1"
	Uri-Path: "policies"		Uri-Path: "policies"
	Payload: -		Payload: -
	Response:		Response:
	Header: Content (Code=2.05)		Header: Content (Code=2.05)
	Content-Format: "application/ace-groupcomm+cbor"		Content-Format: application/ace-groupcomm+cbor
	Payload(in CBOR diagnostic notation):		Payload(in CBOR diagnostic notation):
	{ "group_policies": {"exp-delta": 120} }		{
			/ group_policies / 16: {
			/ Expiration Delta / 2: 120
			}
			}
	Figure 24: Example of Policies Request-Response		Figure 24: Example of Policies Request-Response
	4.7. /ace-group/GROUPNAME/num		4.7. /ace-group/GROUPNAME/num
	This resource implements the GET handler.		This resource implements the GET handler.
	4.7.1. GET Handler		4.7.1. GET Handler
	The handler expects a GET request.		The handler expects a GET request.
	skipping to change at line 2776 ¶		skipping to change at line 2873 ¶
	material before the new keying material is distributed. This number		material before the new keying material is distributed. This number
	is stored in persistent storage.		is stored in persistent storage.
	The payload of the response is formatted as a CBOR integer.		The payload of the response is formatted as a CBOR integer.
	4.7.1.1. Retrieve the Keying Material Version		4.7.1.1. Retrieve the Keying Material Version
	A node in the group can contact the KDC to request information about		A node in the group can contact the KDC to request information about
	the version number of the symmetric group keying material by sending		the version number of the symmetric group keying material by sending
	a CoAP GET request to the /ace-group/GROUPNAME/num endpoint at the		a CoAP GET request to the /ace-group/GROUPNAME/num endpoint at the
	KDC, where GROUPNAME identifies the group, and is formatted as		KDC, which is formatted as defined in Section 4.7.1 and with the
	defined in Section 4.7.1. In particular, the version is incremented		group identified by GROUPNAME. In particular, the version is
	by the KDC every time the group keying material is renewed before it		incremented by the KDC every time the group keying material is
	is distributed to the group members.		renewed before it is distributed to the group members.
	Figure 25 gives an overview of the exchange described above, while		Figure 25 gives an overview of the exchange described above, while
	Figure 26 shows an example.		Figure 26 shows an example.
	Client KDC		Client KDC
	| |		| |
	|---- Version Request: GET /ace-group/GROUPNAME/num ---->|		|---- Version Request: GET /ace-group/GROUPNAME/num ---->|
	| |		| |
	|<---------- Version Response: 2.05 (Content) -----------|		|<---------- Version Response: 2.05 (Content) -----------|
	| |		| |
	skipping to change at line 2805 ¶		skipping to change at line 2902 ¶
	Header: GET (Code=0.01)		Header: GET (Code=0.01)
	Uri-Host: "kdc.example.com"		Uri-Host: "kdc.example.com"
	Uri-Path: "ace-group"		Uri-Path: "ace-group"
	Uri-Path: "g1"		Uri-Path: "g1"
	Uri-Path: "num"		Uri-Path: "num"
	Payload: -		Payload: -
	Response:		Response:
	Header: Content (Code=2.05)		Header: Content (Code=2.05)
	Payload(in CBOR diagnostic notation):		Payload (in CBOR diagnostic notation):
	13		13
	Figure 26: Example of Version Request-Response		Figure 26: Example of Version Request-Response
	4.8. /ace-group/GROUPNAME/nodes/NODENAME		4.8. /ace-group/GROUPNAME/nodes/NODENAME
	This resource implements the GET, PUT, and DELETE handlers.		This resource implements the GET, PUT, and DELETE handlers.
	In addition to what is defined in Section 4.1.2, each of the handlers		In addition to what is defined in Section 4.1.2, each of the handlers
	performs the following two verifications.		performs the following two verifications.
	skipping to change at line 2850 ¶		skipping to change at line 2947 ¶
	In particular, the format for the group keying material is the same		In particular, the format for the group keying material is the same
	as defined in the response of Section 4.3.2. If the 'exp' parameter		as defined in the response of Section 4.3.2. If the 'exp' parameter
	is included, the 'exi' parameter MUST also be included. If the		is included, the 'exi' parameter MUST also be included. If the
	parameter 'exi' is included, its value specifies the residual		parameter 'exi' is included, its value specifies the residual
	lifetime of the group keying material from the current time at the		lifetime of the group keying material from the current time at the
	KDC.		KDC.
	The CBOR map can include additional parameters that specify the		The CBOR map can include additional parameters that specify the
	individual keying material for the Client. The specific format of		individual keying material for the Client. The specific format of
	individual keying material for group members or of the information to		individual keying material for group members or of the information to
	derive such keying material, as well as the corresponding CBOR label,		derive such keying material MUST be defined in application profiles
	MUST be specified in the application profile (REQ27) and registered		of this specification (REQ27), together with the corresponding CBOR
	in Section 11.7.		map key that has to be registered in the "ACE Groupcomm Parameters"
			registry defined in Section 11.7.
	Optionally, the KDC can make the sub-resource at /ace-		Optionally, the KDC can make the sub-resource at /ace-
	group/GROUPNAME/nodes/NODENAME also observable [RFC7641] for the		group/GROUPNAME/nodes/NODENAME also observable [RFC7641] for the
	associated node. In case the KDC removes that node from the group		associated node. In case the KDC removes that node from the group
	without having been explicitly asked for it, this allows the KDC to		without having been explicitly asked for it, this allows the KDC to
	send an unsolicited 4.04 (Not Found) response to the node as a		send an unsolicited 4.04 (Not Found) response to the node as a
	notification of eviction from the group (see Section 5).		notification of eviction from the group (see Section 5).
	Note that the node could have also been observing the resource at		Note that the node could have also been observing the resource at
	/ace-group/GROUPNAME in order to be informed of changes in the keying		/ace-group/GROUPNAME in order to be informed of changes in the group
	material. In such a case, this method would result in largely		keying material. In such a case, this method would result in largely
	overlapping notifications received for the resource at /ace-group/		overlapping notifications received for the resource at /ace-group/
	GROUPNAME and the sub-resource at /ace-group/GROUPNAME/nodes/		GROUPNAME and the sub-resource at /ace-group/GROUPNAME/nodes/
	NODENAME.		NODENAME.
	In order to mitigate this, a node that supports the No-Response		In order to mitigate this, a node that supports the CoAP No-Response
	option [RFC7967] can use it when starting the observation of the sub-		Option [RFC7967] can use it when starting the observation of the sub-
	resource at /ace-group/GROUPNAME/nodes/NODENAME. In particular, the		resource at /ace-group/GROUPNAME/nodes/NODENAME. In particular, the
	GET observation request can also include the No-Response option, with		GET observation request can also include the No-Response option, with
	value set to 2 (Not interested in 2.xx responses).		value set to 2 (Not interested in 2.xx responses).
	4.8.1.1. Retrieve Group and Individual Keying Material		4.8.1.1. Retrieve Group and Individual Keying Material
	When any of the following happens, a node MUST stop using the stored		When any of the following happens, a node MUST stop using the stored
	group keying material to protect outgoing messages and SHOULD stop		group keying material to protect outgoing messages and SHOULD stop
	using it to decrypt and verify incoming messages.		using it to decrypt and verify incoming messages.
	* Upon expiration of the keying material, according to what is		* Upon expiration of the keying material, according to what is
	indicated by the KDC with the 'exp' and/or 'exi' parameter (e.g.,		indicated by the KDC through the 'exp' and/or 'exi' parameter
	in a Join Response) or to a pre-configured value.		(e.g., in a Join Response) or to a pre-configured value.
	* Upon receiving a notification of revoked/renewed keying material		* Upon receiving a notification of revoked/renewed keying material
	from the KDC, possibly as part of an update of the keying material		from the KDC, possibly as part of an update of the keying material
	(rekeying) triggered by the KDC.		(rekeying) triggered by the KDC.
	* Upon receiving messages from other group members without being		* Upon receiving messages from other group members without being
	able to retrieve the keying material to correctly decrypt them.		able to retrieve the keying material to correctly decrypt them.
	This may be due to rekeying messages previously sent by the KDC		This may be due to rekeying messages previously sent by the KDC
	that the Client was not able to receive or decrypt.		that the Client was not able to receive or decrypt.
	skipping to change at line 2907 ¶		skipping to change at line 3005 ¶
	formatted as specified in Section 4.8.1. The Client can request the		formatted as specified in Section 4.8.1. The Client can request the
	latest keying material from the KDC before the currently stored, old		latest keying material from the KDC before the currently stored, old
	keying material reaches its expiration time.		keying material reaches its expiration time.
	Note that policies can be set up so that the Client sends a Key		Note that policies can be set up so that the Client sends a Key
	Distribution Request to the KDC only after a given number of received		Distribution Request to the KDC only after a given number of received
	messages could not be decrypted (because of failed decryption		messages could not be decrypted (because of failed decryption
	processing or the inability to retrieve the necessary keying		processing or the inability to retrieve the necessary keying
	material).		material).
	It is application dependent and pertains to the particular message		It is application dependent and pertaining to the used secure message
	exchange (e.g., [GROUP-OSCORE]) to set up these policies for		exchange (e.g., [GROUP-OSCORE]) to set up these policies for
	instructing Clients to retain incoming messages and for how long		instructing Clients to retain incoming messages and for how long
	(OPT11). This allows Clients to possibly decrypt such messages after		(OPT11). This allows Clients to possibly decrypt such messages after
	getting updated keying material, rather than just consider them		getting updated keying material, rather than just consider them
	invalid messages to discard right away.		invalid messages to discard right away.
	After having failed to decrypt messages from another group member and		After having failed to decrypt messages from another group member and
	having sent a Key Distribution Request to the KDC, the Client might		having sent a Key Distribution Request to the KDC, the Client might
	end up retrieving the same, latest group keying material that it		end up retrieving the same, latest group keying material that it
	already stores. In such a case, multiple failed decryptions might be		already stores. In such a case, multiple failed decryptions might be
	due to the message sender and/or the KDC that have changed their		due to the message sender and/or the KDC that have changed their
	authentication credential. Hence, the Client can retrieve such		authentication credential. Hence, the Client can retrieve such
	latest authentication credentials by sending to the KDC an		latest authentication credentials by sending to the KDC an
	Authentication Credential Request (see Sections 4.4.1.1 and 4.4.2.1)		Authentication Credential Request (see Sections 4.4.1.1 and 4.4.2.1)
	and a KDC Authentication Credential Request (see Section 4.5.1.1),		and a KDC Authentication Credential Request (see Section 4.5.1.1),
	respectively.		respectively.
	The Client can also send to the KDC a Key Distribution Request		The Client can also send to the KDC a Key Distribution Request
	without having been triggered by a failed decryption of a message		without having been triggered by a failed decryption of a message
	from another group member if the Client wants to be sure that it		from another group member, if the Client wants to be sure that it
	currently stores the latest group keying material. If that is the		currently stores the latest group keying material. If that is the
	case, the Client will receive from the KDC the same group keying		case, the Client will receive from the KDC the same group keying
	material it already stores.		material it already stores.
	Figure 27 gives an overview of the exchange described above, while		Figure 27 gives an overview of the exchange described above, while
	Figure 28 shows an example.		Figure 28 shows an example.
	Client KDC		Client KDC
	| |		| |
	|------------------ Key Distribution Request: --------------->|		|------------------ Key Distribution Request: --------------->|
	skipping to change at line 2958 ¶		skipping to change at line 3056 ¶
	Uri-Host: "kdc.example.com"		Uri-Host: "kdc.example.com"
	Uri-Path: "ace-group"		Uri-Path: "ace-group"
	Uri-Path: "g1"		Uri-Path: "g1"
	Uri-Path: "nodes"		Uri-Path: "nodes"
	Uri-Path: "c101"		Uri-Path: "c101"
	Payload: -		Payload: -
	Response:		Response:
	Header: Content (Code=2.05)		Header: Content (Code=2.05)
	Content-Format: "application/ace-groupcomm+cbor"		Content-Format: application/ace-groupcomm+cbor
	Payload (in CBOR diagnostic notation,		Payload (in CBOR diagnostic notation, with "ind-key" being the
	with KEY and IND_KEY being CBOR byte strings,		profile-specified label for individual keying material):
	and "ind-key" being the profile-specified label		{
	for individual keying material):		/ gkty / 7: 65600,
	{ "gkty": 13, "key": KEY, "num": 12, "ind-key": IND_KEY }		/ key / 8: h'73657373696f6e6b6579',
			/ num / 9: 12,
			"ind-key": h'fcae9023'
			}
	Figure 28: Example of Key Distribution Request-Response		Figure 28: Example of Key Distribution Request-Response
	4.8.2. PUT Handler		4.8.2. PUT Handler
	The PUT handler processes requests from a Client that asks for new		The PUT handler processes requests from a Client that asks for new
	individual keying material, as required to process messages exchanged		individual keying material, as required to process messages exchanged
	in the group.		in the group.
	The handler expects a PUT request with an empty payload.		The handler expects a PUT request with an empty payload.
	skipping to change at line 2994 ¶		skipping to change at line 3095 ¶
	If the KDC is currently not able to serve this request, i.e., to		If the KDC is currently not able to serve this request, i.e., to
	generate new individual keying material for the requesting Client,		generate new individual keying material for the requesting Client,
	the KDC MUST reply with a 5.03 (Service unavailable) error response.		the KDC MUST reply with a 5.03 (Service unavailable) error response.
	The response MUST have Content-Format "application/concise-problem-		The response MUST have Content-Format "application/concise-problem-
	details+cbor" and is formatted as defined in Section 4.1.2. Within		details+cbor" and is formatted as defined in Section 4.1.2. Within
	the Custom Problem Detail entry 'ace-groupcomm-error', the value of		the Custom Problem Detail entry 'ace-groupcomm-error', the value of
	the 'error-id' field MUST be set to 4 ("No available node		the 'error-id' field MUST be set to 4 ("No available node
	identifiers").		identifiers").
	If all verifications succeed, the handler replies with a 2.05		If all verifications succeed, the handler replies with a 2.04
	(Content) response containing newly generated individual keying		(Changed) response containing newly generated individual keying
	material for the Client. The payload of the response is formatted as		material for the Client. The payload of the response is formatted as
	a CBOR map. The specific format of newly generated individual keying		a CBOR map. The specific format of newly generated individual keying
	material for group members or of the information to derive such		material for group members or of the information to derive such
	keying material, as well as the corresponding CBOR label, MUST be		keying material MUST be defined in application profiles of this
	specified in the application profile (REQ27) and registered in		specification (REQ27), together with the corresponding CBOR map key
	Section 11.7.		that has to be registered in the "ACE Groupcomm Parameters" registry
			defined in Section 11.7.
	The typical successful outcome consists in replying with newly		The typical successful outcome consists in replying with newly
	generated individual keying material for the Client, as defined		generated individual keying material for the Client, as defined
	above. However, application profiles of this specification MAY also		above. However, application profiles of this specification MAY also
	extend this handler in order to achieve different akin outcomes		extend this handler in order to achieve different akin outcomes
	(OPT12), for instance:		(OPT12), for instance:
	* Not providing the Client with newly generated individual keying		* Not providing the Client with newly generated individual keying
	material, but rather rekeying the whole group, i.e., providing all		material, but rather rekeying the whole group, i.e., providing all
	the current group members with newly generated group keying		the current group members with newly generated group keying
	material.		material.
	* Both providing the Client with newly generated individual keying		* Both providing the Client with newly generated individual keying
	material, as well as rekeying the whole group, i.e., providing all		material, as well as rekeying the whole group, i.e., providing all
	the current group members with newly generated group keying		the current group members with newly generated group keying
	material.		material.
	In either case, the handler may specify the new group keying material		In either case, the handler may specify the new group keying material
	as part of the 2.05 (Content) response.		as part of the 2.04 (Changed) response.
	Note that this handler is not intended to accommodate requests from a		Note that this handler is not intended to accommodate requests from a
	group member to trigger a group rekeying, whose scheduling and		group member to trigger a group rekeying, whose scheduling and
	execution is an exclusive prerogative of the KDC (also see related		execution is an exclusive prerogative of the KDC (also see related
	security considerations in Section 10.2).		security considerations in Section 10.2).
	4.8.2.1. Request to Change Individual Keying Material		4.8.2.1. Request to Change Individual Keying Material
	A Client may ask the KDC for new individual keying material. For		A Client may ask the KDC for new individual keying material. For
	instance, this can be due to the expiration of such individual keying		instance, this can be due to the expiration of such individual keying
	material or to the exhaustion of Authenticated Encryption with		material or to the exhaustion of Authenticated Encryption with
	Associated Data (AEAD) nonces if an AEAD encryption algorithm is used		Associated Data (AEAD) nonces if an AEAD encryption algorithm is used
	for protecting communications in the group. An example of individual		for protecting communications in the group. An example of individual
	keying material can simply be an individual encryption key associated		keying material can simply be an individual encryption key associated
	with the Client. Hence, the Client may ask for a new individual		with the Client. Hence, the Client may ask for a new individual
	encryption key or for new input material to derive it.		encryption key or for new input material to derive it.
	To this end, the Client performs a Key Renewal Request-Response		To this end, the Client performs a Key Renewal Request-Response
	exchange with the KDC, i.e., it sends a CoAP PUT request to the /ace-		exchange with the KDC, i.e., it sends a CoAP PUT request to the /ace-
	group/GROUPNAME/nodes/NODENAME endpoint at the KDC, where GROUPNAME		group/GROUPNAME/nodes/NODENAME endpoint at the KDC, which is
	identifies the group and NODENAME is its node name, and is formatted		formatted as defined in Section 4.8.1 and with the group identified
	as defined in Section 4.8.1.		by GROUPNAME.
	Figure 29 gives an overview of the exchange described above, while		Figure 29 gives an overview of the exchange described above, while
	Figure 30 shows an example.		Figure 30 shows an example.
	Client KDC		Client KDC
	| |		| |
	|---------------- Key Renewal Request: ---------------->|		|---------------- Key Renewal Request: ---------------->|
	| PUT /ace-group/GROUPNAME/nodes/NODENAME |		| PUT /ace-group/GROUPNAME/nodes/NODENAME |
	| |		| |
	|<-------- Key Renewal Response: 2.05 (Content) --------|		|<-------- Key Renewal Response: 2.04 (Changed) --------|
	| |		| |
	Figure 29: Message Flow of Key Renewal Request-Response		Figure 29: Message Flow of Key Renewal Request-Response
	Request:		Request:
	Header: PUT (Code=0.03)		Header: PUT (Code=0.03)
	Uri-Host: "kdc.example.com"		Uri-Host: "kdc.example.com"
	Uri-Path: "ace-group"		Uri-Path: "ace-group"
	Uri-Path: "g1"		Uri-Path: "g1"
	Uri-Path: "nodes"		Uri-Path: "nodes"
	Uri-Path: "c101"		Uri-Path: "c101"
	Payload: -		Payload: -
	Response:		Response:
	Header: Content (Code=2.05)		Header: Changed (Code=2.04)
	Content-Format: "application/ace-groupcomm+cbor"		Content-Format: application/ace-groupcomm+cbor
	Payload (in CBOR diagnostic notation, with IND_KEY being a		Payload (in CBOR diagnostic notation, with "ind-key" being the
	CBOR byte string, and "ind-key" being the profile-specified		profile-specified label for individual keying material):
	label for individual keying material):		{
	{ "ind-key": IND_KEY }		"ind-key": h'b71acc28'
			}
	Figure 30: Example of Key Renewal Request-Response		Figure 30: Example of Key Renewal Request-Response
	Note that there is a difference between the Key Renewal Request in		Note that there is a difference between the Key Renewal Request in
	this section and the Key Distribution Request in Section 4.8.1.1.		this section and the Key Distribution Request in Section 4.8.1.1.
	The former asks the KDC for new individual keying material, while the		The former asks the KDC for new individual keying material, while the
	latter asks the KDC for the current group keying material together		latter asks the KDC for the current group keying material together
	with the current individual keying material.		with the current individual keying material.
	As discussed in Section 4.8.2, application profiles of this		As discussed in Section 4.8.2, application profiles of this
	skipping to change at line 3115 ¶		skipping to change at line 3218 ¶
	If all verification succeeds, the handler performs the actions		If all verification succeeds, the handler performs the actions
	defined in Section 5 and replies with a 2.02 (Deleted) response with		defined in Section 5 and replies with a 2.02 (Deleted) response with
	an empty payload.		an empty payload.
	4.8.3.1. Leave the Group		4.8.3.1. Leave the Group
	A Client can actively request to leave the group. In this case, the		A Client can actively request to leave the group. In this case, the
	Client sends a CoAP DELETE request to the endpoint /ace-		Client sends a CoAP DELETE request to the endpoint /ace-
	group/GROUPNAME/nodes/NODENAME at the KDC, where GROUPNAME identifies		group/GROUPNAME/nodes/NODENAME at the KDC, where GROUPNAME identifies
	the group and NODENAME is its node name, formatted as defined in		the group and NODENAME is the Client's node name.
	Section 4.8.3
	Note that, after having left the group, the Client may wish to join		Note that, after having left the group, the Client may wish to join
	it again. Then, as long as the Client is still authorized to join		it again. Then, as long as the Client is still authorized to join
	the group, i.e., the associated access token is still valid, the		the group, i.e., the associated access token is still valid, the
	Client can request to rejoin the group directly to the KDC (see		Client can request to rejoin the group directly to the KDC (see
	Section 4.3.1.1) without having to retrieve a new access token from		Section 4.3.1.1) without having to retrieve a new access token from
	the AS.		the AS.
	4.9. /ace-group/GROUPNAME/nodes/NODENAME/cred		4.9. /ace-group/GROUPNAME/nodes/NODENAME/cred
	This resource implements the POST handler.		This resource implements the POST handler.
	4.9.1. POST Handler		4.9.1. POST Handler
	The POST handler is used to replace the stored authentication		The POST handler is used to replace the stored authentication
	credential of this Client (identified by NODENAME) with the one		credential of this Client (identified by NODENAME) with the one
	specified in the request at the KDC for the group identified by		specified in the request at the KDC for the group identified by
	GROUPNAME.		GROUPNAME.
	The handler expects a POST request with the payload, as specified in		The handler expects a POST request with the payload as specified in
	Section 4.3.1, with the difference that it includes only the		Section 4.3.1, with the difference that the payload includes only the
	parameters 'client_cred', 'cnonce', and 'client_cred_verify'.		parameters 'client_cred', 'cnonce', and 'client_cred_verify'.
	The PoP evidence included in the 'client_cred_verify' parameter is		The PoP evidence included in the 'client_cred_verify' parameter is
	computed in the same way considered in Section 4.3.1 and defined by		computed in the same way considered in Section 4.3.1 and defined by
	the specific application profile (REQ14) by using the following to		the specific application profile (REQ14) by using the following to
	build the PoP input: i) the same scope entry specified by the Client		build the PoP input: i) the same scope entry specified by the Client
	in the 'scope' parameter of the latest Join Request that the Client		in the 'scope' parameter of the latest Join Request that the Client
	sent to the KDC in order to join the group identified by GROUPNAME;		sent to the KDC in order to join the group identified by GROUPNAME;
	ii) the latest N_S value stored by the Client; and iii) a new N_C		ii) the latest N_S value stored by the Client; and iii) a new N_C
	nonce generated by the Client and specified in the parameter 'cnonce'		nonce generated by the Client and specified in the parameter 'cnonce'
	skipping to change at line 3171 ¶		skipping to change at line 3273 ¶
	error response. The response MUST have Content-Format "application/		error response. The response MUST have Content-Format "application/
	concise-problem-details+cbor" and is formatted as defined in		concise-problem-details+cbor" and is formatted as defined in
	Section 4.1.2. Within the Custom Problem Detail entry 'ace-		Section 4.1.2. Within the Custom Problem Detail entry 'ace-
	groupcomm-error', the value of the 'error-id' field MUST be set to 1		groupcomm-error', the value of the 'error-id' field MUST be set to 1
	("Request inconsistent with the current roles").		("Request inconsistent with the current roles").
	If the KDC cannot retrieve the 'kdcchallenge' associated with this		If the KDC cannot retrieve the 'kdcchallenge' associated with this
	Client (see Section 3.3), the KDC MUST reply with a 4.00 (Bad		Client (see Section 3.3), the KDC MUST reply with a 4.00 (Bad
	Request) error response, which MUST also have Content-Format		Request) error response, which MUST also have Content-Format
	"application/ace-groupcomm+cbor". The payload of the error response		"application/ace-groupcomm+cbor". The payload of the error response
	is a CBOR map including a newly generated 'kdcchallenge' value. This		is a CBOR map including the 'kdcchallenge' parameter, which specifies
	is specified in the 'kdcchallenge' parameter. In such a case, the		a newly generated 'kdcchallenge' value. In such a case, the KDC MUST
	KDC MUST store the newly generated value as the 'kdcchallenge' value		store the newly generated value as the 'kdcchallenge' value
	associated with this Client, replacing the currently stored value (if		associated with this Client, replacing the currently stored value (if
	any).		any).
	Otherwise, the handler checks that the authentication credential		Otherwise, the handler checks that the authentication credential
	specified in the 'client_cred' field is valid for the group		specified in the 'client_cred' field is valid for the group
	identified by GROUPNAME. That is, the handler checks that the		identified by GROUPNAME. That is, the handler checks that the
	authentication credential is encoded according to the format used in		authentication credential is encoded according to the format used in
	the group, is intended for the public key algorithm used in the		the group, is intended for the public key algorithm used in the
	group, and is aligned with the possible associated parameters used in		group, and is aligned with the possible associated parameters used in
	the group. If that cannot be successfully verified, the handler MUST		the group. If that cannot be successfully verified, the handler MUST
	reply with a 4.00 (Bad Request) error response. The response MUST		reply with a 4.00 (Bad Request) error response. The response MUST
	have Content-Format "application/concise-problem-details+cbor" and is		have Content-Format "application/concise-problem-details+cbor" and is
	formatted as defined in Section 4.1.2. Within the Custom Problem		formatted as defined in Section 4.1.2. Within the Custom Problem
	Detail entry 'ace-groupcomm-error', the value of the 'error-id' field		Detail entry 'ace-groupcomm-error', the value of the 'error-id' field
	MUST be set to 2 ("Authentication credential incompatible with the		MUST be set to 2 ("Authentication credential incompatible with the
	group configuration").		group configuration").
	Otherwise, the handler verifies the PoP evidence contained in the		Otherwise, the handler verifies the PoP evidence conveyed in the
	'client_cred_verify' field of the request by using the authentication		'client_cred_verify' parameter of the request, by using the
	credential specified in the 'client_cred' field, as well as the same		authentication credential specified in the 'client_cred' parameter as
	way considered in Section 4.3.1 and defined by the specific		well as the same way considered in Section 4.3.1 and defined by the
	application profile (REQ14). If the PoP evidence does not pass		specific application profile (REQ14). If the PoP evidence does not
	verification, the handler MUST reply with a 4.00 (Bad Request) error		pass verification, the handler MUST reply with a 4.00 (Bad Request)
	response. The response MUST have Content-Format "application/		error response. The response MUST have Content-Format "application/
	concise-problem-details+cbor" and is formatted as defined in		concise-problem-details+cbor" and is formatted as defined in
	Section 4.1.2. Within the Custom Problem Detail entry 'ace-		Section 4.1.2. Within the Custom Problem Detail entry 'ace-
	groupcomm-error', the value of the 'error-id' field MUST be set to 3		groupcomm-error', the value of the 'error-id' field MUST be set to 3
	("Invalid Proof-of-Possession evidence").		("Invalid proof-of-possession evidence").
	If all verifications succeed, the handler performs the following		If all verifications succeed, the handler performs the following
	actions.		actions.
	* The handler associates the authentication credential from the		* The handler associates the authentication credential from the
	'client_cred' field of the request with the node identifier		'client_cred' parameter of the request with the node identifier
	NODENAME, as well as with the access token associated with the		NODENAME, as well as with the access token associated with the
	node identified by NODENAME.		node identified by NODENAME.
	* In the stored list of group members' authentication credentials		* In the stored list of group members' authentication credentials
	for the group identified by GROUPNAME, the handler replaces the		for the group identified by GROUPNAME, the handler replaces the
	authentication credential of the node identified by NODENAME with		authentication credential of the node identified by NODENAME with
	the authentication credential specified in the 'client_cred' field		the authentication credential specified in the 'client_cred'
	of the request.		parameter of the request.
	Then, the handler replies with a 2.04 (Changed) response, which does		Then, the handler replies with a 2.04 (Changed) response, which does
	not include a payload.		not include a payload.
	scope, N_S, and N_C expressed in CBOR diagnostic notation:		scope, N_S, and N_C expressed in CBOR diagnostic notation:
	scope = h'826667726f7570316673656e646572'		scope = h'826667726f7570316673656e646572'
	N_S = h'018a278f7faab55a'		N_S = h'018a278f7faab55a'
	N_C = h'0446baefc56111bf'		N_C = h'0446baefc56111bf'
	scope, N_S, and N_C as CBOR encoded byte strings:		scope, N_S, and N_C as CBOR encoded byte strings:
	skipping to change at line 3247 ¶		skipping to change at line 3349 ¶
	4.9.1.1. Uploading an Authentication Credential		4.9.1.1. Uploading an Authentication Credential
	In case the KDC maintains the authentication credentials of group		In case the KDC maintains the authentication credentials of group
	members, a node in the group can contact the KDC to upload a new		members, a node in the group can contact the KDC to upload a new
	authentication credential to use in the group and to replace the		authentication credential to use in the group and to replace the
	currently stored one.		currently stored one.
	To this end, the Client performs an Authentication Credential Update		To this end, the Client performs an Authentication Credential Update
	Request-Response exchange with the KDC, i.e., it sends a CoAP POST		Request-Response exchange with the KDC, i.e., it sends a CoAP POST
	request to the /ace-group/GROUPNAME/nodes/NODENAME/cred endpoint at		request to the /ace-group/GROUPNAME/nodes/NODENAME/cred endpoint at
	the KDC, where GROUPNAME identifies the group and NODENAME is its		the KDC, where GROUPNAME identifies the group and NODENAME is the
	node name.		Client's node name.
	The request is formatted as specified in Section 4.9.1.		The request is formatted as specified in Section 4.9.1.
	Figure 32 gives an overview of the exchange described above, while		Figure 32 gives an overview of the exchange described above, while
	Figure 33 shows an example.		Figure 33 shows an example.
	Client KDC		Client KDC
	| |		| |
	|----------- Authentication Credential Update Request: --------->|		|----------- Authentication Credential Update Request: --------->|
	| POST /ace-group/GROUPNAME/nodes/NODENAME/cred |		| POST /ace-group/GROUPNAME/nodes/NODENAME/cred |
	skipping to change at line 3275 ¶		skipping to change at line 3377 ¶
	Request:		Request:
	Header: POST (Code=0.02)		Header: POST (Code=0.02)
	Uri-Host: "kdc.example.com"		Uri-Host: "kdc.example.com"
	Uri-Path: "ace-group"		Uri-Path: "ace-group"
	Uri-Path: "g1"		Uri-Path: "g1"
	Uri-Path: "nodes"		Uri-Path: "nodes"
	Uri-Path: "c101"		Uri-Path: "c101"
	Uri-Path: "cred"		Uri-Path: "cred"
	Content-Format: "application/ace-groupcomm+cbor"		Content-Format: application/ace-groupcomm+cbor
	Payload (in CBOR diagnostic notation, with AUTH_CRED		Payload (in CBOR diagnostic notation):
	and POP_EVIDENCE being CBOR byte strings):		{
	{ "client_cred": AUTH_CRED, "cnonce": h'0446baefc56111bf',		/ client_cred / 5: h'a2026008a101a501020241fc20012158
	"client_cred_verify": POP_EVIDENCE }		20bac5b11cad8f99f9c72b05cf4b9e26
			d244dc189f745228255a219a86d6a09e
			ff22582020138bf82dc1b6d562be0fa5
			4ab7804a3a64b6d72ccfed6b6fb6ed28
			bbfc117e',
			/ cnonce / 6: h'0446baefc56111bf',
			/ client_cred_verify / 24: h'e2aeafd40d69d19dfe6e52077c5d7ff4
			e408282cbefb5d06cbf414af2e19d982
			ac45ac98b8544c908b4507de1e90b717
			c3d34816fe926a2b98f53afd2fa0f30a'
			}
	Response:		Response:
	Header: Changed (Code=2.04)		Header: Changed (Code=2.04)
	Payload: -		Payload: -
	Figure 33: Example of Authentication Credential Update Request-		Figure 33: Example of Authentication Credential Update Request-
	Response		Response
	Additionally, after updating its own authentication credential, a		Additionally, after updating its own authentication credential, a
	skipping to change at line 3336 ¶		skipping to change at line 3448 ¶
	* In case of forced eviction, i.e., for cases 2 and 3 above, the KDC		* In case of forced eviction, i.e., for cases 2 and 3 above, the KDC
	deletes the authentication credential of the removed Client if it		deletes the authentication credential of the removed Client if it
	acts as a repository of authentication credentials for group		acts as a repository of authentication credentials for group
	members.		members.
	* If the removed Client is registered as an observer of the group-		* If the removed Client is registered as an observer of the group-
	membership resource at /ace-group/GROUPNAME, the KDC removes the		membership resource at /ace-group/GROUPNAME, the KDC removes the
	Client from the list of observers of that resource.		Client from the list of observers of that resource.
	* If the sub-resource nodes/NODENAME was created for the removed		* If the sub-resource /nodes/NODENAME was created for the removed
	Client, the KDC deletes that sub-resource.		Client, the KDC deletes that sub-resource.
	In case of forced eviction, i.e., for cases 2 and 3 above, the KDC		In case of forced eviction, i.e., for cases 2 and 3 above, the KDC
	MAY explicitly inform the removed Client by means of the following		MAY explicitly inform the removed Client by means of the following
	methods.		methods.
	- If the evicted Client implements the 'control_uri' resource		- If the evicted Client implements the 'control_uri' resource
	specified in Section 4.3.1, the KDC sends a DELETE request,		(see Section 4.3.1), the KDC sends a DELETE request to that
	targeting the URI specified in the 'control_uri' parameter of		resource, targeting the URI specified in the 'control_uri'
	the Join Request (see Section 4.3.1).		parameter of the Join Request (see Section 4.3.1).
	- If the evicted Client is observing its associated sub-resource		- If the evicted Client is observing its associated sub-resource
	at /ace-group/GROUPNAME/nodes/NODENAME (see Section 4.8.1), the		at /ace-group/GROUPNAME/nodes/NODENAME (see Section 4.8.1), the
	KDC sends an unsolicited 4.04 (Not Found) error response, which		KDC sends an unsolicited 4.04 (Not Found) error response, which
	does not include the Observe Option and indicates that the		does not include the Observe Option and indicates that the
	observed resource has been deleted (see Section 3.2 of		observed resource has been deleted (see Section 3.2 of
	[RFC7641]).		[RFC7641]).
	The response MUST have Content-Format "application/concise-		The response MUST have Content-Format "application/concise-
	problem-details+cbor" and is formatted as defined in		problem-details+cbor" and is formatted as defined in
	skipping to change at line 3407 ¶		skipping to change at line 3519 ¶
	Distributing the new group keying material requires the KDC to send		Distributing the new group keying material requires the KDC to send
	multiple rekeying messages to the group members. Depending on the		multiple rekeying messages to the group members. Depending on the
	rekeying scheme used in the group and the reason that has triggered		rekeying scheme used in the group and the reason that has triggered
	the rekeying process, each rekeying message can be intended for one		the rekeying process, each rekeying message can be intended for one
	or multiple group members, hereafter referred to as target group		or multiple group members, hereafter referred to as target group
	members. The KDC MUST support at least the "Point-to-Point" group		members. The KDC MUST support at least the "Point-to-Point" group
	rekeying scheme described in Section 6.1 and MAY support additional		rekeying scheme described in Section 6.1 and MAY support additional
	ones.		ones.
	Each rekeying message MUST have Content-Format "application/ace-		Each rekeying message MUST have Content-Format "application/ace-
	groupcomm+cbor" and its payload formatted as a CBOR map, which MUST		groupcomm+cbor" and its payload is formatted as a CBOR map, which
	include at least the information specified in the Key Distribution		MUST include at least the information specified in the Key
	Response message (see Section 4.3.2), i.e., the parameters 'gkty',		Distribution Response message (see Section 4.3.2), i.e., the
	'key', and 'num' defined in Section 4.3.1. The CBOR map SHOULD also		parameters 'gkty', 'key', and 'num' defined in Section 4.3.1. The
	include the parameters 'exp' and 'exi'. If the 'exp' parameter is		CBOR map SHOULD also include the parameters 'exp' and 'exi'. If the
	included, the 'exi' parameter MUST also be included. The CBOR map		'exp' parameter is included, the 'exi' parameter MUST also be
	MAY include the parameter 'mgt_key_material' to specify new		included. The CBOR map MAY include the parameter 'mgt_key_material'
	administrative keying material for the target group members if it is		to specify new administrative keying material for the target group
	relevant for the used rekeying scheme.		members if it is relevant for the used rekeying scheme.
	A rekeying message may include additional information, depending on		A rekeying message may include additional information, depending on
	the rekeying scheme used in the group, the reason that has triggered		the rekeying scheme used in the group, the reason that has triggered
	the rekeying process, and the specific target group members. In		the rekeying process, and the specific target group members. In
	particular, if the group rekeying is performed due to one or multiple		particular, if the group rekeying is performed due to one or multiple
	Clients that have joined the group and the KDC acts as a repository		Clients that have joined the group and the KDC acts as a repository
	of authentication credentials of the group members, then a rekeying		of authentication credentials of the group members, then a rekeying
	message MAY also include the authentication credentials that those		message MAY also include the authentication credentials that those
	Clients use in the group, together with the roles and node identifier		Clients use in the group, together with the roles and node identifier
	that the corresponding Client has in the group. It is RECOMMENDED to		that each of such Clients has in the group. It is RECOMMENDED to
	specify this information by means of the parameters 'creds',		specify this information by means of the parameters 'creds',
	'peer_roles', and 'peer_identifiers', like it is done in the Join		'peer_roles', and 'peer_identifiers', like it is done in the Join
	Response message (see Section 4.3.1).		Response message (see Section 4.3.1).
	The complete format of a rekeying message, including the encoding and		The complete format of a rekeying message, including the encoding and
	content of the 'mgt_key_material' parameter, has to be defined in		content of the 'mgt_key_material' parameter, has to be defined in
	separate specifications aimed at profiling the used rekeying scheme		separate specifications aimed at profiling the used rekeying scheme
	in the context of the used application profile of this specification.		in the context of the used application profile of this specification.
	As a particular case, an application profile of this specification		As a particular case, an application profile of this specification
	MAY define additional information to include in rekeying messages for		MAY define additional information to include in rekeying messages for
	the "Point-to-Point" group rekeying scheme in Section 6.1 (OPT14).		the "Point-to-Point" group rekeying scheme defined in Section 6.1
			(OPT14).
	Consistently with the used group rekeying scheme, the actual delivery		Consistently with the used group rekeying scheme, the actual delivery
	of rekeying messages can occur through different approaches, as		of rekeying messages can occur through different approaches, as
	discussed in Sections 6.1 and 6.2.		discussed in Sections 6.1 and 6.2.
	The possible, temporary misalignment of the keying material stored by		The possible, temporary misalignment of the keying material stored by
	the different group members due to a group rekeying is discussed in		the different group members due to a group rekeying is discussed in
	Section 6.3. Further security considerations related to the group		Section 6.3. Further security considerations related to the group
	rekeying process are compiled in Section 10.2.		rekeying process are compiled in Section 10.2.
	6.1. Point-to-Point Group Rekeying		6.1. Point-to-Point Group Rekeying
	A point-to-point group rekeying consists in the KDC sending one		A point-to-point group rekeying consists in the KDC sending one
	individual rekeying message to each target group member. In		individual rekeying message to each target group member. In
	particular, the rekeying message is protected by means of the		particular, the rekeying message is protected by means of the secure
	security association between the KDC and the target group member in		communication association between the KDC and the target group member
	question, as per the used application profile of this specification		in question, as per the used application profile of this
	and the used transport profile of ACE.		specification and the used transport profile of ACE.
	This is the approach taken by the basic "Point-to-Point" group		This is the approach taken by the basic "Point-to-Point" group
	rekeying scheme, which the KDC can explicitly signal in the Join		rekeying scheme, which the KDC can explicitly indicate in the Join
	Response (see Section 4.3.1), through the 'rekeying_scheme' parameter		Response (see Section 4.3.1), through the 'rekeying_scheme' parameter
	specifying the value 0.		specifying the value 0.
	When taking this approach in the group identified by GROUPNAME, the		When taking this approach in the group identified by GROUPNAME, the
	KDC can practically deliver the rekeying messages to the target group		KDC can practically deliver the rekeying messages to the target group
	members in different, coexisting ways.		members in different, coexisting ways.
	* The KDC SHOULD make the /ace-group/GROUPNAME resource observable		* The KDC SHOULD make the /ace-group/GROUPNAME resource observable
	[RFC7641]. Thus, upon performing a group rekeying, the KDC can		[RFC7641]. Thus, upon performing a group rekeying, the KDC can
	distribute the new group keying material through individual		distribute the new group keying material through individual
	skipping to change at line 3488 ¶		skipping to change at line 3601 ¶
	groupcomm-error', the value of the 'error-id' field MUST be set to		groupcomm-error', the value of the 'error-id' field MUST be set to
	6 ("Group deleted").		6 ("Group deleted").
	* If a target group member specified a URI in the 'control_uri'		* If a target group member specified a URI in the 'control_uri'
	parameter of the Join Request upon joining the group (see		parameter of the Join Request upon joining the group (see
	Section 4.3.1), the KDC can provide that group member with the new		Section 4.3.1), the KDC can provide that group member with the new
	group keying material by sending a unicast POST request to that		group keying material by sending a unicast POST request to that
	URI.		URI.
	A Client that does not plan to observe the /ace-group/GROUPNAME		A Client that does not plan to observe the /ace-group/GROUPNAME
	resource at the KDC SHOULD provide a URI in the 'control_uri'		resource at the KDC SHOULD specify a URI in the 'control_uri'
	parameter of the Join Request upon joining the group.		parameter of the Join Request upon joining the group.
	If the KDC has to send a rekeying message to a target group member,		If the KDC has to send a rekeying message to a target group member,
	but this did not include the 'control_uri' parameter in the Join		but this did not include the 'control_uri' parameter in the Join
	Request and is not a registered observer for the /ace-group/GROUPNAME		Request and is not a registered observer for the /ace-group/GROUPNAME
	resource, then that target group member would not be able to		resource, then that target group member will not be able to
	participate in the group rekeying. Later on, after having repeatedly		participate in the group rekeying. Later on, after having repeatedly
	failed to successfully exchange secure messages in the group, that		failed to successfully exchange secure messages in the group, that
	group member can retrieve the current group keying material from the		group member can retrieve the current group keying material from the
	KDC by sending a GET request to /ace-group/GROUPNAME or /ace-		KDC, by sending a GET request to the /ace-group/GROUPNAME or /ace-
	group/GROUPNAME/nodes/NODENAME (see Sections 4.3.2 and 4.8.1,		group/GROUPNAME/nodes/NODENAME resource at the KDC (see Sections
	respectively).		4.3.2 and 4.8.1, respectively).
	Figure 34 provides an example of point-to-point group rekeying. In		Figure 34 provides an example of point-to-point group rekeying. In
	particular, the example makes the following assumptions:		particular, the example makes the following assumptions:
	* The group currently consists of four group members, namely C1, C2,		* The group currently consists of four group members, namely C1, C2,
	C3, and C4.		C3, and C4.
	* Each group member, when joining the group, provided the KDC with a		* Each group member, when joining the group, provided the KDC with a
	URI in the 'control_uri' parameter with url-path "grp-rek".		URI in the 'control_uri' parameter with url-path "grp-rek".
	skipping to change at line 3585 ¶		skipping to change at line 3698 ¶
	the administrative keying material to use to protect them, as well as		the administrative keying material to use to protect them, as well as
	the set of target group members depend on the specific group rekeying		the set of target group members depend on the specific group rekeying
	scheme and are typically affected by the reason that has triggered		scheme and are typically affected by the reason that has triggered
	the group rekeying. Details about the data content and format of		the group rekeying. Details about the data content and format of
	rekeying messages have to be defined by separate documents profiling		rekeying messages have to be defined by separate documents profiling
	the use of the group rekeying scheme in the context of the used		the use of the group rekeying scheme in the context of the used
	application profile of this specification.		application profile of this specification.
	When one of these group rekeying schemes is used, the KDC provides		When one of these group rekeying schemes is used, the KDC provides
	related information to a Client joining the group in the Join		related information to a Client joining the group in the Join
	Response message (see Section 4.3.1). In particular,		Response message (see Section 4.3.1). In particular, the
	'rekeying_scheme' identifies the rekeying scheme used in the group		'rekeying_scheme' parameter indicates the rekeying scheme used in the
	(if no default can be assumed); 'control_group_uri', if present,		group (if no default scheme can be assumed); the 'control_group_uri'
	specifies a URI whose addressing information is, e.g., a multicast IP		parameter, if present, specifies a URI whose addressing information
	address, where the KDC will send the rekeying messages for that group		is, e.g., a multicast IP address where the KDC will send the rekeying
	by reaching all the group members; and 'mgt_key_material' specifies a		messages for that group as intended to reach all the group members;
	subset of the administrative keying material intended for that		and the 'mgt_key_material' parameter specifies a subset of the
	particular joining Client to have, as used to protect the rekeying		administrative keying material intended for that particular joining
	messages sent to the group when also intended for that joining		Client to have, as used to protect the rekeying messages sent to the
	Client.		group when also intended for that joining Client.
	Rekeying messages can be protected at the application layer by using		Rekeying messages can be protected at the application layer by using
	COSE and the administrative keying material as prescribed by the		COSE [RFC9052] and the administrative keying material as prescribed
	specific group rekeying scheme (see Section 6.2.1). After that, the		by the specific group rekeying scheme (see Section 6.2.1). After
	delivery of protected rekeying messages to the intended target group		that, the delivery of protected rekeying messages to the intended
	members can occur in different ways, such as the following ones.		target group members can occur in different ways, such as the
			following ones.
	Over multicast - In this case, the KDC simply sends a rekeying		Over multicast - In this case, the KDC simply sends a rekeying
	message as a CoAP request addressed to the URI specified in the		message as a CoAP request addressed to the URI specified in the
	'control_group_uri' parameter of the Join Response (see		'control_group_uri' parameter of the Join Response (see
	Section 4.3.1).		Section 4.3.1).
	If a particular rekeying message is intended for a single target		If a particular rekeying message is intended for a single target
	group member, the KDC may alternatively protect the message using		group member, the KDC may alternatively protect the message using
	the security association with that group member and deliver the		the secure communication association with that group member and
	message like when using the "Point-to-Point" group rekeying scheme		deliver the message like when using the "Point-to-Point" group
	(see Section 6.1).		rekeying scheme (see Section 6.1).
	Through a pub-sub communication model - In this case, the KDC acts		Through a pub-sub communication model - In this case, the KDC acts
	as a publisher and publishes each rekeying message to a specific		as a publisher and publishes each rekeying message to a specific
	"rekeying topic", which is associated with the group and is hosted		"rekeying topic", which is associated with the group and is hosted
	at a Broker server. Following their group joining, the group		at a Broker server. Following their group joining, the group
	members subscribe to the rekeying topic at the Broker, thus		members subscribe to the rekeying topic at the Broker, thus
	receiving the group rekeying messages as they are published by the		receiving the group rekeying messages as they are published by the
	KDC.		KDC.
	In order to make such message delivery more efficient, the		In order to make such message delivery more efficient, the
	skipping to change at line 3651 ¶		skipping to change at line 3765 ¶
	the leaving of group members, which have to be excluded from future		the leaving of group members, which have to be excluded from future
	communications in the group.		communications in the group.
	From a high-level point of view, each group member stores only a		From a high-level point of view, each group member stores only a
	subset of the overall administrative keying material, which is		subset of the overall administrative keying material, which is
	obtained upon joining the group. Then, when a group rekeying occurs:		obtained upon joining the group. Then, when a group rekeying occurs:
	* Each rekeying message is protected by using a (most convenient)		* Each rekeying message is protected by using a (most convenient)
	key from the administrative keying material such that: i) the used		key from the administrative keying material such that: i) the used
	key is not stored by any node leaving the group, i.e., the key is		key is not stored by any node leaving the group, i.e., the key is
	safe to use and does not have to be renewed and ii) the used key		safe to use and does not have to be renewed; and ii) the used key
	is stored by all the target group members that indeed have to be		is stored by all the target group members that indeed have to be
	provided with new group keying material to protect communications		provided with new group keying material to protect communications
	in the group.		in the group.
	* Each rekeying message includes not only the new group keying		* Each rekeying message includes not only the new group keying
	material intended for all the rekeyed group members but also any		material intended for all the rekeyed group members but also any
	new administrative keys that: i) are pertaining to and supposed to		new administrative keys that: i) are pertaining to and supposed to
	be stored by the target group members and ii) had to be updated		be stored by the target group members; and ii) had to be updated
	since leaving group members to store the previous version.		because leaving group members to store the previous version.
	Further details depend on the specific rekeying scheme used in the		Further details depend on the specific rekeying scheme used in the
	group.		group.
	Figure 35 provides an example of a one-to-many group rekeying over		Figure 35 provides an example of a one-to-many group rekeying over
	multicast. In particular, the example makes the following		multicast. In particular, the example makes the following
	assumptions:		assumptions:
	* The group currently consists of four group members, namely C1, C2,		* The group currently consists of four group members, namely C1, C2,
	C3, and C4.		C3, and C4.
	skipping to change at line 3690 ¶		skipping to change at line 3804 ¶
	in the group has version number num=5.		in the group has version number num=5.
	* The KDC performs the group rekeying in such a way to evict the		* The KDC performs the group rekeying in such a way to evict the
	group member C3, which has been found to be compromised.		group member C3, which has been found to be compromised.
	In the example, the KDC determines that the most convenient way to		In the example, the KDC determines that the most convenient way to
	perform a group rekeying that evicts C3 is as follows.		perform a group rekeying that evicts C3 is as follows.
	First, the KDC sends one rekeying message over multicast to the		First, the KDC sends one rekeying message over multicast to the
	multicast address MULT_ADDR and the url-path "grp-mrek". In the		multicast address MULT_ADDR and the url-path "grp-mrek". In the
	figure, the message is denoted with dashed lines. The message is		figure, the message is denoted with solid arrows. The message is
	protected with a non-compromised key from the administrative keying		protected with a non-compromised key from the administrative keying
	material that only C1 and C2 store. Therefore, even though all the		material that only C1 and C2 store. Therefore, even though all the
	group members receive this message, only C1 and C2 are able to		group members receive this message, only C1 and C2 are able to
	decrypt it. The message includes: the new group keying material with		decrypt it. The message includes: the new group keying material with
	version number num=6 and new keys from the administrative keying		version number num=6 and new keys from the administrative keying
	material to replace those stored by the group members C1, C2, and C3.		material to replace those stored by the group members C1, C2, and C3.
	After that, the KDC sends one rekeying message addressed individually		After that, the KDC sends one rekeying message addressed individually
	to C4 and with url-path "grp-rek". In the figure, the message is		to C4 and with url-path "grp-rek". In the figure, the message is
	denoted with a dotted line. The message is protected with the secure		denoted with a dotted arrow. The message is protected with the
	association shared between C4 and the KDC. The message includes: the		secure association shared between C4 and the KDC. The message
	new group keying material with version number num=6 and new keys from		includes: the new group keying material with version number num=6 and
	the administrative keying material to replace those stored by both C4		new keys from the administrative keying material to replace those
	and C3.		stored by both C4 and C3.
	.---------------------------------------------------------------------.		.---------------------------------------------------------------------.
	| KDC |		| KDC |
	'---------------------------------------------------------------------'		'---------------------------------------------------------------------'
	| :		| :
	* Group keying material (num=6) | * Group keying :		* Group keying material (num=6) | * Group keying :
	* Updated administrative | material (num=6) :		* Updated administrative | material (num=6) :
	keying material for C1 and C2 | * Updated administrative :		keying material for C1 and C2 | * Updated administrative :
	| keying material for C4 :		| keying material for C4 :
	| :		| :
	skipping to change at line 3760 ¶		skipping to change at line 3874 ¶
	* A Base IV is also included with the same size of the AEAD nonce		* A Base IV is also included with the same size of the AEAD nonce
	considered by the encryption algorithm to use.		considered by the encryption algorithm to use.
	First, the KDC computes a COSE_Encrypt0 object as follows.		First, the KDC computes a COSE_Encrypt0 object as follows.
	* The encryption key to use is selected from the administrative		* The encryption key to use is selected from the administrative
	keying material, as defined by the rekeying scheme used in the		keying material, as defined by the rekeying scheme used in the
	group.		group.
	* The plaintext is the actual data content of the rekeying message.		* The plaintext is the actual data content of the present rekeying
			message.
	* The Additional Authenticated Data (AAD) is empty unless otherwise		* The Additional Authenticated Data (AAD) is empty unless otherwise
	specified by separate documents profiling the use of the group		specified by separate documents profiling the use of the group
	rekeying scheme.		rekeying scheme.
	* Since the KDC is the only sender of rekeying messages, the AEAD		* Since the KDC is the only sender of rekeying messages, the AEAD
	nonce can be computed as follows, where NONCE_SIZE is the size in		nonce can be computed as follows, where NONCE_SIZE is the size in
	bytes of the AEAD nonce. Separate documents profiling the use of		bytes of the AEAD nonce. Separate documents profiling the use of
	the group rekeying scheme may define alternative ways to compute		the group rekeying scheme may define alternative ways to compute
	the AEAD nonce.		the AEAD nonce.
	skipping to change at line 3800 ¶		skipping to change at line 3915 ¶
	encryption key, AEAD nonce). For example, this includes not using		encryption key, AEAD nonce). For example, this includes not using
	the same encryption key from the administrative keying material		the same encryption key from the administrative keying material
	more than 2^16 times during the same rekeying instance.		more than 2^16 times during the same rekeying instance.
	* The protected header of the COSE_Encrypt0 object MUST include the		* The protected header of the COSE_Encrypt0 object MUST include the
	following parameters.		following parameters.
	- 'alg': specifying the used encryption algorithm.		- 'alg': specifying the used encryption algorithm.
	- 'kid': specifying the identifier of the encryption key from the		- 'kid': specifying the identifier of the encryption key from the
	administrative keying material used to protect this rekeying		administrative keying material used to protect the present
	message.		rekeying message.
	* The unprotected header of the COSE_Encrypt0 object MUST include		* The unprotected header of the COSE_Encrypt0 object MUST include
	the 'Partial IV' parameter with the value of the Partial IV		the 'Partial IV' parameter with the value of the Partial IV
	computed above.		computed above.
	In order to ensure source authentication, each rekeying message		In order to ensure source authentication, each rekeying message
	protected with the administrative keying material MUST be signed by		protected with the administrative keying material MUST be signed by
	the KDC. To this end, the KDC computes a countersignature of the		the KDC. To this end, the KDC computes a countersignature of the
	COSE_Encrypt0 object, as described in Sections 3.2 and 3.3 of		COSE_Encrypt0 object, as described in Sections 3.2 and 3.3 of
	[RFC9338]. In particular, the following applies when computing the		[RFC9338]. In particular, the following applies when computing the
	skipping to change at line 3866 ¶		skipping to change at line 3981 ¶
	6.3. Misalignment of Group Keying Material		6.3. Misalignment of Group Keying Material
	A group member can receive a message shortly after the group has been		A group member can receive a message shortly after the group has been
	rekeyed and new keying material has been distributed by the KDC. In		rekeyed and new keying material has been distributed by the KDC. In
	the following two cases, this may result in misaligned keying		the following two cases, this may result in misaligned keying
	material between the group members.		material between the group members.
	In the first case, the sender protects a message using the old group		In the first case, the sender protects a message using the old group
	keying material. However, the recipient receives the message after		keying material. However, the recipient receives the message after
	having received the new group keying material, hence not being able		having received the new group keying material, hence it is not able
	to correctly process it. A possible way to limit the impact of this		to correctly process the message. A possible way to limit the impact
	issue is to preserve the old, retained group keying material for a		of this issue is to preserve the old, retained group keying material
	maximum amount of time defined by the application, during which it is		for a maximum amount of time defined by the application, during which
	used solely for processing incoming messages. By doing so, the		such group keying material is used solely for processing incoming
	recipient can still temporarily process received messages also by		messages. By doing so, the recipient can still temporarily process
	using the old, retained group keying material. Note that a former		received messages also by using the old, retained group keying
	(compromised) group member can take advantage of this by sending		material. Note that a former (compromised) group member can take
	messages protected with the old, retained group keying material.		advantage of this by sending messages protected with the old,
	Therefore, a conservative application policy should not admit the		retained group keying material. Therefore, a conservative
	storage of old group keying material. Eventually, the sender will		application policy should not admit the storage of old group keying
	have obtained the new group keying material too and can possibly		material. Eventually, the sender will have obtained the new group
	resend the message protected with such keying material.		keying material too and can possibly resend the message protected
			with such keying material.
	In the second case, the sender protects a message using the new group		In the second case, the sender protects a message using the new group
	keying material, but the recipient receives that message before		keying material, but the recipient receives that message before
	having received the new group keying material. Therefore, the		having received the new group keying material. Therefore, the
	recipient would not be able to correctly process the message and		recipient will not be able to correctly process the message and hence
	hence discards it. If the recipient receives the new group keying		will discard it. If the recipient receives the new group keying
	material shortly after that and the application at the sender		material shortly after that and the application at the sender
	endpoint performs retransmissions, the former will still be able to		endpoint performs retransmissions, the former will still be able to
	receive and correctly process the message. In any case, the		receive and correctly process the message. In any case, the
	recipient should actively ask the KDC for the latest group keying		recipient should actively ask the KDC for the latest group keying
	material according to an application-defined policy, for instance,		material according to an application-defined policy, for instance,
	after a given number of unsuccessfully decrypted incoming messages.		after a given number of unsuccessfully decrypted incoming messages.
	7. Extended Scope Format		7. Extended Scope Format
	This section defines an extended format of binary-encoded scope,		This section defines an extended format of binary-encoded scope,
	skipping to change at line 3922 ¶		skipping to change at line 4038 ¶
	The value of the 'scope' claim following the extended format is		The value of the 'scope' claim following the extended format is
	composed as follows. Given the original scope using semantics SEM		composed as follows. Given the original scope using semantics SEM
	and encoded as a CBOR byte string, the corresponding extended scope		and encoded as a CBOR byte string, the corresponding extended scope
	consists of the same CBOR byte string enclosed by a CBOR tag		consists of the same CBOR byte string enclosed by a CBOR tag
	[RFC8949], whose tag number identifies the semantics SEM.		[RFC8949], whose tag number identifies the semantics SEM.
	The resulting tagged CBOR byte string is used as the value of the		The resulting tagged CBOR byte string is used as the value of the
	'scope' claim of the access token.		'scope' claim of the access token.
	Figures 36 and 37 build on the examples in Section 3.2 and show the		Figures 36 and 37 build on the examples in Section 3.1 and show the
	corresponding extended scopes.		corresponding extended scopes.
	;# include rfc9237		;# include rfc9237
	gname = tstr		gname = tstr
	permissions = uint .bits roles		permissions = uint .bits roles
	roles = &(		roles = &(
	Requester: 1,		Requester: 1,
	Responder: 2,		Responder: 2,
	Monitor: 3,		Monitor: 3,
	Verifier: 4		Verifier: 4
	)		)
	scope_entries = AIF-Generic<gname, permissions>		scope_entries = AIF-Generic<gname, permissions>
	scope = bstr .cbor scope_entries		scope = bstr .cbor scope_entries
	extended_scope = #6.TAG_FOR_THIS_SEMANTICS(scope)		extended_scope = #6.<TAG_FOR_THIS_SEMANTICS>(scope)
	Figure 36: Example CDDL Definition of scope, Using the Default		TAG_FOR_THIS_SEMANTICS = uint
	Authorization Information Format
			Figure 36: Example of Extended scope Using AIF
	gname = tstr		gname = tstr
	role = tstr		role = tstr
	scope_entry = [ gname , ? ( role / [ 2*role ] ) ]		scope_entry = [ gname , ? ( role / [ 2*role ] ) ]
	scope_entries = [ * scope_entry ]		scope_entries = [ * scope_entry ]
	scope = bstr .cbor scope_entries		scope = bstr .cbor scope_entries
	extended_scope = #6.TAG_FOR_THIS_SEMANTICS(scope)		extended_scope = #6.<TAG_FOR_THIS_SEMANTICS>(scope)
	Figure 37: CDDL Definition of scope, Using an Example Group Name		TAG_FOR_THIS_SEMANTICS = uint
	Encoded as tstr and Role as tstr
			Figure 37: Example of Extended scope Using the Textual Format,
			with the Role Identifiers Encoded as Text Strings
	The usage of the extended scope format is not limited to application		The usage of the extended scope format is not limited to application
	profiles of this specification or to applications based on group		profiles of this specification or to applications based on group
	communication. Rather, it is generally applicable to any application		communication. Rather, it is generally applicable to any application
	and application profile where access control information in the		and application profile where access control information in the
	access token is expressed as a binary-encoded scope.		access token is expressed as a binary-encoded scope.
	Applications and application profiles using the extended format of		Applications and application profiles using the extended format of
	scope have to specify which CBOR tag from [CBOR.Tags] is used for		scope have to specify which CBOR tag from [CBOR.Tags] is used for
	identifying the scope semantics or to register a new CBOR tag if a		identifying the scope semantics or to register a new CBOR tag if a
	skipping to change at line 3990 ¶		skipping to change at line 4109 ¶
	This is especially relevant when the binary encoded scope uses AIF.		This is especially relevant when the binary encoded scope uses AIF.
	That is, it is expected that the definition of an AIF-specific data		That is, it is expected that the definition of an AIF-specific data
	model comes together with the registration of CoAP Content-Formats		model comes together with the registration of CoAP Content-Formats
	for the relevant combinations of its Toid and Tperm values. As		for the relevant combinations of its Toid and Tperm values. As
	discussed above, this yields the automatic registration of the CBOR		discussed above, this yields the automatic registration of the CBOR
	tags associated with those CoAP Content-Formats.		tags associated with those CoAP Content-Formats.
	8. ACE Groupcomm Parameters		8. ACE Groupcomm Parameters
	This specification defines a number of parameters used during the		This specification defines a number of parameters used during the
	second part of the message exchange after the exchange of Token		second phase of the key provisioning process, i.e., after the
	Transfer Request and Response. The table below summarizes them and		exchange after the exchange of Token Transfer Request and Response.
	specifies the CBOR key to use instead of the full descriptive name.		The table below summarizes them and specifies the CBOR map keys to
			use instead of the full descriptive names.
	Note that the media type "application/ace-groupcomm+cbor" MUST be		Note that the media type "application/ace-groupcomm+cbor" MUST be
	used when these parameters are transported in the respective message		used when these parameters are transported in the respective CBOR map
	fields.		entries.
	+=======================+======+========================+===========+		+=======================+======+========================+===========+
	| Name | CBOR | CBOR Type | Reference |		| Name | CBOR | CBOR Type | Reference |
	| | Key | | |		| | Key | | |
	+=======================+======+========================+===========+		+=======================+======+========================+===========+
	| gid | 0 | array | RFC 9594 |		| gid | 0 | array | RFC 9594 |
	+-----------------------+------+------------------------+-----------+		+-----------------------+------+------------------------+-----------+
	| gname | 1 | array of tstr | RFC 9594 |		| gname | 1 | array of tstr | RFC 9594 |
	+-----------------------+------+------------------------+-----------+		+-----------------------+------+------------------------+-----------+
	| guri | 2 | array of tstr | RFC 9594 |		| guri | 2 | array of tstr | RFC 9594 |
	skipping to change at line 4071 ¶		skipping to change at line 4191 ¶
	Table 5: ACE Groupcomm Parameters		Table 5: ACE Groupcomm Parameters
	The KDC is expected to support all the parameters above. Instead, a		The KDC is expected to support all the parameters above. Instead, a
	Client can support only a subset of such parameters, depending on the		Client can support only a subset of such parameters, depending on the
	roles it expects to take in the joined groups or on other conditions		roles it expects to take in the joined groups or on other conditions
	defined in application profiles of this specification.		defined in application profiles of this specification.
	In the following, the parameters are categorized according to the		In the following, the parameters are categorized according to the
	support expected by Clients. That is, a Client that supports a		support expected by Clients. That is, a Client that supports a
	parameter is able to: i) use and specify it in a request message to		parameter is able to: i) use and specify it in a request message to
	the KDC and ii) understand and process it if specified in a response		the KDC; and ii) understand and process it if specified in a response
	message from the KDC. It is REQUIRED of application profiles of this		message from the KDC. It is REQUIRED of application profiles of this
	specification to sort their newly defined parameters according to the		specification to sort their newly defined parameters according to the
	same categorization (REQ29).		same categorization (REQ29).
	Note that the actual use of a parameter and its inclusion in a		Note that the actual use of a parameter and its inclusion in a
	message depends on the specific exchange, the specific Client and		message depends on the specific exchange, the specific Client and
	group involved, as well as what is defined in the used application		group involved, as well as what is defined in the used application
	profile of this specification.		profile of this specification.
	A Client MUST support the following parameters.		A Client MUST support the following parameters.
	skipping to change at line 4118 ¶		skipping to change at line 4238 ¶
	* 'control_uri'		* 'control_uri'
	* 'rekeying_scheme'		* 'rekeying_scheme'
	A Client SHOULD support the following parameter.		A Client SHOULD support the following parameter.
	* 'get_creds': That is, not supporting this parameter would yield		* 'get_creds': That is, not supporting this parameter would yield
	the inconvenient and undesirable behavior where: i) the Client		the inconvenient and undesirable behavior where: i) the Client
	does not ask for the other group members' authentication		does not ask for the other group members' authentication
	credentials upon joining the group (see Section 4.3.1.1) and ii)		credentials upon joining the group (see Section 4.3.1.1); and ii)
	later on as a group member, the Client only retrieves the		later on as a group member, the Client only retrieves the
	authentication credentials of all group members (see		authentication credentials of all group members (see
	Section 4.4.2.1).		Section 4.4.2.1).
	The following conditional parameters are relevant only if specific		The following conditional parameters are relevant only if specific
	conditions hold. It is REQUIRED of application profiles of this		conditions hold. It is REQUIRED of application profiles of this
	specification to define whether Clients must, should, or may support		specification to define whether Clients must, should, or may support
	these parameters and under which circumstances (REQ30).		these parameters and under which circumstances (REQ30).
	* 'client_cred' and 'client_cred_verify': These parameters are		* 'client_cred' and 'client_cred_verify': These parameters are
	skipping to change at line 4163 ¶		skipping to change at line 4283 ¶
	used application profile of this specification, the KDC has an		used application profile of this specification, the KDC has an
	associated authentication credential and this is required for the		associated authentication credential and this is required for the
	correct group operation.		correct group operation.
	* 'mgt_key_material': This parameter is relevant for a Client that		* 'mgt_key_material': This parameter is relevant for a Client that
	supports an advanced rekeying scheme possibly used in the group,		supports an advanced rekeying scheme possibly used in the group,
	such as based on one-to-many rekeying messages sent over IP		such as based on one-to-many rekeying messages sent over IP
	multicast.		multicast.
	* 'control_group_uri': This parameter is relevant for a Client that		* 'control_group_uri': This parameter is relevant for a Client that
	supports the hosting of local resources, each associated with a		also acts as a CoAP server supporting: i) the hosting of a
	group (hence acting as CoAP server), and the reception of one-to-		dedicated resource for each group that the Client is interested to
	many requests sent to those resources by the KDC (e.g., over IP		be a part of; and ii) the reception of one-to-many requests sent
	multicast), which targets multiple members of the corresponding		to those resources by the KDC (e.g., over IP multicast), as
	group. Examples of related management operations that the KDC can		targeting multiple members of the corresponding group. Examples
	perform by this means are the eviction of group members and the		of related management operations that the KDC can perform by this
	execution of a group rekeying process through an advanced rekeying		means are the eviction of group members and the execution of a
	scheme, such as based on one-to-many rekeying messages.		group rekeying process through an advanced rekeying scheme, such
			as based on one-to-many rekeying messages.
	9. ACE Groupcomm Error Identifiers		9. ACE Groupcomm Error Identifiers
	This specification defines a number of values that the KDC can use as		This specification defines a number of values that the KDC can use as
	error identifiers. These are used in error responses with Content-		error identifiers. These are used in error responses with Content-
	Format "application/concise-problem-details+cbor" as values of the		Format "application/concise-problem-details+cbor", as values of the
	'error-id' field within the Custom Problem Detail entry 'ace-		'error-id' field within the Custom Problem Detail entry 'ace-
	groupcomm-error' (see Section 4.1.2).		groupcomm-error' (see Section 4.1.2).
	+=======+=============================================+		+=======+=============================================+
	| Value | Description |		| Value | Description |
	+=======+=============================================+		+=======+=============================================+
	| 0 | Operation permitted only to group members |		| 0 | Operation permitted only to group members |
	+-------+---------------------------------------------+		+-------+---------------------------------------------+
	| 1 | Request inconsistent with the current roles |		| 1 | Request inconsistent with the current roles |
	+-------+---------------------------------------------+		+-------+---------------------------------------------+
	skipping to change at line 4203 ¶		skipping to change at line 4324 ¶
	+-------+---------------------------------------------+		+-------+---------------------------------------------+
	| 5 | Group membership terminated |		| 5 | Group membership terminated |
	+-------+---------------------------------------------+		+-------+---------------------------------------------+
	| 6 | Group deleted |		| 6 | Group deleted |
	+-------+---------------------------------------------+		+-------+---------------------------------------------+
	Table 6: ACE Groupcomm Error Identifiers		Table 6: ACE Groupcomm Error Identifiers
	If a Client supports the problem-details format [RFC9290] and the		If a Client supports the problem-details format [RFC9290] and the
	Custom Problem Detail entry 'ace-groupcomm-error' defined in		Custom Problem Detail entry 'ace-groupcomm-error' defined in
	Section 4.1.2 and is able to understand the error specified in the		Section 4.1.2 of this document and is able to understand the error
	'error-id' field therein, then the Client can use that information to		specified in the 'error-id' field therein, then the Client can use
	determine what actions to take next. If the Concise Problem Details		that information to determine what actions to take next. If the
	data item specified in the error response includes the 'detail' entry		Concise Problem Details data item specified in the error response
	and the Client supports it, such an entry may provide additional		includes the 'detail' entry and the Client supports it, such an entry
	context.		may provide additional context.
	In particular, the following guidelines apply, and application		In particular, the following guidelines apply, and application
	profiles of this specification can define more detailed actions for		profiles of this specification can define more detailed actions for
	the Client to take when learning that a specific error has occurred.		the Client to take when learning that a specific error has occurred.
	* In case of error 0, the Client should stop sending the request in		* In case of error 0, the Client should stop sending the request in
	question to the KDC. Rather, the Client should first join the		question to the KDC. Rather, the Client should first join the
	targeted group. If it has not happened already, this first		targeted group. If it has not happened already, this first
	requires the Client to obtain an appropriate access token		requires the Client to obtain an appropriate access token
	authorizing access to the group and provide it to the KDC.		authorizing access to the group and provide it to the KDC.
	* In case of error 1, the Client as a group member should rejoin the		* In case of error 1, the Client as a group member should rejoin the
	group with all the roles needed to perform the operation in		group with all the roles needed to perform the operation in
	question. This might require the Client to first obtain a new		question. This might require the Client to first obtain a new
	access token and provide it to the KDC if the current access token		access token and provide it to the KDC, if the current access
	does not authorize it to take those roles in the group. For		token does not authorize the Client to take those roles in the
	operations admitted to a Client that is not a group member (e.g.,		group. For operations admitted to a Client that is not a group
	an external signature verifier), the Client should first obtain a		member (e.g., an external signature verifier), the Client should
	new access token authorizing to also have the missing roles.		first obtain a new access token authorizing to also have the
			missing roles.
	* In case of error 2, the Client has to obtain or self-generate a		* In case of error 2, the Client has to obtain or self-generate a
	different asymmetric key pair, as aligned to the public key		different asymmetric key pair, as aligned to the public key
	algorithms and parameters used in the targeted group. After that,		algorithm and parameters used in the targeted group. After that,
	the Client should provide the KDC with its new authentication		the Client should provide the KDC with its new authentication
	credential, which is consistent with the format used in the		credential, which is consistent with the format used in the
	targeted group and including the new public key.		targeted group and including the new public key.
	* In case of error 3, the Client should ensure to compute its proof-		* In case of error 3, the Client should ensure to compute its proof-
	of-possession evidence by correctly using the parameters and		of-possession evidence by correctly using the parameters and
	procedures defined in the used application profile of this		procedures defined in the used application profile of this
	specification. In an unattended setup, it might not be possible		specification. In an unattended setup, it might not be possible
	for a Client to autonomously diagnose the error and take an		for a Client to autonomously diagnose the error and take an
	effective next action to address it.		effective next action to address it.
	skipping to change at line 4385 ¶		skipping to change at line 4507 ¶
	material used before their joining, and thus they could access		material used before their joining, and thus they could access
	past group communications if they have recorded old exchanged		past group communications if they have recorded old exchanged
	messages. This might still be acceptable for some applications		messages. This might still be acceptable for some applications
	and in situations where the new group members are freshly deployed		and in situations where the new group members are freshly deployed
	through strictly controlled procedures.		through strictly controlled procedures.
	* The leaving group members would remain able to access upcoming		* The leaving group members would remain able to access upcoming
	group communications, as protected with the current keying		group communications, as protected with the current keying
	material that has not been updated. This is typically		material that has not been updated. This is typically
	undesirable, especially if the leaving group member is compromised		undesirable, especially if the leaving group member is compromised
	or suspected to be, and it might have an impact or compromise the		or suspected to be, and it might impact or compromise the security
	security properties of the protocols used in the group to protect		properties of the protocols used in the group to protect messages
	messages exchanged among the group members.		exchanged among the group members.
	The KDC should renew the group keying material in case it has		The KDC should renew the group keying material in case it has
	rebooted, even if it stores the whole group keying material in		rebooted, even if it stores the whole group keying material in
	persistent storage. This assumes that the secure associations with		persistent storage. This assumes that the secure communication
	the current group members as well as any administrative keying		associations with the current group members as well as any
	material required to rekey the group are also stored in persistent		administrative keying material required to rekey the group are also
	storage.		stored in persistent storage.
	However, if the KDC relies on Observe notifications to distribute the		However, if the KDC relies on Observe notifications to distribute the
	new group keying material, the KDC would have lost all the current		new group keying material, the KDC would have lost all the current
	ongoing Observations with the group members after rebooting, and the		ongoing Observations with the group members after rebooting, and the
	group members would continue using the old group keying material.		group members would continue using the old group keying material.
	Therefore, the KDC will rely on each group member asking for the new		Therefore, the KDC will rely on each group member asking for the new
	group keying material (see Sections 4.3.2.1 and 4.8.1.1) or perform a		group keying material (see Sections 4.3.2.1 and 4.8.1.1) or perform a
	group rekeying by actively sending rekeying messages to group members		group rekeying by actively sending rekeying messages to group members
	as discussed in Section 6.		as discussed in Section 6.
	skipping to change at line 4431 ¶		skipping to change at line 4553 ¶
	If the Block-Wise CoAP options [RFC7959] are used and the keying		If the Block-Wise CoAP options [RFC7959] are used and the keying
	material is updated in the middle of a Block-Wise transfer, the		material is updated in the middle of a Block-Wise transfer, the
	sender of the blocks just changes the group keying material to the		sender of the blocks just changes the group keying material to the
	updated one and continues the transfer. As long as both sides get		updated one and continues the transfer. As long as both sides get
	the new group keying material, updating the group keying material in		the new group keying material, updating the group keying material in
	the middle of a transfer will not cause any issue. Otherwise, the		the middle of a transfer will not cause any issue. Otherwise, the
	sender will have to transmit the message again when receiving an		sender will have to transmit the message again when receiving an
	error message from the recipient.		error message from the recipient.
	Compared to a scenario where the transfer does not use Block-Wise,		Compared to a scenario where the transfer does not use Block-Wise,
	depending on how fast the group keying material is changed, the group		and depending on how fast the group keying material is changed, the
	members might consume a larger amount of the network bandwidth by		group members might consume a larger amount of the network bandwidth
	repeatedly resending the same blocks, which might be problematic.		by repeatedly resending the same blocks, which might be problematic.
	11. IANA Considerations		11. IANA Considerations
	Per this document, IANA has completed the following actions.		Per this document, IANA has completed the following actions.
	11.1. Media Type Registrations		11.1. Media Type Registrations
	This specification has registered the "application/ace-		This specification has registered the "application/ace-
	groupcomm+cbor" media type for messages of the protocols defined in		groupcomm+cbor" media type for messages of the protocols defined in
	this document following the ACE exchange and carrying parameters		this document following the ACE exchange and carrying parameters
	skipping to change at line 4573 ¶		skipping to change at line 4695 ¶
	Values in this registry are covered by different registration		Values in this registry are covered by different registration
	policies as indicated below. Some policies require Expert Review;		policies as indicated below. Some policies require Expert Review;
	guidelines are provided in Section 11.14		guidelines are provided in Section 11.14
	The columns of this registry are:		The columns of this registry are:
	Name: This is a descriptive name that enables easier reference to		Name: This is a descriptive name that enables easier reference to
	the item. The name MUST be unique. It is not used in the		the item. The name MUST be unique. It is not used in the
	encoding.		encoding.
	CBOR Key: This is the value used as the CBOR key of the item. These		CBOR Key: This is the value used as the CBOR map key of the item.
	values MUST be unique. The value can be a positive integer, a		These values MUST be unique. The value can be a positive integer,
	negative integer, or a text string. Different ranges of values		a negative integer, or a text string. Different ranges of values
	use different registration policies [RFC8126]. Integer values		use different registration policies [RFC8126]. Integer values
	from -256 to 255 as well as text strings of length 1 are		from -256 to 255 as well as text strings of length 1 are
	designated as "Standards Action With Expert Review". Integer		designated as "Standards Action With Expert Review". Integer
	values from -65536 to -257 and from 256 to 65535 as well as text		values from -65536 to -257 and from 256 to 65535 as well as text
	strings of length 2 are designated as "Specification Required".		strings of length 2 are designated as "Specification Required".
	Integer values greater than 65535 as well as text strings of		Integer values greater than 65535 as well as text strings of
	length greater than 2 are designated as "Expert Review". Integer		length greater than 2 are designated as "Expert Review". Integer
	values less than -65536 are marked as "Private Use".		values less than -65536 are marked as "Private Use".
	CBOR Type: This contains the CBOR type of the item or a pointer to		CBOR Type: This field contains the CBOR type of the item or a
	the registry that defines its type when that depends on another		pointer to the registry that defines its type when that depends on
	item.		another item.
	Reference: This contains a pointer to the public specification for		Reference: This field contains a pointer to the public specification
	the item.		for the item.
	This registry has been initially populated with the values in		This registry has been initially populated with the values in
	Table 5.		Table 5.
	11.8. ACE Groupcomm Key Types		11.8. ACE Groupcomm Key Types
	This specification establishes the "ACE Groupcomm Key Types" IANA		This specification establishes the "ACE Groupcomm Key Types" IANA
	registry within the "Authentication and Authorization for Constrained		registry within the "Authentication and Authorization for Constrained
	Environments (ACE)" registry group.		Environments (ACE)" registry group.
	skipping to change at line 4632 ¶		skipping to change at line 4754 ¶
	Use".		Use".
	Profile: This field may contain one or more descriptive strings of		Profile: This field may contain one or more descriptive strings of
	application profiles to be used with this item. The values should		application profiles to be used with this item. The values should
	be taken from the "Name" column of the "ACE Groupcomm Profiles"		be taken from the "Name" column of the "ACE Groupcomm Profiles"
	registry.		registry.
	Description: This field contains a brief description of the keying		Description: This field contains a brief description of the keying
	material.		material.
	Reference: This contains a pointer to the public specification for		Reference: This field contains a pointer to the public specification
	the format of the keying material, if one exists.		for the format of the keying material, if one exists.
	This registry has been initially populated with the value in Table 1.		This registry has been initially populated with the value in Table 1.
	11.9. ACE Groupcomm Profiles		11.9. ACE Groupcomm Profiles
	This specification establishes the "ACE Groupcomm Profiles" IANA		This specification establishes the "ACE Groupcomm Profiles" IANA
	registry within the "Authentication and Authorization for Constrained		registry within the "Authentication and Authorization for Constrained
	Environments (ACE)" registry group.		Environments (ACE)" registry group.
	Values in this registry are covered by different registration		Values in this registry are covered by different registration
	policies as indicated below. Some policies require Expert Review;		policies as indicated below. Some policies require Expert Review;
	guidelines are provided in Section 11.14.		guidelines are provided in Section 11.14.
	The columns of this registry are:		The columns of this registry are:
	Name: The name of the application profile to be used as value of the		Name: The name of the application profile.
	profile attribute.
	Description: Text giving an overview of the application profile and		Description: Text giving an overview of the application profile and
	the context it is developed for.		the context it is developed for.
	CBOR Value: CBOR abbreviation for the name of this application		CBOR Value: CBOR abbreviation for the name of this application
	profile. These values MUST be unique. The value can be a		profile. These values MUST be unique. The value can be a
	positive integer or a negative integer. Different ranges of		positive integer or a negative integer. Different ranges of
	values use different registration policies [RFC8126]. Integer		values use different registration policies [RFC8126]. Integer
	values from -256 to 255 are designated as "Standards Action With		values from -256 to 255 are designated as "Standards Action With
	Expert Review". Integer values from -65536 to -257 and from 256		Expert Review". Integer values from -65536 to -257 and from 256
	to 65535 are designated as "Specification Required". Integer		to 65535 are designated as "Specification Required". Integer
	values greater than 65535 are designated as "Expert Review".		values greater than 65535 are designated as "Expert Review".
	Integer values less than -65536 are marked as "Private Use".		Integer values less than -65536 are marked as "Private Use".
	Reference: This contains a pointer to the public specification of		Reference: This field contains a pointer to the public specification
	the abbreviation for this application profile, if one exists.		for this application profile, if one exists.
	This registry has been initially populated with the value in Table 2.		This registry has been initially populated with the value in Table 2.
	11.10. ACE Groupcomm Policies		11.10. ACE Groupcomm Policies
	This specification establishes the "ACE Groupcomm Policies" IANA		This specification establishes the "ACE Groupcomm Policies" IANA
	registry within the "Authentication and Authorization for Constrained		registry within the "Authentication and Authorization for Constrained
	Environments (ACE)" registry group.		Environments (ACE)" registry group.
	Values in this registry are covered by different registration		Values in this registry are covered by different registration
	skipping to change at line 4704 ¶		skipping to change at line 4825 ¶
	"Expert Review". Integer values less than -65536 are marked as		"Expert Review". Integer values less than -65536 are marked as
	"Private Use".		"Private Use".
	CBOR Type: The CBOR type used to encode the value of this group		CBOR Type: The CBOR type used to encode the value of this group
	communication policy.		communication policy.
	Description: This field contains a brief description for this group		Description: This field contains a brief description for this group
	communication policy.		communication policy.
	Reference: This field contains a pointer to the public specification		Reference: This field contains a pointer to the public specification
	providing the format of the group communication policy, if one		for this group communication policy and its format, if one exists.
	exists.
	This registry has been initially populated with the values in		This registry has been initially populated with the values in
	Table 3.		Table 3.
	11.11. Sequence Number Synchronization Methods		11.11. Sequence Number Synchronization Methods
	This specification establishes the "Sequence Number Synchronization		This specification establishes the "Sequence Number Synchronization
	Methods" IANA registry within the "Authentication and Authorization		Methods" IANA registry within the "Authentication and Authorization
	for Constrained Environments (ACE)" registry group.		for Constrained Environments (ACE)" registry group.
	skipping to change at line 4823 ¶		skipping to change at line 4943 ¶
	Expert Reviewers should take into consideration the following points:		Expert Reviewers should take into consideration the following points:
	* Point squatting should be discouraged. Reviewers are encouraged		* Point squatting should be discouraged. Reviewers are encouraged
	to get sufficient information for registration requests to ensure		to get sufficient information for registration requests to ensure
	that the usage is not going to duplicate one that is already		that the usage is not going to duplicate one that is already
	registered and that the point is likely to be used in deployments.		registered and that the point is likely to be used in deployments.
	The zones tagged as "Private Use" are intended for testing		The zones tagged as "Private Use" are intended for testing
	purposes and closed environments; code points in other ranges		purposes and closed environments; code points in other ranges
	should not be assigned for testing.		should not be assigned for testing.
	* Specifications are required for the standards track range of point		* Specifications are required for the Standards Track range of point
	assignment. Specifications should exist for Specification		assignment. Specifications should exist for Specification
	Required ranges, but early assignment before a specification is		Required ranges, but early assignment before a specification is
	available is considered to be permissible. When specifications		available is considered to be permissible. When specifications
	are not provided, the description provided needs to have		are not provided, the description provided needs to have
	sufficient information to identify what the point is being used		sufficient information to identify what the point is being used
	for.		for.
	* Experts should take into account the expected usage of fields when		* Experts should take into account the expected usage of fields when
	approving point assignments. The fact that there is a range for		approving point assignments. The fact that there is a range for
	Standards Track documents does not mean that a Standards Track		Standards Track documents does not mean that a Standards Track
	skipping to change at line 5079 ¶		skipping to change at line 5199 ¶
	DOI 10.17487/RFC9431, July 2023,		DOI 10.17487/RFC9431, July 2023,
	<https://www.rfc-editor.org/info/rfc9431>.		<https://www.rfc-editor.org/info/rfc9431>.
	Appendix A. Requirements for Application Profiles		Appendix A. Requirements for Application Profiles
	This section lists the requirements for application profiles of this		This section lists the requirements for application profiles of this
	specification for the convenience of application profile designers.		specification for the convenience of application profile designers.
	A.1. Mandatory-to-Address Requirements		A.1. Mandatory-to-Address Requirements
	REQ1: Specify the format and encoding of 'scope'. This includes		REQ1: Specify the format and encoding of scope. This includes
	defining the set of possible roles and their identifiers, as		defining the set of possible roles and their identifiers, as
	well as the corresponding encoding to use in the scope		well as the corresponding encoding to use in the scope
	entries according to the used scope format (see Section 3.1).		entries according to the used scope format (see Section 3.1).
	REQ2: If 'scope' uses AIF, register its specific instance of "Toid"		REQ2: If scope uses AIF, register its specific instance of "Toid"
	and "Tperm" as media type parameters and a corresponding		and "Tperm" as media type parameters and a corresponding
	Content-Format, as per the guidelines in [RFC9237].		Content-Format, as per the guidelines in [RFC9237].
	REQ3: If used, specify the acceptable values for 'sign_alg' (see		REQ3: If used, specify the acceptable values for the 'sign_alg'
	Section 3.3).		parameter (see Section 3.3).
	REQ4: If used, specify the acceptable values and structures for		REQ4: If used, specify the acceptable values and structures for the
	'sign_parameters' (see Section 3.3).		'sign_parameters' parameter (see Section 3.3).
	REQ5: If used, specify the acceptable values and structures for		REQ5: If used, specify the acceptable values and structures for the
	'sign_key_parameters' (see Section 3.3).		'sign_key_parameters' parameter (see Section 3.3).
	REQ6: Specify the acceptable formats for authentication credentials		REQ6: Specify the acceptable formats for authentication credentials
	and, if used, the acceptable values for 'cred_fmt' (see		and, if applicable, the acceptable values for the 'cred_fmt'
	Section 3.3).		parameter (see Section 3.3).
	REQ7: If the value of the GROUPNAME URI path and the group name in		REQ7: If the value of the GROUPNAME URI path and the group name in
	the access token scope (gname in Section 3.2) are not		the access token scope ('gname' in Section 3.1) are not
	required to coincide, specify the mechanism to map the		required to coincide, specify the mechanism to map the
	GROUPNAME value in the URI to the group name (see		GROUPNAME value in the URI to the group name (see
	Section 4.1).		Section 4.1).
	REQ8: Define whether the KDC has an authentication credential and		REQ8: Define whether the KDC has an authentication credential as
	if this has to be provided through the 'kdc_cred' parameter		required for the correct group operation and if this has to
	(see Section 4.3.1).		be provided through the 'kdc_cred' parameter (see
			Section 4.3.1).
	REQ9: Specify if any part of the KDC interface as defined in this		REQ9: Specify if any part of the KDC interface as defined in this
	document is not supported by the KDC (see Section 4.1).		document is not supported by the KDC (see Section 4.1).
	REQ10: Register a Resource Type for the group-membership resource,		REQ10: Register a Resource Type for the group-membership resources,
	which is used to discover the correct URL for sending a Join		which is used to discover the correct URL for sending a Join
	Request to the KDC (see Section 4.1).		Request to the KDC (see Section 4.1).
	REQ11: Define what specific actions (e.g., CoAP methods) are allowed		REQ11: Define what specific actions (e.g., CoAP methods) are allowed
	on each resource provided by the KDC interface, depending on		on each resource that are accessible through the KDC
	whether the Client is a current group member; the roles that		interface, depending on whether: the Client is a current
	a Client is authorized to take as per the obtained access		group member; the roles that a Client is authorized to take
	token (see Section 3.1); and the roles that the Client has as		as per the obtained access token (see Section 3.1); and the
	a current group member.		roles that the Client has as a current group member.
	REQ12: Categorize possible newly defined operations for Clients into		REQ12: Categorize possible newly defined operations for Clients into
	primary operations expected to be minimally supported and		primary operations expected to be minimally supported and
	secondary operations and provide accompanying considerations		secondary operations, and provide accompanying considerations
	(see Section 4.1.1).		(see Section 4.1.1).
	REQ13: Specify the encoding of the group identifier (see		REQ13: Specify the encoding of group identifier (see Section 4.2.1).
	Section 4.2.1).
	REQ14: Specify the approaches used to compute and verify the PoP		REQ14: Specify the approaches used to compute and verify the PoP
	evidence to include in 'client_cred_verify' and which of		evidence to include in the 'client_cred_verify' parameter and
	those approaches is used in which case (see Section 4.3.1).		which of those approaches is used in which case (see
			Section 4.3.1).
	REQ15: Specify how the nonce N_S is generated if the token is not		REQ15: Specify how the nonce N_S is generated, if the access token
	provided to the KDC through the Token Transfer Request to the		is not provided to the KDC through the Token Transfer Request
	authz-info endpoint (e.g., if it is used directly to validate		sent to the /authz-info endpoint (e.g., the access token is
	TLS instead).		instead transferred during the establishment of a secure
			communication association).
	REQ16: Define the initial value of the 'num' parameter (see		REQ16: Define the initial value of the version number for the group
	Section 4.3.1).		keying material (see Section 4.3.1).
	REQ17: Specify the format of the 'key' parameter and register a		REQ17: Specify the format of the group keying material that is
	corresponding entry in the "ACE Groupcomm Key Types" IANA		conveyed in the 'key' parameter (see Section 4.3.1).
	registry (see Section 4.3.1).
	REQ18: Specify the acceptable values of the 'gkty' parameter (see		REQ18: Specify the acceptable values of the 'gkty' parameter (see
	Section 4.3.1).		Section 4.3.1). For each of them, register a corresponding
			entry in the "ACE Groupcomm Key Types" IANA registry if such
			an entry does not exist already.
	REQ19: Specify and register the application profile identifier (see		REQ19: Specify and register the application profile identifier (see
	Section 4.3.1).		Section 4.3.1).
	REQ20: If used, specify the format and content of 'group_policies'		REQ20: If used, specify the format, content, and default values of
	and its entries. Specify the policies' default values (see		the entries of the CBOR map to include in the
	Section 4.3.1).		'group_policies' parameter (see Section 4.3.1).
	REQ21: Specify the approaches used to compute and verify the PoP		REQ21: Specify the approaches used to compute and verify the PoP
	evidence to include in 'kdc_cred_verify' and which of those		evidence to include in the 'kdc_cred_verify' parameter and
	approaches is used in which case (see Sections 4.3.1 and		which of those approaches is used in which case (see Sections
	4.5.1). If external signature verifiers are supported,		4.3.1 and 4.5.1). If external signature verifiers are
	specify how those provide a nonce to the KDC to be used for		supported, specify how those provide a nonce to the KDC to be
	computing the PoP evidence (see Section 4.5.1).		used for computing the PoP evidence (see Section 4.5.1).
	REQ22: Specify the communication protocol that the members of the		REQ22: Specify the communication protocol that members of the group
	group must use (e.g., CoAP for group communication).		use to communicate with each other (e.g., CoAP for group
			communication).
	REQ23: Specify the security protocol the group members must use to		REQ23: Specify the security protocol that members of the group use
	protect their communication (e.g., group OSCORE). This must		to protect the group communication (e.g., Group OSCORE).
	provide encryption, integrity, and replay protection.		This must provide encryption, integrity, and replay
			protection.
	REQ24: Specify how the communication is secured between the Client		REQ24: Specify how the communication is secured between the Client
	and KDC. Optionally, specify a transport profile of ACE		and the KDC. Optionally, specify a transport profile of ACE
	[RFC9200] to use between Client and KDC (see		[RFC9200] to use between the Client and the KDC (see
	Section 4.3.1.1).		Section 4.3.1.1).
	REQ25: Specify the format of the identifiers of group members (see		REQ25: Specify the format of the node identifiers of group members
	Sections 4.3.1 and 4.4.1).		(see Sections 4.3.1 and 4.4.1).
	REQ26: Specify policies at the KDC to handle ids that are not		REQ26: Specify policies at the KDC to handle node identifiers that
	included in 'get_creds' (see Section 4.4.1).		are included in the 'get_creds' parameter but are not
			associated with any current group member (see Section 4.4.1).
	REQ27: Specify the format of (newly generated) individual keying		REQ27: Specify the format of (newly generated) individual keying
	material for group members or of the information to derive		material for group members or of the information to derive
	such keying material, as well as the corresponding CBOR label		such keying material, as well as the corresponding CBOR map
	(see Sections 4.8.1 and 4.8.2).		key that has to be registered in the "ACE Groupcomm
			Parameters" registry (see Sections 4.8.1 and 4.8.2).
	REQ28: Specify which CBOR tag is used for identifying the semantics		REQ28: Specify which CBOR tag is used for identifying the semantics
	of binary scopes, or register a new CBOR tag if a suitable		of binary scopes, or register a new CBOR tag if a suitable
	one does not exist already (see Section 7).		one does not exist already (see Section 7).
	REQ29: Categorize newly defined parameters according to the same		REQ29: Categorize newly defined parameters according to the same
	criteria of Section 8.		criteria of Section 8.
	REQ30: Define whether Clients must, should, or may support the		REQ30: Define whether Clients must, should, or may support the
	conditional parameters defined in Section 8 and under which		conditional parameters defined in Section 8 and under which
	circumstances.		circumstances.
	A.2. Optional-to-Address Requirements		A.2. Optional-to-Address Requirements
	OPT1: Optionally, if the textual format of 'scope' is used, specify		OPT1: Optionally, if the textual format of scope is used, specify
	CBOR values to use for abbreviating the role identifiers in		CBOR values to use for abbreviating the role identifiers in
	the group (see Section 3.1).		the group (see Section 3.1).
	OPT2: Optionally, specify the additional parameters used in the		OPT2: Optionally, specify the additional parameters used in the
	exchange of Token Transfer Request and Response (see		exchange of Token Transfer Request and Response (see
	Section 3.3).		Section 3.3).
	OPT3: Optionally, specify the negotiation of parameter values for		OPT3: Optionally, specify the negotiation of parameter values for
	signature algorithm and signature keys if 'sign_info' is not		signature algorithm and signature keys, if the 'sign_info'
	used (see Section 3.3).		parameter is not used (see Section 3.3).
	OPT4: Optionally, specify possible or required payload formats for		OPT4: Optionally, specify possible or required payload formats for
	specific error cases.		specific error cases (see Section 4.1.2).
	OPT5: Optionally, specify additional identifiers of error types as		OPT5: Optionally, specify additional identifiers of error types as
	values of the 'error-id' field within the Custom Problem		values of the 'error-id' field within the Custom Problem
	Detail entry 'ace-groupcomm-error' (see Section 4.1.2).		Detail entry 'ace-groupcomm-error' (see Section 4.1.2).
	OPT6: Optionally, specify the encoding of 'creds_repo' if the		OPT6: Optionally, specify the encoding of the 'creds_repo'
	default is not used (see Section 4.3.1).		parameter if the default one is not used (see Section 4.3.1).
	OPT7: Optionally, specify the functionalities implemented at the		OPT7: Optionally, specify the functionalities implemented at the
	'control_uri' resource hosted at the Client, including		resource hosted by the Client at the URI indicated in the
	message exchange encoding and other details (see		'control_uri' parameter, including the encoding of exchanged
	Section 4.3.1).		messages and other details (see Section 4.3.1).
	OPT8: Optionally, specify the behavior of the handler in case of		OPT8: Optionally, specify the behavior of the POST handler of
	failure to retrieve an authentication credential for the		group-membership resources, for the case when it fails to
	specific node (see Section 4.3.1).		retrieve an authentication credential for the specific Client
			(see Section 4.3.1).
	OPT9: Optionally, define a default group rekeying scheme to refer		OPT9: Optionally, define a default group rekeying scheme to refer
	to in case the 'rekeying_scheme' parameter is not included in		to in case the 'rekeying_scheme' parameter is not included in
	the Join Response (see Section 4.3.1).		the Join Response (see Section 4.3.1).
	OPT10: Optionally, specify the functionalities implemented at the		OPT10: Optionally, specify the functionalities implemented at the
	'control_group_uri' resource hosted at the Client, including		resource hosted by the Client at the URI indicated in the
	message exchange encoding and other details (see		'control_group_uri' parameter, including the encoding of
	Section 4.3.1).		exchanged messages and other details (see Section 4.3.1).
	OPT11: Optionally, specify policies that instruct Clients to retain		OPT11: Optionally, specify policies that instruct Clients to retain
	messages and for how long if they are unsuccessfully		messages and for how long, if those are unsuccessfully
	decrypted (see Section 4.8.1.1). This makes it possible to		decrypted (see Section 4.8.1.1). This makes it possible for
	decrypt such messages after getting updated keying material.		Clients to decrypt such messages after obtaining updated
			keying material.
	OPT12: Optionally, specify for the KDC to perform group rekeying		OPT12: Optionally, specify for the KDC to perform group rekeying
	(together or instead of renewing individual keying material)		when receiving a Key Renewal Request, together with or
	when receiving a Key Renewal Request (see Section 4.8.2.1).		instead of renewing individual keying material (see
			Section 4.8.2.1).
	OPT13: Optionally, specify how the identifier of a group member's		OPT13: Optionally, specify how the identifier of a group member's
	authentication credential is included in requests sent to		authentication credential is included in requests sent to
	other group members (see Section 4.9.1.1).		other group members (see Section 4.9.1.1).
	OPT14: Optionally, specify additional information to include in		OPT14: Optionally, specify additional information to include in
	rekeying messages for the "Point-to-Point" group rekeying		rekeying messages for the "Point-to-Point" group rekeying
	scheme (see Section 6).		scheme (see Section 6).
	Appendix B. Extensibility for Future COSE Algorithms		Appendix B. Extensibility for Future COSE Algorithms
End of changes. 266 change blocks.
	717 lines changed or deleted		847 lines changed or added
This html diff was produced by rfcdiff 1.48.