]> RISE AB

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

RISE AB

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

Hollandstr. 12/4 Vienna 1020 Austria christian@amsuess.com

Ericsson AB

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

WIT CoRE Working Group Internet-Draft The Constrained Application Protocol (CoAP) allows clients to "observe" resources at a server and to receive notifications as unicast responses upon changes of the resource state. In some use cases, such as those based on publish-subscribe, it would be convenient for the server to send a single notification addressed to all the clients observing the same target resource. This document updates RFC7252 and RFC7641, and it defines how a server sends observe notifications as response messages over multicast, synchronizing all the observers of the same resource on the same shared Token value. Besides, this document defines how the security protocol Group Object Security for Constrained RESTful Environments (Group OSCORE) can be used to protect multicast notifications end-to-end between the server and the observer clients. Discussion Venues Discussion of this document takes place on the Constrained RESTful Environments Working Group mailing list (core@ietf.org), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction The Constrained Application Protocol (CoAP) has been extended with a number of mechanisms, including resource Observation . This enables CoAP clients to register at a CoAP server as "observers" of a resource, and hence to be automatically notified with an unsolicited response upon changes of the resource state. CoAP supports group communication , e.g., over IP multicast. This includes support for Observe registration requests over multicast, in order for clients to efficiently register as observers of a resource hosted at multiple servers. However, in a number of use cases, using multicast messages for responses would also be desirable. That is, it would be useful that a server sends observe notifications for the same target resource to multiple observers as responses over IP multicast. For instance, in the publish-subscribe architecture for CoAP , multiple clients can subscribe to a topic, by observing the related resource hosted at the responsible broker. When new data is published on that topic, it would be convenient for the broker to send a single multicast notification at once, addressed to all the subscriber clients observing the resource related to that topic. A different use case concerns clients observing the same registration resource at the CoRE Resource Directory . For example, multiple clients can benefit from observation for discovering (to-be-created) groups that use the security protocol Group Object Security for Constrained RESTful Environments (Group OSCORE) , by retrieving from the Resource Directory updated links and descriptions to join those groups through the respective Group Manager . More in general, multicast notifications would be beneficial whenever several CoAP clients observe the same target resource at a CoAP server, and thus they could all be notified at once by means of a single response message. However, CoAP does not originally define response messages addressed to multiple clients, e.g., over IP multicast. This document fills this gap and provides the following twofold contribution. First, it updates and , by defining a method to deliver observe notifications as CoAP responses addressed to multiple clients, e.g., over IP multicast. In particular, the group of potential observers entrusts the server to manage the Token space for multicast notifications. Building on that, the server provides all the observers of a target resource with the same Token value to bind to their own observation, by sending a unicast informative response to each observer client. That Token value is then used in every multicast notification for the target resource under that observation. Second, this document defines how to use Group OSCORE to protect multicast notifications end-to-end between the server and the observer clients. This is also achieved by means of the unicast informative response mentioned above, which additionally includes parameter values used by the server to protect every multicast notification for the target resource by using Group OSCORE. This provides a secure binding between each of such notifications and the observation of each of the clients.

Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. Readers are expected to be familiar with terms and concepts described in CoAP , group communication for CoAP , Observe , Concise Data Definition Language (CDDL) , Concise Binary Object Representation (CBOR) , Object Security for Constrained RESTful Environments (OSCORE) , Group OSCORE , and Constrained Resource Identifiers (CRIs) . This document additionally defines the following terminology.

• Traditional observation: a resource observation associated with a single observer client, as defined in .
• Group observation: a resource observation associated with a group of clients. The server sends notifications for the group-observed resource over IP multicast to all the observer clients.
• Phantom request: the CoAP request message that the server would have received to start a group observation on one of its resources. A phantom request is generated inside the server and does not hit the wire.
• Informative response: a CoAP response message that the server sends to a given client via unicast, providing the client with information on a group observation.

Prerequisites In order to use multicast notifications as defined in this document, the following prerequisites have to be fulfilled.

• The server and the clients need to be on a network where multicast notifications can reach a sufficiently large portion of the clients. This document focuses on a network setup where the clients are capable of listening to multicast traffic and can directly receive multicast notifications. Alternative network setups may leverage intermediaries such as proxies, e.g., in order to accommodate clients that are not able to directly listen to multicast traffic. How the method specified in this document can be used in such setups is discussed in .
• The server needs to be provisioned with multicast addresses whose Token space is placed under its control. On general purpose networks, unmanaged multicast addresses such as "All CoAP Nodes" (see ) are not suitable for this purpose.
• The server and the clients need to agree out-of-band that multicast notifications may be used. This document does not describe a way for a client to influence the server's decision to start group observations and thus to use multicast notifications. This is done on purpose. That is, the method specified in this document is expected to be used in situations where sending individual notifications is not feasible, or is not preferred beyond a certain number of clients observing a target resource. If applications arise where a negotiation between the clients and the server does make sense, those applications are welcome to specify additional means for clients to opt in for receiving multicast notifications.

High-Level Overview of Available Variants The method defined in this document fundamentally enables a server to set up a group observation. This is associated with a phantom observation request that is generated by the server and to which the multicast notifications of the group observation are bound. Consistent with the scope of this document, the following assumes a network setup where the clients participating in the group observation are capable of listening to multicast traffic. In such a setup, the clients directly receive multicast notifications from the server. Alternative network setups that rely on intermediaries such as proxies are discussed in . While the server can provide the phantom request in question to the interested clients as they reach out for registering to the group observation, the server may alternatively distribute the phantom request in advance by alternative means (e.g., see ). Clients that have already retrieved the phantom request can immediately start listening to multicast notifications. The rest of this section provides an overview of the available variants to enforce a group observation, which differ as to whether exchanged messages are protected end-to-end between the observer clients and the server.

• Variant without end-to-end security - Messages pertaining to the group observation are not protected. This basic case is defined in and from the server and the client side, respectively. An example is provided in .
• Variant with end-to-end security - Messages pertaining to the group observation are protected end-to-end between the clients and the server, by using the security protocol Group OSCORE . This case is defined in . An example is provided in . If the participating endpoints using Group OSCORE also support the concept of Deterministic Client , then the possible early distribution of the phantom request can specifically make available its smaller, plain version. Consequently, all the clients are able to compute the same protected phantom request to use (see ).

Server-Side Requirements The server can, at any time, start a group observation on one of its resources. Practically, the server may want to do that under the following circumstances:

• In the absence of observations for the target resource, the server receives a registration request from a first client wishing to start a traditional observation on that resource.
• When a certain number of traditional observations has been established on the target resource, the server decides to make the corresponding observer clients part of a group observation on that resource.

The server maintains an observer counter for each group observation to a target resource, as a rough estimation of the observers actively taking part in the group observation. The server initializes the counter to 0 when starting the group observation and increments it after a new client starts taking part in that group observation. The server is expected to keep the counter up-to-date over time, for instance by using the method described in . This allows the server to possibly terminate a group observation if, at some point in time, not enough clients are estimated to be still active and interested.

Request Assuming that the server is reachable at the address SRV_ADDR and port number SRV_PORT, the server starts a group observation on one of its resources as defined below. The server intends to send multicast notifications for the target resource to the multicast IP address GRP_ADDR and port number GRP_PORT.

1. The server builds a phantom observation request, i.e., a GET request with an Observe Option set to 0 (register).
2. The server selects an available value T, from the Token space of a CoAP endpoint used for messages that have:
   • As source address and port number, the IP multicast address GRP_ADDR and port number GRP_PORT.
   • As destination address and port number, the server address SRV_ADDR and port number SRV_PORT, intended for accessing the target resource.
   This Token space is under exclusive control of the server.
3. The server processes the phantom observation request above, without transmitting it on the wire. The request is addressed to the resource for which the server wants to start the group observation, as if it was sent by the group of observers, i.e., with GRP_ADDR as source address and GRP_PORT as source port.
4. Upon processing the self-generated phantom registration request, the server interprets it as an Observe registration request from the group of potential observer clients. In particular, from then on, the server MUST use T as its own local Token value associated with that observation, with respect to the (previous hop towards the) clients.
5. The server does not immediately respond to the phantom observation request with a multicast notification sent on the wire. The server stores the phantom observation request as is, throughout the lifetime of the group observation.
6. The server builds a CoAP response message INIT_NOTIF as the initial multicast notification for the target resource, in response to the phantom observation request. This message is formatted like other multicast notifications (see ) and MUST include the current representation of the target resource as its payload. The server stores the message INIT_NOTIF and does not transmit it. The server considers this message as the latest multicast notification for the target resource, until it transmits a new multicast notification for that resource as a CoAP message on the wire, after which the server deletes the message INIT_NOTIF.

Informative Response After having started a group observation on a target resource, the server proceeds as follows. For each traditional observation ongoing on the target resource, the server MAY cancel that observation. Then, the server considers the corresponding clients as now taking part in the group observation, for which it increases the corresponding observer counter accordingly. The server sends to each of such clients an informative response message, encoded as a unicast response with response code 5.03 (Service Unavailable). As per , such a response does not include an Observe Option. The response MUST be a Confirmable message sent as a separate response (see ), MUST NOT have link-local source or destination addresses, and MUST NOT provide link-local or site-local addresses in the transport-specific information specified in its payload (see below). The Content-Format of the informative response is set to "application/informative-response+cbor", which is registered in . The payload of the informative response is a CBOR map, whose fields use the CBOR abbreviations that are defined in . When using the method specified in this document, the CBOR map conveyed as the payload of the informative response includes the following parameters with the semantics defined below. Other specifications may define different uses of the informative response for providing alternative information that is relevant to other protocols and applications.

• 'tp_info', with value a CBOR array. This includes the transport-specific information required to correctly receive multicast notifications that are bound to the phantom observation request. Typically, this comprises the Token value associated with the group observation, as well as the source and destination addressing information of the related multicast notifications. The CBOR array is formatted as defined in . This parameter MUST be included.
• 'ph_req', with value the byte serialization of the transport-independent information of the phantom observation request (see ), encoded as a CBOR byte string. The value of the CBOR byte string is formatted as defined in . This parameter MAY be omitted if the phantom request is, in terms of transport-independent information, identical to the registration request from the client. Otherwise, this parameter MUST be included. Note that the registration request from the client may indeed differ from the phantom observation request in terms of transport-independent information, but still be acceptable for the server to register the client as taking part in the group observation.
• 'last_notif', with value the byte serialization of the transport-independent information of the latest multicast notification for the target resource, encoded as a CBOR byte string. The value of the CBOR byte string is formatted as defined in . This parameter MAY be included.
• 'next_not_before', with value the number of seconds that will minimally elapse before the server sends the next multicast notification for the group observation of the target resource, encoded as a CBOR unsigned integer. This parameter MAY be included. This information can help a new client to align itself with the server's timeline, especially in scenarios where multicast notifications are regularly sent. Also, it can help synchronizing different clients when orchestrating content distribution through multicast notifications.
• 'ending', with value the time when the group observation of the target resource is planned to be canceled, encoded as a CBOR integer or as a CBOR floating-point number. The value is the number of seconds from 1970-01-01T00:00:00Z UTC until the specified UTC date/time, ignoring leap seconds, analogous to what is specified for NumericDate in . This parameter MAY be included.

The CDDL notation provided below describes the payload of the informative response.

Format of the Informative Response Payload array, ; 'tp_info' (transport-specific information) ? 1 => bstr, ; 'ph_req' (transport-independent information) ? 2 => bstr, ; 'last_notif' (transport-independent information) ? 3 => uint, ; 'next_not_before' ? 4 => ~time ; 'ending' } ]]>

Upon receiving a registration request to observe the target resource, the server does not create a corresponding individual observation for the requesting client. Instead, the server considers that client as now taking part in the group observation of the target resource, of which it increments the observer counter by 1. Then, the server replies to the client with the same informative response message defined above, which MUST be a Confirmable message sent as a separate response (see ). Note that this also applies when, with no ongoing traditional observations on the target resource, the server receives a registration request from a first client and decides to start a group observation on the target resource.

Transport-Specific Message Information The CBOR array specified in the 'tp_info' parameter of an informative response is formatted according to the following CDDL notation.

General Format of 'tp_info'

The following holds for the two elements 'tpi_server' and 'tpi_details'.

