This document provides a profile for requesting access to more than one resource in a single XACML Request Context, or for requesting a single response to a request for an entire hierarchy.

Status:

This document was last revised or approved by the eXtensible Access Control Markup Language (XACML) TC on the above date. The level of approval is also listed above. Check the “Latest Version” or “Latest Approved Version” location noted above for possible later revisions of this document.

Technical Committee members should send comments on this specification to the Technical Committee’s email list. Others should send comments to the Technical Committee by using the “Send A Comment” button on the Technical Committee’s web page at http://www.oasis-open.org/committees/xacml/.

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 Technical Committee web page http://www.oasis-open.org/committees/xacml/ipr.php.

The non-normative errata page for this specification is located at http://www.oasis-open.org/committees/xacml/.

Notices

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.

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 Committee Specification or OASIS Standard, 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 specification.

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 specification 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 specification. 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 document 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 Committee Specification or OASIS Standard, 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 names "OASIS" and “XACML” are trademarks 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 http://www.oasis-open.org/who/trademark.php for above guidance.

Table of Contents

1 Introduction. 6

1.1 Glossary. 6

1.2 Abbreviated identifiers. 6

1.3 Terminology. 6

1.4 Normative References. 7

1.5 Non-Normative References. 7

2 Requests for multiple resources. 8

2.1 Nodes identified by “scope” 8

2.1.1 Profile URI 8

2.1.2 Original request context syntax. 8

2.1.3 Semantics. 9

2.2 Nodes identified by XPath. 9

2.2.1 Profile URI 9

2.2.2 Original request context 9

2.2.3 Semantics. 9

2.3 Multiple <Attributes> elements. 10

2.3.1 Profile URI 10

2.3.2 Original request context 10

2.3.3 Semantics. 10

2.4 By reference to <Attributes> elements. 10

2.4.1 Profile URI 10

2.4.2 Original request context 10

2.4.3 Semantics. 11

3 Requests for an entire hierarchy. 12

3.1 XML resources. 12

3.1.1 Profile URI 12

3.1.2 Original request context 12

3.1.3 Semantics. 12

3.2 Non-XML resources. 13

3.2.1 Profile URI 13

3.2.2 Original request context 13

3.2.3 Semantics. 13

4 New attribute identifiers. 14

4.1 “scope” 14

5 New profile identifiers. 15

6 Conformance. 16

6.1 Processor of requests for multiple resources as nodes identified by “scope” 16

6.2 Processor of requests for multiple resources as nodes identified by XPath. 16

6.3 Processor of requests for multiple resources by multiple <Attributes> elements. 16

6.4 Processor of requests for multiple resources by reference to <Attributes> elements. 16

6.5 Processor of requests for an entire hierarchy of XML resources. 16

6.6 Processor of requests for an entire hierarchy of non-XML resources. 16

A. Acknowledgements. 17

B. Revision History. 18

1 Introduction

{Non-normative}

The policy evaluation performed by an XACML Policy Decision Point, or PDP, is defined in terms of a single requested resource in the XACML Specification [XACML], with the authorization decision contained in a single <Result> element of the response context. A Policy Enforcement Point, or PEP, however, may wish to submit a single request context for access to multiple resources, and may wish to obtain a single response context that contains a separate authorization decision (<Result> element) for each requested resource. Such a request context might be used to avoid sending multiple decision request messages between a PEP and PDP, for example. Alternatively, a PEP may wish to submit a single request context for all the nodes in a hierarchy, and may wish to obtain a single authorization decision (<Result> element) that indicates whether access is permitted to all of the requested nodes. Such a request context might be used when the requester wants access to an entire XML document, to an entire sub-tree of elements in such a document, or to an entire file system directory with all its subdirectories and files, for example.

This Profile describes three ways in which a PEP can request authorization decisions for multiple resources in a single request context, and how the result of each such authorization decision is represented in the single response context that is returned to the PEP.

This Profile also describes two ways in which a PEP can request a single authorization decision in response to a request for all the nodes in a hierarchy.

