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

[Anne Anderson <Anne.Anderson@Sun.com>]

On 18 October, Daniel Engovatov writes:
 > 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.

I believe it is your interpretation that suggests that the PDP
has some sort of internal knowledge about what information must
be available in the context.  I am being very clear in saying
that the PDP does NOT have that knowledge, and if it is unable to
find an attribute that is referenced by an AttributeDesignator,
for whatever reason, it will ALWAYS return "Indeterminate" as the
result.

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

a) I can't use those in the Target
b) If I try to use an attribute whose retrieval could fail in a
   Target, then the Target will evaluate to NotApplicable.  This
   will happen even if a temporary network glitch was the cause
   for the attribute retrieval failure, and even if the policy
   has a "Deny" effect and would have caused me to deny access
   had the attribute been available.

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

That would answer only one concern.  I agree, however, that if we
accept your interpretation, we must spell this out.

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