Code change:
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" ? Even if the proxy somehow obtains multiple different Sender IDs from the Group Manager (i.e., one for each authorized user of the proxy service), the proxy would have to sign a Group OSCORE protected request with a private key of its own (possibly one per corresponding Sender ID), which is not in control of the actual origin client. With such a level of trust on the proxy, and with a client not interested in e2e security anyway, it would be just easier to think of the proxy simply as another single member of the same OSCORE group including the servers, thus sacrificing verifiable data authorship/origin. Maybe this might be useful/applicable for case 4, with a client anyway likely unaware of what happens beyond the reverse-proxy and to be actually reaching a group of servers. Not sure about case 2, where the client would be aware of an actual group of servers it tries to reach. Yes, when exactly OSCORE is also conveniently used between Client and Proxy, to fulfill REQ2 from URL : REQ2. The CoAP proxy MUST identify a client sending a CoAP group request, in order to verify whether the client is allowed-listed to do so. For example, this can rely on one of the following ... Note that this requirement applies even in case end-to-end security is not enforced between client and servers.
Agree, in the two-legs security case it seems sufficient that the proxy has one "identity" within the group. And I agree that this proxy would most likely be a reverse proxy Case 4 i.e. it operates like a (trusted!) origin server. By definition of a reverse proxy , it has to be trusted just like a client trusts an origin server with being able to know and manipulate the served content.
This issue was addressed in Section 5.3 of version -04. NAME , can we close it?
Yes!
Looks good! See inline some proposed rephrasing.

Related discussion:
text: 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