• The 'tpi_server' element MUST be present and specifies:
  • The transport protocol used to transport a CoAP response from the server, i.e., a multicast notification in this document; and
  • The addressing information of the server, i.e., the source addressing information of the multicast notifications that are sent for the group observation. Such addressing information MUST be equal to the source addressing information of the informative response sent by the server (see ).
  This element specifies a CRI , of which both 'scheme' and 'authority' are given, while 'path', 'query', and 'fragment' are not given. Consistent with , the CRI scheme is given as a negative integer 'scheme-id'. In particular, a 'scheme-id' with value ID denotes the CRI scheme that has CRI scheme number equal to (-1 - ID). The latter identifies the corresponding registered URI scheme, per the associated entry in the "Uniform Resource Identifier (URI) Schemes" registry defined in and updated in . The combination of URI scheme and 'authority' component determines the CoAP transport used to distribute multicast notifications for the group observation. Note that:
  • If the 'authority' component specifies a host-ip, then the 'scheme-id' (hence the URI scheme) is sufficient to identify the transport.
  • If the 'authority' component specifies a host-name, then the consumer of the CRI has to resolve the host-name and consider the result together with the 'scheme-id' (hence the URI scheme) in order to identify the transport. For instance, DNS resolution can be used (e.g., as defined in ).
  The identified transport determines what elements are required in the 'tpi_details' element of the 'tp_info' array, as well as what information they convey, their encoding, and their semantics. Those elements are specified in the 'Transport Information Details' column of the "CoAP Transport Information" registry for the entry associated with the identified CoAP transport (see )
• The 'tpi_details' element MAY be present and specifies transport-specific information related to a pertinent request message, i.e., the phantom observation request in this document. The exact format of 'tpi_details' depends on the CoAP transport, which is identified according to the CRI conveyed by the 'tpi_server' element, as described above. In the "CoAP Transport Information" registry defined in of this document, the entry corresponding to the identified CoAP transport specifies the list of elements composing 'tpi_details' for that transport, as indicated in the 'Transport Information Details' column. Within 'tpi_details', its elements MUST be ordered according to what is specified in the 'Transport Information Details' column of the "CoAP Transport Information" registry.

defines an entry to be registered in the "CoAP Transport Information" registry, for the transport "CoAP over UDP". When such a transport is used, i.e., CoAP responses are transported over UDP as per and , the full encoding of the 'tp_info' CBOR array is as defined in . If a future specification defines the use of CoAP multicast notifications transported over different transport protocols, then that specification must perform the following actions, unless those have been already performed for different reasons:

• Define the elements in 'tpi_details', as to what information they convey, their encoding, and their semantics.
• Register an entry in the "CoAP Transport Information" registry defined in of this document.
• Register an entry in the "Uniform Resource Identifier (URI) Schemes" registry defined in and updated in , where the value in the 'CRI Scheme Number' column is (-1 - ID). In particular, ID is the negative integer to be used as 'scheme-id' for CRIs conveyed by the 'tpi_server' element and by elements in 'tpi_details'.

UDP Transport-Specific Information When CoAP multicast notifications are transported over UDP as per and , the server specifies the 'tp_info' CBOR array as follows.

• In the 'tpi_server' element, the CRI has 'scheme-id' with value -1 ("coap"), while 'authority' conveys addressing information of the server, i.e., the source addressing information of the multicast notifications that are sent for the group observation. This information consists of the IP address SRV_ADDR (expressed as a literal or as a host-name to be resolved) and the port number SRV_PORT of the server hosting the target resource, from where the server will send multicast notifications for the target resource.
• The 'tpi_details' element MUST be present and in turn includes the following two elements:
  • 'tpi_client' is a CRI, with the same format of 'tpi_server' (see ). In particular, the CRI has 'scheme-id' with value -1 ("coap"), while 'authority' conveys the destination addressing information of the multicast notifications that the server sends for the group observation. This information consists of the IP multicast address GRP_ADDR (expressed as a literal or as a host-name to be resolved) and the port number GRP_PORT, where the server will send multicast notifications for the target resource.
  • 'tpi_token' is a CBOR byte string, whose value is the Token value of the phantom observation request generated by the server (see ). Note that the same Token value is used for the multicast notifications bound to that phantom observation request (see ).

The CDDL notation in describes the format of the 'tp_info' CBOR array when CoAP is transported over UDP.

Format of 'tp_info' with UDP as Transport Protocol

The CBOR diagnostic notation in provides an example of the 'tp_info' CBOR array when CoAP is transported over UDP. In the example, SRV_ADDR is 2001:db8::ab, SRV_PORT is 5683 (omitted in the CRI of 'tpi_server' as it is the default port number when CoAP is transported over UDP), GRP_ADDR is ff35:30:2001:db8::23, and GRP_PORT is 61616.

Example of 'tp_info' with UDP as Transport Protocol

Transport-Independent Message Information For both the parameters 'ph_req' and 'last_notif' in the informative response, the value of the CBOR byte string is the concatenation of the following components, in the order specified below. When defining the value of each component, "CoAP message" refers to the phantom observation request for the 'ph_req' parameter and to the corresponding latest multicast notification for the 'last_notif' parameter.

• A single byte, with value the content of the Code field in the CoAP message.
• The byte serialization of the complete sequence of CoAP options in the CoAP message.
• If the CoAP message includes a non-zero length payload, the one-byte Payload Marker (0xff) followed by the payload.

Notifications Upon a change in the status of the target resource under group observation, the server sends a multicast notification intended to all the clients taking part in the group observation of that resource. In particular, each such multicast notification is formatted as follows.

• It MUST be a Non-confirmable message.
• It MUST include an Observe Option, as per .
• It MUST have the same Token value T of the phantom registration request that started the group observation. That is, every multicast notification for a target resource is not bound to the observation requests from the different clients, but instead to the phantom registration request associated with the whole set of clients taking part in the group observation of that resource. The Token value T is specified by an element of 'tpi_details' within the 'tp_info' parameter, in the informative response sent to the observer clients. In particular, when transporting CoAP over UDP, the Token value is specified by the element 'tpi_token' (see ).
• It MUST be sent from the same IP address SRV_ADDR and port number SRV_PORT where the corresponding informative responses are sent from by the server (see ). That is, redirection MUST NOT be used. Note that, in most cases, such SRV_ADDR and SRV_PORT are those to which original observation requests are sent to by clients (see ), unless those requests are sent to a multicast address (see ). The addressing information above is provided to the observer clients through the CRI specified by the element 'tpi_server' within the 'tp_info' parameter, in the informative response (see ).
• It MUST be sent to the IP multicast address GRP_ADDR and port number GRP_PORT. The addressing information above is provided to the observer clients through the CRI specified by an element of 'tpi_details' within the 'tp_info' parameter, in the informative response. In particular, when transporting CoAP over UDP, the CRI is conveyed by the element 'tpi_client' (see ).

For each target resource with an active group observation, the server MUST store the latest multicast notification.

Congestion Control In order to not cause congestion, the server ought to conservatively control the sending of multicast notifications. In particular:

• The multicast notifications MUST be Non-confirmable messages.
• In constrained environments such as low-power, lossy networks (LLNs), the server SHOULD only support multicast notifications for resources whose representation is small in size. Following related guidelines from , this can consist, for example, in having the payload of multicast notifications as limited to approximately 5% of the IP Maximum Transmit Unit (MTU) size, so that it fits into a single link-layer frame when using IPv6 over Low-Power Wireless Personal Area Networks (6LoWPAN) (see ).
• The server SHOULD provide multicast notifications with the smallest possible IP multicast scope that fulfills the application needs. For example, following related guidelines from , site-local scope is always preferred over global scope IP multicast, if this fulfills the application needs. Similarly, realm-local scope is always preferred over site-local scope, if this fulfills the application needs. Ultimately, it is up to the server administrator to explicitly configure the most appropriate IP multicast scope.
• Following related guidelines from , the server SHOULD NOT send more than one multicast notification every 3 seconds and SHOULD use an even less aggressive rate when possible (see also ). Furthermore, a goal for an appropriate transmission rate of multicast notifications is the avoidance of a possible "broadcast storm" problem . This prevents a following considerable increase of the channel load, whose origin would be likely attributed to a router rather than to the server.

Cancellation At a certain point in time, the server might want to cancel a group observation of a target resource. For instance, the server realizes that no clients or not enough clients are interested in taking part in the group observation anymore. defines a possible approach that the server can use to make an assessment in this respect. Another reason is that the group observation has reached its ending time, as originally scheduled by the server. In order to cancel the group observation, the server sends a multicast response with response code 5.03 (Service Unavailable), signaling that the group observation has been terminated. The response has the same Token value T of the phantom registration request, it has no payload, and it does not include an Observe Option. The server sends the response to the same multicast IP address GRP_ADDR and port number GRP_PORT used to send the multicast notifications related to the target resource. Finally, the server releases the memory and network resources allocated for the group observation, and it especially frees up the Token value T used at its CoAP endpoint.

Client-Side Requirements

Request A client sends an observation request to the server as described in , i.e., a GET request with an Observe Option set to 0 (register). The request MUST NOT have link-local source or destination addresses. If the server is not configured to accept registrations on that target resource specifically for a group observation, this would still result in a positive notification response to the client as described in , in the case that the server is able and willing to add the client to the list of observers. In a particular setup, the information typically specified in the 'tp_info' parameter of the informative response (see ) can be pre-configured on the server and the clients. For example, the destination multicast address and port number where to send multicast notifications for a group observation, as well as the associated Token value to use, can be set aside for particular tasks (e.g., enforcing observations of a specific resource). Alternative mechanisms can rely on using some bytes from the hash of the observation request as the last bytes of the multicast address or as part of the Token value. In such a particular setup, the client may also have an early knowledge of the phantom request, i.e., it will be possible for the server to safely omit the parameter 'ph_req' from the informative response to the observation request (see ). In this case, the client can include a No-Response Option with value 16 in its Observe registration request, which results in the server suppressing the informative response. As a consequence, the observation request only informs the server that there is one additional client interested to take part in the group observation. While the considered client is able to simply set up its multicast address and start receiving multicast notifications for the group observation, sending an observation request as above allows the server to increment the observer counter. This helps the server to assess the current number of clients interested in the group observation over time (e.g., by using the method defined in ), which in turn can play a role in deciding to cancel the group observation (see ).

Informative Response Upon receiving the informative response defined in , the client has to identify the CoAP transport used to distribute multicast notifications for the group observation. To this end, the client relies on the element 'tpi_server' within the 'tp_info' parameter of the informative response (see ). In particular, the client considers the CRI conveyed by 'tpi_server' and identifies the CoAP transport, by assessing together the 'authority' component and the URI scheme determined from 'scheme-id' (see ). After that, the client parses the remainder of the 'tp_info' array, i.e., the information conveyed by 'tpi_details', according to what is specified in the 'Transport Information Details' column of the "CoAP Transport Information" registry for the entry associated with the identified CoAP transport (see ). Then, the client performs the following steps.

1. The client configures an observation of the target resource. To this end, it relies on a CoAP endpoint used for messages having:
   • As source address and port number, the server address SRV_ADDR and port number SRV_PORT intended for accessing the target resource. These are specified by the CRI conveyed by the element 'tpi_server' within the 'tp_info' parameter, in the informative response (see ). If the port number is not present in the CRI, the client MUST use as SRV_PORT the default port number defined for the identified CoAP transport (e.g., the default port number is 5683 when the transport is CoAP over UDP).
   • As destination address and port number, the IP multicast address GRP_ADDR and port number GRP_PORT. These are specified by the CRI conveyed by a dedicated element of 'tpi_details' within the 'tp_info' parameter, in the informative response. In particular, when transporting CoAP over UDP, the CRI is conveyed by the element 'tpi_client' (see ). If the port number is not present in the CRI, the client MUST use as GRP_PORT the default port number defined for the identified CoAP transport (e.g., the default port number is 5683 when the transport is CoAP over UDP).
2. The client rebuilds the phantom registration request as follows.
   • The client uses the Token value T that is specified by a dedicated element of 'tpi_details' within the 'tp_info' parameter, in the informative response. In particular, when transporting CoAP over UDP, the Token value is specified by the element 'tpi_token' (see ).
   • If the 'ph_req' parameter is not present in the informative response, the client uses the transport-independent information from its original Observe registration request.
   • If the 'ph_req' parameter is present in the informative response, the client uses the transport-independent information specified in the parameter.
3. If the informative response includes the parameter 'ph_req' and the transport-independent information specified therein differs from the one in the original Observe registration request, then the client checks whether a response to the rebuilt phantom request can, if available in a cache entry, be used to satisfy the original observation request. If this is not the case, the client SHOULD explicitly withdraw from the group observation.
4. The client stores the phantom registration request, as associated with the observation of the target resource. In particular, the client MUST use the Token value T of this phantom registration request as its own local Token value associated with that group observation, with respect to the server. The particular way to achieve this is implementation specific.
5. If the informative response includes the parameter 'last_notif', the client rebuilds the latest multicast notification, by using:
   • The same Token value T used at Step 2; and
   • The transport-independent information specified in the 'last_notif' parameter of the informative response.
