Help Guide the Next Generation of XACML

12 Jun 2025

Security

The OASIS XACML Technical Committee (TC) is currently engaged in an effort to produce a successor to XACML version 3.0, and we’re looking for input from the community. The goals of this new version(s) are:

To modernize the language to make it more accessible to a wider audience,
To add new features to extend the expressibility of the language and support new use cases, and
To simplify the language where possible.

The headline change is the decision to abstract the core language to remove its dependence on XML and XML Schema, i.e., to make it syntax-agnostic. This will facilitate the use of other syntaxes for representing the core language. The TC has decided to define representations for at least JSON and YAML, while continuing to support XML. To reflect this expanded scope and modernized approach, the effort is being referred to as “XACML Next Gen” rather than “XACML 4.0.”

The XACML TC intends that implementations will be able to claim conformance with the core language by implementing one or any combination of the possible syntaxes. XML will not be required.

There is a strong desire in the XACML TC to find a new name for the core language to show that it is no longer tied to XML. Various suggestions are on the table, but there is no clear frontrunner at this time. The new name should lend itself to distinct acronyms for each supported syntax for simple identification. Regardless of the new name and version number for the core language, there is consensus in the TC that the XML representation of the core language will be known as XACML 4.0 in recognition of its antecedent. So the moniker “XACML 4.0” will reference only part of the TC’s eventual outputs.

The major structural change to the core language is the merging of PolicySet and Policy into a single construct that will carry the name “Policy.” A new Policy may contain embedded policies, policy references, rules, and variable definitions. This change removes some duplication from the core language where essentially the same thing was defined under separate names for both policy sets and policies, for example, PolicySetId and PolicyId. There is now only PolicyId. There are no longer separate policy combining algorithms and rule combining algorithms, just combining algorithms.

Current Changes In Progress

1. Support for JSON and YAML Policies

One of the most anticipated updates in XACML Next Gen is the addition of JSON and YAML as alternative policy representation formats. While XACML has traditionally been based on XML, these new formats aim to:

Simplify policy authoring by providing more concise and readable structures.
Improve integration with modern applications that rely on JSON-based APIs.
Reduce verbosity compared to XML, making policies easier to maintain.
Improve readability and auditability by allowing the substitution of many URIs with short string names using standardized and user-defined vocabularies.

Implications for Policy Writers:

Policies can now be expressed in JSON or YAML, reducing the learning curve for those unfamiliar with XML.
JSON and YAML formats align with modern infrastructure-as-code practices, allowing policies to be managed like other configuration files.

2. Simplified and More Efficient Policy Structure

To make policies easier to write and maintain, XACML Next Gen is introducing:

A. Flattened Policy Hierarchy

The distinction between Policy and PolicySet is being removed, creating a single structure that can contain both rules and sub-policies.
This means fewer elements to track and simplifies how policies are nested and combined.

B. Common Structure for Obligations and Advice

The structure of an obligation or advice instance is practically the same, except for naming. Obligation and Advice will be replaced by a common Notice structure with the semantic differences indicated by a boolean flag.
Likewise, for the various structures related to obligations and advice.

C. Targets Revised

Targets in policies have been changed to Boolean expressions, giving them the same expressive power and flexibility as Conditions in rules.
Targets have been removed from rules; a Condition is sufficient.

D. Decluttering

CombinedDecision, ReturnPolicyIdList, and MustBePresent have been given sensible defaults so that they can usually be omitted, reducing clutter.

E. Global Variables for Reusability

Variables will be defined globally and reusable across multiple policies, reducing redundancy and improving clarity.
Policy writers will be able to import global variables without having to redefine them within each policy.

F. Composite Functions for Simpler Expressions

Policy authors will be able to define custom functions that can be reused across multiple rules, reducing repetition.
Example: Instead of repeating the same logical expression in multiple places, writers can define it once and reference it when needed.

3. Improved Policy Efficiency

A. Optimized Rule Evaluation

New ternary conditional functions (similar to a ? b : c in programming languages) allow policy writers to define logic more concisely.

B. Aggregate Functions for Policy Simplification

XACML Next Gen will introduce functions like min, max, sum, and average, enabling policy writers to perform calculations on groups of attributes without excessive nesting.

C. Shortcuts for Common Operations

New functions like empty-bag() and non-empty-bag() make it easier to check for missing attributes without verbose expressions.

D. JSONPath

Support for JSONPath will be added to the language. Like support for XPath, it will be optional to implement.
Support for newer XPath versions will be added.

4. Naming and Structural Changes

To better reflect its expanded scope beyond XML, there are ongoing discussions about renaming XACML to something more format-agnostic. Current discussion can be viewed [here].

Regardless of the naming decision, the XML version will continue to be referred to as XACML, ensuring backward compatibility.

XACML Next Gen is shaping up to be a more flexible, efficient, and modern policy definition framework. By introducing JSON and YAML, flattening policy structures, and adding global variables and composite functions, the new version aims to make policy authoring easier and less error-prone, while the addition of canonical string identifiers will significantly improve the readability and audibility of policy corpora.

We Want Your Feedback

The XACML TC is eager to hear from the broader community as we move forward with this next-generation effort. Whether you’re a longtime implementer, a policy expert, or simply someone with a stake in access control, your input can help shape a modern, more accessible, and flexible standard. We’re especially interested in feedback on new feature requirements, potential use cases, naming ideas for the core language, and thoughts on the move toward syntax-agnostic design. If you’d like to get involved or share your perspective, please contact us via our GitHub project.

Authors

Steven Legg, Editor, OASIS XACML Technical Committee
[LinkedIn Profile]

William Parducci, Co-Chair, OASIS XACML Technical Committee
[LinkedIn Profile]