OASIS eXtensible Access Control Markup Language (XACML) TC

Hi Erik & all I appreciate and admire the work Erik has done to put these late changes on a complicated topic into the 3.0 spec. But there are a couple of things that I would like to discuss. The reworded first paragraphs under 7.12 and 7.13 are not clear enough. Some of the wording from the previous version should be preserved, to make it clear that the Target determines applicability of the policy, while the combining algorithm applied to the Rule or Policy[Set] children determine the result. The wd-20 wording leaves open the interpretation that the Target participates in the combining algorithm. For 7.12 opening paragraphs I propose: "The value of a policy SHALL be determined by its contents, considered in relation to the contents of the request context. "The policy's target SHALL be evaluated to determine the applicability of the policy. If the target evaluates to "Match" then the value of the policy SHALL be determined by evaluating the policy's rules according to the specified rule combining algorithm. If the target evaluates to "No match" then the value of the policy shall be "Not Applicable". If the target evaluates to "Indeterminate", then the value of the policy shall be determined as if the policy's rules were evaluated according to the specified rule combining algorithm, and then transforming the result according to Table 7 (Section 7.14)." For 7.13: "The value of a policy set SHALL be determined by its contents, considered in relation to the contents of the request context. "The policy set's target SHALL be evaluated to determine the applicability of the policy set. If the target evaluates to "Match" then the value of the policy set SHALL be determined by evaluating the child policies and policy sets according to the specified policy combining algorithm. If the target evaluates to "No match" then the value of the policy set shall be "Not Applicable". If the target evaluates to "Indeterminate", then the value of the policy set shall be determined as if the child policies and policy sets were evaluated according to the specified policy combining algorithm, and then transforming the result according to Table 7 (Section 7.14)." On another point: The clarification that extended indeterminate values shall not be returned from the top-level evaluation leaves me confused, if all it does is return plain Indeterminate. I probably still don't fully understand the extended intermediate indeterminate values, because I don't see where an "Indeterminate{P}" is ever construed as "Permit" or an "Indeterminate{D}" as "Deny". The various indeterminate flavors simply bubble up through the policy evaluation process without influencing the results (except that {P} or {D} might become {DP}). I thought the purpose was to reduce the incidence of indeterminacy when a missing attribute, if supplied, would not change the decision. I won't belabor this point, but if someone has a simple explanation I would appreciate it. Otherwise I will study it further. Regards, --Paul

Hi Paul, Thanks for the effort. See inline. On 2011-05-26 18:47, Paul Tyson wrote: > Hi Erik& all > > I appreciate and admire the work Erik has done to put these late changes > on a complicated topic into the 3.0 spec. But there are a couple of > things that I would like to discuss. > > The reworded first paragraphs under 7.12 and 7.13 are not clear enough. > Some of the wording from the previous version should be preserved, to > make it clear that the Target determines applicability of the policy, > while the combining algorithm applied to the Rule or Policy[Set] > children determine the result. The wd-20 wording leaves open the > interpretation that the Target participates in the combining algorithm. Are you sure this is the case? I figured that the way the tables are written, it is clear that if the target says NoMatch, then the result is NoMatch. If the target matches, then the combining algorithm decides the result, etc. The reason I dropped the text was that I wanted the tables to speak for themselves. If we put text in there as well, the we are specifying the same thing twice, and it's really cumbersome to capture the full, exact meaning of the table in plain English. If the text is not exactly like the table, then there is an ambiguity. > For 7.12 opening paragraphs I propose: > > "The value of a policy SHALL be determined by its contents, considered > in relation to the contents of the request context. > > "The policy's target SHALL be evaluated to determine the applicability > of the policy. If the target evaluates to "Match" then the value of the > policy SHALL be determined by evaluating the policy's rules according to > the specified rule combining algorithm. If the target evaluates to "No > match" then the value of the policy shall be "Not Applicable". If the > target evaluates to "Indeterminate", then the value of the policy shall > be determined as if the policy's rules were evaluated according to the > specified rule combining algorithm, and then transforming the result > according to Table 7 (Section 7.14)." > > For 7.13: > > "The value of a policy set SHALL be determined by its contents, > considered in relation to the contents of the request context. > > "The policy set's target SHALL be evaluated to determine the > applicability of the policy set. If the target evaluates to "Match" > then the value of the policy set SHALL be determined by evaluating the > child policies and policy sets according to the specified policy > combining algorithm. If the target evaluates to "No match" then the > value of the policy set shall be "Not Applicable". If the target > evaluates to "Indeterminate", then the value of the policy set shall be > determined as if the child policies and policy sets were evaluated > according to the specified policy combining algorithm, and then > transforming the result according to Table 7 (Section 7.14)." > > On another point: > The clarification that extended indeterminate values shall not be > returned from the top-level evaluation leaves me confused, if all it > does is return plain Indeterminate. I probably still don't fully > understand the extended intermediate indeterminate values, because I > don't see where an "Indeterminate{P}" is ever construed as "Permit" or > an "Indeterminate{D}" as "Deny". The various indeterminate flavors > simply bubble up through the policy evaluation process without > influencing the results (except that {P} or {D} might become {DP}). I > thought the purpose was to reduce the incidence of indeterminacy when a > missing attribute, if supplied, would not change the decision. I won't > belabor this point, but if someone has a simple explanation I would > appreciate it. Otherwise I will study it further. This was simply intended to make it clear that all of Indeterminate{*} become just plain Indeterminate in the <Result> in the response from the PDP. If it is not clear, could you propose a better wording? Best regards, Erik > Regards, > --Paul > > > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >

