OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


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


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

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.

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.

A result of "Indeterminate" due to a "Missing attribute" MUST NOT
be returned at the time a policy is parsed.  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".

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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC