XACML v3.0 Errata
NOTE: Text that has been struckthrough has been addressed via Errata.
1 Definition of Target
Target: The set of decision requests, identified by definitions for resource, subject, environment, action, or other custom attributes that a PDP is intended to evaluate according to the applicable rule, policy, or policy set
2 Namespace Context for XPath Expressions
The core specification is not clear about what constitutes the "context" that is used to resolve namespace prefixes appearing in XPath expressions, either in xPathExpression values or in the Path XML Attribute of an AttributeSelector. The examples in the core specification are consistent with that context being the [in-scope namespaces] of the <AttributeValue> and <AttributeSelector> elements respectively.
See this email thread for discussion: https://lists.oasis-open.org/archives/xacml-comment/201308/msg00000.html .
Note from Erik: For XPathExpression this is defined in Appendix A.2: "When the value is encoded in an <AttributeValue> element, the namespace context is given by the <AttributeValue> element". For the attribute selector, this is implicitly defined by the evaluation procedure in section 7.3.7.
3 Number of Minor Status Codes
Section 5.55 of the core specification says that a <StatusCode> element contains "an optional sequence of minor status codes" and the description of the <StatusCode> child element indicates there can be "Any Number". However, the XML Schema definition allows at most one <StatusCode> child element. Either the text or the XML Schema needs to change.
Note from Erik: The sequence is in the form of nested <StatusCode> elements. Both the spec and the schema allow for optional nesting of status codes and the spec says that the child code qualifies the parent code. I see nothing wrong here.
4 Multiple Category Elements
Specific cases of multiple category elements need definitive process descriptions; in particular, is there requirement that a pdp decision must be based on at most one element per category per decision. LinkToArchives
Note from Erik: The core spec is intended to operate only on single instances of a given attribute category. Anything else is specified in the multiple decision profile. This is stated in section 5.42 "There may be multiple <Attributes> elements with the same Category attribute if the PDP implements the multiple decision profile, see [Multi]. Under other conditions, it is a syntax error if there are multiple <Attributes> elements with the same Category (see Section 7.19.2 for error codes)."
5 Keyword Usage
Section A.3.5 of the core spec says on line 4259 MAY NOT, but should say may not.
6 Policy Identifier List
In section 5.48 of the core spec, begining at line 2921, replace:
. If the ReturnPolicyIdList attribute in the <Request> is true (see section 5.42), a PDP that implements this optional feature MUST return a list of all policies which were found to be fully applicable. That is, all policies where both the <Target> matched and the <Condition> evaluated to true, whether or not the <Effect> was the same or different from the <Decision>.
. If the ReturnPolicyIdList attribute in the <Request> is true (see section 5.42), a PDP that implements this optional feature MUST return a list which includes the identifiers of all policies which were found to be fully applicable, whether or not the <Effect> was the same or different from the <Decision>. The list MAY include the identifiers of other polices which are currently in force, as long as no policies required for the decision are omitted. A PDP MAY satisfy this requirement by including all policies currently in force, or by including all policies which were evaluated in making the decision, or by including all policies which did not evaluate to “NotApplicable”, or by any other algorithm which does not omit any policies which contributed to the decision. However, a decision which returns “NotApplicable” MUST return an empty list.
Note from Martin: the most useful lists IMHO would be (1) all evaluated policies for this request; and (2) all that contributed to the decision. The former would be useful for verifying that all intended policies are in fact evaluated; the latter for forensics, i.e., why was this access allowed. Of course, to really answer that question the values of the attributes at decision time would have to be captured.
The revised text covers these cases but it's not clear how the using organization can tell which version(s) of the list are being returned if implementers have a choice.
Note from Hal: The PEP can request any or all of the Attribute values be returned as a part of decision result. Further, using the signature Profile, this result can be signed by the PDP, thus providing a complete receipt of the decision.
This assumes 1) that every Policy Id refers to a unique policy, i.e. the Policy Id gets changed every time the policy gets changed, at least in a production environment and 2) that consumers of this information have a way to obtain policies by Policy Id.
I am not aware of any usecase for this feature in which the difference among the allowable sets of policy id lists has any impact, except possibly performance. Inotherwords, including irrelevant policies can never affect the decision.
7 Attribute Selector Result
The core specification doesn't detail what the response of evaluating the <AttributeSelector> should be when either an <Attributes> element specified by the Category XML attribute doesn't exist in the request context, or such an <Attributes> element does exist but it doesn't have a <Content> child element (it being optional). Section 7.3.7, which describes attribute selector evaluation, assumes both are present as a starting point.
The description of the <AttributeDesignator> element says to consider the MustBePresent XML attribute if no matching attribute is found, but the description of the <AttributeSelector> element doesn't have anything similar. Its definition of the MustBePresent XML attribute only says what to do "in the event the XPath expression selects no node". If the <Attributes> or <Content> element are absent we don't get as far as evaluating the XPath expression. Section 7.3.7 talks about constructing a stand-alone XML document from the contents of the <Content> element. We can't simply assume an empty element if it isn't actually present because the <Content> element must have a child and an XML document must have a root element. Without a valid XML document there is no context node to which to apply the XPath expression.
Consistency with attribute designators would suggest deferring to the MustBePresent setting when an attribute selector doesn't find the <Attributes> element or the <Content> element. Note that Section 7.3.5 says "If the attribute is missing, then MustBePresent governs whether the attribute designator or attribute selector returns an empty bag or an “Indeterminate” result". The statement is bogus in the case of an attribute selector because it isn't an attribute that is missing. Whether it really meant an empty node set or something more is open to interpretation.
We appear to have consensus on a fix - https://lists.oasis-open.org/archives/xacml/201506/msg00007.html
Here are suggested text revisions:
. "This attribute governs whether the element returns “Indeterminate” or an empty bag in the event the XPath expression selects no node."
. "This attribute governs whether the element returns “Indeterminate” or an empty bag in the event that the attributes category specified by the Category attribute does not exist in the request context, or the attributes category does exist but it does not have a <Content> child element, or the <Content> element does exist but the XPath expression selects no node."
In Section 7.3.7, AttributeSelector evaluation:
. "1. Construct an XML data structure" ...
. "1. If the attributes category given by the Category attribute is not found or does not have a <Content> child element, then the return value is either “Indeterminate” or an empty bag as determined by the MustBePresent attribute; otherwise, construct an XML data structure" ...
To the end of step 3, ADD:
. "If the evaluation returns an empty sequence of nodes, then the return value is either “Indeterminate” or an empty bag as determined by the MustBePresent attribute."
Section 4.2.2: the data type of JSON propery "CategoryId" is defined as anyURI (I assume like Category attribute in XACML 3.0, i.e. XSD-1.0-defined anyURI). But the data type of other JSON properties (e.g. AttributeId, Datatype, Category) is defined simply as URI without refering to a specific URI standard. Is URI the same as anyURI in XACML 3.0 (XSD 1.0 à RFC 2396) or something else (e.g. RFC 3986) ? This should be clarified. In particular, if you use JSON schema to validate input – which I tried to do – and use the built-in type “uri”, this refers to RFC 3986.
In 8.1 Request Example,
(a the Attribute object in Action category is not a JSON array although it should, according to 4.2.4. (b typo: “ AttributeId” (one space too many) instead of “AttributeId” for the location attribute of AccessSubject.
Value & Content
Security consideration: the attribute Value and Content items can be any arbitrary object of arbitrary depth and/or string of arbitrary length, resulting in possible denial of service from the PDP. I think the spec should mention this issue somewhere (like section 9 in XACML 3.0). On a side node, section 9 of XACML 3.0 could also mention the same kind of issue with AttributeValues or Attributes/Content possibly containing arbitrary XML elements of excessive depth or text size.
The StatusCode member of the Status object is optional in the JSON profile whereas it is mandatory in the XML representation. It was the editors' intention that an absent StatusCode member should be treated the same as a StatusCode object with the Value member set to "urn:oasis:names:tc:xacml:1.0:status:ok".
The proposed correction is to change the default value of the "StatusCode" member in Table 12, Section 5.2.2 from "None" to "See text." and to add this paragraph at the end of Section 5.2.2:
The StatusCode member is optional. If it is not specified then we assume it is equivalent to a StatusCode object with a Value member with the default value as defined in section 5.2.4, The StatusCode object representation (i.e., "urn:oasis:names:tc:xacml:1.0:status:ok").
CS02 - Comments
"...the last sentence of 2.2.1 Entry Point which says: The XACML entry point representation that is returned SHOULD NOT contain anything other than links to other resources specified in this profile." "However, the assertion urn:oasis:names:tc:xacml:3.0:profile:rest:assertion:home:pdp does not mention that requirement again but simply says: The XACML entry point representation SHOULD contain a link to the PDP." (ref: https://markmail.org/message/ivrci34de5nestxl?q=%22REST+Profile%22+%22Entry+Point%22+list:org%2Eoasis-open%2Elists%2Exacml-comment)
Problem framed, issues discussed. (ref: https://lists.oasis-open.org/archives/xacml/201708/msg00012.html)
TC adopts Option 1 from previous link. No action deemed necessary in this version. (ref: https://lists.oasis-open.org/archives/xacml/201708/msg00012.html)