These tests are non-normative and do not constitute a full
test of conformance to the XACML Version 2.0 Standard. A full
description of the requirements for conformance is included in
Section 10. Conformance of the
XACML Version 2.0 specification. There is no OASIS- or XACML
TC- sponsored branding or certification program for
XACML.

History of changes since XACML 2.0

AnySubject and other Any* elements in the Target are not allowed in XACML 2.0

Environment element is required in Target for Request in XACML 2.0

FunctionId is not allowed in Condition element in XACML 2.0

IssueInstant attribute is not allowed in Attribute in XACML 2.0

IIIASpecial.txt is removed, because AttributeAssignment element has AttributeValue in XACML 2.0.

IIIGSpecial.txt is removed, because in XACML 2.0 it's defined that <xacml-context:Request>
is the context node for xpath expressions.

Version 0.2

Remove DataType attribute from AttributeValue elements in *Request.xml files.
Data types should be specified in the parent Attribute element.

Replace regexp-string-match in *Policy.xml files with string-regexp-match.
In XACML 2.0 this function's urn was changed to make it more consistent with names of
similar functions. Thanks to Ryan Eberhard for reporting this discrepancy in the
test suite.

Version 0.3

Fix typos in policy combining algorithm urns. These typos were a result of
a bug in the scripts, which were used to convert XACML 1.0 conformance tests
to XACML 2.0. Thanks to Ryan Eberhard for reporting this bug in the
test suite.

Version 0.4

IIC086-IIC091: change some attribute types to string.

IIA004, IIA005 - these files contained intentional errors, which were accidentally "fixed"
when converting to xacml 2.0. Errors are reintroduced.

IID029, IID030, IIE001, IIE002 - these files were not converted properly to
to xacml 2.0: Condition had FunctionId attribute. This bug was first reported by Frederic Deleon.

Version 0.4

IIF001: new test for Variable feature.

Test Case Groupings
Tests are divided into those that exercise
Mandatory-to-Implement functionality and those that
exercise Optional, but normative functionality. All
implementations that claim conformance to the eXtensible Access
Control Markup Language (XACML) Version 2.0 OASIS StandardMUST support all Mandatory-to-Implement functionality as
described in the
XACML Version 2.0 specification.
Conforming implementations MAY additionally support
various Optional functionality areas.

Tests are divided into groups based on the primary area of
functionality or schema being exercised.

Each test case consists of three XML documents (or sets of documents):

An XACML Request

An XACML Policy or set of Policy documents

An XACML Response

Each XML document is named according to the section of this
document in which it occurs. For example, the XML
documents for the test in Part II (Mandatory to
implement), Section B (Target Matching), Test Case 8 (Case:
match: multiple actions) are named:

The request and response used in executing these tests need not
be instances of the XACML Context Schema. The request and
response should, however, contain exactly the same information as
the given Request and Response file, and should exercise the XACML
policy evaluation functionality that the test is intended to
exercise. It should be possible, at least conceptually, to
mechanically convert the request and response used in the
implementation to the given XACML Request and Response
instances.

While this suite of tests is non-normative, we hope the suite
will represent a general consensus as to the intent of the XACML
Version 2.0 Standard. For this reason, contributed tests are
marked **EXPERIMENTAL**
until the tests have undergone successful review and use, defined
as follows:

no objections to the test have been reported to the
xacml-comment mailing list.

Once the tests have undergone successful review and use, then the
**EXPERIMENTAL** status will be
removed.

If an objection is reported on the xacml-comment mailing list to
an **EXPERIMENTAL** test during the review
period, then the test will be removed from the test suite on the
next update unless the XACML TC upholds the objection. It is up
to the test submitter to request review by the TC, and it is up
to the TC to decide whether or not to review a test.

If an objection is reported to a test that is no longer **EXPERIMENTAL**, the objection is treated
as a bug. See Bugs in the
Tests for a
description of how bugs are handled.

Major or controversial bugs reported against non-**EXPERIMENTAL**
tests will be reviewed by the XACML TC. If the TC agrees that
the test does not conform to the intent of the XACML Version 2.0
Standard, then the test will be modified or removed as
appropriate on the next test suite update.

Periodically, an updated copy of the entire Conformance Test
Suite, containing all corrections to date, will be posted to the
XACML TC Web Site.

Mandatory-to-Implement Functionality Tests
This section contains tests of all mandatory-to-implement
functionality. All implementations that conform to the XACML
Version 2.0 Standard should pass all these tests except as
explained in any associated Special Instructions
(<test ID>Special.txt) file.