We must implement on the consumer a generic cookie manager that store the cookies in the consumer portal session and leverage threadlocal + soap handler to read/write headers on the wire.

I believe a lot of code can be borrowed from the initCookie management stuff. And then probably the initCookie stuff can leverage also this manager in order to have a unified management of producer cookies.

On the producer side we must check that the code using the servlet request+response creating an HTTP session will trigger the setting of a cookie on the http response OR if the soap layer will prevent this.

for the actual consumer we scope a cookie for one single portlet or a group of portlet (depending on the producer configuration). In that case we want to send a cookie back to the producer whatever portlet is invoked for that particular producer and without the initCookie initiative.

Section 3.13 of WSRP 2.0 PD says :

Since the transport layer is often used to store various pieces of information (e.g. J2EE load balancing depends on a session cookie and HTTP transport), and these pieces of information often will pertain to a client session with the Consumer rather than the Consumer itself, Consumers that manage transport layer issues, such as cookies, MUST
return them to the Producer only for subsequent invocations within the Markup Interface during the same client
session.

the scope of every cookie must be per producer X user, like a web browser does. this rule does not apply for the cookies got from the initCookie operation of course as those follow specific rules.

For example wsrp4j WS stack does it by default, that's why there is no cookie related code in the wsrp4j. However the docs says :

The WSRP consumer implementation session handling is based on the SOAP stack's session handling. The generated SOAP stubs are doing the cookie handling and are caching the cookies in instance variables. This means that one stub object instance is equivalent to one HTTP session which we map to one WSRP session (initCookie wise). When a WSRP session did time out an InvalidCookie exception is being thrown and a new session must be established.