Fact-checked by Grok 2 weeks ago

XACML

eXtensible Markup Language (XACML) is an XML-based standard developed by the Organization for the Advancement of Structured Information Standards () for expressing, combining, and evaluating policies in a declarative, fine-grained, and attribute-based manner. It enables the definition of security rules that specify what actions subjects (such as users or systems) can perform on resources under specific conditions, using attributes from subjects, resources, actions, and environments to make authorization decisions. The standard supports complex policy structures, including rules with conditions, obligations (actions to take upon permit or deny), and combining algorithms like deny-overrides or ordered permit-overrides to resolve conflicts between multiple policies. XACML's architecture separates policy administration, decision-making, and enforcement to promote flexibility in distributed systems. Key components include the Policy Administration Point (PAP), which creates and manages policies; the Policy Decision Point (PDP), which evaluates applicable policies against a request to issue decisions like permit, deny, or not applicable; the Policy Enforcement Point (PEP), which intercepts access requests and enforces PDP decisions; the Policy Information Point (PIP), which retrieves attribute values needed for evaluation; and the Context Handler, which handles communication between components by formatting requests and responses. This model allows externalization of access control logic from applications, supporting enterprise-wide policy consistency across heterogeneous environments. The standard has evolved through several versions since its inception. Version 1.0 was approved in 2003, introducing the core policy language and architecture; , ratified in February 2005, added features like variable definitions and policy delegation; and Version 3.0, approved on January 22, 2013, enhanced capabilities with hierarchical resources, multiple decision profiles, and improved support for privacy and obligations. XACML remains the primary standard for (ABAC), widely used in systems to address limitations of (RBAC) by incorporating dynamic, context-aware policies.

History

Origins and Early Development

In the early 2000s, the need for a standardized, XML-based policy language emerged to enable fine-grained in increasingly complex enterprise environments, addressing limitations of traditional (RBAC) systems that lacked flexibility for attribute-based decisions and distributed administration. This conception was driven by regulatory pressures and the demand for interoperable security policies across heterogeneous systems, where existing mechanisms struggled with expressing nuanced authorization rules involving user attributes, resource characteristics, and environmental factors. XACML was envisioned as an extensible framework to support (ABAC), extending beyond RBAC's rigid role assignments to incorporate dynamic, -driven evaluations. The Extensible Markup Language (XACML) Technical Committee was formed in April 2001 following a call for participation, with its charter finalized in July 2001, marking the start of formal initial work. Influenced by emerging XML standards, including the Security Services Technical Committee's work on SAML for identity assertions and attributes, as well as LDAP for directory services, the committee aimed to define a core for policies that ensured and extensibility. The effort built on prior models, such as those from Hinton et al. and Sloman, adapting them into a declarative XML format to facilitate policy expression across domains. Key contributors included editors Simon Godik from Overxeer and Tim Moses from Entrust, alongside a diverse group of experts such as Anne Anderson (), Michiharu Kudo (), Carlisle Adams (Entrust), Hal Lockhart (, formerly Entegrity), and Bill Parducci (Overxeer), representing companies like , , Entrust, OpenNetwork, Quadrasis, and Sterling Commerce. The working group focused on drafting specifications that supported multiple subjects, content introspection, and protocol bindings like , conducting reviews and iterations through 2001 and 2002 to refine the policy language. XACML 1.0 was released as an Standard on February 18, 2003, emphasizing basic policy syntax for permit/deny decisions based on attributes, rules, and targets, which laid the foundation for subsequent enhancements in later versions.

Standardization and Version Evolution

The eXtensible (XACML) Technical Committee (TC) began the formal process in 2002, culminating in the approval of XACML 1.0 as an Standard on February 18, 2003. This initial version established the foundational XML-based schema for expressing policies, attributes, and decisions. XACML 2.0 followed as an Standard on February 1, 2005, building on framework with enhancements such as the hierarchical resource profile for modeling resource structures and improved policy administration capabilities through better support for policy sets and combining algorithms. These updates addressed limitations in handling complex resource hierarchies and policy management in distributed environments. XACML 3.0 advanced to Standard status on January 22, 2013, incorporating refinements for broader applicability, including the Multiple Decision Profile to enable efficient evaluation of access requests over multiple resources in a single query. Additionally, extensions like the Profile of XACML 3.0, approved later, provided support for JSON-based representations to integrate with modern and API-driven systems. Following XACML 3.0, the XACML TC has pursued post-3.0 developments, including errata updates and additional profiles, but no version 4.0 has been released. In June 2025, the TC announced efforts toward a "Next Gen" XACML to enhance flexibility and efficiency with syntax-agnostic approaches, such as support for and , while maintaining backward compatibility with prior versions. Key milestone dates include 2003 for version 1.0, 2005 for , and 2013 for version 3.0.

Overview and Architecture

Definition and Core Purpose

XACML, or eXtensible Access Control Markup Language, is an XML-based standard developed by the Organization for the Advancement of Structured Information Standards (OASIS) for expressing and evaluating access control policies in a structured, machine-readable format. It serves as a core schema that enables the definition of authorization policies, including those for entitlements and obligations, across diverse enterprise systems. The primary goal of XACML is to provide a common language for managing security policies, allowing organizations to enforce consistent access controls without embedding logic directly into applications. At its core, XACML facilitates (ABAC), where decisions are made dynamically based on attributes associated with the subject (e.g., user roles or clearance levels), (e.g., sensitivity), (e.g., read or modify), and environment (e.g., time or location). This approach externalizes policy decisions from the application code, routing requests through a policy decision point () that evaluates policies against contextual attributes to return permit, deny, not applicable, or indeterminate responses, while policy enforcement points () handle the actual access. By decoupling decisions from enforcement, XACML supports fine-grained, context-aware that adapts to real-time conditions, reducing the rigidity of traditional models. XACML extends (RBAC) by incorporating a broader set of attributes beyond static roles, enabling more flexible and dynamic policy enforcement suitable for complex scenarios. For instance, while RBAC might grant access solely based on a user's position, XACML can factor in environmental variables like network security status to refine decisions. This evolution addresses limitations in RBAC for handling nuanced, policy-driven requirements in distributed environments. The benefits of XACML include enhanced among heterogeneous systems due to its standardized XML format, which promotes vendor-neutral . It also offers for large-scale enterprises by supporting distributed policy administration and evaluation, including mechanisms for combining multiple policies. Additionally, XACML's inclusion of obligations—binding directives like or notifications—allows policies to specify mandatory actions that the PEP must perform upon permit or deny decisions, enriching enforcement without altering core access logic.

Key Components and Terminology

XACML defines a set of core entities that form the architectural foundation for implementing systems. The Policy Administration Point (PAP) is the system component responsible for creating, managing, and distributing policies or policy sets to other components in the architecture. The Policy Decision Point (PDP) serves as the central evaluator, receiving authorization requests and applying applicable policies to render decisions such as permit or deny access. The Policy Enforcement Point (PEP) acts as the enforcement layer, intercepting access requests from s or applications and enforcing the decisions issued by the PDP. Complementing these, the Policy Information Point (PIP) provides attribute values from various sources, such as user directories or environmental data, to support policy evaluation. Finally, the Context Handler facilitates communication by converting between native request/response formats used by the PEP and the canonical XML formats expected by the PDP, while also coordinating attribute retrieval from PIPs. Central to XACML's policy language are key terms that describe the elements involved in access decisions. The refers to the entity, such as a or , whose attributes are considered in the authorization request. The denotes the object or targeted by the request, encompassing , files, or components. The Action specifies the operation to be performed on the resource, such as read, write, or execute. The captures contextual attributes that influence the decision but are not tied to the subject, resource, or action, including factors like time of day or network location. Policy outcomes are expressed through four primary decision types: Permit, which grants ; Deny, which prohibits it; NotApplicable, indicating no policy applies; and Indeterminate, signaling an evaluation error or incomplete information. XACML operates on an attribute-based model, where policies are evaluated by matching attributes associated with the subject, resource, action, and environment against policy rules, enabling fine-grained and context-aware access control without relying on predefined roles or identities alone. Attributes are drawn from multiple sources via PIPs and categorized to organize their scope, such as subject-related attributes for identity or resource attributes for content metadata. Authorization in XACML relies on structured XML-based request and response contexts to standardize communication between components. A request context encapsulates the attributes for the subject, resource, action, and environment in a canonical XML format, allowing the to process queries uniformly regardless of the originating system. The response context, similarly XML-structured, conveys the 's decision along with any associated obligations or advice, ensuring that enforcements at the PEP are precise and auditable.