6. If the informative response includes the parameter 'last_notif', the client processes the multicast notification rebuilt at Step 5 as defined in . In particular, the value of the Observe Option is used as initial baseline for notification reordering in this group observation.
7. If a traditional observation to the target resource is ongoing, the client MAY silently cancel it without notifying the server.

In addition to 'tpi_server', further elements of the 'tp_info' array can convey a CRI. The client MUST treat any CRI within the 'tp_info' array as invalid, if the 'authority' component is a host-name such that, when resolved, its combination with the URI scheme indicates multiple transports (see ). As a possible way to verify if that is the case, the client can rely on DNS resolution (e.g., as defined in ). If any of the expected fields in the informative response are absent, malformed, or invalid, the client MAY try sending a new registration request to the server (see ). If the client chooses not to, then the client SHOULD explicitly withdraw from the group observation. describes possible alternative ways for clients to retrieve the phantom registration request and other information related to a group observation.

Notifications After having successfully processed the informative response as defined in , the client will receive, accept, and process multicast notifications about the state of the target resource from the server, as responses to the phantom registration request and with Token value T. The client relies on the value of the Observe Option for notification reordering, as defined in .

Cancellation At a certain point in time, a client may no longer be interested in receiving further multicast notifications about a target resource. When this happens, the client can simply "forget" about being part of the group observation for that target resource, as per . When, later on, the server sends the next multicast notification, the client will not recognize the Token value T in the message. Since the multicast notification is a Non-confirmable message, it is optional for the client to reject it with a Reset message (see ). If the server has canceled a group observation as defined in , the client simply forgets about the group observation and frees up the used Token value T for that endpoint, upon receiving the multicast error response defined in .

Web Linking The possible use of multicast notifications in a group observation MAY be indicated by a target attribute "gp-obs" in a web link to a resource, e.g., using a link-format document . The "gp-obs" attribute is a hint, indicating that the server might send multicast notifications for observations of the resource targeted by the link. Note that this is simply a hint, i.e., it does not include any information required to participate in a group observation and to receive and process multicast notifications. A value MUST NOT be given for the "gp-obs" attribute and any present value MUST be ignored by the recipient. The "gp-obs" attribute MUST NOT appear more than once in a given link-value; occurrences after the first MUST be ignored by the recipient. The example in shows a use of the "gp-obs" attribute: the client does resource discovery on a server and gets back a list of resources, one of which includes the "gp-obs" attribute indicating that the server might send multicast notifications for observations of that resource. The CoRE Link-Format notation from is used.

The Web Link ;gp-obs, ;if="sensor" ]]>

Example The following example refers to two clients C1 and C2 that register to observe a resource /r at a server S, which has address SRV_ADDR and listens to the port number SRV_PORT. Before the following exchanges occur, no clients are observing the resource /r , which has value "1234". The server S sends multicast notifications to the IP multicast address GRP_ADDR and port number GRP_PORT. The server starts the group observation upon receiving a registration request from a first client that wishes to start a traditional observation on the resource /r. The following notation is used for the payload of the informative responses:

• The application-extension identifier "cri" defined in is used to notate a CBOR Extended Diagnostic Notation (EDN) literal for a CRI.
• 'bstr(X)' denotes a CBOR byte string with value the byte serialization of X, with '|' denoting byte concatenation.
• 'OPT' denotes a sequence of CoAP options. This refers to the phantom registration request encoded by the 'ph_req' parameter, or to the corresponding latest multicast notification encoded by the 'last_notif' parameter.
• 'PAYLOAD' denotes a CoAP payload. This refers to the latest multicast notification encoded by the 'last_notif' parameter.