See inline.

>
Original Message-----
> From: Erik Rissanen [ mailto:erik@axiomatics.com ]
> Sent: Monday, May 30, 2011 09:58
> To: xacml@lists.oasis-open.org
> Subject: Re: [xacml] wd-20 policy evaluation description
>
> Hi Paul,
>
> Thanks for the effort. See inline.
>
> On 2011-05-26 18:47, Paul Tyson wrote:
> > Hi Erik& all
> >
> > I appreciate and admire the work Erik has done to put these late
> changes
> > on a complicated topic into the 3.0 spec. But there are a couple of
> > things that I would like to discuss.
> >
> > The reworded first paragraphs under 7.12 and 7.13 are not clear
> enough.
> > Some of the wording from the previous version should be preserved, to
> > make it clear that the Target determines applicability of the policy,
> > while the combining algorithm applied to the Rule or Policy[Set]
> > children determine the result. The wd-20 wording leaves open the
> > interpretation that the Target participates in the combining
> algorithm.
>
> Are you sure this is the case? I figured that the way the tables are
> written, it is clear that if the target says NoMatch, then the result
> is
> NoMatch. If the target matches, then the combining algorithm decides
> the
> result, etc.
>
> The reason I dropped the text was that I wanted the tables to speak for
> themselves. If we put text in there as well, the we are specifying the
> same thing twice, and it's really cumbersome to capture the full, exact
> meaning of the table in plain English. If the text is not exactly like
> the table, then there is an ambiguity.

I think my proposed wording is exactly like the table. The new wd-20 wording introduces confusion, because the 2nd sentence in 7.12 says: "A policy's value SHALL be determined by evaluation of the policy's target and rules, according to the specified rule-combining algorithm." This is a subtle but significant change from the previous wording, which did not allow the possibility of the Target participating in the rule-combining algorithm. Similarly for the 1st paragraph in 7.13.

I guess we could strike the 2nd sentence in each paragraph, and just refer to the truth table. I find the tables to be a helpful summary but I would like the natural language explanation to be complete and precise--or at least not misleading.

>
> > For 7.12 opening paragraphs I propose:
> >
> > "The value of a policy SHALL be determined by its contents,
> considered
> > in relation to the contents of the request context.
> >
> > "The policy's target SHALL be evaluated to determine the
> applicability
> > of the policy. If the target evaluates to "Match" then the value of
> the
> > policy SHALL be determined by evaluating the policy's rules according
> to
> > the specified rule combining algorithm. If the target evaluates to
> "No
> > match" then the value of the policy shall be "Not Applicable". If
> the
> > target evaluates to "Indeterminate", then the value of the policy
> shall
> > be determined as if the policy's rules were evaluated according to
> the
> > specified rule combining algorithm, and then transforming the result
> > according to Table 7 (Section 7.14)."
> >
> > For 7.13:
> >
> > "The value of a policy set SHALL be determined by its contents,
> > considered in relation to the contents of the request context.
> >
> > "The policy set's target SHALL be evaluated to determine the
> > applicability of the policy set. If the target evaluates to "Match"
> > then the value of the policy set SHALL be determined by evaluating
> the
> > child policies and policy sets according to the specified policy
> > combining algorithm. If the target evaluates to "No match" then the
> > value of the policy set shall be "Not Applicable". If the target
> > evaluates to "Indeterminate", then the value of the policy set shall
> be
> > determined as if the child policies and policy sets were evaluated
> > according to the specified policy combining algorithm, and then
> > transforming the result according to Table 7 (Section 7.14)."
> >
> > On another point:
> > The clarification that extended indeterminate values shall not be
> > returned from the top-level evaluation leaves me confused, if all it
> > does is return plain Indeterminate. I probably still don't fully
> > understand the extended intermediate indeterminate values, because I
> > don't see where an "Indeterminate{P}" is ever construed as "Permit"
> or
> > an "Indeterminate{D}" as "Deny". The various indeterminate flavors
> > simply bubble up through the policy evaluation process without
> > influencing the results (except that {P} or {D} might become {DP}).
> I
> > thought the purpose was to reduce the incidence of indeterminacy when
> a
> > missing attribute, if supplied, would not change the decision. I
> won't
> > belabor this point, but if someone has a simple explanation I would
> > appreciate it. Otherwise I will study it further.
>
> This was simply intended to make it clear that all of Indeterminate{*}
> become just plain Indeterminate in the <Result> in the response from
> the
> PDP. If it is not clear, could you propose a better wording?