Policy Evaluation Flow

The policy evaluation flow in XACML begins when a Policy Enforcement Point (PEP) receives an request from a attempting to a and translates it into a format suitable for the XACML system. The PEP then forwards this request to the Context Handler, which constructs an XACML request context by incorporating the initial request details and coordinating with Policy Information Points (PIPs) to retrieve additional attributes relevant to the , , , and . These attributes may include dynamic data such as the subject's role or environmental conditions like time of day, ensuring the request context provides a complete set of information for decision-making. Once the request context is fully formed, the Context Handler passes it to the , which retrieves applicable and policy sets from the or a policy repository. The PDP first evaluates the targets of the policies to determine which ones apply to the request; only matching policies proceed to further evaluation. For applicable policies, the PDP assesses individual rules by checking their conditions against the request context attributes. When multiple rules or policies apply, the PDP applies a specified —such as deny-overrides or permit-overrides—to resolve the overall decision by prioritizing or ordering the outcomes from sub-evaluations. The PDP then returns a response context to the Context Handler, containing the final decision (Permit, Deny, NotApplicable, or Indeterminate) along with any associated obligations or advice that the PEP must enforce if the decision is Permit or Deny. Obligations represent mandatory actions, such as the access attempt or notifying an , that the PEP performs upon receiving a permitting decision. The Context Handler translates this response into the PEP's native format and delivers it back, enabling the PEP to either grant or deny the access accordingly. In cases of errors during , such as missing attributes that cannot be resolved by PIPs or conflicts in policy application, the issues an Indeterminate decision, which may propagate through combining algorithms depending on their rules (e.g., treating Indeterminate as a higher in some overrides). This ensures the system handles incomplete information gracefully without defaulting to unsafe permissions. The flow supports multiple policies by allowing the to manage hierarchies of policy sets, where context is passed recursively during to maintain consistency across nested decisions.

Policy Language Elements

Structural Elements

The eXtensible Access Control Markup Language (XACML) defines a hierarchical XML-based structure for expressing policies, enabling modular and scalable policy definitions through nested elements. At the core of this structure are the PolicySet, , and elements, which form a containment where PolicySets can enclose Policies or other PolicySets, and Policies contain one or more Rules. This design supports the composition of complex policies from simpler components, with evaluation proceeding from the top-level PolicySet downward to individual Rules during policy . The PolicySet element serves as the top-level container for aggregating multiple Policies or subordinate PolicySets, facilitating the organization of large-scale access control configurations. It requires a unique identifier via the PolicySetId attribute (a URI, such as urn:oasis:names:tc:xacml:3.0:example:policysetid:1) and specifies a PolicyCombiningAlgId attribute (a URI identifying the algorithm for resolving decisions from its child elements, e.g., urn:oasis:names:tc:xacml:1.0:policy-combining-algorithm:deny-overrides). Optional attributes include Version (e.g., "3.0") for versioning and MaxDelegationDepth for limiting policy delegation chains. Contained within a PolicySet are optional <Target> elements for applicability scoping, references to other policies via <PolicyIdReference> or <PolicySetIdReference>, and optional <ObligationExpressions> or <AdviceExpressions> for post-decision actions. As defined in the XACML 3.0 core specification, "A element is the container for a set of policies and/or policy sets," allowing hierarchical nesting to build modular policy architectures. The element represents the smallest complete policy unit that can be evaluated by a Policy Decision Point (), encapsulating a set of Rules along with their combination logic. It mandates a PolicyId attribute (a , e.g., urn:oasis:names:tc:xacml:3.0:example:policyid:1) and a RuleCombiningAlgId attribute (a specifying how Rule outcomes are aggregated, such as urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:deny-overrides). Like PolicySet, it supports optional Version and MaxDelegationDepth attributes, as well as descriptive elements like <Description> and <PolicyIssuer>. A Policy must include a <Target> element to define its and can contain zero or more <Rule> elements, plus optional obligation or expressions and combiner parameters. The specification states that "The element is the smallest entity that SHALL be presented to the PDP for evaluation," emphasizing its role as a self-contained document. At the base of the hierarchy, the Rule element functions as the atomic decision unit, providing a single authorization outcome without further decomposition. Each Rule requires a unique RuleId attribute (a URI, e.g., urn:oasis:names:tc:xacml:3.0:example:ruleid:1) and an Effect attribute specifying either "Permit" or "Deny" as the decision if the Rule applies. It may include an optional <Target> for matching criteria, a <Condition> element to refine applicability, and optional <ObligationExpressions> for associated actions. Rules are evaluated individually within their parent Policy, contributing to the overall decision via the specified combining algorithm. According to the core specification, "A Rule specifies an effect of Permit or Deny that is to be returned if the rule applies," making it the fundamental building block for policy logic. The XML structure of XACML policies adheres to a formal schema defined in the namespace urn:oasis:names:tc:xacml:3.0:core:schema:wd-17, with the schema document available at http://docs.oasis-open.org/xacml/3.0/xacml-core-v3-schema-wd-17.xsd. This schema uses XML Schema Definition (XSD) complex types such as PolicySetType, PolicyType, and RuleType to enforce the element hierarchy and attribute constraints. Policies and PolicySets declare their version compatibility through the Version attribute, typically formatted as a dotted decimal (e.g., "3.0"), ensuring interoperability across implementations. Additional namespaces, such as http://www.w3.org/2001/XMLSchema-instance for schema instances, are incorporated to support validation and extensibility. The specification outlines these basics in Sections 5.1 through 5.4, confirming that all elements conform to standard XML rules for well-formedness and namespace usage.

Attributes and Categories

In XACML, attributes represent characteristics of entities involved in decisions, such as users, resources, actions, or the environment, and are fundamental to policy evaluation. Each attribute is structured with an AttributeId that serves as its unique name, typically a like urn:oasis:names:tc:xacml:1.0:subject:subject-id to ensure global uniqueness. The attribute also includes a DataType attribute, referencing an type such as http://www.w3.org/2001/XMLSchema#string or http://www.w3.org/2001/XMLSchema#integer, which defines the expected format and enables type-safe comparisons. The actual value is encapsulated in an <AttributeValue> element, which can be a simple literal like [email protected] or a more complex structured value, and an optional Issuer identifies the source of the attribute, such as med.example.com, to track and support decisions. Attributes are organized into standard categories to provide semantic grouping and facilitate policy authoring. The subject category, identified by the URI urn:oasis:names:tc:xacml:1.0:subject-category:access-subject, captures properties of the requesting entity, such as roles, authentication credentials, or identifiers like subject-id. The resource category, using urn:oasis:names:tc:xacml:3.0:attribute-category:resource, describes the target object of the access request, including attributes like resource identifiers, content types, or metadata such as resource-id or resource:owner. The action category, denoted by urn:oasis:names:tc:xacml:3.0:attribute-category:action, specifies details of the intended operation, for example, action-id with values like read or write. Finally, the environment category, with URI urn:oasis:names:tc:xacml:3.0:attribute-category:environment, includes contextual factors external to the subject, resource, or action, such as current time (environment:current-time), location, or system load. These categories are referenced in policy elements like <Attributes> to scope attributes logically. XACML supports custom attributes to accommodate domain-specific requirements beyond the standard categories. Users can define additional categories by assigning unique URIs, such as urn:example:company:attribute-category:device, allowing integration of specialized properties like device type or organizational clearance levels without conflicting with core definitions. This extensibility ensures flexibility for diverse applications, from healthcare to , while maintaining interoperability through URI-based identification. Attribute values are dynamically retrieved during policy evaluation from Policy Information Points (PIPs), which act as external sources like directories, databases, or sensors. Retrieval is triggered by elements like <AttributeDesignator>, which specifies the category, AttributeId, DataType, and optional , or <AttributeSelector> for XPath-based from provided . The context handler mediates these requests, aggregating attributes into the decision context while applying safeguards to protect sensitive data. considerations are critical, as attributes may contain personally identifiable information; thus, implementations must enforce for PIP access, use secure channels for transmission, and minimize data disclosure by requesting only necessary attributes.