Support for each of the mechanisms described in this Profile is optional for compliant XACML implementations.

1.1 Glossary

Hierarchical resource

A resource that is organized as a tree or forest (Directed Acyclic Graph) of individual resources called nodes.

Node

An individual resource that is part of a hierarchical resource.

1.2 Abbreviated identifiers

Commonly used resource attributes are abbreviated as follows:

“resource-id” attribute

A resource attribute with an AttributeId of “urn:oasis:names:tc:xacml:1.0:resource:resource-id”.

“scope” attribute

A resource attribute with an AttributeId of “urn:oasis:names:tc:xacml:2.0:resource:scope”. See Section 4.1 for more information about this attribute.

1.3 Terminology

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC2119].

The phrase {Optional} means that the described functionality is optional for compliant XACML implementations, but, if the functionality is claimed as being supported according to this Profile, then it SHALL be supported in the way described.

Example code listings appear like this.

In descriptions of syntax, elements in angle brackets (“<”, “>”) are to be replaced by appropriate values, square brackets (“[“, “]”) enclose optional elements, elements in quotes are literal components, and “*” indicates that the preceding element may occur zero or more times.

1.4 Normative References

[Hierarchical] E.Rissanen, R. Levinson and H. Lockhart eds., Hierarchical XACML v3.0 Hierarchical Resource Profile Version 1.0, Working draft 8, 5 April 2009, FIXME URL

[RFC2119] S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, http://www.ietf.org/rfc/rfc2119.txt, IETF RFC 2119, March 1997.

[XACML] E. Rissanen, ed., eXtensible Access Control Markup Language (XACML) Version 3.0, Working draft 11, 5 April 2009, FIXME URL

[XPath] XML Path Language (XPath), Version 1.0, W3C Recommendation 16, November 1999. Available at http://www.w3.org/TR/xpath

1.5 Non-Normative References

None

2 Requests for multiple resources

{Optional}

A single XACML request context MAY represent a request for access to multiple resources, with a separate authorization decision desired for each resource. The syntax and semantics of such requests and responses are specified in this Section.

The <Result> elements produced by evaluating a request for access to multiple resources SHALL be identical to those that would be produced from a series of requests, each requesting access to exactly one of the resources. Each such resource is called an Individual Resource. The conceptual request context that corresponds to each <Result> element is called an Individual Resource Request. This mapping of an original request context containing multiple authorization decision requests to Individual Resource Requests, and the corresponding mapping of multiple authorization decisions to multiple <Result> elements in a single response context MAY be performed by the Context Handler described in the non-normative Data-flow model of the core XACML specification [XACML]. This Profile does NOT REQUIRE that the implementation of the evaluation of a request for access to multiple resources conform to the preceding model or that actual Individual Resource Requests be constructed. The Profile REQUIRES only that the <Result> elements SHALL be the same as if the preceding model were used.

Three ways of specifying requests for access to multiple resources are described in the following Sections. Each way of specifying requests describes the Individual Resource Requests that correspond to the <Result> elements in the response context.

A single XACML request context submitted by a PEP MAY use more than one of these ways of requesting access to multiple resources in different <Resource> elements.

2.1 Nodes identified by “scope”

{Optional}

This Section describes the use of two values for the “scope“ resource attribute to specify a request for access to multiple resources in a hierarchy. This syntax MAY be used with any hierarchical resource [Hierarchical], regardless of whether it is an XML document or not. The “scope” resource attribute is defined in Section 4.

2.1.1 Profile URI

The following URIs SHALL be used as URI identifiers for the functionality specified in this Section of this Profile. The first identifier SHALL be used when the functionality is supported for XML resources, and the second identifier SHALL be used when the functionality is supported for resources that are not XML documents:

· urn:oasis:names:tc:xacml:3.0:profile:multiple:scope:xml

· urn:oasis:names:tc:xacml:3.0:profile:multiple:scope:non-xml

2.1.2 Original request context syntax

