1. Introduction
The Workshop on Access Control Application Scenarios gathered participants from research and industry together to discuss new uses and potential shortcomings in access control. As XACML is a widely used language, most papers and input to the workshop referred to it. But the discussions weren't strictly limited to XACML: There was some focus on using XACML to implement privacy friendly identity management, but the variety of use cases and papers submitted led to more general discussion. As a result, the Workshop identified extension points for XACML that are further detailed below.
2. Attributes
The workshop gathered many people with solutions for very specific issues. As was already mentioned in the call for participation, privacy was one of them. Privacy has a special relation to access control. Therefore, privacy friendly access control scenarios were presented. Mostly, they used XACML out of the box, but added the necessary semantics. XACML creates interoperability by allowing a unified access control over a heterogenous IT landscape. But to expand to inter-enterprise interoperability or to wider use on an Internet scale, XACML needs semantics filling out its own framework that makes access control conditions predictable and interoperable even where there was no prior agreement on the semantics of the access control conditions.
The participants agreed that the basis for a more widespread use of XACML are met as the language is already widely used and implemented in closed shop scenarios. This gives the right momentum to expand further into the Internet sphere.
XACML Policies take a number of kinds of Attributes as inputs. Subject Attributes are most often used and the last ten years has seen the development of a variety of mechanisms for accessing and distributing them. The second most frequently used type is Resource Attributes. Currently there are almost no standards for storage, retrieval or distribution of Resource Attributes. In both case, current practice is largely to define Attribute syntax and semantics on an ad-hoc basis. This approach with its risk of homonyms and synonyms and half matching semantics is lacking a consistent approach to cross company border interoperability for access control.
The participants presented their vocabularies during the Workshop. PrimeLife presented a privacy vocabulary. UPC presented access control using FOAF and ODRL together to get the necessary semantics while using XACML for the policies. Other work on attribute vocabularies for export control, geospatial data and health care data were presented in the workshop. The gap between natural language and formal languages is huge. The reduction of complexity of the former into the latter is tricky and needs further work.
The chair invited all participants to contribute their semantics to the TC XACML that could act as a clearing house for those ontologies. This way, duplication of attributes could be avoided and a cleared vocabulary could be standardized for a wider audience.
But the relations of attributes to each other are also of high interest as it allows for complex scenarios and evenly complex matching algorithms. These are out of scope for the current charter of TC XACML and are much closer to Semantic Web initiatives. Vocabularies making use of such relations should be contributed to W3C's Policy Language Interest Group (PLING).
In a more complex scenario, as presented on the Workshop, with multiple distributed decision points, matching of policies can be challenging. On several occasions, the question about a standardized matching came up. But matching by itself does not seem to be sufficient. Furthermore, a mechanism to create the resulting agreement has to be drawn up, including a feedback mechanism in case the matching fails to produce an agreement and the parties wonder why. Finally, a mechanism to visualize XACML Policies was suggested to ease the complexity and allow people to understand what the policy actually means to them.
As XACML 3.0 is in freeze right now to push the Drafts on to the OASIS standardization track, there is not much space for changes that would change the Schema. But changes which simply involve profiling the use of existing XACML features can be accommodated at any time. For example, the attribute semantics actually operate within the current XACML framework and are, thus, independent of the current Drafts and their evolution. A separate evolution of attribute specifications was encouraged and a corresponding initiative should be brought to the TC XACML.
Many of the participants in the workshop are affiliated with organizations which are already members of OASIS and could join the XACML TC immediately. In other cases, it may be desirable to join OASIS. Non-members can contribute by posting to the XACML comment list, which only requires signing a short feedback agreement. For information, see the comment submission page.
3. Sticky Policies
An important new application area called data handling was represented in a number of workshop papers. Data handling refers to the distribution and storage of information relating to individuals. The primary requirement here is privacy protection. In order for privacy to be protected at all times, the privacy polices must travel with the data, and every party that receives and distributes the data must enforce them. This capability is referred to as sticky polices.
The workshop discussed the binding of a policy to a traveling resource but also to the transfer of data sets and the policing of data warehouses. Apart from the missing interoperability on the semantic side, there is a need for policy expression and a need for a means to transport and bind policies. A parallel issue exists for DRM too. Binding policy to data that survives cascades of XACML PDPs would be an extension to XACML. People largely agreed that this extension is needed. There are several possibilities that could co-exist. There was discussion about using a binding like in XML Signature (detached and in line). There could be an online data store that contains the bindings, so the PEP could just ask there. The policy could also be bound to the payload. The Workshop did not decide in favor of either of the solutions.
Participants then went on to discuss the probability of whether the agreed policy will be followed. Several scenarios about enforcement were drawn up: This turned into a discussion about trust. People also agreed that the term "policy" in this sense was the agreement between both sides. This means there must be a mechanism on policy agreement and a format as a result of this agreement. But can the enforcement by the remote PEP be trusted? Do we need a system for revocation of allowances? CARML of Liberty Alliance was mentioned as one of the possible formats to use. But it would again require the elaboration of further attributes. The different participants in the workshop were encouraged to push the different suggestions presented on to TC XACML for further consideration and to actively defend those viewpoints during standardization.
An additional issue came up while considering that access policies with conditions travel around. The sending service has a set of policies, but also the receiving service has already a certain set of policies (endogenous policies). In practice, those policies must be combined in order to compute a concrete result on whether access can be granted, or whether the receiving service is able to accommodate the requirements from the sending service. It became quickly clear that the combinability of policies turns into a major requirement once more complex distributed systems or ad-hoc systems are considered. There are several algorithms already available, but none of them is currently standardized. But standardization of the algorithm of combination is needed to design policies and systems with predictable results. XACML currently provides a built in set of policy combining algorithms, but work is need to determine their suitability for this application.
4. Obligations
For privacy policies but also for other areas to be policed, there are conditions and actions that are not tied to an access control event. For the moment, XACML has an intentionally underspecified <Obligation> element that people were using in creative ways. But this underspecification has the side effect of undermining interoperability of such obligations. Thus, one cannot be sure whether the specified actions are actually performed by the receiving service. One of the immediate requirements was that if the receiving service doesn't understand the obligation, it should deny access with a feedback to the requester.
PrimeLife inherited an obligation language from the PRIME project and developed it further. This was presented at the workshop. Also, TAS3 presented an original use of the <obligation> element to the audience and argued for possibility to use multiple obligation languages. The protocol towards an agreement on which language to use was seen as the corner stone for further interoperability. Others suggested the use of Semantic Web technologies and the use of the W3C Rule Interchange Format (RIF).
XACML 3.0 has several new features in this area. In addition to Obligations, which relate to access control enforcement, a new element called Advice can be used to associate any information with a decision. There is also work currently in draft form to define families of semantics for Obligations. The latest draft is the 28 December 2007 Working Draft of XACML v3.0 Obligation Families version 1.0. But there were still too many open questions to come to a conclusion. Several projects announced that they will coordinate their efforts to come up with a suggestion for TC XACML.
5. Credential based Access Control
Credential based Access Control would allow for a more privacy friendly access control system that would also be more widely useable on the Web. The aim is to prove only selected attributes as need for the task at hand. There is already a large set of literature on capabilities, but XACML currently does not have the ability to identify the type of credential used nor to specify, which credential is needed to get access to a certain resource. This is more or less a special case of the attributes topic with additional protocol issues. One way to convey the credential would be to use SAML, but SAML only allows XML Signature as a proof token.
Somewhat in the same direction but with a different angle was the question on how to establish a user feedback channel in XACML, so that missing credentials and things can be given by the user interactively. This would prevent the current "give-me-all-you-have" approach.