Targets and Matching

In XACML, the element serves as a mechanism to define the scope of applicability for a , , or by specifying conditions based on attributes from the , , , and categories. This element acts as an initial filter, determining whether a given decision request warrants further of the policy's rules and conditions, thereby optimizing performance by excluding irrelevant policies early in the process. The is optional in Rules but mandatory in Policies and PolicySets unless inherited from a parent element; if absent, it is assumed to match any request. The structure of the element organizes matching criteria into dedicated sections—Subjects, , Actions, and optionally Environments—each comprising an AllOf sequence of one or more AnyOf groups, which in turn contain individual elements. A element performs a between an AttributeValue (a literal value with a specified DataType, such as "http://www.w3.org/2001/XMLSchema#string") and an attribute from the request context, identified via an AttributeDesignator or AttributeSelector. The comparison uses an operator defined by the MatchId attribute, which references a standard like "urn:oasis:names:tc:xacml:1.0:function:string-equal" for checks or "urn:oasis:names:tc:xacml:1.0:function:integer-greater-than" for numeric comparisons, ensuring type-safe evaluation based on the DataType. The overall Target evaluates to "" only if all AllOf conditions succeed (i.e., at least one AnyOf per group matches), resulting in "No-match" or "Indeterminate" otherwise, with the latter occurring due to retrieval errors or failures. This matching process enables efficient policy selection during the evaluation flow, where the Policy Decision Point (PDP) first assesses across the policy hierarchy to identify applicable components before proceeding to rule evaluation or combining algorithms. For instance, a might restrict a to requests where the action attribute equals "read" and the is within a specific category, filtering out unrelated requests without invoking deeper logic. Starting with XACML 2.0, the specification supports resource hierarchies through a dedicated profile, allowing Targets to match structured resources such as file systems or XML documents using attributes like resource-parent or resource-ancestor, often via XPath expressions in AttributeSelectors for precise node identification. This hierarchical matching extends to multi-resource scenarios via another 2.0 profile, where a single request can target multiple resources—such as descendants in a tree—by including multiple Resource elements or scope attributes like "Children" or "Descendants," with the PDP deriving individual decisions while applying the same Target criteria per resource. These features enhance applicability for complex environments without altering the core Target matching logic.

Conditions and Expressions

In XACML policies, the <Condition> within a <Rule> serves as an optional that further refines the applicability of the beyond its <Target>, evaluating to one of three outcomes: "True" (indicating the rule applies), "False" (the rule does not apply), or "Indeterminate" (due to missing attributes or errors). This enables fine-grained conditional by combining attribute values from the request , allowing policies to incorporate dynamic checks such as time-based or role-specific constraints. The <Condition> is composed of one or more <Expression> sub-elements, which can include <Apply> for invoking s on arguments, <VariableReference> for reusing defined expressions, <AttributeDesignator> for static attribute retrieval, and <AttributeSelector> for dynamic content selection. The <Apply> element applies a specified —such as logical operators like urn:oasis:names:tc:xacml:1.0:function:and or functions like urn:oasis:names:tc:xacml:1.0:function:string-equal—to its child expressions, supporting nested structures for complex logic. For instance, a condition might use <Apply> with string-one-and-only to extract a single value from an attribute bag before . <AttributeDesignator> retrieves attribute values from the XACML request context by specifying a category (e.g., "urn:oasis:names:tc:xacml:3.0:attribute-category:access-subject") and an attribute ID (e.g., "parent-guardian-id"), optionally including a data type and issuer; it returns a bag of values if multiple matches exist. In contrast, <AttributeSelector> dynamically extracts values from the resource's XML content using an XPath expression (data type urn:oasis:names:tc:xacml:3.0:data-type:xpathExpression), such as //md:patient/md:patient-number/text(), targeting specific nodes within the provided resource document. The MustBePresent attribute in both can be set to "true" to make the condition Indeterminate if the attribute is absent. <VariableReference> allows referencing a <VariableDefinition> elsewhere in the policy, promoting modularity by defining reusable expressions, such as a that can be invoked multiple times without repetition. All expressions adhere to the XACML 3.0 (urn:oasis:names:tc:xacml:3.0:core:schema:wd-17), ensuring type-safe where functions expect specific types like http://www.w3.org/2001/XMLSchema#string or http://www.w3.org/2001/XMLSchema#date. A practical example of a <Condition> is one that permits access only if the current time exceeds 9:00 AM, implemented as: 
xml
<Condition>
  <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:time-greater-than">
    <AttributeDesignator 
      Category="urn:oasis:names:tc:xacml:3.0:attribute-category:environment"
      AttributeId="urn:oasis:names:tc:xacml:1.0:environment:current-time"
      DataType="http://www.w3.org/2001/XMLSchema#time"/>
    <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:time-one-and-only">
      <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#time">09:00:00</AttributeValue>
    </Apply>
  </Apply>
</Condition>
This uses <AttributeDesignator> to fetch the environment's current time and compares it against a static <AttributeValue>. Another example involves checking if a is under 16 years old by applying date functions like urn:oasis:names:tc:xacml:1.0:function:date-less-than to the birth date and a computed future date, potentially via a <VariableReference> for the calculation.

Obligations and Advice

In XACML, obligations represent mandatory actions that the Policy Enforcement Point (PEP) must perform in conjunction with enforcing an authorization decision, such as a or . These actions are typically specified within rules, , or policy sets and are triggered only when the associated decision matches the obligation's FulfillOn attribute, which can be set to "Permit", "Deny", or both. Expressed as XML elements, an obligation is defined using the <Obligation> with an ObligationId attribute for , often containing <AttributeAssignment> elements to provide necessary parameters, such as an or log message. For instance, a might require the PEP to send a notification to a user upon granting access to sensitive data. Upon receiving a decision from the , the PEP is required to fulfill all applicable obligations; failure to do so mandates denying access, even if the PDP issued a Permit. This enforcement ensures compliance with policy intent beyond simple . Obligations are returned in the PDP response within an <Obligations> container element, allowing multiple obligations to be associated with a single decision. In earlier versions like XACML 2.0, obligations were limited to the policy or policy set level and lacked formal support for optional recommendations, restricting their flexibility. Advice, introduced in XACML 3.0, provides optional supplementary information to the PEP, such as recommendations for alternative resources or additional context, without mandating enforcement. Similar in structure to obligations, advice uses the <Advice> element with an AdviceId attribute and can include attribute assignments for details like suggested endpoints. Unlike obligations, the PEP may safely ignore advice, treating it as non-binding guidance to enhance or . XACML 3.0 enhancements allow multiple pieces of advice per decision, enabling richer interactions while maintaining for obligations from prior versions.

Policy Resolution

Combining Algorithms