No, the spec is clear about the ultimate return value. The whole Ind{P D} business doesn't make sense when I try to analyze what difference these values make to policy evaluation, because the different flavors of Ind never appear to change a decision--they just bubble up to the top, perhaps becoming more indeterminate (e.g., Ind{P} -> Ind{DP}).

Regards,
--Paul

Hi Paul, See inline. On 2011-05-31 15:08, Tyson, Paul H wrote: > See inline. > >>
Original Message----- >> From: Erik Rissanen [ mailto:erik@axiomatics.com ] >> Sent: Monday, May 30, 2011 09:58 >> To: xacml@lists.oasis-open.org >> Subject: Re: [xacml] wd-20 policy evaluation description >> >> Hi Paul, >> >> Thanks for the effort. See inline. >> >> On 2011-05-26 18:47, Paul Tyson wrote: >>> Hi Erik& all >>> >>> I appreciate and admire the work Erik has done to put these late >> changes >>> on a complicated topic into the 3.0 spec. But there are a couple of >>> things that I would like to discuss. >>> >>> The reworded first paragraphs under 7.12 and 7.13 are not clear >> enough. >>> Some of the wording from the previous version should be preserved, to >>> make it clear that the Target determines applicability of the policy, >>> while the combining algorithm applied to the Rule or Policy[Set] >>> children determine the result. The wd-20 wording leaves open the >>> interpretation that the Target participates in the combining >> algorithm. >> >> Are you sure this is the case? I figured that the way the tables are >> written, it is clear that if the target says NoMatch, then the result >> is >> NoMatch. If the target matches, then the combining algorithm decides >> the >> result, etc. >> >> The reason I dropped the text was that I wanted the tables to speak for >> themselves. If we put text in there as well, the we are specifying the >> same thing twice, and it's really cumbersome to capture the full, exact >> meaning of the table in plain English. If the text is not exactly like >> the table, then there is an ambiguity. > I think my proposed wording is exactly like the table. The new wd-20 wording introduces confusion, because the 2nd sentence in 7.12 says: "A policy's value SHALL be determined by evaluation of the policy's target and rules, according to the specified rule-combining algorithm." This is a subtle but significant change from the previous wording, which did not allow the possibility of the Target participating in the rule-combining algorithm. Similarly for the 1st paragraph in 7.13. > > I guess we could strike the 2nd sentence in each paragraph, and just refer to the truth table. I find the tables to be a helpful summary but I would like the natural language explanation to be complete and precise--or at least not misleading. Sure, it should not be misleading. We could fix that sentence. If we put a full description, then at the least we must make it non-normative. >>> For 7.12 opening paragraphs I propose: >>> >>> "The value of a policy SHALL be determined by its contents, >> considered >>> in relation to the contents of the request context. >>> >>> "The policy's target SHALL be evaluated to determine the >> applicability >>> of the policy. If the target evaluates to "Match" then the value of >> the >>> policy SHALL be determined by evaluating the policy's rules according >> to >>> the specified rule combining algorithm. If the target evaluates to >> "No >>> match" then the value of the policy shall be "Not Applicable". If >> the >>> target evaluates to "Indeterminate", then the value of the policy >> shall >>> be determined as if the policy's rules were evaluated according to >> the >>> specified rule combining algorithm, and then transforming the result >>> according to Table 7 (Section 7.14)." >>> >>> For 7.13: >>> >>> "The value of a policy set SHALL be determined by its contents, >>> considered in relation to the contents of the request context. >>> >>> "The policy set's target SHALL be evaluated to determine the >>> applicability of the policy set. If the target evaluates to "Match" >>> then the value of the policy set SHALL be determined by evaluating >> the >>> child policies and policy sets according to the specified policy >>> combining algorithm. If the target evaluates to "No match" then the >>> value of the policy set shall be "Not Applicable". If the target >>> evaluates to "Indeterminate", then the value of the policy set shall >> be >>> determined as if the child policies and policy sets were evaluated >>> according to the specified policy combining algorithm, and then >>> transforming the result according to Table 7 (Section 7.14)." >>> >>> On another point: >>> The clarification that extended indeterminate values shall not be >>> returned from the top-level evaluation leaves me confused, if all it >>> does is return plain Indeterminate. I probably still don't fully >>> understand the extended intermediate indeterminate values, because I >>> don't see where an "Indeterminate{P}" is ever construed as "Permit" >> or >>> an "Indeterminate{D}" as "Deny". The various indeterminate flavors >>> simply bubble up through the policy evaluation process without >>> influencing the results (except that {P} or {D} might become {DP}). >> I >>> thought the purpose was to reduce the incidence of indeterminacy when >> a >>> missing attribute, if supplied, would not change the decision. I >> won't >>> belabor this point, but if someone has a simple explanation I would >>> appreciate it. Otherwise I will study it further. >> This was simply intended to make it clear that all of Indeterminate{*} >> become just plain Indeterminate in the<Result> in the response from >> the >> PDP. If it is not clear, could you propose a better wording? > No, the spec is clear about the ultimate return value. The whole Ind{P D} business doesn't make sense when I try to analyze what difference these values make to policy evaluation, because the different flavors of Ind never appear to change a decision--they just bubble up to the top, perhaps becoming more indeterminate (e.g., Ind{P} -> Ind{DP}). Here is an example. Without extended values: deny-overrides: Indeterminate Permit ->>> Result should be Indeterminate because first child could have been deny if there would not have been an error With extended values: deny-overrides: Indeterminate{P} Permit ->>> Result should be Permit since second child says explicitly Permit and the first child could not have changed that even if there would have not been any error. Best regards, Erik

