OASIS has announced the successful balloting and approval of the Extensible Access Control Markup Language (XACML) a new OASIS Open Standard. Formal definitions for the XACML language are provided in XML Schema Definitions (a Policy Schema and a Context Schema ). Chaired by Carlisle Adams (Entrust) and Hal Lockhart (BEA Systems), the XACML TC has created an XML specification for expressing policies for information access over the Internet. XACML is designed to enable the expression of well-established ideas in the field of access-control policy. Such a common policy language, "if implemented throughout an enterprise, allows the enterprise to manage the enforcement of all the elements of its access control policy in all the components of its information systems. Managing an authorization policy may include some or all of the following steps: writing, reviewing, testing, approving, issuing, combining, analyzing, modifying, withdrawing, retrieving and enforcing policy."

Bibliographic Information

The XACML Committee Specification is available for inspection as the final version is in preparation.

OASIS eXtensible Access Control Markup Language (XACML). Committee Specification 1.0 (Revision 1). 12-December-2002. Edited by Simon Godik (Overxeer) and Tim Moses (Entrust). Document identifier: cs-xacml-specification-1.0-1.doc. 130 pages. XML Schema Definitions include: Policy Schema and Context Schema. With contributions by Anne Anderson (Sun Microsystems), Bill Parducci (Overxeer), Carlisle Adams (Entrust), Daniel Engovatov (CrossLogix), Don Flinn (Quadrasis), Ernesto Damiani (University of Milan), Gerald Brose (Xtradyne), Hal Lockhart (Entegrity), James MacLean (Affinitex), John Merrells (Jiffy Software), Ken Yagen (CrossLogix), Konstantin Beznosov (Quadrasis), Michiharu Kudo (IBM), Pierangela Samarati (University of Milan), Pirasenna Velandai Thiyagarajan (Sun Microsystems), Polar Humenn (Syracuse University), Satoshi Hada (IBM), Sekhar Vajjhala (Sun Microsystems), Seth Proctor (Sun Microsystems), Steve Anderson (OpenNetworks), Steve Crocker (Pervasive Security Systems), and Suresh Damodaran (Sterling Commerce).

XACML Background

The motivation behind XACML is to express the well-established ideas in the field of access-control policy using an extension language of XML.

The basic requirements of a policy language for expressing information system security policy [providing backdrop to XACML design]:

• To provide a method for combining individual rules and policies into a single policy set that applies to a particular decision request.
• To provide a method for flexible definition of the procedure by which rules and policies are combined.
• To provide a method for dealingwith multiple subjects acting in different capacities.
• To provide a method for basing an authorization decision on attributes of the subject and resource.
• To provide a method for dealing with multi-valued attributes.
• To provide a method for basing an authorization decision on the contents of an information resource.
• To provide a set of logical and mathematical operators on attributes of the subject, resource and environment.
• To provide a method for handling a distributed set of policy components, while abstracting the method for locating, retrieving and authenticating the policy components.
• To provide a method for rapidly identifying the policy that applies to a given action, based upon the values of attributes of the subjects, resource and action.
• To provide an abstraction-layer that insulates the policy-writer from the details of the application environment.
• To provide a method for specifying a set of actions that must be performed in conjunction with policy enforcement.

The "economics of scale" have driven computing platform vendors to develop products with very generalized functionality, so that they can be used in the widest possible range of situations. "Out of the box", these products have the maximum possible privilege for accessing data and executing software, so that they can be used in as many application environments as possible, including those with the most permissive security policies. In the more common case of a relatively restrictive security policy, the platform's inherent privileges must be constrained, by configuration.

The security policy of a large enterprise has many elements and many points of enforcement. Elements of policy may be managed by the Information Systems department, by Human Resources, by the Legal department and by the Finance department. And the policy may be enforced by the extranet, mail, WAN and remote-access systems; platforms which inherently implement a permissive security policy. The current practice is to manage the configuration of each point of enforcement independently in order to implement the security policy as accurately as possible. Consequently, it is an expensive and unreliable proposition to modify the security policy. And, it is virtually impossible to obtain a consolidated view of the safeguards in effect throughout the enterprise to enforce the policy. At the same time, there is increasing pressure on corporate and government executives from consumers, shareholders and regulators to demonstrate "best practice" in the protection of the information assets of the enterprise and its customers.

For these reasons, there is a pressing need for a common language for expressing security policy. If implemented throughout an enterprise, a common policy language allows the enterprise to manage the enforcement of all the elements of its security policy in all the components of its information systems. Managing security policy may include some or all of the following steps: writing, reviewing, testing, approving, issuing, combining, analyzing, modifying, withdrawing, retrieving and enforcing policy.

XML is a natural choice as the basis for the common security-policy language, due to the ease with which its syntax and semantics can be extended to accommodate the unique requirements of this application, and the widespread support that it enjoys from all the main platform and tool vendors. [from the Committee Specification]

Patent Hurdles Overcome

As reflected in the text of the OASIS announcement, negative votes were initially cast against approval of XACML, based upon concerns that its implementation might be subject to royalty fees; see the reference to the OASIS process for resolving negative votes, and the comments [1], [2]. The IPR statements of concern are referenced from the TC's website (IBM, ContentGuard).

In the case of IBM's 15-February-2002 disclosure, the TC engineered around the potential problem: "We intentionally made one feature of the language -- Obligations -- not mandatory to implement in order to make it easier for implementations to avoid a particular feature that might, in some cases, infringe on a known IP claim." In the case of ContentGuard's 26-November-2002 disclosure, the TC felt that the Intellectual Property Rights claims did not stand in the way of royalty-free implementation: "The XACML TC has taken reasonable steps to ensure and to document that all features of this language are derived from previous work in the field that is not under patent restrictions... It is the belief of the TC that useful and fully-compliant implementations of XACML 1.0 can be created that are royalty free. The TC therefore requests that OASIS adopt the XACML 1.0 specification as submitted."

That negative votes were cast against the specification only on principles of openness (potentially encumbered, proprietary technology) suggests that the ability to implement key standards on a royalty-free basis may remain a critical business model concern -- and a basis for casting ballots -- until clearer norms are established.