Example of Group Observation S /r | GET | | Token: 0x4a | | Observe: 0 (register) | | Uri-Path: "r" | | | | | | ( S allocates the available Token value 0x7b ) | | | | ( S sends to itself a phantom observation request PH_REQ | | as coming from the IP multicast address GRP_ADDR ) | | .---------------------------------------------------- | | / | | \ | | `---------------------------------------------------> | /r | GET | | Token: 0x7b | | Observe: 0 (register) | | Uri-Path: "r" | | | | | | ( S creates a group observation of /r ) | | | | ( S increments the observer counter | | for the group observation of /r ) | | | C1 <-------------------- [ Unicast ] ------------------------- S | 5.03 | | Token: 0x4a | | Content-Format: application/informative-response+cbor | | Max-Age: 0 | | | | Payload: { | | / tp_info / 0 : [ | | cri'coap://SRV_ADDR:SRV_PORT/', | | cri'coap://GRP_ADDR:GRP_PORT/', | | 0x7b | | ], | | / last_notif / 2 : bstr(0x45 | OPT | 0xff | PAYLOAD) | | } | | | C2 --------------------- [ Unicast ] ------------------------> S /r | GET | | Token: 0x01 | | Observe: 0 (register) | | Uri-Path: "r" | | | | | | ( S increments the observer counter | | for the group observation of /r ) | | | C2 <-------------------- [ Unicast ] ------------------------- S | 5.03 | | Token: 0x01 | | Content-Format: application/informative-response+cbor | | Max-Age: 0 | | | | Payload: { | | / tp_info / 0 : [ | | cri'coap://SRV_ADDR:SRV_PORT/', | | cri'coap://GRP_ADDR:GRP_PORT/', | | 0x7b | | ], | | / last_notif / 2 : bstr(0x45 | OPT | 0xff | PAYLOAD) | | } | | | | ( The value of the resource /r changes to "5678" ) | | | +--+ | C1 | | | <------------------ [ Multicast ] ----------------------- S C2 | ( Destination address/port: GRP_ADDR/GRP_PORT ) | +--+ | | 2.05 | | Token: 0x7b | | Observe: 11 | | | | Payload: "5678" | | | ]]>

Rough Counting of Clients in the Group Observation This section specifies a method that the server can use to keep an estimate of still active and interested clients, without creating undue traffic on the network.

Feedback-Divider Option This section defines the new CoAP option Feedback-Divider. By including the option in an outgoing message, a sender endpoint elicits a stochastic reaction and thereby a feedback from the message recipient(s) that would otherwise not react. If the sender endpoint triggering a feedback is a client sending a request, the Feedback-Divider Option included in the request triggers the recipient server(s) to send a response with some probability. In particular, the Feedback-Divider Option stochastically overrides the possible response suppression performed by the server(s). Such an influence affects response suppression that can otherwise be performed, e.g., according to: default processing; the No-Response Option , if present in the request; an unmatching filter from the URI query component, when the request is sent over multicast and targets the /.well-known/core resource (see ). If the sender endpoint triggering a feedback is a server sending a response, the feedback elicitation is currently limited to using observe notifications. In particular, the Feedback-Divider Option included in an observe notification triggers the recipient client(s) to send with some probability a new request to the server. Such a request includes the Observe Option set to 0 (register) and is addressed to the same target resource for which the observe notification was sent. That is, a reacting client (re-)registers a regular unicast observation on the same target resource. This document specifically defines how the Feedback-Divider Option is used when the sender endpoint triggering a feedback is a server sending multicast notifications. Note that it is not so useful to include the Feedback-Divider Option in an observe notification sent over unicast to a single client. That is, the server can more efficiently query a single client by means of an observe notification sent as a Confirmable message, thereby eliciting an Acknowledgement message in return. The Feedback-Divider Option has the properties summarized in , which extends Table 4 of . The option is not Critical, not Safe-to-Forward, and integer valued. Since the option is not Safe-to-Forward, the 'N' column indicates a dash for "not applicable". The Feedback-Divider Option. C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable

No.	C	U	N	R	Name	Format	Length	Default
TBD18		x	-		Feedback-Divider	uint	0-1	(none)

Note to RFC Editor: In the table above, please replace TBD18 with the registered option number. Then, please delete this paragraph. The Feedback-Divider Option is of class E for OSCORE .

Processing on the Client Side Upon receiving a response with a Feedback-Divider Option, a client that supports the option and is interested in continuing receiving multicast notifications for the target resource SHOULD acknowledge its interest, as described below. The client picks an integer random number I, from 0 inclusive to Z = (2^Q) exclusive, where Q is the value specified in the option. If I is different from 0, the client takes no further action. Otherwise, the client should wait a random fraction of the Leisure time (see ) and then registers a regular observation on the same target resource. To this end, the client essentially follows the steps that got it originally subscribed to group notifications for the target resource. In particular, the client sends an observation request to the server, i.e., a GET request with an Observe Option set to 0 (register). The request MUST be addressed to the same target resource and MUST have the same destination IP address and port number used for the original registration request, regardless of the source IP address and port number of the received multicast notification. Since this Observe registration is only done for its side effect of looking as an attempted observation at the server, the client MUST send the unicast request as a Non-confirmable message and with the maximum No-Response setting . In the request, the client MUST include a Feedback-Divider Option, whose value MUST be set to 0. As per , this is represented with an empty option value (a zero-length sequence of bytes). The client does not need to wait for responses and can keep processing further notifications on the same Token. The client MUST ignore the Feedback-Divider Option, if the multicast notification is retrieved from the 'last_notif' parameter of an informative response (see ). A client includes the Feedback-Divider Option only in a re-registration request triggered by the server as described above and MUST NOT include it in any other request. and provide a description in pseudo-code of the operations above performed by the client.

Processing on the Server Side In order to avoid needless use of network resources, a server SHOULD keep a rough, updated count of the number of clients taking part in the group observation of a target resource. To this end, the server updates the value COUNT of the associated observer counter (see ), for instance by using the method described below.

Request for Feedback When it wants to obtain a new estimated count, the server considers a number M of confirmations that it would like to receive from the clients. It is up to applications to define policies about how the server determines and possibly adjusts the value of M. Then, the server computes the value Q = max(L, 0), where:

• L is computed as L = ceil(log2(N / M)).
• N is the current value of the observer counter, possibly rounded up to 1, i.e., N = max(COUNT, 1).

Finally, the server sets Q as the value of the Feedback-Divider Option, which is sent within a successful multicast notification. If several multicast notifications are sent in a burst fashion, it is RECOMMENDED for the server to include the Feedback-Divider Option only in the first notification of such a burst.

Collection of Feedback The server collects observation requests from the clients, for an amount of time of MAX_CONFIRMATION_WAIT seconds. During this time, the server regularly increments the observer counter when adding a new client to the group observation (see ). It is up to applications to define the value of MAX_CONFIRMATION_WAIT, which has to take into account the transmission time of the multicast notification and of observation requests, as well as the leisure time of the clients, which may be hard to know or estimate for the server. If this information is not known to the server, it is RECOMMENDED to define MAX_CONFIRMATION_WAIT as follows. MAX_CONFIRMATION_WAIT = MAX_RTT + MAX_CLIENT_REQUEST_DELAY where MAX_RTT is as defined in and has default value 202 seconds, while MAX_CLIENT_REQUEST_DELAY is equivalent to MAX_SERVER_RESPONSE_DELAY defined in and has default value 250 seconds. In the absence of more specific information, the server can thus consider a conservative MAX_CONFIRMATION_WAIT of 452 seconds. If more information is available in deployments, a much shorter MAX_CONFIRMATION_WAIT can be set. This can be based on a realistic round trip time (replacing MAX_RTT) and on the largest leisure time configured on the clients (replacing MAX_CLIENT_REQUEST_DELAY), e.g., DEFAULT_LEISURE = 5 seconds, thus shortening MAX_CONFIRMATION_WAIT to a few seconds.

Processing of Feedback Once MAX_CONFIRMATION_WAIT seconds have passed, the server counts the R confirmations that have arrived as observation requests to the target resource, since the time when the latest multicast notification with the Feedback-Divider Option has been sent. In particular, the server considers an observation request as a confirmation from a client only if the request includes a Feedback-Divider Option with value 0. Then, the server computes a feedback indicator as E = R * (2^Q). According to what is defined by application policies, the server determines the next time when to ask clients for their confirmation, e.g., after a certain number of multicast notifications has been sent. For example, the decision can be influenced by the reception of no confirmations from the clients, i.e., R = 0, or by the value of the ratios (E/N) and (N/E). Finally, the server computes a new estimated count of the observers. To this end, the server first considers COUNT' as the current value of the observer counter at this point in time. Note that COUNT' may be greater than the value COUNT used at the beginning of this process, if the server has incremented the observer counter upon adding new clients to the group observation (see ). In particular, the server computes the new estimated count value as COUNT' + ((E - N) / D), where D > 0 is an integer value used as dampener. This step has to be performed atomically. That is, until this step is completed, the server MUST hold the processing of an observation request for the same target resource from a new client. Finally, the server considers the result as the current observer counter, which can be taken into account for possibly canceling the group observation (see ). This estimate is skewed by packet loss, but it gives the server a sufficiently good estimation for further counts and for deciding when to cancel the group observation. It is up to applications to define policies about how the server takes the newly updated estimate into account and determines whether to cancel the group observation. As an example, if the server currently estimates that N = COUNT = 32 observers are active and considers a constant M = 8, it sends a notification with Feedback-Divider with value Q = 2. Then, out of 18 actually active clients, 5 send a re-registration request based on their random draw, of which one request gets lost, thus leaving 4 re-registration requests received by the server. Also, no new clients have been added to the group observation during this time, i.e., COUNT' is equal to COUNT. As a consequence, assuming that a dampener value D = 1 is used, the server computes the new estimated count value as 32 + (16 - 32) = 16 and keeps the group observation active. To produce a most accurate updated counter, a server can include a Feedback-Divider Option with value Q = 0 in its multicast notifications, as if M is equal to N. This will trigger all the active clients to state their interest in continuing receiving notifications for the target resource. Thus, the amount R of arrived confirmations is affected only by possible packet loss. provides a description in pseudo-code of the operations above performed by the server, including example behaviors for scheduling the next count update and deciding whether to cancel the group observation.

Protection of Multicast Notifications with Group OSCORE A server can protect multicast notifications by using the security protocol Group OSCORE , thus ensuring that they are protected end-to-end for the observer clients. This requires that both the server and the clients interested in receiving multicast notifications from that server are members of the same OSCORE group. In some settings, the OSCORE group to refer to can be pre-configured on the clients and the server. In such a case, a server which is aware of such pre-configuration can simply assume a client to already be a member of the correct OSCORE group. In any other case, the server MAY communicate to clients what OSCORE group they are required to join, by providing additional guidance in the informative response as described in . Note that clients could already be members of the right OSCORE group, if they previously joined it to securely communicate with the same server or with other servers to access their resources. Both the clients and the server MAY join the OSCORE group by using the approach defined in and based on the ACE framework for Authentication and Authorization in constrained environments . When doing so, the server has to join the group (also) with the roles of Requester and Responder. Instead, a client can join the group with any permitted role or combination of roles, unless it intends to send its original observation requests (see ) protected with Group OSCORE. In such a case, the client has to join the group (also) as a Requester. Further details on how to discover the OSCORE group and join it are out of the scope of this document. If multicast notifications are protected using Group OSCORE, then the original registration requests and related unicast (notification) responses MUST also be protected, including and especially the informative responses from the server. An exception is the case discussed in , where the informative response from the server is not protected. In order to protect unicast messages exchanged between the server and each client, including the original client registration (see ), alternative security protocols than Group OSCORE can be used, such as OSCORE and/or DTLS . However, it is RECOMMENDED to use OSCORE or Group OSCORE, in order to reduce the number of libraries that the clients and the server have to support.

Signaling the OSCORE Group in the Informative Response This section describes a mechanism for the server to communicate to the client what OSCORE group to join, in order to decrypt and verify the multicast notifications protected with Group OSCORE. The client MAY use the information provided by the server to start the ACE joining procedure described in . The mechanism defined in this section is OPTIONAL to support for the client and server. In addition to what is defined in , the CBOR map in the informative response payload contains the following fields, whose CBOR abbreviations are defined in .

• 'join_uri', with value the URI for joining the OSCORE group at the respective Group Manager, encoded as a CBOR text string. If the procedure described in is used for joining, this field specifically indicates the URI of the group-membership resource at the Group Manager.
• 'sec_gp', with value the name of the OSCORE group, encoded as a CBOR text string.
• Optionally, 'as_uri', with value the URI of the Authorization Server associated with the Group Manager for the OSCORE group, encoded as a CBOR text string.
• Optionally, 'hkdf', with value the HKDF Algorithm used in the OSCORE group, encoded as a CBOR text string or integer. The HKDF Algorithm is specified by the HMAC Algorithm value, which is taken from the 'Value' column of the "COSE Algorithms" registry . For example, the HKDF Algorithm HKDF SHA-256 is specified as the HMAC Algorithm HMAC 256/256.
• Optionally, 'cred_fmt', with value the format of the authentication credentials used in the OSCORE group, encoded as a CBOR integer. The value is taken from the 'Label' column of the "COSE Header Parameters" Registry . Consistent with , acceptable values denote a format that provides the public key and a comprehensive set of information related to the public key algorithm, including, e.g., the used elliptic curve (when applicable). At the time of writing this specification, acceptable formats of authentication credentials are CBOR Web Tokens (CWTs) and CWT Claim Sets (CCSs) , X.509 certificates , and C509 certificates . Further formats may be available in the future, and they would be acceptable to use as long as they comply with the criteria above. [ As to C509 certificates, there is a pending registration requested by draft-ietf-cose-cbor-encoded-cert. ]
• Optionally, 'gp_enc_alg', with value the Group Encryption Algorithm used in the OSCORE group to encrypt messages protected with the group mode, encoded as a CBOR text string or integer. The value is taken from the 'Value' column of the "COSE Algorithms" registry .
• Optionally, 'sign_alg', with value the Signature Algorithm used to sign messages in the OSCORE group, encoded as a CBOR text string or integer. The value is taken from the 'Value' column of the "COSE Algorithms" registry .
• Optionally, 'sign_params', encoded as a CBOR array and including the following two elements:
  • 'sign_alg_capab': a CBOR array, with the same format and value of the COSE capabilities array for the algorithm indicated in 'sign_alg', as specified for that algorithm in the 'Capabilities' column of the "COSE Algorithms" Registry .
  • 'sign_key_type_capab': a CBOR array, with the same format and value of the COSE capabilities array for the COSE key type of the keys used with the algorithm indicated in 'sign_alg', as specified for that key type in the 'Capabilities' column of the "COSE Key Types" Registry .

The values of 'sign_alg', 'sign_params', and 'cred_fmt' provide an early knowledge of the format of authentication credentials as well as of the type of public keys used in the OSCORE group. Thus, the client does not need to ask the Group Manager for this information as a preliminary step before the (ACE) join process, or to perform a trial-and-error exchange with the Group Manager upon joining the group. Hence, the client is able to provide the Group Manager with its own authentication credential in the correct expected format and including a public key of the correct expected type, at the very first step of the (ACE) join process. The values of 'hkdf', 'gp_enc_alg', and 'sign_alg' provide an early knowledge of the algorithms used in the OSCORE group. Thus, the client is able to decide whether to actually proceed with the (ACE) join process, depending on its support for the indicated algorithms. As mentioned above, since this mechanism is OPTIONAL, all the corresponding fields are OPTIONAL in the informative response. However, the 'join_uri' and 'sec_gp' fields MUST be present if this mechanism is used. If any of the fields are present without the 'join_uri' and 'sec_gp' fields present, the client MUST ignore these fields, since they would not be sufficient to start the (ACE) join procedure. When this happens, the client MAY try sending a new registration request to the server (see ). If the client chooses not to, then the client SHOULD explicitly withdraw from the group observation. describes a possible alternative approach, where the server self-manages the OSCORE group, and provides the observer clients with the necessary keying material in the informative response. The approach in MUST NOT be used together with the mechanism defined in this section for indicating what OSCORE group to join.

Server-Side Requirements When using Group OSCORE to protect multicast notifications, the server performs the operations described in , with the following differences.

Registration The phantom registration request MUST be protected, by using Group OSCORE. In particular, the group mode of Group OSCORE defined in MUST be used. The server protects the phantom registration request as defined in by using its Sender Context, i.e., like if it was the actual sender. As a consequence, the server consumes the current value of its Sender Sequence Number SN in the OSCORE group and hence updates it to SN* = (SN + 1). Consistent with that, the OSCORE Option value in the phantom registration request specifies:

• In the 'kid' field, the Sender ID of the server in the OSCORE group.
• In the 'Partial IV' field, the Partial IV encoding the previously consumed Sender Sequence Number value SN of the server in the OSCORE group, i.e., (SN* - 1).

Informative Response The value of the CBOR byte string in the 'ph_req' parameter encodes the phantom observation request as a message protected with Group OSCORE (see ). Consequently, the following applies:

• The specified Code is 0.05 (FETCH) .
• The sequence of CoAP options will be limited to the outer, non encrypted options.
• A payload is always present, as the ciphertext followed by the countersignature.

Note that, in terms of transport-independent information, the registration request from the client typically differs from the phantom request. Thus, the server has to include the 'ph_req' parameter in the informative response. An exception is the case discussed in . Similarly, the value of the CBOR byte string in the 'last_notif' parameter encodes the latest multicast notification as a message protected with Group OSCORE (see ). This applies also to the initial multicast notification INIT_NOTIF built at Step 6 of . Optionally, the informative response includes additional parameters that provide information about the OSCORE group to join (see ).

Notifications The server MUST protect every multicast notification for the target resource with Group OSCORE. In particular, the group mode of Group OSCORE defined in MUST be used. The process described in applies, with the following additions when building the two OSCORE external_aad structures to encrypt and sign the multicast notification (see ).

• The 'request_kid' element contains the value of the 'kid' field in the OSCORE Option value of the phantom registration request, i.e., the Sender ID of the server.
• The 'request_piv' element contains the value of the 'Partial IV' field in the OSCORE Option value of the phantom registration request, i.e., the Partial IV encoding the consumed Sender Sequence Number SN of the server.
• The 'request_kid_context' element contains the value of the 'kid context' field in the OSCORE Option value of the phantom registration request, i.e., the Group Identifier value (Gid) of the OSCORE group used as ID Context.

Note that these same values are used to protect each and every multicast notification sent for the target resource under this group observation.

Cancellation When canceling a group observation as defined in , the multicast response with error code 5.03 (Service Unavailable) is protected with Group OSCORE, as per . The server MUST use its own Sender Sequence Number as Partial IV to protect the error response and MUST include the Partial IV in the OSCORE Option value of the response.

Client-Side Requirements When using Group OSCORE to protect multicast notifications, the client performs as described in , with the following differences.

Informative Response Upon receiving the informative response from the server, the client performs the same steps defined in , with the following additions. When performing Step 2, the client expects the 'ph_req' parameter to be included in the informative response, which is otherwise considered malformed. An exception is the case discussed in . Once completed Step 2, the client decrypts and verifies the rebuilt phantom registration request as defined in , with the following differences.

• The client MUST NOT perform any replay check. That is, the client skips Step 3 in .
• If decryption and verification of the phantom registration request succeed:
  • The client MUST NOT update the Replay Window in the Recipient Context associated with the server. That is, the client skips the second bullet of Step 6 in .
  • The client MUST NOT take any further process as normally expected according to . That is, the client skips Step 8 in . In particular, the client MUST NOT deliver the phantom registration request to the application and MUST NOT take any action in the Token space of its unicast endpoint where the informative response has been received.
  • The client stores the values of the 'kid', 'Partial IV', and 'kid context' fields from the OSCORE Option value of the phantom registration request.
• If decryption and verification of the phantom registration request fail, the client MAY try sending a new registration request to the server (see ). If the client chooses not to, then the client SHOULD explicitly withdraw from the group observation.

After successful decryption and verification, the client performs Step 3 in , considering the decrypted phantom registration request. If the informative response includes the parameter 'last_notif', the client also decrypts and verifies the latest multicast notification rebuilt at Step 5 in , just like it would for the multicast notifications transmitted as CoAP messages on the wire (see ). If decryption and verification succeed, the client proceeds with Step 6, considering the decrypted latest multicast notification. Otherwise, the client proceeds to Step 7.

Notifications After having successfully processed the informative response as defined in , the client will decrypt and verify every multicast notification for the target resource as defined in , with the following difference. For both decryption and signature verification, the client MUST set the external_aad structure defined in as follows. The particular way to achieve this is implementation specific.

• The 'request_kid' element takes the value of the 'kid' field from the OSCORE Option value of the phantom registration request (see ).
• The 'request_piv' element takes the value of the 'Partial IV' field from the OSCORE Option value of the phantom registration request (see ).
• The 'request_kid_context' element takes the value of the 'kid context' field from the OSCORE Option value of the phantom registration request (see ).

Note that these same values are used to decrypt and verify each and every multicast notification received for the target resource under this group observation.

Example with Group OSCORE The following example refers to two clients C1 and C2 that register to observe a resource /r at a server S, which has address SRV_ADDR and listens to the port number SRV_PORT. Before the following exchanges occur, no clients are observing the resource /r , which has value "1234". The server S sends multicast notifications to the IP multicast address GRP_ADDR and port number GRP_PORT. The server starts the group observation upon receiving a registration request from a first client that wishes to start a traditional observation on the resource /r. Pairwise communication over unicast is protected with OSCORE, while S protects multicast notifications with Group OSCORE. Specifically:

• C1 and S have a pairwise OSCORE Security Context. In particular, C1 has 'kid' = 0x01 as Sender ID and SN_1 = 101 (i.e., 0x65) as Sender Sequence Number.
• C2 and S have a pairwise OSCORE Security Context. In particular, C2 has 'kid' = 0x02 as Sender ID and SN_2 = 201 (i.e., 0xc9) as Sender Sequence Number.
• S is a member of the OSCORE group with name "myGroup" and with 'kid context' = 0x57ab2e as Group ID. In the OSCORE group, S has 'kid' = 0x05 as Sender ID and SN_5 = 501 (i.e., 0x01f5) as Sender Sequence Number.

The following notation is used for the payload of the informative responses:

• The application-extension identifier "cri" defined in is used to notate a CBOR Extended Diagnostic Notation (EDN) literal for a CRI.
• 'bstr(X)' denotes a CBOR byte string with value the byte serialization of X, with '|' denoting byte concatenation.
• 'OPT' denotes a sequence of CoAP options. This refers to the phantom registration request encoded by the 'ph_req' parameter, or to the corresponding latest multicast notification encoded by the 'last_notif' parameter.
• 'PAYLOAD' denotes an encrypted CoAP payload. This refers to the phantom registration request encoded by the 'ph_req' parameter, or to the corresponding latest multicast notification encoded by the 'last_notif' parameter.
• 'SIGN' denotes the countersignature appended to an encrypted CoAP payload. This refers to the phantom registration request encoded by the 'ph_req' parameter, or to the corresponding latest multicast notification encoded by the 'last_notif' parameter.

Example of Group Observation with Group OSCORE S /r | 0.05 (FETCH) | | Token: 0x4a | | Observe: 0 (register) | | OSCORE: [kid:0x01, Partial IV:0x65] | | | | 0xff | | Encrypted_payload { | | 0x01 (GET), | | Observe: 0 (register), | | Uri-Path: "r", | | | | } | | | | ( S allocates the available Token value 0x7b ) | | | | ( S sends to itself a phantom observation request PH_REQ | | as coming from the IP multicast address GRP_ADDR ) | | .------------------------------------------------------- | | / | | \ | | `------------------------------------------------------> | /r | 0.05 (FETCH) | | Token: 0x7b | | Observe: 0 (register) | | OSCORE: [kid:0x05, Partial IV:0x01f5, | | kid context:0x57ab2e] | | | | 0xff | | Encrypted_payload { | | 0x01 (GET), | | Observe: 0 (register), | | Uri-Path: "r", | | | | } | | | | | | ( S steps SN_5 in the Group OSCORE | | Security Context: SN_5 <-- 502 ) | | | | | | ( S creates a group observation of /r ) | | | | ( S increments the observer counter | | for the group observation of /r ) | | | C1 <--------------- [ Unicast w/ OSCORE ] -------------------- S | 2.05 (Content) | | Token: 0x4a | | OSCORE: - (empty) | | Max-Age: 0 | | | | 0xff | | Encrypted_payload { | | 5.03 (Service Unavailable), | | Content-Format: application/informative-response+cbor, | | , | | 0xff, | | Payload { | | / tp_info / 0 : [ | | cri'coap://SRV_ADDR:SRV_PORT/', | | cri'coap://GRP_ADDR:GRP_PORT/', | | 0x7b | | ], | | / ph_req / 1 : bstr(0x05 | OPT | 0xff | | | PAYLOAD | SIGN), | | / last_notif / 2 : bstr(0x45 | OPT | 0xff | | | PAYLOAD | SIGN), | | / join_uri / 4 : "coap://myGM/ace-group/myGroup", | | / sec_gp / 5 : "myGroup" | | } | | } | | | C2 ---------------- [ Unicast w/ OSCORE ] ------------------> S /r | 0.05 (FETCH) | | Token: 0x01 | | Observe: 0 (register) | | OSCORE: [kid:0x02, Partial IV:0xc9] | | | | 0xff | | Encrypted_payload { | | 0x01 (GET), | | Observe: 0 (register), | | Uri-Path: "r", | | | | } | | | | ( S increments the observer counter | | for the group observation of /r ) | | | C2 <--------------- [ Unicast w/ OSCORE ] -------------------- S | 2.05 (Content) | | Token: 0x01 | | OSCORE: - (empty) | | Max-Age: 0 | | | | 0xff, | | Encrypted_payload { | | 5.03 (Service Unavailable), | | Content-Format: application/informative-response+cbor, | | , | | 0xff, | | Payload { | | / tp_info / 0 : [ | | cri'coap://SRV_ADDR:SRV_PORT/', | | cri'coap://GRP_ADDR:GRP_PORT/', | | 0x7b | | ], | | / ph_req / 1 : bstr(0x05 | OPT | 0xff | | | PAYLOAD | SIGN), | | / last_notif / 2 : bstr(0x45 | OPT | 0xff | | | PAYLOAD | SIGN), | | / join_uri / 4 : "coap://myGM/ace-group/myGroup", | | / sec_gp / 5 : "myGroup" | | } | | } | | | | ( The value of the resource /r changes to "5678" ) | | | +--+ | C1 | | | <----------- [ Multicast w/ Group OSCORE ] -------------- S C2 | (Destination address/port: GRP_ADDR/GRP_PORT) | +--+ | | 2.05 (Content) | | Token: 0x7b | | Observe: 2 | | OSCORE: [kid:0x05, Partial IV:0x01f6] | | Max-Age: 0 | | | | 0xff | | Encrypted_payload { | | 2.05 (Content), | | Observe: - (empty), | | , | | 0xff, | | Payload: "5678" | | } | | | | | ]]>