Regarding the wording of 7.12 and 7.13: I don't want to see "target", "rule" (or "policy"), and "combining algorithm" mentioned in the same sentence unless it is clear that the combining algorithm only applies to the child rules (or policies), and not to the target.

Thanks for the example of extended indeterminate values. I see now how an indeterminate value can be swallowed by the algorithm.

Regards,
--Paul

>
Original Message-----
> From: Erik Rissanen [ mailto:erik@axiomatics.com ]
> Sent: Tuesday, May 31, 2011 09:58
> To: Tyson, Paul H
> Cc: xacml@lists.oasis-open.org
> Subject: Re: [xacml] wd-20 policy evaluation description
>
> Hi Paul,
>
> See inline.
>
> On 2011-05-31 15:08, Tyson, Paul H wrote:
> > See inline.
> >
> >>
Original Message-----
> >> From: Erik Rissanen [ mailto:erik@axiomatics.com ]
> >> Sent: Monday, May 30, 2011 09:58
> >> To: xacml@lists.oasis-open.org
> >> Subject: Re: [xacml] wd-20 policy evaluation description
> >>
> >> Hi Paul,
> >>
> >> Thanks for the effort. See inline.
> >>
> >> On 2011-05-26 18:47, Paul Tyson wrote:
> >>> Hi Erik& all
> >>>
> >>> I appreciate and admire the work Erik has done to put these late
> >> changes
> >>> on a complicated topic into the 3.0 spec. But there are a couple
> of
> >>> things that I would like to discuss.
> >>>
> >>> The reworded first paragraphs under 7.12 and 7.13 are not clear
> >> enough.
> >>> Some of the wording from the previous version should be preserved,
> to
> >>> make it clear that the Target determines applicability of the
> policy,
> >>> while the combining algorithm applied to the Rule or Policy[Set]
> >>> children determine the result. The wd-20 wording leaves open the
> >>> interpretation that the Target participates in the combining
> >> algorithm.
> >>
> >> Are you sure this is the case? I figured that the way the tables are
> >> written, it is clear that if the target says NoMatch, then the
> result
> >> is
> >> NoMatch. If the target matches, then the combining algorithm decides
> >> the
> >> result, etc.
> >>
> >> The reason I dropped the text was that I wanted the tables to speak
> for
> >> themselves. If we put text in there as well, the we are specifying
> the
> >> same thing twice, and it's really cumbersome to capture the full,
> exact
> >> meaning of the table in plain English. If the text is not exactly
> like
> >> the table, then there is an ambiguity.
> > I think my proposed wording is exactly like the table. The new wd-20
> wording introduces confusion, because the 2nd sentence in 7.12 says: "A
> policy's value SHALL be determined by evaluation of the policy's target
> and rules, according to the specified rule-combining algorithm." This
> is a subtle but significant change from the previous wording, which did
> not allow the possibility of the Target participating in the rule-
> combining algorithm. Similarly for the 1st paragraph in 7.13.
> >
> > I guess we could strike the 2nd sentence in each paragraph, and just
> refer to the truth table. I find the tables to be a helpful summary
> but I would like the natural language explanation to be complete and
> precise--or at least not misleading.
>
> Sure, it should not be misleading. We could fix that sentence. If we
> put
> a full description, then at the least we must make it non-normative.
>
> >>> For 7.12 opening paragraphs I propose:
> >>>
> >>> "The value of a policy SHALL be determined by its contents,
> >> considered
> >>> in relation to the contents of the request context.
> >>>
> >>> "The policy's target SHALL be evaluated to determine the
> >> applicability
> >>> of the policy. If the target evaluates to "Match" then the value
> of
> >> the
> >>> policy SHALL be determined by evaluating the policy's rules
> according
> >> to
> >>> the specified rule combining algorithm. If the target evaluates to
> >> "No
> >>> match" then the value of the policy shall be "Not Applicable". If
> >> the
> >>> target evaluates to "Indeterminate", then the value of the policy
> >> shall
> >>> be determined as if the policy's rules were evaluated according to
> >> the
> >>> specified rule combining algorithm, and then transforming the
> result
> >>> according to Table 7 (Section 7.14)."
> >>>
> >>> For 7.13:
> >>>
> >>> "The value of a policy set SHALL be determined by its contents,
> >>> considered in relation to the contents of the request context.
> >>>
> >>> "The policy set's target SHALL be evaluated to determine the
> >>> applicability of the policy set. If the target evaluates to
> "Match"
> >>> then the value of the policy set SHALL be determined by evaluating
> >> the
> >>> child policies and policy sets according to the specified policy
> >>> combining algorithm. If the target evaluates to "No match" then
> the
> >>> value of the policy set shall be "Not Applicable". If the target
> >>> evaluates to "Indeterminate", then the value of the policy set
> shall
> >> be
> >>> determined as if the child policies and policy sets were evaluated
> >>> according to the specified policy combining algorithm, and then
> >>> transforming the result according to Table 7 (Section 7.14)."
> >>>
> >>> On another point:
> >>> The clarification that extended indeterminate values shall not be
> >>> returned from the top-level evaluation leaves me confused, if all
> it
> >>> does is return plain Indeterminate. I probably still don't fully
> >>> understand the extended intermediate indeterminate values, because
> I
> >>> don't see where an "Indeterminate{P}" is ever construed as "Permit"
> >> or
> >>> an "Indeterminate{D}" as "Deny". The various indeterminate flavors
> >>> simply bubble up through the policy evaluation process without
> >>> influencing the results (except that {P} or {D} might become {DP}).
> >> I
> >>> thought the purpose was to reduce the incidence of indeterminacy
> when
> >> a
> >>> missing attribute, if supplied, would not change the decision. I
> >> won't
> >>> belabor this point, but if someone has a simple explanation I would
> >>> appreciate it. Otherwise I will study it further.
> >> This was simply intended to make it clear that all of
> Indeterminate{*}
> >> become just plain Indeterminate in the<Result> in the response from
> >> the
> >> PDP. If it is not clear, could you propose a better wording?
> > No, the spec is clear about the ultimate return value. The whole
> Ind{P D} business doesn't make sense when I try to analyze what
> difference these values make to policy evaluation, because the
> different flavors of Ind never appear to change a decision--they just
> bubble up to the top, perhaps becoming more indeterminate (e.g., Ind{P}
> -> Ind{DP}).
>
> Here is an example. Without extended values:
>
> deny-overrides:
> Indeterminate
> Permit
> ->>> Result should be Indeterminate because first child could have been
> deny if there would not have been an error
>
> With extended values:
>
> deny-overrides:
> Indeterminate{P}
> Permit
> ->>> Result should be Permit since second child says explicitly Permit
> and the first child could not have changed that even if there would
> have
> not been any error.
>
> Best regards,
> Erik
>