In XACML, combining algorithms determine how the results from multiple child policies within a PolicySet or multiple rules within a Policy are resolved into a single decision when more than one is applicable. These algorithms are specified via the PolicyCombiningAlgId attribute in a PolicySet element or the RuleCombiningAlgId attribute in a Policy element, using standardized URIs to select the desired resolution strategy. The core combining algorithms include deny-overrides, permit-overrides, first-applicable, and only-one-applicable, each addressing conflict resolution in access control decisions. The deny-overrides algorithm (URI: urn:oasis:names:tc:xacml:1.0:policy-combining-algorithm:deny-overrides for policies and urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:deny-overrides for rules) prioritizes denial by returning "Deny" if any applicable child evaluates to "Deny"; otherwise, it returns "Permit" if at least one does, or "NotApplicable" if none do. Similarly, the permit-overrides algorithm (URI: urn:oasis:names:tc:xacml:1.0:policy-combining-algorithm:permit-overrides for policies and urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:permit-overrides for rules) favors permission, returning "Permit" if any child evaluates to "Permit" and "Deny" only if all applicable children return "Deny". The first-applicable algorithm (URI: urn:oasis:names:tc:xacml:1.0:policy-combining-algorithm:first-applicable for policies and urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:first-applicable for rules) evaluates children in the order they appear in the XML structure and returns the decision from the first applicable one, ignoring subsequent children. In contrast, the only-one-applicable algorithm (URI: urn:oasis:names:tc:xacml:1.0:policy-combining-algorithm:only-one-applicable for policies and urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:only-one-applicable for rules) requires exactly one applicable child; it returns that child's decision if met, "NotApplicable" if none apply, and "Indeterminate" if more than one applies. Evaluation order plays a key role in ordered variants of these algorithms, such as ordered-deny-overrides (URI: urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:ordered-deny-overrides), which process rules or policies sequentially based on their listed order to enforce priorities, unlike unordered variants that aggregate results without regard to sequence. Weighted combining can also incorporate priorities via attributes on rules or policies, allowing higher-weighted decisions to override lower ones in deny- or permit-overrides scenarios. Indeterminate decisions, arising from errors, missing attributes, or evaluation failures in a child, are handled algorithmically to ensure robust resolution. In deny- and permit-overrides, an Indeterminate child is treated as neutral: the overall result depends on the decisions from other children, with Indeterminate returned only if all applicable children are Indeterminate. For first-applicable, evaluation skips Indeterminate children until a decisive one is found, returning Indeterminate only if all applicable children are Indeterminate. The only-one-applicable algorithm returns Indeterminate if the single applicable child is Indeterminate or if multiple children include Indeterminates alongside others. These strategies prevent single failures from halting the entire evaluation while maintaining policy integrity.

Function Library Overview

The XACML function library serves as a foundational component for policy evaluation, enabling the Policy Decision Point (PDP) to perform computations on attributes, conditions, and expressions within policies. These functions allow for flexible by supporting operations ranging from comparisons to data manipulations, ensuring that decisions can be precisely tailored to contextual information. In XACML 3.0, the library encompasses over 100 standardized functions, categorized to address diverse needs in . Functions are identified by unique URIs, such as urn:oasis:names:tc:xacml:1.0:function:string-equal, which specify the function's identifier, input types, and type. Categories include predicates for matching values, operations for numerical computations, logical functions for logic, and manipulations for handling collections, set operations for relational algebra-like processing, higher-order functions that operate on multisets of values, regular-expression-based matching, XPath-based selections, and specialized functions for /time and non-numeric comparisons. This categorization, totaling 107 functions in XACML 3.0, facilitates modular authoring by providing reusable building blocks. A notable advancement in XACML 3.0 is the introduction of higher-order functions, which accept other functions as arguments, enhancing expressiveness for operations like applying a filter across a bag of attributes. For instance, higher-order bag functions enable dynamic aggregation and selection without hardcoding specific predicates. Additionally, the specification provides extension points through a dedicated schema, allowing implementers to define custom functions with non-standard URIs while maintaining interoperability; these extensions follow the same signature format but use prefixes like urn:oasis:names:tc:xacml:3.0:function: for identification. Such mechanisms ensure the library's adaptability to domain-specific requirements. These functions are integral to evaluating conditions and expressions in XACML policies, where they process attribute values to determine rule applicability.

Functions

Matching and Arithmetic Functions

In XACML, matching functions enable the comparison of attribute values to determine policy applicability, primarily through equality predicates and pattern-based matching, while arithmetic functions support numerical computations on integer and double data types within policy conditions. These functions are integral to evaluating targets and expressions, allowing precise attribute-based decisions without relying on external scripting. The standard function identifiers follow a consistent URN namespace defined by the OASIS XACML 3.0 core specification. Equality functions compare two values of the same and return true if they are identical, forming the basis for attribute matching in targets and conditions. Supported types include strings, integers, doubles, booleans, and anyURIs, with identifiers such as urn:oasis:names:tc:xacml:1.0:function:string-equal for strings, urn:oasis:names:tc:xacml:1.0:function:integer-equal for integers, urn:oasis:names:tc:xacml:1.0:function:double-equal for doubles, urn:oasis:names:tc:xacml:1.0:function:boolean-equal for booleans, and urn:oasis:names:tc:xacml:1.0:function:anyURI-equal for anyURIs. Inequality is achieved by applying the logical operator to these functions, rather than dedicated not-equal predicates, ensuring consistent handling across data types. For instance, a might use string-equal to match a user's attribute to "admin" for granting elevated . Beyond exact equality, allow flexible comparisons against templates. The string-match function, identified as urn:oasis:names:tc:xacml:1.0:function:string-match, evaluates whether a string attribute value conforms to a specified , such as a wildcard or template. Similarly, anyURI-match, with identifier urn:oasis:names:tc:xacml:1.0:function:anyURI-match, performs on values, useful for identifiers like hierarchical paths. These are commonly applied in targets to filter requests, for example, matching a user against an RFC822 for domain-based . Arithmetic functions provide basic numerical operations on integers and doubles, enabling computations like aggregation or checks in logic. For integers, the operations include (urn:oasis:names:[tc](/page/TC):xacml:1.0:function:integer-add), subtraction (urn:oasis:names:[tc](/page/TC):xacml:1.0:function:integer-subtract), multiplication (urn:oasis:names:[tc](/page/TC):xacml:1.0:function:integer-multiply), and division (urn:oasis:names:[tc](/page/TC):xacml:1.0:function:integer-divide), each taking two arguments and returning the result or an error for invalid cases like . Double-precision equivalents are urn:oasis:names:[tc](/page/TC):xacml:1.0:function:double-add, urn:oasis:names:[tc](/page/TC):xacml:1.0:function:double-subtract, urn:oasis:names:[tc](/page/TC):xacml:1.0:function:double-multiply, and urn:oasis:names:[tc](/page/TC):xacml:1.0:function:double-divide, supporting with semantics. An example use case is calculating a resource's total size by adding file attributes (integer-add) to enforce quota limits in a .
Function TypeData TypeURN IdentifierOperation
Equalityurn:oasis:names:tc:xacml:1.0:function:string-equalExact match
Equalityurn:oasis:names:tc:xacml:1.0:function:integer-equalExact match
Equalityurn:oasis:names:tc:xacml:1.0:function:double-equalExact match
Equalityurn:oasis:names:tc:xacml:1.0:function:boolean-equalExact match
EqualityanyURIurn:oasis:names:tc:xacml:1.0:function:anyURI-equalExact match
Pattern Matchurn:oasis:names:tc:xacml:1.0:function:string-matchPattern conformance
Pattern MatchanyURIurn:oasis:names:tc:xacml:1.0:function:anyURI-matchPattern conformance
Arithmeticurn:oasis:names:tc:xacml:1.0:function:integer-addAddition
Arithmeticurn:oasis:names:tc:xacml:1.0:function:integer-subtractSubtraction
Arithmeticurn:oasis:names:tc:xacml:1.0:function:integer-multiplyMultiplication
Arithmeticurn:oasis:names:tc:xacml:1.0:function:integer-divideDivision
Arithmeticurn:oasis:names:tc:xacml:1.0:function:double-addAddition
Arithmeticurn:oasis:names:tc:xacml:1.0:function:double-subtractSubtraction
Arithmeticurn:oasis:names:tc:xacml:1.0:function:double-multiplyMultiplication
Arithmeticurn:oasis:names:tc:xacml:1.0:function:double-divideDivision
These functions integrate with XACML's expression , where results can feed into higher-level decisions, such as permit or deny outcomes based on computed values.

