Code change:
groupcomm, and it is RECOMMENDED to perform them according to the approach described in I-D.ietf-ace-key-groupcomm-oscore. <ins> 5.3. Different solutions may be selected for secure group communication via a proxy depending on proxy type, use case and deployment requirements.  In this section the options based on Group OSCORE are listed. For a client performing a group communication request via a forward- proxy, end-to-end security should be implemented.  The client then creates a group request protected with Group OSCORE and unicasts this to the proxy.  The proxy adapts the request from a forward-proxy request to a regular request and multicasts this adapted request to the indicated CoAP group.  During the adaptation, the security provided by Group OSCORE persists, in either case of using the group mode or using the pairwise mode.  The first leg of communication from client to proxy can optionally be further protected, e.g., by using (D)TLS and/or OSCORE. For a client performing a group communication request via a reverse- proxy, either end-to-end-security or hop-by-hop security can be implemented.  The case of end-to-end security is the same as for the forward-proxy case. The case of hop-by-hop security is only possible if the proxy can be completely trusted and it is configured as a member of the OSCORE security group(s) that it needs to access, on behalf of clients.  The first leg of communication between client and proxy is then protected with a security method for CoAP unicast, such as (D)TLS, OSCORE or a combination of such methods.  The second leg between proxy and servers is protected using Group OSCORE.  This can be useful in applications where for example the origin client does not implement Group OSCORE, or the group management operations are confined to a particular network domain and the client is outside this domain. For all the above cases, more details on using Group OSCORE are defined in I-D.tiloca-core-groupcomm-proxy. </ins> 6. This section provides security considerations for CoAP group

Related discussion:
text: text for proxy security cases
Reverse proxy may act as origin server and hence client doesn't use e2e security to server group. However, in other cases a reverse proxy may assume the client uses e2e OSCORE security and not add any security by itself. To consider all the different, possible/valid cases for this. And see if it's different for forward proxies.
One particular example is a client that connects over CoAP+TLS+TCP (or CoAP+DTLS) to the reverse-proxy, where the proxy uses OSCORE security for the multicast request. The client is not aware of the (group) security material which the proxy and servers have.
At high level, there are 4 different potential cases of "proxying with security". Forward proxy with e2e security [=Group oscore e2e via proxy] Forward proxy with two-leg security [=unicast OSCORE or DTLS on 1st leg, with group OSCORE on 2nd leg] Reverse proxy with e2e security [=Group oscore e2e via proxy] Reverse proxy with two-leg security [=unicast OSCORE or DTLS on 1st leg, with group OSCORE on 2nd leg] Currently the draft doesn't say anything about these combinations, which are valid, which not, and where to find the security solution to them (e.g. a pointer to draft-groupcomm-proxy for covering most of these cases) This text/analysis could be a new Section 5.3 "Proxy Security" or so. Note: cases 2 and 4 depend on a 100% trusted proxy so no e2e security model. The client in this case is not even aware necessarily of the existence of Group-OSCORE. The proxy stores the "group member identity" to be used to make the Group OSCORE protected request. This may be a single identity, or a separate identity for each authorized user of the Proxy service. Case 1 and 3 most likely means OSCORE-in-OSCORE is needed?
It seems like a good idea. Intermediaries are usually considered non-trusted, hence the interest for an actual e2e security model between origin client and origin servers. How would the proxy store and use a "group member identity" ?