I found the following issues with wd-20:


5.14 Element <Policy>
"<CombinerParameters> [Optional]
A sequence of parameters to be used by the rule-combining algorithm."
- Are these parameters only used by the rule-combining algorithm, or also by the policy-combining algorithm?


5.14 Element <Policy>
"<ObligationExpressions> [Optional]
A conjunctive sequence of obligation expressions which MUST be evaluated into obligations byt the PDP."
- "byt" should be "by". Also in 5.21.


5.16 Element <CombinerParameters>
"If multiple <CombinerParameters> elements occur within the same policy or policy set, they SHALL be considered equal to one <CombinerParameters> element containing the concatenation of all the sequences of <CombinerParameters> contained in all the aforementioned <CombinerParameters> elements, such that the order of occurence of the <CominberParameters> elements is preserved in the concatenation of the <CombinerParameter> elements."
- "Cominber" should be "Combiner". Also in 5.18, 5.19, and 5.20. Also found "<PolicyCominberParameters>" and "<PolicySetCominberParmeters>".
- "occurence" should be "occurrence".
- I have a feeling that some of these "<CombinerParameters>" should be "<CombinerParameter>", but I find that hard to tell with the current wording. Also in 5.18, 5.19, and 5.20.


5.18 Element <RuleCombinerParameters>
"Support for the <RuleCombinerParameters> element is optional, only if support for combiner parameters is not implemented."
- This wording is unclear to me. Does this mean that support for <RuleCombinerParameters> is only optional if support for combiner parameters is not implemented???


5.29 Element <AttributeDesignator>
"If the Issuer is not present in the attribute designator, then the matching of the attribute to the named attribute SHALL be governed by AttributeId and DataType attributes alone."
- And Category.


5.30 Element <AttributeSelector>
"The values shall be constructed from the node(s) selected by applying the XPath expression given by the element's Path attribute to the XML content indicated by the element's Category attribute."
- "shall" should be "SHALL".


5.30 Element <AttributeSelector>
"DataType [Required]
The attribute specifies the datatype of the values returned from the evaluation of this <AttributeSelector> element."
- "The attribute" should be "This attribute", like everywhere else.