The original XACML request context <Attributes> element in the resource category SHALL contain a “scope” attribute with a value of either “Children”, or “Descendants”. If the requested resources are in an XML document, then the <Content> element SHALL be present and SHALL contain the entire XML document of which the requested elements are a part. Also, if the requested resources are in an XML document, then the XPath [XPath] expression used as the value of the “resource-id” attribute SHALL evaluate to a nodeset containing exactly one node.

2.1.3 Semantics

Such a request context SHALL be interpreted as a request for access to a set of nodes in a hierarchy relative to the single node specified in the “resource-id” attribute. If the value of the “scope” attribute is “Children”, each Individual Resource is the one node indicated by the “resource-id” attribute (or attributes, where the single resource has multiple normative identifiers) and all of its immediate child nodes. If the value of the “scope” attribute is “Descendants”, the Individual Resource is the one node indicated by the “resource-id” attribute and all of its descendant nodes.

Each Individual Resource Request SHALL be identical to the original request context with two exceptions: the “scope” attribute SHALL NOT be present and the <Attributes> element SHALL represent a single Individual Resource. This <Attributes> element SHALL contain at least one “resource-id” attribute, and all values for such attributes SHALL be unique, normative identities of the Individual Resource. If the “resource-id” attribute in the original request context contained an Issuer, the “resource-id” attributes in the Individual Resource Request SHALL contain the same Issuer. If a <Content> element was present in the original request context, then that same <Content> element SHALL be included in each Individual Resource Request. If the “resource-id” attribute in the original request context contained an IncludeInResult, the “resource-id” attributes in the Individual Resource Request SHALL contain the same IncludeInResult.

Neither XACML nor this Profile specifies how the Context Handler obtains the information required to determine which nodes are children or descendants of a given node, except in the case of an XML document, where the information SHALL be obtained from the <Content> element.

2.2 Nodes identified by XPath

{Optional}

This Section describes use of an XPath [XPath] expression in the “resource-id” attribute, together with an “XPath-expression” value in the “scope” attribute to specify a request for access to multiple nodes in an XML document. This syntax SHALL be used only with resources that are XML documents.

2.2.1 Profile URI

The following URI SHALL be used as the URI identifier for the functionality specified in this Section of this Profile:

· urn:oasis:names:tc:xacml:3.0:profile:multiple:xpath-expression

2.2.2 Original request context

The original XACML request context <Attributes> element in the resource category SHALL contain a <Content> element and a “resource-id” attribute with a DataType of “urn:oasis:names:tc:xacml:3.0:data-type:xpathExpression”, such that the <AttributeValue> of the “resource-id” attribute is an XPath expression that evaluates to a nodeset that represents multiple nodes in the resource category <Content> element. The <Attributes> element with the resource category SHALL contain a “scope” attribute with a value of “XPath-expression”.

2.2.3 Semantics

Such a request context SHALL be interpreted as a request for access to the multiple nodes in the nodeset represented by the <AttributeValue> of the “resource-id” attribute. Each such node SHALL represent an Individual Resource.

Each Individual Resource Request SHALL be identical to the original request context with two exceptions: the “scope” attribute SHALL NOT be present and the “resource-id” attribute value SHALL be an XPath expression that evaluates to a single node in the <Content> element. That node SHALL be the Individual Resource. If the “resource-id” attribute in the original request context contained an Issuer, the “resource-id” attribute in the Individual Resource Request SHALL contain the same Issuer. If the “resource-id” attribute in the original request context contained an IncludeInResult, the “resource-id” attribute in the Individual Resource Request SHALL contain the same IncludeInResult.

2.3 Multiple <Attributes> elements

{Optional}

This Section describes use of multiple <Attributes> elements with the same category in a request context to specify a request for access to multiple resources or requests for access by multiple subjects. This syntax MAY be used with any resource or resources, regardless of whether they are XML documents or not and regardless of whether they are hierarchical resources [Hierarchical] or not.

2.3.1 Profile URI