String, Logical, and Set Functions

XACML provides a suite of built-in functions for manipulating , performing logical operations, and handling bags (multi-valued collections akin to sets but allowing duplicates) to support flexible policy expressions. These functions enable policy authors to process textual data, evaluate conditions, and operate on attribute values that may occur multiple times in a request context. They are essential for constructing complex rules that combine attributes from subjects, resources, actions, and environments. String functions in XACML facilitate text processing and type conversions, allowing policies to normalize, extract, or transform string-based attributes for comparison or . The string-substring function extracts a portion of a string based on a starting position and length, returning the as a new string value; for instance, it can isolate a from a full in an attribute. Uppercase conversion is handled via the string-normalize-to-upper-case function, which transforms all characters in the input string to uppercase, aiding in case-insensitive matching; a parallel string-normalize-to-lower-case function performs the opposite normalization. Conversions to other types include functions like string-from-integer, which serializes an integer value into its string representation, and integer-from-string, enabling seamless integration of numeric and textual data in expressions. These operations ensure consistent handling of string attributes across diverse data sources. Logical functions support within policy conditions, allowing aggregation of multiple predicates into a single decision criterion. The and function evaluates to true only if all input values are true, accepting a of booleans to handle variable numbers of conditions efficiently. The or function returns true if at least one input is true, similarly operating on for scalable . The n-of function implements , returning true if at least n of the provided values are true; it takes an and a of booleans, enabling policies like "approve if at least two out of three clearances are granted." The not function inverts a single input, providing for excluding specific scenarios. These functions parallel arithmetic aggregation but focus on outcomes, forming the backbone of conditional expressions in rules. Bag functions manage multi-valued attributes, which are common in XACML as allow duplicates, supporting operations on collections like roles or addresses. The bag-size returns the count of elements in a bag, useful for checking the multiplicity of attributes such as the number of assigned groups (e.g., urn:oasis:names:[tc](/page/TC):xacml:1.0:[function](/page/Function):bag-size). is provided by intersection, which yields a new bag containing only elements common to both input bags, filtering overlapping permissions (urn:oasis:names:[tc](/page/TC):xacml:1.0:[function](/page/Function):intersection). The union merges two bags into one containing all elements from both, preserving duplicates (urn:oasis:names:[tc](/page/TC):xacml:1.0:[function](/page/Function):union). Subset checking uses subset, returning true if every element in the first bag appears at least as many times in the second bag, ideal for verifying inclusions (urn:oasis:names:[tc](/page/TC):xacml:1.0:[function](/page/Function):subset). Additional bag utilities include is-in to test membership and set-difference for exclusions (urn:oasis:names:[tc](/page/TC):xacml:1.0:[function](/page/Function):set-difference). These operate on bags as multi-sets; there are no separate functions that enforce uniqueness as in strict sets. Examples include combining conditions via logical functions on bag-filtered attributes, such as permitting access only if a user's bag intersects with required privileges and meets a size threshold.

Specialized Functions

XACML 3.0 introduces specialized functions that extend the policy language's capabilities for handling complex , XML querying, and paradigms on data bags, enabling more nuanced decisions in advanced scenarios. functions provide mechanisms for validating and matching string , particularly useful in requiring format checks on attributes such as user identifiers or resource names. The primary in this category is string-regexp-match, which evaluates whether a given string matches a specified , returning true if the match succeeds and false otherwise (urn:oasis:names:tc:xacml:1.0:function:string-regexp-match). For instance, this can enforce validation in a by checking if an attribute value conforms to a like ^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$, ensuring only properly formatted addresses trigger permit decisions. XPath functions facilitate direct interaction with XML resources, allowing policies to query and assess structured content without external preprocessing. The xpath-node-match function determines if a provided XPath expression selects a specific within a resource's XML representation, typically used in conjunction with a content selector to verify access to particular elements (urn:oasis:names:tc:xacml:3.0:function:xpath-node-match). An example application involves querying medical s stored in XML, where a might use <Match MatchId="urn:oasis:names:tc:xacml:3.0:function:xpath-node-match"><AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">md:record</AttributeValue></Match> to confirm whether a requested , such as a element, aligns with the request. Complementing this, the xpath-node-count function computes the number of s returned by an XPath expression, enabling quantitative conditions like limiting based on the volume of matching elements in a document (urn:oasis:names:tc:xacml:3.0:function:xpath-node-count). Higher-order functions, introduced in XACML 3.0, operate on of attribute values to apply predicates or transformations across collections, building on foundational bag operations for scalable logic (urn:oasis:names:tc:xacml:3.0:function:[any-of](/page/Function), urn:oasis:names:tc:xacml:3.0:function:[all-of](/page/Function), urn:oasis:names:tc:xacml:3.0:function:[map](/page/Map)). The any-of returns true if at least one element in a bag satisfies a given , useful for permissive scenarios where is granted if any matching attribute exists. In contrast, all-of evaluates to true only if every element in the bag meets the , enforcing strict uniformity such as requiring all user roles to align with criteria. The map applies a specified to each item in a bag, producing a new bag of results that can feed into further evaluations, for example, transforming a set of string attributes via uppercase conversion before comparison. These enhance extensibility by allowing authors to compose complex expressions without custom extensions.

XACML 3.0

Core Schema and Data Types

The core schema of XACML 3.0 is defined using XML Schema Definition (XSD) language and resides in the namespace urn:oasis:names:tc:xacml:3.0:core:schema:wd-17. The primary schema document, xacml-core-v3-schema-wd-17.xsd, specifies the structure for key elements such as policies, requests, responses, and attributes, ensuring syntactic validity and interoperability across implementations. This schema is hosted by OASIS and serves as the foundational blueprint for encoding XACML documents in XML format. XACML 3.0 employs a that distinguishes between built-in primitive data types and custom extensions, with strict validation rules to maintain consistency during policy and attribute matching. Built-in types are predefined and mandatory for compliant implementations, drawing primarily from Part 2 datatypes and supplemented by XACML-specific identifiers. Custom types can be introduced via extensions using unique URIs, but they must adhere to the same validation mechanisms, including lexical representation checks and functional compatibility with higher-order functions. Validation occurs at multiple levels: schema-level enforces structural constraints, while ensures type unification—meaning arguments to functions must share a common supertype or be convertible without loss of information. The primitive data types in XACML 3.0 form the basis for attribute values and support a range of operations in policy expressions. These include:
  • http://www.w3.org/2001/XMLSchema#string: For textual data.
  • http://www.w3.org/2001/XMLSchema#boolean: For true/false values.
  • http://www.w3.org/2001/XMLSchema#integer: For .
  • http://www.w3.org/2001/XMLSchema#double: For floating-point numbers.
  • http://www.w3.org/2001/XMLSchema#time: For time-of-day values (e.g., 12:00:00Z).
  • http://www.w3.org/2001/XMLSchema#date: For calendar dates (e.g., 2025-11-11).
  • http://www.w3.org/2001/XMLSchema#anyURI: For uniform resource identifiers.
  • http://www.w3.org/2001/XMLSchema#hexBinary: For hexadecimal-encoded binary data.
  • http://www.w3.org/2001/XMLSchema#base64Binary: For base64-encoded binary data.
  • urn:oasis:names:tc:xacml:3.0:data-type:dayTimeDuration: For durations like days, hours, and seconds (e.g., P1DT2H).
  • urn:oasis:names:tc:xacml:3.0:data-type:yearMonthDuration: For durations like years and months (e.g., P1Y2M).
  • urn:oasis:names:tc:xacml:3.0:data-type:xpathExpression: For queries over XML content.