5.41 Element <AttributeAssignmentExpression>
"The value specified SHALL be understood by the PEP, but it is not further specified by XACML."
- It only SHALL be understood for an obligation, not for an advice.


5.44 Element <Attributes>
- In the XML schema fragment, there is a trailing "<xs:complexType name="SubjectType">" that shouldn't be there.


5.49 Element <PolicyIdentifierList>
- We use "Id" everywhere, so why is this "Identifier" all of a sudden?
- Also, we use the plural "s" everywhere and here we use "List".


6 XPath 2.0 definitions
- "make user of" should be "make use of".


Thanks,
Ray

Remon, Thanks. See inline. On 2011-06-07 07:08, remon.sinnema@emc.com wrote: > I found the following issues with wd-20: > > > 5.14 Element<Policy> > "<CombinerParameters> [Optional] > A sequence of parameters to be used by the rule-combining algorithm." > - Are these parameters only used by the rule-combining algorithm, or also by the policy-combining algorithm? > As far as I can tell this is wrong. It should say policy combining, not rule combining. But then there is no real definition of how these elements apply. I figure the intent is that the <CombinerParameters> element applies to the element it is contained in (<Policy> or <PolicySet>) since it does not contain a reference. <PolicySetCombinerParameters>, <PolicyCombinerParameters> and <RuleCombinerParameters> all contain a reference, so they would apply to what the reference is pointing. > 5.14 Element<Policy> > "<ObligationExpressions> [Optional] > A conjunctive sequence of obligation expressions which MUST be evaluated into obligations byt the PDP." > - "byt" should be "by". Also in 5.21. > > > 5.16 Element<CombinerParameters> > "If multiple<CombinerParameters> elements occur within the same policy or policy set, they SHALL be considered equal to one<CombinerParameters> element containing the concatenation of all the sequences of<CombinerParameters> contained in all the aforementioned<CombinerParameters> elements, such that the order of occurence of the<CominberParameters> elements is preserved in the concatenation of the<CombinerParameter> elements." > - "Cominber" should be "Combiner". Also in 5.18, 5.19, and 5.20. Also found "<PolicyCominberParameters>" and"<PolicySetCominberParmeters>". > - "occurence" should be "occurrence". > - I have a feeling that some of these "<CombinerParameters>" should be"<CombinerParameter>", but I find that hard to tell with the current wording. Also in 5.18, 5.19, and 5.20. I think the final <CombinerParameters> should be just <CombinerParameter> so it says: "... such that the order of occurence of the <CominberParameter> elements is preserved in the concatenation ..." > 5.18 Element<RuleCombinerParameters> > "Support for the<RuleCombinerParameters> element is optional, only if support for combiner parameters is not implemented." > - This wording is unclear to me. Does this mean that support for<RuleCombinerParameters> is only optional if support for combiner parameters is not implemented??? I guess it means that if you do implement combiner parameters, you have to do that for both policy and rule combining, not just one of them. > 5.29 Element<AttributeDesignator> > "If the Issuer is not present in the attribute designator, then the matching of the attribute to the named attribute SHALL be governed by AttributeId and DataType attributes alone." > - And Category. Yes! > 5.30 Element<AttributeSelector> > "The values shall be constructed from the node(s) selected by applying the XPath expression given by the element's Path attribute to the XML content indicated by the element's Category attribute." > - "shall" should be "SHALL". Yes > 5.30 Element<AttributeSelector> > "DataType [Required] > The attribute specifies the datatype of the values returned from the evaluation of this<AttributeSelector> element." > - "The attribute" should be "This attribute", like everywhere else. Yes > 5.41 Element<AttributeAssignmentExpression> > "The value specified SHALL be understood by the PEP, but it is not further specified by XACML." > - It only SHALL be understood for an obligation, not for an advice. Well, yes, but advice can be ignored in their entirety, so it would not matter. but I guess we could change that. > 5.44 Element<Attributes> > - In the XML schema fragment, there is a trailing "<xs:complexType name="SubjectType">" that shouldn't be there. Will remove. > 5.49 Element<PolicyIdentifierList> > - We use "Id" everywhere, so why is this "Identifier" all of a sudden? > - Also, we use the plural "s" everywhere and here we use "List". I guess it was a different person who added this element at a later stage so it became like that. I would prefer to keep it. It has no impact on implementations. > 6 XPath 2.0 definitions > - "make user of" should be "make use of". Will fix for next draft. > Thanks, > Ray >

Erik,


>
Original Message-----
> From: Erik Rissanen [ mailto:erik@axiomatics.com ]
> Sent: Thursday, June 09, 2011 11:27 AM
> To: xacml@lists.oasis-open.org
> Subject: Re: [xacml] wd-20 issues
>
> > 5.29 Element<AttributeDesignator>
> > "If the Issuer is not present in the attribute designator, then
> the matching of the attribute to the named attribute SHALL be governed
> by AttributeId and DataType attributes alone."
> > - And Category.
>
> Yes!