The following URI SHALL be used as the URI identifier for the functionality specified in this Section of this Profile:

· urn:oasis:names:tc:xacml:3.0:profile:multiple:multiple-resource-elements

2.3.2 Original request context

The XACML request context SHALL contain multiple <Attributes> elements with the same category.

2.3.3 Semantics

Such a request context SHALL be interpreted as a request for access to all resources specified in the individual <Attributes> elements. Each <Attributes> element SHALL represent one Individual Resource, subject, or another category unless that element utilizes the other mechanisms described in this Profile.

For each combination of repeated <Attributes> elements, one Individual Resource Request SHALL be created. This Individual Request SHALL be identical to the original request context with one exception: only one <Attributes> element of each repeated category SHALL be present. If such a <Attributes> element contains a “scope” attribute having any value other than “Immediate”, then the Individual Request SHALL be further processed according to the corresponding Section of this Profile listed in Section 4.1. This processing may involve decomposing the one Individual Request into other Individual Requests before evaluation by the PDP.

2.4 By reference to <Attributes> elements

{Optional}

This section describes use of a list of references to <Attributes> elements to construct multiple individual <Request> elements.

2.4.1 Profile URI

The following URIs SHALL be used as URI identifiers for the functionality specified in this Section of this Profile.

urn:oasis:names:tc:xacml:3.0:profile:multiple:reference

2.4.2 Original request context

The original XACML <Request> element SHALL contain a <MultiRequests> element.

2.4.3 Semantics

Such a request context SHALL be interpreted as multiple individual request contexts specified by references to <Attributes> elements.

The context handler MUST construct a new <Request> element for each <RequestReference> element contained in the <MultiRequests> element, and process the generated <Request> element.

Each <RequestReference> element contains one or more <AttributesReference> elements, each of which refers to the xml:id XML attribute of one of the <Attributes> elements in the enclosing original <Request> element. The generated <Request> element MUST be identical to a <Request> element which contains the referenced <Attributes> elements.

The result(s) of each such generated <Request> element MUST be included as one or more <Result> elements in the <Response> element corresponding to the original <Request> element. There may be multiple results for a single generated <Request> element when the generated <Request> element makes use of one or more of the other multiple request schemes in this profile. There MUST be exactly one <Response> element for the original <Request> element.

If a <RequestReference> contains an invalid reference, then the corresponding <Result> MUST contain an Indeterminate decision with status code urn:oasis:names:tc:xacml:1.0:status:syntax-error.

3 Requests for an entire hierarchy

{Optional}

In some cases, a resource is hierarchical, but the authorization decision request is intended to request access to all the nodes within that resource or to an entire sub-hierarchy of nodes within that resource. This might be the case when access to an XML document is being requested for purposes of making a copy of the entire document, or where access to an entire file system directory with all its subdirectories and files is being requested. A single <Result> is desired, indicating whether the requester is permitted to access the entire set of nodes.

The <Result> element produced by evaluating such a request for access SHALL be identical to that produced by the following process. A series of request contexts is evaluated, each requesting access to exactly one node of the hierarchy. The <Decision> in the single <Result> that is returned to the PEP SHALL be “Permit” if and only if all <Result> elements resulting from the evaluation of the individual nodes contained a <Decision> of “Permit”. Otherwise, the <Decision> in the single <Result> returned to the PEP SHALL be “Deny”. This Profile does NOT REQUIRE that the implementation of the evaluation of a request for access to such a hierarchical resource conform to the preceding model or that actual request contexts corresponding to the individual nodes in the hierarchy be constructed. This Profile REQUIRES only that the <Result> element SHALL be the same as if the preceding model were used.

Two syntax's for this functionality are specified in the following Sections, one for use with resources that are XML documents, and the other for use with resources that are not XML documents.

3.1 XML resources

{Optional}

This Section describes the syntax for requesting access to an entire XML document, or to an element within that document with all its recursive sub-elements.

3.1.1 Profile URI

The following URI SHALL be used as the identifier for the functionality specified in this Section of this Profile:

