Re: [xacml] bags and targets. Forwarded message from Seth Proctor.

[Polar Humenn <polar@syr.edu>]

Anne,

A *Match does not return indeterminate, unless something is wrong
operationally. The predicate is there an attribute that matches? If there
is no attributes of that name, then the information isn't there.

If you really want an indeterminate, you may wrap the attribute designator
in an apply of "*-one-and-only". This forces an Indeterminate error if
there isn't one attribute. Simiarly, you can write "*-greater-than" on the
"*-length", etc.

I strongly suggest that policy writers should not be relying on
"Indeterminate" for evaluations.  It is an error condition, not a valid
access decision.

Writers (or should I say their tools) should be using "present" in boolean
expressions that lead to the desired effect.

Cheers,
-Polar

On Fri, 18 Oct 2002, Anne Anderson wrote:

> On 17 October, Polar Humenn writes: Re: [xacml] bags and targets. Forwarded message from Seth Proctor.
>  > This sentence means exactly what it says. If the the selector or
>  > designator evalutates to an empty bag, then there is no match, i.e. the
>  > match "predicate" is False.
>  >
>  > The match predicate is akin to asking, "Do you have one or more of any
>  > subject ids that match "john.*". If you have none, then False, if you have
>  > at least one, then True.
>
> Are you saying that the result will be "False", rather than
> "Indeterminate", when an not-found attribute is compared to a
> value?
>
> If so, I think this is wrong.  If we can't find an attribute
> value in the Request Context, for whatever reason, then the
> result should be "Indeterminate", because there MAY be such a
> value available somewhere and we simply weren't able to get it.
>
> If your application needs to know for sure that something is not
> available (e.g. "Is this person a convicted felon?"), then the
> application needs to use a positive attribute like "Is not a
> convicted felon", where a trusted authority makes a positive
> assertion that such information is missing, rather than depending
> on a missing "Is a convicted felon" attribute.
>
> We really need to pin this down.  Daniel, I think, says that only
> some sort of operational error in talking to the PIP or
> repository would result in "Indeterminate".  But we can't
> guarantee that an error would be detected or that the PDP wasn't
> querying the wrong PIP or repository.  A classic security breach
> is to make something silently unavailable (unplug a relay,
> re-route a message, etc.), and use that to access systems that
> assume something that is not available is false.
>
> If an attribute is not present, then the PDP doesn't know what
> its value is, and the result should be "Indeterminate" - which
> means "the PDP is unable to determine the result".
>
> 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>
>