Have the basic semantics of Target changed in XACML 3.0? - Is thisan issue that needs addressing?

["Rich.Levinson" <rich.levinson@oracle.com>]

To TC:

While perusing the core spec, I noticed what appears to be a possibly subtle but significant change in the semantics of Target. In particular, I think this subtlety shows up wrt the description of Target in section 3.1.1.1, lines 526-528:

"If the rule is intended to apply to all entities of a particular data-type, then the corresponding entity is omitted from the target. An XACML PDP verifies that the matches defined by the target are satisfied by the attributes in the request context."

Also relevant to this discussion is the term "entity" used above, that also shows up in section 5.9 lines1908-1909:

"The <Match> element SHALL identify a set of entities by matching attribute values in an <Attributes> element of the request context with the embedded attribute value."

The "change in semantics" I am talking about can be fairly clearly seen be comparing the above text to its counterparts in XACML 2.0.

In 2.0 section 3.1.1.1, lines 642-645:

"If the rule is intended to apply to all entities of a particular data-type, then the corresponding entity is omitted from the target. An XACML PDP verifies that the matches defined by the target are satisfied by the subjects, resource, action and environment attributes in the request context."

and for example, in 2.0 section 5.8 on SubjectMatch, lines 1964-1966:

"The <SubjectMatch> element SHALL identify a set of subject-related entities by matching attribute values in a <xacml-context:Subject> element of the request context with the embedded attribute value."

The "problem" that I think may have been introduced is that when policy-side <SubjectMatch>, <ResourceMatch>, <ActionMatch>, <EnvironmentMatch> were reduced to a generic <Match> in 3.0, that the implicit "category" or "entity-type", conveyed by "Subject", "Resource", "Action", "Environment" was not included in the policy-side definitions. However, it was retained on the Request side with the Category element defined on lines 2794-2798:

"Category [Required]
This attribute indicates which attribute category the contained attributes belong to. The Category attribute is used to differentiate between attributes of subject, resource, action, environment or other categories."

What I believe is needed is some notion of "Category" on the Policy side. As it stands now, it appears to me that Target can contain a random selection of AttributeSelectors and AttributeDesignators, which are unrelated by Category in the <AllOf> and <AnyOf> elements of Target, which previously were represented by <Subject> and <Subjects> elements in 2.0 (as well as corresponding for Resource, Action, and Environment).

As it stands statements like the one at the top of this email where it is stated:

"If the rule is intended to apply to all entities of a particular data-type, then the corresponding entity is omitted from the target."

do not appear to have any meaning. Note that it appears that "data-type" was not used properly in these statements, and that it probably should be replaced by "entity-type" both in 2.0 and 3.0. I am not aware of any interpretation of the above statement where "data-type" has any semantic meaning in the XACML sense. Clearly, the things that are omitted are Subject, Resource, Action or Environment, or in 3.0 any specific "Category". However all these "entities" or "categories" can contain a set of Attributes with differing "data-types" to which no significance in this context is relevant.

Another example of a possibly "meaningless" statement is in section 5.6, lines 1867-1869:

"The <Target> element SHALL contain a conjunctive sequence of <AnyOf> elements. For the parent of the <Target> element to be applicable to the decision request, there MUST be at least one positive match between each <AnyOf> element of the <Target> element and the corresponding section of the <Request> element."

I do not see how there is a determined a "corresponding section" to an <AnyOf> element. Because there is no Category on the AnyOf element there is no restriction on the Category of any of the descendant Attribute Designators or Selectors, and if there are more than one Category associated with different Match elements within an AllOf, then there is no "upward" way to set an unambiguous Category.

Possibly the <AnyOf> and possibly the <AllOf> and <Match> elements could use a Category xml attribute to restore the original intent of the Target semantics? i.e. the point would be to restore the connection between the groupings of Match statements within AnyOf, AllOf, and the specific Category in the Request. Also, I allow for the possibility that this is an unnecessary restriction, which I recognize that technically it is unnecessarily, but semantically, has it been so generalized as to totally lose the intended semantics?

Also, I recognize that Category is a required attribute of the AttributeSelectors and the AttributeDesignators, however, there appears no restriction by <Target>, <AnyOf>,<AllOf>, or <Match> which would control their grouping within the Target.

Also, I recognize that the old semantics can be retained by "convention" for Policy designers, but this is a "convention" that was not required by 2.0.

Maybe I have missed something, in which case we can put this in the "Never mind" folder.

    Thanks,
    Rich