· urn:oasis:names:tc:xacml:3.0:profile:multiple:entire-hierarchy:xml

3.1.2 Original request context

The <Attributes> element with the resource category in the original request context SHALL contain a “scope” attribute with a value of “EntireHierarchy”.

The <Attributes> element in the original request context SHALL contain a single “resource-id” attribute with a DataType of “urn:oasis:names:tc:xacml:3.0:data-type:xpathExpression” (defined in [Hierarchical]), such that the <AttributeValue> evaluates to a nodeset that represents exactly one node in the <Content> element.

The <Attributes> element in the original request context MAY contain other attributes.

3.1.3 Semantics

The <Result> of such a request SHALL be equivalent to that produced by the following process. For each node in the requested hierarchy, the Context Handler SHALL create a new request context. Each such request context SHALL contain a single <Attributes> element with the resource category having a “resource-id” attribute with a DataType of “urn:oasis:names:tc:xacml:3.0:data-type:xpathExpression” (defined in [Hierarchical]) and a value that is an XPath [XPath] expression that evaluates to a nodeset that contains exactly that one node in the <Content> element. The Context Handler SHALL submit each such new request context to the PDP for evaluation and SHALL keep track of the <Decision> in the corresponding <Result> elements. If and only if all the new request contexts evaluate to “Permit”, then a single <Result> containing a <Decision> of “Permit” SHALL be placed into the response context returned to the PEP. If any of the new request contexts evaluates to “Deny”, “Indeterminate”, or “NotApplicable”, then a single <Result> containing a <Decision> of “Deny” SHALL be placed into the response context returned to the PEP. If any attribute in the original request context contained an IncludeInResult, then the attribute SHALL be included in the result.

3.2 Non-XML resources

{Optional}

This Section describes the syntax for requesting access to an entire hierarchy of nodes within a hierarchical resource that is not an XML document.

3.2.1 Profile URI

The following URI SHALL be used as the identifier for the functionality specified in this Section of this Profile:

· urn:oasis:names:tc:xacml:3.0:profile:multiple:entire-hierarchy:non-xml

3.2.2 Original request context

The <Attributes> element with the resource category in the original request context SHALL contain a “scope” attribute with a value of “EntireHierarchy”.

The <Attributes> element in the original request context SHALL contain a single “resource-id” attribute that represents a single node in a hierarchical resource.

The <Attributes> element in the original request context MAY contain other attributes.

The representation of nodes in a hierarchical resource specified in Section FIXME 2.2 of the Hierarchical resource profile of XACML v3.0 [Hierarchical] MAY be used to represent the identity of the single node.

3.2.3 Semantics

The <Result> of such a request SHALL be equivalent to that produced by the following process. For each node in the requested hierarchy, the Context Handler SHALL create a new request context. Each such request context SHALL contain a single <Attributes> element with the resource category having a “resource-id” attribute with a value that is the identity of that one node in the hierarchy. The Context Handler SHALL submit each such new request context to the PDP for evaluation and SHALL keep track of the <Decision> in the corresponding <Result> elements. If and only if all the new request contexts evaluate to “Permit”, then a single <Result> containing a <Decision> of “Permit” SHALL be placed into the response context returned to the PEP. If any of the new request contexts evaluates to “Deny”, “Indeterminate”, or “NotApplicable”, then a single <Result> containing a <Decision> of “Deny” SHALL be placed into the response context returned to the PEP. If any attribute in the original request context contained an IncludeInResult, then the attribute SHALL be included in the result.

Neither XACML nor this Profile specifies how the Context Handler obtains the information required to determine which nodes are descendants of the originally specified node, or how to represent the identity of each such node. The representation of nodes in a hierarchical resource specified in Section FIXME 2.2 of the Hierarchical resource profile of XACML v3.0 [Hierarchical] MAY be used to represent the identity of each such node.

4 New attribute identifiers

4.1 “scope”

