Re: Delegation and on-permit-apply-second

[Steven Legg <steven.legg@viewds.com>]

Hi Erik,

On 5/09/2012 11:27 PM, Erik Rissanen wrote:
> Hi Steven,
>
> I think this looks all good to me. If nobody else objects, I'll change it accordingly.
>
> I would prefer to keep the text short, rather than add more examples. I guess we could add a sentence or two
> if you have something nice to add.

Not something short. I was going to suggest some text on this but found
it would take a few paragraphs to do justice to these other use cases,
so I asked the question instead. I don't feel strongly that we need
further examples, so let's not bother.

Regards,
Steven

> Best regards,
> Erik
>
>
> On 2012-09-03 06:07, Steven Legg wrote:
> > 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?
> >
> > Regards,
> > Steven
> >
> > > Best regards,
> > > Erik
> > >
> > > 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
> > > > said:
> > > >
> > > > 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.
> > > >
> > > > Regards,
> > > > Steven