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 representation). 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" documents. Resolutions of Issues that pertain to this: Issue 36: 36. [Anne] attribute references and indeterminate results Long, verbose, religious, tedious thread starts with:
http://lists.oasis-open.org/archives/xacml/200207/msg00071.html Subsidiary thread (pdp status element):
http://lists.oasis-open.org/archives/xacml/200207/msg00140.html 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 occurs. - 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? NOT APPLICABLE - TRUE? PERMIT or DENY (as specified in rule's Effect) d. What is Rule result if Target evaluates to FALSE? NOT APPLICABLE 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