The two external_aad structures used to encrypt and sign the multicast notification above include 'request_kid' = 0x05, 'request_piv' = 0x01f5, and 'request_kid_context' = 0x57ab2e. These values are specified in the 'kid', 'Partial IV', and 'kid context' fields of the OSCORE Option value of the phantom observation request, which is encoded in the 'ph_req' parameter of the unicast informative response to the two clients. Thus, the two clients can build the two same external_aad structures for decrypting and verifying this multicast notification and the following ones in the group observation.

Informative Response Parameters This document defines a number of fields used in the informative response defined in . The table below summarizes them and specifies the CBOR key to use as abbreviation, instead of the full descriptive name. Note that the media type "application/informative-response+cbor" MUST be used when these fields are transported. Informative Response Parameters.

Name	CBOR Key	CBOR Type	Reference
tp_info	0	array	of [RFC-XXXX]
ph_req	1	byte string	of [RFC-XXXX]
last_notif	2	byte string	of [RFC-XXXX]
next_not_before	3	unsigned integer	of [RFC-XXXX]
ending	4	integer or float	of [RFC-XXXX]
join_uri	5	text string	of [RFC-XXXX]
sec_gp	6	text string	of [RFC-XXXX]
as_uri	7	text string	of [RFC-XXXX]
hkdf	8	integer or text string	of [RFC-XXXX]
cred_fmt	9	integer	of [RFC-XXXX]
gp_enc_alg	10	integer or text string	of [RFC-XXXX]
sign_alg	11	integer or text string	of [RFC-XXXX]
sign_params	12	array	of [RFC-XXXX]
gp_material	13	map	of [RFC-XXXX]
srv_cred	14	byte string	of [RFC-XXXX]
srv_identifier	15	byte string	of [RFC-XXXX]
exi	16	unsigned integer	of [RFC-XXXX]
exp	17	integer or float	of [RFC-XXXX]

Note to RFC Editor: In the table above, please replace "[RFC-XXXX]" with the RFC number of this specification and delete this paragraph.

Transport Protocol Information defines the transport-specific information that the server has to specify as elements of 'tpi_details' within the 'tp_info' parameter of the informative response defined in , when CoAP responses are transported over UDP. defines the corresponding entry that registers in the "CoAP Transport Information" registry defined in this document. CoAP Transport Information for CoAP over UDP.

CoAP Transport	Transport Information Details	Reference
CoAP over UDP	tpi_client,tpi_token	of [RFC-XXXX]

Note to RFC Editor: In the table above, please replace "[RFC-XXXX]" with the RFC number of this specification and delete this paragraph.

Security Considerations In addition to the security considerations from , , , , and , the following considerations hold for this document.

Unprotected Communications If communications are not protected, the server might not be able to effectively authenticate a new client when it registers as an observer. specifies how, in such a case, the server must strictly limit the number of notifications sent between receiving acknowledgements from the client, as confirming to be still interested in the observation; i.e., any notifications sent in Non-confirmable messages must be interspersed with confirmable messages. This is not possible to achieve by the same means when using the communication model defined in this document, since multicast notifications are sent as Non-confirmable messages. Nonetheless, the server might obtain such acknowledgements by other means. For instance, the method defined in to perform the rough counting of still interested clients triggers (some of) them to explicitly send a new observation request to acknowledge their interest. Then, the server can decide to terminate the group observation altogether, in the case that not enough clients are estimated to be still active. If the method defined in is used, the server SHOULD NOT send more than a strict number of multicast notifications for a given group observation, without having first performed a new rough counting of active clients. Note that, when using the method defined in with unprotected communications, an adversary can craft and inject multiple new observation requests including the Feedback-Divider Option, hence inducing the server to overestimate the number of still interested clients and thus to inappropriately continue the group observation.

Protected Communications If multicast notifications for an observed resource are protected using Group OSCORE as per , it is ensured that those are securely bound to the phantom registration request that started the group observation of that resource. Furthermore, the following applies.

• The original registration requests and related unicast (notification) responses MUST also be protected, including and especially the informative responses from the server. An exception is the case discussed in , where the informative response from the server is not protected. Protecting informative responses from the server prevents on-path active adversaries from altering the conveyed IP multicast address and serialized phantom registration request.
• A re-registration request, possibly including the Feedback-Divider Option to support the rough counting of clients (see ), MUST also be protected.

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

Media Type Registrations This document registers the media type "application/informative-response+cbor" for error messages as informative response defined in , when carrying parameters encoded in CBOR. This registration follows the procedures specified in .

• Type name: application
• Subtype name: informative-response+cbor
• Required parameters: N/A
• Optional parameters: N/A
• Encoding considerations: Must be encoded as a CBOR map containing the parameters defined in of [RFC-XXXX].
• Security considerations: See of [RFC-XXXX].
• Interoperability considerations: N/A
• Published specification: [RFC-XXXX]
• Applications that use this media type: The type is used by CoAP servers and clients that support error messages as informative response defined in of [RFC-XXXX].
• Fragment identifier considerations: N/A
• Additional information: N/A
• Person & email address to contact for further information: CoRE WG mailing list (core@ietf.org) or IETF Applications and Real-Time Area (art@ietf.org)
• Intended usage: COMMON
• Restrictions on usage: None
• Author/Change controller: IETF
• Provisional registration: No

CoAP Content-Formats Registry IANA is asked to add the following entry to the "CoAP Content-Formats" registry within the "Constrained RESTful Environments (CoRE) Parameters" registry group. Content Type: application/informative-response+cbor Content Coding: - ID: TBD (value between 0 and 255) Reference: [RFC-XXXX]

CoAP Option Numbers Registry IANA is asked to enter the following option number to the "CoAP Option Numbers" registry within the "Constrained RESTful Environments (CoRE) Parameters" registry group. Registrations in the CoAP Option Numbers Registry

Number	Name	Reference
TBD18	Feedback-Divider	[RFC-XXXX]

For the Feedback-Divider Option, the preferred value range is 0-255. In particular, 18 is the preferred option number. Note to RFC Editor: In the table above, please replace TBD18 with the registered option number. Then, please delete this paragraph and the previous paragraph.

Target Attributes Registry IANA is asked to register the following entry in the "Target Attributes" registry within the "Constrained RESTful Environments (CoRE) Parameters" registry group.

• Attribute Name: gp-obs
• Brief Description: Observable resource supporting group observation
• Change Controller: IETF
• Reference: of [RFC-XXXX]