Also in 7.3.4 Attribute Matching.


5.48 Element <Result>
"<PolicyIdentifierList> [Optional]
If the ReturnPolicyIdList attribute in the <Request> is true (see section 5.42), a PDP that implements this optional feature MUST return a list of all policies which were found to be fully applicable."
- This prevents the PDP from skipping evaluation of policies that cannot affect the decision. IOW, it prevents performance optimizations. This is not a big deal to me, since the feature is optional, but maybe something to note in the implementer's guide?


7.3.7 AttributeSelector evaluation
"If the DataType is not one of the primitive types listed above, then the return values shall be constructed from the nodeset in a manner specified by the of the particular DataType extension specification."
- "specified by the of the" misses a crucial noun.


7.7 Target evaluation
"An empty target matches any request. Otherwise the target value SHALL be "Match" if all the AnyOf specified in the target match values in the request context."
- This conflicts with 5.6 Element <Target>: "For the parent of the <Target> element to be applicable to the decision request, there MUST be at least one positive match between each <AnyOf> element of the <Target> element and the corresponding section of the <Request> element."


Thanks,
Ray

Remon, See inline. On 2011-06-10 09:51, remon.sinnema@emc.com wrote: > Erik, > > >>
Original Message----- >> From: Erik Rissanen [ mailto:erik@axiomatics.com ] >> Sent: Thursday, June 09, 2011 11:27 AM >> To: xacml@lists.oasis-open.org >> Subject: Re: [xacml] wd-20 issues >> >>> 5.29 Element<AttributeDesignator> >>> "If the Issuer is not present in the attribute designator, then >> the matching of the attribute to the named attribute SHALL be governed >> by AttributeId and DataType attributes alone." >>> - And Category. >> Yes! > Also in 7.3.4 Attribute Matching. > > > 5.48 Element<Result> > "<PolicyIdentifierList> [Optional] > If the ReturnPolicyIdList attribute in the<Request> is true (see section 5.42), a PDP that implements this optional feature MUST return a list of all policies which were found to be fully applicable." > - This prevents the PDP from skipping evaluation of policies that cannot affect the decision. IOW, it prevents performance optimizations. This is not a big deal to me, since the feature is optional, but maybe something to note in the implementer's guide? The intended behavior is not how you interpret it. It says "which were found..." so it's simply the list of policies the PDP worked on during evaluation. It does not mean that the PDP has to figure out which policies "might have been fully applicable if they were to be evaluated". If you have a suggestion for better wording, please post it, and I can update this while we are fixing the other issues. > 7.3.7 AttributeSelector evaluation > "If the DataType is not one of the primitive types listed above, then the return values shall be constructed from the nodeset in a manner specified by the of the particular DataType extension specification." > - "specified by the of the" misses a crucial noun. It should just say "in a manner specified by the particular datatype extension specification", meaning that if you extend XACML with a custom data type, you also need to define (and implement) this constructor. > 7.7 Target evaluation > "An empty target matches any request. Otherwise the target value SHALL be "Match" if all the AnyOf specified in the target match values in the request context." > - This conflicts with 5.6 Element<Target>: "For the parent of the<Target> element to be applicable to the decision request, there MUST be at least one positive match between each<AnyOf> element of the<Target> element and the corresponding section of the<Request> element." Yes, I will fix that. Thanks for noticing. > Thanks, > Ray >

Hi Erik, On the last item, I don't understand what is going to be fixed . Also, I do not see any inconsistency between 5.6 and 7.7. I think both situations: zero <AnyOf> elements and one or more <AnyOf> elements appear to be covered in both sections 5.6 and 7.7 in a consistent manner. Or am I missing something?       Thanks,       Rich On 6/15/2011 7:11 AM, Erik Rissanen wrote: 4DF8935D.4070204@axiomatics.com type= cite >Remon, See inline. On 2011-06-10 09:51, remon.sinnema@emc.com wrote: Erik,
Original Message----- From: Erik Rissanen [ mailto:erik@axiomatics.com ] Sent: Thursday, June 09, 2011 11:27 AM To: xacml@lists.oasis-open.org Subject: Re: [xacml] wd-20 issues 5.29 Element<AttributeDesignator>         If the Issuer is not present in the attribute designator, then the matching of the attribute to the named attribute SHALL be governed by AttributeId and DataType attributes alone. - And Category. Yes! Also in 7.3.4 Attribute Matching. 5.48 Element<Result>         <PolicyIdentifierList>   [Optional]        If the ReturnPolicyIdList attribute in the<Request>   is true (see section 5.42), a PDP that implements this optional feature MUST return a list of all policies which were found to be fully applicable. - This prevents the PDP from skipping evaluation of policies that cannot affect the decision. IOW, it prevents performance optimizations. This is not a big deal to me, since the feature is optional, but maybe something to note in the implementer's guide? The intended behavior is not how you interpret it. It says which were found... so it's simply the list of policies the PDP worked on during evaluation. It does not mean that the PDP has to figure out which policies might have been fully applicable if they were to be evaluated . If you have a suggestion for better wording, please post it, and I can update this while we are fixing the other issues. 7.3.7 AttributeSelector evaluation         If the DataType is not one of the primitive types listed above, then the return values shall be constructed from the nodeset in a manner specified by the of the particular DataType extension specification. - specified by the of the misses a crucial noun. It should just say in a manner specified by the particular datatype extension specification , meaning that if you extend XACML with a custom data type, you also need to define (and implement) this constructor. 7.7 Target evaluation         An empty target matches any request. Otherwise the target value SHALL be Match if all the AnyOf specified in the target match values in the request context. - This conflicts with 5.6 Element<Target>: For the parent of the<Target>   element to be applicable to the decision request, there MUST be at least one positive match between each<AnyOf>   element of the<Target>   element and the corresponding section of the<Request>   element. Yes, I will fix that. Thanks for noticing. Thanks, Ray --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.   Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

