OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: Delegation and on-permit-apply-second

Hi Erik,

On 1/09/2012 1:23 AM, Erik Rissanen wrote:
Hi Steven,

I don't think we change the delegation model in this way since it would mean changing the core schema, which
we really don't want to do at this stage. Also, I think we did consider labeling policies like this in early
stages of the delegation work. I don't remember right now why we did not go that way, but I suspect there
was a reason. Probably that the current mechanism is more flexible.

I'll respond to this in a separate thread.

Regarding your other suggestions, could you propose changes to the text in the combalgs wd? It's a lot
easier to discuss and to come to agreement when there is a proposal to discuss.

After some consideration I think the ideas you posted previously; changing the status code from
indeterminate from the first policy, and allowing denys from it, do make sense.

Could you post your suggestion for concrete text?

Here you go (the indented text is the concrete text).

The on-permit-apply-second description doesn't have a non-normative informative description
like the combining rules in the core specification. If you are interested in providing an
informative description (I'm not bothered if you leave out an informative description),
then I suggest this:

    The following is a non-normative informative description of this combining algorithm.

        The on permit deny second combining algorithm is primarily intended for those cases
        where it would be desirable to attach a condition to a policy or policy set. This
        algorithm has the following behavior.

        The input contains an array of children (policies and/or policy sets).

        1.  If there are not exactly two children, then the result is "Indeterminate{DP}".
        2.  Otherwise, if the decision from the first child is "NotApplicable", "Deny",
            or "Indeterminate{D}", then the result is "NotApplicable".
        3.  Otherwise, if the decision from the first child is "Permit", then the result
            is the decision from the second child.
        4.  Otherwise, if the decision from the second child is "Permit", then the
            result is "Indeterminate{P}".
        5.  Otherwise, if the decision from the second child is "Deny", then the result
            is "Indeterminate{D}".
        6.  Otherwise, the result is the decision from the second child.

The pseudo-code is replaced with the following:

    Decision onPermitApplySecondCombiningAlgorithm(Node[] children)
      if (lengthOf(children) != 2) {
        // Use status code urn:oasis:names:tc:xacml:1.0:status:processing-error
        return Indeterminate{DP}
      Decision decision0 = children[0].evaluate();
      if (decision0 == NotApplicable ||
          decision0 == Deny ||
          decision0 == Indeterminate{D}) {
        return NotApplicable;
      Decision decision1 = children[1].evaluate();
      if (decision0 == Permit) {
        return decision1;
      // decision0 is Indeterminate{P} or Indeterminate{DP}
      if (decision1 == Permit) {
        // Use the status code from decision0
        return Indeterminate{P};
      if (decision1 == Deny) {
        // Use the status code from decision0
        return Indeterminate{D};
      if (decision1 == NotApplicable) {
        return NotApplicable;
      // Combine the status codes from decision0 and decision1 (implementation-defined)
      return decision1;

Replace the structure for policy set X and the paragraph following it with this:

        PolicySet X [on-permit-apply-second]
          Target A
          Policy Y
            Rule Z [Permit]
              Condition A
          Policy A:
            Rules of A...

    If Target A is applicable, then the on-permit-apply-second combining algorithm will
    evaluate Policy Y. If Condition A applies, then Policy Y will evaluate to Permit and
    Policy A will be evaluated with the result of Policy A being used as the result
    of Policy Set X. If Condition A does not apply, then Policy Set X returns NotApplicable.

Were you wanting some text on additional uses for on-permit-apply-second that
leverage the ability to turn Deny into NotApplicable?


Best regards,

On 2012-08-28 14:48, Steven Legg wrote:

Hi Erik,

I neglected the fact that the administration profile uses "policy" to mean
policy or policy set. Using the same convention, this is what I should have

The fact that the on-permit-apply-second combining rule restricts the
number of child policies to two means that both child policies must
be trusted policies (there is no room for authorizing administrative
policies). This will have implications for access control on the policies
themselves, which will vary between PAP implementations.

A delegation-friendly change would be to restrict a policy set using
the on-permit-apply-second combining rule to exactly two *access* policies
with no limit on the number of administrative policies. The combining
algorithm would test the first access policy (which may need to be
authorized by an administrative policy) before deciding to evaluate
the second access policy (which may also need to be authorized).

I have previously argued on the comment list that labelling each policy
as an access policy or administrative policy would improve the delegation
profile and resolve a number of issues surrounding category prefixing.
Such labelling would make it easy for the on-permit-apply-second
combining rule to tell the difference between access policies and
administrative policies.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]