First of all, let me freely admit that if a number of the many people who have contributed ideas to XACML over the years responded to this question, you would probably receive many different answers. I offer my perspective, plus some historical context as well as what I believe are the basic principles of XACML which we have used to guide our decisions about specific features.
When we started XACML, there was agreement on the goal of using existing work as much as possible. The first source we tapped was the ISO access control model. We immediately adopted the PDP-PEP terminology. ISO also had defined Subject, Resource, Action and Environment as values for what we called attribute Category. At that time, I actually generated a slide deck which argued that there were issues with the Environment, specifically mentioning Session Attributes. However, the TC was satisfied with following ISO and we had many other more significant technical decisions to make for version 1.0.
Early on, we decided that XACML policies would operate directly on existing data to the extent possible, both in the naming of Attributes and format of their data values. We did not choose the path of creating our own access control model and forcing users to map their data to it. In effect we decided that the only semantics XACML cared about were access control semantics and these would be expressed in the policies, not in a data model. As Anne Anderson put it, âan XACML PDP can be viewed as a text processing engine.â
We were committed to XML, both by charter and because one of the original members, Michiharu Kudoh had published work on the use of XML to represent not only the policies, but also the Attributes used to evaluate them. The web A/C people (including me) were more focused on data provided in other ways. This led to the Selector/Designator schemes which are still part of the language.
This principle meant among other things, that distinct attributes maintained separately, might actually have the same identifier. Thus, it was decided that an attribute provided to the PDP and an attribute in a policy would only match if the identifier was the same and the category and datatype were also the same.
Although we invented the Context Handler as a kind of generalized data converter, we wanted to stick to conversions which were straightforward and intuitive. We felt that using XML Schema gave us that for many popular formats and that specifications and implementations were widely available. We also added datatypes we knew would be sure to be useful, such as URL and IP Address.
The sections of the XACML specifications on Environment or Category did not change until XACML 3.0. In the meantime, Rich Levinson promoted the idea of Entities. This was based on the observation that Attributes are associated with concrete or abstract Entities. Every Entity has some finite list of attributes it could potentially possess. Of course, not all the attribute values of a given Entity may be present at the time of a particular access decision for various reasons.
In this view, Attributes are not just free-floating N-tuples, which is more or less how they appear in the XACML core. This way of framing things makes it clear that Category is the name of an Entity Class. XACML does not provide a means to enumerate the Attribute Identifiers which are valid for an Entity Class, but other tooling could do so.
Consistent with this model, although perhaps not based on exactly this reasoning, XACML 3.0 allows Categories to take any value. Environment may still be used, but instead Attributes may be attributed to any Category according to what seems natural in a given problem space.
ÂSteven Leggâs recent work on Time Extensions, reminds us that even Time, that most Environmental seeming Attribute, may be different for the Subject, Intermediary and Resource in the same decision.
Data Modelers and Policy designers are free to select whatever Category is most logical in the specific application context. This might be based on where the Attributes are obtained or their semantics, conceivably on semantics which lie outside of the Attributeâs role in Access Control. For example, you might choose to treat the Session as an entity, or to associate different Session Attributes with distinct Categories, associating Username with Access Subject and Location with Environment.
Hal Lockhart