The following identifier is used as the AttributeId of a resource attribute that indicates the scope of a request for access in a single <Attributes> element of a request context.

· urn:oasis:names:tc:xacml:2.0:resource:scope

The attribute SHALL have a DataType of “http://www.w3.org/2001/XMLSchema#string“.

The valid values for this attribute are listed below, along with a reference to the Section of this Profile or to the core XACML specification that describes how the <Attributes> element with the resource category is to be processed. An implementation MAY support any subset of these values, including the empty set.

· “Immediate” - The <Attributes> element refers to a single non-hierarchical resource or to a single node in a hierarchical resource. This is the default value, if no “scope” attribute is present. The <Attributes> element SHALL be processed according to the core XACML specification [XACML].

· “Children” - The <Attributes> element refers to multiple resources in a hierarchy. The set of resources consists of a single node described by the “resource-id” resource attribute and of all that node's immediate children in the hierarchy. The <Attributes> element SHALL be processed according to Section 2.1 of this Profile.

· “Descendants” - The <Attributes> element refers to multiple resources in a hierarchy. The set of resources consists of a single node described by the “resource-id” resource attribute and of all that node's descendants in the hierarchy. The <Attributes> element SHALL be processed according to Section 2.1 of this Profile.

· “XPath-expression” - The <Attributes> element refers to multiple resources. The set of resources consists of the nodes in a nodeset described by the “resource-id” resource attribute. Each of the nodes SHALL be contained in the <Content> element of the <Attributes> element. The <Resource> element SHALL be processed according to Section 2.2 of this Profile.

· “EntireHierarchy” - The <Resource> element refers to a single resource. The resource consists of a node described by the “resource-id” resource attribute along with all that node's descendants. All of the nodes SHALL be nodes in an XML document that is contained in the <Content> element of the <Attributes> element. The <Attributes> element SHALL be processed according to Section 2.4.

5 New profile identifiers

The following URI values SHALL be used as URI identifiers for the functionality specified in various Sections of this Profile:

Section 2.1: “scope attribute of “children” or “descendants” in <Attributes>: XML resources

· urn:oasis:names:tc:xacml:3.0:profile:multiple:scope:xml

Section 2.1: “scope attribute of “children” or “descendants” in <Attributes>: Non-XML resources

· urn:oasis:names:tc:xacml:3.0:profile:multiple:scope:non-xml

Section 2.2: XPath expression in “resource-id” attribute

· urn:oasis:names:tc:xacml:3.0:profile:multiple:xpath-expression

Section 2.3: Multiple <Attributes> elements

· urn:oasis:names:tc:xacml:3.0:profile:multiple:multiple-resource-elements

Section 2.4: By reference to <Attributes> elements

· urn:oasis:names:tc:xacml:3.0:profile:multiple:reference

Section 3.1: Requests for an entire hierarchy: XML resources

· urn:oasis:names:tc:xacml:3.0:profile:multiple:entire-hierarchy:xml

Section 3.2: Requests for an entire hierarchy: Non-XML resources

· urn:oasis:names:tc:xacml:3.0:profile:multiple:entire-hierarchy:non-xml

6 Conformance

An implementation may conform to this specification in one or more of the following ways.

The following individuals have participated in the creation of this specification and are gratefully acknowledged:

Participants:

Anthony Nadalin

Bill Parducci

Daniel Engovatov

Hal Lockhart

Michael McIntosh

Ron Jacobson

Seth Proctor

Steve Anderson

Tim Moses

B. Revision History

Revision	Date	Editor	Changes Made
WD 1		Erik Rissanen	Initial update to XACML 3.0.
WD 2	28 Dec 2007	Erik Rissanen	Update to current OASIS template.
WD 3	4 Nov 2008	Erik Rissanen	Define behavior for the IncludeInResult attribute.
WD 4	3 Mar 2009	Erik Rissanen	Added the new <MultiRequests> scheme.
WD 5		Erik Rissanen	Changed error behavior in <MultiRequests> Clarified some text Editorial cleanups Conformance section