Informative Response Parameters Registry This document establishes the "Informative Response Parameters" registry within the "Constrained RESTful Environments (CoRE) Parameters" registry group. The registration policy is either "Private Use", "Standards Action with Expert Review", or "Specification Required" or "Expert Review" per . "Expert Review" guidelines are provided in . All assignments according to "Standards Action with Expert Review" are made on a "Standards Action" basis per with "Expert Review" additionally required per . The procedure for early IANA allocation of "standards track code points" defined in also applies. When such a procedure is used, IANA will ask the designated expert(s) to approve the early allocation before registration. In addition, working group chairs are encouraged to consult the expert(s) early during the process outlined in . The columns of this registry are:

• Name: This is a descriptive name that enables easier reference to the item. The name MUST be unique. It is not used in the encoding of the item.
• CBOR Key: This is the value used as the CBOR map key of the item. These values MUST be unique. The value can be a positive integer, a negative integer, or a text string. Different ranges of values use different registration policies . Integer values from -256 to 255 as well as text strings of length 1 are designated as "Standards Action With Expert Review". Integer values from -65536 to -257 and from 256 to 65535 as well as text strings of length 2 are designated as "Specification Required". Integer values greater than 65535 as well as text strings of length greater than 2 are designated as "Expert Review". Integer values less than -65536 are marked as "Private Use".
• CBOR Type: This contains the CBOR type of the item, or a pointer to the registry that defines its type, when that depends on another item.
• Reference: This contains a pointer to the public specification for the item, if one exists.

This registry has been initially populated by the entries in .

CoAP Transport Information Registry This document establishes the "CoAP Transport Information" registry within the "Constrained RESTful Environments (CoRE) Parameters" registry group. The registration policy is "Expert Review" . "Expert Review" guidelines are provided in . The columns of this registry are:

• CoAP Transport: This field contains a text string. The value MUST be unique and it uniquely identifies the transport used for CoAP messages.
• Transport Information Details: This field contains a list of text strings, where two adjacent strings are separated by a single comma character. Each text string is the name of an element that provides transport-specific information related to a pertinent CoAP request. Optional elements are prepended by '?' and MUST be specified next to each other as last ones.
• Reference: This contains a pointer to the public specification for the item, if one exists.

This registry has been initially populated by the entry in .

Expert Review Instructions "Standards Action with Expert Review", "Specification Required", and "Expert Review" are three of the registration policies defined for the IANA registries established in this document. This section gives some general guidelines for what the experts should be looking for, but they are being designated as experts for a reason, so they should be given substantial latitude. Expert reviewers should take into consideration the following points:

• Point squatting should be discouraged. Reviewers are encouraged to get sufficient information for registration requests to ensure that the usage is not going to duplicate one that is already registered and that the point is likely to be used in deployments. The zones tagged as "Private Use" are intended for testing purposes and closed environments. Code points in other ranges should not be assigned for testing.
• Specifications are required for the "Standards Action With Expert Review" range of point assignment. Specifications should exist for "Specification Required" ranges, but early assignment before a specification is available is considered to be permissible. When specifications are not provided, the description provided needs to have sufficient information to identify what the point is being used for.
• Experts should take into account the expected usage of fields when approving point assignment. The fact that there is a range for Standards Track documents does not mean that a Standards Track document cannot have points assigned outside of that range. The length of the encoded value should be weighed against how many code points of that length are left, the size of device it will be used on, and the number of code points left that encode to that size.

References Normative References IoTconsultancy.nl RISE AB The Constrained Application Protocol (CoAP) is a web transfer protocol for constrained devices and constrained networks. In a number of use cases, constrained devices often naturally operate in groups (e.g., in a building automation scenario, all lights in a given room may need to be switched on/off as a group). This document specifies the use of CoAP for group communication, including the use of UDP/IP multicast as the default underlying data transport. Both unsecured and secured CoAP group communication are specified. Security is achieved by use of the Group Object Security for Constrained RESTful Environments (Group OSCORE) protocol. The target application area of this specification is any group communication use cases that involve resource-constrained devices or networks that support CoAP. This document replaces and obsoletes RFC 7390, while it updates RFC 7252 and RFC 7641. RISE AB Ericsson AB Ericsson AB Ericsson AB RISE AB This document defines the security protocol Group Object Security for Constrained RESTful Environments (Group OSCORE), providing end-to-end security of messages exchanged with the Constrained Application Protocol (CoAP) between members of a group, e.g., sent over IP multicast. In particular, the described protocol defines how OSCORE is used in a group communication setting to provide source authentication for CoAP group requests, sent by a client to multiple servers, and for protection of the corresponding CoAP responses. Group OSCORE also defines a pairwise mode where each member of the group can efficiently derive a symmetric pairwise key with each other member of the group for pairwise OSCORE communication. Group OSCORE can be used between endpoints communicating with CoAP or CoAP- mappable HTTP. RISE AB Ericsson AB This document defines an application profile of the Authentication and Authorization for Constrained Environments (ACE) framework, to request and provision keying material in group communication scenarios that are based on the Constrained Application Protocol (CoAP) and are secured with Group Object Security for Constrained RESTful Environments (Group OSCORE). This application profile delegates the authentication and authorization of Clients, which join an OSCORE group through a Resource Server acting as Group Manager for that group. This application profile leverages protocol-specific transport profiles of ACE to achieve communication security, server authentication, and proof of possession of a key owned by the Client and bound to an OAuth 2.0 access token. Universität Bremen TZI Fraunhofer SIT The Constrained Resource Identifier (CRI) is a complement to the Uniform Resource Identifier (URI) that represents the URI components in Concise Binary Object Representation (CBOR) rather than as a sequence of characters. This approach simplifies parsing, comparison, and reference resolution in environments with severe limitations on processing power, code size, and memory size. This RFC updates RFC 7595 by adding a column on the "URI Schemes" registry. // (This "cref" paragraph will be removed by the RFC editor:) After // approval of -28 and nit fixes in -29, the present revision -30 // contains two more small fixes for nits that were uncovered in the // RPC intake process. Universität Bremen TZI This document formalizes and consolidates the definition of the Extended Diagnostic Notation (EDN) of the Concise Binary Object Representation (CBOR), addressing implementer experience. Replacing EDN's previous informal descriptions, it updates RFC 8949, obsoleting its Section 8, and RFC 8610, obsoleting its Appendix G. It also specifies registry-based extension points and uses them to support text representations such as of epoch-based dates/times and of IP addresses and prefixes. // (This cref will be removed by the RFC editor:) The present -22 is // intended to present a complete specification that can be used to // confirm the results of the 2026-04-01 CBOR interim. This includes // extending inline comments to encompass C-style comments, and end- // of-line comments to encompass C++-style comments. This document describes the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on IEEE 802.15.4 networks. Additional specifications include a simple header compression scheme using shared context and provisions for packet delivery in IEEE 802.15.4 meshes. [STANDARDS-TRACK] This document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols. This memo documents an Internet Best Current Practice. This memo describes the process for early allocation of code points by IANA from registries for which "Specification Required", "RFC Required", "IETF Review", or "Standards Action" policies apply. This process can be used to alleviate the problem where code point allocation is needed to facilitate desired or required implementation and deployment experience prior to publication of an RFC, which would normally trigger code point allocation. The procedures in this document are intended to apply only to IETF Stream documents. The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation. CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments. This document updates the guidelines and recommendations, as well as the IANA registration processes, for the definition of Uniform Resource Identifier (URI) schemes. It obsoletes RFC 4395. The Constrained Application Protocol (CoAP) is a RESTful application protocol for constrained nodes and networks. The state of a resource on a CoAP server can change over time. This document specifies a simple protocol extension for CoAP that enables CoAP clients to "observe" resources, i.e., to retrieve a representation of a resource and keep this representation updated by the server over a period of time. The protocol follows a best-effort approach for sending new representations to clients and provides eventual consistency between the state observed by each client and the actual resource state at the server. There can be machine-to-machine (M2M) scenarios where server responses to client requests are redundant. This kind of open-loop exchange (with no response path from the server to the client) may be desired to minimize resource consumption in constrained systems while updating many resources simultaneously or performing high-frequency updates. CoAP already provides Non-confirmable (NON) messages that are not acknowledged by the recipient. However, the request/response semantics still require the server to respond with a status code indicating "the result of the attempt to understand and satisfy the request", per RFC 7252. This specification introduces a CoAP option called 'No-Response'. Using this option, the client can explicitly express to the server its disinterest in all responses against the particular request. This option also provides granular control to enable expression of disinterest to a particular response class or a combination of response classes. The server MAY decide to suppress the response by not transmitting it back to the client according to the value of the No-Response option in the request. This option may be effective for both unicast and multicast requests. This document also discusses a few examples of applications that benefit from this option. The User Datagram Protocol (UDP) provides a minimal message-passing transport that has no inherent congestion control mechanisms. This document provides guidelines on the use of UDP for the designers of applications, tunnels, and other protocols that use UDP. Congestion control guidelines are a primary focus, but the document also provides guidance on other topics, including message sizes, reliability, checksums, middlebox traversal, the use of Explicit Congestion Notification (ECN), Differentiated Services Code Points (DSCPs), and ports. Because congestion control is critical to the stable operation of the Internet, applications and other protocols that choose to use UDP as an Internet transport must employ mechanisms to prevent congestion collapse and to establish some degree of fairness with concurrent traffic. They may also need to implement additional mechanisms, depending on how they use UDP. Some guidance is also applicable to the design of other protocols (e.g., protocols layered directly on IP or via IP-based tunnels), especially when these protocols do not themselves provide congestion control. This document obsoletes RFC 5405 and adds guidelines for multicast UDP usage. Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. The methods defined in RFC 7252 for the Constrained Application Protocol (CoAP) only allow access to a complete resource, not to parts of a resource. In case of resources with larger or complex data, or in situations where resource continuity is required, replacing or requesting the whole resource is undesirable. Several applications using CoAP need to access parts of the resources. This specification defines the new CoAP methods, FETCH, PATCH, and iPATCH, which are used to access and update parts of a resource. This specification defines a model for the relationships between resources on the Web ("links") and the type of those relationships ("link relation types"). It also defines the serialisation of such links in HTTP headers with the Link header field. This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON. This document defines Object Security for Constrained RESTful Environments (OSCORE), a method for application-layer protection of the Constrained Application Protocol (CoAP), using CBOR Object Signing and Encryption (COSE). OSCORE provides end-to-end protection between endpoints communicating using CoAP or CoAP-mappable HTTP. OSCORE is designed for constrained nodes and networks supporting a range of proxy operations, including translation between different transport protocols. Although an optional functionality of CoAP, OSCORE alters CoAP options processing and IANA registration. Therefore, this document updates RFC 7252. The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. This document specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework. It utilizes Object Security for Constrained RESTful Environments (OSCORE) to provide communication security and proof-of-possession for a key owned by the client and bound to an OAuth 2.0 access token. IANA IANA IANA IANA IANA IANA In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References Ericsson Dogtiger Labs Ericsson This document describes a publish-subscribe architecture for the Constrained Application Protocol (CoAP), extending the capabilities of CoAP communications for supporting endpoints with long breaks in connectivity and/or up-time. CoAP clients publish on and subscribe to a topic via a corresponding topic resource at a CoAP server acting as broker. RISE AB Group communication over the Constrained Application Protocol (CoAP) can be secured by means of Group Object Security for Constrained RESTful Environments (Group OSCORE). At deployment time, devices may not know the exact security groups to join, the respective Group Manager, or other information required to perform the joining process. This document defines how a CoAP endpoint can use descriptions and links of resources registered at the CoRE Resource Directory to discover security groups and to acquire information for joining them through the respective Group Manager. A given security group can be used to protect communications in multiple application groups, which are separately announced in the Resource Directory as sets of endpoints sharing a pool of resources. This approach is consistent with, but not limited to, the joining of security groups based on the ACE framework for Authentication and Authorization in constrained environments. ARM The Constrained RESTful Application Language (CoRAL) defines a data model and interaction model as well as a compact serialization formats for the description of typed connections between resources on the Web ("links"), possible operations on such resources ("forms"), and simple resource metadata. RISE AB When using the Constrained Application Protocol (CoAP), exchanged messages can be protected end-to-end also across untrusted intermediary proxies. This can be achieved with Object Security for Constrained RESTful Environments (OSCORE) or, in the case of group communication, with Group Object Security for Constrained RESTful Environments (Group OSCORE). However, this sidesteps the proxies' abilities to cache responses from the origin server(s). This document restores cacheability of end-end protected responses at proxies, by using Group OSCORE and introducing consensus requests, which any client in an OSCORE group can send to one server or multiple servers in the same group. Ericsson AB Ericsson AB University of Glasgow RISE AB IN Groupe This document specifies a CBOR encoding of X.509 certificates. The resulting certificates are called C509 certificates. The CBOR encoding supports a large subset of RFC 5280, common certificate profiles and is extensible. Two types of C509 certificates are defined. One type is an invertible CBOR re-encoding of DER-encoded X.509 certificates with the signature field copied from the DER encoding. The other type is identical except that the signature is over the CBOR encoding instead of the DER encoding, avoiding the use of ASN.1. Both types of certificates have the same semantics as X.509 and the same reduced size compared to X.509. The document also specifies CBOR encoded data structures for certificate (signing) requests and certificate request templates, new COSE headers, as well as a TLS certificate type and a file format for C509. This document updates RFC 6698; the TLSA selectors registry is extended to include C509 certificates. RISE AB RISE AB Ericsson AB The Constrained Application Protocol (CoAP) allows clients to "observe" resources at a server and to receive notifications as unicast responses upon changes of the resource state. Instead of sending a distinct unicast notification to each different client, a server can alternatively send a single notification as a response message over multicast, to all the clients observing the same target resource. When doing so, the security protocol Group Object Security for Constrained RESTful Environments (Group OSCORE) can be used to protect multicast notifications end-to-end between the server and the observer clients. This document describes how multicast notifications can be used in network setups that leverage a proxy, e.g., in order to accommodate clients that are not able to directly listen to multicast traffic. The present version -00 refers to version -12 of draft-ietf-core- observe-multicast-notifications, which includes content about proxies that is also included in the present document. Such content will be removed from draft-ietf-core-observe-multicast-notifications in its next revision. This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] This specification defines Web Linking using a link format for use by constrained web servers to describe hosted resources, their attributes, and other relationships between links. Based on the HTTP Link Header field defined in RFC 5988, the Constrained RESTful Environments (CoRE) Link Format is carried as a payload and is assigned an Internet media type. "RESTful" refers to the Representational State Transfer (REST) architecture. A well-known URI is defined as a default entry point for requesting the links hosted by a server. [STANDARDS-TRACK] JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. CBOR Web Token (CWT) is a compact means of representing claims to be transferred between two parties. The claims in a CWT are encoded in the Concise Binary Object Representation (CBOR), and CBOR Object Signing and Encryption (COSE) is used for added application-layer security protection. A claim is a piece of information asserted about a subject and is represented as a name/value pair consisting of a claim name and a claim value. CWT is derived from JSON Web Token (JWT) but uses CBOR rather than JSON. This document specifies version 1.3 of the Datagram Transport Layer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. The DTLS 1.3 protocol is based on the Transport Layer Security (TLS) 1.3 protocol and provides equivalent security guarantees with the exception of order protection / non-replayability. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document obsoletes RFC 6347. In many Internet of Things (IoT) applications, direct discovery of resources is not practical due to sleeping nodes or networks where multicast traffic is inefficient. These problems can be solved by employing an entity called a Resource Directory (RD), which contains information about resources held on other servers, allowing lookups to be performed for those resources. The input to an RD is composed of links, and the output is composed of links constructed from the information stored in the RD. This document specifies the web interfaces that an RD supports for web servers to discover the RD and to register, maintain, look up, and remove information on resources. Furthermore, new target attributes useful in conjunction with an RD are defined. This specification defines a framework for authentication and authorization in Internet of Things (IoT) environments called ACE-OAuth. The framework is based on a set of building blocks including OAuth 2.0 and the Constrained Application Protocol (CoAP), thus transforming a well-known and widely used authorization solution into a form suitable for IoT devices. Existing specifications are used where possible, but extensions are added and profiles are defined to better serve the IoT use cases. This document defines a protocol for exchanging DNS queries (OPCODE 0) over the Constrained Application Protocol (CoAP). These CoAP messages can be protected by (D)TLS-Secured CoAP or Object Security for Constrained RESTful Environments (OSCORE) to provide encrypted DNS message exchange for constrained devices in the Internet of Things (IoT).

