Performance problems with policy intersection

As you all know, Policy Intersection works on matching the QNames of assertions within policy alternatives.  The contents of nested policies are also compared using QName matching, recursively.   There is no wildcard matching nor, as been suggested by some, that an empty nested policy match a nested policy with any specific content.

Thus, if you have an assertion with one or more levels of nested policies, the policy writer needs to enumerate explicitly all the options that he supports.  We saw this with the WS-Addressing assertion and on last Wednesday's call Dave Orchard and I worried whether this could lead to performance problems in cases where a large number of possible combinations of options need to be enumerated.

Take a look at the X509 policy assertion from the SecurityPolicy specification.  This is, indeed, a complex assertions with many, many possible variations and it could become a problem to enumerate all the options that a client/service supports.

<sp:X509Token sp:IncludeToken="xs:anyURI"? xmlns:sp="..." ... >
  ( 
    <sp:Issuer>wsa:EndpointReferenceType</sp:Issuer> |  
    <sp:IssuerName>xs:anyURI</sp:IssuerName> 
  ) ? 
  <wst:Claims Dialect="..."> ... </wst:Claims> ?
  <wsp:Policy xmlns:wsp="...">
    (
      <sp:RequireDerivedKeys ... /> |
      <sp:RequireExplicitDerivedKeys ... /> |
      <sp:RequireImpliedDerivedKeys ... />
    ) ?
    <sp:RequireKeyIdentifierReference ... /> ?
    <sp:RequireIssuerSerialReference ... /> ?
    <sp:RequireEmbeddedTokenReference ... /> ?
    <sp:RequireThumbprintReference ... /> ?
    (
      <sp:WssX509V3Token10 ... /> |
      <sp:WssX509Pkcs7Token10 ... /> |
      <sp:WssX509PkiPathV1Token10 ... /> |
      <sp:WssX509V1Token11 ... /> |
      <sp:WssX509V3Token11 ... /> |
      <sp:WssX509Pkcs7Token11 ... /> |
      <sp:WssX509PkiPathV1Token11 ... />
    ) ?
    ...
  </wsp:Policy> 
  ...
</sp:X509Token>




All the best, Ashok