These types enable precise representation of attributes in decisions, with bags (multi-valued collections) allowed for types like string or integer to handle sets of values. Compared to XACML , the 3.0 version introduces refinements to the , including the addition of dedicated types (dayTimeDuration and yearMonthDuration) with OASIS-standardized URIs for improved in temporal calculations, superseding the earlier reliance on draft references. Additionally, the xpathExpression type is a new primitive, distinct from treating as a string in prior versions, allowing native support for XML content evaluation. These changes enhance expressiveness without breaking backward compatibility through translation guidelines.

New Features and Profiles

XACML 3.0 introduced several enhancements to improve , administrative flexibility, and in systems. These include advanced support for bulk , mechanisms, and specialized profiles that extend the core for domain-specific applications. Such features address limitations in earlier versions by enabling more dynamic policy administration and integration with modern data formats and environments. The Multiple Decision Profile (OASIS Committee Specification, 2014) provides mechanisms for submitting bulk requests to obtain multiple access control decisions within a single XACML Request Context, particularly over resource hierarchies. It supports identification of nodes using a "scope" attribute with values such as "Children" for immediate children or "Descendants" for all descendants, allowing efficient evaluation of hierarchical structures like file systems or organizational trees. Additional methods include XPath expressions for precise node selection and repeated attribute categories for handling multiple resources. This profile also introduces a combined decision option to aggregate results, enhancing performance for large-scale authorizations. The Administration and Delegation Profile (OASIS Committee Specification Draft, 2014) enables the expression of delegation policies, supporting attribute-based delegation where administrative rights are granted based on , , , and attributes. It models hierarchies through a reduction graph with policy nodes and directed edges representing permit or deny authorizations, including types like policy-to-policy (PP) and delegation-to-policy (). Delegation depth is controlled via the MaxDelegationDepth attribute to prevent infinite chains, while models allow super administrators or issuers to retract permissions. These improvements facilitate constrained administrative models, such as delegating local rights to global administrators without full authority. GeoXACML extends XACML 3.0 with geospatial capabilities, allowing policies to incorporate geographic and spatiotemporal conditions for access rights. It leverages the ISO 19125 geometry model for core conformance and supports extended topological tests for , such as intersection or containment queries. This profile enables interoperable enforcement in applications like location-based services or GIS systems, functioning as a policy decision point or gateway. The Profile of XACML 3.0 Version 1.1 (OASIS Standard) standardizes non-XML serialization of XACML 3.0 requests and responses between policy enforcement points () and policy decision points (PDPs), using JSON objects to represent categories, attributes, and results while preserving semantic equivalence to XML. It specifies the application/xacml+json for HTTP transport, facilitating integration with RESTful and reducing parsing overhead in web-based systems. Other additions in XACML 3.0 include the PolicyIssuer element for attributing policy sources, aiding in auditing and trust verification by identifying issuers and their attributes. Obligations and advice expressions allow policies to mandate or suggest actions like logging for compliance, with required to deny if obligations are unsupported. Attribute-based is further realized through these mechanisms in the delegation profile. In practical extensions, the iSHARE adopts a port of XACML 3.0 for structuring evidence in data spaces, enabling fine-grained, time-bound authorizations across interoperable systems as of November 2025 implementations. This port translates XML specifications into for easier exchange of structures, supporting in networked environments. As of June 2025, the XACML Technical Committee is developing a next-generation version of the standard, incorporating native and support, a flattened model, and enhanced efficiency for contemporary applications.

Examples

Sample Policies

Sample policies in XACML demonstrate how policy writers can express fine-grained decisions using elements such as , conditions, and effects, often leveraging attributes from subjects, resources, actions, and the . These examples illustrate core concepts like attribute matching and conditional logic to evaluate requests, resulting in decisions of Permit, Deny, NotApplicable, or Indeterminate based on the policy's combining . One common involves time-based to restrict access outside , utilizing environment attributes such as the current time. For instance, a might permit personnel to ring an alarm bell only outside core operating hours (e.g., 08:00 to 17:00 UTC), effectively denying such during unless overridden by another rule. This is achieved through a rule with a specifying the , , and , combined with a that inverts a time-range check. The following XML snippet represents such a rule within a policy using the deny-overrides combining algorithm (illustrative example using standard XACML elements): 
xml
<Rule RuleId="alrmbell-ring-outside-hours" Effect="Permit"
      xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17">
  <Description>Permit ringing alarm bell outside business hours for security role</Description>
  <Target>
    <AnyOf>
      <AllOf>
        <Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
          <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">/bell/ring</AttributeValue>
          <AttributeDesignator Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"
                               AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"
                               DataType="http://www.w3.org/2001/XMLSchema#string" MustBePresent="true"/>
        </Match>
      </AllOf>
    </AnyOf>
    <AnyOf>
      <AllOf>
        <Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
          <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">POST</AttributeValue>
          <AttributeDesignator Category="urn:oasis:names:tc:xacml:3.0:attribute-category:action"
                               AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id"
                               DataType="http://www.w3.org/2001/XMLSchema#string" MustBePresent="true"/>
        </Match>
      </AllOf>
    </AnyOf>
    <AnyOf>
      <AllOf>
        <Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
          <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">security-role</AttributeValue>
          <AttributeDesignator Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject"
                               AttributeId="urn:oasis:names:tc:xacml:2.0:subject:role"
                               DataType="http://www.w3.org/2001/XMLSchema#string" MustBePresent="true"/>
        </Match>
      </AllOf>
    </AnyOf>
  </Target>
  <Condition>
    <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:not">
      <Apply FunctionId="urn:oasis:names:tc:xacml:2.0:function:time-in-range">
        <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:time-one-and-only">
          <AttributeDesignator AttributeId="urn:oasis:names:tc:xacml:1.0:environment:current-time"
                               DataType="http://www.w3.org/2001/XMLSchema#time"
                               Category="urn:oasis:names:tc:xacml:3.0:attribute-category:environment"
                               MustBePresent="false"/>
        </Apply>
        <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#time">08:00:00</AttributeValue>
        <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#time">17:00:00</AttributeValue>
      </Apply>
    </Apply>
  </Condition>
</Rule>
In evaluation, the PDP first checks the target against the request attributes; if matched (e.g., POST to /bell/ring by a security-role subject), it proceeds to the condition. The condition retrieves the current-time environment attribute and applies the time-in-range function to test if it falls between 08:00:00 and 17:00:00; the not function inverts this, yielding true (and thus Permit) only outside that range. If the condition is false (inside hours), the rule returns NotApplicable, and the deny-overrides algorithm may yield Deny if no other permitting rules apply. Another example integrates user with date-based conditions, such as permitting a or guardian to read a minor's only if the patient is under 16 years old. This policy uses attributes for matching and attributes like current-date, along with resource content via selectors, to enforce age restrictions. The rule's target limits it to read actions on s, while the condition combines verification with a arithmetic check. The XML for this rule, part of a medical access policy, is as follows (adapted from XACML 3.0 core specification example): 
xml
<Rule RuleId="parent-guardian-read-minor" Effect="Permit"
      xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17">
  <Target>
    <AnyOf>
      <AllOf>
        <Match MatchId="urn:oasis:names:tc:xacml:1.0:function:anyURI-equal">
          <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#anyURI">urn:example:med:schemas:record</AttributeValue>
          <AttributeDesignator Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"
                               AttributeId="urn:oasis:names:tc:xacml:2.0:resource:target-namespace"/>
        </Match>
      </AllOf>
    </AnyOf>
    <AnyOf>
      <AllOf>
        <Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
          <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">read</AttributeValue>
          <AttributeDesignator Category="urn:oasis:names:tc:xacml:3.0:attribute-category:action"
                               AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id"/>
        </Match>
      </AllOf>
    </AnyOf>
  </Target>
  <Condition>
    <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:and">
      <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
        <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-one-and-only">
          <AttributeDesignator Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject"
                               AttributeId="urn:oasis:names:tc:xacml:3.0:example:attribute:parent-guardian-id"/>
        </Apply>
        <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-one-and-only">
          <AttributeSelector Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"
                             Path="md:record/md:parentGuardian/md:parentGuardianId/text()"/>
        </Apply>
      </Apply>
      <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:date-less-or-equal">
        <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:date-one-and-only">
          <AttributeDesignator AttributeId="urn:oasis:names:tc:xacml:1.0:environment:current-date"
                               DataType="http://www.w3.org/2001/XMLSchema#date"
                               Category="urn:oasis:names:tc:xacml:3.0:attribute-category:environment"
                               MustBePresent="false"/>
        </Apply>
        <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:date-add-yearMonthDuration">
          <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:date-one-and-only">
            <AttributeSelector Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"
                               Path="md:record/md:patient/md:patientDoB/text()"
                               DataType="http://www.w3.org/2001/XMLSchema#date"
                               MustBePresent="false"/>
          </Apply>
          <AttributeValue DataType="urn:oasis:names:tc:xacml:1.0:data-type:yearMonthDuration">P16Y</AttributeValue>
        </Apply>
      </Apply>
    </Apply>
  </Condition>