Different Sources for Group Observation Data While the clients usually receive the phantom registration request and other information related to the group observation through an informative response (see ), the server can also make the same group observation data available through different means, such as those described in and . In such a case, the server has to first start the group observation (see ), before making the corresponding data available. When distributed through different means than informative responses, the group observation data has to specify the time when the group observation is planned to be canceled by the server. In particular, the server commits to keeping the group observation ongoing until the scheduled cancellation time is reached. Before that time, the server might however retract the advertised group observation data and thus make it not available to new clients. After a client has obtained the group observation data from different sources than an informative response, the client can simply set up the right multicast address and start receiving multicast notifications for the group observation. Consequently, the server will not receive an observation request from that client, will not follow-up with a corresponding informative response, and thus its observer counter (see ) is not incremented to reflect the presence of the new client.

Topic Discovery in Publish-Subscribe Settings In a Publish-Subscribe scenario (e.g., see ), a group observation can be discovered along with topic metadata. To this end, together with the topic metadata, the server has to publish the same information associated with the group observation that would be conveyed in the informative response returned to observer clients (see ). This information especially includes the phantom observation request associated with the group observation, as well as the addressing information of the server and the addressing information where multicast notifications are sent to. provides an example where a group observation is discovered. The example assumes a CoRAL namespace that contains properties analogous to those in the Content-Format "application/informative-response+cbor". Note that the information about the transport protocol used for the group observation is not expressed through a dedicated element equivalent to 'tp_id' of the informative response (see ). Instead, it is expressed through the scheme and authority components of the two URIs specified as 'tp_info_server' and 'tp_info_client', where the former specifies the addressing information of the server (like 'tpi_server' in ), and the latter specifies the addressing information where multicast notifications are sent to (like 'tpi_client' in ).

Group Observation Discovery in a Pub-Sub Scenario Accept: 65087 (application/coral+cbor) Response: 2.05 Content Content-Format: 65087 (application/coral+cbor) rdf:type [ = , topic [ = , tp_info_server , tp_info_client , tp_info_token "7b"^^xsd::hexBinary, ph_req "0160.."^^xsd::hexBinary, last_notif "256105.."^^xsd::hexBinary, ending "2051251201"^^xsd::unsignedLong, ] ] ]]>

With this information from the topic discovery step, the client can already set up its multicast address and start receiving multicast notifications for the group observation in question. In heavily asymmetric networks like municipal notification services, discovery and notifications do not necessarily need to use the same network link. For example, a departure monitor could use its (costly and usually switched off) cellular uplink to discover the topics it needs to update its display to, and then listen on a LoRaWAN interface for receiving the actual multicast notifications.

Introspection at the Multicast Notification Sender For network debugging purposes, it can be useful to query a server that sends multicast responses as matching a phantom registration request. Such an interface is left for other documents to specify on demand. shows an example of a possible interface, as relying on the already known Token value of intercepted multicast notifications associated with a phantom registration request.

Group Observation Discovery with Server Introspection Response: 2.05 Content Content-Format: application/informative-response+cbor { / tp_info / 0 : [ [ / tpi_server / -1, / scheme-id -- equivalent to "coap" / h'20010db80000000000000000000000ab' / host-ip / ], [ / tpi_client / -1, / scheme-id -- equivalent to "coap" / h'ff35003020010db80000000000000023', / host-ip / 61616 / port / ], h'7b' / tpi_token / ], / ph_req / 1 : h'0160...528c', / elided for brevity / / last_notif / 2 : h'256105...4fa1', / elided for brevity / / ending / 4 : 2051251201 } ]]>

For example, a network sniffer could offer sending such a request when unknown multicast notifications are seen in the network. Consequently, it can associate those notifications with a URI, or decrypt them if it is a member of the correct OSCORE group.

Pseudo-Code for Rough Counting of Clients This appendix provides a description in pseudo-code of the two algorithms used for the rough counting of active observers, as defined in . In particular, describes the algorithm for the client side and describes an optimized version for constrained clients. Finally, describes the algorithm for the server side.

Client Side

Client Side (Optimized Version) = UINT_BIT) { if (rand() != 0) return false; Q -= UINT_BIT; } unsigned int mask = ~((~0u) << Q); unsigned int masked = mask & rand(); return masked == 0; } ]]>

Server Side notification.send(GRP_ADDR, GRP_PORT); Timer t = new Timer(); t.setAndStart(MAX_CONFIRMATION_WAIT); // Time t1 while(!t.isExpired()); // Time t2 int R = ; int E = R * (2^Q); // Determine after how many multicast notifications // the next count update will be performed if ((R == 0) || (max(E/N, N/E) > RETRY_NEXT_THRESHOLD)) { } else { } // Compute the new count estimate int COUNT_PRIME = ; int NEW_COUNT = COUNT_PRIME + ((E - N) / D); // Determine whether to cancel the group observation if (NEW_COUNT < CANCEL_THRESHOLD) { ; return 0; } return NEW_COUNT; ]]>

OSCORE Group Self-Managed by the Server For simple settings, where no pre-arranged group with suitable memberships is available, the server can be responsible to set up and manage the OSCORE group used to protect the group observation. In such a case, a client would implicitly request to join the OSCORE group when sending the observe registration request to the server. When replying, the server includes the group keying material and related information in the informative response (see ). In addition to what is defined in , the CBOR map in the informative response payload contains the following fields, whose CBOR abbreviations are defined in .

• 'gp_material': this element is a CBOR map, which includes what the client needs in order to set up the Group OSCORE Security Context. This parameter has as value a subset of the Group_OSCORE_Input_Material object, which is defined in and extends the OSCORE_Input_Material object encoded in CBOR as defined in . In particular, the following elements of the Group_OSCORE_Input_Material object are included, using the same CBOR abbreviations from the OSCORE Security Context Parameters Registry, as in .
  • 'ms', 'contexId', 'cred_fmt', 'gp_enc_alg', 'sign_alg', and 'sign_params'. These elements MUST be included.
  • 'hkdf' and 'salt'. These elements MAY be included.
  The 'group_senderId' element of the Group_OSCORE_Input_Material object MUST NOT be included. Note that no information is provided as related to the AEAD Algorithm, or to the Pairwise Key Agreement Algorithm and its parameters. In fact, the clients and the server will never use the pairwise mode of Group OSCORE as per and will not need to compute a cofactor Diffie-Hellman shared secret in this OSCORE group. It follows that:
  • In the Common Context of the Group OSCORE Security Context, the parameter AEAD Algorithm and the parameter Pairwise Key Agreement Algorithm are not set (see and ).
  • Aligned with the previous point, when building the two OSCORE external_aad structures to process messages protected with Group OSCORE in this OSCORE group, (see ), the elements 'alg_aead' and 'alg_pairwise_key_agreement' within the 'algorithms' arrays are set to the CBOR simple value null (0xf6).
• 'srv_cred': this element is a CBOR byte string, with value the original byte serialization of the server's authentication credential used in the OSCORE group. In particular, the original byte serialization complies with the format specified by the 'cred_fmt' element of 'gp_material'.
• 'srv_identifier': this element is encoded as a CBOR byte string, with value the Sender ID that the server has in the OSCORE group.
• 'exi': this element has as value the residual lifetime of the keying material of the OSCORE group specified in the 'gp_material' parameter, encoded as a CBOR unsigned integer. The value represents the residual lifetime of the keying material in seconds, i.e., the number of seconds between the current time at the server and the time when the keying material expires. Upon receiving the informative response containing the 'exi' parameter, a client determines the expiration time of the keying material by adding the number of seconds specified in the 'exi' parameter to its current time.

If the server has a reliable way to synchronize its internal clock with UTC, then the server includes also the following field:

• 'exp': this element has as value the expiration time of the keying material of the OSCORE group specified in the 'gp_material' parameter, encoded as a CBOR integer or as a CBOR floating-point number. The value is the number of seconds from 1970-01-01T00:00:00Z UTC until the specified UTC date/time, ignoring leap seconds, analogous to what is specified for NumericDate in .

If a client has a reliable way to synchronize its internal clock with UTC and the 'exp' parameter is present in the informative response, then the client MUST use the 'exp' parameter value as expiration time for the group keying material. Note that the informative response does not require to include an explicit proof of possession of the server's private key. Although the server is also acting as Group Manager and a proof-of-possession evidence of the Group Manager's private key is included in a full-fledged Join Response (see ), such proof of possession will be achieved through every multicast notification that the server sends, as protected with the group mode of Group OSCORE and including a signature computed with its private key. A client receiving an informative response uses the information above to set up the Group OSCORE Security Context, as described in . Note that the client does not obtain a Sender ID of its own, hence it installs the Security Context like a "silent server" would, i.e., without a Sender Context. From then on, the client uses the received keying material to process the incoming multicast notifications from the server. Since the server is also acting as the Group Manager, the authentication credential of the server provided in the 'srv_cred' element of the informative response is also used in the 'gm_cred' element of the external_aad structure for encrypting and signing the phantom request and multicast notifications (see ). Furthermore, the server complies with the following points.

