For intersecting two policies, the WS-Policy Framework specification tells that we have to find if two policy assertions are compatibles, and leave that to be implemented at an assertion level.
But if the assertions contains an inside policy, by obtaining the inside policy we can recursively apply the intersection algorithm, and that way to implement the intersection in a more general fashion. That is the case of the security policy assertions, by obtaining the inside policy for each one the algorithm can be used, and the intersection to work generally for policies that contains security policy assertions.
So in the Rampart implementation of policy (org.apache.ws.secpolicy) the serialization could be changed to obtain the inside policy of the security assertions which have one - completed with the namespace so from there to obtain a new policy to be used to recursively to do the intersection. And in Neethi, to implement the intersection by verifying if a particular assertion have an inside policy and go recursively from there.
Example:
For the assertion:
<sp:X509Token sp:IncludeToken='http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/Never'>
<wsp:Policy>
<sp:WssX509V3Token10 />
</wsp:Policy>
</sp:X509Token>
<wsp:Policy>
<sp:WssX509V3Token10 />
</wsp:Policy>
</sp:X509Token>
The inside policy:
<wsp:Policy xmlns:wsp="http://www.w3.org/ns/ws-policy">
<wsp:ExactlyOne>
<wsp:All>
<sp:WssX509V3Token10 xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy" />
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
<wsp:ExactlyOne>
<wsp:All>
<sp:WssX509V3Token10 xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy" />
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
Do you think this may be part of the Neethi implementation?
