XACML v4 Summary Doc

[humantypo]

Here is the first draft of a Summary of v4. I tried to cover the Issues list from a scope perspective, while keeping concepts at a higher level.

Overview of XACML 4.0: Scope and Direction

The OASIS XACML Technical Committee is developing version 4.0 of the specification with the goal of modernizing access control policy definition. A significant focus is on making policy writing more intuitive and efficient, reducing complexity, and introducing support for additional formats like JSON and YAML. This document provides a high-level summary of the key changes relevant to policy writers.

---

1. Support for JSON and YAML Policies

One of the most anticipated updates in XACML 4.0 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.

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 4.0 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. 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.

C. 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

• Variable definitions are now evaluated only when needed, reducing unnecessary computations.
• 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 4.0 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.

---

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. Some of the proposed alternatives include:

• AzL (Authorization Language) with JSON and YAML variants named JAzL and YAzL.
• OAPL (OASIS Authorization Policy Language) to unify different syntax representations.

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

---

Marketing snippet 😄

XACML 4.0 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.

[steven-legg]

@humantypo I was having a go at a summary but you got in before me. FWIW, this is where I got up to. In particular I was avoiding calling the whole effort XACML 4. Use, or not, as you see fit.

The OASIS XACML TC is currently engaged in an effort to produce a successor to XACML version 3.0. The goals 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.

The XACML TC intends that implementions 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 front runner 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.

[humantypo]

I have incorporated your input here, @steven-legg, thoughts?

The Next Generation of XACML: Scope and Direction

The OASIS XACML TC is currently engaged in an effort to produce a successor to XACML version v3.0. The goals 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 front runner 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.

Key Points

---

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.

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. 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.

C. 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

• Variable definitions are now evaluated only when needed, reducing unnecessary computations.
• 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.

---

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. Some of the proposed alternatives include:

• AzL (Authorization Language) with JSON and YAML variants named JAzL and YAzL.
• OAPL (OASIS Authorization Policy Language) to unify different syntax representations.

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

---

Marketing snippet 😄

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.

[steven-legg]

thoughts?

@humantypo Works for me. XACML Next Gen is a suitable overall name for what we are doing.

Variable definitions are now evaluated only when needed

This isn't a new feature. It was already an implementation choice in version 3.0.

[steven-legg]

I added some more cases: 2 D, E, F and 3 D. Some of these are from the closed issues list.

The Next Generation of XACML: Scope and Direction

The OASIS XACML TC is currently engaged in an effort to produce a successor to XACML version v3.0. The goals 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 front runner 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.

Key Points

---

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.

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. 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.

C. 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.

D. 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 difference indicated by a boolean flag.
• Likewise for the various structures related to obligations and advice.

E. 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.

F. Decluttering

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

---

3. Improved Policy Efficiency

A. Optimized Rule Evaluation

• Variable definitions are now evaluated only when needed, reducing unnecessary computations.
• 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. Some of the proposed alternatives include:

• AzL (Authorization Language) with JSON and YAML variants named JAzL and YAzL.
• OAPL (OASIS Authorization Policy Language) to unify different syntax representations.

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

---

Marketing snippet 😄

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.