• The server MUST NOT self-manage OSCORE groups and provide the related keying material in the informative response for any other purpose than the protection of the phantom requests and the multicast notifications in group observations that it hosts, according to the method defined in this document. The server MAY use the same self-managed OSCORE group to protect the phantom request and the multicast notifications of multiple group observations that it hosts.
• The server MUST NOT provide in the informative response the keying material of other OSCORE groups it is or has been a member of.

Upon expiration of the group keying material as indicated in the informative response by the 'exp' parameter (if present) and the 'exi' parameter:

• The server MUST stop using the keying material and MUST cancel the group observations for which that keying material is used (see and ). If the server creates a new group observation as a replacement or follow-up using the same OSCORE group, then the following applies:
  • The server MUST update the OSCORE Master Secret.
  • The server MUST update the ID Context used as Group Identifier (Gid), consistent with .
  • The server MAY update the OSCORE Master Salt.
• The client MUST stop using the keying material and MAY re-register the observation at the server.

Before the keying material has expired, the server can send a multicast response with response code 5.03 (Service Unavailable) to the observing clients, protected with the current keying material. In particular, while it is analogous to the informative response defined in , this response has the following differences:

• it additionally contains the parameters mentioned above, for the next group keying material to be used; and
• it MAY omit the 'tp_info' and 'ph_req' parameters, since the associated information is immutable throughout the observation lifetime.

The response has the same Token value T of the phantom registration request and it does not include an Observe Option. The server MUST use its own Sender Sequence Number as Partial IV to protect the error response and MUST include the Partial IV in the OSCORE Option value of the response. When some clients leave the OSCORE group and forget about the group observation, the server does not have to provide the remaining clients with any stale Sender IDs, as normally required for Group OSCORE (see ). In fact, only two entities in the group have a Sender ID, i.e., the server and possibly the Deterministic Client, if the optimization defined in this appendix is combined with the use of phantom requests as Deterministic Requests (see ). In particular, both of them never change their Sender ID during the group lifetime and they both remain part of the group until the group ceases to exist. As an alternative to renewing the keying material before it expires, the server can simply cancel the group observation (see and ), which results in the eventual re-registration of the clients that are still interested in the group observation. Applications requiring backward security or forward security are REQUIRED to use an actual group joining process (usually through a dedicated Group Manager), e.g., the ACE joining procedure defined in . The server can facilitate the clients by providing them with information about the OSCORE group to join, as described in .

Phantom Request as Deterministic Request In some settings, the server can assume that all the approaching clients already have the exact phantom observation request to use, together with the transport-specific information required to listen to corresponding multicast notifications. For instance, the clients can be pre-configured with the phantom observation request, or they may be expected to retrieve it through dedicated means (see ). In either case, the server would already have started the group observation, before the associated phantom observation request was disseminated. Then, the clients can set up the multicast address and group observation for listening to multicast notifications. If Group OSCORE is used to protect the group observation (see ) and the OSCORE group supports the concept of Deterministic Client , then the server and clients in the OSCORE group can also independently compute the protected phantom observation request. In such a case, the unprotected version of the phantom observation request can be made available to the clients as a smaller, plain CoAP message. As above, this can be pre-configured on the clients, or they can obtain it through dedicated means (see ). In either case, the clients and the server can independently protect the plain CoAP message by using the approach defined in , thus all computing the same protected Deterministic Request. The latter is used as the actual phantom observation request that the protected multicast notifications will match under the group observation in question. When receiving the Deterministic Request, the server can clearly understand what is happening. In fact, as the result of an early check, the server recognizes the phantom request among the stored ones. This relies on a byte-by-byte comparison of the incoming message minus the transport-related fields, i.e., by considering only: i) the outer REST code; ii) the outer options; and iii) the ciphertext from the message payload. If the server recognizes the received Deterministic Request as one of its self-generated deterministic phantom requests, then the server does not perform any Group OSCORE processing on it. This opens for replying with an unprotected response, although not indicating any OSCORE-related error. In particular, the server MUST reply with an informative response that MUST NOT be protected. Note that the phantom registration request is, in terms of transport-independent information, identical to the same Deterministic Request sent by any client that wishes to take part in the group observation. Thus, if the server receives such a phantom registration request, the informative response may omit the 'ph_req' parameter (see ). If a client receives an informative response that includes the 'ph_req' parameter and this specifies transport-independent information different from the one of the sent Deterministic Request, then the client considers the informative response malformed. When using a Deterministic Request as a phantom observation request, the observer counter at the server (see ) is not reliably incremented when new clients start participating in the group observation. That is, the clients can simply set up the right multicast address and port number, and then start listening to multicast notifications bound to the Deterministic Request. Hence, the observer counter at the server is not incremented as new clients start listening to multicast notifications. Furthermore, the security identity associated with the sender of any Deterministic Request in the OSCORE group is exactly the same one, i.e., the pair (SID, OSCORE ID Context), where SID is the OSCORE Sender ID of the Deterministic Client in the OSCORE group, which clients in the group rely on to produce Deterministic Requests. The setting described above requires the server and all the clients interested in taking part in the group observation to support the approach defined in . On the other hand, its use allows clients to start from a smaller, unprotected version of the phantom observation request, which does not need to be verified as a request generated by the server. Therefore, in applications where the OSCORE group is configured for the use of Deterministic Requests and observer clients are expected to support the approach defined in , servers that start group observations are encouraged to do so by using Deterministic Requests as corresponding phantom observation requests. If the optimization defined in is also used, the 'gp_material' element in the informative response from the server MUST also include the following elements from the Group_OSCORE_Input_Material object.

• 'alg', as per .
• 'det_senderId' and 'det_hash_alg', defined in . These specify the Sender ID of the Deterministic Client in the OSCORE group and the hash algorithm used to compute Deterministic Requests (see ).

Note that, like in , no information is provided as related to the Pairwise Key Agreement Algorithm and its parameters. In fact, the clients and the server will not need to compute a cofactor Diffie-Hellman shared secret in this OSCORE group. It follows that:

• In the Common Context of the Group OSCORE Security Context, the parameter Pairwise Key Agreement Algorithm is not set (see ).
• Aligned with the previous point, when building the two OSCORE external_aad structures to process messages protected with Group OSCORE in this OSCORE group, (see ), the element 'alg_pairwise_key_agreement' within the 'algorithms' arrays is set to the CBOR simple value null (0xf6).

If a Deterministic Request is used as a phantom observation request for a group observation, the server does not assist clients that are interested in taking part in the group observation but do not support Deterministic Requests. This is consistent with the fact that the setup in question already relies on a lot of agreed pre-configuration. Therefore, the following holds when a group observation for a target resource relies on a Deterministic Request as a phantom observation request.

• Every client that is interested to take part in such a group observation: has to support Deterministic Requests; and has to know the phantom observation request, as a result of pre-configuration or following its retrieval through dedicated means (see ).
• The server does not simultaneously run a parallel group observation for the same target resource, as associated with a different phantom observation request and intended to clients that do not support Deterministic Requests.
• If the server receives an observation request for the target resource that differs from the specific Deterministic Request associated with the group observation for that target resource, then the server replies as usual with an informative response, including: the transport-specific information, the phantom request (i.e., the expected Deterministic Request), and (optionally) the latest notification.

Document Updates

Version -13 to -14

• Clarified expected roles in the OSCORE group for clients and server.
• The HKDF Algorithm of Group OSCORE is specified as the corresponding HMAC Algorithm.
• Generalized semantics of the Multicast-Response-Feedback-Divider Option and renamed it as Feedback-Divider.
• Clarified pre-conditions and advantages of using deterministic phantom requests.
• Removed unnecessary normative language.
• Fixes and simplifications in the example with Group OSCORE.
• Updated references.
• Clarifications and editorial improvements.

Version -12 to -13

• Content on proxies moved out to the new document draft-ietf-core-multicast-notifications-proxy.
• Clarified avoidance of link-local addresses.
• Alignment with the update to the "Uniform Resource Identifier (URI) Schemes" IANA registry made by draft-ietf-core-href-26.
• Revised value syntax for the 'Transport Information Details' column of the new IANA registry "CoAP Transport Information".
• Suggested range and value for the registration in the IANA registry "CoAP Option Numbers".
• Updated references.
• Editorial improvements.

Version -11 to -12

• Changed CBOR type of 'ending' and 'exp' to be integer or float.
• Avoid limiting the informative response to this protocol.
• Transport identified by (scheme-id, authority) in the CRI of 'tpi_server'.
• Renamed 'sign_enc_alg' to 'gp_enc_alg', now aligned with draft-ietf-ace-key-groupcomm-oscore.
• Editorial improvements.

Version -10 to -11

• Do not rule out original observation requests sent over multicast.
• Defined 'ending' parameter for the informative response payload.
• Group observation data available on different sources can be removed.
• Initial description of a scenario with a reverse-proxy.
• Minor fixes in examples.
• Clarifications and editorial improvements.

Version -09 to -10

• Fixed section numbers of referred documents.
• Revised registration policies in the IANA considerations.
• Clarifications and editorial improvements.

Version -08 to -09

• Revised 'tp_info' also to use CRIs for transport information.
• Section restructuring: impact from proxies on rough counting of clients.
• Revised and repositioned text on deterministic phantom requests.
• Fixes in the examples with message exchanges.
• Clarifications and editorial improvements.

Version -07 to -08

• Fixed the CDDL definition 'srv_addr' in 'tp_info'.
• Early mentioning that 'srv_addr' cannot instruct redirection.
• The replay protection of multicast notifications is as per Group OSCORE.
• Consistently use the format uint for the Multicast-Response-Feedback-Divider Option.
• Fixed consumption of proxy-related options in a ticket request sent to the proxy.
• Possible use of the option Proxy-Cri or Proxy-Scheme-Number in a ticket request.
• Explained non-provisioning of some parameters in self-managed OSCORE groups.
• Use of 'exi' for relative expiration time in self-managed OSCORE groups.
• Improved notation in the examples of message exchanges with proxy.
• Clarifications and editorial improvements.

Version -06 to -07

• Added more details on proxies that do not support the Multicast-Response-Feedback-Divider Option.
• Added more details on the reliability of the client rough counting.
• Added more details on the unreliability of counting new clients, when the phantom request is obtained from other sources or is an OSCORE Deterministic Request.
• Revised parameter naming.
• Fixes in IANA considerations.
• Editorial improvements.

Version -05 to -06

• Clarified rough counting of clients when a proxy is used
• IANA considerations: registration of target attribute "gp-obs"
• Editorial improvements.

Version -04 to -05

• If the phantom request is an OSCORE Deterministic Request, there is no parallel group observation for clients that lack support.
• Clarification on pre-configured clients.
• Clarified early publication of phantom request.
• Fixes in IANA considerations.
• Fixed example with proxy and Group OSCORE.
• Editorial improvements.

Version -03 to -04

• Added a new section on prerequisites.
• Added a new section overviewing alternative variants.
• Consistent renaming of 'cli_addr' to 'cli_host' in 'tp_info'.
• Added pre-requirements for early retrieval of phantom request.
• Revised example with early retrieval of phantom request.
• Clarified use, rationale and example of phantom request as Deterministic Request.
• Editorial improvements.

Version -02 to -03

• Distinction between authentication credential and public key.
• Fixed processing of informative response at the client, when Group OSCORE is used.
• Discussed scenarios with pre-configured address/port and Token value.

Version -01 to -02

• Clarifications on client rough counting and IP multicast scope.
• The 'ph_req' parameter is optional in the informative response.
• New parameter 'next_not_before' for the informative response.
• Optimization when rekeying the self-managed OSCORE group.
• Security considerations on unsecured multicast notifications.
• Protection of the ticket request sent to a proxy.
• RFC8126 terminology in IANA considerations.
• Editorial improvements.

Version -00 to -01

• Simplified cancellation of the group observation, without using a phantom cancellation request.
• Aligned parameter semantics with core-oscore-groupcomm and ace-key-groupcomm-oscore.
• Clarifications about self-managed OSCORE group and use of Deterministic Requests for cacheable OSCORE.
• New example with a proxy, Group OSCORE and a deterministic phantom request.
• Fixes in the examples and editorial improvements.

Acknowledgments The authors sincerely thank , , , , , , , and for their comments and feedback. The work on this document has been partly supported by the Sweden's Innovation Agency VINNOVA and the Celtic-Next projects CRITISEC and CYPRESS; and by the H2020 project SIFIS-Home (Grant agreement 952652).