Hi Rich, Yes, you are right. It seems Remon did not notice the description of <AnyOf> in 5.6, which is correct. 7.7 correctly says that an empty target will always match, though the case is not listed in the table. So no action should be required on this. Best regards, Erik On 2011-06-16 07:50, rich levinson wrote: 4DF999BF.5060806@oracle.com type= cite > Hi Erik, On the last item, I don't understand what is going to be fixed . Also, I do not see any inconsistency between 5.6 and 7.7. I think both situations: zero <AnyOf> elements and one or more <AnyOf> elements appear to be covered in both sections 5.6 and 7.7 in a consistent manner. Or am I missing something?       Thanks,       Rich On 6/15/2011 7:11 AM, Erik Rissanen wrote: 4DF8935D.4070204@axiomatics.com type= cite >Remon, See inline. On 2011-06-10 09:51, remon.sinnema@emc.com wrote: Erik,
Original Message----- From: Erik Rissanen [ mailto:erik@axiomatics.com ] Sent: Thursday, June 09, 2011 11:27 AM To: xacml@lists.oasis-open.org Subject: Re: [xacml] wd-20 issues 5.29 Element<AttributeDesignator>         If the Issuer is not present in the attribute designator, then the matching of the attribute to the named attribute SHALL be governed by AttributeId and DataType attributes alone. - And Category. Yes! Also in 7.3.4 Attribute Matching. 5.48 Element<Result>         <PolicyIdentifierList>   [Optional]        If the ReturnPolicyIdList attribute in the<Request>   is true (see section 5.42), a PDP that implements this optional feature MUST return a list of all policies which were found to be fully applicable. - This prevents the PDP from skipping evaluation of policies that cannot affect the decision. IOW, it prevents performance optimizations. This is not a big deal to me, since the feature is optional, but maybe something to note in the implementer's guide? The intended behavior is not how you interpret it. It says which were found... so it's simply the list of policies the PDP worked on during evaluation. It does not mean that the PDP has to figure out which policies might have been fully applicable if they were to be evaluated . If you have a suggestion for better wording, please post it, and I can update this while we are fixing the other issues. 7.3.7 AttributeSelector evaluation         If the DataType is not one of the primitive types listed above, then the return values shall be constructed from the nodeset in a manner specified by the of the particular DataType extension specification. - specified by the of the misses a crucial noun. It should just say in a manner specified by the particular datatype extension specification , meaning that if you extend XACML with a custom data type, you also need to define (and implement) this constructor. 7.7 Target evaluation         An empty target matches any request. Otherwise the target value SHALL be Match if all the AnyOf specified in the target match values in the request context. - This conflicts with 5.6 Element<Target>: For the parent of the<Target>   element to be applicable to the decision request, there MUST be at least one positive match between each<AnyOf>   element of the<Target>   element and the corresponding section of the<Request>   element. Yes, I will fix that. Thanks for noticing. Thanks, Ray --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.   Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

Erik/Rich,


From: Erik Rissanen [ mailto:erik@axiomatics.com ]
Sent: Thursday, June 16, 2011 10:57 AM
To: xacml@lists.oasis-open.org
Subject: Re: [xacml] wd-20 issues

My understanding was the following:


7.7 Target evaluation
       "An empty target matches any request. Otherwise the target value SHALL be "Match" if all the AnyOf specified in the target match values in the request context."
=> All the <AnyOf>s must match


5.6 Element<Target>
"For the parent of the<Target>   element to be applicable to the decision request, there MUST be at least one positive match between each<AnyOf>   element of the<Target>   element and the corresponding section of the<Request>   element."
=> Any of the <AnyOf>s must match

This, however, is just my misreading: I got fooled by the "at least one" part. So I agree there is no issue, although maybe the wording could be a bit improved.


Thanks,
Ray