</Rule>
Evaluation begins with target matching for read actions on medical records; if applicable, the condition uses string-equal to verify the subject's parent-guardian-id against the resource's, and date-less-or-equal to compare the current-date (from ) with the patient's birth date plus 16 years. Both must hold true for Permit; failure on either (e.g., non-matching or patient 16 or older) results in NotApplicable, potentially leading to Deny under deny-overrides. This ensures - and time-sensitive while referencing elements like attributes and functions defined in the XACML core schema.

Sample Requests and Responses

In XACML 3.0, a request to a is structured as a <Request> element containing categorized attributes for the , , and , enabling the to evaluate access based on provided . The following XML example illustrates a basic request where a attempts to read a . 
xml
<Request xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17">
  <Attributes Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject">
    <Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id">
      <AttributeValue DataType="urn:oasis:names:tc:xacml:1.0:data-type:rfc822Name">[email protected]</AttributeValue>
    </Attribute>
  </Attributes>
  <Attributes Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource">
    <Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id">
      <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#anyURI">file://example/med/record/patient/BartSimpson</AttributeValue>
    </Attribute>
  </Attributes>
  <Attributes Category="urn:oasis:names:tc:xacml:3.0:attribute-category:action">
    <Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id">
      <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">read</AttributeValue>
    </Attribute>
  </Attributes>
</Request>
The responds with a <Response> encapsulating one or more <Result> elements, each specifying a <Decision> (such as Permit, Deny, NotApplicable, or Indeterminate), a <Status> indicating outcome, and optional attributes. A basic response might simply permit access without additional requirements, as shown below for the preceding request. 
xml
<Response xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17">
  <Result>
    <Decision>Permit</Decision>
    <Status>
      <StatusCode Value="urn:oasis:names:tc:xacml:1.0:status:ok"/>
    </Status>
  </Result>
</Response>
Responses may include <Obligations> to enforce post-decision actions, such as notifications, which the Policy Enforcement Point (PEP) must fulfill for decisions like Permit. The example below permits access to a but obligates the PEP to send an email to the patient. 
xml
<Response xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17">
  <Result>
    <Decision>Permit</Decision>
    <Status>
      <StatusCode Value="urn:oasis:names:tc:xacml:1.0:status:ok"/>
    </Status>
    <Obligations>
      <Obligation ObligationId="urn:oasis:names:tc:xacml:3.0:example:obligation:send-email" FulfillOn="Permit">
        <AttributeAssignment AttributeId="urn:oasis:names:tc:xacml:3.0:example:email-address" DataType="http://www.w3.org/2001/XMLSchema#string">
          <Content>[email protected]</Content>
        </AttributeAssignment>
      </Obligation>
    </Obligations>
  </Result>
</Response>
The Profile of XACML 3.0 provides an alternative representation for requests and responses, facilitating integration with web services via , where requests use category arrays like AccessSubject, , and . A corresponding request to the XML example above might appear as follows, querying whether a subject can purchase a resource. 
json
{
  "Request": {
    "AccessSubject": [{
      "Attribute": [{
        "AttributeId": "urn:oasis:names:tc:xacml:1.0:subject:subject-id",
        "DataType": "urn:oasis:names:tc:xacml:1.0:data-type:rfc822Name",
        "Value": "[email protected]"
      }]
    }],
    "Action": [{
      "Attribute": [{
        "AttributeId": "urn:oasis:names:tc:xacml:1.0:action:action-id",
        "DataType": "http://www.w3.org/2001/XMLSchema#string",
        "Value": "read"
      }]
    }],
    "Resource": [{
      "Attribute": [{
        "AttributeId": "urn:oasis:names:tc:xacml:1.0:resource:resource-id",
        "DataType": "http://www.w3.org/2001/XMLSchema#anyURI",
        "Value": "file://example/med/record/patient/BartSimpson"
      }]
    }]
  }
}
A basic JSON response permits the action without obligations. 
json
{
  "Response": [{
    "Decision": "Permit",
    "Status": {
      "StatusCode": {
        "Value": "urn:oasis:names:tc:xacml:1.0:status:ok"
      }
    }
  }]
}
For obligations in , the response includes an Obligations array with identifiers and assignments, mirroring the XML structure; for instance, the email obligation would add "Obligations": [{"ObligationId": "urn:oasis:names:tc:xacml:3.0:example:obligation:send-email", "FulfillOn": "Permit", "AttributeAssignment": [{"AttributeId": "urn:oasis:names:tc:xacml:3.0:example:email-address", "DataType": "http://www.w3.org/2001/XMLSchema#string", "Content": "[email protected]"}]}].

Multiple Decision Profile

The Multiple Decision Profile, defined in XACML 3.0, enables a Policy Enforcement Point (PEP) to obtain multiple access control decisions from a Policy Decision Point (PDP) within a single request context, thereby minimizing communication overhead in scenarios involving sets or hierarchies of resources, such as directories or XML document subtrees. This profile is particularly useful for efficient evaluation over tree-like structures, where a single query can cover a root resource and its descendants, avoiding the need for separate requests per individual item. Requests utilizing this profile include an attribute identifying the profile, such as urn:oasis:names:tc:xacml:3.0:profile:multiple:scope, typically placed in the request's or . For hierarchical resources, the request employs bags within the <Attributes Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"> element, incorporating a attribute with values like "Children" (immediate subordinates) or "Descendants" (all subordinates), alongside the root identifier. This allows the PDP to evaluate policies against the specified without requiring explicit enumeration of each child . The response structure features one or more <Result> elements, each providing an individual decision (Permit, Deny, Indeterminate, or NotApplicable) for a distinct resource or combination within the , along with associated , obligations, , and ApplicablePolicyIds if the ReturnPolicyIdList attribute is true. Aggregated decisions thus reveal partial outcomes, such as permits for some sub-resources and denies for others, enabling the PEP to handle complex access patterns granularly. A sample request for directory access in XML format, targeting read access to a folder named "folder1" and all its descendants, is as follows: 
xml
<Request xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17"
         CombinedDecision="false"
         ReturnPolicyIdList="true">
  <Attributes Category="urn:oasis:names:tc:xacml:3.0:attribute-category:action">
    <Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id">
      <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">read</AttributeValue>
    </Attribute>
  </Attributes>
  <Attributes Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject">
    <Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id">
      <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">user1</AttributeValue>
    </Attribute>
  </Attributes>
  <Attributes Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource">
    <Attribute AttributeId="urn:oasis:names:tc:xacml:2.0:resource:scope">
      <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">Descendants</AttributeValue>
    </Attribute>
    <Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id">
      <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">folder1</AttributeValue>
    </Attribute>
  </Attributes>
