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] Request Context and presence of Attributes

The handling of "dynamic" attributes is not specified clearly in
the specification.  Questions:

1) If a <SubjectAttributeDesignator> refers to a particular
   AttributeId, must that AttributeId be present as a <Subject>
   <Attribute> in a physical <Request> document?

2) If a <SubjectAttributeDesignator> refers to a particular
   AttributeId, when must that <Attribute> value be made
   available, and by what entity?  If the PEP did not supply a
   value for the <Attribute>, is the reference passed to the PIP
   at that time the <SubjectAttributeDesignator> is parsed by the
   PDP?  Is it passed to the PIP at the time the value of the
   <SubjectAttributeDesignator> is evaluated by the FunctionId of
   which it is a part?

3) Is there some level of evaluation, say a specific <Target> or
   <Condition> element, that must be parsed and all referenced
   <Attribute>s obtained and stored in the Request context before
   the PDP evaluates the <Target> or <Condition>?

I have included the text of Issues that relate to these
questions below.

It was my understanding from the resolutions to the Issues that
the <Request> context was a "notional" document, and that the
<Attribute>s need not exist in a physical XML document at any
time.  Referencing <Attribute>s as if they were in such a
physical XML document is an abstraction to separate the PDP from
the PIP and from the various protocols required to locate,
retrieve, and parse various AttributeIds.

But the current text (0.18a) does not match my understanding.

a) Section 3.1, "Data-flow model", Figure 1, "Data-flow diagram",
   p. 16, line 514, does not clarify when the data flow between
   the context handler and the PIP takes place.  Can it take
   place at the time the PDP references the Request context?

b) Section 3.1, Data-flow model, Steps 4-8 imply that the
   context-handler somehow knows what Attributes will be required
   by the applicable policies, and retrieves them all from the
   PIP before presenting a complete Request Context document to
   the PDP for evaluation.

c) Section 3.2, XACML context, Figure 2 - "XACML context", shows
   the xacml Context/Request.xml strictly as an input to the PDP,
   implying that it is a static document (or at least a static

d) Section 7.1, "Missing attributes", 4th paragraph, Lines
   2814-2828, paragraph starts with 'If an "Indeterminate"
   decision value is returned, ...": this implies that the
   process of obtaining "missing attributes" is resolved by an
   interchange between the PDP and the PEP, but does not mention
   any such resolution by an explicit or implicit interchange
   between the PDP and the Context Handler, or between the PDP
   and the PIP.

Seth Proctor, who is implementing XACML, does not understand the
"notion" of a "notional" document, or how it would be
implemented.  Eve Maler, however, indicated that XPath DOM,
etc. implementations already have to deal with "notional"

Resolutions of Issues that pertain to this:

Issue 36:
36. [Anne] attribute references and indeterminate results
    Long, verbose, religious, tedious thread starts with:
    Subsidiary thread (pdp status element):

    Some sub-issues and options

    Order of evaluation
    a. In what order MUST arguments be evaluated
       Implementation-dependent unless the function definition
       specifies an order.  orderedOr and orderedAne are the only
       standard functions we have defined that specifies an order.
    b. MUST all arguments be evaluated?
       No, if a result can be returned without evaluating all.  You
       could define a custom function that requires evaluating all
       arguments, but none of our standard functions does this.
    c. MAY all arguments be evaluated, even if not required to reach a
       function result?
       Yes, but can never change the overall result.

    Operational errors (e.g. divide by 0) and missing information
       (AttributeDesignator freturns empty set)
    a. Reporting of errors via the response obtained while evaluating
       a request by PDP:

       Reporting by PDP in the Response is optional.  PDP MAY include
       error information in the Status element of the Response.  PEP
       must not depend on the PDP supplying this information.

    b. Operational errors and missing information are handled as follows
       - Standard OR and ORDERED-OR implementation:

         Evaluate arguments in any order (or in specified order)
         IF (you receive an error or null AttributeDesignator result) {
             Go on to next argument evaluation unless all evaluated
             IF (you get at least one TRUE) {
                  return TRUE
             } ELSE {
                  return error (which may be a set of errors)
         } ELSE IF (you get at least one TRUE) {
              return TRUE
         } ELSE {
              return FALSE

       - Standard AND and ORDERED-AND implementation:

         Evaluate arguments in any order (or in specified order)
         IF (you receive an error) {
             Go on to next argument evaluation unless all evaluated
             IF (you get at least one FALSE) {
                  return FALSE
             } ELSE {
                  return error (which may be a set of errors)
         } ELSE IF (you get at least one FALSE) {
              return FALSE
         } ELSE {
              return TRUE

       - function:present: returns TRUE if argument is
         not empty set.  Returns FALSE if argument is empty set.  If
         evaluating argument results in an error, return error.
       - function:not  returns TRUE if argument is FALSE,
         returns FALSE if argument is TRUE.  If argument results in an
         error, return error.
       - Other standard functions: return "error" if any argument is an
         error or if an operational error in computing the function
       - Custom functions must behave like "Other standard functions"
         unless specific handling of errors is specified.

    c. What is Rule result if Condition evaluates to (exactly same as
       table in v15 of specification):
       - operational Error?
         INDETERMINATE(error=operational error)
       - "necessary information not available"?
         INDETERMINATE (error=missing information)
       - FALSE?
       - TRUE?
         PERMIT or DENY (as specified in rule's Effect)

    d. What is Rule result if Target evaluates to FALSE?

    e. Combining Algorithms must specify how PERMIT, DENY,
       INDETERMINATE, and NOT APPLICABLE are handled.  Standard
       algorithms already do this.

    f. If operational errors are reported, how is the type of
       error reported?
       Reported via Status element in Response

    CLOSED: See decisions above.

41. [Anne] Is a "notional" XML document for Request a good idea?
    http://lists.oasis-open.org/archives/xacml/200207/msg00078.html [2.]
    [Daniel] http://lists.oasis-open.org/archives/xacml/200207/msg00080.html

    CLOSED: notional XML document is not a problem.  In XML,
    everything is a virtual document anyway.  Note: how to
    specify "dynamic" attributes that are not supplied in the
    request from the PEP is a separate issue and is still not
    completely resolved.

61. [All] Dynamic attributes: how are they referenced and retrieved?

    Define a schema for the "static context"?  This would be used for
    conveying cached attributes in the form of a Request Context
    between cooperating PDPs.

    CLOSED: Perhaps define such a schema for a later version of XACML.
    Dynamic attributes are referenced and retrieved through the
    "notional" XACML Request Context regardless of whether they are
    supplied by the PEP or retrieved from a PIP.

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