Re: [xacml] [CR] New Section 7.x: Request context

[Polar Humenn <polar@syr.edu>]

Anne,

I believe we already have that. I think with the definition of "OR" we
have, or even the policy combinators. that you cannot issue an
indeterminate without evaluating the consitiuents is a particular manner.
This manner will preserve the attribute monotonicity you are looking for
(between implemenations).

An "optimizing compiler", one that is scanning policy for required
attributes, that doesn't take into account the expressions the
AttributeDesignators appear in, isn't a very good compiler, and needs to
revisit some old course work. :)

If you have an expression, such that A, B, C, are needed attributes
	( (A /\ B) \/ C )
means that Attribute A, B are required or C is required, and not that A,
B, and C are required.

Policy Interpreters will do the same thing by the nature of evaluating on
the fly, so there is no worry there.

However, if you want something like that, we should probably say it down
at the combinator level, and not up at the PDP response level.

-Polar


On Wed, 9 Oct 2002, Anne Anderson wrote:


> On 8 October, Polar Humenn writes: Re: [xacml] [CR] New Section 7.x: Request context
>  > >  A result of "Indeterminate" MUST NOT be returned unless the
>  > > immediately enclosing function that references the "missing attribute"
>  > > is actually executed.  For example, if two AttributeDesignators are
>  > > supplied as arguments to "function:or", and the first
>  > > AttributeDesignator returns a value of "true", then the result of the
>  > > "function:or" is "true" even if the second AttributeDesignator, if
>  > > evaluated, would have returned a result of "Indeterminate" due to
>  > > "Missing attribute".
>  >
>  > I don't know what you are trying to prevent here. What you are giving is
>  > semantics of Indeterminate that are needed down at the function:or or
>  > function:and specification and not at the PDP response level.
>  >
>  > I would just go with the first three paragraphs.
>
> I would be happy to eliminate everything after the first three
> paragraphs up to the paragraph above; I agree, we do not need to
> discuss caching and the interaction with the PIP.
>
> But I really think this last paragraph is important.  I am trying
> to provide a conceptual model for the interpretation of attribute
> references.  What I am trying to prevent is having
>
> 1) One PDP return Indeterminate after pre-scanning the policy and
>    finding there is one attribute somewhere in the policy that it
>    will not be able to provide a value for.
>
> 2) Another PDP return Deny or Permit for the same policy and the
>    same set of retrievable policies because the missing attribute
>    occurs as the second argument to a function:or where the first
>    argument evaluates to TRUE.
>
> I want to make it clear that 2) is the intended model, and not 1).

But that puts an overly dynamic operation to the evaluation of the policy.
It cannot be optimized for fear of issuing an indeterminate.

In 1, if the PEP offers all requested attributes, he will be guarrantteed
an Effect. (or at least an Indeterminate without any missing attributes).

This will be the case in 2 as well.

What we don't want is for 2 to come up with Indeterminate, while 1 comes
up with an Effect.

> Anne
> --
> Anne H. Anderson             Email: Anne.Anderson@Sun.COM
> Sun Microsystems Laboratories
> 1 Network Drive,UBUR02-311     Tel: 781/442-0928
> Burlington, MA 01803-0902 USA  Fax: 781/442-1692
>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>