</Request>
The corresponding response might include multiple <Result> elements, for instance, permitting access to "folder1" itself and some subfolders while denying others, each with relevant ApplicablePolicyIds referencing the governing policies. The Profile of XACML 3.0 extends support for this profile by mapping the XML structures to objects, using a "MultiRequests" with references to IDs for combinations, and including attributes in the for hierarchical cases. A representative request for directory access to "folder1" and descendants, adapted for read action by a , follows the : 
json
{
  "Request": {
    "AccessSubject": [
      {
        "Id": "subject1",
        "Attribute": [
          {
            "AttributeId": "urn:oasis:names:tc:xacml:1.0:subject:subject-id",
            "DataType": "http://www.w3.org/2001/XMLSchema#string",
            "Value": "user1"
          }
        ]
      }
    ],
    "Action": [
      {
        "Id": "action1",
        "Attribute": [
          {
            "AttributeId": "urn:oasis:names:tc:xacml:1.0:action:action-id",
            "DataType": "http://www.w3.org/2001/XMLSchema#string",
            "Value": "read"
          }
        ]
      }
    ],
    "Resource": [
      {
        "Id": "resource1",
        "Attribute": [
          {
            "AttributeId": "urn:oasis:names:tc:xacml:2.0:resource:scope",
            "DataType": "http://www.w3.org/2001/XMLSchema#string",
            "Value": "Descendants"
          },
          {
            "AttributeId": "urn:oasis:names:tc:xacml:1.0:resource:resource-id",
            "DataType": "http://www.w3.org/2001/XMLSchema#string",
            "Value": "folder1"
          }
        ]
      }
    ],
    "MultiRequests": {
      "RequestReference": [
        {
          "ReferenceId": ["subject1", "action1", "resource1"]
        }
      ]
    }
  }
}
A sample response for such a request could aggregate decisions with partial permits and denies across the , structured as an of decision objects, each detailing the outcome for specific sub-resources along with ApplicablePolicyIds. For instance: 
json
{
  "Response": [
    {
      "Decision": "Permit",
      "Status": {
        "StatusCode": {
          "Value": "urn:oasis:names:tc:xacml:1.0:status:ok"
        }
      },
      "ApplicablePolicyId": ["policy1"],
      "Category": [
        {
          "CategoryId": "urn:oasis:names:tc:xacml:3.0:attribute-category:resource",
          "Attribute": [
            {
              "AttributeId": "urn:oasis:names:tc:xacml:1.0:resource:resource-id",
              "DataType": "http://www.w3.org/2001/XMLSchema#string",
              "Value": "folder1/subfile1.txt"
            }
          ]
        }
      ]
    },
    {
      "Decision": "Deny",
      "Status": {
        "StatusCode": {
          "Value": "urn:oasis:names:tc:xacml:1.0:status:ok"
        }
      },
      "ApplicablePolicyId": ["policy2"],
      "Category": [
        {
          "CategoryId": "urn:oasis:names:tc:xacml:3.0:attribute-category:resource",
          "Attribute": [
            {
              "AttributeId": "urn:oasis:names:tc:xacml:1.0:resource:resource-id",
              "DataType": "http://www.w3.org/2001/XMLSchema#string",
              "Value": "folder1/subfolder2"
            }
          ]
        }
      ]
    }
  ]
}
This format facilitates integration with JSON-based systems while preserving the profile's hierarchical evaluation capabilities.

Implementation and Extensions

Developer Profiles and Tools

The Abbreviated Language for Authorization (ALFA) serves as a designed to simplify the authoring of XACML policies by providing a concise, human-readable syntax that abstracts away much of the XML verbosity inherent in XACML. Developed by Axiomatics and proposed as a profile to the XACML Technical Committee, ALFA enables developers to express authorization rules using familiar programming constructs like variables, functions, and conditionals, while ensuring full compliance with XACML 3.0 semantics. Policies written in ALFA can be compiled directly into equivalent XACML 3.0 XML documents, facilitating integration with any standards-compliant Policy Decision Point (PDP). This compilation process supports validation, error checking, and optimization, making it particularly useful for complex (ABAC) scenarios. The JSON Profile of XACML 3.0, standardized by in Version 1.1, addresses the limitations of XML-based exchanges by defining a lightweight representation for XACML requests, responses, and policies, enabling easier integration with modern web and mobile applications. It ensures lossless translation between XML and formats, mapping core elements such as Attributes categories to objects and supporting shorthand data types (e.g., "string" for XML Schema strings), while allowing optional Base64 encoding for binary content. This profile standardizes communication between Policy Enforcement Points (PEPs) and PDPs over HTTP using the application/xacml+json media type, with extensions for multiple decision requests. Representative samples include a basic authorization request in , such as { "Request": { "ReturnPolicyIdList": false, "Category": [ { "CategoryId": "urn:oasis:names:tc:xacml:3.0:subject-category:access-subject", "Attribute": [ { "AttributeId": "urn:oasis:names:tc:xacml:1.0:subject:subject-id", "DataType": "string", "Value": ["alice"] } ] } ] } }, which queries access for a subject, and corresponding responses indicating Permit or Deny decisions with obligations. For implementation, developers can leverage open-source PDPs such as AuthzForce, an OW2 project that provides a fully compliant XACML 3.0 engine with features like policy caching, custom function support, and for embedded or -based deployment. AuthzForce enables simulation of PDP behavior through its API or CLI tools, allowing request evaluation without full production setup. Commercial options include Axiomatics Server, which offers enterprise-grade PDPs with advanced management, testing, and integration capabilities for high-scale environments. Testing XACML implementations often involves simulators derived from these PDPs; for instance, AuthzForce can generate evaluation traces to verify outcomes against sample requests, while frameworks like the Testing Framework use extensions to automate test case generation from ALFA policies. Best practices for XACML development emphasize policy versioning to track changes and assess impact, such as using mutant to compare policy versions and identify differences in decision outcomes through counterexamples. For debugging, enabling evaluation traces in PDPs like AuthzForce or DataPower's xacml-debug mode captures step-by-step , attribute , and rule matching details, aiding in complex combining algorithms or attribute mismatches.

Integration with Other Standards

XACML integrates with the Security Assertion Markup Language (SAML) through a standardized profile that enables the exchange of authorization decisions and attributes between systems supporting identity federation. This profile, defined by the OASIS XACML SAML Profile Version 2.0, allows SAML 2.0 assertions to carry XACML policy decisions, requests, and responses, facilitating scenarios where authentication via SAML informs fine-grained authorization via XACML. For instance, a SAML assertion can provide subject attributes to an XACML Policy Decision Point (PDP) for evaluating access requests in federated environments. XACML complements OAuth by enabling fine-grained authorization decisions based on attributes derived from OAuth tokens, extending OAuth's coarse-grained scope-based access to more nuanced policy enforcement. In this integration, OAuth handles delegation and token issuance, while XACML evaluates contextual attributes—such as those from token claims—for ABAC policies. XACML policies can be mapped to Rego, the policy language of the Open Policy Agent (OPA), to enable hybrid or migrated deployments in cloud-native environments. Tools for translating XACML's XML-based policies into Rego allow OPA to execute equivalent logic, bridging XACML's structured, standards-driven approach with Rego's flexible, declarative syntax for policy-as-code. Key differences include XACML's emphasis on explicit attribute matching and obligations versus Rego's query-based evaluation, which supports dynamic data integration but requires careful mapping to preserve policy semantics. In cloud computing, the ABAC model exemplified by XACML is similar to implementations like AWS (IAM), where attribute-based policies enable fine-grained control using user, resource, and environmental attributes. AWS IAM supports ABAC through policy conditions that mirror XACML's attribute evaluation, allowing scalable authorization in multi-tenant environments without direct protocol integration. In contrast, SPIFFE focuses on workload identity attestation and mutual TLS for service mesh architectures, providing cryptographic proofs of rather than policy decisions, thus complementing XACML in zero-trust setups where identity feeds into ABAC policies. As of November 2025, the XACML Technical Committee is developing version 4.0 of the standard to modernize policy definition, incorporating feedback for enhanced flexibility and efficiency in contemporary environments.