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

[Polar Humenn <polar@syr.edu>]

On Tue, 8 Oct 2002, Anne Anderson wrote:

> CR: Add new section early in Chapter 7 to describe how the
> Request context is to be handled.
>
> Rationale: This will make the handling of missing attributes more
> clear.  This is related to the issue of the "notional"
> Request.xml that I discussed in
> http://lists.oasis-open.org/archives/xacml/200210/msg00035.html
> "[xacml] Request Context and presence of Attributes" dated 7 Oct
> 2002.
>
> Text:
>
> 7.x Request context
>
> The XACML Request Context is an abstraction that allows a policy
> to refer to attributes "as if" the attributes were in an XML
> document that follows the XACML 1.0 Request Context schema.  This
> applies to both AttributeDesignators and to AttributeSelectors.
>
> Any attributes supplied by the PEP are always available in the
                                         XXXXXX - strike this-not  needed.
> XACML Request Context, as are the subject:subject-category and
> environment:current-time attribute.
>
> Additional attributes may be referenced by a policy "as if" they
> were in the Request Context XML document, although their
> existence may not be determined until the time that they are
> referenced during evaluation of the policy.

STOP HERE. THIS IS GOOD ENOUGH.


> An attribute is first referenced at the time it must be resolved
> in order to evaluate a function.  Function arguments are resolved
> at the time the function is computed, not at the time the
> function is parsed.  Attributes may be cached or collected prior
> to such first reference, but failure to obtain an attribute prior
> to first reference does not affect the decision returned by
> XACML.

I don't know why you have to say anything about caching. It is either
there or the PDP failed to retrieve it. I suggest removing this paragraph.

> If a referenced attribute is not available in the cached list of
> attributes or among those supplied by the PEP, then a request is
> made to the PIP for a value for the referenced attribute.  This
> request is implementation-dependent, and is not visible to the
> PDP.  If the PIP is not able to supply a value for the attribute,
> then a result of "Indeterminate" due to "Missing attribute" is
> returned to the PDP.

This PIP is a non-entity in my mind. There is no interface for it, and
there is no way to distinguish PIP from the PEP or the PDP. Either the PDP
knows where this attribute lives and if it lives. So, I suggest we just
leave it at that.

> A result of "Indeterminate" due to a "Missing attribute" MUST NOT
> be returned at the time a policy is parsed.

I don't see what "parsing" the policy has to do with the evaulation of the
request. The parsing may have happened two years before its evaluation.

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

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