https://docs.https:xacml/xacml/v4.0/csd01/xacml-v4.0-csd01.md
(Authoritative)
https://docs.https:xacml/xacml/v4.0/csd01/xacml-v4.0-csd01.html
https://docs.https:xacml/xacml/v4.0/csd01/xacml-v4.0-csd01.pdf
N/A
https://docs.https:xacml/xacml/v4.0/xacml-v4.0.md
(Authoritative)
https://docs.https:xacml/xacml/v4.0/xacml-v4.0.html
https://docs.https:xacml/xacml/v4.0/xacml-v4.0.pdf
OASIS eXtensible Access Control Markup Language (XACML) TC
Hal Lochhart (harold.w.lochhart@gmail.com),
Individual
Bill Parducci (bill@parducci.net), Individual
Steven Legg (steven.legg@viewds.com), ViewDS Identity Solutions
Cyril Dangerville (cyril.dangerville@thalesgroup.com),
THALES
This document is one component of a Work Product that also includes:
(Note: Any normative computer language definitions that are part of the Work Product, such as XML instances, schemas and Java(TM) code, including fragments of such, must be (a) well formed and valid, (b) provided in separate plain text files, (c) referenced from the Work Product; and (d) where any definition in these separate files disagrees with the definition found in the specification, the definition in the separate file prevails. Remove this note before submitting for publication.)This specification replaces or supersedes:
This specification is related to:
(remove "Related work" section or the "replaces" or "related" subsections if no entries)urn:oasis:names:tc:xacml:4.0:core:schemaThis specification defines Version 4.0 of the eXtensible Access Control Markup Language.
This document was last revised or approved by the OASIS eXtensible Access Control Markup Language (XACML) TC on the above date. The level of approval is also listed above. Check the "Latest stage" location noted above for possible later revisions of this document. Any other numbered Versions and other technical work produced by the Technical Committee (TC) are listed at https://groups.https:communities/tc-community-home2?CommunityKey=67afe552-0921-49b7-9a85-018dc7d3ef1d#technical.
TC members should send comments on this specification to the TC's email list.
Others should send comments to the OASIS TC comment list at Technical-Committee-Comments@oasis-open.org.
This specification is provided under the RF on Limited Terms Mode of the OASIS IPR Policy, the mode chosen when the Technical Committee was established. For information on whether any patents have been disclosed that may be essential to implementing this specification, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the TC's web page (https://www.oasis-open.org/committees/xacml/ipr.php).
Note that any machine-readable content (Computer Language Definitions) declared Normative for this Work Product is provided in separate plain text files. In the event of a discrepancy between any such plain text file and display content in the Work Product's prose narrative document(s), the content in the separate plain text file prevails.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] and [RFC8174] when, and only when, they appear in all capitals, as shown here.
When referencing this specification the following citation format should be used:
[XACML-v4.0]
eXtensible Access Control Markup Language (XACML) Version 4.0. Edited by Steven Legg and Cyril Dangerville. 9 September 2024. OASIS Committee Specification Draft 01. https://docs.oasis-open.org/xacml/xacml/v4.0/csd01/xacml-v4.0-csd01.html. Latest stage: https://docs.oasis-open.org/xacml/xacml/v4.0/xacml-v4.0.html.
Copyright © OASIS Open 2024. All Rights Reserved.
Distributed under the terms of the OASIS IPR Policy.
For complete copyright information please see the full Notices section in an Appendix below.
[TOC will be inserted here]
Here is a customized command line which will generate HTML from this
markdown file (named xacml-v4.0-csd01.md):
$ pandoc -f gfm+definition_lists -t html xacml-v4.0-csd01.md -c styles/markdown-styles-v1.7.3a.css --toc --toc-depth=5 \
-s --lua-filter diagram.lua --embed-resources \
--metadata title="eXtensible Access Control Markup Language (XACML) Version 4.0" \
-o xacml-v4.0-csd01.htmlN.B.: before running this command, you must either install Pandoc, Graphviz and PlantUML on your system; or else simply use Docker with the following shell alias:
$ alias pandoc='docker run --rm --volume "$(pwd):/data" cdang/pandoc-plantuml'The Dockerfile (named Dockerfile) of the docker
image used in the alias above is provided with this markdown file for
your convenience if you wish to build it yourself.
OASIS staff are currently using pandoc 3.0 from https://github.com/jgm/pandoc/releases/tag/3.0.
Generating HTML in OASIS style requires a reference to a .css file containing the HTML styles. The .css file may be either included with the markdown file (like styles/markdown-styles-v1.7.3.css) or a reference to one of the online stylesheets:
Note this command generates a Table of Contents (TOC) in HTML which is located at the top of the HTML document, and which requires additional editing in order to be published in the expected OASIS style. This editing will be handled by OASIS staff during publication. A TC may use other ways to generate HTML from markdown, which may generate a TOC in a different way. For instance, github can build a TOC.
For PDF output, the command line is the following (different
-t and -H arguments):
$ pandoc -f gfm+definition_lists -t pdf xacml-v4.0-csd01.md -c styles/markdown-styles-v1.7.3a.css \
-H custom_latex_header_for_pandoc_pdf_output.tex --toc --toc-depth=5 -s -L diagram.lua \
--metadata title="eXtensible Access Control Markup Language (XACML) Version 4.0" --embed-resources \
-o /tmp/xacml-v4.0-csd01.pdf XACML 4.0 differs from XACML 3.0 in the following ways:
The policy and policy set constructs have been merged into a single construct which is known as a policy in XACML 4.0.
The <PolicySet>,
<PolicySetIdReference>,
<PolicySetCombinerParameters> and
<PolicySetDefaults> elements and
PolicySet type no longer appear.
The PolicyType type now allows child
<Policy>, <PolicyReference> (was
PolicyIdReference) and
<PolicyCombinerParameters> elements.
Separate rule and policy combining algorithms have been replaced with a single collection of combining algorithms. Legacy combining algorithms have been removed. The only-one-applicable policy combining algorithm has been removed.
The <Target> element's type has been changed
to be the same as the <Condition> element's type (a
single Boolean expression). The <AnyOf>,
<AllOf> and <Match> elements have
been removed.
The <Target> element has been removed from
RuleType.
Obligations and
advice no longer have distinct element
definitions. Instead they now share the common
<Notice> element definition. The difference between
obligations and
advice is indicated by an
IsObligation XML attribute.
Users are able to define short identifiers to use in place of URIs to refer to XACML definitions. A predefined collection of short identifiers for standard-defined URIs is also provided.
Performing an action.
Controlling access in accordance with a policy.
An operation on a resource.
A notice providing supplementary information to the PEP about a decision from the PDP.
The set of policies that governs access for a specific decision request.
Characteristic of a subject, resource, action or environment that may be referenced in a predicate (see also – named attribute).
The result of evaluating applicable policy,
returned by the PDP to the
PEP. A function that evaluates to
Permit, Deny, Indeterminate or
NotApplicable, and (optionally) a list of
notices.
An unordered collection of values, in which there may be duplicate values.
The procedure for combining the decision and notices from multiple policies and rules.
An expression of predicates. A function
that evaluates to True, False or
Indeterminate.
A sequence of predicates combined using the
logical AND operation.
The canonical representation of a decision request and an authorization decision.
The system entity that converts decision requests in the native request format to the XACML canonical form, coordinates with Policy Information Points to add attribute values to the request context, and converts authorization decisions in the XACML canonical form to the native response format.
The result of evaluating a rule or policy.
The request by a PEP to a PDP to render an authorization decision.
A sequence of predicates combined using the
logical OR operation.
The intended consequence of a satisfied
rule (either Permit or
Deny).
The set of attributes that are relevant to an authorization decision and are independent of a particular subject, resource or action.
The identifier equality operation which is defined in Section 7.20.
A set of attributes describing the source of a policy.
A specific instance of an attribute, determined by the attribute name and type, the identity of the attribute holder (which may be of type: subject, resource, action or environment) and (optionally) the identity of the issuing authority.
An additional information item provided to the PEP alongside a decision from the PDP. A notice is either an obligation or advice. Notices are potentially generated by rules and policies during their evaluation by the PDP.
A notice specifying an operation that should be performed by the PEP in conjunction with the enforcement of an authorization decision.
A set of rules, other policies, an identifier for the combining algorithm and (optionally) a list of notice expressions. May be a component of another policy.
The system entity that creates a policy.
The system entity that evaluates applicable policy and renders an authorization decision. This term is defined in a joint effort by the IETF Policy Framework Working Group and the Distributed Management Task Force (DMTF)/Common Information Model (CIM) in [RFC3198]. This term corresponds to "Access Decision Function" (ADF) in [ISO10181-3].
The system entity that performs access control, by making decision requests and enforcing authorization decisions. This term is defined in a joint effort by the IETF Policy Framework Working Group and the Distributed Management Task Force (DMTF)/Common Information Model (CIM) in [RFC3198]. This term corresponds to "Access Enforcement Function" (AEF) in [ISO10181-3].
The system entity that acts as a source of attribute values.
A statement about attributes whose truth can be evaluated.
Data, service or system component.
An effect, a condition and (optionally) a list of notice expressions. A component of a policy.
A simple alias name that stands for a URI or a part thereof.
An abbreviation of short identifier.
An actor whose attributes may be referenced by a predicate.
An element of an XACML policy which matches specified values of resource, subject, environment, action, or other custom attributes against those provided in the request context as a part of the process of determining whether the policy is applicable to the current decision.
The method by which two type expressions are "unified". The type
expressions are matched along their structure. Where a type variable
appears in one expression it is then "unified" to represent the
corresponding structure element of the other expression, be it another
variable or subexpression. All variable assignments must remain
consistent in both structures. Unification fails if the two expressions
cannot be aligned, either by having dissimilar structure, or by having
instance conflicts, such as a variable needs to represent both
xs:string and xs:integer. For a full
explanation of type unification, please see
[Hancock].
In the field of access control and authorization there are several closely related terms in common use. For purposes of precision and clarity, certain of these terms are not used in this specification.
For instance, the term attribute is used in place of the terms: group and role.
In place of the terms: privilege, permission, authorization, entitlement and right, we use the term rule.
The term object is also in common use, but we use the term resource in this specification.
Requestors and initiators are covered by the term subject.
This specification contains schema conforming to W3C XML Schema and normative text to describe the syntax and semantics of XML-encoded policy statements.
Listings of XACML schema and code listings appear like this.Conventional XML namespace prefixes are used throughout the listings in this specification to stand for their respective namespaces as follows, whether or not a namespace declaration is present in the example:
The prefix xacml: stands for the XACML 4.0
namespace.
The prefix ds: stands for the W3C XML Signature
namespace [DS].
The prefix xs: stands for the W3C XML Schema
namespace [XS].
The prefix xf: stands for the XQuery 1.0 and XPath
2.0 Function and Operators specification namespace [XF].
The prefix xml: stands for the XML namespace https://www.w3.org/XML/1998/namespace.
This specification uses the following typographical conventions in
text: <XACMLElement>,
<ns:ForeignElement>, Attribute,
Datatype, OtherCode. Terms in
bold-face italic are intended to have the
meaning defined in the Glossary.
The XACML syntax is defined in a schema associated with the following XML namespace:
urn:oasis:names:tc:xacml:4.0:core:schema
The "economics of scale" have driven computing platform vendors to develop products with very generalized functionality, so that they can be used in the widest possible range of situations. "Out of the box", these products have the maximum possible privilege for accessing data and executing software, so that they can be used in as many application environments as possible, including those with the most permissive security policies. In the more common case of a relatively restrictive security policy, the platform's inherent privileges must be constrained by configuration.
The security policy of a large enterprise has many elements and many points of enforcement. Elements of policy may be managed by the Information Systems department, by Human Resources, by the Legal department and by the Finance department. And the policy may be enforced by the extranet, mail, WAN, and remote-access systems; platforms which inherently implement a permissive security policy. The current practice is to manage the configuration of each point of enforcement independently in order to implement the security policy as accurately as possible. Consequently, it is an expensive and unreliable proposition to modify the security policy. Moreover, it is virtually impossible to obtain a consolidated view of the safeguards in effect throughout the enterprise to enforce the policy. At the same time, there is increasing pressure on corporate and government executives from consumers, shareholders, and regulators to demonstrate "best practice" in the protection of the information assets of the enterprise and its customers.
For these reasons, there is a pressing need for a common language for expressing security policy. If implemented throughout an enterprise, a common policy language allows the enterprise to manage the enforcement of all the elements of its security policy in all the components of its information systems. Managing security policy may include some or all of the following steps: writing, reviewing, testing, approving, issuing, combining, analyzing, modifying, withdrawing, retrieving, and enforcing policy.
XML is a natural choice as the basis for the common security-policy language, due to the ease with which its syntax and semantics can be extended to accommodate the unique requirements of this application, and the widespread support that it enjoys from all the main platform and tool vendors.
The basic requirements of a policy language for expressing information system security policy are:
To provide a method for combining individual rules and policies into a single policy that applies to a particular decision request.
To provide a method for flexible definition of the procedure by which rules and policies are combined.
To provide a method for dealing with multiple subjects acting in different capacities.
To provide a method for basing an authorization decision on attributes of the subject and resource.
To provide a method for dealing with multi-valued attributes.
To provide a method for basing an authorization decision on the contents of an information resource.
To provide a set of logical and mathematical operators on attributes of the subject, resource and environment.
To provide a method for handling a distributed set of policy components, while abstracting the method for locating, retrieving and authenticating the policy components.
To provide a method for rapidly identifying the policy that applies to a given action, based upon the values of attributes of the subjects, resource and action.
To provide an abstraction-layer that insulates the policy-writer from the details of the application environment.
To provide a method for specifying a set of actions that must be performed in conjunction with policy enforcement.
The motivation behind XACML is to express these well-established ideas in the field of access control policy using an extension language of XML. The XACML solutions for each of these requirements are discussed in the following sections.
The complete policy applicable to a particular decision request may be composed of a number of individual rules or policies. For instance, in a personal privacy application, the owner of the personal information may define certain aspects of disclosure policy, whereas the enterprise that is the custodian of the information may define certain other aspects. In order to render an authorization decision, it must be possible to combine the two separate policies to form the single policy applicable to the request.
XACML defines two top-level policy
elements: <Rule> and <Policy>. The
<Rule> element contains a Boolean expression that can
be evaluated in isolation, but that is not intended to be accessed in
isolation by a PDP. So, it is not intended to
form the basis of an authorization decision by
itself. It is intended to exist in isolation only within an XACML
PAP, where it may form the basic unit of
management.
The <Policy> element contains a set of
<Rule> or other <Policy> elements
and a specified procedure for combining the results of their evaluation.
It is the basic unit of policy used by the
PDP, and so it is intended to form the basis
of an authorization decision. It is also the
standard means for combining separate policies
into a single combined policy.
Hinton et al [Hinton] discuss the question of the compatibility of separate policies applicable to the same decision request.
XACML defines a number of combining
algorithms that can be identified by a
CombiningAlgId attribute of the <Policy>
element. The combining algorithm defines a
procedure for arriving at an authorization
decision given the individual results of evaluation of a
set of rules and
policies. Some examples of standard
combining algorithms are (see Appendix G for a
full list of standard combining
algorithms):
Deny-overrides (Ordered and Unordered),
Permit-overrides (Ordered and Unordered) and
First-applicable
In the case of the Deny-overrides algorithm, if a single
<Rule> or <Policy> element is
encountered that evaluates to Deny, then, regardless of the
evaluation result of the other <Rule> or
<Policy> elements in the applicable
policy, the combined result is Deny.
Likewise, in the case of the Permit-overrides algorithm, if a single
Permit result is encountered, then the combined result is
Permit.
In the case of the First-applicable
combining algorithm, the combined result is
the same as the result of the first <Rule> or
<Policy> element in the list of
rules and policies
that is applicable to the decision
request.
Policies may take parameters that modify the behavior of the combining algorithms. However, none of the standard combining algorithms is affected by parameters.
Users of this specification may, if necessary, define their own combining algorithms.
Access control policies often place requirements on the actions of more than one subject. For instance, the policy governing the execution of a high-value financial transaction may require the approval of more than one individual, acting in different capacities. Therefore, XACML recognizes that there may be more than one subject relevant to a decision request. Different attribute categories are used to differentiate between subjects acting in different capacities. Some standard values for these attribute categories are specified, and users may define additional ones.
Another common requirement is to base an
authorization decision on some characteristic
of the subject other than its identity.
Perhaps, the most common application of this idea is the
subject's role [RBAC].
XACML provides facilities to support this approach.
Attributes of
subjects contained in the request
context may be identified by the
<AttributeDesignator> element. This element contains
a URN that identifies the attribute.
Alternatively, the <AttributeSelector> element may
contain an XPath expression over the <Content>
element of the subject to identify a
particular subject attribute value by its
location in the context (see Section 2.11 for an explanation of
context).
XACML provides a standard way to reference the attributes defined in the LDAP series of specifications [LDAP-1], [LDAP-2]. This is intended to encourage implementers to use standard attribute identifiers for some common subject attributes.
Another common requirement is to base an authorization
decision on some characteristic of the
resource other than its identity. XACML
provides facilities to support this approach.
Attributes of the
resource may be identified by the
<AttributeDesignator> element. This element contains
a URN that identifies the attribute.
Alternatively, the <AttributeSelector> element may
contain an XPath expression over the <Content>
element of the resource to identify a
particular resource attribute value by its
location in the context.
The most common techniques for communicating attributes (LDAP, XPath, SAML, etc.) support multiple values per attribute. Therefore, when an XACML PDP retrieves the value of a named attribute, the result may contain multiple values. A collection of such values is called a bag. A bag differs from a set in that it may contain duplicate values, whereas a set may not. Sometimes this situation represents an error. Sometimes the XACML rule is satisfied if any one of the attribute values meets the criteria expressed in the rule.
XACML provides a set of functions that allow a policy writer to be absolutely clear about how the PDP should handle the case of multiple attribute values. These are the "higher-order" functions (see Appendix E.3).
In many applications, it is required to base an authorization decision on data contained in the information resource to which access is requested. For instance, a common component of privacy policy is that a person should be allowed to read records for which he or she is the subject. The corresponding policy must contain a reference to the subject identified in the information resource itself.
XACML provides facilities for doing this when the information
resource can be represented as an XML
document. The <AttributeSelector> element may contain
an XPath expression over the <Content> element of the
resource to identify data in the information
resource to be used in the
policy evaluation.
In cases where the information resource is not an XML document, specified attributes of the resource can be referenced, as described in Section 2.5.
Information security policies operate upon attributes of subjects, the resource, the action and the environment in order to arrive at an authorization decision. In the process of arriving at the authorization decision, attributes of many different types may have to be compared or computed. For instance, in a financial application, a person's available credit may have to be calculated by adding their credit limit to their account balance. The result may then have to be compared with the transaction value. This sort of situation gives rise to the need for arithmetic operations on attributes of the subject (account balance and credit limit) and the resource (transaction value).
Even more commonly, a policy may identify the set of roles that are permitted to perform a particular action. The corresponding operation involves checking whether there is a non-empty intersection between the set of roles occupied by the subject and the set of roles identified in the policy; hence the need for set operations.
XACML includes a number of built-in functions and a method of adding
non-standard functions. These functions may be nested to build
arbitrarily complex expressions. This is achieved with the
<Apply> element. The <Apply>
element has an XML attribute called FunctionId that
identifies the function to be applied to the contents of the element.
Each standard function is defined for specific argument data-type
combinations, and its return data-type is also specified. Therefore,
data-type consistency of the policy can be
checked at the time the policy is written or
parsed. And, the types of the data values presented in the request
context can be checked against the values
expected by the policy to ensure a predictable
outcome.
In addition to operators on numerical and set arguments, operators are defined for date, time and duration arguments.
Relationship operators (equality and comparison) are also defined for a number of data-types, including the RFC822 and X.500 name-forms, strings, URIs, etc.
Also noteworthy are the operators over Boolean data-types, which permit the logical combination of predicates in a rule. For example, a rule may contain the statement that access may be permitted during business hours AND from a terminal on business premises.
The XACML method of representing functions borrows from MathML [MathML] and from the XQuery 1.0 and XPath 2.0 Functions and Operators specification [XF].
In a distributed system, individual policy
statements may be written by several policy
writers and enforced at several enforcement points. In addition to
facilitating the collection and combination of independent
policy components, this approach allows
policies to be updated as required. XACML
policy statements may be distributed in any
one of a number of ways. But, XACML does not describe any normative way
to do this. Regardless of the means of distribution,
PDPs are expected to confirm, by examining the
policy's <Target> element
that the policy is applicable to the
decision request that it is processing.
<Policy> elements may be attached to the
information resources to which they apply, as
described by Perritt [Perritt93].
Alternatively, <Policy> elements may be maintained in
one or more locations from which they are retrieved for evaluation. In
such cases, the applicable policy may be
referenced by an identifier or locator closely associated with the
information resource.
For efficiency of evaluation and ease of management, the overall
security policy in force across an enterprise may be expressed as
multiple independent policy components. In
this case, it is necessary to identify and retrieve the
applicable policy statement and verify that it
is the correct one for the requested action
before evaluating it. This is the purpose of the
<Target> element in XACML.
Two approaches are supported:
<Target> element of the retrieved
policy statements as defined by the XACML
specification.<Target> elements in the context of a particular
decision request, in order to identify the
policies that are applicable to that
request.The use of constraints limiting the applicability of a policy was described by Sloman [Sloman94].
PEPs come in many forms. For instance, a PEP may be part of a remote-access gateway, part of a Web server or part of an email user-agent, etc. It is unrealistic to expect that all PEPs in an enterprise do currently, or will in the future, issue decision requests to a PDP in a common format. Nevertheless, a particular policy may have to be enforced by multiple PEPs. It would be inefficient to force a policy writer to write the same policy several different ways in order to accommodate the format requirements of each PEP. Similarly attributes may be contained in various envelope types (e.g. X.509 attribute certificates, SAML attribute assertions, etc.). Therefore, there is a need for a canonical form of the request and response handled by an XACML PDP. This canonical form is called the XACML context. Its syntax is defined in XML schema.
Naturally, XACML-conformant PEPs may issue requests and receive responses in the form of an XACML context. But, where this situation does not exist, an intermediate step is required to convert between the request/response format understood by the PEP and the XACML context format understood by the PDP.
The benefit of this approach is that policies may be written and analyzed independently of the specific environment in which they are to be enforced.
In the case where the native request/response format is specified in XML Schema (e.g. a SAML-conformant PEP), the transformation between the native format and the XACML context may be specified in the form of an Extensible Stylesheet Language Transformation [XSLT].
Similarly, in the case where the resource to which access is requested is an XML document, the resource itself may be included in, or referenced by, the request context. Then, through the use of XPath expressions [XPath] in the policy, values in the resource may be included in the policy evaluation.
In many applications, policies specify actions that MUST be performed, either instead of, or in addition to, actions that MAY be performed. This idea was described by Sloman [Sloman94]. XACML provides facilities to specify actions that MUST be performed in conjunction with policy evaluation through obligation notices. This idea was described as a provisional action by Kudo [Kudo00]. There are no standard definitions for these actions in version 3.0 of XACML. Therefore, bilateral agreement between a PAP and the PEP that will enforce its policies is required for correct interpretation. PEPs that conform to v3.0 of XACML are required to deny access unless they understand and can discharge all of the obligation notices associated with the applicable policy. Obligation notices are returned to the PEP for enforcement.
In some applications it is helpful to specify supplemental information about a decision. XACML provides facilities to specify supplemental information about a decision through advice notices. Such advice may be safely ignored by the PEP.
The data-flow model and language model of XACML are described in the following sub-sections.
The major actors in the XACML domain are shown in the data-flow diagram of Figure 1.
The model operates by the following steps.
XACML is intended to be suitable for a variety of application
environments. The core language is insulated from the application
environment by the XACML context, as shown in
Figure 2, in which the scope of
the XACML specification is indicated by the shaded area. The XACML
context is defined in XML schema, describing a
canonical representation for the inputs and outputs of the
PDP. Attributes
referenced by an instance fof XACML policy may
be in the form of XPath expressions over the
<Content> elements of the
context, or
attribute designators that identify the
attribute by its category, identifier,
data-type and (optionally) its issuer. Implementations must convert
between the attribute representations in the
application environment (e.g., SAML, J2SE, CORBA, and so on) and the
attribute representations in the XACML
context. How this is achieved is outside the
scope of the XACML specification. In some cases, such as SAML, this
conversion may be accomplished in an automated way through the use of an
XSLT transformation.
Typical categories of attributes in the context are the subject, resource, action and environment, but users may define their own categories as needed. See Appendix F.2 for suggested attribute categories.
See Section 7.4.5 for a more detailed discussion of the request context.
The policy language model is shown in Figure 3. The main components of the model are:
Rule; and
Policy.
These are described in the following sub-sections.
A rule is the most elementary unit of policy. It may exist in isolation only within one of the major actors of the XACML domain. In order to exchange rules between major actors, they must be encapsulated in a policy. A rule can be evaluated on the basis of its contents. The main components of a rule are:
an effect,
a condition, and
notice expressions.
These are discussed in the following sub-sections.
The condition defines the set of requests to which the rule is intended to apply in the form of a logical expression on attributes in the request. If the rule is intended to apply to all entities of a particular data-type, then the corresponding entity is omitted from the condition. An XACML PDP verifies that the matches defined by the condition are satisfied by the attributes in the request context.
The <Condition> element may be absent from a
<Rule>. In this case, the
condition of the <Rule> is
the same as the target of the parent
<Policy> element.
Certain subject name-forms, resource name-forms and certain types of resource are internally structured. For instance, the X.500 directory name-form and RFC 822 name-form are structured subject name-forms, whereas an account number commonly has no discernible structure. UNIX file-system path-names and URIs are examples of structured resource name-forms. An XML document is an example of a structured resource.
Generally, the name of a node (other than a leaf node) in a
structured name-form is also a legal instance of the name-form. So, for
instance, the RFC822 name med.example.com is a legal RFC822
name identifying the set of mail addresses hosted by the med.example.com
mail server. The XPath value md:record/md:patient/ is a legal XPath
value identifying a node-set in an XML document.
The question arises: how should a name that identifies a set of subjects or resources be interpreted by the PDP, whether it appears in a policy or a request context? Are they intended to represent just the node explicitly identified by the name, or are they intended to represent the entire sub-tree subordinate to that node?
In the case of subjects, there is no real
entity that corresponds to such a node. So, names of this type always
refer to the set of subjects subordinate in
the name structure to the identified node. Consequently, non-leaf
subject names should not be used in equality
functions, only in match functions, such as
urn:oasis:names:tc:xacml:1.0:function:rfc822Name-match
instead of
urn:oasis:names:tc:xacml:1.0:function:rfc822Name-equal (see
Appendix E.3.14).
The effect of the
rule indicates the
rule-writer's intended consequence of a
True evaluation for the
condition. Two values are allowed:
Permit and Deny.
Notice expressions may be added by the writer of the rule.
When a PDP evaluates a rule containing notice expressions, it evaluates the notice expressions into notices and returns certain of those notices to the PEP in the response context. Section 7.18 explains which notices are to be returned.
In contrast to obligation notices, advice notices may be safely ignored by the PEP.
From the data-flow model one can see that rules are not exchanged amongst system entities. Therefore, a PAP combines rules in a policy. A policy comprises four main components:
a target;
a combining algorithm identifier;
a set of rules and policies and
notice expressions.
Rules are described above. The remaining components are described in the following sub-sections.
An XACML <Policy> element contains a
<Target> element that specifies the set of requests
to which it applies. The <Target> of a
<Policy> may be declared by the writer of the
<Policy>, or it may be calculated from the
<Target> and <Condition> elements
of the <Policy> and <Rule>
elements (respectively) that it contains.
A system entity that calculates a <Target> in this
way is not defined by XACML, but there are two logical methods that
might be used. In one method, the <Target> element of
the outer <Policy> (the "outer component") is
calculated as the union of all the <Target> elements
of the referenced <Policy> elements and the
<Condition> elements of the referenced
<Rule> elements (the "inner components"). In another
method, the <Target> element of the outer component
is calculated as the intersection of all the <Target>
and <Condition> elements of the inner components. The
results of evaluation in each case will be very different: in the first
case, the <Target> element of the outer component
makes it applicable to any decision request
that matches the <Target> or
<Condition> element of at least one inner component;
in the second case, the <Target> element of the outer
component makes it applicable only to decision
requests that match the <Target> and
<Condition> elements of every inner component. Note
that computing the intersection of a set of <Target>
and <Condition> elements is likely only practical if
the data-model is relatively simple.
In cases where the <Target> of a
<Policy> is declared by the
policy writer, any component
<Rule> elements in the <Policy>
that have the same <Condition> element as the
<Target> element may omit the
<Condition> element. Such <Rule>
elements inherit the <Target> of the
<Policy> in which they are contained.
The combining algorithm specifies the
procedure by which the results of evaluating the component
rules and policies
are combined when evaluating the policy, i.e.
the Decision value placed in the response
context by the PDP
is the result of evaluating the policy, as
defined by the combining algorithm. A
policy may have combining parameters that
affect the operation of the combining
algorithm.
See Appendix G for definitions of the normative combining algorithms.
The writer of a policy may add notice expressions to the policy, in addition to those contained in the component rules and policies.
When a PDP evaluates a policy containing notice expressions, it evaluates the notice expressions into notices and returns certain of those notices to the PEP in the response context. Section 7.18 explains which notices are to be returned. In contrast to obligation notices, advice notices may be safely ignored by the PEP.
This section contains two examples of the use of XACML for illustrative purposes. The first example is a relatively simple one to illustrate the use of target, context, matching functions and subject attributes. The second example additionally illustrates the use of the combining algorithm, conditions and notices.
Note: this section is referenced.
The <SIDCollection> element defines a collection
of short identifiers. It contains its own
definitions of short identifiers as well as
references to other short identifier
collections, which are imported (recursively) into this collection.
<xs:element name="SIDCollection" type="xacml:SIDCollectionType"/>
<xs:complexType name="SIDCollectionType">
<xs:sequence>
<xs:element ref="xacml:SIDCollectionReference" minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="xacml:ShortIdentifier" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="SIDCollectionId" type="xs:anyURI" use="required"/>
</xs:complexType>The <SIDCollection> element is of
SIDCollectionType complex type.
The <SIDCollection> element contains the following
attributes and elements:
SIDCollectionId [Required]The identifier for this short identifier collection. It is the responsibility of the PAP to ensure that no two short identifier collections visible to the PDP have the same identifier. This MAY be achieved by following a predefined URN or URI scheme. If the identifier is in the form of a URL, then it MAY be resolvable.
<SIDCollectionReference> [Any Number]A reference to another short identifier collection. The short identifiers of the referenced collection are included in this collection. This applies recursively to the collections referenced by a referenced collection. This collection SHALL NOT reference itself and SHALL NOT reference a collection that directly or indirectly references this collection.
<ShortIdentifier> [Any Number]A short identifier that is defined in this collection.
A predefined collection of short identifiers for the URIs defined in this specification is provided as a convenience, in both XML (xacml-core-v4-identifiers.xml) and JSON (xacml-core-v4-identifiers.json) representations. Use of this collection is OPTIONAL.
The <SIDCollectionReference> element is used to
reference a short identifier collection by
URI.
<xs:element name="SIDCollectionReference" type="xs:anyURI"/>The <ShortIdentifier> element defines a single
short identifier.
Attribute categories,
attributes, data types, functions,
combining algorithms and other artifacts in
XACML are ultimately identified by URIs. A short
identifier provides a simple alias name to use when
composing and displaying policies and protocol messages instead of using
the full URI.
<xs:element name="ShortIdentifier" type="xacml:ShortIdentifierType"/>
<xs:complexType name="ShortIdentifierType">
<xs:attribute name="Name" type="xacml:ShortIdentifierNameType" use="required"/>
<xs:attribute name="Value" type="xs:string" use="required"/>
</xs:complexType>
<xs:simpleType name="ShortIdentifierNameType">
<xs:restriction base="xs:string">
<xs:pattern value="[A-Za-z][0-9A-Za-z]*(-[0-9A-Za-z]+)*"/>
<!-- The exact pattern is still open for discussion. -->
</xs:restriction>
</xs:simpleType>The <ShortIdentifier> element is of
ShortIdentifierType complex type.
The <ShortIdentifier> element contains the
following attributes:
Name [Required]A simple alias name that stands for a URI or a part thereof.
Value [Required]The character string used to replace the simple alias name when a
value of IdentifierType is evaluated to produce a complete
URI; see Section 7.3. The value
MAY contain references to other short
identifiers in the form of the short
identifier name enclosed in curly brackets (i.e.,
{ and }; U+007B and U+007D) with the following
restrictions: the value SHALL NOT reference this short
identifier, the value SHALL NOT reference a
short identifier that directly or indirectly
references this short identifier, and the
referenced short identifier MUST be in the
same short identifier collection (which
includes sibling definitions and definitions included by references to
other collections). The characters preceding, following or separating
the short identifier references MUST be
characters allowed in a URI, which means that the curly bracket
characters are not permitted in the value other than to enclose a
short identifier name.
A value of the IdentifierType simple type refers to a
specific attribute category,
attribute, data type, function,
notice, status code, combining
algorithm or XPath version.
<xs:simpleType name="IdentifierType">
<xs:restriction base="xs:string">
<xs:pattern value="[^{}]*({[A-Za-z][0-9A-Za-z]*(-[0-9A-Za-z]+)*}[^{}]*)*"/>
</xs:restriction>
</xs:simpleType>A value of this simple type is either:
{ and }; U+007B and U+007D) optionally
preceded, followed and/or separated by other characters allowed in a
URI.A short identifier name appearing in the second and third cases MUST be the name of a member of a short identifier collection referenced by the containing policy, request or response.
Note that the three cases can be distinguished from each other
syntactically in a valid, correctly formatted value. If the value
contains curly brackets then the third case must apply since the curly
bracket characters are not legal characters for an absolute URI or a
short identifier name; otherwise, if the value
matches the pattern for a short identifier
name then the second case applies since an absolute URI begins with a
scheme name and a colon character (i.e., :; U+003A) and the
colon character is not a legal character for a short
identifier name; otherwise, the value is an absolute
URI.
The conversion of a value of the IdentifierType simple
type into an absolute URI is detailed in Section 7.3.
The <Policy> element is a top-level element in the
XACML policy schema.
<Policy> is an aggregation of
rules and other
policies. Policies
MAY be included in an enclosing <Policy> element
either directly using the <Policy> element or
indirectly using the <PolicyReference> element.
A <Policy> element may be evaluated, in which case
the evaluation procedure defined in Section 7.12 SHALL be used.
The main components of this element are the
<Target>, <Policy>,
<Rule>, <CombinerParameters>,
<PolicyCombinerParameters>,
<RuleCombinerParameters>,
<VariableDefinition> and
<NoticeExpression> elements and the
CombiningAlgId attribute.
If a <Policy> element contains references to other
policies in the form of URLs, then these
references MAY be resolvable.
Policies and
rules included in a
<Policy> element MUST be combined using the algorithm
identified by the CombiningAlgId attribute.
A <Policy> element MAY contain a
<PolicyIssuer> element. The interpretation of the
<PolicyIssuer> element is explained in the separate
administrative policy profile [XACMLAdmin].
The <Target> element defines the applicability of
the <Policy> element to a set of decision
requests. If the <Target> element
within the <Policy> element matches the request
context, then the <Policy>
element MAY be used by the PDP in making its
authorization decision. See Section 7.12.
The <NoticeExpression> elements MUST be evaluated
into notices by the
PDP. Any resulting
obligation notices
MUST be fulfilled by the PEP in conjunction
with the authorization decision. If the
PEP does not understand or cannot fulfill any
of the obligation
notices, then it MUST act according to the
PEP bias. See Section 7.2 and Section 7.18. Any resulting
advice notices MAY
be safely ignored by the PEP.
<xs:element name="Policy" type="xacml:PolicyType"/>
<xs:complexType name="PolicyType">
<xs:sequence>
<xs:element ref="xacml:SIDCollectionReference" minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="xacml:Description" minOccurs="0"/>
<xs:element ref="xacml:PolicyIssuer" minOccurs="0"/>
<xs:element ref="xacml:PolicyDefaults" minOccurs="0"/>
<xs:element ref="xacml:Target" minOccurs="0"/>
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element ref="xacml:Policy"/>
<xs:element ref="xacml:PolicyReference"/>
<xs:element ref="xacml:CombinerParameters"/>
<xs:element ref="xacml:PolicyCombinerParameters"/>
<xs:element ref="xacml:RuleCombinerParameters"/>
<xs:element ref="xacml:VariableDefinition"/>
<xs:element ref="xacml:Rule"/>
</xs:choice>
<xs:element ref="xacml:NoticeExpression" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="PolicyId" type="xs:anyURI" use="required"/>
<xs:attribute name="Version" type="xacml:VersionType" use="required"/>
<xs:attribute name="CombiningAlgId" type="xacml:IdentifierType" use="required"/>
<xs:attribute name="MaxDelegationDepth" type="xs:integer" use="optional"/>
</xs:complexType>The <Policy> element is of PolicyType
complex type.
The <Policy> element contains the following
attributes and elements:
PolicyId [Required]Policy identifier. It is the responsibility of the PAP to ensure that no two policies visible to the PDP have the same identifier. This MAY be achieved by following a predefined URN or URI scheme. If the policy identifier is in the form of a URL, then it MAY be resolvable.
Version [Required]The version number of the Policy.
CombiningAlgId [Required]The identifier of the combining algorithm
by which the <Policy>, <Rule>,
<CombinerParameters>,
<PolicyCombinerParameters> and
<RuleCombinerParameters> components MUST be combined.
Standard combining algorithms are listed in Appendix G.
Standard combining algorithm identifiers are
listed in Appendix F.9.
MaxDelegationDepth [Optional]If present, limits the depth of delegation which is authorized by this policy. See the delegation profile [XACMLAdmin].
<SIDCollectionReference> [Any Number]A reference to a short identifier collection. The short identifiers used by the policy MUST be defined in the referenced collections.
<Description> [Optional]A free-form description of the policy.
<PolicyIssuer> [Optional]Attributes of the issuer of the policy.
<PolicyDefaults> [Optional]A set of default values applicable to the
policy. The scope of the
<PolicyDefaults> element SHALL be the enclosing
policy.
<Target> [Optional]The <Target> element defines the applicability of
a policy to a set of decision
requests.
The <Target> element MAY be declared by the
creator of the <Policy> element or it MAY be computed
from the <Target> elements of the referenced
<Policy> and <Rule> elements,
either as an conjunction or as a disjunction.
<Policy> [Any Number]A policy that is included in this
policy. Policies
whose <Target> elements match the
decision request MUST be considered.
Policies whose <Target>
elements do not match the decision request
SHALL be ignored.
<PolicyReference> [Any Number]A reference to a policy that MUST be
included in this policy. If the
Id attribute of the <PolicyReference>
element is a URL, then it MAY be resolvable.
Policies whose <Target>
elements match the decision request MUST be
considered. Policies whose
<Target> elements do not match the
decision request SHALL be ignored.
<VariableDefinition> [Any Number]Common function definitions that can be referenced from anywhere in a contained policy or rule where an expression can be found.
<Rule> [Any Number]A sequence of rules that MUST be combined
according to the CombiningAlgId attribute.
Rules whose
conditions match the decision
request MUST be considered. Rules whose
conditions do not match the
decision request SHALL be ignored.
<NoticeExpression> [Any Number]A sequence of notice expressions to be evaluated into notices by the PDP. See Section 5.39. See Section 7.18 for a description of how the notices to be returned by the PDP shall be determined.
<CombinerParameters> [Optional]Contains a sequence of <CombinerParameter>
elements. The parameters apply to the combining
algorithm as such and it is up to the specific
combining algorithm to interpret them and
adjust its behavior accordingly.
<PolicyCombinerParameters> [Optional]Contains a sequence of <CombinerParameter>
elements that are associated with a particular
<Policy> or <PolicyReference>
element within the <Policy>. It is up to the specific
combining algorithm to interpret them and
adjust its behavior accordingly.
<RuleCombinerParameters> [Optional]Contains a sequence of <CombinerParameter>
elements that are associated with a particular <Rule>
element within the <Policy>. It is up to the specific
combining algorithm to interpret them and
adjust its behavior accordingly.
The <Description> element contains a free-form
description of the <Policy>,
<Rule> or <Apply> element. The
<Description> element is of xs:string
simple type.
<xs:element name="Description" type="xs:string"/>The <PolicyIssuer> element contains
attributes describing the
issuer of the
policy. The use of the
<PolicyIssuer> element is defined in a separate
administration profile [XACMLAdmin]. A
PDP which does not implement the
administration profile MUST report an error or return an Indeterminate
result if it encounters this element.
<xs:element name="PolicyIssuer" type="xacml:PolicyIssuerType"/>
<xs:complexType name="PolicyIssuerType">
<xs:sequence>
<xs:element ref="xacml:Content" minOccurs="0"/>
<xs:element ref="xacml:Attribute" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>The <PolicyIssuer> element is of
PolicyIssuerType complex type.
The <PolicyIssuer> element contains the following
elements:
<Content> [Optional]Free form XML describing the issuer. See Section 5.45.
<Attribute> [Zero to many]An attribute of the issuer. See Section 5.46.
The <PolicyDefaults> element SHALL specify default
values that apply to the <Policy> element.
<xs:element name="PolicyDefaults" type="xacml:DefaultsType"/>
<xs:complexType name="DefaultsType">
<xs:sequence>
<xs:choice>
<xs:element ref="xacml:XPathVersion">
</xs:choice>
</xs:sequence>
</xs:complexType><PolicyDefaults> element is of
DefaultsType complex type.
The <PolicyDefaults> element contains the
following elements:
<XPathVersion> [Optional]Default XPath version.
The <XPathVersion> element SHALL specify the
version of the XPath specification to be used by
<AttributeSelector> elements and XPath-based
functions in the policy.
<xs:element name="XPathVersion" type="xacml:IdentifierType"/>The URI for the XPath 1.0 specification is
https://www.w3.org/TR/1999/REC-xpath-19991116/.
The URI for the XPath 2.0 specification is
https://www.w3.org/TR/2007/REC-xpath20-20070123/.
The <XPathVersion> element is REQUIRED if the
XACML enclosing policy contains
<AttributeSelector> elements or XPath-based
functions.
The BooleanExpressionType complex type contains one
<Expression> child element, with the restriction that
the <Expression> return data-type MUST be
https://www.w3.org/2001/XMLSchema#boolean.
<xs:complexType name="BooleanExpressionType">
<xs:sequence>
<xs:element ref="xacml:Expression"/>
</xs:sequence>
</xs:complexType>The <Target> and <Condition>
elements are of this type.
Expression evaluation is described in Section 7.5.
The <Target> element identifies the set of
decision requests that the parent
<Policy> element is intended to evaluate. If this
element is omitted from the <Policy> element then the
policy matches all decision
requests.
<xs:element name="Target" type="xacml:BooleanExpressionType"/>The <Target> element is of
BooleanExpressionType complex type. Evaluation of the
<Target> element is described in Section 7.7.
The <PolicyReference> element is used to reference
a policy by identifier and version.
<xs:element name="PolicyReference" type="xacml:PolicyReferenceType"/>
<xs:complexType name="PolicyReferenceType">
<xs:complexContent>
<xs:extension base="xacml:PatternMatchIdReferenceType">
<xs:sequence>
<xs:element ref="xacml:Expression" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="PatternMatchIdReferenceType">
<xs:complexContent>
<xs:extension base="xacml:IdReferenceType">
<xs:attribute name="Version" type="xacml:VersionMatchType" use="optional"/>
<xs:attribute name="EarliestVersion" type="xacml:VersionMatchType" use="optional"/>
<xs:attribute name="LatestVersion" type="xacml:VersionMatchType" use="optional"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="IdReferenceType" abstract="true">
<xs:attribute name="Id" type="xs:anyURI" use="required"/>
</xs:complexType>The <PolicyReference> element is of
xacml:PolicyReferenceType complex type.
The PolicyReferenceType type extends the
PatternMatchIdReferenceType type with the following
elements:
<Expression> [Any Number]Arguments for a parameterized policy.
The PatternMatchIdReferenceType type extends the
IdReferenceType type with the following attributes:
Version [Optional]Specifies a matching expression for an acceptable version of the policy referenced.
EarliestVersion [Optional]Specifies a matching expression for the earliest acceptable version of the policy referenced.
LatestVersion [Optional]Specifies a matching expression for the latest acceptable version of the policy referenced.
The matching operation is defined in Section 5.14. Any
combination of these attributes MAY be present in a
PatternMatchIdReference instance. The referenced
policy MUST match all expressions. If none of
these attributes is present, then any version of the
policy is acceptable. In the case that more
than one matching version can be obtained, then the most recent one
SHOULD be used.
The IdReferenceType type contains the following
attribute:
Id [Required]A URI being the PolicyId of the referenced
policy. If the URI is a URL, then it MAY be
resolvable to the policy. However, the
mechanism for resolving a policy reference to
the corresponding policy is outside the scope
of this specification.
Elements of this type SHALL contain the version number of the policy.
<xs:simpleType name="VersionType">
<xs:restriction base="xs:string">
<xs:pattern value="(\d+\.)*\d+"/>
</xs:restriction>
</xs:simpleType>The version number is expressed as a sequence of decimal numbers,
each separated by a period (.). d+ represents a sequence of
one or more decimal digits.
Elements of this type SHALL contain a restricted regular expression matching a version number (see Section 5.13). The expression SHALL match versions of a referenced policy that are acceptable for inclusion in the referencing policy.
<xs:simpleType name="VersionMatchType">
<xs:restriction base="xs:string">
<xs:pattern value="((\d+|\*)\.)*(\d+|\*|\+)"/>
</xs:restriction>
</xs:simpleType>A version match is .-separated, like a version string. A
number represents a direct numeric match. A \* means that
any single number is valid. A + means that any number, and
any subsequent numbers, are valid. In this manner, the following four
patterns would all match the version string 1.2.3:
1.2.3, 1.\*.3, 1.2.\* and
1.+.
The <CombinerParameters> element conveys
parameters for a combining algorithm.
If multiple <CombinerParameters> elements occur
within the same policy, they SHALL be
considered equal to one <CombinerParameters> element
containing the concatenation of all the sequences of
<CombinerParameter> elements contained in all the
aforementioned <CombinerParameters> elements, such
that the order of occurrence of the
<CombinerParameters> elements is preserved in the
concatenation of the <CombinerParameter>
elements.
Note that none of the combining algorithms specified in XACML 4.0 is parameterized.
<xs:element name="CombinerParameters" type="xacml:CombinerParametersType"/>
<xs:complexType name="CombinerParametersType">
<xs:sequence>
<xs:element ref="xacml:CombinerParameter" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>The <CombinerParameters> element is of
CombinerParametersType complex type.
The <CombinerParameters> element contains the
following elements:
<CombinerParameter> [Any Number]A single parameter. See Section 5.17.
Support for the <CombinerParameters> element is
optional.
The <CombinerParameter> element conveys a single
parameter for a combining algorithm.
<xs:element name="CombinerParameter" type="xacml:CombinerParameterType"/>
<xs:complexType name="CombinerParameterType">
<xs:sequence>
<xs:element ref="xacml:AttributeValue"/>
</xs:sequence>
<xs:attribute name="ParameterName" type="xs:string" use="required"/>
</xs:complexType>The <CombinerParameter> element is of
CombinerParameterType complex type.
The <CombinerParameter> element contains the
following attributes:
ParameterName [Required]The identifier of the parameter.
<AttributeValue> [Required]The value of the parameter.
Support for the <CombinerParameter> element is
optional.
The <RuleCombinerParameters> element conveys
parameters associated with a particular rule
within a policy for a combining algorithm.
Each <RuleCombinerParameters> element MUST be
associated with a rule contained within the
same policy. If multiple
<RuleCombinerParameters> elements reference the same
rule, they SHALL be considered equal to one
<RuleCombinerParameters> element containing the
concatenation of all the sequences of
<CombinerParameter> elements contained in all the
aforementioned <RuleCombinerParameters> elements,
such that the order of occurrence of the
<RuleCombinerParameters> elements is preserved in the
concatenation of the <CombinerParameter>
elements.
Note that none of the combining algorithms specified in XACML 4.0 is parameterized.
<xs:element name="RuleCombinerParameters" type="xacml:RuleCombinerParametersType"/>
<xs:complexType name="RuleCombinerParametersType">
<xs:complexContent>
<xs:extension base="xacml:CombinerParametersType">
<xs:attribute name="RuleIdRef" type="xs:string" use="required"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>The <RuleCombinerParameters> element contains the
following attribute:
RuleIdRef [Required]The identifier of the <Rule> contained in the
policy.
Support for the <RuleCombinerParameters> element
is optional, only if support for combiner parameters is not
implemented.
The <PolicyCombinerParameters> element conveys
parameters associated with a particular contained
policy for a combining
algorithm.
Each <PolicyCombinerParameters> element MUST be
associated with a policy contained within the
same enclosing policy. If multiple
<PolicyCombinerParameters> elements reference the
same policy, they SHALL be considered equal to
one <PolicyCombinerParameters> element containing the
concatenation of all the sequences of
<CombinerParameter> elements contained in all the
aforementioned <PolicyCombinerParameters> elements,
such that the order of occurrence of the
<PolicyCombinerParameters> elements is preserved in
the concatenation of the <CombinerParameter>
elements.
Note that none of the combining algorithms specified in XACML 4.0 is parameterized.
<xs:element name="PolicyCombinerParameters" type="xacml:PolicyCombinerParametersType"/>
<xs:complexType name="PolicyCombinerParametersType">
<xs:complexContent>
<xs:extension base="xacml:CombinerParametersType">
<xs:attribute name="PolicyIdRef" type="xs:anyURI" use="required"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>The <PolicyCombinerParameters> element is of
PolicyCombinerParametersType complex type.
The <PolicyCombinerParameters> element contains
the following attribute:
PolicyIdRef [Required]The identifier of a <Policy> or the value of a
<PolicyReference> contained in the
policy.
Support for the <PolicyCombinerParameters> element
is optional, only if support for combiner parameters is not
implemented.
The <Rule> element SHALL define the individual
rules in the policy.
The main components of this element are the
<Condition> and <NoticeExpression>
elements and the Effect attribute.
A <Rule> element may be evaluated, in which case
the evaluation procedure defined in Section 7.10 SHALL be used.
<xs:element name="Rule" type="xacml:RuleType"/>
<xs:complexType name="RuleType">
<xs:sequence>
<xs:element ref="xacml:Description" minOccurs="0"/>
<xs:element ref="xacml:Condition" minOccurs="0"/>
<xs:element ref="xacml:NoticeExpression" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="RuleId" type="xs:string" use="required"/>
<xs:attribute name="Effect" type="xacml:EffectType" use="required"/>
</xs:complexType>The <Rule> element is of RuleType
complex type.
The <Rule> element contains the following
attributes and elements:
RuleId [Required]A string identifying this rule. It is the responsibility of the PAP to ensure that no two _rules in the same policy have the same identifier.
Effect [Required]Rule effect. The value of this attribute is
either Permit or Deny.
<Description> [Optional]A free-form description of the rule.
<Condition> [Optional]A predicate that MUST be satisfied for the
rule to be assigned its Effect
value.
<NoticeExpression> [Any Number]A sequence of notice expressions to be evaluated into notices by the PDP. See Section 5.39. See Section 7.18 for a description of how the notices to be returned by the PDP shall be determined. See Section 7.2 about enforcement of obligation notices.
The EffectType simple type defines the values allowed
for the Effect attribute of the <Rule>
element and for the AppliesTo attribute of the
<NoticeExpression> elements.
<xs:simpleType name="EffectType">
<xs:restriction base="xs:string">
<xs:enumeration value="Permit"/>
<xs:enumeration value="Deny"/>
</xs:restriction>
</xs:simpleType>The <VariableDefinition> element SHALL be used to
define a value that can be referenced by a
<VariableReference> element. The name supplied for
its VariableId attribute SHALL NOT occur in the
VariableId attribute of any other
<VariableDefinition> element within the encompassing
policy. The
<VariableDefinition> element MAY contain undefined
<VariableReference> elements, but if it does, a
corresponding <VariableDefinition> element MUST be
defined later in the encompassing policy.
<VariableDefinition> elements MAY be grouped together
or MAY be placed close to the reference in the encompassing
policy. There MAY be zero or more references
to each <VariableDefinition> element.
<xs:element name="VariableDefinition" type="xacml:VariableDefinitionType"/>
<xs:complexType name="VariableDefinitionType">
<xs:sequence>
<xs:element ref="xacml:Expression"/>
</xs:sequence>
<xs:attribute name="VariableId" type="xs:string" use="required"/>
</xs:complexType>The <VariableDefinition> element is of
VariableDefinitionType complex type. The
<VariableDefinition> element has the following
elements and attributes:
<Expression> [Required]Any element of ExpressionType complex type.
VariableId [Required]The name of the variable definition.
The <VariableReference> element is used to
reference a value defined within the same encompassing
<Policy> element. The
<VariableReference> element SHALL refer to the
<VariableDefinition> element by
identifier equality on the value of their
respective VariableId attributes. One and only one
<VariableDefinition> MUST exist within the same
encompassing <Policy> element to which the
<VariableReference> refers. There MAY be zero or more
<VariableReference> elements that refer to the same
<VariableDefinition> element.
<xs:element name="VariableReference" type="xacml:VariableReferenceType" substitutionGroup="xacml:Expression"/>
<xs:complexType name="VariableReferenceType">
<xs:complexContent>
<xs:extension base="xacml:ExpressionType">
<xs:attribute name="VariableId" type="xs:string" use="required"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>The <VariableReference> element is of the
VariableReferenceType complex type, which is of the
ExpressionType complex type and is a member of the
<Expression> element substitution group. The
<VariableReference> element MAY appear any place
where an <Expression> element occurs in the
schema.
The <VariableReference> element has the following
attribute:
VariableId [Required]The name used to refer to the value defined in a
<VariableDefinition> element.
The <Expression> element is not used directly in a
policy. The <Expression>
element signifies that an element that extends the
ExpressionType and is a member of the
<Expression> element substitution group SHALL appear
in its place.
<xs:element name="Expression" type="xacml:ExpressionType" abstract="true"/>
<xs:complexType name="ExpressionType" abstract="true"/>The following elements are in the <Expression>
element substitution group:
<Apply>, <AttributeSelector>,
<AttributeValue>, <Function>,
<VariableReference> and
<AttributeDesignator>.
The <Condition> element is a Boolean function over
attributes or functions of
attributes.
<xs:element name="Condition" type="xacml:BooleanExpressionType"/>The <Condition> element is of
BooleanExpressionType complex type. Evaluation of the
<Condition> element is described in Section 7.9.
The <Apply> element denotes application of a
function to its arguments, thus encoding a function call. The
<Apply> element can be applied to any combination of
the members of the <Expression> element substitution
group. See Section 5.25.
<xs:element name="Apply" type="xacml:ApplyType" substitutionGroup="xacml:Expression"/>
<xs:complexType name="ApplyType">
<xs:complexContent>
<xs:extension base="xacml:ExpressionType">
<xs:sequence>
<xs:element ref="xacml:Description" minOccurs="0"/>
<xs:element ref="xacml:Expression" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="FunctionId" type="xacml:IdentifierType" use="required"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>The <Apply> element is of ApplyType
complex type.
The <Apply> element contains the following
attributes and elements:
FunctionId [Required]The identifier of the function to be applied to the arguments. XACML-defined functions are described in Appendix E.3.
<Description> [Optional]A free-form description of the <Apply>
element.
<Expression> [Optional]Arguments to the function, which may include other functions.
The <Function> element SHALL be used to name a
function as an argument to the function defined by the parent
<Apply> element.
<xs:element name="Function" type="xacml:FunctionType" substitutionGroup="xacml:Expression"/>
<xs:complexType name="FunctionType">
<xs:complexContent>
<xs:extension base="xacml:ExpressionType">
<xs:attribute name="FunctionId" type="xacml:IdentifierType" use="required"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>The <Function> element is of
FunctionType complex type.
The <Function> element contains the following
attribute:
FunctionId [Required]The identifier of the function.
The <AttributeDesignator> element retrieves a
bag of values for a named
attribute from the request
context. A named
attribute SHALL be considered present if there is at least
one attribute that matches the criteria set
out below.
The <AttributeDesignator> element SHALL return a
bag containing all the
attribute values that are matched by the
named attribute. In the event that no matching
attribute is present in the
context, the MustBePresent
attribute governs whether this element returns an empty
bag or Indeterminate. See Section 7.4.5.
The <AttributeDesignator> MAY appear in the
<Match> element and MAY be passed to the
<Apply> element as an argument.
The <AttributeDesignator> element is of the
AttributeDesignatorType complex type.
<xs:element name="AttributeDesignator" type="xacml:AttributeDesignatorType" substitutionGroup="xacml:Expression"/>
<xs:complexType name="AttributeDesignatorType">
<xs:complexContent>
<xs:extension base="xacml:ExpressionType">
<xs:attribute name="Category" type="xacml:IdentifierType" use="required"/>
<xs:attribute name="AttributeId" type="xacml:IdentifierType" use="required"/>
<xs:attribute name="DataType" type="xacml:IdentifierType" use="required"/>
<xs:attribute name="Issuer" type="xs:string" use="optional"/>
<xs:attribute name="MustBePresent" type="xs:boolean" use="optional" default="false"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>A named attribute SHALL match an
attribute if the values of their respective
Category, AttributeId, DataType
and Issuer attributes match. The attribute designator's
Category MUST match, by identifier
equality, the Category of the
<Attributes> element in which the
attribute is present. The attribute
designator's AttributeId MUST match, by
identifier equality, the
AttributeId of the attribute. The
attribute designator's DataType MUST match, by
identifier equality, the DataType
of the same attribute.
If the Issuer attribute is present in the attribute
designator, then it MUST match, using the
urn:oasis:names:tc:xacml:1.0:function:string-equal
function, the Issuer of the same
attribute. If the Issuer is not
present in the attribute designator, then the matching of the
attribute to the named
attribute SHALL be governed by AttributeId
and DataType attributes alone.
The <AttributeDesignatorType> contains the
following attributes:
Category [Required]This attribute SHALL specify the Category with which to match the attribute.
AttributeId [Required]This attribute SHALL specify the AttributeId with which to match the attribute.
DataType [Required]The bag returned by the
<AttributeDesignator> element SHALL contain values of
this data-type.
Issuer [Optional]This attribute, if supplied, SHALL specify the Issuer with which to match the attribute.
MustBePresent [Optional]This attribute governs whether the element returns
Indeterminate or an empty bag in
the event the named attribute is absent from
the request context. See Section 7.4.5. Also see Section 7.19.2 and Section 7.19.3. If this attribute is
omitted it is treated as being set to 'false'.
The <AttributeSelector> element produces a
bag of unnamed and uncategorized
attribute values. The values shall be
constructed from the node(s) selected by applying the XPath expression
given by the element's Path attribute to the XML content indicated by
the element's Category attribute. Support for the
<AttributeSelector> element is OPTIONAL.
See Section 7.4.7 for
details of <AttributeSelector> evaluation.
<xs:element name="AttributeSelector" type="xacml:AttributeSelectorType" substitutionGroup="xacml:Expression"/>
<xs:complexType name="AttributeSelectorType">
<xs:complexContent>
<xs:extension base="xacml:ExpressionType">
<xs:attribute name="Category" type="xacml:IdentifierType" use="required"/>
<xs:attribute name="ContextSelectorId" type="xacml:IdentifierType" use="optional"/>
<xs:attribute name="Path" type="xs:string" use="required"/>
<xs:attribute name="DataType" type="xacml:IdentifierType" use="required"/>
<xs:attribute name="MustBePresent" type="xs:boolean" use="optional" default="false"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>The <AttributeSelector> element is of
AttributeSelectorType complex type.
The <AttributeSelector> element has the following
attributes:
Category [Required]This attribute SHALL specify the attributes
category of the <Content> element containing the XML
from which nodes will be selected. It also indicates the
attributes category containing the applicable
ContextSelectorId attribute, if the element includes a
ContextSelectorId XML attribute.
ContextSelectorId [Optional]This attribute refers to the attribute (by
its AttributeId) in the request
context in the category given by the
Category attribute. The referenced
attribute MUST have data type
urn:oasis:names:tc:xacml:3.0:data-type:xpathExpression, and must select
a single node in the <Content> element. The
XPathCategory attribute of the referenced
attribute MUST be equal to the
Category attribute of the attribute selector.
Path [Required]This attribute SHALL contain an XPath expression to be evaluated
against the specified XML content. See Section 7.4.7 for details
of the XPath evaluation during <AttributeSelector>
processing. The namespace context for the value of the Path attribute is
given by the [in-scope namespaces] [INFOSET] of
the <AttributeSelector> element.
DataType [Required]The attribute specifies the datatype of the values returned from the
evaluation of this <AttributeSelector> element.
MustBePresent [Optional]This attribute governs whether the element returns
Indeterminate or an empty bag in
the event that the attributes category specified by the
Category attribute does not exist in the request
context, or the attributes category does exist
but it does not have a <Content> child element, or
the <Content> element does exist but the XPath
expression selects no node. See Section 7.4.5. Also see Section 7.19.2 and Section 7.19.3. If this attribute is
omitted it is treated as being set to 'false'.
The <AttributeValue> element SHALL contain a
literal attribute value.
<xs:element name="AttributeValue" type="xacml:AttributeValueType" substitutionGroup="xacml:Expression"/>
<xs:complexType name="AttributeValueType" mixed="true">
<xs:complexContent mixed="true">
<xs:extension base="xacml:ExpressionType">
<xs:sequence>
<xs:any namespace="##any" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="DataType" type="xacml:IdentifierType" use="required"/>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>The <AttributeValue> element is of
AttributeValueType complex type.
The <AttributeValue> element has the following
attributes:
DataType [Required]The data-type of the attribute value.
The <Notice> element SHALL contain an identifier
for the notice and a list of
attribute assignments that form arguments of
the notice.
<xs:element name="Notice" type="xacml:NoticeType"/>
<xs:complexType name="NoticeType">
<xs:sequence>
<xs:element ref="xacml:AttributeAssignment" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="Id" type="xacml:IdentifierType" use="required"/>
<xs:attribute name="IsObligation" type="xs:boolean" use="optional" default="false"/>
</xs:complexType>The <Notice> element is of NoticeType
complexType. See Section 7.18 for a
description of how the list of notices to be
returned by the PDP is determined.
The <Notice> element contains the following
elements and attributes:
Id [Required]An identifier for the notice that the PEP associates with particular processing requirements or informational content.
IsObligation [Optional]If IsObligation is present and set to true then the
notice is an obligation; otherwise, the
notice is
advice.
<AttributeAssignment> [Any Number]A list of attribute assignments for forming the arguments of the notice.
The <AttributeAssignment> element is used for
including arguments in notice expressions. It
SHALL contain an AttributeId and the corresponding
attribute value, by extending the
AttributeValueType type definition. The
<AttributeAssignment> element MAY be used in any way
that is consistent with the schema syntax, which is a sequence of
<xs:any> elements. The value specified SHALL be
understood by the PEP, but it is not further
specified by XACML. See Section 7.18. Section 4.2.4.3 provides a number of examples of
attribute assignments included in
notices.
<xs:element name="AttributeAssignment" type="xacml:AttributeAssignmentType"/>
<xs:complexType name="AttributeAssignmentType" mixed="true">
<xs:complexContent>
<xs:extension base="xacml:AttributeValueType">
<xs:attribute name="AttributeId" type="xacml:IdentifierType" use="required"/>
<xs:attribute name="Category" type="xacml:IdentifierType" use="optional"/>
<xs:attribute name="Issuer" type="xs:string" use="optional"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>The <AttributeAssignment> element is of
AttributeAssignmentType complex type.
The <AttributeAssignment> element contains the
following attributes:
AttributeId [Required]The attribute Identifier.
Category [Optional]An optional category of the attribute. If
this attribute is missing, the attribute has
no category. The PEP SHALL interpret the
significance and meaning of any Category attribute.
Non-normative note: an expected use of the category is to disambiguate
attributes that are relayed from the
request.
Issuer [Optional]An optional issuer of the attribute. If
this attribute is missing, the attribute has
no issuer. The PEP SHALL interpret the
significance and meaning of any Issuer attribute.
Non-normative note: an expected use of the issuer is to disambiguate
attributes that are relayed from the
request.
The <NoticeExpression> element evaluates to a
notice and SHALL contain an identifier for the
notice and a set of expressions that form
arguments of the notice. The
AppliesTo attribute indicates the
effect for which this
notice is eligible to be provided to the
PEP. If the AppliesTo attribute
is absent then this notice is eligible to be
provided to the PEP if the
effect is either Permit or
Deny.
<xs:element name="NoticeExpression" type="xacml:NoticeExpressionType"/>
<xs:complexType name="NoticeExpressionType">
<xs:sequence>
<xs:element ref="xacml:Condition" minOccurs="0"/>
<xs:element ref="xacml:AttributeAssignmentExpression" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="Id" type="xacml:IdentifierType" use="required"/>
<xs:attribute name="IsObligation" type="xs:boolean" use="optional"/>
<xs:attribute name="AppliesTo" type="xacml:EffectType" use="optional"/>
</xs:complexType>The <NoticeExpression> element is of
NoticeExpressionType complexType. See Section 7.18 for a description of how the list
of notices to be returned by the
PDP is determined.
The <NoticeExpression> element contains the
following elements and attributes:
Id [Required]An identifier for the notice that the PEP associates with particular processing requirements or informational content.
IsObligation [Optional]The setting for the IsObligation attribute of the
notice. If IsObligation is
present then the IsObligation attribute of the
notice is set to the same value; otherwise,
the IsObligation attribute is omitted from the
notice.
AppliesTo [Optional]The effect for which this
notice is eligible to be provided to the
PEP, or if absent, either Permit
or Deny.
Condition [Optional]An optional condition that must be
satisfied for this notice to be provided to
the PEP. An absent
condition is treated as True.
<AttributeAssignmentExpression> [Any Number]Notice arguments in the form of
expressions. The expressions SHALL be evaluated by the PDP to constant
<AttributeValue> elements or
bags, which shall be the attribute assignments
in the <Notice> returned to the PEP. If an
<AttributeAssignmentExpression> evaluates to an
atomic attribute value, then there MUST be one
resulting <AttributeAssignment> which MUST contain
this single attribute value. If the
<AttributeAssignmentExpression> evaluates to a
bag, then there MUST be a resulting
<AttributeAssignment> for each of the values in the
bag. If the bag is
empty, there shall be no <AttributeAssignment> from
this <AttributeAssignmentExpression>. The values of
the notice arguments SHALL be interpreted by
the PEP.
The <AttributeAssignmentExpression> element is
used for including arguments in notices. It
SHALL contain an AttributeId and an expression which SHALL
by evaluated into the corresponding attribute
value. The value specified SHALL be understood by the
PEP, but it is not further specified by XACML.
See Section 7.18. Section 4.2.4.3 provides a number of examples of
attribute assignment expressions included in
notice expressions.
<xs:element name="AttributeAssignmentExpression" type="xacml:AttributeAssignmentExpressionType"/>
<xs:complexType name="AttributeAssignmentExpressionType">
<xs:sequence>
<xs:element ref="xacml:Expression"/>
</xs:sequence>
<xs:attribute name="AttributeId" type="xacml:IdentifierType" use="required"/>
<xs:attribute name="Category" type="xacml:IdentifierType" use="optional"/>
<xs:attribute name="Issuer" type="xs:string" use="optional"/>
</xs:complexType>The <AttributeAssignmentExpression> element is of
AttributeAssignmentExpressionType complex type.
The <AttributeAssignmentExpression> element
contains the following attributes:
<Expression> [Required]The expression which evaluates to a constant attribute value or a bag of zero or more attribute values. See Section 5.25.
AttributeId [Required]The attribute identifier. The value of the
AttributeId attribute in the resulting
<AttributeAssignment> element MUST be equal to this
value.
Category [Optional]An optional category of the attribute. If
this attribute is missing, the attribute has
no category. The value of the Category attribute in the
resulting <AttributeAssignment> element MUST be equal
to this value.
Issuer [Optional]An optional issuer of the attribute. If
this attribute is missing, the attribute has
no issuer. The value of the Issuer attribute in the
resulting <AttributeAssignment> element MUST be equal
to this value.
The <Request> element is an abstraction layer used
by the policy language. For simplicity of
expression, this document describes policy
evaluation in terms of operations on the
context. However a conforming
PDP is not required to actually instantiate
the context in the form of an XML document.
But, any system conforming to the XACML specification MUST produce
exactly the same authorization decisions as if
all the inputs had been transformed into the form of an
<Request> element.
<xs:element name="Request" type="xacml:RequestType"/>
<xs:complexType name="RequestType">
<xs:sequence>
<xs:element ref="xacml:SIDCollectionReference" minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="xacml:RequestDefaults" minOccurs="0"/>
<xs:element ref="xacml:Attributes" maxOccurs="unbounded"/>
<xs:element ref="xacml:MultiRequests" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="ReturnPolicyIdList" type="xs:boolean" use="optional" default="false"/>
<xs:attribute name="CombinedDecision" type="xs:boolean" use="optional" default="false"/>
</xs:complexType>The <Request> element is of
RequestType complex type.
The <Request> element contains the following
elements and attributes:
ReturnPolicyIdList [Optional]This attribute is used to request that the
PDP return a list of all fully applicable
policies which were used in the decision as a
part of the decision response. If this attribute is omitted it is
treated as being set to false.
CombinedDecision [Optional]This attribute is used to request that the
PDP combines multiple decisions into a single
decision. The use of this attribute is specified in [Multi]. If the PDP does not
implement the relevant functionality in [Multi],
then the PDP must return an Indeterminate with
a status code of urn:oasis:names:tc:xacml:1.0:status:processing-error if
it receives a request with this attribute set to true. If
this attribute is omitted it is treated as being set to
false.
<SIDCollectionReference> [Any Number]A reference to a short identifier collection. The short identifiers used by the request MUST be defined in the referenced collections.
<RequestDefaults> [Optional]Contains default values for the request, such as XPath version. See Section 5.43.
<Attributes> [One to Many]Specifies information about attributes of
the request context by listing a sequence of
<Attribute> elements associated with an
attribute category. One or more
<Attributes> elements are allowed. Different
<Attributes> elements with different categories are
used to represent information about the
subject, resource,
action, environment
or other categories of the access request.
The <Request> element contains
<Attributes> elements. There may be multiple
<Attributes> elements with the same
Category attribute if the PDP
implements the multiple decision profile, see [Multi]. Under other conditions, it is a syntax error
if there are multiple <Attributes> elements with the
same Category (see Section 7.19.2 for error
codes).
<MultiRequests> [Optional]Lists multiple request contexts by
references to the <Attributes> elements.
Implementation of this element is optional. The semantics of this
element is defined in [Multi]. If the
implementation does not implement this element, it MUST return an
Indeterminate result if it encounters this element. See Section 5.50.
The <RequestDefaults> element SHALL specify
default values that apply to the <Request>
element.
<xs:element name="RequestDefaults" type="xacml:RequestDefaultsType"/>
<xs:complexType name="RequestDefaultsType">
<xs:sequence>
<xs:choice>
<xs:element ref="xacml:XPathVersion"/>
</xs:choice>
</xs:sequence>
</xs:complexType>The <RequestDefaults> element is of
RequestDefaultsType complex type.
The <RequestDefaults> element contains the
following elements:
<XPathVersion> [Optional]Default XPath version for XPath expressions occurring in the request.
The <Attributes> element specifies
attributes of a
subject, resource,
action, environment
or another category by listing a sequence of
<Attribute> elements associated with the
category.
<xs:element name="Attributes" type="xacml:AttributesType"/>
<xs:complexType name="AttributesType">
<xs:sequence>
<xs:element ref="xacml:Content" minOccurs="0"/>
<xs:element ref="xacml:Attribute" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="Category" type="xacml:IdentifierType" use="required"/>
<xs:attribute ref="xml:id" use="optional"/>
</xs:complexType>The <Attributes> element is of
AttributesType complex type.
The <Attributes> element contains the following
elements and attributes:
Category [Required]This attribute indicates which attribute
category the contained attributes belong to.
The Category attribute is used to differentiate between
attributes of
subject, resource,
action, environment
or other categories.
xml:id [Optional]This attribute provides a unique identifier for this
<Attributes> element. See [XMLid]. It is primarily intended to be referenced in
multiple requests. See [Multi].
<Content> [Optional]Specifies additional sources of attributes
in free form XML document format which can be referenced using
<AttributeSelector> elements.
<Attribute> [Any Number]A sequence of attributes that apply to the category of the request.
The <Content> element is a notional placeholder
for additional attributes, typically the
content of the resource.
<xs:element name="Content" type="xacml:ContentType"/>
<xs:complexType name="ContentType" mixed="true">
<xs:sequence>
<xs:any namespace="##any" processContents="lax"/>
</xs:sequence>
</xs:complexType>The <Content> element is of
ContentType complex type.
The <Content> element has exactly one arbitrary
type child element.
The <Attribute> element is the central abstraction
of the request context. It contains
attribute meta-data and one or more
attribute values. The
attribute meta-data comprises the
attribute identifier and the
attribute issuer.
<AttributeDesignator> elements in the
policy MAY refer to
attributes by means of this meta-data.
<xs:element name="Attribute" type="xacml:AttributeType"/>
<xs:complexType name="AttributeType">
<xs:sequence>
<xs:element ref="xacml:AttributeValue" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="AttributeId" type="xacml:IdentifierType" use="required"/>
<xs:attribute name="Issuer" type="xs:string" use="optional"/>
<xs:attribute name="IncludeInResult" type="xs:boolean" use="required"/>
</xs:complexType>The <Attribute> element is of
AttributeType complex type.
The <Attribute> element contains the following
attributes and elements:
AttributeId [Required]The attribute identifier. A number of identifiers are reserved by XACML to denote commonly used attributes. See Appendix F.
Issuer [Optional]The attribute issuer. For example, this
attribute value MAY be an x500Name that binds to a public
key, or it may be some other identifier exchanged out-of-band by issuing
and relying parties.
IncludeInResult [Default: false]Whether to include this attribute in the result. This is useful to correlate requests with their responses in case of multiple requests.
<AttributeValue> [One to Many]One or more attribute values. Each attribute value MAY have contents that are empty, occur once or occur multiple times.
The <Response> element is an abstraction layer
used by the policy language. Any proprietary
system using the XACML specification MUST transform an XACML
context <Response> element
into the form of its authorization
decision.
The <Response> element encapsulates the
authorization decision produced by the
PDP. It includes a sequence of one or more
results, with one <Result> element per requested
resource. Multiple results MAY be returned by
some implementations, in particular those that support the XACML Profile
for Requests for Multiple Resources [Multi].
Support for multiple results is OPTIONAL.
<xs:element name="Response" type="xacml:ResponseType"/>
<xs:complexType name="ResponseType">
<xs:sequence>
<xs:element ref="xacml:SIDCollectionReference" minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="xacml:Result" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>The <Response> element is of
ResponseType complex type.
The <Response> element contains the following
elements:
<SIDCollectionReference> [Any Number]A reference to a short identifier collection. The short identifiers used by the response MUST be defined in the referenced collections.
<Result> [One to Many]An authorization decision result. See Section 5.48.
The <Result> element represents an
authorization decision result. It MAY include
a list of notices. If the
PEP does not understand or cannot fulfill an
obligation notice,
then the action of the PEP is determined by
its bias, see Section 7.2.
Any advice notices
MAY be safely ignored by the PEP.
<xs:complexType name="ResultType">
<xs:sequence>
<xs:element ref="xacml:Decision"/>
<xs:element ref="xacml:Status" minOccurs="0"/>
<xs:element ref="xacml:Notice" minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="xacml:Attributes" minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="xacml:ApplicablePolicyReference" minOccurs="0" maxOccurs="unbounded" />
</xs:sequence>
</xs:complexType>The <Result> element is of ResultType
complex type.
The <Result> element contains the following
attributes and elements:
<Decision> [Required]The authorization decision:
Permit, Deny, Indeterminate or
NotApplicable.
<Status> [Optional]Indicates whether errors occurred during evaluation of the
decision request, and optionally, information
about those errors. If the <Response> element
contains <Result> elements whose
<Status> elements are all identical, and the
<Response> element is contained in a protocol wrapper
that can convey status information, then the common status information
MAY be placed in the protocol wrapper and this
<Status> element MAY be omitted from all
<Result> elements.
<Notice> [any Number]A list of notices to be interpreted by the PEP. See Section 5.34. If the PEP does not understand or cannot fulfill an obligation notice, then the action of the PEP is determined by its bias, see Section 7.2. If the PEP does not understand an advice notice, the PEP may safely ignore the notice. See Section 7.18 for a description of how the list of notices to be returned by the PDP is determined.
<Attributes> [Optional]A list of attributes that were part of the
request. The choice of which attributes are
included here is made with the IncludeInResult attribute of
the <Attribute> elements of the request. See Section 5.46.
<ApplicablePolicyReference> [Optional]If the ReturnPolicyIdList attribute in the
<Request> is true (see Section 5.42), a
PDP that implements this optional feature MUST
return a list which includes the identifiers of all
policies which were found to be fully
applicable, whether or not the <Effect> (after rule
combining) was the same or different from the
<Decision>. The list is unordered. The list MAY
include the identifiers of other policies which are currently in force,
as long as no policies required for the decision are omitted. A
PDP MAY satisfy this requirement by including
all policies currently in force, or by including all policies which were
evaluated in making the decision, or by including all policies which did
not evaluate to NotApplicable, or by any other algorithm
which does not omit any policies which contributed to the decision.
However, a decision which returns NotApplicable MUST return
an empty list.
The <ApplicablePolicyReference> element contains
the policy identifier of a
policy that has been applicable to a
request.
<xs:element name="ApplicablePolicyReference" type="xacml:ExactMatchIdReferenceType"/>
<xs:complexType name="ExactMatchIdReferenceType">
<xs:complexContent>
<xs:extension base="xacml:IdReferenceType">
<xs:attribute name="Version" type="xacml:VersionType" use="required"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>The <ApplicablePolicyReference> element is of
ExactMatchIdReferenceType complex type.
The ExactMatchIdReferenceType type extends the
IdReferenceType type with the following attribute:
<Version> [Required]The version of a policy that was applicable to the request. See Section 5.12.
The <MultiRequests> element contains a list of
requests by reference to <Attributes> elements in the
enclosing <Request> element. The semantics of this
element are defined in [Multi]. Support for this
element is optional. If an implementation does not support this element,
but receives it, the implementation MUST generate an
Indeterminate response.
<xs:element name="MultiRequests" type="xacml:MultiRequestsType"/>
<xs:complexType name="MultiRequestsType">
<xs:sequence>
<xs:element ref="xacml:RequestReference" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>The <MultiRequests> element contains the following
elements.
<RequestReference> [one to many]Defines a request instance by reference to
<Attributes> elements in the enclosing
<Request> element. See Section 5.51.
The <RequestReference> element defines an instance
of a request in terms of references to <Attributes>
elements. The semantics of this element are defined in [Multi]. Support for this element is optional.
<xs:element name="RequestReference" type="xacml:RequestReference "/>
<xs:complexType name="RequestReferenceType">
<xs:sequence>
<xs:element ref="xacml:AttributesReference" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>The <RequestReference> element contains the
following elements.
<AttributesReference> [one to many]A reference to an <Attributes> element in the
enclosing <Request> element. See Section 5.52.
The <AttributesReference> element makes a
reference to an <Attributes> element. The meaning of
this element is defined in [Multi]. Support for
this element is optional.
<xs:element name="AttributesReference" type="xacml:AttributesReference"/>
<xs:complexType name="AttributesReferenceType">
<xs:attribute name="ReferenceId" type="xs:IDREF" use="required" />
</xs:complexType>The <AttributesReference> element contains the
following attributes.
ReferenceId [required]A reference to the xml:id attribute of an
<Attributes> element in the enclosing
<Request> element.
The <Decision> element contains the result of
policy evaluation.
<xs:element name="Decision" type="xacml:DecisionType"/>
<xs:simpleType name="DecisionType">
<xs:restriction base="xs:string">
<xs:enumeration value="Permit"/>
<xs:enumeration value="Deny"/>
<xs:enumeration value="Indeterminate"/>
<xs:enumeration value="NotApplicable"/>
</xs:restriction>
</xs:simpleType>The <Decision> element is of
DecisionType simple type.
<Decision> element have the
following meanings:Permit: the requested access
is permitted.
Deny: the requested access is
denied.
Indeterminate: the PDP is
unable to evaluate the requested access.
Reasons for such inability include: missing
attributes, network errors while retrieving
policies, division by zero during
policy evaluation, syntax errors in the
decision request or in the
policy, etc.
NotApplicable: the PDP does
not have any policy that applies to this
decision request.
The <Status> element represents the status of the
authorization decision result.
<xs:element name="Status" type="xacml:StatusType"/>
<xs:complexType name="StatusType">
<xs:sequence>
<xs:element ref="xacml:StatusCode"/>
<xs:element ref="xacml:StatusMessage" minOccurs="0"/>
<xs:element ref="xacml:StatusDetail" minOccurs="0"/>
</xs:sequence>
</xs:complexType>The <Status> element is of StatusType
complex type.
The <Status> element contains the following
elements:
<StatusCode> [Required]Status code.
<StatusMessage> [Optional]A status message describing the status code.
<StatusDetail> [Optional]Additional status information.
The <StatusCode> element contains a major status
code value and an optional recursive series of minor status codes.
<xs:element name="StatusCode" type="xacml:StatusCodeType"/>
<xs:complexType name="StatusCodeType">
<xs:sequence>
<xs:element ref="xacml:StatusCode" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="Value" type="xacml:IdentifierType" use="required"/>
</xs:complexType>The <StatusCode> element is of
StatusCodeType complex type.
The <StatusCode> element contains the following
attributes and elements:
Value [Required]See Appendix F.8 for a list of values.
<StatusCode> [Any Number]Minor status code. This status code qualifies its parent status code.
The <StatusMessage> element is a free-form
description of the status code.
<xs:element name="StatusMessage" type="xs:string"/>The <StatusMessage> element is of
xs:string type.
The <StatusDetail> element qualifies the
<Status> element with additional information.
<xs:element name="StatusDetail" type="xacml:StatusDetailType"/>
<xs:complexType name="StatusDetailType">
<xs:sequence>
<xs:any namespace="##any" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>The <StatusDetail> element is of
StatusDetailType complex type.
The <StatusDetail> element allows arbitrary XML
content.
Inclusion of a <StatusDetail> element is optional.
However, if a PDP returns one of the following
XACML-defined <StatusCode> values and includes a
<StatusDetail> element, then the following rules
apply.
urn:oasis:names:tc:xacml:1.0:status:okA PDP MUST NOT return a
<StatusDetail> element in conjunction with the
ok status value.
urn:oasis:names:tc:xacml:1.0:status:missing-attributeA PDP MAY choose not to return any
<StatusDetail> information or MAY choose to return a
<StatusDetail> element containing one or more
<MissingAttributeDetail> elements.
urn:oasis:names:tc:xacml:1.0:status:syntax-errorA PDP MUST NOT return a
<StatusDetail> element in conjunction with the
syntax-error status value. A syntax error may represent
either a problem with the policy being used or
with the request context. The
PDP MAY return a
<StatusMessage> describing the problem.
urn:oasis:names:tc:xacml:1.0:status:processing-errorA PDP MUST NOT return
<StatusDetail> element in conjunction with the
processing-error status value. This status code indicates
an internal problem in the PDP. For security
reasons, the PDP MAY choose to return no
further information to the PEP. In the case of
a divide-by-zero error or other computational error, the
PDP MAY return a
<StatusMessage> describing the nature of the
error.
The <MissingAttributeDetail> element conveys
information about attributes required for
policy evaluation that were missing from the
request context.
<xs:element name="MissingAttributeDetail" type="xacml:MissingAttributeDetailType"/>
<xs:complexType name="MissingAttributeDetailType">
<xs:sequence>
<xs:element ref="xacml:AttributeValue" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="Category" type="xacml:IdentifierType" use="required"/>
<xs:attribute name="AttributeId" type="xacml:IdentifierType" use="required"/>
<xs:attribute name="DataType" type="xacml:IdentifierType" use="required"/>
<xs:attribute name="Issuer" type="xs:string" use="optional"/>
</xs:complexType>The <MissingAttributeDetail> element is of
MissingAttributeDetailType complex type.
The <MissingAttributeDetal> element contains the
following attributes and elements:
<AttributeValue> [Optional]The required value of the missing attribute.
Category [Required]The category identifier of the missing attribute.
AttributeId [Required]The identifier of the missing attribute.
DataType [Required]The data-type of the missing attribute.
Issuer [Optional]This attribute, if supplied, SHALL specify the required
Issuer of the missing
attribute.
If the PDP includes
<AttributeValue> elements in the
<MissingAttributeDetail> element, then this indicates
the acceptable values for that attribute. If
no <AttributeValue> elements are included, then this
indicates the names of attributes that the
PDP failed to resolve during its evaluation.
The list of attributes may be partial or
complete. There is no guarantee by the PDP
that supplying the missing values or
attributes will be sufficient to satisfy the
policy.
The XPath 2.0 specification leaves a number of aspects of behavior implementation defined. This section defines how XPath 2.0 SHALL behave when hosted in XACML.
https://www.w3.org/TR/2007/REC-xpath20-20070123/#id-impl-defined-items
defines the following items:
XACML leaves this implementation defined. It is RECOMMENDED that the latest version is used.
XACML leaves this implementation defined.
XACML defines the implicit time zone as UTC.
XACML leaves this implementation defined.
An XPath error causes an XACML Indeterminate value in the element
where the XPath error occurs. The StatusCode value SHALL be
urn:oasis:names:tc:xacml:1.0:status:processing-error.
Implementations MAY provide additional details about the error in the
response or by some other means.
XACML is based on XML 1.0.
XACML leaves this implementation defined. It is RECOMMENDED that users of XACML do not make use of the namespace axis.
XACML leaves this implementation defined.
https://www.w3.org/TR/2007/REC-xpath-datamodel-20070123/#implementation-defined
defines the following items:
It is RECOMMENDED that implementations of XACML do not define any additional types and it is RECOMMENDED that users of XACML do not make use of any additional types.
An XPath error causes an XACML Indeterminate value in the element
where the XPath error occurs. The StatusCode value SHALL be
urn:oasis:names:tc:xacml:1.0:status:processing-error.
Implementations MAY provide additional details about the error in the
response or by some other means.
https://www.w3.org/TR/2007/REC-xpath-functions-20070123/#impl-def
defines the following items:
XACML leaves this implementation defined.
xs:integer operations, implementations that support
limited-precision integer operations must either raise an error
[err:FOAR0002] or provide an implementation-defined mechanism that
allows users to choose between raising an error and returning a result
that is modulo the largest representable integer value.XACML leaves this implementation defined. If an implementation
chooses to raise an error, the StatusCode value SHALL be
urn:oasis:names:tc:xacml:1.0:status:processing-error.
Implementations MAY provide additional details about the error in the
response or by some other means.
xs:decimal values the number of digits of precision
returned by the numeric operators is implementation-defined.XACML leaves this implementation defined.
XACML leaves this implementation defined.
XACML leaves this implementation defined. It is RECOMMENDED that the latest version is used.
fn:normalize-unicode, conforming implementations
must support normalization form "NFC" and may support normalization
forms "NFD", "NFKC", "NFKD", "FULLY-NORMALIZED". They may also support
other normalization forms with implementation-defined semantics.XACML leaves this implementation defined.
XACML leaves this implementation defined.
XACML leaves this implementation defined, and it is RECOMMENDED that users of XACML do not expect greater limits and precision.
xs:decimal, when the
resulting value is not too large or too small but nevertheless has too
many decimal digits to be accurately represented, is
implementation-defined.XACML leaves this implementation defined.
fn:doc
are implementation-defined. Implementations may provide external
configuration options that allow any aspect of the processing to be
controlled by the user.XACML leaves this implementation defined.
fn:collection and
fn:doc are implementation-defined.XACML leaves this implementation defined.
This section specifies certain functional requirements that are not directly associated with the production or consumption of a particular XACML element.
Note that in each case an implementation is conformant as long as it produces the same result as is specified here, regardless of how and in what order the implementation behaves internally.
In Unicode, some equivalent characters can be represented by more than one different Unicode character sequence. See [CMF]. The process of converting Unicode strings into equivalent character sequences is called "normalization" [UAX15]. Some operations, such as string comparison, are sensitive to normalization. An operation is normalization-sensitive if its output(s) are different depending on the state of normalization of the input(s); if the output(s) are textual, they are deemed different only if they would remain different were they to be normalized.
For more information on normalization see [CM].
An XACML implementation MUST behave as if each normalization-sensitive operation normalizes input strings into Unicode Normalization Form C ("NFC"). An implementation MAY use some other form of internal processing (such as using a non-Unicode, "legacy" character encoding) as long as the externally visible results are identical to this specification.
The version of Unicode used by XACML is implementation defined. It is RECOMMENDED that the latest version is used. Also note security issues in Appendix B.3.
This section describes the requirements for the PEP.
An application functions in the role of the PEP if it guards access to a set of resources and asks the PDP for an authorization decision. The PEP MUST abide by the authorization decision as described in one of the following sub-sections
In any case any advice in the decision may be safely ignored by the PEP.
If the decision is Permit,
then the PEP SHALL permit
access. If
obligation notices
accompany the decision, then the
PEP SHALL permit
access only if it understands and it can and
will discharge those obligations.
If the decision is Deny, then
the PEP SHALL deny
access. If
obligation notices
accompany the decision, then the
PEP shall deny
access only if it understands, and it can and
will discharge those obligations.
If the decision is
Not Applicable, then the PEP's
behavior is undefined.
If the decision is
Indeterminate, then the PEP's
behavior is undefined.
If the decision is Permit,
then the PEP SHALL permit
access. If
obligation notices
accompany the decision, then the
PEP SHALL permit
access only if it understands and it can and
will discharge those obligations.
Note: other actions, e.g. consultation of additional PDPs, reformulation/resubmission of the decision request, etc., are not prohibited.
If the decision is Deny, then
the PEP SHALL deny
access. If
obligation notices
accompany the decision, then the
PEP shall deny
access only if it understands, and it can and
will discharge those obligations.
Note: other actions, e.g. consultation of additional PDPs, reformulation/resubmission of the decision request, etc., are not prohibited.
Various XACML artifacts are uniquely identified by URI [RFC2396]. This includes
attribute categories,
attributes, data types, functions,
notices, status codes, combining
algorithms and XPath versions. Values of the
IdentifierType simple type are used to refer to such
artifacts, possibly using short identifier
names, which are not themselves URIs. Therefore an
IdentifierType value containing short
identifier names must undergo evaluation to convert the
value to an absolute URI.
The value of a short identifier may also contain short identifier names. The expanded value of the short identifier is the value of the short identifier with any reference to another short identifier (including the curly brackets) replaced by the expanded value of the referenced short identifier (thus the expansion is applied recursively).
In the case where the IdentifierType value is already an
absolute URI then the result of evaluation is that URI.
In the case where the IdentifierType value is just a
short identifier name then the result of
evaluation is the expanded value of that short
identifier.
In the case where the IdentifierType value contains
curly brackets then the result of evaluation is the value with any
reference to a short identifier replaced by
the expanded value of the referenced short
identifier.
The end result of evaluation MUST be an absolute URI.
Given the following short identifier definitions:
<ShortIdentifier Name="xs" Value="https://www.w3.org/2001/XMLSchema#"/>
<ShortIdentifier Name="string" Value="{xs}string"/>these IdentifierType values are all equivalent and
evaluate to the URI of the string data type:
"https://www.w3.org/2001/XMLSchema#string"
"string"
"{string}"
"{xs}string"Attributes are represented in the request
context by the context
handler, regardless of whether or not they appeared in the
original decision request, and are referred to
in the policy by attribute designators and
attribute selectors. A named attribute is the
term used for the criteria that the specific attribute designators use
to refer to particular attributes in the
<Attributes> elements of the request
context.
<AttributeValue> elements MAY contain an instance
of a structured XML data-type, for example
<ds:KeyInfo>. XACML 4.0 supports several ways for
comparing the contents of such elements.
string-regexp-match, described
below. This requires that the element be given the data-type
https://www.w3.org/2001/XMLSchema#string. For example, a
structured data-type that is actually a ds:KeyInfo/KeyName
would appear in the context as: <AttributeValue DataType="https://www.w3.org/2001/XMLSchema#string">
<ds:KeyName>jhibbert-key</ds:KeyName>
</AttributeValue>In general, this method will not be adequate unless the structured data-type is quite simple.
The structured attribute MAY be made
available in the <Content> element of the appropriate
attribute category and an
<AttributeSelector> element MAY be used to select the
contents of a leaf sub-element of the structured data-type by means of
an XPath expression. That value MAY then be compared using one of the
supported XACML functions appropriate for its primitive data-type. This
method requires support by the PDP for the
optional XPath expressions feature.
The structured attribute MAY be made
available in the <Content> element of the appropriate
attribute category and an
<AttributeSelector> element MAY be used to select any
node in the structured data-type by means of an XPath expression. This
node MAY then be compared using one of the XPath-based functions
described in Appendix E.3.15.
This method requires support by the PDP for
the optional XPath expressions and XPath functions features.
XACML defines implicit collections of its data-types. XACML refers to a collection of values that are of a single data-type as a bag. Bags of data-types are needed because selections of nodes from an XML resource or XACML request context may return more than one value.
The <AttributeSelector> element uses an XPath
expression to specify the selection of data from free form XML. The
result of an XPath expression is termed a node-set, which contains all
the nodes from the XML content that match the
predicate in the XPath expression. Based on
the various indexing functions provided in the XPath specification, it
SHALL be implied that a resultant node-set is the collection of the
matching nodes. XACML also defines the
<AttributeDesignator> element to have the same
matching methodology for attributes in the
XACML request context.
The values in a bag are not ordered, and some of the values may be duplicates. There SHALL be no notion of a bag containing bags, or a bag containing values of differing types; i.e., a bag in XACML SHALL contain only values that are of the same data-type.
If a single <Attribute> element in a request
context contains multiple
<AttributeValue> child elements, then the
bag of values resulting from evaluation of the
<Attribute> element MUST be identical to the
bag of values that results from evaluating a
context in which each
<AttributeValue> element appears in a separate
<Attribute> element, each carrying identical
meta-data.
A named attribute includes specific
criteria with which to match attributes in the
context. An
attribute specifies a Category,
AttributeId and DataType, and a
named attribute also specifies the
Issuer. A named attribute SHALL
match an attribute if the values of their
respective Category, AttributeId,
DataType and optional Issuer attributes match.
The Category of the named
attribute MUST match, by identifier
equality, the Category of the corresponding
context attribute.
The AttributeId of the named
attribute MUST match, by identifier
equality, the AttributeId of the
corresponding context
attribute. The DataType of the
named attribute MUST match, by
identifier equality, the DataType
of the corresponding context
attribute. If Issuer is supplied
in the named attribute, then it MUST match,
using the
urn:oasis:names:tc:xacml:1.0:function:string-equal
function, the Issuer of the corresponding
context attribute.
If Issuer is not supplied in the named
attribute, then the matching of the
context attribute to
the named attribute SHALL be governed by
AttributeId and DataType alone, regardless of
the presence, absence, or actual value of Issuer in the
corresponding context
attribute. In the case of an attribute
selector, the matching of the attribute to the
named attribute SHALL be governed by the XPath
expression and DataType.
The PDP SHALL request the values of
attributes in the request
context from the context
handler. The context handler MAY
also add attributes to the request
context without the
PDP requesting them. The
PDP SHALL reference the attributes as if they
were in a physical request context document,
but the context handler is responsible for
obtaining and supplying the requested values by whatever means it deems
appropriate, including by retrieving them from one or more
Policy Information Points. The
context handler SHALL return the values of
attributes that match the attribute designator
or attribute selector and form them into a bag
of values with the specified data-type. If no
attributes from the request
context match, then the
attribute SHALL be considered missing. If the
attribute is missing, then
MustBePresent governs whether the attribute designator or
attribute selector returns an empty bag or an
Indeterminate result. If MustBePresent is
False (default value), then a missing
attribute SHALL result in an empty
bag. If MustBePresent is
True, then a missing attribute
SHALL result in Indeterminate. This
Indeterminate result SHALL be handled in accordance with
the specification of the encompassing expressions,
rules and policies.
If the result is Indeterminate, then the
AttributeId, DataType and Issuer
of the attribute MAY be listed in the
authorization decision as described in Section 7.17. However, a
PDP MAY choose not to return such information
for security reasons.
Regardless of any dynamic modifications of the request context during policy evaluation, the PDP SHALL behave as if each bag of attribute values is fully populated in the context before it is first tested, and is thereafter immutable during evaluation. That is, every subsequent test of that attribute shall use the same bag of values that was initially tested.
Standard environment attributes are listed in Appendix F.7. If a value for one of these attributes is supplied in the decision request, then the context handler SHALL use that value. Otherwise, the context handler SHALL supply a value. In the case of date and time attributes, the supplied value SHALL have the semantics of the "date and time that apply to the decision request".
<AttributeSelector> element will be evaluated
according to the following processing model.Note: It is not necessary for an implementation to actually follow these steps. It is only necessary to produce results identical to those that would be produced by following these steps.
If the attributes category given by the
Category attribute is not found or does not have a
<Content> child element, then the return value is
either Indeterminate or an empty
bag as determined by the
MustBePresent attribute; otherwise, construct an XML data
structure suitable for xpath processing from the
<Content> element in the
attributes category given by the Category
attribute. The data structure shall be constructed so that the document
node of this structure contains a single document element which
corresponds to the single child element of the
<Content> element. The constructed data structure
shall be equivalent to one that would result from parsing a stand-alone
XML document consisting of the contents of the
<Content> element (including any comment and
processing-instruction markup). Namespace declarations from the
<Content> element and its ancestor elements for
namespace prefixes that are "visibly utilized", as defined by [exc-c14n], within the contents MUST be present.
Namespace declarations from the <Content> element or
its ancestor elements for namespace prefixes that are not "visibly
utilized" MAY be present. The data structure must meet the requirements
of the applicable XPath version.
Select a context node for XPath processing from this data
structure. If there is a ContextSelectorId attribute, the
context node shall be the node selected by applying the XPath expression
given in the attribute value of the designated
attribute (in the
attributes category given by the
<AttributeSelector> Category attribute).
It shall be an error if this evaluation returns no node or more than one
node, in which case the return value MUST be an
Indeterminate with a status code
urn:oasis:names:tc:xacml:1.0:status:syntax-error. If there
is no ContextSelectorId, the document node of the data
structure shall be the context node.
Evaluate the XPath expression given in the Path
attribute against the xml data structure, using the context node
selected in the previous step. It shall be an error if this evaluation
returns anything other than a sequence of nodes (possibly empty), in
which case the <AttributeSelector> MUST return
Indeterminate with a status code
urn:oasis:names:tc:xacml:1.0:status:syntax-error. If the
evaluation returns an empty sequence of nodes, then the return value is
either Indeterminate or an empty
bag as determined by the
MustBePresent attribute.
If the data type is a primitive data type, convert the text value
of each selected node to the desired data type, as specified in the
DataType attribute. Each value shall be constructed using
the appropriate constructor function from [XF] Section
5 listed below, corresponding to the specified data type:
xs:string
xs:boolean
xs:integer()
xs:double()
xs:dateTime()
xs:date()
xs:time()
xs:hexBinary()
xs:base64Binary()
xs:anyURI()
xs:yearMonthDuration()
xs:dayTimeDuration()
DataType is not one of the primitive types listed
above, then the return values shall be constructed from the nodeset in a
manner specified by the particular DataType extension
specification. If the data type extension does not specify an
appropriate contructor function, then the
<AttributeSelector> MUST return
Indeterminate with a status code
urn:oasis:names:tc:xacml:1.0:status:syntax-error.
DataType, then the result of
the <AttributeSelector> MUST be
Indeterminate, with a status code
urn:oasis:names:tc:xacml:1.0:status:processing-error
XACML specifies expressions in terms of the elements listed below, of
which the <Apply> and <Condition>
elements recursively compose greater expressions. Valid expressions
SHALL be type correct, which means that the types of each of the
elements contained within <Apply> elements SHALL
agree with the respective argument types of the function that is named
by the FunctionId attribute. The resultant type of the
<Apply> element SHALL be the resultant type of the
function, which MAY be narrowed to a primitive data-type, or a
bag of a primitive data-type, by
type-unification. XACML defines an evaluation result of
Indeterminate, which is said to be the result of an invalid
expression, or an operational error occurring during the evaluation of
the expression.
XACML defines these elements to be in the substitution group of the
<Expression> element:
<xacml:AttributeValue><xacml:AttributeDesignator><xacml:AttributeSelector><xacml:Apply><xacml:Function><xacml:VariableReference>flags - all set to 0
trap-enablers - all set to 0 (IEEE 854 §7) with the exception of the "division-by-zero" trap enabler, which SHALL be set to 1
precision - is set to the designated double precision
rounding - is set to round-half-even (IEEE 854 §4.1)
The target value SHALL be
Match if the <Target> element is absent
or the expression specified in the target
evaluates to True. Otherwise, if the expression evaluates
to False, then the target SHALL
be No Match. Otherwise, the
target SHALL be Indeterminate.
The target match table is shown in Table
1.
| Expression value | Target value |
|---|---|
True |
Match |
False |
No Match |
Indeterminate |
Indeterminate |
The <VariableReference> element references a
single <VariableDefinition> element contained within
the same <Policy> element. A
<VariableReference> that does not reference a
particular <VariableDefinition> element within the
encompassing <Policy> element is called an undefined
reference. Policies with undefined references
are invalid.
In any place where a <VariableReference> occurs,
it has the effect as if the text of the <Expression>
element defined in the <VariableDefinition> element
replaces the <VariableReference> element. Any
evaluation scheme that preserves this semantic is acceptable. For
instance, the expression in the <VariableDefinition>
element may be evaluated to a particular value and cached for multiple
references without consequence. (I.e. the value of an
<Expression> element remains the same for the entire
policy evaluation.) This characteristic is one
of the benefits of XACML being a declarative language.
A variable reference containing circular references is invalid. The
PDP MUST detect circular references either at policy loading time or
during runtime evaluation. If the PDP detects a circular reference
during runtime the variable reference evaluates to
Indeterminate with status code
urn:oasis:names:tc:xacml:1.0:status:processing-error.
The condition value SHALL be
True if the <Condition> element is
absent, or if the expression contained in the
<Condition> element evaluates to True.
Its value SHALL be False if the expression evaluates to
False. The condition value SHALL
be Indeterminate, if the expression evaluates to
Indeterminate.
Some combining algorithms are defined in
terms of an extended set of Indeterminate values. The
extended set associated with the Indeterminate contains the
potential effect values which could have occurred if there would not
have been an error causing the Indeterminate. The possible
extended set Indeterminate values are
Indeterminate{D}: an Indeterminate from
a policy or rule
which could have evaluated to Deny, but not
Permit
Indeterminate{P}: an Indeterminate from
a policy or rule
which could have evaluated to Permit, but not
Deny
Indeterminate{DP}: an Indeterminate
from a policy or
rule which could have evaluated to
Deny or Permit.
The combining algorithms which are defined
in terms of the extended Indeterminate make use of the
additional information to allow for better treatment of errors in the
algorithms.
The final decision returned by a PDP cannot
be an extended Indeterminate. Any such decision at the top
level policy is returned as a plain
Indeterminate in the response from the
PDP.
The tables in the following four sections define how extended
Indeterminate values are produced during
rule and policy
evaluation.
A rule has a value that can be calculated by evaluating the rule's condition. The rule truth table is shown in Table 4.
| Condition | Rule Value |
|---|---|
True |
Effect |
False |
NotApplicable |
Indeterminate |
Indeterminate{P} if the
Effect is Permit, or
Indeterminate{D} if the Effect is
Deny |
The value of a policy SHALL be determined only by its contents, considered in relation to the contents of the request context. A policy's value SHALL be determined by evaluation of the policy's target and evaluation of the specified combining algorithm on the contained policies and rules.
The policy truth table is shown in Table 5.
| Target | Combining Algorithm Value | Policy Value |
|---|---|---|
Match |
NotApplicable |
NotApplicable |
Match |
Permit |
Permit |
Match |
Deny |
Deny |
Match |
Indeterminate |
Indeterminate{DP} |
Match |
Indeterminate{DP} |
Indeterminate{DP} |
Match |
Indeterminate{P} |
Indeterminate{P} |
Match |
Indeterminate{D} |
Indeterminate{D} |
No-match |
Don't care | NotApplicable |
Indeterminate |
NotApplicable |
NotApplicable |
Indeterminate |
Permit |
Indeterminate{P} |
Indeterminate |
Deny |
Indeterminate{D} |
Indeterminate |
Indeterminate |
Indeterminate{DP} |
Indeterminate |
Indeterminate{DP} |
Indeterminate{DP} |
Indeterminate |
Indeterminate{P} |
Indeterminate{P} |
Indeterminate |
Indeterminate{D} |
Indeterminate{D} |
Note that none of the combining algorithms defined by XACML 4.0 take parameters. However, non-standard combining algorithms MAY take parameters. In such a case, the values of these parameters associated with the policies and rules, MUST be taken into account when evaluating the policy. The parameters and their types should be defined in the specification of the combining algorithm. If the implementation supports combiner parameters and if combiner parameters are present in a policy, then the parameter values MUST be supplied to the combining algorithm implementation.
A policy reference is evaluated by resolving the reference and evaluating the referenced policy.
If resolving the reference fails, the reference evaluates to
Indeterminate with status code:
urn:oasis:names:tc:xacml:1.0:status:processing-error.
A policy id reference containing circular
references is invalid. The PDP MUST detect circular references either at
policy loading time or during runtime
evaluation. If the PDP detects a circular reference during runtime the
reference evaluates to Indeterminate with status code
urn:oasis:names:tc:xacml:1.0:status:processing-error.
It is often the case that a resource is organized as a hierarchy (e.g. file system, XML document). XACML provides several optional mechanisms for supporting hierarchical resources. These are described in the XACML Profile for Hierarchical Resources [Hier] and in the XACML Profile for Requests for Multiple Resources [Multi].
In relation to a particular decision request, the PDP is defined by a combining algorithm and a set of rules and/or policies. The PDP SHALL return a response context as if it had evaluated a single policy consisting of this combining algorithm and the set of rules and/or policies.
The PDP MUST evaluate the
policy as specified in Section
5 and Section 7. The
PDP MUST return a response
context, with one
<Decision> element of value Permit,
Deny, Indeterminate or
NotApplicable.
If the PDP cannot make a
decision, then an Indeterminate
<Decision> element SHALL be returned.
A rule or policy
may contain one or more notice expressions.
When such a rule or
policy is evaluated, the
notice expression SHALL be evaluated to a
notice, which SHALL be passed up to the next
level of evaluation (the enclosing or referencing
policy or authorization
decision) only if the result of the
rule or policy being
evaluated matches the value of the AppliesTo attribute of
the notice (or matches either
Permit or Deny if the AppliesTo
attribute is absent) and the notice expression
does not have a condition or it has a
condition that evaluates to True.
If the condition in a
notice expression with a matching
AppliesTo attribute evaluates to
Indeterminate, then the whole
rule or policy SHALL
be Indeterminate. If the
condition is absent or evaluates to
True and any of the attribute
assignment expressions in the notice
expression evaluates to Indeterminate, then the whole
rule or policy SHALL
be Indeterminate. If the AppliesTo attribute
is present and does not match the result of the combining
algorithm or the rule
evaluation, then any Indeterminate evaluation in a
notice expression has no effect.
As a consequence of this procedure, notices
SHALL NOT be returned to the PEP if the
rules or policies
from which they are drawn are not evaluated, or if their evaluated
result is Indeterminate or NotApplicable, or
if the decision resulting from evaluating the
rule or policy does
not match the decision resulting from
evaluating an enclosing policy, or if the
notice expression has a
condition that evaluates to
False.
If the PDP's evaluation is viewed as a tree
of rules and
policies, each of which returns
Permit or Deny, then the collection of
notices returned by the
PDP to the PEP will
include only the notices associated with those
paths where the result at each level of evaluation is the same as the
result being returned by the PDP. In
situations where any lack of determinism is unacceptable, a
deterministic combining algorithm, such as
ordered-deny-overrides, should be used.
Also see Section 7.2.
XACML specifies behavior for the PDP in the following situations.
If the PDP attempts to evaluate a
policy that contains an optional element type
or function that the PDP does not support,
then the PDP SHALL return a
<Decision> value of Indeterminate. If a
<StatusCode> element is also returned, then its value
SHALL be urn:oasis:names:tc:xacml:1.0:status:syntax-error
in the case of an unsupported element type, and
urn:oasis:names:tc:xacml:1.0:status:processing-error in the
case of an unsupported function.
If a policy that contains invalid syntax is
evaluated by the XACML PDP at the time a
decision request is received, then the result
of that policy SHALL be
Indeterminate with a StatusCode value of
urn:oasis:names:tc:xacml:1.0:status:syntax-error.
If a policy that contains invalid static
data-types is evaluated by the XACML PDP at
the time a decision request is received, then
the result of that policy SHALL be
Indeterminate with a StatusCode value of
urn:oasis:names:tc:xacml:1.0:status:processing-error.
The absence of matching attributes in the
request context for any of the attribute
designators attribute or selectors that are found in the
policy will result in an enclosing
<AllOf> element to return a value of
Indeterminate,if the designator or selector has the
MustBePresent XML attribute set to true, as described in Section 5.29 and Section 5.30 and may result in
a <Decision> element containing the
Indeterminate value. If, in this case a status code is
supplied, then the value
urn:oasis:names:tc:xacml:1.0:status:missing-attribute
SHALL be used, to indicate that more information is needed in order
for a definitive decision to be rendered. In
this case, the <Status> element MAY list the names
and data-types of any attributes that are
needed by the PDP to refine its
decision (see Section 5.58). A
PEP MAY resubmit a refined request
context in response to a
<Decision> element contents of
Indeterminate with a status code of
urn:oasis:names:tc:xacml:1.0:status:missing-attribute
by adding attribute values for the
attribute names that were listed in the
previous response. When the PDP returns a
<Decision> element contents of
Indeterminate, with a status code of
urn:oasis:names:tc:xacml:1.0:status:missing-attribute,
it MUST NOT list the names and data-types of any
attribute for which values were supplied in
the original request. Note, this requirement forces the
PDP to eventually return an
authorization decision of Permit,
Deny, or Indeterminate with some other status
code, in response to successively-refined requests.
XACML makes use of URIs and strings as identifiers. When such identifiers are compared for equality, the comparison MUST be done so that the identifiers are equal if they have the same length and the characters in the two identifiers are equal codepoint by codepoint.
Values of the IdentifierType simple type may use
short identifiers as aliases for URIs. Where
it is necessary to determine identifier
equality, values of the IdentifierType simple
type MUST first be evaluated according to Section 7.3 and then the comparison
SHALL be performed using the resulting URI. This applies to all
instances of IdentifierType.
This definition of equality MUST also be used by the following URI
identifiers (that are not instances of IdentifierType):
the XML attribute PolicyId in the element
<Policy>,
the XML attribute PolicyIdRef in the element
<PolicyCombinerParameters> and
the XML attribute Id in the complex type
IdReferenceType.
The following is a list of the string identifiers that MUST use this definition of equality:
the XML attribute Issuer in the element
<AttributeDesignator>,
the XML attribute Issuer in the element
<MissingAttributeDetail>,
the XML attribute Issuer in the element
<Attribute>,
the XML attribute Issuer in the element
<AttributeAssignmentExpression>,
the XML attribute ParameterName in the element
<CombinerParameter>,
the XML attribute RuleId in the element
<Rule>,
the XML attribute RuleIdRef in the element
<RuleCombinerParameters>,
the XML attribute VariableId in the element
<VariableDefinition> and
the XML attribute VariableId in the element
<VariableReference>.
It is RECOMMENDED that extensions to XACML use the same definition of identifier equality for similar identifiers.
It is RECOMMENDED that extensions which define identifiers do not define identifiers which could be easily misinterpreted by people as being subject to other kind of processing, such as URL character escaping, before matching.
The <Response> element may contain references to
short identifier collections, and
short identifiers from those collections may
be used within the response. The PDP can freely choose what
short identifier collections it uses in the
response, if any. There are two cases that require special care.
Attributes in the request that have the
IncludeInResult XML attribute set to true are duplicated in
the response. If those attributes contain
short identifiers then those short
identifiers are interpreted with respect to the
short identifier collections referenced by the
request, which may be different from the short
identifier collections chosen by the PDP for the
response.
Notices in the response originate from notice expressions in policies. If those notice expressions contain short identifiers then those short identifiers are interpreted with respect to the short identifier collections referenced by the policies, which may also be different from the short identifier collections chosen by the PDP for the response.
The PDP is responsible for ensuring that any short
identifiers in the response reflect the correct URI when
they are evaluated according to Section 7.3 in the presence of the
short identifier collections it has chosen. An
implementation strategy for achieving this is for the PDP and context
handler to evaluate any values of the IdentifierType simple
type as they are encountered and store them in internal memory as
absolute URIs. Then when the response is composed the absolute URIs can
be replaced by appropriate short identifiers
from the short identifier collections chosen
by the PDP.
If the PDP chooses the same short identifier collections referenced by the request then it has the advantage that they are collections known by the PEP and any attributes included in the result are more likely to have their original short identifiers restored.
This section describes the points within the XACML model and schema where extensions can be added.
The following XML attributes have values that are URIs. These may be
extended by the creation of new URIs associated with new semantics for
these attributes.
Category,
AttributeId,
DataType,
FunctionId,
Id (<Notice> and
<NoticeExpression>),
CombiningAlgId,
StatusCode.
See Section 5 for definitions of these attribute types.
<AttributeValue> elements MAY contain an instance
of a structured XML data-type. Section 7.4.1 describes a number
of standard techniques to identify data items within such a structured
attribute. Listed here are some additional
techniques that require XACML extensions.
For a given structured data-type, a community of XACML users MAY
define new attribute identifiers for each leaf
sub-element of the structured data-type that has a type conformant with
one of the XACML-defined primitive data-types. Using these new
attribute identifiers, the
PEPs or context
handlers used by that community of users can flatten
instances of the structured data-type into a sequence of individual
<Attribute> elements. Each such
<Attribute> element can be compared using the
XACML-defined functions. Using this method, the structured data-type
itself never appears in an <AttributeValue>
element.
A community of XACML users MAY define a new function that can be used to compare a value of the structured data-type against some other value. This method may only be used by PDPs that support the new function.
The XACML specification addresses the following aspect of conformance:
The XACML specification defines a number of functions, etc. that have somewhat special applications, therefore they are not required to be implemented in an implementation that claims to conform with the OASIS standard.
Note: "M" means mandatory-to-implement. "O" means optional.
The implementation MUST follow Section 5, Section 6, Section 7, Appendix E, Appendix F and Appendix G where they apply to implemented items in the following tables.
The implementation MUST support those schema elements that are marked
M.
| Element name | M/O |
|---|---|
| xacml:Apply | M |
| xacml:Attribute | M |
| xacml:AttributeAssignment | M |
| xacml:AttributeAssignmentExpression | M |
| xacml:AttributeDesignator | M |
| xacml:Attributes | M |
| xacml:AttributeSelector | O |
| xacml:AttributesReference | O |
| xacml:AttributeValue | M |
| xacml:CombinerParameter | O |
| xacml:CombinerParameters | O |
| xacml:Condition | M |
| xacml:Content | O |
| xacml:Decision | M |
| xacml:Description | M |
| xacml:Expression | M |
| xacml:Function | M |
| xacml:MissingAttributeDetail | M |
| xacml:MultiRequests | O |
| xacml:Notice | M |
| xacml:NoticeExpression | M |
| xacml:Policy | M |
| xacml:PolicyCombinerParameters | O |
| xacml:PolicyDefaults | O |
| xacml:PolicyIdentifierList | O |
| xacml:PolicyReference | M |
| xacml:PolicyIssuer | O |
| xacml:Request | M |
| xacml:RequestDefaults | O |
| xacml:RequestReference | O |
| xacml:Response | M |
| xacml:Result | M |
| xacml:Rule | M |
| xacml:RuleCombinerParameters | O |
| xacml:Status | M |
| xacml:StatusCode | M |
| xacml:StatusDetail | O |
| xacml:StatusMessage | O |
| xacml:Target | M |
| xacml:VariableDefinition | M |
| xacml:VariableReference | M |
| xacml:XPathVersion | O |
The following identifier prefixes are reserved by XACML.
| Element name |
|---|
| urn:oasis:names:tc:xacml:4.0 |
| urn:oasis:names:tc:xacml:3.0 |
| urn:oasis:names:tc:xacml:2.0 |
| urn:oasis:names:tc:xacml:2.0:conformance-test |
| urn:oasis:names:tc:xacml:2.0:context |
| urn:oasis:names:tc:xacml:2.0:example |
| urn:oasis:names:tc:xacml:1.0:function |
| urn:oasis:names:tc:xacml:2.0:function |
| urn:oasis:names:tc:xacml:2.0:policy |
| urn:oasis:names:tc:xacml:1.0:subject |
| urn:oasis:names:tc:xacml:1.0:resource |
| urn:oasis:names:tc:xacml:1.0:action |
| urn:oasis:names:tc:xacml:1.0:environment |
| urn:oasis:names:tc:xacml:1.0:status |
The implementation MUST include the combining
algorithms associated with the following identifiers that
are marked M
| Algorithm | M/O |
|---|---|
| urn:oasis:names:tc:xacml:4.0:combining-algorithm:deny-overrides | M |
| urn:oasis:names:tc:xacml:4.0:combining-algorithm:permit-overrides | M |
| urn:oasis:names:tc:xacml:4.0:combining-algorithm:first-applicable | M |
| urn:oasis:names:tc:xacml:4.0:combining-algorithm:ordered-deny-overrides | M |
| urn:oasis:names:tc:xacml:4.0:combining-algorithm:ordered-permit-overrides | M |
| urn:oasis:names:tc:xacml:4.0:combining-algorithm:deny-unless-permit | M |
| urn:oasis:names:tc:xacml:4.0:combining-algorithm:permit-unless-deny | M |
Implementation support for the <StatusCode>
element is optional, but if the element is supported, then the following
status codes must be supported and must be used in the way XACML has
specified.
| Identifier | M/O |
|---|---|
| urn:oasis:names:tc:xacml:1.0:status:missing-attribute | M |
| urn:oasis:names:tc:xacml:1.0:status:ok | M |
| urn:oasis:names:tc:xacml:1.0:status:processing-error | M |
| urn:oasis:names:tc:xacml:1.0:status:syntax-error | M |
The implementation MUST support the attributes associated with the following identifiers as specified by XACML. If values for these attributes are not present in the decision request, then their values MUST be supplied by the context handler. So, unlike most other attributes, their semantics are not transparent to the PDP.
| Identifier | M/O |
|---|---|
| urn:oasis:names:tc:xacml:1.0:environment:current-time | M |
| urn:oasis:names:tc:xacml:1.0:environment:current-date | M |
| urn:oasis:names:tc:xacml:1.0:environment:current-dateTime | M |
The implementation MUST use the attributes associated with the following identifiers in the way XACML has defined. This requirement pertains primarily to implementations of a PAP or PEP that uses XACML, since the semantics of the attributes are transparent to the PDP.
| Identifier | M/O |
|---|---|
| urn:oasis:names:tc:xacml:1.0:subject:authn-locality:dns-name | O |
| urn:oasis:names:tc:xacml:1.0:subject:authn-locality:ip-address | O |
| urn:oasis:names:tc:xacml:1.0:subject:authentication-method | O |
| urn:oasis:names:tc:xacml:1.0:subject:authentication-time | O |
| urn:oasis:names:tc:xacml:1.0:subject:key-info | O |
| urn:oasis:names:tc:xacml:1.0:subject:request-time | O |
| urn:oasis:names:tc:xacml:1.0:subject:session-start-time | O |
| urn:oasis:names:tc:xacml:1.0:subject:subject-id | O |
| urn:oasis:names:tc:xacml:1.0:subject:subject-id-qualifier | O |
| urn:oasis:names:tc:xacml:1.0:subject-category:access-subject | M |
| urn:oasis:names:tc:xacml:1.0:subject-category:codebase | O |
| urn:oasis:names:tc:xacml:1.0:subject-category:intermediary-subject | O |
| urn:oasis:names:tc:xacml:1.0:subject-category:recipient-subject | O |
| urn:oasis:names:tc:xacml:1.0:subject-category:requesting-machine | O |
| urn:oasis:names:tc:xacml:1.0:resource:resource-location | O |
| urn:oasis:names:tc:xacml:1.0:resource:resource-id | M |
| urn:oasis:names:tc:xacml:1.0:resource:simple-file-name | O |
| urn:oasis:names:tc:xacml:2.0:resource:target-namespace | O |
| urn:oasis:names:tc:xacml:1.0:action:action-id | O |
| urn:oasis:names:tc:xacml:1.0:action:action-namespace | O |
| urn:oasis:names:tc:xacml:1.0:action:implied-action | O |
The implementation MUST support the data-types associated with the
following identifiers marked M.
| Data-type | M/O |
|---|---|
| https://www.w3.org/2001/XMLSchema#string | M |
| https://www.w3.org/2001/XMLSchema#boolean | M |
| https://www.w3.org/2001/XMLSchema#integer | M |
| https://www.w3.org/2001/XMLSchema#double | M |
| https://www.w3.org/2001/XMLSchema#time | M |
| https://www.w3.org/2001/XMLSchema#date | M |
| https://www.w3.org/2001/XMLSchema#dateTime | M |
| https://www.w3.org/2001/XMLSchema#dayTimeDuration | M |
| https://www.w3.org/2001/XMLSchema#yearMonthDuration | M |
| https://www.w3.org/2001/XMLSchema#anyURI | M |
| https://www.w3.org/2001/XMLSchema#hexBinary | M |
| https://www.w3.org/2001/XMLSchema#base64Binary | M |
| urn:oasis:names:tc:xacml:1.0:data-type:rfc822Name | M |
| urn:oasis:names:tc:xacml:1.0:data-type:x500Name | M |
| urn:oasis:names:tc:xacml:3.0:data-type:xpathExpression | O |
| urn:oasis:names:tc:xacml:2.0:data-type:ipAddress | M |
| urn:oasis:names:tc:xacml:2.0:data-type:dnsName | M |
The implementation MUST properly process those functions associated
with the identifiers marked with an M.
| Function | M/O |
|---|---|
| urn:oasis:names:tc:xacml:1.0:function:string-equal | M |
| urn:oasis:names:tc:xacml:1.0:function:boolean-equal | M |
| urn:oasis:names:tc:xacml:1.0:function:integer-equal | M |
| urn:oasis:names:tc:xacml:1.0:function:double-equal | M |
| urn:oasis:names:tc:xacml:1.0:function:date-equal | M |
| urn:oasis:names:tc:xacml:1.0:function:time-equal | M |
| urn:oasis:names:tc:xacml:1.0:function:dateTime-equal | M |
| urn:oasis:names:tc:xacml:3.0:function:dayTimeDuration-equal | M |
| urn:oasis:names:tc:xacml:3.0:function:yearMonthDuration-equal | M |
| urn:oasis:names:tc:xacml:3.0:function:string-equal-ignore-case | M |
| urn:oasis:names:tc:xacml:1.0:function:anyURI-equal | M |
| urn:oasis:names:tc:xacml:1.0:function:x500Name-equal | M |
| urn:oasis:names:tc:xacml:1.0:function:rfc822Name-equal | M |
| urn:oasis:names:tc:xacml:1.0:function:hexBinary-equal | M |
| urn:oasis:names:tc:xacml:1.0:function:base64Binary-equal | M |
| urn:oasis:names:tc:xacml:1.0:function:integer-add | M |
| urn:oasis:names:tc:xacml:1.0:function:double-add | M |
| urn:oasis:names:tc:xacml:1.0:function:integer-subtract | M |
| urn:oasis:names:tc:xacml:1.0:function:double-subtract | M |
| urn:oasis:names:tc:xacml:1.0:function:integer-multiply | M |
| urn:oasis:names:tc:xacml:1.0:function:double-multiply | M |
| urn:oasis:names:tc:xacml:1.0:function:integer-divide | M |
| urn:oasis:names:tc:xacml:1.0:function:double-divide | M |
| urn:oasis:names:tc:xacml:1.0:function:integer-mod | M |
| urn:oasis:names:tc:xacml:1.0:function:integer-abs | M |
| urn:oasis:names:tc:xacml:1.0:function:double-abs | M |
| urn:oasis:names:tc:xacml:1.0:function:round | M |
| urn:oasis:names:tc:xacml:1.0:function:floor | M |
| urn:oasis:names:tc:xacml:1.0:function:string-normalize-space | M |
| urn:oasis:names:tc:xacml:1.0:function:string-normalize-to-lower-case | M |
| urn:oasis:names:tc:xacml:1.0:function:double-to-integer | M |
| urn:oasis:names:tc:xacml:1.0:function:integer-to-double | M |
| urn:oasis:names:tc:xacml:1.0:function:or | M |
| urn:oasis:names:tc:xacml:1.0:function:and | M |
| urn:oasis:names:tc:xacml:1.0:function:n-of | M |
| urn:oasis:names:tc:xacml:1.0:function:not | M |
| urn:oasis:names:tc:xacml:1.0:function:integer-greater-than | M |
| urn:oasis:names:tc:xacml:1.0:function:integer-greater-than-or-equal | M |
| urn:oasis:names:tc:xacml:1.0:function:integer-less-than | M |
| urn:oasis:names:tc:xacml:1.0:function:integer-less-than-or-equal | M |
| urn:oasis:names:tc:xacml:1.0:function:double-greater-than | M |
| urn:oasis:names:tc:xacml:1.0:function:double-greater-than-or-equal | M |
| urn:oasis:names:tc:xacml:1.0:function:double-less-than | M |
| urn:oasis:names:tc:xacml:1.0:function:double-less-than-or-equal | M |
| urn:oasis:names:tc:xacml:3.0:function:dateTime-add-dayTimeDuration | M |
| urn:oasis:names:tc:xacml:3.0:function:dateTime-add-yearMonthDuration | M |
| urn:oasis:names:tc:xacml:3.0:function:dateTime-subtract-dayTimeDuration | M |
| urn:oasis:names:tc:xacml:3.0:function:dateTime-subtract-yearMonthDuration | M |
| urn:oasis:names:tc:xacml:3.0:function:date-add-yearMonthDuration | M |
| urn:oasis:names:tc:xacml:3.0:function:date-subtract-yearMonthDuration | M |
| urn:oasis:names:tc:xacml:1.0:function:string-greater-than | M |
| urn:oasis:names:tc:xacml:1.0:function:string-greater-than-or-equal | M |
| urn:oasis:names:tc:xacml:1.0:function:string-less-than | M |
| urn:oasis:names:tc:xacml:1.0:function:string-less-than-or-equal | M |
| urn:oasis:names:tc:xacml:1.0:function:time-greater-than | M |
| urn:oasis:names:tc:xacml:1.0:function:time-greater-than-or-equal | M |
| urn:oasis:names:tc:xacml:1.0:function:time-less-than | M |
| urn:oasis:names:tc:xacml:1.0:function:time-less-than-or-equal | M |
| urn:oasis:names:tc:xacml:2.0:function:time-in-range | M |
| urn:oasis:names:tc:xacml:1.0:function:dateTime-greater-than | M |
| urn:oasis:names:tc:xacml:1.0:function:dateTime-greater-than-or-equal | M |
| urn:oasis:names:tc:xacml:1.0:function:dateTime-less-than | M |
| urn:oasis:names:tc:xacml:1.0:function:dateTime-less-than-or-equal | M |
| urn:oasis:names:tc:xacml:1.0:function:date-greater-than | M |
| urn:oasis:names:tc:xacml:1.0:function:date-greater-than-or-equal | M |
| urn:oasis:names:tc:xacml:1.0:function:date-less-than | M |
| urn:oasis:names:tc:xacml:1.0:function:date-less-than-or-equal | M |
| urn:oasis:names:tc:xacml:1.0:function:string-one-and-only | M |
| urn:oasis:names:tc:xacml:1.0:function:string-bag-size | M |
| urn:oasis:names:tc:xacml:1.0:function:string-is-in | M |
| urn:oasis:names:tc:xacml:1.0:function:string-bag | M |
| urn:oasis:names:tc:xacml:1.0:function:boolean-one-and-only | M |
| urn:oasis:names:tc:xacml:1.0:function:boolean-bag-size | M |
| urn:oasis:names:tc:xacml:1.0:function:boolean-is-in | M |
| urn:oasis:names:tc:xacml:1.0:function:boolean-bag | M |
| urn:oasis:names:tc:xacml:1.0:function:integer-one-and-only | M |
| urn:oasis:names:tc:xacml:1.0:function:integer-bag-size | M |
| urn:oasis:names:tc:xacml:1.0:function:integer-is-in | M |
| urn:oasis:names:tc:xacml:1.0:function:integer-bag | M |
| urn:oasis:names:tc:xacml:1.0:function:double-one-and-only | M |
| urn:oasis:names:tc:xacml:1.0:function:double-bag-size | M |
| urn:oasis:names:tc:xacml:1.0:function:double-is-in | M |
| urn:oasis:names:tc:xacml:1.0:function:double-bag | M |
| urn:oasis:names:tc:xacml:1.0:function:time-one-and-only | M |
| urn:oasis:names:tc:xacml:1.0:function:time-bag-size | M |
| urn:oasis:names:tc:xacml:1.0:function:time-is-in | M |
| urn:oasis:names:tc:xacml:1.0:function:time-bag | M |
| urn:oasis:names:tc:xacml:1.0:function:date-one-and-only | M |
| urn:oasis:names:tc:xacml:1.0:function:date-bag-size | M |
| urn:oasis:names:tc:xacml:1.0:function:date-is-in | M |
| urn:oasis:names:tc:xacml:1.0:function:date-bag | M |
| urn:oasis:names:tc:xacml:1.0:function:dateTime-one-and-only | M |
| urn:oasis:names:tc:xacml:1.0:function:dateTime-bag-size | M |
| urn:oasis:names:tc:xacml:1.0:function:dateTime-is-in | M |
| urn:oasis:names:tc:xacml:1.0:function:dateTime-bag | M |
| urn:oasis:names:tc:xacml:1.0:function:anyURI-one-and-only | M |
| urn:oasis:names:tc:xacml:1.0:function:anyURI-bag-size | M |
| urn:oasis:names:tc:xacml:1.0:function:anyURI-is-in | M |
| urn:oasis:names:tc:xacml:1.0:function:anyURI-bag | M |
| urn:oasis:names:tc:xacml:1.0:function:hexBinary-one-and-only | M |
| urn:oasis:names:tc:xacml:1.0:function:hexBinary-bag-size | M |
| urn:oasis:names:tc:xacml:1.0:function:hexBinary-is-in | M |
| urn:oasis:names:tc:xacml:1.0:function:hexBinary-bag | M |
| urn:oasis:names:tc:xacml:1.0:function:base64Binary-one-and-only | M |
| urn:oasis:names:tc:xacml:1.0:function:base64Binary-bag-size | M |
| urn:oasis:names:tc:xacml:1.0:function:base64Binary-is-in | M |
| urn:oasis:names:tc:xacml:1.0:function:base64Binary-bag | M |
| urn:oasis:names:tc:xacml:3.0:function:dayTimeDuration-one-and-only | M |
| urn:oasis:names:tc:xacml:3.0:function:dayTimeDuration-bag-size | M |
| urn:oasis:names:tc:xacml:3.0:function:dayTimeDuration-is-in | M |
| urn:oasis:names:tc:xacml:3.0:function:dayTimeDuration-bag | M |
| urn:oasis:names:tc:xacml:3.0:function:yearMonthDuration-one-and-only | M |
| urn:oasis:names:tc:xacml:3.0:function:yearMonthDuration-bag-size | M |
| urn:oasis:names:tc:xacml:3.0:function:yearMonthDuration-is-in | M |
| urn:oasis:names:tc:xacml:3.0:function:yearMonthDuration-bag | M |
| urn:oasis:names:tc:xacml:1.0:function:x500Name-one-and-only | M |
| urn:oasis:names:tc:xacml:1.0:function:x500Name-bag-size | M |
| urn:oasis:names:tc:xacml:1.0:function:x500Name-is-in | M |
| urn:oasis:names:tc:xacml:1.0:function:x500Name-bag | M |
| urn:oasis:names:tc:xacml:1.0:function:rfc822Name-one-and-only | M |
| urn:oasis:names:tc:xacml:1.0:function:rfc822Name-bag-size | M |
| urn:oasis:names:tc:xacml:1.0:function:rfc822Name-is-in | M |
| urn:oasis:names:tc:xacml:1.0:function:rfc822Name-bag | M |
| urn:oasis:names:tc:xacml:2.0:function:ipAddress-one-and-only | M |
| urn:oasis:names:tc:xacml:2.0:function:ipAddress-bag-size | M |
| urn:oasis:names:tc:xacml:2.0:function:ipAddress-bag | M |
| urn:oasis:names:tc:xacml:2.0:function:dnsName-one-and-only | M |
| urn:oasis:names:tc:xacml:2.0:function:dnsName-bag-size | M |
| urn:oasis:names:tc:xacml:2.0:function:dnsName-bag | M |
| urn:oasis:names:tc:xacml:2.0:function:string-concatenate | M |
| urn:oasis:names:tc:xacml:3.0:function:boolean-from-string | M |
| urn:oasis:names:tc:xacml:3.0:function:string-from-boolean | M |
| urn:oasis:names:tc:xacml:3.0:function:integer-from-string | M |
| urn:oasis:names:tc:xacml:3.0:function:string-from-integer | M |
| urn:oasis:names:tc:xacml:3.0:function:double-from-string | M |
| urn:oasis:names:tc:xacml:3.0:function:string-from-double | M |
| urn:oasis:names:tc:xacml:3.0:function:time-from-string | M |
| urn:oasis:names:tc:xacml:3.0:function:string-from-time | M |
| urn:oasis:names:tc:xacml:3.0:function:date-from-string | M |
| urn:oasis:names:tc:xacml:3.0:function:string-from-date | M |
| urn:oasis:names:tc:xacml:3.0:function:dateTime-from-string | M |
| urn:oasis:names:tc:xacml:3.0:function:string-from-dateTime | M |
| urn:oasis:names:tc:xacml:3.0:function:anyURI-from-string | M |
| urn:oasis:names:tc:xacml:3.0:function:string-from-anyURI | M |
| urn:oasis:names:tc:xacml:3.0:function:dayTimeDuration-from-string | M |
| urn:oasis:names:tc:xacml:3.0:function:string-from-dayTimeDuration | M |
| urn:oasis:names:tc:xacml:3.0:function:yearMonthDuration-from-string | M |
| urn:oasis:names:tc:xacml:3.0:function:string-from-yearMonthDuration | M |
| urn:oasis:names:tc:xacml:3.0:function:x500Name-from-string | M |
| urn:oasis:names:tc:xacml:3.0:function:string-from-x500Name | M |
| urn:oasis:names:tc:xacml:3.0:function:rfc822Name-from-string | M |
| urn:oasis:names:tc:xacml:3.0:function:string-from-rfc822Name | M |
| urn:oasis:names:tc:xacml:3.0:function:ipAddress-from-string | M |
| urn:oasis:names:tc:xacml:3.0:function:string-from-ipAddress | M |
| urn:oasis:names:tc:xacml:3.0:function:dnsName-from-string | M |
| urn:oasis:names:tc:xacml:3.0:function:string-from-dnsName | M |
| urn:oasis:names:tc:xacml:3.0:function:string-starts-with | M |
| urn:oasis:names:tc:xacml:3.0:function:anyURI-starts-with | M |
| urn:oasis:names:tc:xacml:3.0:function:string-ends-with | M |
| urn:oasis:names:tc:xacml:3.0:function:anyURI-ends-with | M |
| urn:oasis:names:tc:xacml:3.0:function:string-contains | M |
| urn:oasis:names:tc:xacml:3.0:function:anyURI-contains | M |
| urn:oasis:names:tc:xacml:3.0:function:string-substring | M |
| urn:oasis:names:tc:xacml:3.0:function:anyURI-substring | M |
| urn:oasis:names:tc:xacml:3.0:function:any-of | M |
| urn:oasis:names:tc:xacml:3.0:function:all-of | M |
| urn:oasis:names:tc:xacml:3.0:function:any-of-any | M |
| urn:oasis:names:tc:xacml:1.0:function:all-of-any | M |
| urn:oasis:names:tc:xacml:1.0:function:any-of-all | M |
| urn:oasis:names:tc:xacml:1.0:function:all-of-all | M |
| urn:oasis:names:tc:xacml:3.0:function:map | M |
| urn:oasis:names:tc:xacml:1.0:function:x500Name-match | M |
| urn:oasis:names:tc:xacml:1.0:function:rfc822Name-match | M |
| urn:oasis:names:tc:xacml:1.0:function:string-regexp-match | M |
| urn:oasis:names:tc:xacml:2.0:function:anyURI-regexp-match | M |
| urn:oasis:names:tc:xacml:2.0:function:ipAddress-regexp-match | M |
| urn:oasis:names:tc:xacml:2.0:function:dnsName-regexp-match | M |
| urn:oasis:names:tc:xacml:2.0:function:rfc822Name-regexp-match | M |
| urn:oasis:names:tc:xacml:2.0:function:x500Name-regexp-match | M |
| urn:oasis:names:tc:xacml:3.0:function:xpath-node-count | O |
| urn:oasis:names:tc:xacml:3.0:function:xpath-node-equal | O |
| urn:oasis:names:tc:xacml:3.0:function:xpath-node-match | O |
| urn:oasis:names:tc:xacml:1.0:function:string-intersection | M |
| urn:oasis:names:tc:xacml:1.0:function:string-at-least-one-member-of | M |
| urn:oasis:names:tc:xacml:1.0:function:string-union | M |
| urn:oasis:names:tc:xacml:1.0:function:string-subset | M |
| urn:oasis:names:tc:xacml:1.0:function:string-set-equals | M |
| urn:oasis:names:tc:xacml:1.0:function:boolean-intersection | M |
| urn:oasis:names:tc:xacml:1.0:function:boolean-at-least-one-member-of | M |
| urn:oasis:names:tc:xacml:1.0:function:boolean-union | M |
| urn:oasis:names:tc:xacml:1.0:function:boolean-subset | M |
| urn:oasis:names:tc:xacml:1.0:function:boolean-set-equals | M |
| urn:oasis:names:tc:xacml:1.0:function:integer-intersection | M |
| urn:oasis:names:tc:xacml:1.0:function:integer-at-least-one-member-of | M |
| urn:oasis:names:tc:xacml:1.0:function:integer-union | M |
| urn:oasis:names:tc:xacml:1.0:function:integer-subset | M |
| urn:oasis:names:tc:xacml:1.0:function:integer-set-equals | M |
| urn:oasis:names:tc:xacml:1.0:function:double-intersection | M |
| urn:oasis:names:tc:xacml:1.0:function:double-at-least-one-member-of | M |
| urn:oasis:names:tc:xacml:1.0:function:double-union | M |
| urn:oasis:names:tc:xacml:1.0:function:double-subset | M |
| urn:oasis:names:tc:xacml:1.0:function:double-set-equals | M |
| urn:oasis:names:tc:xacml:1.0:function:time-intersection | M |
| urn:oasis:names:tc:xacml:1.0:function:time-at-least-one-member-of | M |
| urn:oasis:names:tc:xacml:1.0:function:time-union | M |
| urn:oasis:names:tc:xacml:1.0:function:time-subset | M |
| urn:oasis:names:tc:xacml:1.0:function:time-set-equals | M |
| urn:oasis:names:tc:xacml:1.0:function:date-intersection | M |
| urn:oasis:names:tc:xacml:1.0:function:date-at-least-one-member-of | M |
| urn:oasis:names:tc:xacml:1.0:function:date-union | M |
| urn:oasis:names:tc:xacml:1.0:function:date-subset | M |
| urn:oasis:names:tc:xacml:1.0:function:date-set-equals | M |
| urn:oasis:names:tc:xacml:1.0:function:dateTime-intersection | M |
| urn:oasis:names:tc:xacml:1.0:function:dateTime-at-least-one-member-of | M |
| urn:oasis:names:tc:xacml:1.0:function:dateTime-union | M |
| urn:oasis:names:tc:xacml:1.0:function:dateTime-subset | M |
| urn:oasis:names:tc:xacml:1.0:function:dateTime-set-equals | M |
| urn:oasis:names:tc:xacml:1.0:function:anyURI-intersection | M |
| urn:oasis:names:tc:xacml:1.0:function:anyURI-at-least-one-member-of | M |
| urn:oasis:names:tc:xacml:1.0:function:anyURI-union | M |
| urn:oasis:names:tc:xacml:1.0:function:anyURI-subset | M |
| urn:oasis:names:tc:xacml:1.0:function:anyURI-set-equals | M |
| urn:oasis:names:tc:xacml:1.0:function:hexBinary-intersection | M |
| urn:oasis:names:tc:xacml:1.0:function:hexBinary-at-least-one-member-of | M |
| urn:oasis:names:tc:xacml:1.0:function:hexBinary-union | M |
| urn:oasis:names:tc:xacml:1.0:function:hexBinary-subset | M |
| urn:oasis:names:tc:xacml:1.0:function:hexBinary-set-equals | M |
| urn:oasis:names:tc:xacml:1.0:function:base64Binary-intersection | M |
| urn:oasis:names:tc:xacml:1.0:function:base64Binary-at-least-one-member-of | M |
| urn:oasis:names:tc:xacml:1.0:function:base64Binary-union | M |
| urn:oasis:names:tc:xacml:1.0:function:base64Binary-subset | M |
| urn:oasis:names:tc:xacml:1.0:function:base64Binary-set-equals | M |
| urn:oasis:names:tc:xacml:3.0:function:dayTimeDuration-intersection | M |
| urn:oasis:names:tc:xacml:3.0:function:dayTimeDuration-at-least-one-member-of | M |
| urn:oasis:names:tc:xacml:3.0:function:dayTimeDuration-union | M |
| urn:oasis:names:tc:xacml:3.0:function:dayTimeDuration-subset | M |
| urn:oasis:names:tc:xacml:3.0:function:dayTimeDuration-set-equals | M |
| urn:oasis:names:tc:xacml:3.0:function:yearMonthDuration-intersection | M |
| urn:oasis:names:tc:xacml:3.0:function:yearMonthDuration-at-least-one-member-of | M |
| urn:oasis:names:tc:xacml:3.0:function:yearMonthDuration-union | M |
| urn:oasis:names:tc:xacml:3.0:function:yearMonthDuration-subset | M |
| urn:oasis:names:tc:xacml:3.0:function:yearMonthDuration-set-equals | M |
| urn:oasis:names:tc:xacml:1.0:function:x500Name-intersection | M |
| urn:oasis:names:tc:xacml:1.0:function:x500Name-at-least-one-member-of | M |
| urn:oasis:names:tc:xacml:1.0:function:x500Name-union | M |
| urn:oasis:names:tc:xacml:1.0:function:x500Name-subset | M |
| urn:oasis:names:tc:xacml:1.0:function:x500Name-set-equals | M |
| urn:oasis:names:tc:xacml:1.0:function:rfc822Name-intersection | M |
| urn:oasis:names:tc:xacml:1.0:function:rfc822Name-at-least-one-member-of | M |
| urn:oasis:names:tc:xacml:1.0:function:rfc822Name-union | M |
| urn:oasis:names:tc:xacml:1.0:function:rfc822Name-subset | M |
| urn:oasis:names:tc:xacml:1.0:function:rfc822Name-set-equals | M |
| urn:oasis:names:tc:xacml:3.0:function:access-permitted | O |
These identifiers are associated with previous versions of XACML and newer alternatives exist in XACML 4.0. They are planned to be deprecated at some unspecified point in the future. It is RECOMMENDED that these identifiers not be used in new policies and requests.
The implementation MUST properly process those features associated
with the identifiers marked with an M.
| Function | M/O |
|---|---|
| urn:oasis:names:tc:xacml:1.0:function:xpath-node-count | O |
| urn:oasis:names:tc:xacml:1.0:function:xpath-node-equal | O |
| urn:oasis:names:tc:xacml:1.0:function:xpath-node-match | O |
| urn:oasis:names:tc:xacml:2.0:function:uri-string-concatenate | M |
| https://www.w3.org/TR/2002/WD-xquery-operators-20020816#dayTimeDuration | M |
| https://www.w3.org/TR/2002/WD-xquery-operators-20020816#yearMonthDuration | M |
| urn:oasis:names:tc:xacml:1.0:function:dayTimeDuration-equal | M |
| urn:oasis:names:tc:xacml:1.0:function:yearMonthDuration-equal | M |
| urn:oasis:names:tc:xacml:1.0:function:dateTime-add-dayTimeDuration | M |
| urn:oasis:names:tc:xacml:1.0:function:dateTime-add-yearMonthDuration | M |
| urn:oasis:names:tc:xacml:1.0:function:dateTime-subtract-dayTimeDuration | M |
| urn:oasis:names:tc:xacml:1.0:function:dateTime-subtract-yearMonthDuration | M |
| urn:oasis:names:tc:xacml:1.0:function:date-add-yearMonthDuration | M |
| urn:oasis:names:tc:xacml:1.0:function:date-subtract-yearMonthDuration | M |
| urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:deny-overrides | M |
| urn:oasis:names:tc:xacml:1.0:policy-combining-algorithm:deny-overrides | M |
| urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:permit-overrides | M |
| urn:oasis:names:tc:xacml:1.0:policy-combining-algorithm:permit-overrides | M |
| urn:oasis:names:tc:xacml:1.1:rule-combining-algorithm:ordered-deny-overrides | M |
| urn:oasis:names:tc:xacml:1.1:policy-combining-algorithm:ordered-deny-overrides | M |
| urn:oasis:names:tc:xacml:1.1:rule-combining-algorithm:ordered-permit-overrides | M |
| urn:oasis:names:tc:xacml:1.1:policy-combining-algorithm:ordered-permit-overrides | M |
| urn:oasis:names:tc:xacml:1.0:function:dayTimeDuration-intersection | M |
| urn:oasis:names:tc:xacml:1.0:function:dayTimeDuration-at-least-one-member-of | M |
| urn:oasis:names:tc:xacml:1.0:function:dayTimeDuration-union | M |
| urn:oasis:names:tc:xacml:1.0:function:dayTimeDuration-subset | M |
| urn:oasis:names:tc:xacml:1.0:function:dayTimeDuration-set-equals | M |
| urn:oasis:names:tc:xacml:1.0:function:yearMonthDuration-intersection | M |
| urn:oasis:names:tc:xacml:1.0:function:yearMonthDuration-at-least-one-member-of | M |
| urn:oasis:names:tc:xacml:1.0:function:yearMonthDuration-union | M |
| urn:oasis:names:tc:xacml:1.0:function:yearMonthDuration-subset | M |
| urn:oasis:names:tc:xacml:1.0:function:yearMonthDuration-set-equals | M |
| urn:oasis:names:tc:xacml:1.0:function:dayTimeDuration-one-and-only | M |
| urn:oasis:names:tc:xacml:1.0:function:dayTimeDuration-bag-size | M |
| urn:oasis:names:tc:xacml:1.0:function:dayTimeDuration-is-in | M |
| urn:oasis:names:tc:xacml:1.0:function:dayTimeDuration-bag | M |
| urn:oasis:names:tc:xacml:1.0:function:yearMonthDuration-one-and-only | M |
| urn:oasis:names:tc:xacml:1.0:function:yearMonthDuration-bag-size | M |
| urn:oasis:names:tc:xacml:1.0:function:yearMonthDuration-is-in | M |
| urn:oasis:names:tc:xacml:1.0:function:yearMonthDuration-bag | M |
| urn:oasis:names:tc:xacml:1.0:function:any-of | M |
| urn:oasis:names:tc:xacml:1.0:function:all-of | M |
| urn:oasis:names:tc:xacml:1.0:function:any-of-any | M |
| urn:oasis:names:tc:xacml:1.0:function:map | M |
This appendix contains the normative and informative references that are used in this document.
While any hyperlinks included in this appendix were valid at the time of publication, OASIS cannot guarantee their long-term validity.
`(Reference sources: For references to IETF RFCs, use the approved
citation formats at:
https://docs.oasis-open.org/templates/ietf-rfc-list/ietf-rfc-list.html.
For references to W3C Recommendations, use the approved citation formats
at:
https://docs.oasis-open.org/templates/w3c-recommendations-list/w3c-recommendations-list.html.
Remove this note before submitting for publication.)`
Martin J. Dürst et al, eds., Character Model for the World Wide Web 1.0: Fundamentals, W3C Recommendation 15 February 2005, https://www.w3.org/TR/2005/REC-charmod-20050215/
D. Eastlake et al., XML-Signature Syntax and Processing, https://www.w3.org/TR/xmldsig-core/, World Wide Web Consortium.
J. Boyer et al, eds., Exclusive XML Canonicalization, Version 1.0, W3C Recommendation 18 July 2002, https://www.w3.org/TR/2002/REC-xml-exc-c14n-20020718/
Hancock, Polymorphic Type Checking, in Simon L. Peyton Jones, Implementation of Functional Programming Languages, Section 8, Prentice-Hall International, 1987.
XACML v3.0 Hierarchical Resource Profile Version 1.0. 11 March 2010. Committee Specification Draft 03. https://docs.oasis-open.org/xacml/3.0/xacml-3.0-hierarchical-v1-spec-cd-03-en.html
IEEE Standard for Binary Floating-Point Arithmetic 1985, ISBN 1-5593-7653-8, IEEE Product No. SH10116-TBR.
XML Information Set (Second Edition), W3C Recommendation, 4 February 2004, https://www.w3.org/TR/xml-infoset/
ISO/IEC 10181-3:1996 Information technology – Open Systems Interconnection -- Security frameworks for open systems: Access control framework.
Kudo M and Hada S, XML document security based on provisional authorization, Proceedings of the Seventh ACM Conference on Computer and Communications Security, Nov 2000, Athens, Greece, pp 87-96.
RFC2256, A summary of the X500(96) User Schema for use with LDAPv3, Section 5, M Wahl, December 1997, https://www.ietf.org/rfc/rfc2256.txt
RFC2798, Definition of the inetOrgPerson, M. Smith, April 2000, https://www.ietf.org/rfc/rfc2798.txt
Mathematical Markup Language (MathML), Version 2.0, W3C Recommendation, 21 October 2003, https://www.w3.org/TR/2003/REC-MathML2-20031021/
OASIS Committee Draft 03, XACML v3.0 Multiple Decision Profile Version 1.0, 11 March 2010, https://docs.oasis-open.org/xacml/3.0/xacml-3.0-multiple-v1-spec-cd-03-en.doc
Perritt, H. Knowbots, Permissions Headers and Contract Law, Conference on Technological Strategies for Protecting Intellectual Property in the Networked Multimedia Environment, April 1993. Available at: https://www.cni.org/resources/historical-resources/technological-strategies-for-protecting-intellectual-property-in-the-networked-multimedia-environment/permission-headers-and-contract-law
David Ferraiolo and Richard Kuhn, Role-Based Access Controls, 15th National Computer Security Conference, 1992.
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, https://www.rfc-editor.org/info/rfc2119.
Berners-Lee T, Fielding R, Masinter L, Uniform Resource Identifiers (URI): Generic Syntax, https://www.ietf.org/rfc/rfc2396.txt
Hinden R, Carpenter B, Masinter L, Format for Literal IPv6 Addresses in URL's, https://www.ietf.org/rfc/rfc2732.txt
IETF RFC 3198: Terminology for Policy-Based Management, November 2001. https://www.ietf.org/rfc/rfc3198.txt
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, https://www.rfc-editor.org/info/rfc8174.
Mark Davis, Martin Dürst, Unicode Standard Annex #15: Unicode Normalization Forms, Unicode 5.1, https://unicode.org/reports/tr15/
Davis, Mark, Suignard, Michel, Unicode Technical Report #36: Unicode Security Considerations, https://www.unicode.org/reports/tr36/
OASIS Committee Draft 03, XACML v3.0 Administration and Delegation Profile Version 1.0. 11 March 2010, https://docs.oasis-open.org/xacml/3.0/xacml-3.0-administration-v1-spec-cd-03-en.doc
OASIS Standard, Extensible access control markup language (XACML) Version 1.0. 18 February 2003, https://www.oasis-open.org/committees/download.php/2406/oasis-xacml-1.0.pdf
OASIS Committee Specification, Extensible access control markup language (XACML) Version 1.1. 7 August 2003, https://www.oasis-open.org/committees/xacml/repository/cs-xacml-specification-1.1.pdf
XQuery 1.0 and XPath 2.0 Functions and Operators, W3C Recommendation 23 January 2007, https://www.w3.org/TR/2007/REC-xpath-functions-20070123/
Bray, Tim, et.al. eds, Extensible Markup Language (XML) 1.0 (Fifth Edition), W3C Recommendation 26 November 2008, https://www.w3.org/TR/2008/REC-xml-20081126/
Marsh, Jonathan, et.al. eds, xml:id Version 1.0. W3C Recommendation 9 September 2005, https://www.w3.org/TR/2005/REC-xml-id-20050909/
XML Schema, parts 1 and 2. Available at: https://www.w3.org/TR/xmlschema-1/ and https://www.w3.org/TR/xmlschema-2/
XML Path Language (XPath), Version 1.0, W3C Recommendation 16 November 1999, https://www.w3.org/TR/xpath/
XQuery 1.0 and XPath 2.0 Functions and Operators (Second Edition), W3C Recommendation 14 December 2010, https://www.w3.org/TR/2010/REC-xpath-functions-20101214/
XSL Transformations (XSLT) Version 1.0, W3C Recommendation 16 November 1999, https://www.w3.org/TR/xslt/
Character model for the World Wide Web 1.0: Normalization, W3C Working Draft, 27 October 2005, https://www.w3.org/TR/2005/WD-charmod-norm-20051027/, World Wide Web Consortium.
Hinton, H, M, Lee, E, S, The Compatibility of Policies, Proceedings 2nd ACM Conference on Computer and Communications Security, Nov 1994, Fairfax, Virginia, USA.
Sloman, M. Policy Driven Management for Distributed Systems. Journal of Network and Systems Management, Volume 2, part 4. Plenum Press. 1994.
This section identifies possible security and privacy compromise scenarios that should be considered when implementing an XACML-based system. The section is informative only. It is left to the implementer to decide whether these compromise scenarios are practical in their environment and to select appropriate safeguards.
We assume here that the adversary has access to the communication channel between the XACML actors and is able to interpret, insert, delete, and modify messages or parts of messages.
Additionally, an actor may use information from a former message maliciously in subsequent transactions. It is further assumed that rules and policies are only as reliable as the actors that create and use them. Thus it is incumbent on each actor to establish appropriate trust in the other actors upon which it relies. Mechanisms for trust establishment are outside the scope of this specification.
The messages that are transmitted between the actors in the XACML model are susceptible to attack by malicious third parties. Other points of vulnerability include the PEP, the PDP, and the PAP. While some of these entities are not strictly within the scope of this specification, their compromise could lead to the compromise of access control enforced by the PEP.
It should be noted that there are other components of a distributed system that may be compromised, such as an operating system and the domain-name system (DNS) that are outside the scope of this discussion of threat models. Compromise in these components may also lead to a policy violation.
The following sections detail specific compromise scenarios that may be relevant to an XACML system.
XACML does not specify any inherent mechanisms to protect the confidentiality of the messages exchanged between actors. Therefore, an adversary could observe the messages in transit. Under certain security policies, disclosure of this information is a violation. Disclosure of attributes or the types of decision requests that a subject submits may be a breach of privacy policy. In the commercial sector, the consequences of unauthorized disclosure of personal data may range from embarrassment to the custodian, to imprisonment and/or large fines in the case of medical or financial data.
Unauthorized disclosure is addressed by confidentiality safeguards.
A message replay attack is one in which the adversary records and replays legitimate messages between XACML actors. This attack may lead to denial of service, the use of out-of-date information or impersonation.
Prevention of replay attacks requires the use of message freshness safeguards.
Note that encryption of the message does not mitigate a replay attack since the message is simply replayed and does not have to be understood by the adversary.
A message insertion attack is one in which the adversary inserts messages in the sequence of messages between XACML actors.
The solution to a message insertion attack is to use mutual authentication and message sequence integrity safeguards between the actors. It should be noted that just using SSL mutual authentication is not sufficient. This only proves that the other party is the one identified by the subject of the X.509 certificate. In order to be effective, it is necessary to confirm that the certificate subject is authorized to send the message.
A message deletion attack is one in which the adversary deletes messages in the sequence of messages between XACML actors. Message deletion may lead to denial of service. However, a properly designed XACML system should not render an incorrect authorization decision as a result of a message deletion attack.
The solution to a message deletion attack is to use message sequence integrity safeguards between the actors.
If an adversary can intercept a message and change its contents, then they may be able to alter an authorization decision. A message integrity safeguard can prevent a successful message modification attack.
A result of NotApplicable means that the
PDP could not locate a
policy whose target
matched the information in the decision
request. In general, it is highly recommended that a
Deny effect
policy be used, so that when a
PDP would have returned
NotApplicable, a result of Deny is returned
instead.
In some security models, however, such as those found in many web
servers, an authorization decision of
NotApplicable is treated as equivalent to
Permit. There are particular security considerations that
must be taken into account for this to be safe. These are explained in
the following paragraphs.
If NotApplicable is to be treated as
Permit, it is vital that the matching algorithms used by
the policy to match elements in the
decision request be closely aligned with the
data syntax used by the applications that will be submitting the
decision request. A failure to match will
result in NotApplicable and be treated as
Permit. So an unintended failure to match may allow
unintended access.
Commercial http responders allow a variety of syntaxes to be treated
equivalently. The % can be used to represent characters by
hex value. The URL path /../ provides multiple ways of
specifying the same value. Multiple character sets may be permitted and,
in some cases, the same printed character can be represented by
different binary values. Unless the matching algorithm used by the
policy is sophisticated enough to catch these
variations, unintended access may be
permitted.
It may be safe to treat NotApplicable as
Permit only in a closed environment where all applications
that formulate a decision request can be
guaranteed to use the exact syntax expected by the
policies. In a more open environment, where
decision requests may be received from
applications that use any legal syntax, it is strongly recommended that
NotApplicable NOT be treated as Permit unless
matching rules have been very carefully
designed to match all possible applicable inputs, regardless of syntax
or type variations. Note, however, that according to Section 7.2, a
PEP must deny access
unless it receives an explicit Permit
authorization decision.
A negative rule is one that is based on a
predicate not being True. If not
used with care, negative rules can lead to
policy violations, therefore some authorities recommend that they not be
used. However, negative rules can be extremely
efficient in certain cases, so XACML has chosen to include them.
Nevertheless, it is recommended that they be used with care and avoided
if possible.
A common use for negative rules is to deny
access to an individual or subgroup when their
membership in a larger group would otherwise permit them
access. For example, we might want to write a
rule that allows all vice presidents to see
the unpublished financial data, except for Joe, who is only a ceremonial
vice president and can be indiscreet in his communications. If we have
complete control over the administration of
subject attributes,
a superior approach would be to define Vice President and
Ceremonial Vice President as distinct groups and then
define rules accordingly. However, in some
environments this approach may not be feasible. (It is worth noting in
passing that referring to individuals in rules
does not scale well. Generally, shared
attributes are preferred.)
If not used with care, negative rules can lead to policy violations in two common cases: when attributes are suppressed and when the base group changes. An example of suppressed attributes would be if we have a policy that access should be permitted, unless the subject is a credit risk. If it is possible that the attribute of being a credit risk may be unknown to the PDP for some reason, then unauthorized access may result. In some environments, the subject may be able to suppress the publication of attributes by the application of privacy controls, or the server or repository that contains the information may be unavailable for accidental or intentional reasons.
An example of a changing base group would be if there is a policy that everyone in the engineering department may change software source code, except for secretaries. Suppose now that the department was to merge with another engineering department and the intent is to maintain the same policy. However, the new department also includes individuals identified as administrative assistants, who ought to be treated in the same way as secretaries. Unless the policy is altered, they will unintentionally be permitted to change software source code. Problems of this type are easy to avoid when one individual administers all policies, but when administration is distributed, as XACML allows, this type of situation must be explicitly guarded against.
A denial of service attack is one in which the adversary overloads an XACML actor with excessive computations or network traffic such that legitimate users cannot access the services provided by the actor.
The urn:oasis:names:tc:xacml:3.0:function:access-permitted function may lead to hard to predict behavior in the PDP. It is possible that the function is invoked during the recursive invocations of the PDP such that loops are formed. Such loops may in some cases lead to large numbers of requests to be generated before the PDP can detect the loop and abort evaluation. Such loops could cause a denial of service at the PDP, either because of a malicious policy or because of a mistake in a policy.
Authentication provides the means for one party in a transaction to determine the identity of the other party in the transaction. Authentication may be in one direction, or it may be bilateral.
Given the sensitive nature of access control systems, it is important for a PEP to authenticate the identity of the PDP to which it sends decision requests. Otherwise, there is a risk that an adversary could provide false or invalid authorization decisions, leading to a policy violation.
It is equally important for a PDP to
authenticate the identity of the PEP and
assess the level of trust to determine what, if any, sensitive data
should be passed. One should keep in mind that even simple
Permit or Deny responses could be exploited if
an adversary were allowed to make unlimited requests to a
PDP.
Many different techniques may be used to provide authentication, such as co-located code, a private network, a VPN, or digital signatures. Authentication may also be performed as part of the communication protocol used to exchange the contexts. In this case, authentication may be performed either at the message level or at the session level.
If the contents of policies are exposed outside of the access control system, potential subjects may use this information to determine how to gain unauthorized access.
To prevent this threat, the repository used for the storage of
policies may itself require access
control. In addition, the <Status>
element should be used to return values of missing
attributes only when exposure of the
identities of those attributes will not
compromise security.
Confidentiality mechanisms ensure that the contents of a message can
be read only by the desired recipients and not by anyone else who
encounters the message while it is in transit. There are two areas in
which confidentiality should be considered: one is confidentiality
during transmission; the other is confidentiality within a
<Policy> element.
In some environments it is deemed good practice to treat all data within an access control system as confidential. In other environments, policies may be made freely available for distribution, inspection, and audit. The idea behind keeping policy information secret is to make it more difficult for an adversary to know what steps might be sufficient to obtain unauthorized access. Regardless of the approach chosen, the security of the access control system should not depend on the secrecy of the policy.
Any security considerations related to transmitting or exchanging
XACML <Policy> elements are outside the scope of the
XACML standard. While it is important to ensure that the integrity and
confidentiality of <Policy> elements is maintained
when they are exchanged between two parties, it is left to the
implementers to determine the appropriate mechanisms for their
environment.
Communications confidentiality can be provided by a confidentiality mechanism, such as SSL. Using a point-to-point scheme like SSL may lead to other vulnerabilities when one of the end-points is compromised.
In some cases, an implementation may want to encrypt only parts of an
XACML <Policy> element.
The XML Encryption Syntax and Processing Candidate Recommendation from W3C can be used to encrypt all or parts of an XML document. This specification is recommended for use with XACML.
It should go without saying that if a repository is used to facilitate the communication of cleartext (i.e., unencrypted) policy between the PAP and PDP, then a secure repository should be used to store this sensitive data.
The XACML policy used by the
PDP to evaluate the request
context is the heart of the system. Therefore,
maintaining its integrity is essential. There are two aspects to
maintaining the integrity of the policy. One
is to ensure that <Policy> elements have not been
altered since they were originally created by the
PAP. The other is to ensure that
<Policy> elements have not been inserted or deleted
from the set of policies.
In many cases, both aspects can be achieved by ensuring the integrity of the actors and implementing session-level mechanisms to secure the communication between actors. The selection of the appropriate mechanisms is left to the implementers. However, when policy is distributed between organizations to be acted on at a later time, or when the policy travels with the protected resource, it would be useful to sign the policy. In these cases, the XML Signature Syntax and Processing standard from W3C is recommended to be used with XACML.
Digital signatures should only be used to ensure the integrity of the statements. Digital signatures should not be used as a method of selecting or evaluating policy. That is, the PDP should not request a policy based on who signed it or whether or not it has been signed (as such a basis for selection would, itself, be a matter of policy). However, the PDP must verify that the key used to sign the policy is one controlled by the purported issuer of the policy. The means to do this are dependent on the specific signature technology chosen and are outside the scope of this document.
Since policies can be referenced by their identifiers, it is the responsibility of the PAP to ensure that these are unique. Confusion between identifiers could lead to misidentification of the applicable policy. This specification is silent on whether a PAP must generate a new identifier when a policy is modified or may use the same identifier in the modified policy. This is a matter of administrative practice. However, care must be taken in either case. If the identifier is reused, there is a danger that other policies that reference it may be adversely affected. Conversely, if a new identifier is used, these other policies may continue to use the prior policy, unless it is deleted. In either case the results may not be what the policy administrator intends.
If a PDP is provided with policies from distinct sources which might not be fully trusted, as in the use of the administration profile [XACMLAdmin], there is a concern that someone could intentionally publish a policy with an id which collides with another policy. This could cause policy references that point to the wrong policy, and may cause other unintended consequences in an implementation which is predicated upon having unique policy identifiers.
If this issue is a concern it is RECOMMENDED that distinct policy issuers or sources are assigned distinct namespaces for policy identifiers. One method is to make sure that the policy identifier begins with a string which has been assigned to the particular policy issuer or source. The remainder of the policy identifier is an issuer-specific unique part. For instance, Alice from Example Inc. could be assigned the policy identifiers which begin with https://example.com/xacml/policyId/alice/. The PDP or another trusted component can then verify that the authenticated source of the policy is Alice at Example Inc, or otherwise reject the policy. Anyone else will be unable to publish policies with identifiers which collide with the policies of Alice.
Discussions of authentication, integrity and confidentiality safeguards necessarily assume an underlying trust model: how can one actor come to believe that a given key is uniquely associated with a specific, identified actor so that the key can be used to encrypt data for that actor or verify signatures (or other integrity structures) from that actor? Many different types of trust models exist, including strict hierarchies, distributed authorities, the Web, the bridge, and so on.
It is worth considering the relationships between the various actors of the access control system in terms of the interdependencies that do and do not exist.
None of the entities of the authorization system are dependent on the PEP. They may collect data from it, (for example authentication data) but are responsible for verifying it themselves.
The correct operation of the system depends on the ability of the PEP to actually enforce policy decisions.
The PEP depends on the PDP to correctly evaluate policies. This in turn implies that the PDP is supplied with the correct inputs. Other than that, the PDP does not depend on the PEP.
The PDP depends on the PAP to supply appropriate policies. The PAP is not dependent on other components.
It is important to be aware that any transactions that occur with
respect to access control may reveal private
information about the actors. For example, if an XACML
policy states that certain data may only be
read by subjects with
Gold Card Member status, then any transaction in which a
subject is permitted
access to that data leaks information to an
adversary about the subject's status. Privacy
considerations may therefore lead to encryption and/or to
access control requirements surrounding the
enforcement of XACML policy instances
themselves: confidentiality-protected channels for the request/response
protocol messages, protection of subject
attributes in storage and in transit, and so
on.
Selection and use of privacy mechanisms appropriate to a given environment are outside the scope of XACML. The decision regarding whether, how, and when to deploy such mechanisms is left to the implementers associated with the environment.
There are many security considerations related to use of Unicode. An XACML implementation SHOULD follow the advice given in the relevant version of [UTR36].
Section 7.20 defines the
identifier equality operation for XACML. This
definition of equality does not do any kind of canonicalization or
escaping of characters. The identifiers defined in the XACML
specification have been selected to not include any ambiguity regarding
these aspects. It is RECOMMENDED that identifiers defined by extensions
also do not introduce any identifiers which might be mistaken for being
subject to processing, like for instance URL character encoding using
%.
Note: A Work Product approved by the TC must include a list of people who participated in the development of the Work Product. This is generally done by collecting the list of names in this appendix. This list shall be initially compiled by the Chair, and any Member of the TC may add or remove their names from the list by request. Remove this note before submitting for publication.
Substantial contributions to this document from the following individuals are gratefully acknowledged:
Steven Legg, ViewDS Identity Solutions
Cyril Dangerville, THALES
The following individuals have participated in the creation of this specification and are gratefully acknowledged:
XACML TC Members:
| First Name | Last Name | Company |
|---|---|---|
| Hal | Lochhart | Individual |
| Bill | Parducci | Individual |
| Steven | Legg | ViewDS Identity Solutions |
| Cyril | Dangerville | THALES |
| Revision | Date | Editor | Changes Made |
|---|---|---|---|
| specname-v1.0-wd01 | 2024-08-09 | Steven Legg | Initial working draft |
| 2024-09-09 | Steven Legg | Changed targets to a single child expression. | |
Removed the <AnyOf>,
<AllOf> and <Match> elements. |
|||
| Removed targets from rules. | |||
| Removed the only-one-applicable combining algorithm. | |||
| 2024-09-28 | Cyril Dangerville | Embedded diagrams. | |
| 2024-09-30 | Cyril Dangerville | Added support for definition lists. | |
| 2024-10-22 | Steven Legg | Reformatted indented paragraphs. | |
| Made MustBePresent, CombinedDecision and ReturnPolicyIdList XML attributes default false. | |||
| 2025-04-16 | Steven Legg | Restructured the type hierarchy for policy references. | |
| 2025-04-17 | Steven Legg | Merged obligations and advice into notices. | |
| 2025-07-15 | Steven Legg | Added support for short identifiers. |
This section specifies the data-types and functions used in XACML to create predicates for conditions and targets.
This specification combines the various standards set forth by IEEE and ANSI for string representation of numeric values, as well as the evaluation of arithmetic functions. It describes the primitive data-types and bags. The standard functions are named and their operational semantics are described.
Although XML instances represent all data-types as strings, an XACML *PDP must operate on types of data that, while they have string representations, are not just strings. Types such as Boolean, integer, and double MUST be converted from their XML string representations to values that can be compared with values in their domain of discourse, such as numbers. The following primitive data-types are specified for use with XACML and have explicit data representations:
https://www.w3.org/2001/XMLSchema#string
https://www.w3.org/2001/XMLSchema#boolean
https://www.w3.org/2001/XMLSchema#integer
https://www.w3.org/2001/XMLSchema#double
https://www.w3.org/2001/XMLSchema#time
https://www.w3.org/2001/XMLSchema#date
https://www.w3.org/2001/XMLSchema#dateTime
https://www.w3.org/2001/XMLSchema#anyURI
https://www.w3.org/2001/XMLSchema#hexBinary
https://www.w3.org/2001/XMLSchema#base64Binary
https://www.w3.org/2001/XMLSchema#dayTimeDuration
https://www.w3.org/2001/XMLSchema#yearMonthDuration
urn:oasis:names:tc:xacml:1.0:data-type:x500Name
urn:oasis:names:tc:xacml:1.0:data-type:rfc822Name
urn:oasis:names:tc:xacml:2.0:data-type:ipAddress
urn:oasis:names:tc:xacml:2.0:data-type:dnsName
urn:oasis:names:tc:xacml:3.0:data-type:xpathExpression
For the sake of improved interoperability, it is RECOMMENDED that all time references be in UTC time.
An XACML PDP SHALL be capable of converting string representations into various primitive data-types. For doubles, XACML SHALL use the conversions described in [IEEE754].
XACML defines four data-types representing identifiers for subjects or resources; these are:
urn:oasis:names:tc:xacml:1.0:data-type:x500Name,
urn:oasis:names:tc:xacml:1.0:data-type:rfc822Name,
urn:oasis:names:tc:xacml:2.0:data-type:ipAddress
and
urn:oasis:names:tc:xacml:2.0:data-type:dnsName.
These types appear in several standard applications, such as TLS/SSL and electronic mail.
The urn:oasis:names:tc:xacml:1.0:data-type:x500Name
primitive type represents an ITU-T Rec. X.520 Distinguished Name. The
valid syntax for such a name is described in IETF RFC 2253 "Lightweight
Directory Access Protocol (v3): UTF-8 String Representation of
Distinguished Names".
The urn:oasis:names:tc:xacml:1.0:data-type:rfc822Name
primitive type represents an electronic mail address. The valid syntax
for such a name is described in IETF RFC 2821, Section 4.1.2, Command
Argument Syntax, under the term "Mailbox".
The urn:oasis:names:tc:xacml:2.0:data-type:ipAddress
primitive type represents an IPv4 or IPv6 network address, with optional
mask and optional port or port range. The syntax SHALL be:
ipAddress = address [ `/` mask ] [ `:` [ portrange ] ]For an IPv4 address, the address and mask are formatted in accordance with the syntax for a "host" in IETF RFC 2396 "Uniform Resource Identifiers (URI): Generic Syntax", section 3.2.
For an IPv6 address, the address and mask are formatted in accordance
with the syntax for an "ipv6reference" in IETF RFC 2732 "Format for
Literal IPv6 Addresses in URL's". (Note that an IPv6 address or mask, in
this syntax, is enclosed in literal [ ]
brackets.)
The urn:oasis:names:tc:xacml:2.0:data-type:dnsName
primitive type represents a Domain Name Service (DNS) host name, with
optional port or port range. The syntax SHALL be:
dnsName = hostname [ `:` portrange ]The hostname is formatted in accordance with IETF RFC 2396 "Uniform
Resource Identifiers (URI): Generic Syntax", section 3.2, except that a
wildcard * may be used in the left-most component of the
hostname to indicate "any subdomain" under the domain specified to its
right.
For both the
urn:oasis:names:tc:xacml:2.0:data-type:ipAddress and
urn:oasis:names:tc:xacml:2.0:data-type:dnsName
data-types, the port or port range syntax SHALL be
portrange = portnumber | `-`portnumber | portnumber`-`[portnumber]where portnumber is a decimal port number. If the port
number is of the form -x, where x is a port
number, then the range is all ports numbered x and below.
If the port number is of the form x-, then the range is all
ports numbered x and above. [This syntax is taken from the
Java SocketPermission.]
The
urn:oasis:names:tc:xacml:3.0:data-type:xpathExpression
primitive type represents an XPath expression over the XML in a
<Content> element. The syntax is defined by the XPath
W3C recommendation. The content of this data type also includes the
context in which namespaces prefixes in the expression are resolved,
which distinguishes it from a plain string and the XACML
attribute category of the
<Content> element to which it applies. When the value
is encoded in an <AttributeValue> element, the
namespace context is given by the [in-scope namespaces] (see [INFOSET])
of the <AttributeValue> element, and an XML attribute
called XPathCategory gives the category of the
<Content> element where the expression applies.
The XPath expression MUST be evaluated in a context which is
equivalent of a stand alone XML document with the only child of the
<Content> element as the document element. The
context node of the XPath expression is the document node of this stand
alone document. Namespace declarations from the
<Content> element and its ancestor elements for
namespace prefixes that are "visibly utilized", as defined by [exc-c14n], within the contents MUST be present.
Namespace declarations from the <Content> element or
its ancestor elements for namespace prefixes that are not "visibly
utilized" MAY be present.
XACML specifies the following functions. Unless otherwise specified,
if an argument of one of these functions were to evaluate to
Indeterminate, then the function SHALL be set to
Indeterminate.
Note that in each case an implementation is conformant as long as it produces the same result as is specified here, regardless of how and in what order the implementation behaves internally.
The following functions are the equality functions for the various primitive types. Each function for a particular data-type follows a specified standard convention for that data-type.
urn:oasis:names:tc:xacml:1.0:function:string-equalThis function SHALL take two arguments of data-type
https://www.w3.org/2001/XMLSchema#string and SHALL return
an https://www.w3.org/2001/XMLSchema#boolean. The function
SHALL return True if and only if the value of both of its
arguments are of equal length and each string is determined to be equal.
Otherwise, it SHALL return False. The comparison SHALL use
Unicode codepoint collation, as defined for the identifier https://www.w3.org/2005/xpath-functions/collation/codepoint/
by [XF].
urn:oasis:names:tc:xacml:3.0:function:string-equal-ignore-caseThis function SHALL take two arguments of data-type
https://www.w3.org/2001/XMLSchema#string and SHALL return
an https://www.w3.org/2001/XMLSchema#boolean. The result
SHALL be True if and only if the two strings are equal as
defined by urn:oasis:names:tc:xacml:1.0:function:string-equal after they
have both been converted to lower case with
urn:oasis:names:tc:xacml:1.0:function:string-normalize-to-lower-case.
urn:oasis:names:tc:xacml:1.0:function:boolean-equalThis function SHALL take two arguments of data-type
https://www.w3.org/2001/XMLSchema#boolean and SHALL return
an https://www.w3.org/2001/XMLSchema#boolean. The function
SHALL return True if and only if the arguments are equal.
Otherwise, it SHALL return False.
urn:oasis:names:tc:xacml:1.0:function:integer-equalThis function SHALL take two arguments of data-type
https://www.w3.org/2001/XMLSchema#integer and SHALL return
an https://www.w3.org/2001/XMLSchema#boolean. The function
SHALL return True if and only if the two arguments
represent the same number.
urn:oasis:names:tc:xacml:1.0:function:double-equalThis function SHALL take two arguments of data-type
https://www.w3.org/2001/XMLSchema#double and SHALL return
an https://www.w3.org/2001/XMLSchema#boolean. It SHALL
perform its evaluation on doubles according to IEEE 754 [IEEE754].
urn:oasis:names:tc:xacml:1.0:function:date-equalThis function SHALL take two arguments of data-type
https://www.w3.org/2001/XMLSchema#date and SHALL return an
https://www.w3.org/2001/XMLSchema#boolean. It SHALL perform
its evaluation according to the op:date-equal function [XF]
Section 10.4.9.
urn:oasis:names:tc:xacml:1.0:function:time-equalThis function SHALL take two arguments of data-type
https://www.w3.org/2001/XMLSchema#time and SHALL return an
https://www.w3.org/2001/XMLSchema#boolean. It SHALL perform
its evaluation according to the op:time-equal function [XF]
Section 10.4.12.
urn:oasis:names:tc:xacml:1.0:function:dateTime-equalThis function SHALL take two arguments of data-type
https://www.w3.org/2001/XMLSchema#dateTime and SHALL return
an https://www.w3.org/2001/XMLSchema#boolean. It SHALL
perform its evaluation according to the op:dateTime-equal
function [XF] Section 10.4.6.
urn:oasis:names:tc:xacml:3.0:function:dayTimeDuration-equalThis function SHALL take two arguments of data-type
https://www.w3.org/2001/XMLSchema#dayTimeDuration and SHALL
return an https://www.w3.org/2001/XMLSchema#boolean. This
function shall perform its evaluation according to the
op:duration-equal function [XF] Section 10.4.5. Note that
the lexical representation of each argument MUST be converted to a value
expressed in fractional seconds [XF] Section 10.3.2.
urn:oasis:names:tc:xacml:3.0:function:yearMonthDuration-equalThis function SHALL take two arguments of data-type
https://www.w3.org/2001/XMLSchema#yearMonthDuration and
SHALL return an https://www.w3.org/2001/XMLSchema#boolean.
This function shall perform its evaluation according to the
op:duration-equal function [XF] Section 10.4.5. Note that
the lexical representation of each argument MUST be converted to a value
expressed in fractional seconds [XF] Section 10.3.2.
urn:oasis:names:tc:xacml:1.0:function:anyURI-equalThis function SHALL take two arguments of data-type
https://www.w3.org/2001/XMLSchema#anyURI and SHALL return
an https://www.w3.org/2001/XMLSchema#boolean. The function
SHALL convert the arguments to strings with
urn:oasis:names:tc:xacml:3.0:function:string-from-anyURI and return
True if and only if the values of the two arguments are
equal on a codepoint-by-codepoint basis.
urn:oasis:names:tc:xacml:1.0:function:x500Name-equalThis function SHALL take two arguments of
urn:oasis:names:tc:xacml:1.0:data-type:x500Name and SHALL
return an https://www.w3.org/2001/XMLSchema#boolean. It
SHALL return True if and only if each Relative
Distinguished Name (RDN) in the two arguments matches. Otherwise, it
SHALL return False. Two RDNs shall be said to match if and
only if the result of the following operations is True
.
Normalize the two arguments according to IETF RFC 2253
Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names.
If any RDN contains multiple attributeTypeAndValue pairs,
re-order the Attribute ValuePairs in that RDN in ascending order when
compared as octet strings (described in ITU-T Rec. X.690 (1997 E)
Section 11.6 Set-of components).
Compare RDNs using the rules in IETF RFC 3280
Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile,
Section 4.1.2.4 Issuer.
urn:oasis:names:tc:xacml:1.0:function:rfc822Name-equalThis function SHALL take two arguments of data-type
urn:oasis:names:tc:xacml:1.0:data-type:rfc822Name and SHALL
return an https://www.w3.org/2001/XMLSchema#boolean. It
SHALL return True if and only if the two arguments are
equal. Otherwise, it SHALL return False. An RFC822 name
consists of a local-part followed by @ followed by a
domain-part. The local-part is case-sensitive, while the domain-part
(which is usually a DNS host name) is not case-sensitive. Perform the
following operations:
Normalize the domain-part of each argument to lower case
Compare the expressions by applying the function
urn:oasis:names:tc:xacml:1.0:function:string-equal to the
normalized arguments.
urn:oasis:names:tc:xacml:1.0:function:hexBinary-equalThis function SHALL take two arguments of data-type
https://www.w3.org/2001/XMLSchema#hexBinary and SHALL
return an https://www.w3.org/2001/XMLSchema#boolean. It
SHALL return True if the octet sequences represented by the
value of both arguments have equal length and are equal in a
conjunctive, point-wise, comparison using the
urn:oasis:names:tc:xacml:1.0:function:integer-equal
function. Otherwise, it SHALL return False. The conversion
from the string representation to an octet sequence SHALL be as
specified in [XS] Section 3.2.15.
urn:oasis:names:tc:xacml:1.0:function:base64Binary-equalThis function SHALL take two arguments of data-type
https://www.w3.org/2001/XMLSchema#base64Binary and SHALL
return an https://www.w3.org/2001/XMLSchema#boolean. It
SHALL return True if the octet sequences represented by the
value of both arguments have equal length and are equal in a
conjunctive, point-wise, comparison using the
urn:oasis:names:tc:xacml:1.0:function:integer-equal
function. Otherwise, it SHALL return False. The conversion
from the string representation to an octet sequence SHALL be as
specified in [XS] Section 3.2.16.
All of the following functions SHALL take two arguments of the
specified data-type, integer, or double, and SHALL return an element of
integer or double data-type, respectively. However, the add
and multiply functions MAY take more than two arguments.
Each function evaluation operating on doubles SHALL proceed as specified
by their logical counterparts in IEEE 754 [IEEE754]. For all of these
functions, if any argument is Indeterminate, then the
function SHALL evaluate to Indeterminate. In the case of
the divide functions, if the divisor is zero, then the function SHALL
evaluate to Indeterminate.
urn:oasis:names:tc:xacml:1.0:function:integer-addThis function MUST accept two or more arguments.
urn:oasis:names:tc:xacml:1.0:function:double-addThis function MUST accept two or more arguments.
urn:oasis:names:tc:xacml:1.0:function:integer-subtractThe result is the second argument subtracted from the first argument.
urn:oasis:names:tc:xacml:1.0:function:double-subtractThe result is the second argument subtracted from the first argument.
urn:oasis:names:tc:xacml:1.0:function:integer-multiplyThis function MUST accept two or more arguments.
urn:oasis:names:tc:xacml:1.0:function:double-multiplyThis function MUST accept two or more arguments.
urn:oasis:names:tc:xacml:1.0:function:integer-divideThe result is the first argument divided by the second argument.
urn:oasis:names:tc:xacml:1.0:function:double-divideThe result is the first argument divided by the second argument.
urn:oasis:names:tc:xacml:1.0:function:integer-modThe result is the remainder of the first argument divided by the second argument.
The following functions SHALL take a single argument of the specified
data-type. The round and floor functions SHALL take a single argument of
data-type https://www.w3.org/2001/XMLSchema#double and
return a value of the data-type
https://www.w3.org/2001/XMLSchema#double.
urn:oasis:names:tc:xacml:1.0:function:integer-abs
urn:oasis:names:tc:xacml:1.0:function:double-abs
urn:oasis:names:tc:xacml:1.0:function:round
urn:oasis:names:tc:xacml:1.0:function:floor
The following functions convert between values of the data-type
https://www.w3.org/2001/XMLSchema#string primitive
types.
urn:oasis:names:tc:xacml:1.0:function:string-normalize-spaceThis function SHALL take one argument of data-type
https://www.w3.org/2001/XMLSchema#string and SHALL
normalize the value by stripping off all leading and trailing white
space characters. The whitespace characters are defined in the
metasymbol S (Production 3) of [XML].
urn:oasis:names:tc:xacml:1.0:function:string-normalize-to-lower-caseThis function SHALL take one argument of data-type
https://www.w3.org/2001/XMLSchema#string and SHALL
normalize the value by converting each upper case character to its lower
case equivalent. Case mapping shall be done as specified for the
fn:lower-case function in [XF] with no tailoring for particular
languages or environments.
The following functions convert between the data-type
https://www.w3.org/2001/XMLSchema#integer
and https://www.w3.org/2001/XMLSchema#double primitive
types.
urn:oasis:names:tc:xacml:1.0:function:double-to-integerThis function SHALL take one argument of data-type
https://www.w3.org/2001/XMLSchema#double and SHALL truncate
its numeric value to a whole number and return an element of data-type
https://www.w3.org/2001/XMLSchema#integer.
urn:oasis:names:tc:xacml:1.0:function:integer-to-doubleThis function SHALL take one argument of data-type
https://www.w3.org/2001/XMLSchema#integer and SHALL promote
its value to an element of data-type
https://www.w3.org/2001/XMLSchema#double with the same
numeric value. If the integer argument is outside the range which can be
represented by a double, the result SHALL be Indeterminate, with the
status code
urn:oasis:names:tc:xacml:1.0:status:processing-error.
This section contains the specification for logical functions that
operate on arguments of data-type
https://www.w3.org/2001/XMLSchema#boolean.
urn:oasis:names:tc:xacml:1.0:function:orThis function SHALL return False if it has no arguments
and SHALL return True if at least one of its arguments
evaluates to True. The order of evaluation SHALL be from
first argument to last. The evaluation SHALL stop with a result of
True if any argument evaluates to True,
leaving the rest of the arguments unevaluated.
urn:oasis:names:tc:xacml:1.0:function:andThis function SHALL return True if it has no arguments
and SHALL return False if one of its arguments evaluates to
False. The order of evaluation SHALL be from first argument
to last. The evaluation SHALL stop with a result of False
if any argument evaluates to False, leaving the rest of the
arguments unevaluated.
urn:oasis:names:tc:xacml:1.0:function:n-ofThe first argument to this function SHALL be of data-type https://www.w3.org/2001/XMLSchema#integer.
The remaining arguments SHALL be of data-type https://www.w3.org/2001/XMLSchema#boolean.
The first argument specifies the minimum number of the remaining
arguments that MUST evaluate to True for the expression to
be considered True. If the first argument is 0, the result
SHALL be True. If the number of arguments after the first
one is less than the value of the first argument, then the expression
SHALL result in Indeterminate. The order of evaluation
SHALL be: first evaluate the integer value, and then evaluate each
subsequent argument. The evaluation SHALL stop and return
True if the specified number of arguments evaluate to
True. The evaluation of arguments SHALL stop if it is
determined that evaluating the remaining arguments will not satisfy the
requirement.
urn:oasis:names:tc:xacml:1.0:function:notThis function SHALL take one argument of data-type
https://www.w3.org/2001/XMLSchema#boolean. If the argument
evaluates to True, then the result of the expression SHALL
be False. If the argument evaluates to False,
then the result of the expression SHALL be True.
Note: When evaluating and, or, or n-of, it may not be necessary to
attempt a full evaluation of each argument in order to determine whether
the evaluation of the argument would result in
Indeterminate. Analysis of the argument regarding the
availability of its attributes, or other
analysis regarding errors, such as "divide-by-zero", may render the
argument error free. Such arguments occurring in the expression in a
position after the evaluation is stated to stop need not be
processed.
These functions form a minimal set for comparing two numbers, yielding a Boolean result. For doubles they SHALL comply with the rules governed by IEEE 754 [IEEE754].
urn:oasis:names:tc:xacml:1.0:function:integer-greater-than
urn:oasis:names:tc:xacml:1.0:function:integer-greater-than-or-equal
urn:oasis:names:tc:xacml:1.0:function:integer-less-than
urn:oasis:names:tc:xacml:1.0:function:integer-less-than-or-equal
urn:oasis:names:tc:xacml:1.0:function:double-greater-than
urn:oasis:names:tc:xacml:1.0:function:double-greater-than-or-equal
urn:oasis:names:tc:xacml:1.0:function:double-less-than
urn:oasis:names:tc:xacml:1.0:function:double-less-than-or-equal
These functions perform arithmetic operations with date and time.
urn:oasis:names:tc:xacml:3.0:function:dateTime-add-dayTimeDurationThis function SHALL take two arguments, the first SHALL be of data-type
https://www.w3.org/2001/XMLSchema#dateTime and the
second SHALL be of data-type
https://www.w3.org/2001/XMLSchema#dayTimeDuration. It
SHALL return a result of
https://www.w3.org/2001/XMLSchema#dateTime. This
function SHALL return the value by adding the second argument to the
first argument according to the specification of adding durations to
date and time [XS] Appendix E.
urn:oasis:names:tc:xacml:3.0:function:dateTime-add-yearMonthDurationThis function SHALL take two arguments, the first SHALL be a
https://www.w3.org/2001/XMLSchema#dateTime and the second
SHALL be a
https://www.w3.org/2001/XMLSchema#yearMonthDuration. It
SHALL return a result of
https://www.w3.org/2001/XMLSchema#dateTime. This function
SHALL return the value by adding the second argument to the first
argument according to the specification of adding durations to date and
time [XS] Appendix E.
urn:oasis:names:tc:xacml:3.0:function:dateTime-subtract-dayTimeDurationThis function SHALL take two arguments, the first SHALL be a
https://www.w3.org/2001/XMLSchema#dateTime and the second
SHALL be a
https://www.w3.org/2001/XMLSchema#dayTimeDuration. It SHALL
return a result of
https://www.w3.org/2001/XMLSchema#dateTime. If the second
argument is a positive duration, then this function SHALL return the
value by adding the corresponding negative duration, as per the
specification [XS] Appendix E. If the second argument is a negative
duration, then the result SHALL be as if the function
urn:oasis:names:tc:xacml:1.0:function:dateTime-add-dayTimeDuration
had been applied to the corresponding positive duration.
urn:oasis:names:tc:xacml:3.0:function:dateTime-subtract-yearMonthDurationThis function SHALL take two arguments, the first SHALL be a
https://www.w3.org/2001/XMLSchema#dateTime and the second
SHALL be a
https://www.w3.org/2001/XMLSchema#yearMonthDuration. It
SHALL return a result of
https://www.w3.org/2001/XMLSchema#dateTime. If the second
argument is a positive duration, then this function SHALL return the
value by adding the corresponding negative duration, as per the
specification [XS] Appendix E. If the second argument is a negative
duration, then the result SHALL be as if the function
urn:oasis:names:tc:xacml:1.0:function:dateTime-add-yearMonthDuration
had been applied to the corresponding positive duration.
urn:oasis:names:tc:xacml:3.0:function:date-add-yearMonthDurationThis function SHALL take two arguments, the first SHALL be a
https://www.w3.org/2001/XMLSchema#date and the second SHALL
be a https://www.w3.org/2001/XMLSchema#yearMonthDuration.
It SHALL return a result of
https://www.w3.org/2001/XMLSchema#date. This function SHALL
return the value by adding the second argument to the first argument
according to the specification of adding duration to date [XS] Appendix
E.
urn:oasis:names:tc:xacml:3.0:function:date-subtract-yearMonthDurationThis function SHALL take two arguments, the first SHALL be a
https://www.w3.org/2001/XMLSchema#date and the second SHALL
be a https://www.w3.org/2001/XMLSchema#yearMonthDuration.
It SHALL return a result of
https://www.w3.org/2001/XMLSchema#date. If the second
argument is a positive duration, then this function SHALL return the
value by adding the corresponding negative duration, as per the
specification [XS] Appendix E. If the second argument is a negative
duration, then the result SHALL be as if the function
urn:oasis:names:tc:xacml:1.0:function:date-add-yearMonthDuration
had been applied to the corresponding positive duration.
These functions perform comparison operations on two arguments of non-numerical types.
urn:oasis:names:tc:xacml:1.0:function:string-greater-thanThis function SHALL take two arguments of data-type
https://www.w3.org/2001/XMLSchema#string and SHALL return
an https://www.w3.org/2001/XMLSchema#boolean. It SHALL
return True if and only if the first argument is
lexicographically strictly greater than the second argument. Otherwise,
it SHALL return False. The comparison SHALL use Unicode
codepoint collation, as defined for the identifier
https://www.w3.org/2005/xpath-functions/collation/codepoint/
by [XF].
urn:oasis:names:tc:xacml:1.0:function:string-greater-than-or-equalThis function SHALL take two arguments of data-type
https://www.w3.org/2001/XMLSchema#string and SHALL return
an https://www.w3.org/2001/XMLSchema#boolean. It SHALL
return True if and only if the first argument is
lexicographically greater than or equal to the second argument.
Otherwise, it SHALL return False. The comparison SHALL use
Unicode codepoint collation, as defined for the identifier
https://www.w3.org/2005/xpath-functions/collation/codepoint/
by [XF].
urn:oasis:names:tc:xacml:1.0:function:string-less-thanThis function SHALL take two arguments of data-type
https://www.w3.org/2001/XMLSchema#string and SHALL return
an https://www.w3.org/2001/XMLSchema#boolean. It SHALL
return True if and only the first argument is
lexigraphically strictly less than the second argument. Otherwise, it
SHALL return False. The comparison SHALL use Unicode
codepoint collation, as defined for the identifier
https://www.w3.org/2005/xpath-functions/collation/codepoint/
by [XF].
urn:oasis:names:tc:xacml:1.0:function:string-less-than-or-equalThis function SHALL take two arguments of data-type
https://www.w3.org/2001/XMLSchema#string and SHALL return
an https://www.w3.org/2001/XMLSchema#boolean. It SHALL
return True if and only the first argument is
lexigraphically less than or equal to the second argument. Otherwise, it
SHALL return False. The comparison SHALL use Unicode
codepoint collation, as defined for the identifier
https://www.w3.org/2005/xpath-functions/collation/codepoint/
by [XF].
urn:oasis:names:tc:xacml:1.0:function:time-greater-thanThis function SHALL take two arguments of data-type
https://www.w3.org/2001/XMLSchema#time and SHALL return an
https://www.w3.org/2001/XMLSchema#boolean. It SHALL return
True if and only if the first argument is greater than the
second argument according to the order relation specified for
https://www.w3.org/2001/XMLSchema#time [XS] Section 3.2.8.
Otherwise, it SHALL return False. Note: it is illegal to
compare a time that includes a time-zone value with one that does not.
In such cases, the time-in-range function should be used.
urn:oasis:names:tc:xacml:1.0:function:time-greater-than-or-equalThis function SHALL take two arguments of data-type
https://www.w3.org/2001/XMLSchema#time and SHALL return an
https://www.w3.org/2001/XMLSchema#boolean. It SHALL return
True if and only if the first argument is greater than or
equal to the second argument according to the order relation specified
for https://www.w3.org/2001/XMLSchema#time [XS] Section
3.2.8. Otherwise, it SHALL return False. Note: it is
illegal to compare a time that includes a time-zone value with one that
does not. In such cases, the time-in-range function should be used.
urn:oasis:names:tc:xacml:1.0:function:time-less-thanThis function SHALL take two arguments of data-type
https://www.w3.org/2001/XMLSchema#time and SHALL return an
https://www.w3.org/2001/XMLSchema#boolean. It SHALL return
True if and only if the first argument is less than the
second argument according to the order relation specified for
https://www.w3.org/2001/XMLSchema#time [XS] Section 3.2.8.
Otherwise, it SHALL return False. Note: it is illegal to
compare a time that includes a time-zone value with one that does not.
In such cases, the time-in-range function should be used.
urn:oasis:names:tc:xacml:1.0:function:time-less-than-or-equalThis function SHALL take two arguments of data-type
https://www.w3.org/2001/XMLSchema#time and SHALL return an
https://www.w3.org/2001/XMLSchema#boolean. It SHALL return
True if and only if the first argument is less than or
equal to the second argument according to the order relation specified
for https://www.w3.org/2001/XMLSchema#time [XS] Section
3.2.8. Otherwise, it SHALL return False. Note: it is
illegal to compare a time that includes a time-zone value with one that
does not. In such cases, the time-in-range function should be used.
urn:oasis:names:tc:xacml:2.0:function:time-in-rangeThis function SHALL take three arguments of data-type
https://www.w3.org/2001/XMLSchema#time and SHALL return an
https://www.w3.org/2001/XMLSchema#boolean. It SHALL return
True if the first argument falls in the range defined
inclusively by the second and third arguments. Otherwise, it SHALL
return False. Regardless of its value, the third argument
SHALL be interpreted as a time that is equal to, or later than by less
than twenty-four hours, the second argument. If no time zone is provided
for the first argument, it SHALL use the default time zone at the
context handler. If no time zone is provided for the second or third
arguments, then they SHALL use the time zone from the first
argument.
urn:oasis:names:tc:xacml:1.0:function:dateTime-greater-thanThis function SHALL take two arguments of data-type
https://www.w3.org/2001/XMLSchema#dateTime and SHALL return
an https://www.w3.org/2001/XMLSchema#boolean. It SHALL
return True if and only if the first argument is greater
than the second argument according to the order relation specified for
https://www.w3.org/2001/XMLSchema#dateTime by [XS] part 2,
section 3.2.7. Otherwise, it SHALL return False. Note: if a
dateTime value does not include a time-zone value, then an implicit
time-zone value SHALL be assigned, as described in [XS].
urn:oasis:names:tc:xacml:1.0:function:dateTime-greater-than-or-equalThis function SHALL take two arguments of data-type
https://www.w3.org/2001/XMLSchema#dateTime and SHALL return
an https://www.w3.org/2001/XMLSchema#boolean. It SHALL
return True if and only if the first argument is greater
than or equal to the second argument according to the order relation
specified for https://www.w3.org/2001/XMLSchema#dateTime by
[XS] part 2, section 3.2.7. Otherwise, it SHALL return
False. Note: if a dateTime value does not include a
time-zone value, then an implicit time-zone value SHALL be assigned, as
described in [XS].
urn:oasis:names:tc:xacml:1.0:function:dateTime-less-thanThis function SHALL take two arguments of data-type
https://www.w3.org/2001/XMLSchema#dateTime and SHALL return
an https://www.w3.org/2001/XMLSchema#boolean. It SHALL
return True if and only if the first argument is less than
the second argument according to the order relation specified for
https://www.w3.org/2001/XMLSchema#dateTime by [XS, part 2,
section 3.2.7]. Otherwise, it SHALL return False. Note: if
a dateTime value does not include a time-zone value, then an implicit
time-zone value SHALL be assigned, as described in [XS].
urn:oasis:names:tc:xacml:1.0:function:dateTime-less-than-or-equalThis function SHALL take two arguments of data-type
https://www.w3.org/2001/XMLSchema# dateTime and SHALL
return an https://www.w3.org/2001/XMLSchema#boolean. It
SHALL return True if and only if the first argument is less
than or equal to the second argument according to the order relation
specified for https://www.w3.org/2001/XMLSchema#dateTime by
[XS] part 2, section 3.2.7. Otherwise, it SHALL return
False. Note: if a dateTime value does not include a
time-zone value, then an implicit time-zone value SHALL be assigned, as
described in [XS].
urn:oasis:names:tc:xacml:1.0:function:date-greater-thanThis function SHALL take two arguments of data-type
https://www.w3.org/2001/XMLSchema#date and SHALL return an
https://www.w3.org/2001/XMLSchema#boolean. It SHALL return
True if and only if the first argument is greater than the
second argument according to the order relation specified for
https://www.w3.org/2001/XMLSchema#date by [XS] part 2,
section 3.2.9. Otherwise, it SHALL return False. Note: if a
date value does not include a time-zone value, then an implicit
time-zone value SHALL be assigned, as described in [XS].
urn:oasis:names:tc:xacml:1.0:function:date-greater-than-or-equalThis function SHALL take two arguments of data-type
https://www.w3.org/2001/XMLSchema#date and SHALL return an
https://www.w3.org/2001/XMLSchema#boolean. It SHALL return
True if and only if the first argument is greater than or
equal to the second argument according to the order relation specified
for https://www.w3.org/2001/XMLSchema#date by [XS] part 2,
section 3.2.9. Otherwise, it SHALL return False. Note: if a
date value does not include a time-zone value, then an implicit
time-zone value SHALL be assigned, as described in [XS].
urn:oasis:names:tc:xacml:1.0:function:date-less-thanThis function SHALL take two arguments of data-type
https://www.w3.org/2001/XMLSchema#date and SHALL return an
https://www.w3.org/2001/XMLSchema#boolean. It SHALL return
True if and only if the first argument is less than the
second argument according to the order relation specified for
https://www.w3.org/2001/XMLSchema#date by [XS] part 2,
section 3.2.9. Otherwise, it SHALL return False. Note: if a
date value does not include a time-zone value, then an implicit
time-zone value SHALL be assigned, as described in [XS].
urn:oasis:names:tc:xacml:1.0:function:date-less-than-or-equalThis function SHALL take two arguments of data-type
https://www.w3.org/2001/XMLSchema#date and SHALL return an
https://www.w3.org/2001/XMLSchema#boolean. It SHALL return
True if and only if the first argument is less than or
equal to the second argument according to the order relation specified
for https://www.w3.org/2001/XMLSchema#date by [XS] part 2,
section 3.2.9. Otherwise, it SHALL return False. Note: if a
date value does not include a time-zone value, then an implicit
time-zone value SHALL be assigned, as described in [XS].
The following functions operate on strings and convert to and from other data types.
urn:oasis:names:tc:xacml:2.0:function:string-concatenateThis function SHALL take two or more arguments of data-type
https://www.w3.org/2001/XMLSchema#string and SHALL return a
https://www.w3.org/2001/XMLSchema#string. The result SHALL
be the concatenation, in order, of the arguments.
urn:oasis:names:tc:xacml:3.0:function:boolean-from-stringThis function SHALL take one argument of data-type
https://www.w3.org/2001/XMLSchema#string, and SHALL return
an https://www.w3.org/2001/XMLSchema#boolean. The result
SHALL be the string converted to a boolean. If the argument is not a
valid lexical representation of a boolean, then the result SHALL be
Indeterminate with status code
urn:oasis:names:tc:xacml:1.0:status:syntax-error.
urn:oasis:names:tc:xacml:3.0:function:string-from-booleanThis function SHALL take one argument of data-type
https://www.w3.org/2001/XMLSchema#boolean, and SHALL return
an https://www.w3.org/2001/XMLSchema#string. The result
SHALL be the boolean converted to a string in the canonical form
specified in [XS].
urn:oasis:names:tc:xacml:3.0:function:integer-from-stringThis function SHALL take one argument of data-type
https://www.w3.org/2001/XMLSchema#string, and SHALL return
an https://www.w3.org/2001/XMLSchema#integer. The result
SHALL be the string converted to an integer. If the argument is not a
valid lexical representation of an integer, then the result SHALL be
Indeterminate with status code
urn:oasis:names:tc:xacml:1.0:status:syntax-error.
urn:oasis:names:tc:xacml:3.0:function:string-from-integerThis function SHALL take one argument of data-type
https://www.w3.org/2001/XMLSchema#integer, and SHALL return
an https://www.w3.org/2001/XMLSchema#string. The result
SHALL be the integer converted to a string in the canonical form
specified in [XS].
urn:oasis:names:tc:xacml:3.0:function:double-from-stringThis function SHALL take one argument of data-type
https://www.w3.org/2001/XMLSchema#string, and SHALL return
an https://www.w3.org/2001/XMLSchema#double. The result
SHALL be the string converted to a double. If the argument is not a
valid lexical representation of a double, then the result SHALL be
Indeterminate with status code
urn:oasis:names:tc:xacml:1.0:status:syntax-error.
urn:oasis:names:tc:xacml:3.0:function:string-from-doubleThis function SHALL take one argument of data-type
https://www.w3.org/2001/XMLSchema#double, and SHALL return
an https://www.w3.org/2001/XMLSchema#string. The result
SHALL be the double converted to a string in the canonical form
specified in [XS].
urn:oasis:names:tc:xacml:3.0:function:time-from-stringThis function SHALL take one argument of data-type
https://www.w3.org/2001/XMLSchema#string, and SHALL return
an https://www.w3.org/2001/XMLSchema#time. The result SHALL
be the string converted to a time. If the argument is not a valid
lexical representation of a time, then the result SHALL be Indeterminate
with status code
urn:oasis:names:tc:xacml:1.0:status:syntax-error.
urn:oasis:names:tc:xacml:3.0:function:string-from-timeThis function SHALL take one argument of data-type
https://www.w3.org/2001/XMLSchema#time, and SHALL return an
https://www.w3.org/2001/XMLSchema#string. The result SHALL
be the time converted to a string in the canonical form specified in
[XS].
urn:oasis:names:tc:xacml:3.0:function:date-from-stringThis function SHALL take one argument of data-type
https://www.w3.org/2001/XMLSchema#string, and SHALL return
an https://www.w3.org/2001/XMLSchema#date. The result SHALL
be the string converted to a date. If the argument is not a valid
lexical representation of a date, then the result SHALL be Indeterminate
with status code
urn:oasis:names:tc:xacml:1.0:status:syntax-error.
urn:oasis:names:tc:xacml:3.0:function:string-from-dateThis function SHALL take one argument of data-type
https://www.w3.org/2001/XMLSchema#date, and SHALL return an
https://www.w3.org/2001/XMLSchema#string. The result SHALL
be the date converted to a string in the canonical form specified in
[XS].
urn:oasis:names:tc:xacml:3.0:function:dateTime-from-stringThis function SHALL take one argument of data-type
https://www.w3.org/2001/XMLSchema#string, and SHALL return
an https://www.w3.org/2001/XMLSchema#dateTime. The result
SHALL be the string converted to a dateTime. If the argument is not a
valid lexical representation of a dateTime, then the result SHALL be
Indeterminate with status code
urn:oasis:names:tc:xacml:1.0:status:syntax-error.
urn:oasis:names:tc:xacml:3.0:function:string-from-dateTimeThis function SHALL take one argument of data-type
https://www.w3.org/2001/XMLSchema#dateTime, and SHALL
return an https://www.w3.org/2001/XMLSchema#string. The
result SHALL be the dateTime converted to a string in the canonical form
specified in [XS].
urn:oasis:names:tc:xacml:3.0:function:anyURI-from-stringThis function SHALL take one argument of data-type
https://www.w3.org/2001/XMLSchema#string, and SHALL return
a https://www.w3.org/2001/XMLSchema#anyURI. The result
SHALL be the URI constructed by converting the argument to an URI. If
the argument is not a valid lexical representation of a URI, then the
result SHALL be Indeterminate with status code
urn:oasis:names:tc:xacml:1.0:status:syntax-error.
urn:oasis:names:tc:xacml:3.0:function:string-from-anyURIThis function SHALL take one argument of data-type
https://www.w3.org/2001/XMLSchema#anyURI, and SHALL return
an https://www.w3.org/2001/XMLSchema#string. The result
SHALL be the URI converted to a string in the form it was originally
represented in XML form.
urn:oasis:names:tc:xacml:3.0:function:dayTimeDuration-from-stringThis function SHALL take one argument of data-type
https://www.w3.org/2001/XMLSchema#string, and SHALL return
an https://www.w3.org/2001/XMLSchema#dayTimeDuration . The
result SHALL be the string converted to a dayTimeDuration. If the
argument is not a valid lexical representation of a dayTimeDuration,
then the result SHALL be Indeterminate with status code
urn:oasis:names:tc:xacml:1.0:status:syntax-error.
urn:oasis:names:tc:xacml:3.0:function:string-from-dayTimeDurationThis function SHALL take one argument of data-type
https://www.w3.org/2001/XMLSchema#dayTimeDuration, and
SHALL return an https://www.w3.org/2001/XMLSchema#string.
The result SHALL be the dayTimeDuration converted to a string in the
canonical form specified in [XPathFunc].
urn:oasis:names:tc:xacml:3.0:function:yearMonthDuration-from-stringThis function SHALL take one argument of data-type
https://www.w3.org/2001/XMLSchema#string, and SHALL return
an https://www.w3.org/2001/XMLSchema#yearMonthDuration. The
result SHALL be the string converted to a yearMonthDuration. If the
argument is not a valid lexical representation of a yearMonthDuration,
then the result SHALL be Indeterminate with status code
urn:oasis:names:tc:xacml:1.0:status:syntax-error.
urn:oasis:names:tc:xacml:3.0:function:string-from-yearMonthDurationThis function SHALL take one argument of data-type
https://www.w3.org/2001/XMLSchema#yearMonthDuration, and
SHALL return an https://www.w3.org/2001/XMLSchema#string.
The result SHALL be the yearMonthDuration converted to a string in the
canonical form specified in [XPathFunc].
urn:oasis:names:tc:xacml:3.0:function:x500Name-from-stringThis function SHALL take one argument of data-type
https://www.w3.org/2001/XMLSchema#string, and SHALL return
an urn:oasis:names:tc:xacml:1.0:data-type:x500Name. The
result SHALL be the string converted to an x500Name. If the argument is
not a valid lexical representation of a X500Name, then the result SHALL
be Indeterminate with status code
urn:oasis:names:tc:xacml:1.0:status:syntax-error.
urn:oasis:names:tc:xacml:3.0:function:string-from-x500NameThis function SHALL take one argument of data-type
urn:oasis:names:tc:xacml:1.0:data-type:x500Name, and SHALL
return an https://www.w3.org/2001/XMLSchema#string. The
result SHALL be the x500Name converted to a string in the form it was
originally represented in XML form..
urn:oasis:names:tc:xacml:3.0:function:rfc822Name-from-stringThis function SHALL take one argument of data-type
https://www.w3.org/2001/XMLSchema#string, and SHALL return
an urn:oasis:names:tc:xacml:1.0:data-type:rfc822Name. The
result SHALL be the string converted to an rfc822Name. If the argument
is not a valid lexical representation of an rfc822Name, then the result
SHALL be Indeterminate with status code
urn:oasis:names:tc:xacml:1.0:status:syntax-error.
urn:oasis:names:tc:xacml:3.0:function:string-from-rfc822NameThis function SHALL take one argument of data-type
urn:oasis:names:tc:xacml:1.0:data-type:rfc822Name, and
SHALL return an https://www.w3.org/2001/XMLSchema#string.
The result SHALL be the rfc822Name converted to a string in the form it
was originally represented in XML form.
urn:oasis:names:tc:xacml:3.0:function:ipAddress-from-stringThis function SHALL take one argument of data-type
https://www.w3.org/2001/XMLSchema#string, and SHALL return
an urn:oasis:names:tc:xacml:2.0:data-type:ipAddress. The
result SHALL be the string converted to an ipAddress. If the argument is
not a valid lexical representation of an ipAddress, then the result
SHALL be Indeterminate with status code
urn:oasis:names:tc:xacml:1.0:status:syntax-error.
urn:oasis:names:tc:xacml:3.0:function:string-from-ipAddressThis function SHALL take one argument of data-type
urn:oasis:names:tc:xacml:2.0:data-type:ipAddress, and SHALL
return an https://www.w3.org/2001/XMLSchema#string. The
result SHALL be the ipAddress converted to a string in the form it was
originally represented in XML form.
urn:oasis:names:tc:xacml:3.0:function:dnsName-from-stringThis function SHALL take one argument of data-type
https://www.w3.org/2001/XMLSchema#string, and SHALL return
an urn:oasis:names:tc:xacml:2.0:data-type:dnsName. The
result SHALL be the string converted to a dnsName. If the argument is
not a valid lexical representation of a dnsName, then the result SHALL
be Indeterminate with status code
urn:oasis:names:tc:xacml:1.0:status:syntax-error.
urn:oasis:names:tc:xacml:3.0:function:string-from-dnsNameThis function SHALL take one argument of data-type
urn:oasis:names:tc:xacml:2.0:data-type:dnsName, and SHALL
return an https://www.w3.org/2001/XMLSchema#string. The
result SHALL be the dnsName converted to a string in the form it was
originally represented in XML form.
urn:oasis:names:tc:xacml:3.0:function:string-starts-withThis function SHALL take two arguments of data-type
https://www.w3.org/2001/XMLSchema#string and SHALL return a
https://www.w3.org/2001/XMLSchema#boolean. The result SHALL
be true if the second string begins with the first string, and false
otherwise. Equality testing SHALL be done as defined for
urn:oasis:names:tc:xacml:1.0:function:string-equal.
urn:oasis:names:tc:xacml:3.0:function:anyURI-starts-withThis function SHALL take a first argument of
data-typehttps://www.w3.org/2001/XMLSchema#string and an a
second argument of data-type
https://www.w3.org/2001/XMLSchema#anyURI and SHALL return a
https://www.w3.org/2001/XMLSchema#boolean. The result SHALL
be true if the URI converted to a string with
urn:oasis:names:tc:xacml:3.0:function:string-from-anyURI
begins with the string, and false otherwise. Equality testing SHALL be
done as defined for
urn:oasis:names:tc:xacml:1.0:function:string-equal.
urn:oasis:names:tc:xacml:3.0:function:string-ends-withThis function SHALL take two arguments of data-type
https://www.w3.org/2001/XMLSchema#string and SHALL return a
https://www.w3.org/2001/XMLSchema#boolean. The result SHALL
be true if the second string ends with the first string, and false
otherwise. Equality testing SHALL be done as defined for
urn:oasis:names:tc:xacml:1.0:function:string-equal.
urn:oasis:names:tc:xacml:3.0:function:anyURI-ends-withThis function SHALL take a first argument of data-type
https://www.w3.org/2001/XMLSchema#string and an a second
argument of data-type
https://www.w3.org/2001/XMLSchema#anyURI and SHALL return a
https://www.w3.org/2001/XMLSchema#boolean. The result SHALL
be true if the URI converted to a string with
urn:oasis:names:tc:xacml:3.0:function:string-from-anyURI
ends with the string, and false otherwise. Equality testing SHALL be
done as defined for
urn:oasis:names:tc:xacml:1.0:function:string-equal.
urn:oasis:names:tc:xacml:3.0:function:string-containsThis function SHALL take two arguments of data-type
https://www.w3.org/2001/XMLSchema#string and SHALL return a
https://www.w3.org/2001/XMLSchema#boolean. The result SHALL
be true if the second string contains the first string, and false
otherwise. Equality testing SHALL be done as defined for
urn:oasis:names:tc:xacml:1.0:function:string-equal.
urn:oasis:names:tc:xacml:3.0:function:anyURI-containsThis function SHALL take a first argument of data-type
https://www.w3.org/2001/XMLSchema#string and an a second
argument of data-type
https://www.w3.org/2001/XMLSchema#anyURI and SHALL return a
https://www.w3.org/2001/XMLSchema#boolean. The result SHALL
be true if the URI converted to a string with
urn:oasis:names:tc:xacml:3.0:function:string-from-anyURI
contains the string, and false otherwise. Equality testing SHALL be done
as defined for
urn:oasis:names:tc:xacml:1.0:function:string-equal.
urn:oasis:names:tc:xacml:3.0:function:string-substringThis function SHALL take a first argument of data-type
https://www.w3.org/2001/XMLSchema#string and a second and a
third argument of type
https://www.w3.org/2001/XMLSchema#integer and SHALL return
a https://www.w3.org/2001/XMLSchema#string. The result
SHALL be the substring of the first argument beginning at the position
given by the second argument and ending at the position before the
position given by the third argument. The first character of the string
has position zero. The negative integer value -1 given for the third
arguments indicates the end of the string. If the second or third
arguments are out of bounds, then the function MUST evaluate to
Indeterminate with a status code of
urn:oasis:names:tc:xacml:1.0:status:processing-error.
urn:oasis:names:tc:xacml:3.0:function:anyURI-substringThis function SHALL take a first argument of data-type
https://www.w3.org/2001/XMLSchema#anyURI and a second and a
third argument of type
https://www.w3.org/2001/XMLSchema#integer and SHALL return
a https://www.w3.org/2001/XMLSchema#string. The result
SHALL be the substring of the first argument converted to a string with
urn:oasis:names:tc:xacml:3.0:function:string-from-anyURI
beginning at the position given by the second argument and ending at the
position before the position given by the third argument. The first
character of the URI converted to a string has position zero. The
negative integer value -1 given for the third arguments indicates the
end of the string. If the second or third arguments are out of bounds,
then the function MUST evaluate to Indeterminate with a status code of
urn:oasis:names:tc:xacml:1.0:status:processing-error. If
the resulting substring is not syntactically a valid URI, then the
function MUST evaluate to Indeterminate with a status code of
urn:oasis:names:tc:xacml:1.0:status:processing-error.
These functions operate on a bag of
type values, where type is one of the primitive data-types,
and x.x is a version of XACML where the function has been defined. Some
additional conditions defined for each function below SHALL cause the
expression to evaluate to Indeterminate.
urn:oasis:names:tc:xacml:x.x:function:type-one-and-onlyThis function SHALL take a bag of
type values as an argument and SHALL return a value of
type. It SHALL return the only value in the
bag. If the bag does
not have one and only one value, then the expression SHALL evaluate to
Indeterminate.
urn:oasis:names:tc:xacml:x.x:function:type-bag-sizeThis function SHALL take a bag of
type values as an argument and SHALL return an
https://www.w3.org/2001/XMLSchema#integer indicating the
number of values in the bag.
urn:oasis:names:tc:xacml:x.x:function:type-is-inThis function SHALL take an argument of type as the
first argument and a bag of type
values as the second argument and SHALL return an
https://www.w3.org/2001/XMLSchema#boolean. The function
SHALL evaluate to True if and only if the first argument
matches by the
urn:oasis:names:tc:xacml:x.x:function:type-equal any
value in the bag. Otherwise, it SHALL return
False.
urn:oasis:names:tc:xacml:x.x:function:type-bagThis function SHALL take any number of arguments of type
and return a bag of type values
containing the values of the arguments. An application of this function
to zero arguments SHALL produce an empty bag
of the specified data-type.
These functions operate on bags mimicking sets by eliminating duplicate elements from a bag.
urn:oasis:names:tc:xacml:x.x:function:type-intersectionThis function SHALL take two arguments that are both a
bag of type values. It SHALL
return a bag of type values such
that it contains only elements that are common between the two
bags, which is determined by
urn:oasis:names:tc:xacml:x.x:function:type-equal. No
duplicates, as determined by
urn:oasis:names:tc:xacml:x.x:function:type-equal, SHALL
exist in the result.
urn:oasis:names:tc:xacml:x.x:function:type-at-least-one-member-ofThis function SHALL take two arguments that are both a
bag of type values. It SHALL
return a https://www.w3.org/2001/XMLSchema#boolean. The
function SHALL evaluate to True if and only if at least one
element of the first argument is contained in the second argument as
determined by
urn:oasis:names:tc:xacml:x.x:function:type-is-in.
urn:oasis:names:tc:xacml:x.x:function:type-unionThis function SHALL take two or more arguments that are both a
bag of type values. The
expression SHALL return a bag of
type such that it contains all elements of all the argument
bags. No duplicates, as determined by
urn:oasis:names:tc:xacml:x.x:function:type-equal, SHALL
exist in the result.
urn:oasis:names:tc:xacml:x.x:function:type-subsetThis function SHALL take two arguments that are both a
bag of type values. It SHALL
return a https://www.w3.org/2001/XMLSchema#boolean. It
SHALL return True if and only if the first argument is a
subset of the second argument. Each argument SHALL be considered to have
had its duplicates removed, as determined by
urn:oasis:names:tc:xacml:x.x:function:type-equal, before
the subset calculation.
urn:oasis:names:tc:xacml:x.x:function:type-set-equalsThis function SHALL take two arguments that are both a
bag of type values. It SHALL
return a https://www.w3.org/2001/XMLSchema#boolean. It
SHALL return the result of applying
urn:oasis:names:tc:xacml:1.0:function:and to the
application of
: urn:oasis:names:tc:xacml:x.x:function:type-subset to
the first and second arguments and the application of
urn:oasis:names:tc:xacml:x.x:function:type-subset to the
second and first arguments.
This section describes functions in XACML that perform operations on bags such that functions may be applied to the bags in general.
urn:oasis:names:tc:xacml:3.0:function:any-of
This function applies a Boolean function between specific primitive
values and a bag of values, and SHALL return
True if and only if the predicate is True for
at least one element of the bag.
This function SHALL take n+1 arguments, where n is one or greater.
The first argument SHALL be an <Function> element
that names a Boolean function that takes n arguments of primitive types.
Under the remaining n arguments, n-1 parameters SHALL be values of
primitive data-types and one SHALL be a bag of
a primitive data-type. The expression SHALL be evaluated as if the
function named in the <Function> argument were
applied to the n-1 non-bag arguments and each element of the
bag argument and the results are combined with
urn:oasis:names:tc:xacml:1.0:function:or.
For example, the following expression SHALL return
True:
<Apply FunctionId="urn:oasis:names:tc:xacml:3.0:function:any-of">
<Function FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-equal"/>
<AttributeValue
DataType="https://www.w3.org/2001/XMLSchema#string">Paul</AttributeValue>
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-bag">
<AttributeValue
DataType="https://www.w3.org/2001/XMLSchema#string">John</AttributeValue>
<AttributeValue
DataType="https://www.w3.org/2001/XMLSchema#string">Paul</AttributeValue>
<AttributeValue
DataType="https://www.w3.org/2001/XMLSchema#string">George</AttributeValue>
<AttributeValue
DataType="https://www.w3.org/2001/XMLSchema#string">Ringo</AttributeValue>
</Apply>
</Apply>True because the first argument is equal
to at least one of the elements of the bag,
according to the function.
urn:oasis:names:tc:xacml:3.0:function:all-of
This function applies a Boolean function between a specific primitive
value and a bag of values, and returns
True if and only if the predicate is True for
every element of the bag.
This function SHALL take n+1 arguments, where n is one or greater.
The first argument SHALL be a <Function> element that
names a Boolean function that takes n arguments of primitive types.
Under the remaining n arguments, n-1 parameters SHALL be values of
primitive data-types and one SHALL be a bag of
a primitive data-type. The expression SHALL be evaluated as if the
function named in the <Function> argument were
applied to the n-1 non-bag arguments and each element of the
bag argument and the results are combined with
urn:oasis:names:tc:xacml:1.0:function:and.
For example, the following expression SHALL evaluate to
True:
<Apply FunctionId="urn:oasis:names:tc:xacml:3.0:function:all-of">
<Function FunctionId="urn:oasis:names:tc:xacml:2.0:function:integer-greater-than"/>
<AttributeValue DataType="https://www.w3.org/2001/XMLSchema#integer">10</AttributeValue>
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:integer-bag">
<AttributeValue DataType="https://www.w3.org/2001/XMLSchema#integer">9</AttributeValue>
<AttributeValue DataType="https://www.w3.org/2001/XMLSchema#integer">3</AttributeValue>
<AttributeValue DataType="https://www.w3.org/2001/XMLSchema#integer">4</AttributeValue>
<AttributeValue DataType="https://www.w3.org/2001/XMLSchema#integer">2</AttributeValue>
</Apply>
</Apply>True because the first argument (10) is
greater than all of the elements of the bag
(9,3,4 and 2).
urn:oasis:names:tc:xacml:3.0:function:any-of-any
This function applies a Boolean function on each tuple from the cross
product on all bags arguments, and returns
True if and only if the predicate is True for
at least one inside-function call.
This function SHALL take n+1 arguments, where n is one or greater.
The first argument SHALL be an <Function> element
that names a Boolean function that takes n arguments. The remaining
arguments are either primitive data types or
bags of primitive types. The expression SHALL
be evaluated as if the function named in the
<Function> argument was applied between every tuple
of the cross product on all bags and the
primitive values, and the results were combined using
urn:oasis:names:tc:xacml:1.0:function:or. The semantics are
that the result of the expression SHALL be True if and only
if the applied predicate is True for at least one function
call on the tuples from the bags and primitive
values.
For example, the following expression SHALL evaluate to
True:
<Apply FunctionId="urn:oasis:names:tc:xacml:3.0:function:any-of-any">
<Function FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-equal"/>
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-bag">
<AttributeValue DataType="https://www.w3.org/2001/XMLSchema#string">Ringo</AttributeValue>
<AttributeValue DataType="https://www.w3.org/2001/XMLSchema#string">Mary</AttributeValue>
</Apply>
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-bag">
<AttributeValue DataType="https://www.w3.org/2001/XMLSchema#string">John</AttributeValue>
<AttributeValue DataType="https://www.w3.org/2001/XMLSchema#string">Paul</AttributeValue>
<AttributeValue DataType="https://www.w3.org/2001/XMLSchema#string">George</AttributeValue>
<AttributeValue DataType="https://www.w3.org/2001/XMLSchema#string">Ringo</AttributeValue>
</Apply>
</Apply>True because at least one of the elements
of the first bag, namely Ringo,
is equal to at least one of the elements of the second
bag.
urn:oasis:names:tc:xacml:1.0:function:all-of-any
This function applies a Boolean function between the elements of two
bags. The expression SHALL be
True if and only if the supplied predicate is
True between each element of the first
bag and any element of the second
bag.
This function SHALL take three arguments. The first argument SHALL be
an <Function> element that names a Boolean function
that takes two arguments of primitive types. The second argument SHALL
be a bag of a primitive data-type. The third
argument SHALL be a bag of a primitive
data-type. The expression SHALL be evaluated as if the
urn:oasis:names:tc:xacml:3.0:function:any-of function had
been applied to each value of the first bag
and the whole of the second bag using the
supplied xacml:Function, and the results were then combined using
urn:oasis:names:tc:xacml:1.0:function:and.
For example, the following expression SHALL evaluate to
True:
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:all-of-any">
<Function FunctionId="urn:oasis:names:tc:xacml:2.0:function:integer-greater-than"/>
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:integer-bag">
<AttributeValue DataType="https://www.w3.org/2001/XMLSchema#integer">10</AttributeValue>
<AttributeValue DataType="https://www.w3.org/2001/XMLSchema#integer">20</AttributeValue>
</Apply>
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:integer-bag">
<AttributeValue DataType="https://www.w3.org/2001/XMLSchema#integer">1</AttributeValue>
<AttributeValue DataType="https://www.w3.org/2001/XMLSchema#integer">3</AttributeValue>
<AttributeValue DataType="https://www.w3.org/2001/XMLSchema#integer">5</AttributeValue>
<AttributeValue DataType="https://www.w3.org/2001/XMLSchema#integer">19</AttributeValue>
</Apply>
</Apply>True because each of the elements of the
first bag is greater than at least one of the
elements of the second bag.
urn:oasis:names:tc:xacml:1.0:function:any-of-all
This function applies a Boolean function between the elements of two
bags. The expression SHALL be
True if and only if the supplied predicate is
True between each element of the second
bag and any element of the first
bag.
This function SHALL take three arguments. The first argument SHALL be
an <Function> element that names a Boolean function
that takes two arguments of primitive types. The second argument SHALL
be a bag of a primitive data-type. The third
argument SHALL be a bag of a primitive
data-type. The expression SHALL be evaluated as if the
urn:oasis:names:tc:xacml:3.0:function:any-of function had
been applied to each value of the second bag
and the whole of the first _bag** using the
supplied xacml:Function, and the results were then combined using
urn:oasis:names:tc:xacml:1.0:function:and.
For example, the following expression SHALL evaluate to
True:
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:any-of-all">
<Function FunctionId="urn:oasis:names:tc:xacml:2.0:function:integer-greater-than"/>
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:fu`nction:integer-bag">
<AttributeValue DataType="https://www.w3.org/2001/XMLSchema#integer">3</AttributeValue>
<AttributeValue DataType="https://www.w3.org/2001/XMLSchema#integer">5</AttributeValue>
</Apply>
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:integer-bag">
<AttributeValue DataType="https://www.w3.org/2001/XMLSchema#integer">1</AttributeValue>
<AttributeValue DataType="https://www.w3.org/2001/XMLSchema#integer">2</AttributeValue>
<AttributeValue DataType="https://www.w3.org/2001/XMLSchema#integer">3</AttributeValue>
<AttributeValue DataType="https://www.w3.org/2001/XMLSchema#integer">4</AttributeValue>
</Apply>
</Apply>True because, for all of the values in
the second bag, there is a value in the first
bag that is greater.
urn:oasis:names:tc:xacml:1.0:function:all-of-all
This function applies a Boolean function between the elements of two
bags. The expression SHALL be
True if and only if the supplied predicate is
True between each and every element of the first
bag collectively against all the elements of
the second bag.
This function SHALL take three arguments. The first argument SHALL be
an <Function> element that names a Boolean function
that takes two arguments of primitive types. The second argument SHALL
be a bag of a primitive data-type. The third
argument SHALL be a bag of a primitive
data-type. The expression is evaluated as if the function named in the
<Function> element were applied between every element
of the second argument and every element of the third argument and the
results were combined using
urn:oasis:names:tc:xacml:1.0:function:and. The semantics
are that the result of the expression is True if and only
if the applied predicate is True for all elements of the
first bag compared to all the elements of the
second bag.
For example, the following expression SHALL evaluate to
True:
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:all-of-all">
<Function FunctionId="urn:oasis:names:tc:xacml:2.0:function:integer-greater-than"/>
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:integer-bag">
<AttributeValue DataType="https://www.w3.org/2001/XMLSchema#integer">6</AttributeValue>
<AttributeValue DataType="https://www.w3.org/2001/XMLSchema#integer">5</AttributeValue>
</Apply>
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:integer-bag">
<AttributeValue DataType="https://www.w3.org/2001/XMLSchema#integer">1</AttributeValue>
<AttributeValue DataType="https://www.w3.org/2001/XMLSchema#integer">2</AttributeValue>
<AttributeValue DataType="https://www.w3.org/2001/XMLSchema#integer">3</AttributeValue>
<AttributeValue DataType="https://www.w3.org/2001/XMLSchema#integer">4</AttributeValue>
</Apply>
</Apply>True because all elements of the first
bag, 5 and 6, are
each greater than all of the integer values 1,
2, 3, 4 of the second
bag.
urn:oasis:names:tc:xacml:3.0:function:map
This function converts a bag of values to another bag of values.
This function SHALL take n+1 arguments, where n is one or greater.
The first argument SHALL be a <Function> element
naming a function that takes a n arguments of a primitive data-type and
returns a value of a primitive data-type Under the remaining n
arguments, n-1 parameters SHALL be values of primitive data-types and
one SHALL be a bag of a primitive data-type.
The expression SHALL be evaluated as if the function named in the
<Function> argument were applied to the n-1 non-bag
arguments and each element of the bag argument
and resulting in a bag of the converted value.
The result SHALL be a bag of the primitive
data-type that is returned by the function named in the
<xacml:Function> element.
For example, the following expression,
<Apply FunctionId="urn:oasis:names:tc:xacml:3.0:function:map">
<Function FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-normalize-to-lower-case">
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-bag">
<AttributeValue DataType="https://www.w3.org/2001/XMLSchema#string">Hello</AttributeValue>
<AttributeValue DataType="https://www.w3.org/2001/XMLSchema#string">World!</AttributeValue>
</Apply>
</Apply>hello and world!.
These functions operate on various types using regular expressions and evaluate to
https://www.w3.org/2001/XMLSchema#boolean.
urn:oasis:names:tc:xacml:1.0:function:string-regexp-match
This function decides a regular expression match. It SHALL take two arguments of
https://www.w3.org/2001/XMLSchema#string and SHALL
return an https://www.w3.org/2001/XMLSchema#boolean. The
first argument SHALL be a regular expression and the second argument
SHALL be a general string. The function specification SHALL be that of
the xf:matches function with the arguments reversed [XF]
Section 7.6.2.
urn:oasis:names:tc:xacml:2.0:function:anyURI-regexp-match
This function decides a regular expression match. It SHALL take two
arguments; the first is of type
https://www.w3.org/2001/XMLSchema#string and the second is
of type
https://www.w3.org/2001/XMLSchema#anyURI. It SHALL
return an
https://www.w3.org/2001/XMLSchema#boolean. The first
argument SHALL be a regular expression and the second argument SHALL be
a URI. The function SHALL convert the second argument to type
https://www.w3.org/2001/XMLSchema#string with
urn:oasis:names:tc:xacml:3.0:function:string-from-anyURI,
then apply
urn:oasis:names:tc:xacml:1.0:function:string-regexp-match.
urn:oasis:names:tc:xacml:2.0:function:ipAddress-regexp-match
This function decides a regular expression match. It SHALL take two
arguments; the first is of type
https://www.w3.org/2001/XMLSchema#string and the second is
of type
urn:oasis:names:tc:xacml:2.0:data-type:ipAddress. It
SHALL return an
https://www.w3.org/2001/XMLSchema#boolean. The first
argument SHALL be a regular expression and the second argument SHALL be
an IPv4 or IPv6 address. The function SHALL convert the second argument
to type https://www.w3.org/2001/XMLSchema#string with
urn:oasis:names:tc:xacml:3.0:function:string-from-ipAddress,
then apply
urn:oasis:names:tc:xacml:1.0:function:string-regexp-match.
urn:oasis:names:tc:xacml:2.0:function:dnsName-regexp-match
This function decides a regular expression match. It SHALL take two
arguments; the first is of type
https://www.w3.org/2001/XMLSchema#string and the second is
of type
urn:oasis:names:tc:xacml:2.0:data-type:dnsName. It SHALL
return an
https://www.w3.org/2001/XMLSchema#boolean. The first
argument SHALL be a regular expression and the second argument SHALL be
a DNS name. The function SHALL convert the second argument to type
https://www.w3.org/2001/XMLSchema#string with
urn:oasis:names:tc:xacml:3.0:function:string-from-dnsName,
then apply
urn:oasis:names:tc:xacml:1.0:function:string-regexp-match.
urn:oasis:names:tc:xacml:2.0:function:rfc822Name-regexp-match
This function decides a regular expression match. It SHALL take two
arguments; the first is of type
https://www.w3.org/2001/XMLSchema#string and the second is
of type
urn:oasis:names:tc:xacml:1.0:data-type:rfc822Name. It
SHALL return an
https://www.w3.org/2001/XMLSchema#boolean. The first
argument SHALL be a regular expression and the second argument SHALL be
an RFC 822 name. The function SHALL convert the second argument to type
https://www.w3.org/2001/XMLSchema#string with
urn:oasis:names:tc:xacml:3.0:function:string-from-rfc822Name,
then apply
urn:oasis:names:tc:xacml:1.0:function:string-regexp-match.
urn:oasis:names:tc:xacml:2.0:function:x500Name-regexp-match
This function decides a regular expression match. It SHALL take two
arguments; the first is of type
https://www.w3.org/2001/XMLSchema#string and the second is
of type
urn:oasis:names:tc:xacml:1.0:data-type:x500Name. It
SHALL return an
https://www.w3.org/2001/XMLSchema#boolean. The first
argument SHALL be a regular expression and the second argument SHALL be
an X.500 directory name. The function SHALL convert the second argument
to type https://www.w3.org/2001/XMLSchema#string with
urn:oasis:names:tc:xacml:3.0:function:string-from-x500Name,
then apply
urn:oasis:names:tc:xacml:1.0:function:string-regexp-match.
These functions operate on various types and evaluate to
https://www.w3.org/2001/XMLSchema#boolean based on the
specified standard matching algorithm.
urn:oasis:names:tc:xacml:1.0:function:x500Name-matchThis function shall take two arguments of
urn:oasis:names:tc:xacml:1.0:data-type:x500Name and shall
return an https://www.w3.org/2001/XMLSchema#boolean. It
shall return True if and only if the first argument matches
some terminal sequence of RDNs from the second argument when compared
using x500Name-equal.
As an example (non-normative), if the first argument is
O=Medico Corp,C=US and the second argument is
cn=John Smith,o=Medico Corp, c=US, then the function will
return True.
urn:oasis:names:tc:xacml:1.0:function:rfc822Name-matchThis function SHALL take two arguments, the first is of data-type
https://www.w3.org/2001/XMLSchema#string and the second is
of data-type
urn:oasis:names:tc:xacml:1.0:data-type:rfc822Name and SHALL
return an https://www.w3.org/2001/XMLSchema#boolean. This
function SHALL evaluate to True if the first argument
matches the second argument according to the following
specification.
An RFC822 name consists of a local-part followed by @
followed by a domain-part. The local-part is case-sensitive, while the
domain-part (which is usually a DNS name) is not case-sensitive.
The second argument contains a complete rfc822Name. The first argument is a complete or partial rfc822Name used to select appropriate values in the second argument as follows.
In order to match a particular address in the second argument, the
first argument must specify the complete mail address to be matched. For
example, if the first argument is Anderson@sun.com, this
matches a value in the second argument of Anderson@sun.com
and Anderson@SUN.COM, but not
Anne.Anderson@sun.com, anderson@sun.com or
Anderson@east.sun.com.
In order to match any address at a particular domain in the second
argument, the first argument must specify only a domain name (usually a
DNS name). For example, if the first argument is sun.com,
this matches a value in the second argument of
Anderson@sun.com or Baxter@SUN.COM, but not
Anderson@east.sun.com.
In order to match any address in a particular domain in the second
argument, the first argument must specify the desired domain-part with a
leading .. For example, if the first argument is
.east.sun.com, this matches a value in the second argument
of Anderson@east.sun.com and
anne.anderson@ISRG.EAST.SUN.COM but not
Anderson@sun.com.
This section specifies functions that take XPath expressions for arguments. An XPath expression evaluates to a node-set, which is a set of XML nodes that match the expression. A node or node-set is not in the formal data-type system of XACML. All comparison or other operations on node-sets are performed in isolation of the particular function specified. The context nodes and namespace mappings of the XPath expressions are defined by the XPath data-type, see Appendix E.2.5. The following functions are defined:
urn:oasis:names:tc:xacml:3.0:function:xpath-node-countThis function SHALL take an
urn:oasis:names:tc:xacml:3.0:data-type:xpathExpression as
an argument and evaluates to an
https://www.w3.org/2001/XMLSchema#integer. The value
returned from the function SHALL be the count of the nodes within the
node-set that match the given XPath expression. If the
<Content> element of the category to which the XPath
expression applies to is not present in the request, this function SHALL
return a value of zero.
urn:oasis:names:tc:xacml:3.0:function:xpath-node-equalThis function SHALL take two
urn:oasis:names:tc:xacml:3.0:data-type:xpathExpression
arguments and SHALL return an
https://www.w3.org/2001/XMLSchema#boolean. The function
SHALL return True if any of the XML nodes in the node-set
matched by the first argument equals any of the XML nodes in the
node-set matched by the second argument. Two nodes are considered equal
if they have the same identity. If the <Content>
element of the category to which either XPath expression applies to is
not present in the request, this function SHALL return a value of
False.
urn:oasis:names:tc:xacml:3.0:function:xpath-node-matchThis function SHALL take two
urn:oasis:names:tc:xacml:3.0:data-type:xpathExpression
arguments and SHALL return an
https://www.w3.org/2001/XMLSchema#boolean. This function
SHALL evaluate to True if one of the following two
conditions is satisfied: (1) Any of the XML nodes in the node-set
matched by the first argument is equal to any of the XML nodes in the
node-set matched by the second argument; (2) any node below any of the
XML nodes in the node-set matched by the first argument is equal to any
of the XML nodes in the node-set matched by the second argument. Two
nodes are considered equal if they have the same identity. If the
<Content> element of the category to which either
XPath expression applies to is not present in the request, this function
SHALL return a value of False. Note: The first condition is
equivalent to xpath-node-equal, and guarantees that
xpath-node-equal is a special case of
xpath-node-match.
urn:oasis:names:tc:xacml:3.0:function:access-permittedThis function SHALL take an
https://www.w3.org/2001/XMLSchema#anyURI and an
https://www.w3.org/2001/XMLSchema#string as arguments.
The first argument SHALL be interpreted as an
attribute category. The second argument SHALL
be interpreted as the XML content of an <Attributes>
element with Category equal to the first argument. The
function evaluates to an
https://www.w3.org/2001/XMLSchema#boolean. This function
SHALL return True if and only if the
policy evaluation described below returns the
value of Permit.
The following evaluation is described as if the context is actually instantiated, but it is only required that an equivalent result be obtained.
The function SHALL construct a new context,
by copying all the information from the current
context, omitting any
<Attributes> element with Category equal
to the first argument. The second function argument SHALL be added to
the context as the content of an
<Attributes> element with Category equal
to the first argument.
The function SHALL invoke a complete policy evaluation using the newly constructed context. This evaluation SHALL be completely isolated from the evaluation which invoked the function, but shall use all current policies and combining algorithms, including any per request policies.
The PDP SHALL detect any loop which may
occur if successive evaluations invoke this function by counting the
number of total invocations of any instance of this function during any
single initial invocation of the PDP. If the
total number of invocations exceeds the bound for such invocations, the
initial invocation of this function evaluates to Indeterminate with a
urn:oasis:names:tc:xacml:1.0:status:processing-error status
code. Also, see the security considerations in Appendix B.1.8.
Functions and primitive types are specified by string identifiers allowing for the introduction of functions in addition to those specified by XACML. This approach allows one to extend the XACML module with special functions and special primitive data-types.
In order to preserve the integrity of the XACML evaluation strategy, the result of an extension function SHALL depend only on the values of its arguments. Global and hidden parameters SHALL NOT affect the evaluation of an expression. Functions SHALL NOT have side effects, as evaluation order cannot be guaranteed in a standard way.
The following functions, data types and algorithms have been defined by previous versions of XACML and newer and better alternatives are defined in XACML 4.0. Their use is discouraged for new use and they are candidates for deprecation in future versions of XACML.
The following xpath based functions have been replaced with equivalent functions which use the new urn:oasis:names:tc:xacml:3.0:data-type:xpathExpression datatype instead of strings.
urn:oasis:names:tc:xacml:1.0:function:xpath-node-countReplaced with urn:oasis:names:tc:xacml:3.0:function:xpath-node-count
urn:oasis:names:tc:xacml:1.0:function:xpath-node-equalReplaced with urn:oasis:names:tc:xacml:3.0:function:xpath-node-equal
urn:oasis:names:tc:xacml:1.0:function:xpath-node-matchReplaced with urn:oasis:names:tc:xacml:3.0:function:xpath-node-match
The following URI and string concatenation function has been replaced with a string to URI conversion function, which allows the use of the general string functions with URI through string conversion.
urn:oasis:names:tc:xacml:2.0:function:uri-string-concatenateReplaced by urn:oasis:names:tc:xacml:3.0:function:string-from-anyURI
The following identifiers have been replaced with official identifiers defined by W3C.
https://www.w3.org/TR/2002/WD-xquery-operators-20020816#dayTimeDurationReplaced with https://www.w3.org/2001/XMLSchema#dayTimeDuration
https://www.w3.org/TR/2002/WD-xquery-operators-20020816#yearMonthDurationReplaced with https://www.w3.org/2001/XMLSchema#yearMonthDuration
The following functions have been replaced with functions which use the updated dayTimeDuration and yearMonthDuration data types.
urn:oasis:names:tc:xacml:1.0:function:dayTimeDuration-equalReplaced with urn:oasis:names:tc:xacml:3.0:function:dayTimeDuration-equal
urn:oasis:names:tc:xacml:1.0:function:yearMonthDuration-equalReplaced with urn:oasis:names:tc:xacml:3.0:function:yearMonthDuration-equal
urn:oasis:names:tc:xacml:1.0:function:dateTime-add-dayTimeDurationReplaced with urn:oasis:names:tc:xacml:3.0:function:dateTime-add-dayTimeDuration
urn:oasis:names:tc:xacml:1.0:function:dateTime-add-yearMonthDurationReplaced with urn:oasis:names:tc:xacml:3.0:function:dateTime-add-yearMonthDuration
urn:oasis:names:tc:xacml:1.0:function:dateTime-subtract-dayTimeDurationReplaced with urn:oasis:names:tc:xacml:3.0:function:dateTime-subtract-dayTimeDuration
urn:oasis:names:tc:xacml:1.0:function:dateTime-subtract-yearMonthDurationReplaced with urn:oasis:names:tc:xacml:3.0:function:dateTime-subtract-yearMonthDuration
urn:oasis:names:tc:xacml:1.0:function:date-add-yearMonthDurationReplaced with urn:oasis:names:tc:xacml:3.0:function:date-add-yearMonthDuration
urn:oasis:names:tc:xacml:1.0:function:date-subtract-yearMonthDurationReplaced with urn:oasis:names:tc:xacml:3.0:function:date-subtract-yearMonthDuration
The following attribute identifiers have been replaced with new identifiers.
urn:oasis:names:tc:xacml:1.0:subject:authn-locality:ip-addressReplaced with urn:oasis:names:tc:xacml:3.0:subject:authn-locality:ip-address
urn:oasis:names:tc:xacml:1.0:subject:authn-locality:dns-nameReplaced with urn:oasis:names:tc:xacml:3.0:subject:authn-locality:dns-name
This section defines standard identifiers for commonly used entities.
XACML is defined using this identifier.
urn:oasis:names:tc:xacml:4.0:core:schema
The following attribute category identifiers MUST be used when an XACML 2.0 or earlier policy or request is translated into XACML 4.0.
Attributes previously placed in the Resource, Action, and Environment sections of a request are placed in an attribute category with the following identifiers respectively. It is RECOMMENDED that they are used to list attributes of resources, actions, and the environment respectively when authoring XACML 4.0 policies or requests.
urn:oasis:names:tc:xacml:3.0:attribute-category:resource
urn:oasis:names:tc:xacml:3.0:attribute-category:action
urn:oasis:names:tc:xacml:3.0:attribute-category:environment
Attributes previously placed in the Subject section of a request are placed in an attribute category which is identical of the subject category in XACML 2.0, as defined below. It is RECOMMENDED that they are used to list attributes of subjects when authoring XACML 4.0 policies or requests.
This identifier indicates the system entity that initiated the access request. That is, the initial entity in a request chain. If subject category is not specified in XACML 2.0, this is the default translation value.
urn:oasis:names:tc:xacml:1.0:subject-category:access-subject
This identifier indicates the system entity that will receive the results of the request (used when it is distinct from the access-subject).
urn:oasis:names:tc:xacml:1.0:subject-category:recipient-subject
This identifier indicates a system entity through which the access request was passed.
urn:oasis:names:tc:xacml:1.0:subject-category:intermediary-subject
This identifier indicates a system entity associated with a local or remote codebase that generated the request. Corresponding subject attributes might include the URL from which it was loaded and/or the identity of the code-signer.
urn:oasis:names:tc:xacml:1.0:subject-category:codebase
This identifier indicates a system entity associated with the computer that initiated the access request. An example would be an IPsec identity.
urn:oasis:names:tc:xacml:1.0:subject-category:requesting-machine
The following identifiers indicate data-types that are defined in Appendix E.2:
urn:oasis:names:tc:xacml:1.0:data-type:x500Name
urn:oasis:names:tc:xacml:1.0:data-type:rfc822Name
urn:oasis:names:tc:xacml:2.0:data-type:ipAddress
urn:oasis:names:tc:xacml:2.0:data-type:dnsName
urn:oasis:names:tc:xacml:3.0:data-type:xpathExpression.
The following data-type identifiers are defined by XML Schema [XS]:
https://www.w3.org/2001/XMLSchema#string
https://www.w3.org/2001/XMLSchema#boolean
https://www.w3.org/2001/XMLSchema#integer
https://www.w3.org/2001/XMLSchema#double
https://www.w3.org/2001/XMLSchema#time
https://www.w3.org/2001/XMLSchema#date
https://www.w3.org/2001/XMLSchema#dateTime
https://www.w3.org/2001/XMLSchema#anyURI
https://www.w3.org/2001/XMLSchema#hexBinary
https://www.w3.org/2001/XMLSchema#base64Binary.
The following data-type identifiers correspond to the dayTimeDuration and yearMonthDuration data-types defined in [XF] Sections 10.3.2 and 10.3.1, respectively:
https://www.w3.org/2001/XMLSchema#dayTimeDuration
https://www.w3.org/2001/XMLSchema#yearMonthDuration.
These identifiers indicate attributes of a
subject. When used, it is RECOMMENDED that
they appear within an <Attributes> element of the
request context with a
subject category (see Appendix F.2).
At most one of each of these attributes is
associated with each subject. Each
attribute associated with authentication
included within a single <Attributes> element relates
to the same authentication event.
This identifier indicates the name of the subject.
urn:oasis:names:tc:xacml:1.0:subject:subject-id
This identifier indicates the security domain of the subject. It identifies the administrator and policy that manages the name-space in which the subject id is administered.
urn:oasis:names:tc:xacml:1.0:subject:subject-id-qualifier
This identifier indicates a public key used to confirm the subject's identity.
urn:oasis:names:tc:xacml:1.0:subject:key-info
This identifier indicates the time at which the subject was authenticated.
urn:oasis:names:tc:xacml:1.0:subject:authentication-time
This identifier indicates the method used to authenticate the subject.
urn:oasis:names:tc:xacml:1.0:subject:authentication-method
This identifier indicates the time at which the subject initiated the access request, according to the PEP.
urn:oasis:names:tc:xacml:1.0:subject:request-time
This identifier indicates the time at which the subject's current session began, according to the PEP.
urn:oasis:names:tc:xacml:1.0:subject:session-start-time
The following identifiers indicate the location where authentication credentials were activated.
This identifier indicates that the location is expressed as an IP address.
urn:oasis:names:tc:xacml:3.0:subject:authn-locality:ip-address
The corresponding attribute SHALL be of
data-type
urn:oasis:names:tc:xacml:2.0:data-type:ipAddress.
This identifier indicates that the location is expressed as a DNS name.
urn:oasis:names:tc:xacml:3.0:subject:authn-locality:dns-name
The corresponding attribute SHALL be of
data-type
urn:oasis:names:tc:xacml:2.0:data-type:dnsName.
Where a suitable attribute is already defined in LDAP [LDAP-1], [LDAP-2], the XACML identifier SHALL be formed by adding the attribute name to the URI of the LDAP specification. For example, the XACML attribute name for the userPassword attribute defined in the RFC 2256 SHALL be:
https://www.ietf.org/rfc/rfc2256.txt#userPassword
These identifiers indicate attributes of
the resource. When used, it is RECOMMENDED
they appear within the <Attributes> element of the
request context with Category
urn:oasis:names:tc:xacml:3.0:attribute-category:resource.
This attribute identifies the resource to which access is requested.
urn:oasis:names:tc:xacml:1.0:resource:resource-id
This attribute identifies the namespace of
the top element(s) of the contents of the <Content>
element. In the case where the resource
content is supplied in the request context and
the resource namespaces are defined in the
resource, the PEP
MAY provide this attribute in the request to
indicate the namespaces of the resource
content. In this case there SHALL be one value of this
attribute for each unique namespace of the top
level elements in the <Content> element. The type of
the corresponding attribute SHALL be
https://www.w3.org/2001/XMLSchema#anyURI.
urn:oasis:names:tc:xacml:2.0:resource:target-namespace
These identifiers indicate attributes of
the action being requested. When used, it is
RECOMMENDED they appear within the <Attributes>
element of the request context with
Category
urn:oasis:names:tc:xacml:3.0:attribute-category:action.
This attribute identifies the action for which access is requested.
urn:oasis:names:tc:xacml:1.0:action:action-id
Where the action is implicit, the value of the action-id attribute SHALL be
urn:oasis:names:tc:xacml:1.0:action:implied-action
This attribute identifies the namespace in which the action-id attribute is defined.
urn:oasis:names:tc:xacml:1.0:action:action-namespace
These identifiers indicate attributes of
the environment within which the
decision request is to be evaluated. When used
in the decision request, it is RECOMMENDED
they appear in the <Attributes> element of the
request context with Category
urn:oasis:names:tc:xacml:3.0:attribute-category:environment.
This identifier indicates the current time at the context
handler. In practice it is the time at which the request
context was created. For this reason, if these
identifiers appear in multiple places within a
<Policy>, then the same value SHALL be assigned to
each occurrence in the evaluation procedure, regardless of how much time
elapses between the processing of the occurrences.
urn:oasis:names:tc:xacml:1.0:environment:current-time
The corresponding attribute SHALL be of
data-type https://www.w3.org/2001/XMLSchema#time.
urn:oasis:names:tc:xacml:1.0:environment:current-date
The corresponding attribute SHALL be of
data-type https://www.w3.org/2001/XMLSchema#date.
urn:oasis:names:tc:xacml:1.0:environment:current-dateTime
The corresponding attribute SHALL be of
data-type https://www.w3.org/2001/XMLSchema#dateTime.
The following status code values are defined.
This identifier indicates success.
urn:oasis:names:tc:xacml:1.0:status:ok
This identifier indicates that all the attributes necessary to make a policy decision were not available (see Section 5.58).
urn:oasis:names:tc:xacml:1.0:status:missing-attribute
This identifier indicates that some attribute value contained a syntax error, such as a letter in a numeric field.
urn:oasis:names:tc:xacml:1.0:status:syntax-error
This identifier indicates that an error occurred during policy evaluation. An example would be division by zero.
urn:oasis:names:tc:xacml:1.0:status:processing-error
The deny-overrides combining algorithm has
the following value for the CombiningAlgId attribute:
urn:oasis:names:tc:xacml:4.0:combining-algorithm:deny-overrides
The permit-overrides combining algorithm
has the following value for the CombiningAlgId
attribute:
urn:oasis:names:tc:xacml:4.0:combining-algorithm:permit-overrides
The first-applicable combining algorithm
has the following value for the CombiningAlgId
attribute:
urn:oasis:names:tc:xacml:4.0:combining-algorithm:first-applicable
The ordered-deny-overrides combining
algorithm has the following value for the
CombiningAlgId attribute:
urn:oasis:names:tc:xacml:4.0:combining-algorithm:ordered-deny-overrides
The ordered-permit-overrides combining
algorithm has the following value for the
CombiningAlgId attribute:
urn:oasis:names:tc:xacml:4.0:combining-algorithm:ordered-permit-overrides
The deny-unless-permit combining algorithm
has the following value for the CombiningAlgId
attribute:
urn:oasis:names:tc:xacml:4.0:combining-algorithm:deny-unless-permit
The permit-unless-deny combining algorithm
has the following value for the CombiningAlgId
attribute:
urn:oasis:names:tc:xacml:4.0:combining-algorithm:permit-unless-deny
This section contains a description of the combining algorithms specified by XACML. Pseudo code is normative, descriptions in English are non-normative.
Note that in each case an implementation is conformant as long as it produces the same result as is specified here, regardless of how and in what order the implementation behaves internally.
Some combining algorithms are defined in
terms of an extended set of Indeterminate values. See Section 7.10 for the definition
of the Extended Indeterminate values. For these algorithms, the
PDP MUST keep track of the extended set of
Indeterminate values during rule
and policy combining.
The output of a combining algorithm which
does not track the extended set of Indeterminate values
MUST be treated as Indeterminate{DP} for the value
Indeterminate by a combining
algorithm which tracks the extended set of
Indeterminate values.
A combining algorithm which does not track
the extended set of Indeterminate values MUST treat the
output of a combining algorithm which tracks
the extended set of Indeterminate values as an
Indeterminate for any of the possible values of the
extended set of Indeterminate.
This section defines the Deny-overrides
combining algorithm of a
policy.
This combining algorithm makes use of the
extended Indeterminate.
The combining algorithm defined here has the following identifier:
urn:oasis:names:tc:xacml:4.0:combining-algorithm:deny-overrides
The following is a non-normative informative description of this combining algorithm. The deny overrides combining algorithm is intended for those cases where a deny decision should have priority over a permit decision. This algorithm has the following behavior.
If any decision is Deny, the result is
Deny.
Otherwise, if any decision is Indeterminate{DP}, the
result is Indeterminate{DP}.
Otherwise, if any decision is Indeterminate{D} and
another decision is
Indeterminate{P} or Permit, the result is Indeterminate{DP}`.
Otherwise, if any decision is Indeterminate{D}, the
result is Indeterminate{D}.
Otherwise, if any decision is Permit, the result is
Permit.
Otherwise, if any decision is Indeterminate{P}, the
result is Indeterminate{P}.
Otherwise, the result is NotApplicable.
The following pseudo-code represents the normative specification of this combining algorithm. The algorithm is presented here in a form where the input to it is an array with children (the policies or rules) of the policy. The children may be processed in any order, so the list of notices provided by this algorithm is not deterministic.
Decision denyOverridesCombiningAlgorithm(Node[] children)
{
Boolean atLeastOneErrorD = false;
Boolean atLeastOneErrorP = false;
Boolean atLeastOneErrorDP = false;
Boolean atLeastOnePermit = false;
for( i=0 ; i < lengthOf(children) ; i++ )
{
Decision decision = children[i].evaluate();
if (decision == Deny)
{
return Deny;
}
if (decision == Permit)
{
atLeastOnePermit = true;
continue;
}
if (decision == NotApplicable)
{
continue;
}
if (decision == Indeterminate{D})
{
atLeastOneErrorD = true;
continue;
}
if (decision == Indeterminate{P})
{
atLeastOneErrorP = true;
continue;
}
if (decision == Indeterminate{DP})
{
atLeastOneErrorDP = true;
continue;
}
}
if (atLeastOneErrorDP)
{
return Indeterminate{DP};
}
if (atLeastOneErrorD && (atLeastOneErrorP || atLeastOnePermit))
{
return Indeterminate{DP};
}
if (atLeastOneErrorD)
{
return Indeterminate{D};
}
if (atLeastOnePermit)
{
return Permit;
}
if (atLeastOneErrorP)
{
return Indeterminate{P};
}
return NotApplicable;
}Notices SHALL be combined as described in Section 7.18.
The following specification defines the
Ordered-deny-overrides combining
algorithm of a policy. The
behavior of this algorithm is identical to that of the
Deny-overrides combining
algorithm with one exception. The order in which the
collection of policies and
rules is evaluated SHALL match the order as
listed in the policy.
The combining algorithm defined here has the following identifier:
urn:oasis:names:tc:xacml:4.0:combining-algorithm:ordered-deny-overrides
This section defines the Permit-overrides
combining algorithm of a
policy.
This combining algorithm makes use of the
extended Indeterminate.
The combining algorithm defined here has the following identifier:
urn:oasis:names:tc:xacml:4.0:combining-algorithm:permit-overrides
The following is a non-normative informative description of this combining algorithm. The permit overrides combining algorithm is intended for those cases where a permit decision should have priority over a deny decision. This algorithm has the following behavior.
If any decision is Permit, the result is
Permit.
Otherwise, if any decision is Indeterminate{DP}, the
result is Indeterminate{DP}.
Otherwise, if any decision is Indeterminate{P} and
another decision is
Indeterminate{D} or Deny, the result is Indeterminate{DP}`.
Otherwise, if any decision is Indeterminate{P}, the
result is Indeterminate{P}.
Otherwise, if any decision is Deny, the result is
Deny.
Otherwise, if any decision is Indeterminate{D}, the
result is Indeterminate{D}.
Otherwise, the result is NotApplicable.
The following pseudo-code represents the normative specification of this combining algorithm. The algorithm is presented here in a form where the input to it is an array with all children (the policies or rules) of the policy. The children may be processed in any order, so the list of noticess provided by this algorithm is not deterministic.
Decision permitOverridesCombiningAlgorithm(Node[] children)
{
Boolean atLeastOneErrorD = false;
Boolean atLeastOneErrorP = false;
Boolean atLeastOneErrorDP = false;
Boolean atLeastOneDeny = false;
for( i=0 ; i < lengthOf(children) ; i++ )
{
Decision decision = children[i].evaluate();
if (decision == Deny)
{
atLeastOneDeny = true;
continue;
}
if (decision == Permit)
{
return Permit;
}
if (decision == NotApplicable)
{
continue;
}
if (decision == Indeterminate{D})
{
atLeastOneErrorD = true;
continue;
}
if (decision == Indeterminate{P})
{
atLeastOneErrorP = true;
continue;
}
if (decision == Indeterminate{DP})
{
atLeastOneErrorDP = true;
continue;
}
}
if (atLeastOneErrorDP)
{
return Indeterminate{DP};
}
if (atLeastOneErrorP && (atLeastOneErrorD || atLeastOneDeny))
{
return Indeterminate{DP};
}
if (atLeastOneErrorP)
{
return Indeterminate{P};
}
if (atLeastOneDeny)
{
return Deny;
}
if (atLeastOneErrorD)
{
return Indeterminate{D};
}
return NotApplicable;
}Notices SHALL be combined as described in Section 7.18.
The following specification defines the
Ordered-permit-overrides combining
algorithm of a policy. The
behavior of this algorithm is identical to that of the
Permit-overrides combining
algorithm with one exception. The order in which the
collection of policies and
rules is evaluated SHALL match the order as
listed in the policy.
The combining algorithm defined here has the following identifier:
urn:oasis:names:tc:xacml:4.0:combining-algorithm:ordered-permit-overrides
This section defines the Deny-unless-permit
combining algorithm of a
policy.
The combining algorithm defined here has the following identifier:
urn:oasis:names:tc:xacml:4.0:combining-algorithm:deny-unless-permit
The following is a non-normative informative description of this
combining algorithm. The
Deny-unless-permit combining
algorithm is intended for those cases where a permit
decision should have priority over a deny decision, and an
Indeterminate or NotApplicable must never be
the result. It is particularly useful at the top level in a
policy structure to ensure that a
PDP will always return a definite
Permit or Deny result. This algorithm has the
following behavior.
If any decision is Permit, the result is
Permit.
Otherwise, the result is Deny.
The following pseudo-code represents the normative specification of this combining algorithm. The algorithm is presented here in a form where the input to it is an array with all the children (the policies or rules) of the policy. The children may be processed in any order, so the list of notices provided by this algorithm is not deterministic.
Decision denyUnlessPermitCombiningAlgorithm(Node[] children)
{
for( i=0 ; i < lengthOf(children) ; i++ )
{
if (children[i].evaluate() == Permit)
{
return Permit;
}
}
return Deny;
}Notices SHALL be combined as described in Section 7.18.
This section defines the Permit-unless-deny
combining algorithm of a
policy.
The combining algorithm defined here has the following identifier:
urn:oasis:names:tc:xacml:4.0:combining-algorithm:permit-unless-deny
The following is a non-normative informative description of this
combining algorithm. The
Permit-unless-deny combining
algorithm is intended for those cases where a deny
decision should have priority over a permit decision, and an
Indeterminate or NotApplicable must never be
the result. It is particularly useful at the top level in a
policy structure to ensure that a
PDP will always return a definite
Permit or Deny result. This algorithm has the
following behavior.
If any decision is Deny, the result is
Deny.
Otherwise, the result is Permit.
The following pseudo-code represents the normative specification of this combining algorithm. The algorithm is presented here in a form where the input to it is an array with all the children (the policies or rules) of the policy. The children may be processed in any order, so the list of notices provided by this algorithm is not deterministic.
Decision permitUnlessDenyCombiningAlgorithm(Node[] children)
{
for( i=0 ; i < lengthOf(children) ; i++ )
{
if (children[i].evaluate() == Deny)
{
return Deny;
}
}
return Permit;
}Notices SHALL be combined as described in Section 7.18.
This section defines the First-applicable
combining algorithm of a
policy.
The combining algorithm defined here has the following identifier:
urn:oasis:names:tc:xacml:4.0:combining-algorithm:first-applicable
The following is a non-normative informative description of the
First-Applicable combining
algorithm of a policy.
For a particular child policy or
rule, if that policy
or rule evaluates to Permit,
Deny or Indeterminate, then the evaluation
SHALL halt and the enclosing policy shall
evaluate to the value of that policy or
rule. If the policy
or rule evaluates to
NotApplicable, then the next child
policy or rule in
the order SHALL be evaluated. If no further child
policy or rule
exists in the order, then the enclosing policy
shall evaluate to NotApplicable. If an error occurs while
evaluating a policy or
rule, or a policy
reference is considered invalid, then the evaluation shall halt, and the
enclosing policy shall evaluate to
Indeterminate, with the appropriate error status.
The following pseudo-code represents the normative specification of this combining algorithm.
Decision firstApplicableEffectRuleCombiningAlgorithm(Node[] children)
{
for( i = 0 ; i < lengthOf(children) ; i++ )
{
Decision decision = children[i].evaluate();
if (decision == Deny)
{
return Deny;
}
if (decision == Permit)
{
return Permit;
}
if (decision == NotApplicable)
{
continue;
}
if (decision == Indeterminate)
{
return Indeterminate;
}
}
return NotApplicable;
}Notices SHALL be combined as described in Section 7.18.
Copyright © OASIS Open 2024. All Rights Reserved.
All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to OASIS, except as needed for the purpose of developing any document or deliverable produced by an OASIS Technical Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must be followed) or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
As stated in the OASIS IPR Policy, the following three paragraphs in brackets apply to OASIS Standards Final Deliverable documents (Committee Specification, OASIS Standard, or Approved Errata).
[OASIS requests that any OASIS Party or any other party that believes it has patent claims that would necessarily be infringed by implementations of this OASIS Standards Final Deliverable, to notify OASIS TC Administrator and provide an indication of its willingness to grant patent licenses to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this deliverable.]
[OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of any patent claims that would necessarily be infringed by implementations of this OASIS Standards Final Deliverable by a patent holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this OASIS Standards Final Deliverable. OASIS may include such claims on its website, but disclaims any obligation to do so.]
[OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this OASIS Standards Final Deliverable or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS' procedures with respect to rights in any document or deliverable produced by an OASIS Technical Committee can be found on the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this OASIS Standards Final Deliverable, can be obtained from the OASIS TC Administrator. OASIS makes no representation that any information or list of intellectual property rights will at any time be complete, or that any claims in such list are, in fact, Essential Claims.]
The name "OASIS" is a trademark of OASIS, the owner and developer of this specification, and should be used only to refer to the organization and its official outputs. OASIS welcomes reference to, and implementation and use of, specifications, while reserving the right to enforce its marks against misleading uses. Please see https://www.https:policies-guidelines/trademark/ for above guidance.