Decision required: Issue#70: Must Policy[Set]Id match value used in acorresponding Policy[Set]IdReference?

[Anne Anderson <Anne.Anderson@sun.com>]

PROBLEM

The question is, when one policy references another, as in

    <PolicySet ...>
       <Target .../>
       ....
       <PolicyIdReference>xxxx</PolicyIdReference>
       ....
    </PolicySet>

    referenced policy:

   <Policy PolicyId="yyyy">
       ....
   </Policy>

whether "xxxx" must equal "yyyy".

This question may also apply to Policy[Set]IdRef values in 
CombinerParamters.

Please state what you want the spec to say, and why.

WHAT THE SPEC SAYS NOW

The XACML 2.0 Specification never flat-out states that the value used in 
   a Policy[Set]IdReference must match the value of the Policy[Set]Id 
used in the referenced policy, and if so, does not state the algorithm 
for doing the id matching.  It says

     "The <Policy[Set]IdReference> element SHALL be used to reference a
      <Policy[Set]> element by id"

but does state explicitly that the "id" must match the Policy[Set]Id 
value in the referenced policy.  The non-normative examples, in 
describing Policy[Set]Id, say

     "Policy[Set] identifier.  This parameter allows the policy [set] to
      be referenced by a policy set"

but again does not explicitly say the values must match and is also 
non-normative.

WHAT IMPLEMENTATIONS AND DEPLOYMENTS DO NOW

Seth says "There are many examples of people taking advantage of the 
*current* behavior, which does not require that these identifiers match 
up. It may  have been someone's intent that identifiers match, but that 
has never been encoded in the specification. We should be very careful 
about changing the current behavior."

OPTIONS

This needs to be clarified in XACML 3.0 and in XACML 2.0 Errata.

A. If the TC decides that the values MUST match, then we need to state 
that explicitly and specify the matching function (probably 
anyURI-equal) to use.

B. If the TC decides that they do not need to match (or even MUST NOT 
match, as one old e-mail suggested), then we need to make some bigger 
changes in our specs.  The places I can think of are:

- XACML 2.0 Core: If a PolicySet uses references even to internal 
Policy[Set]s, there is no way to know which ones match the reference. 
We need to state that the Policy[Set]IdReference value does NOT [MUST 
NOT?] correspond to the Policy[Set]Id in the referenced policy, and that 
the PDP must know via some additional undefined mechanism which policies 
satisfy which references.

- XACML 2.0 Core: Policy[Set]CombinerParameters include a 
Policy[Set]IdRef that MUST be associated with a policy in the same 
PolicySet.  We need to state that the IdRef value does NOT [MUST NOT?] 
correspond to the Policy[Set]Id in the referenced policy, and that the 
PDP must know via some additional undefined mechanism which policies 
satisfy which references.

- XACML 3.0 Core: We might want to add an optional 
"ReferenceMatchValues" element to Policy[Set] to contain the 
Policy[Set]IdRef and Policy[Set]IdReference values it matches.  This 
could be a many-to-many match, so we can't just stick in an XML 
attribute, and maybe we need to have separate lists for Policy[Set]IdRef 
and for Policy[Set]IdReference.  Alternatively, we could add an optional 
element to Policy[Set]IdRef and Policy[Set]IdReference to contain the 
Policy[Set]Id values that it is intended to match, for cases where the 
implementation does not want to provide an additional 
implementation-specific mechanism.

- SAML Profile 2.0: If an XACMLPolicyQuery requests policies according 
to Policy[Set]IdReferences, currently all the referenced policies are 
returned directly.  We need to state that the PDP must know via some 
additional undefined mechanism which policies satisfy which references.

- SAML Profile, Version 2: I would add an encapsulating element around 
each returned Policy[Set] that contains the Policy[Set]IdReference 
value(s) it satisfies.  This would go into SAML Profile V2 WD4.

- SAML Profile, Version 2: If an XACMLAuthzDecisionQuery passes in a set 
of policies, it must also supply copies of all policies referenced, 
either from the first set or from other referenced policies.  In WD3 
these are passed with no indication of which reference each policy 
satisfies, so in WD4, I would add an encapsulating element around each 
referenced policy that contains the Policy[Set]IdReference value(s) it 
satisfies.  This would go into SAML Profile V2 WD 4.

- WS-XACML: If a Requirements element in an XACMLAssertionAbstractType 
instance includes a policy, then it must also supply copies of all 
policies referenced, either from the original Requirements policy, or 
from another referenced policy.  The WD9 does not include this, but the 
TC has decided it should.   For WD10, I would encapsulate each policy 
copy in an element that specifies the value of the reference to which 
the encapsulated policy corresponds.

- Are there others?

Regards,
Anne
-- 
Anne H. Anderson               Anne.Anderson@sun.com
Sun Microsystems Labs          1-781-442-0928
Burlington, MA USA