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

[Daniel Engovatov <dengovatov@crosslogix.com>]

>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.


Not only an operational error - value out of the permissible value space for
the particular data type, or inability of an underlying computational
procedure to produce a result when the value is returned by an another
function application also results in Indeterminate.

What you are suggesting is that PDP should have some sort of an internal
knowledge of what information must be available in the context and signal
any discrepancy via Indeterminate result.  I do not think it is a workable
operational requirement, especially given that we do not specify much about
the internals of our virtual context (and I do not think we should).   Such
intrusion detection is probably the job of the PIP service, and yes - it can
pass Indeterminate value to the PDP if, for example, some SHA signature is
off etc.   But that is not the job of the PDP, and an empty bag is a
critically useful abstraction to use.

If you want to write your policy in the way, that prohibits access if
something is missing - you can.  Polar suggested several different
approaches to this - using present, *-one-and-only will achieve the same
effect.

I do not remember whether we agreed or even discussed my proposal to treat
designator supplied as an argument to a function requiring a single value
attribute as an implicitly wrapped in *-one-and-only type transformation
(but at least several examples used around do treat it that way).
Explicitly stating such an assumption will probably answer your concern - it
does produce Indeterminate on missing attribute, when applied to a function
requiring a singleton..

Daniel.