1 Introduction

1.1 Glossary (non-normative)

1.1.1 Preferred terms

Access

Performing an action

Access control

Controlling access in accordance with a policy or policy set

Action

An operation on a resource

Advice

A supplementary piece of information in a policy or policy set which is provided to the PEP with the decision of the PDP.

Applicable policy

The set of policies and policy sets that governs access for a specific decision request

Attribute

Characteristic of a subject, resource, action or environment that may be referenced in a predicate or target (see also – named attribute)

Authorization decision

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 set of obligations and advice

Bag

An unordered collection of values, in which there may be duplicate values

Condition

An expression of predicates. A function that evaluates to "True", "False" or “Indeterminate”

Conjunctive sequence

A sequence of predicates combined using the logical ‘AND’ operation

Context

The canonical representation of a decision request and an authorization decision

Context handler

The system entity that converts decision requests in the native request format to the XACML canonical form and converts authorization decisions in the XACML canonical form to the native response format

Decision

The result of evaluating a rule, policy or policy set

Decision request

The request by a PEP to a PDP to render an authorization decision

Disjunctive sequence

A sequence of predicates combined using the logical ‘OR’ operation

Effect

The intended consequence of a satisfied rule (either "Permit" or "Deny")

Environment

The set of attributes that are relevant to an authorization decision and are independent of a particular subject, resource or action

Issuer

A set of attributes describing the source of a policy

Named attribute

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

Obligation

An operation specified in a rule, policy or policy set that should be performed by the PEP in conjunction with the enforcement of an authorization decision

Policy

A set of rules, an identifier for the rule-combining algorithm and (optionally) a set of obligations or advice. May be a component of a policy set

Policy administration point (PAP)

The system entity that creates a policy or policy set

Policy-combining algorithm

The procedure for combining the decision and obligations from multiple policies

Policy decision point (PDP)

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

Policy enforcement point (PEP)

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

Policy information point (PIP)

The system entity that acts as a source of attribute values

Policy set

A set of policies, other policy sets, a policy-combining algorithm and (optionally) a set of obligations or advice. May be a component of another policy set

Predicate

A statement about attributes whose truth can be evaluated

Resource

Data, service or system component

Rule

A target, an effect, a condition and (optionally) a set of obligations or advice. A component of a policy

Rule-combining algorithm

The procedure for combining decisions from multiple rules

Subject

An actor whose attributes may be referenced by a predicate

Target

The set of decision requests, identified by definitions for resource, subject and action that a rule, policy, or policy set is intended to evaluate

Type Unification

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

1.1.2 Related terms

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.

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

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 appear like this.

Example 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 3.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 http://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.

1.3 Schema organization and namespaces

The XACML syntax is defined in a schema associated with the following XML namespace:

urn:oasis:names:tc:xacml:3.0:core:schema:wd-17

1.4 Normative References

[CMF] Martin J. Dürst et al, eds., Character Model for the World Wide Web 1.0: Fundamentals, W3C Recommendation 15 February 2005, http://www.w3.org/TR/2005/REC-charmod-20050215/

[DS] D. Eastlake et al., XML-Signature Syntax and Processing, http://www.w3.org/TR/xmldsig-core/, World Wide Web Consortium.

[exc-c14n] J. Boyer et al, eds., Exclusive XML Canonicalization, Version 1.0, W3C Recommendation 18 July 2002, http://www.w3.org/TR/2002/REC-xml-exc-c14n-20020718/

[Hancock] Hancock, Polymorphic Type Checking, in Simon L. Peyton Jones, Implementation of Functional Programming Languages, Section 8,
Prentice-Hall International, 1987.

[Haskell] Haskell, a purely functional language. Available at http://www.haskell.org/

[Hier] OASIS Committee Draft 03, XACML v3.0 Hierarchical Resource Profile Version 1.0, 11 March 2010, http://docs.oasis-open.org/xacml/3.0/xacml-3.0-hierarchical-v1-spec-cd-03-en.doc

[IEEE754] IEEE Standard for Binary Floating-Point Arithmetic 1985, ISBN 1-5593-7653-8, IEEE Product No. SH10116-TBR.

[ISO10181-3] ISO/IEC 10181-3:1996 Information technology – Open Systems Interconnection -- Security frameworks for open systems: Access control framework.

[Kudo00] 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.

[LDAP-1] RFC2256, A summary of the X500(96) User Schema for use with LDAPv3, Section 5, M Wahl, December 1997, http://www.ietf.org/rfc/rfc2256.txt

[LDAP-2] RFC2798, Definition of the inetOrgPerson, M. Smith, April 2000 http://www.ietf.org/rfc/rfc2798.txt

[MathML] Mathematical Markup Language (MathML), Version 2.0, W3C Recommendation, 21 October 2003. Available at: http://www.w3.org/TR/2003/REC-MathML2-20031021/

[Multi] OASIS Committee Draft 03, XACML v3.0 Multiple Decision Profile Version 1.0, 11 March 2010, http://docs.oasis-open.org/xacml/3.0/xacml-3.0-multiple-v1-spec-cd-03-en.doc

[Perritt93] 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: http://www.ifla.org/documents/infopol/copyright/perh2.txt

[RBAC] David Ferraiolo and Richard Kuhn, Role-Based Access Controls, 15th National Computer Security Conference, 1992.

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

[RFC2396] Berners-Lee T, Fielding R, Masinter L, Uniform Resource Identifiers (URI): Generic Syntax. Available at: http://www.ietf.org/rfc/rfc2396.txt

[RFC2732] Hinden R, Carpenter B, Masinter L, Format for Literal IPv6 Addresses in URL's. Available at: http://www.ietf.org/rfc/rfc2732.txt

[RFC3198] IETF RFC 3198: Terminology for Policy-Based Management, November 2001. http://www.ietf.org/rfc/rfc3198.txt

[UAX15] Mark Davis, Martin Dürst, Unicode Standard Annex #15: Unicode Normalization Forms, Unicode 5.1, available from http://unicode.org/reports/tr15/

[UTR36] Davis, Mark, Suignard, Michel, Unicode Technocal Report #36: Unicode Security Considerations. Available at http://www.unicode.org/reports/tr36/

[XACMLAdmin] OASIS Committee Draft 03, XACML v3.0 Administration and Delegation Profile Version 1.0. 11 March 2010. http://docs.oasis-open.org/xacml/3.0/xacml-3.0-administration-v1-spec-cd-03-en.doc

[XACMLv1.0] OASIS Standard, Extensible access control markup language (XACML) Version 1.0. 18 February 2003. http://www.oasis-open.org/committees/download.php/2406/oasis-xacml-1.0.pdf

[XACMLv1.1] OASIS Committee Specification, Extensible access control markup language (XACML) Version 1.1. . 7 August 2003. http://www.oasis-open.org/committees/xacml/repository/cs-xacml-specification-1.1.pdf

[XF] XQuery 1.0 and XPath 2.0 Functions and Operators, W3C Recommendation 23 January 2007. Available at: http://www.w3.org/TR/2007/REC-xpath-functions-20070123/

[XML] Bray, Tim, et.al. eds, Extensible Markup Language (XML) 1.0 (Fifth Edition), W3C Recommendation 26 November 2008, available at http://www.w3.org/TR/2008/REC-xml-20081126/

[XMLid] Marsh, Jonathan, et.al. eds, xml:id Version 1.0. W3C Recommendation 9 September 2005. Available at: http://www.w3.org/TR/2005/REC-xml-id-20050909/

[XS] XML Schema, parts 1 and 2. Available at: http://www.w3.org/TR/xmlschema-1/ and http://www.w3.org/TR/xmlschema-2/

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

[XSLT] XSL Transformations (XSLT) Version 1.0, W3C Recommendation 16 November 1999. Available at: http://www.w3.org/TR/xslt

1.5 Non-Normative References

[CM] Character model model for the World Wide Web 1.0: Normalization, W3C Working Draft, 27 October 2005, http://www.w3.org/TR/2005/WD-charmod-norm-20051027/, World Wide Web Consortium.

[Hinton94] Hinton, H, M, Lee, E, S, The Compatibility of Policies, Proceedings 2nd ACM Conference on Computer and Communications Security, Nov 1994, Fairfax, Virginia, USA.

[Sloman94] Sloman, M. Policy Driven Management for Distributed Systems. Journal of Network and Systems Management, Volume 2, part 4. Plenum Press. 1994.

2 Background (non-normative)

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.

2.1 Requirements

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

2.2 Rule and policy combining

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 three top-level policy elements: <Rule>, <Policy> and <PolicySet>. 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, and be re-used in multiple policies.

The <Policy> element contains a set of <Rule> 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.

The <PolicySet> element contains a set of <Policy> or other <PolicySet> elements and a specified procedure for combining the results of their evaluation. It is the standard means for combining separate policies into a single combined policy.

Hinton et al [Hinton94] discuss the question of the compatibility of separate policies applicable to the same decision request.

2.3 Combining algorithms

XACML defines a number of combining algorithms that can be identified by a RuleCombiningAlgId or PolicyCombiningAlgId attribute of the <Policy> or <PolicySet> elements, respectively. The rule-combining algorithm defines a procedure for arriving at an authorization decision given the individual results of evaluation of a set of rules. Similarly, the policy-combining algorithm defines a procedure for arriving at an authorization decision given the individual results of evaluation of a set of policies. Standard combining algorithms are defined for:

· Deny-overrides (Ordered and Unordered),

· Permit-overrides (Ordered and Unordered),

· First-applicable and

· Only-one-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 evaluating the first <Rule>, <Policy> or <PolicySet> element in the list of rules whose target and condition is applicable to the decision request.

The "Only-one-applicable" policy-combining algorithm only applies to policies. The result of this combining algorithm ensures that one and only one policy or policy set is applicable by virtue of their targets. If no policy or policy set applies, then the result is "NotApplicable", but if more than one policy or policy set is applicable, then the result is "Indeterminate". When exactly one policy or policy set is applicable, the result of the combining algorithm is the result of evaluating the single applicable policy or policy set.

Policies and policy sets 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.

2.4 Multiple subjects

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.

2.5 Policies based on subject and resource attributes

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.

2.6 Multi-valued attributes

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 Section A.3).

2.7 Policies based on resource contents

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.

2.8 Operators

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

2.9 Policy distribution

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.

2.10 Policy indexing

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:

Policy statements may be stored in a database. In this case, the PDP should form a database query to retrieve just those policies that are applicable to the set of decision requests to which it expects to respond. Additionally, the PDP should evaluate the <Target> element of the retrieved policy or policy set statements as defined by the XACML specification.
Alternatively, the PDP may be loaded with all available policies and evaluate their <Target> elements in the context of a particular decision request, in order to identify the policies and policy sets that are applicable to that request.

The use of constraints limiting the applicability of a policy was described by Sloman [Sloman94].

2.11 Abstraction layer

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.

2.12 Actions performed in conjunction with enforcement

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 in the <Obligations> element. 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 <Obligations> elements associated with the applicable policy. <Obligations> elements are returned to the PEP for enforcement.

2.13 Supplemental information about a decision

In some applications it is helpful to specify supplemental information about a decision. XACML provides facilities to specify supplemental information about a decision with the <Advice> element. Such advice may be safely ignored by the PEP.

3 Models (non-normative)

The data-flow model and language model of XACML are described in the following sub-sections.

3.1 Data-flow model

The major actors in the XACML domain are shown in the data-flow diagram of Figure 1.

Figure 1 - Data-flow diagram

Note: some of the data-flows shown in the diagram may be facilitated by a repository. For instance, the communications between the context handler and the PIP or the communications between the PDP and the PAP may be facilitated by a repository. The XACML specification is not intended to place restrictions on the location of any such repository, or indeed to prescribe a particular communication protocol for any of the data-flows.

The model operates by the following steps.

PAPs write policies and policy sets and make them available to the PDP. These policies or policy sets represent the complete policy for a specified target.
The access requester sends a request for access to the PEP.
The PEP sends the request for access to the context handler in its native request format, optionally including attributes of the subjects, resource, action, environment and other categories.
The context handler constructs an XACML request context and sends it to the PDP.
The PDP requests any additional subject, resource, action, environment and other categories (not shown) attributes from the context handler.
The context handler requests the attributes from a PIP.
The PIP obtains the requested attributes.
The PIP returns the requested attributes to the context handler.
Optionally, the context handler includes the resource in the context.
The context handler sends the requested attributes and (optionally) the resource to the PDP. The PDP evaluates the policy.
The PDP returns the response context (including the authorization decision) to the context handler.
The context handler translates the response context to the native response format of the PEP. The context handler returns the response to the PEP.
The PEP fulfills the obligations.
(Not shown) If access is permitted, then the PEP permits access to the resource; otherwise, it denies access.

3.2 XACML context

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

Figure 2 - XACML context

Note: The PDP is not required to operate directly on the XACML representation of a policy. It may operate directly on an alternative representation.

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 B.2 for suggested attribute categories.

See Section 7.3.5 for a more detailed discussion of the request context.

3.3 Policy language model

The policy language model is shown in Figure 3. The main components of the model are:

· Rule;

· Policy; and

· Policy set.

These are described in the following sub-sections.

Figure 3 - Policy language model

3.3.1 Rule

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:

· a target;

· an effect,

· a condition,

· obligation epxressions, and

· advice expressions

These are discussed in the following sub-sections.

3.3.1.1 Rule target

The target 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. The <Condition> element may further refine the applicability established by the target. If the rule is intended to apply to all entities of a particular data-type, then the corresponding entity is omitted from the target. An XACML PDP verifies that the matches defined by the target are satisfied by the attributes in the request context.

The <Target> element may be absent from a <Rule>. In this case, the target of the <Rule> is the same as that 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” not “urn:oasis:names:tc:xacml:1.0:function:rfc822Name-equal” (see Appendix 10.2.9).

3.3.1.2 Effect

The effect of the rule indicates the rule-writer's intended consequence of a "True" evaluation for the rule. Two values are allowed: "Permit" and "Deny".

3.3.1.3 Condition

Condition represents a Boolean expression that refines the applicability of the rule beyond the predicates implied by its target. Therefore, it may be absent.

3.3.1.4 Obligation expressions

Obligation expressions may be added by the writer of the rule.

When a PDP evaluates a rule containing obligation, expressions, it evaluates the obligation expressions into obligations and returns certain of those obligations to the PEP in the response context. Section 7.16 explains which obligations are to be returned.

3.3.1.5 Advice

Advice expressions may be added by the writer of the rule.

When a PDP evaluates a rule containing advice expressions, it evaluates the advice expressions into advice and returns certain of those advice to the PEP in the response context. Section 7.16 explains which advice are to be returned. In contrast to obligations, advice may be safely ignored by the PEP.

3.3.2 Policy

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 rule-combining algorithm-identifier;

· a set of rules;

· obligation expressions and

· advice expressions

Rules are described above. The remaining components are described in the following sub-sections.

3.3.2.1 Policy target

An XACML <PolicySet>, <Policy> or <Rule> element contains a <Target> element that specifies the set of requests to which it applies. The <Target> of a <PolicySet> or <Policy> may be declared by the writer of the <PolicySet> or <Policy>, or it may be calculated from the <Target> elements of the <PolicySet>, <Policy> and <Rule> elements 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 <PolicySet> or <Policy> (the "outer component") is calculated as the union of all the <Target> elements of the referenced <PolicySet>, <Policy> or <Rule> elements (the "inner components"). In another method, the <Target> element of the outer component is calculated as the intersection of all the <Target> 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> 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> elements of every inner component. Note that computing the intersection of a set of <Target> elements is likely only practical if the target 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 <Target> element as the <Policy> element may omit the <Target> element. Such <Rule> elements inherit the <Target> of the <Policy> in which they are contained.

3.3.2.2 Rule-combining algorithm

The rule-combining algorithm specifies the procedure by which the results of evaluating the component rules are combined when evaluating the policy, i.e. the decision value placed in the response context by the PDP is the value of the policy, as defined by the rule-combining algorithm. A policy may have combining parameters that affect the operation of the rule-combining algorithm.

See Appendix C for definitions of the normative rule-combining algorithms.

3.3.2.3 Obligation expressions

Obligation expressions may be added by the writer of the policy.

When a PDP evaluates a policy containing obligation expressions, it evaluates the obligation expressions into obligations and returns certain of those obligations to the PEP in the response context. Section 7.16 explains which obligations are to be returned.

3.3.2.4 Advice

Advice expressions may be added by the writer of the policy.

When a PDP evaluates a policy containing advice expressions, it evaluates the advice expressions into advice and returns certain of those advice to the PEP in the response context. Section 7.16 explains which advice are to be returned. In contrast to obligations, advice may be safely ignored by the PEP.

3.3.3 Policy set

A policy set comprises four main components:

· a target;

· a policy-combining algorithm-identifier

· a set of policies;

· obligation expressions, and

· advice expressions

The target and policy components are described above. The other components are described in the following sub-sections.

3.3.3.1 Policy-combining algorithm

The policy-combining algorithm specifies the procedure by which the results of evaluating the component policies are combined when evaluating the policy set, i.e. the Decision value placed in the response context by the PDP is the result of evaluating the policy set, as defined by the policy-combining algorithm. A policy set may have combining parameters that affect the operation of the policy-combining algorithm.

See Appendix C for definitions of the normative policy-combining algorithms.

3.3.3.2 Obligation expressions

The writer of a policy set may add obligation expressions to the policy set, in addition to those contained in the component rules, policies and policy sets.

When a PDP evaluates a policy set containing obligations expressions, it evaluates the obligation expressions into obligations and returns certain of those obligations to the PEP in its response context. Section 7.16 explains which obligations are to be returned.

3.3.3.3 Advice expressions

Advice expressions may be added by the writer of the policy set.

When a PDP evaluates a policy set containing advice expressions, it evaluates the advice expressions into advice and returns certain of those advice to the PEP in the response context. Section 7.16 explains which advice are to be returned. In contrast to obligations, advice may be safely ignored by the PEP.

4 Examples (non-normative)

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 rule-combining algorithm, conditions and obligations.

4.1 Example one

4.1.1 Example policy

Assume that a corporation named Medi Corp (identified by its domain name: med.example.com) has an access control policy that states, in English:

Any user with an e-mail name in the "med.example.com" namespace is allowed to perform any action on any resource.

An XACML policy consists of header information, an optional text description of the policy, a target, one or more rules and an optional set of obligation expressions.

[a1] <?xml version="1.0" encoding="UTF-8"?>

[a2] <Policy

[a3] xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17"

[a4] xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

[a5] xsi:schemaLocation="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17

[a6] http://docs.oasis-open.org/xacml/3.0/xacml-core-v3-schema-wd-17.xsd"

[a7] PolicyId="urn:oasis:names:tc:xacml:3.0:example:SimplePolicy1"

[a8] Version="1.0"

[a9] RuleCombiningAlgId="identifier:rule-combining-algorithm:deny-overrides">

[a10] <Description>

[a11] Medi Corp access control policy

[a12] </Description>

[a13] <Target/>

[a14] <Rule

[a15] RuleId= "urn:oasis:names:tc:xacml:3.0:example:SimpleRule1"

[a16] Effect="Permit">

[a17] <Description>

[a18] Any subject with an e-mail name in the med.example.com domain

[a19] can perform any action on any resource.

[a20] </Description>

[a21] <Target>

[a22] <AnyOf>

[a23] <AllOf>

[a24] <Match

[a25] MatchId="urn:oasis:names:tc:xacml:1.0:function:rfc822Name-match">

[a26] <AttributeValue

[a27] DataType="http://www.w3.org/2001/XMLSchema#string"

[a28] >med.example.com</AttributeValue>

[a29] <AttributeDesignator

[a30] MustBePresent="false"

[a31] Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject"

[a32] AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id"

[a33] DataType="urn:oasis:names:tc:xacml:1.0:data-type:rfc822Name"/>

[a34] </Match>

[a35] </AllOf>

[a36] </AnyOf>

[a37] </Target>

[a38] </Rule>

[a39] </Policy>

[a1] is a standard XML document tag indicating which version of XML is being used and what the character encoding is.

[a2] introduces the XACML Policy itself.

[a3] - [a4] are XML namespace declarations.

[a3] gives a URN for the XACML policies schema.

[a7] assigns a name to this policy instance. The name of a policy has to be unique for a given PDP so that there is no ambiguity if one policy is referenced from another policy. The version attribute specifies the version of this policy is “1.0”.

[a9] specifies the algorithm that will be used to resolve the results of the various rules that may be in the policy. The deny-overrides rule-combining algorithm specified here says that, if any rule evaluates to “Deny”, then the policy must return “Deny”. If all rules evaluate to “Permit”, then the policy must return “Permit”. The rule-combining algorithm, which is fully described in Appendix C, also says what to do if an error were to occur when evaluating any rule, and what to do with rules that do not apply to a particular decision request.

[a10] - [a12] provide a text description of the policy. This description is optional.

[a13] describes the decision requests to which this policy applies. If the attributes in a decision request do not match the values specified in the policy target, then the remainder of the policy does not need to be evaluated. This target section is useful for creating an index to a set of policies. In this simple example, the target section says the policy is applicable to any decision request.

[a14] introduces the one and only rule in this simple policy.

[a15] specifies the identifier for this rule. Just as for a policy, each rule must have a unique identifier (at least unique for any PDP that will be using the policy).

[a16] says what effect this rule has if the rule evaluates to “True”. Rules can have an effect of either “Permit” or “Deny”. In this case, if the rule is satisfied, it will evaluate to “Permit”, meaning that, as far as this one rule is concerned, the requested access should be permitted. If a rule evaluates to “False”, then it returns a result of “NotApplicable”. If an error occurs when evaluating the rule, then the rule returns a result of “Indeterminate”. As mentioned above, the rule-combining algorithm for the policy specifies how various rule values are combined into a single policy value.

[a17] - [a20] provide a text description of this rule. This description is optional.

[a21] introduces the target of the rule. As described above for the target of a policy, the target of a rule describes the decision requests to which this rule applies. If the attributes in a decision request do not match the values specified in the rule target, then the remainder of the rule does not need to be evaluated, and a value of “NotApplicable” is returned to the rule evaluation.

The rule target is similar to the target of the policy itself, but with one important difference. [a22] - [a36] spells out a specific value that the subject in the decision request must match. The <Match> element specifies a matching function in the MatchId attribute, a literal value of “med.example.com” and a pointer to a specific subject attribute in the request context by means of the <AttributeDesignator> element with an attribute category which specifies the access subject. The matching function will be used to compare the literal value with the value of the subject attribute . Only if the match returns “True” will this rule apply to a particular decision request. If the match returns “False”, then this rule will return a value of “NotApplicable”.

[a38] closes the rule. In this rule, all the work is done in the <Target> element. In more complex rules, the <Target> may have been followed by a <Condition> element (which could also be a set of conditions to be ANDed or ORed together).

[a39] closes the policy. As mentioned above, this policy has only one rule, but more complex policies may have any number of rules.

4.1.2 Example request context

Let's examine a hypothetical decision request that might be submitted to a PDP that executes the policy above. In English, the access request that generates the decision request may be stated as follows:

Bart Simpson, with e-mail name "bs@simpsons.com", wants to read his medical record at Medi Corp.

In XACML, the information in the decision request is formatted into a request context statement that looks as follows:

[b1] <?xml version="1.0" encoding="UTF-8"?>

[b2] <Request xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17"

[b3] xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

[b4] xsi:schemaLocation="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17 http://docs.oasis-open.org/xacml/3.0/xacml-core-v3-schema-wd-17.xsd"

[b5] ReturnPolicyIdList="false">

[b6] <Attributes Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject">

[b7] <Attribute IncludeInResult="false"

[b8] AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id">

[b9] <AttributeValue

[b10] DataType="urn:oasis:names:tc:xacml:1.0:data-type:rfc822Name"

[b11] >bs@simpsons.com</AttributeValue>

[b12] </Attribute>

[b13] </Attributes>

[b14] <Attributes

[b15] Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource">

[b16] <Attribute IncludeInResult="false"

[b17] AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id">

[b18] <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#anyURI"

[b19] >file://example/med/record/patient/BartSimpson</AttributeValue>

[b20] </Attribute>

[b21] </Attributes>

[b22] <Attributes

[b23] Category="urn:oasis:names:tc:xacml:3.0:attribute-category:action">

[b24] <Attribute IncludeInResult="false"

[b25] AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id">

[b26] <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string"

[b27] >read</AttributeValue>

[b28] </Attribute>

[b29] </Attributes>

[b30] </Request>

[b1] - [b2] contain the header information for the request context, and are used the same way as the header for the policy explained above.

The first <Attributes> element contains attributes of the entity making the access request. There can be multiple subjects in the form of additional <Attributes> elements with different categories, and each subject can have multiple attributes. In this case, in [b6] - [b13], there is only one subject, and the subject has only one attribute: the subject's identity, expressed as an e-mail name, is “bs@simpsons.com”.

The second <Attributes> element contains attributes of the resource to which the subject (or subjects) has requested access. Lines [b14] - [b21] contain the one attribute of the resource to which Bart Simpson has requested access: the resource identified by its file URI, which is “file://medico/record/patient/BartSimpson”.

The third <Attributes> element contains attributes of the action that the subject (or subjects) wishes to take on the resource. [b22] - [b29] describe the identity of the action Bart Simpson wishes to take, which is “read”.

[b30] closes the request context. A more complex request context may have contained some attributes not associated with the subject, the resource or the action. Environment would be an example of such an attribute category. These would have been placed in additional <Attributes> elements. Examples of such attributes are attributes describing the environment or some application specific category of attributes.

The PDP processing this request context locates the policy in its policy repository. It compares the attributes in the request context with the policy target. Since the policy target is empty, the policy matches this context.

The PDP now compares the attributes in the request context with the target of the one rule in this policy. The requested resource matches the <Target> element and the requested action matches the <Target> element, but the requesting subject-id attribute does not match "med.example.com".

4.1.3 Example response context

As a result of evaluating the policy, there is no rule in this policy that returns a "Permit" result for this request. The rule-combining algorithm for the policy specifies that, in this case, a result of "NotApplicable" should be returned. The response context looks as follows:

[c1] <?xml version="1.0" encoding="UTF-8"?>

[c2] <Response xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17 http://docs.oasis-open.org/xacml/3.0/xacml-core-v3-schema-wd-17.xsd">

[c3] <Result>

[c4] <Decision>NotApplicable</Decision>

[c5] </Result>

[c6] </Response>

[c1] - [c2] contain the same sort of header information for the response as was described above for a policy.

The <Result> element in lines [c3] - [c5] contains the result of evaluating the decision request against the policy. In this case, the result is “NotApplicable”. A policy can return “Permit”, “Deny”, “NotApplicable” or “Indeterminate”. Therefore, the PEP is required to deny access.

[c6] closes the response context.

4.2 Example two

This section contains an example XML document, an example request context and example XACML rules. The XML document is a medical record. Four separate rules are defined. These illustrate a rule-combining algorithm, conditions and obligation expressions.

4.2.1 Example medical record instance

The following is an instance of a medical record to which the example XACML rules can be applied. The <record> schema is defined in the registered namespace administered by Medi Corp.

[d1] <?xml version="1.0" encoding="UTF-8"?>

[d2] <record xmlns="urn:example:med:schemas:record"

[d3] xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

[d4] <patient>

[d5] <patientName>

[d6] <first>Bartholomew</first>

[d7] <last>Simpson</last>

[d8] </patientName>

[d9] <patientContact>

[d10] <street>27 Shelbyville Road</street>

[d11] <city>Springfield</city>

[d12] <state>MA</state>

[d13] <zip>12345</zip>

[d14] <phone>555.123.4567</phone>

[d15] <fax/>

[d16] <email/>

[d17] </patientContact>

[d18] <patientDoB>1992-03-21</patientDoB>

[d19] <patientGender>male</patientGender>

[d20] <patient-number>555555</patient-number>

[d21] </patient>

[d22] <parentGuardian>

[d23] <parentGuardianId>HS001</parentGuardianId>

[d24] <parentGuardianName>

[d25] <first>Homer</first>

[d26] <last>Simpson</last>

[d27] </parentGuardianName>

[d28] <parentGuardianContact>

[d29] <street>27 Shelbyville Road</street>

[d30] <city>Springfield</city>

[d31] <state>MA</state>

[d32] <zip>12345</zip>

[d33] <phone>555.123.4567</phone>

[d34] <fax/>

[d35] <email>homers@aol.com</email>

[d36] </parentGuardianContact>

[d37] </parentGuardian>

[d38] <primaryCarePhysician>

[d39] <physicianName>

[d40] <first>Julius</first>

[d41] <last>Hibbert</last>

[d42] </physicianName>

[d43] <physicianContact>

[d44] <street>1 First St</street>

[d45] <city>Springfield</city>

[d46] <state>MA</state>

[d47] <zip>12345</zip>

[d48] <phone>555.123.9012</phone>

[d49] <fax>555.123.9013</fax>

[d50] <email/>

[d51] </physicianContact>

[d52] <registrationID>ABC123</registrationID>

[d53] </primaryCarePhysician>

[d54] <insurer>

[d55] <name>Blue Cross</name>

[d56] <street>1234 Main St</street>

[d57] <city>Springfield</city>

[d58] <state>MA</state>

[d59] <zip>12345</zip>

[d60] <phone>555.123.5678</phone>

[d61] <fax>555.123.5679</fax>

[d62] <email/>

[d63] </insurer>

[d64] <medical>

[d65] <treatment>

[d66] <drug>

[d67] <name>methylphenidate hydrochloride</name>

[d68] <dailyDosage>30mgs</dailyDosage>

[d69] <startDate>1999-01-12</startDate>

[d70] </drug>

[d71] <comment>

[d72] patient exhibits side-effects of skin coloration and carpal degeneration

[d73] </comment>

[d74] </treatment>

[d75] <result>

[d76] <test>blood pressure</test>

[d77] <value>120/80</value>

[d78] <date>2001-06-09</date>

[d79] <performedBy>Nurse Betty</performedBy>

[d80] </result>

[d81] </medical>

[d82] </record>

4.2.2 Example request context

The following example illustrates a request context to which the example rules may be applicable. It represents a request by the physician Julius Hibbert to read the patient date of birth in the record of Bartholomew Simpson.

[e1] <?xml version="1.0" encoding="UTF-8"?>

[e2] <Request xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17"

[e3] xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

[e4] xsi:schemaLocation="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17 http://docs.oasis-open.org/xacml/3.0/xacml-core-v3-schema-wd-17.xsd"

[e5] ReturnPolicyIdList="false">

[e6] <Attributes

[e7] Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject">

[e8] <Attribute IncludeInResult="false"

[e9] AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id"

[e10] Issuer="med.example.com">

[e11] <AttributeValue

[e12] DataType="http://www.w3.org/2001/XMLSchema#string">CN=Julius Hibbert</AttributeValue>

[e13] </Attribute>

[e14] <Attribute IncludeInResult="false"

[e15] AttributeId="urn:oasis:names:tc:xacml:3.0:example:attribute:role"

[e16] Issuer="med.example.com">

[e17] <AttributeValue

[e18] DataType="http://www.w3.org/2001/XMLSchema#string"

[e19] >physician</AttributeValue>

[e20] </Attribute>

[e21] <Attribute IncludeInResult="false"

[e22] AttributeId="urn:oasis:names:tc:xacml:3.0:example:attribute:physician-id"

[e23] Issuer="med.example.com">

[e24] <AttributeValue

[e25] DataType="http://www.w3.org/2001/XMLSchema#string">jh1234</AttributeValue>

[e26] </Attribute>

[e27] </Attributes>

[e28] <Attributes

[e29] Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource">

[e30] <Content>

[e31] <md:record xmlns:md="urn:example:med:schemas:record"

[e32] xsi:schemaLocation="urn:example:med:schemas:record

[e33] http://www.med.example.com/schemas/record.xsd">

[e34] <md:patient>

[e35] <md:patientDoB>1992-03-21</md:patientDoB>

[e36] <md:patient-number>555555</md:patient-number>

[e37] <md:patientContact>

[e38] <md:email>b.simpson@example.com</md:email>

[e39] </md:patientContact>

[e40] </md:patient>

[e41] </md:record>

[e42] </Content>

[e43] <Attribute IncludeInResult="false"

[e44] AttributeId="urn:oasis:names:tc:xacml:3.0:content-selector" >

[e45] <AttributeValue

[e46] XPathCategory="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"

[e47] DataType=" urn:oasis:names:tc:xacml:3.0:data-type:xpathExpression"

[e48] >md:record/md:patient/md:patientDoB</AttributeValue>

[e49] </Attribute>

[e50] <Attribute IncludeInResult="false"

[e51] AttributeId="urn:oasis:names:tc:xacml:2.0:resource:target-namespace" >

[e52] <AttributeValue

[e53] DataType="http://www.w3.org/2001/XMLSchema#anyURI"

[e54] >urn:example:med:schemas:record</AttributeValue>

[e55] </Attribute>

[e56] </Attributes>

[e57] <Attributes

[e58] Category="urn:oasis:names:tc:xacml:3.0:attribute-category:action">

[e59] <Attribute IncludeInResult="false"

[e60] AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id" >

[e61] <AttributeValue

[e62] DataType="http://www.w3.org/2001/XMLSchema#string">read</AttributeValue>

[e63] </Attribute>

[e64] </Attributes>

[e65] <Attributes

[e66] Category="urn:oasis:names:tc:xacml:3.0:attribute-category:environment">

[e67] <Attribute IncludeInResult="false"

[e68] AttributeId="urn:oasis:names:tc:xacml:1.0:environment:current-date" >

[e69] <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#date"

[e70] >2010-01-11</AttributeValue>

[e71] </Attribute>

[e72] </Attributes>

[e73] </Request>

[e2] - [e4] Standard namespace declarations.

[e6] - [e27] Access subject attributes are placed in the urn:oasis:names:tc:xacml:1.0:subject-category:access-subject attribute category of the <Request> element. Each attribute consists of the attribute meta-data and the attribute value. There is only one subject involved in this request. This value of the attribute category denotes the identity for which the request was issued.

[e8] - [e13] Subject subject-id attribute.

[e14] - [e20] Subject role attribute.

[e21] - [e26] Subject physician-id attribute.

[e28] - [e56] Resource attributes are placed in the urn:oasis:names:tc:xacml:3.0:attribute-category:resource attribute category of the <Request> element. Each attribute consists of attribute meta-data and an attribute value.

[e30] - [e42] Resource content. The XML resource instance, access to all or part of which may be requested, is placed here.

[e43] - [e49] The identifier of the Resource instance for which access is requested, which is an XPath expression into the <Content> element that selects the data to be accessed.

[e57] - [e64] Action attributes are placed in the urn:oasis:names:tc:xacml:3.0:attribute-category:action attribute category of the <Request> element.

[e59] - [e63] Action identifier.

4.2.3 Example plain-language rules

The following plain-language rules are to be enforced:

Rule 1: A person, identified by his or her patient number, may read any record for which he or she is the designated patient.

Rule 2: A person may read any record for which he or she is the designated parent or guardian, and for which the patient is under 16 years of age.

Rule 3: A physician may write to any medical element for which he or she is the designated primary care physician, provided an email is sent to the patient.

Rule 4: An administrator shall not be permitted to read or write to medical elements of a patient record.

These rules may be written by different PAPs operating independently, or by a single PAP.

4.2.4 Example XACML rule instances

4.2.4.1 Rule 1

Rule 1 illustrates a simple rule with a single <Condition> element. It also illustrates the use of the <VariableDefinition> element to define a function that may be used throughout the policy. The following XACML <Rule> instance expresses Rule 1:

[f1] <?xml version="1.0" encoding="UTF-8"?>

[f2] <Policy

[f3] xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17"

[f4] xmlns:xacml ="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17"

[f5] xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

[f6] xmlns:md="http://www.med.example.com/schemas/record.xsd"

[f7] PolicyId="urn:oasis:names:tc:xacml:3.0:example:policyid:1"

[f8] RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:deny-overrides"

[f9] Version="1.0">

[f10] <PolicyDefaults>

[f11] <XPathVersion>http://www.w3.org/TR/1999/REC-xpath-19991116</XPathVersion>

[f12] </PolicyDefaults>

[f13] <Target/>

[f14] <VariableDefinition VariableId="17590034">

[f15] <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-equal">

[f16] <Apply

[f17] FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-one-and-only">

[f18] <AttributeDesignator

[f19] MustBePresent="false"

[f20] Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject"

[f21] AttributeId="urn:oasis:names:tc:xacml:3.0:example:attribute:patient-number"

[f22] DataType="http://www.w3.org/2001/XMLSchema#string"/>

[f23] </Apply>

[f24] <Apply

[f25] FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-one-and-only">

[f26] <AttributeSelector

[f27] MustBePresent="false"

[f28] Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"

[f29] RequestContextPath="md:record/md:patient/md:patient-number/text()"

[f30] DataType="http://www.w3.org/2001/XMLSchema#string"/>

[f31] </Apply>

[f32] </Apply>

[f33] </VariableDefinition>

[f34] <Rule

[f35] RuleId="urn:oasis:names:tc:xacml:3.0:example:ruleid:1"

[f36] Effect="Permit">

[f37] <Description>

[f38] A person may read any medical record in the

[f39] http://www.med.example.com/schemas/record.xsd namespace

[f40] for which he or she is the designated patient

[f45] <Match MatchId="urn:oasis:names:tc:xacml:1.0:function:anyURI-equal">

[f46] <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#anyURI"

[f47] >urn:example:med:schemas:record </AttributeValue>

[f48] <AttributeDesignator

[f49] MustBePresent="false"

[f50] Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"

[f51] AttributeId="urn:oasis:names:tc:xacml:2.0:resource:target-namespace"

[f52] DataType="http://www.w3.org/2001/XMLSchema#anyURI"/>

[f53] </Match>

[f54] <Match

[f55] MatchId="urn:oasis:names:tc:xacml:3.0:function:xpath-node-match">

[f56] <AttributeValue

[f57] DataType="urn:oasis:names:tc:xacml:3.0:data-type:xpathExpression"

[f58] XPathCategory="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"

[f59] >md:record</AttributeValue>

[f60] <AttributeDesignator

[f61] MustBePresent="false"

[f62] Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"

[f63] AttributeId="urn:oasis:names:tc:xacml:3.0:content-selector"

[f64] DataType="urn:oasis:names:tc:xacml:3.0:data-type:xpathExpression"/>

[f71] MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">

[f72] <AttributeValue

[f73] DataType="http://www.w3.org/2001/XMLSchema#string"

[f74] >read</AttributeValue>

[f75] <AttributeDesignator

[f76] MustBePresent="false"

[f77] Category="urn:oasis:names:tc:xacml:3.0:attribute-category:action"

[f78] AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id"

[f79] DataType="http://www.w3.org/2001/XMLSchema#string"/>

[f85] <VariableReference VariableId="17590034"/>

[f86] </Condition>

[f87] </Rule>

[f88] </Policy>

[f3] - [f6] XML namespace declarations.

[f11] XPath expressions in the policy are to be interpreted according to the 1.0 version of the XPath specification.

[f14] - [f33] A <VariableDefinition> element. It defines a function that evaluates the truth of the statement: the patient-number subject attribute is equal to the patient-number in the resource.

[f15] The FunctionId attribute names the function to be used for comparison. In this case, comparison is done with the “urn:oasis:names:tc:xacml:1.0:function:string-equal” function; this function takes two arguments of type “http://www.w3.org/2001/XMLSchema#string”.

[f17] The first argument of the variable definition is a function specified by the FunctionId attribute. Since urn:oasis:names:tc:xacml:1.0:function:string-equal takes arguments of type “http://www.w3.org/2001/XMLSchema#string” and AttributeDesignator selects a bag of type “http://www.w3.org/2001/XMLSchema#string”, “urn:oasis:names:tc:xacml:1.0:function:string-one-and-only” is used. This function guarantees that its argument evaluates to a bag containing exactly one value.

[f18] The AttributeDesignator selects a bag of values for the patient-number subject attribute in the request context.

[f25] The second argument of the variable definition is a function specified by the FunctionId attribute. Since “urn:oasis:names:tc:xacml:1.0:function:string-equal” takes arguments of type “http://www.w3.org/2001/XMLSchema#string” and the AttributeSelector selects a bag of type “http://www.w3.org/2001/XMLSchema#string”, “urn:oasis:names:tc:xacml:1.0:function:string-one-and-only” is used. This function guarantees that its argument evaluates to a bag containing exactly one value.

[f26] The <AttributeSelector> element selects a bag of values from the resource content using a free-form XPath expression. In this case, it selects the value of the patient-number in the resource. Note that the namespace prefixes in the XPath expression are resolved with the standard XML namespace declarations.

[f35] Rule identifier.

[f36] Rule effect declaration. When a rule evaluates to ‘True’ it emits the value of the Effect attribute. This value is then combined with the Effect values of other rules according to the rule-combining algorithm.

[f37] - [f41] Free form description of the rule.

[f42] - [f83] A rule target defines a set of decision requests that the rule is intended to evaluate.

[f43] - [f67] The <AnyOf> element contains a disjunctive sequence of <AllOf> elements. In this example, there is just one.

[f44] - [f66] The <AllOf> element encloses the conjunctive sequence of Match elements. In this example, there are two.

[f45] - [f53] The first <Match> element compares its first and second child elements according to the matching function. A match is positive if the value of the first argument matches any of the values selected by the second argument. This match compares the target namespace of the requested document with the value of “urn:example:med:schemas:record”.

[f45] The MatchId attribute names the matching function.

[f46] - [f47] Literal attribute value to match.

[f48] - [f52] The <AttributeDesignator> element selects the target namespace from the resource contained in the request context. The attribute name is specified by the AttributeId.

[f54] - [f65] The second <Match> element. This match compares the results of two XPath expressions applied to the <Content> element of the resource category. The second XPath expression is the location path to the requested XML element and the first XPath expression is the literal value “md:record”. The “xpath-node-match” function evaluates to “True” if the requested XML element is below the “md:record” element.

[f68] - [f82] The <AnyOf> element contains a disjunctive sequence of <AllOf> elements. In this case, there is just one <AllOf> element.

[f69] - [f81] The <AllOf> element contains a conjunctive sequence of <Match> elements. In this case, there is just one <Match> element.

[f70] - [f80] The <Match> element compares its first and second child elements according to the matching function. The match is positive if the value of the first argument matches any of the values selected by the second argument. In this case, the value of the action-id action attribute in the request context is compared with the literal value “read”.

[f84] - [f86] The <Condition> element. A condition must evaluate to “True” for the rule to be applicable. This condition contains a reference to a variable definition defined elsewhere in the policy.

4.2.4.2 Rule 2

Rule 2 illustrates the use of a mathematical function, i.e. the <Apply> element with functionId "urn:oasis:names:tc:xacml:1.0:function:date-add-yearMonthDuration" to calculate the date of the patient’s sixteenth birthday. It also illustrates the use of predicate expressions, with the functionId "urn:oasis:names:tc:xacml:1.0:function:and". This example has one function embedded in the <Condition> element and another one referenced in a <VariableDefinition> element.

[g1] <?xml version="1.0" encoding="UTF-8"?>

[g2] <Policy

[g3] xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17"

[g4] xmlns:xacml="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17"

[g5] xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

[g6] xmlns:xf="http://www.w3.org/2005/xpath-functions"

[g7] xmlns:md="http:www.med.example.com/schemas/record.xsd"

[g8] PolicyId="urn:oasis:names:tc:xacml:3.0:example:policyid:2"

[g9] Version="1.0"

[g10] RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:deny-overrides">

[g11] <PolicyDefaults>

[g12] <XPathVersion>http://www.w3.org/TR/1999/REC-xpath-19991116</XPathVersion>

[g13] </PolicyDefaults>

[g14] <Target/>

[g15] <VariableDefinition VariableId="17590035">

[g16] <Apply

[g17] FunctionId="urn:oasis:names:tc:xacml:1.0:function:date-less-or-equal">

[g18] <Apply

[g19] FunctionId="urn:oasis:names:tc:xacml:1.0:function:date-one-and-only">

[g20] <AttributeDesignator

[g21] MustBePresent="false"

[g22] Category="urn:oasis:names:tc:xacml:3.0:attribute-category:environment"

[g23] AttributeId="urn:oasis:names:tc:xacml:1.0:environment:current-date"

[g24] DataType="http://www.w3.org/2001/XMLSchema#date"/>

[g25] </Apply>

[g26] <Apply

[g27] FunctionId="urn:oasis:names:tc:xacml:1.0:function:date-add-yearMonthDuration">

[g28] <Apply

[g29] FunctionId="urn:oasis:names:tc:xacml:1.0:function:date-one-and-only">

[g30] <AttributeSelector

[g31] MustBePresent="false"

[g32] Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"

[g33] RequestContextPath="md:record/md:patient/md:patientDoB/text()"

[g34] DataType="http://www.w3.org/2001/XMLSchema#date"/>

[g35] </Apply>

[g36] <AttributeValue

[g37] DataType="http://www.w3.org/2001/XMLSchema#yearMonthDuration"

[g38] >P16Y </AttributeValue>

[g39] </Apply>

[g40] </Apply>

[g41] </VariableDefinition>

[g42] <Rule

[g43] RuleId="urn:oasis:names:tc:xacml:3.0:example:ruleid:2"

[g44] Effect="Permit">

[g45] <Description>

[g46] A person may read any medical record in the

[g47] http://www.med.example.com/records.xsd namespace

[g48] for which he or she is the designated parent or guardian,

[g49] and for which the patient is under 16 years of age

[g50] </Description>

[g51] <Target>

[g52] <AnyOf>

[g53] <AllOf>

[g54] <Match

[g55] MatchId="urn:oasis:names:tc:xacml:1.0:function:anyURI-equal">

[g56] <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#anyURI"

[g57] >urn:example:med:schemas:record</AttributeValue>

[g58] <AttributeDesignator

[g59] MustBePresent="false"

[g60] Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"

[g61] AttributeId= "urn:oasis:names:tc:xacml:2.0:resource:target-namespace"

[g62] DataType="http://www.w3.org/2001/XMLSchema#anyURI"/>

[g63] </Match>

[g64] <Match

[g65] MatchId="urn:oasis:names:tc:xacml:3.0:function:xpath-node-match">

[g66] <AttributeValue

[g67] DataType="urn:oasis:names:tc:xacml:3.0:data-type:xpathExpression"

[g68] XPathCategory="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"

[g69] >md:record</AttributeValue>

[g70] <AttributeDesignator

[g71] MustBePresent="false"

[g72] Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"

[g73] AttributeId="urn:oasis:names:tc:xacml:3.0:content-selector"

[g74] DataType="urn:oasis:names:tc:xacml:3.0:data-type:xpathExpression"/>

[g75] </Match>

[g76] </AllOf>

[g77] </AnyOf>

[g78] <AnyOf>

[g79] <AllOf>

[g80] <Match

[g81] MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">

[g82] <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string"

[g83] >read</AttributeValue>

[g84] <AttributeDesignator

[g85] MustBePresent="false"

[g86] Category="urn:oasis:names:tc:xacml:3.0:attribute-category:action"

[g87] AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id"

[g88] DataType="http://www.w3.org/2001/XMLSchema#string"/>

[g89] </Match>

[g90] </AllOf>

[g91] </AnyOf>

[g92] </Target>

[g93] <Condition>

[g94] <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:and">

[g95] <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-equal">

[g96] <Apply

[g97] FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-one-and-only">

[g98] <AttributeDesignator

[g99] MustBePresent="false"

[g100] Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject"

[g101] AttributeId="urn:oasis:names:tc:xacml:3.0:example:attribute:parent-guardian-id"

[g102] DataType="http://www.w3.org/2001/XMLSchema#string"/>

[g103] </Apply>

[g104] <Apply

[g105] FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-one-and-only">

[g106] <AttributeSelector

[g107] MustBePresent="false"

[g108] Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"

[g109] RequestContextPath="md:record/md:parentGuardian/md:parentGuardianId/text()"

[g110] DataType="http://www.w3.org/2001/XMLSchema#string"/>

[g111] </Apply>

[g112] </Apply>

[g113] <VariableReference VariableId="17590035"/>

[g114] </Apply>

[g115] </Condition>

[g116] </Rule>

[g117] </Policy>

[g15] - [g41] The <VariableDefinition> element contains part of the condition (i.e. is the patient under 16 years of age?). The patient is under 16 years of age if the current date is less than the date computed by adding 16 to the patient’s date of birth.

[g16] - [g40] “urn:oasis:names:tc:xacml:1.0:function:date-less-or-equal” is used to compare the two date arguments.

[g18] - [g25] The first date argument uses “urn:oasis:names:tc:xacml:1.0:function:date-one-and-only“ to ensure that the bag of values selected by its argument contains exactly one value of type “http://www.w3.org/2001/XMLSchema#date”.

[g20] The current date is evaluated by selecting the “urn:oasis:names:tc:xacml:1.0:environment:current-date” environment attribute.

[g26] - [g39] The second date argument uses “urn:oasis:names:tc:xacml:1.0:function:date-add-yearMonthDuration” to compute the date of the patient’s sixteenth birthday by adding 16 years to the patient’s date of birth. The first of its arguments is of type “http://www.w3.org/2001/XMLSchema#date” and the second is of type “http://www.w3.org/TR/2007/REC-xpath-functions-20070123/#dt-yearMonthDuration”.

[g30] The <AttributeSelector> element selects the patient’s date of birth by taking the XPath expression over the resource content.

[g36] - [g38] Year Month Duration of 16 years.

[g51] - [g92] Rule declaration and rule target. See Rule 1 in Section 4.2.4.1 for the detailed explanation of these elements.

[g93] - [g115] The <Condition> element. The condition must evaluate to “True” for the rule to be applicable. This condition evaluates the truth of the statement: the requestor is the designated parent or guardian and the patient is under 16 years of age. It contains one embedded <Apply> element and one referenced <VariableDefinition> element.

[g94] The condition uses the “urn:oasis:names:tc:xacml:1.0:function:and” function. This is a Boolean function that takes one or more Boolean arguments (2 in this case) and performs the logical “AND” operation to compute the truth value of the expression.

[g95] - [g112] The first part of the condition is evaluated (i.e. is the requestor the designated parent or guardian?). The function is “urn:oasis:names:tc:xacml:1.0:function:string-equal” and it takes two arguments of type “http://www.w3.org/2001/XMLSchema#string”.

[g96] designates the first argument. Since “urn:oasis:names:tc:xacml:1.0:function:string-equal” takes arguments of type “http://www.w3.org/2001/XMLSchema#string”, “urn:oasis:names:tc:xacml:1.0:function:string-one-and-only” is used to ensure that the subject attribute “urn:oasis:names:tc:xacml:3.0:example:attribute:parent-guardian-id” in the request context contains exactly one value.

[g98] designates the first argument. The value of the subject attribute “urn:oasis:names:tc:xacml:3.0:example:attribute:parent-guardian-id” is selected from the request context using the <AttributeDesignator> element.

[g104] As above, the “urn:oasis:names:tc:xacml:1.0:function:string-one-and-only” is used to ensure that the bag of values selected by it’s argument contains exactly one value of type “http://www.w3.org/2001/XMLSchema#string”.

[g106] The second argument selects the value of the <md:parentGuardianId> element from the resource content using the <AttributeSelector> element. This element contains a free-form XPath expression, pointing into the <Content> element of the resource category. Note that all namespace prefixes in the XPath expression are resolved with standard namespace declarations. The AttributeSelector evaluates to the bag of values of type “http://www.w3.org/2001/XMLSchema#string”.

[g113] references the <VariableDefinition> element, where the second part of the condition is defined.

4.2.4.3 Rule 3

Rule 3 illustrates the use of an obligation expression.

[h1] <?xml version="1.0" encoding="UTF-8"?>

[h2] <Policy

[h3] xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17"

[h4] xmlns:xacml ="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17"

[h5] xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

[h6] xsi:schemaLocation="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17 http://docs.oasis-open.org/xacml/3.0/xacml-core-v3-schema-wd-17.xsd"

[h7] xmlns:md="http:www.med.example.com/schemas/record.xsd"

[h8] PolicyId="urn:oasis:names:tc:xacml:3.0:example:policyid:3"

[h9] Version="1.0"

[h10] RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:deny-overrides">

[h11] <Description>

[h12] Policy for any medical record in the

[h13] http://www.med.example.com/schemas/record.xsd namespace

[h14] </Description>

[h15] <PolicyDefaults>

[h16] <XPathVersion>http://www.w3.org/TR/1999/REC-xpath-19991116</XPathVersion>

[h17] </PolicyDefaults>

[h18] <Target>

[h19] <AnyOf>

[h20] <AllOf>

[h21] <Match

[h22] MatchId="urn:oasis:names:tc:xacml:1.0:function:anyURI-equal">

[h23] <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#anyURI"

[h24] >urn:example:med:schemas:record</AttributeValue>

[h25] <AttributeDesignator

[h26] MustBePresent="false"

[h27] Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"

[h28] AttributeId="urn:oasis:names:tc:xacml:2.0:resource:target-namespace"

[h29] DataType="http://www.w3.org/2001/XMLSchema#anyURI"/>

[h30] </Match>

[h31] </AllOf>

[h32] </AnyOf>

[h33] </Target>

[h34] <Rule RuleId="urn:oasis:names:tc:xacml:3.0:example:ruleid:3"

[h35] Effect="Permit">

[h36] <Description>

[h37] A physician may write any medical element in a record

[h38] for which he or she is the designated primary care

[h39] physician, provided an email is sent to the patient

[h40] </Description>

[h41] <Target>

[h42] <AnyOf>

[h43] <AllOf>

[h44] <Match

[h45] MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">

[h46] <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string"

[h47] >physician</AttributeValue>

[h48] <AttributeDesignator

[h49] MustBePresent="false"

[h50] Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject"

[h51] AttributeId="urn:oasis:names:tc:xacml:3.0:example:attribute:role"

[h52] DataType="http://www.w3.org/2001/XMLSchema#string"/>

[h53] </Match>

[h54] </AllOf>

[h55] </AnyOf>

[h56] <AnyOf>

[h57] <AllOf>

[h58] <Match

[h59] MatchId="urn:oasis:names:tc:xacml:3.0:function:xpath-node-match">

[h60] <AttributeValue

[h61] DataType="urn:oasis:names:tc:xacml:3.0:data-type:xpathExpression"

[h62] XPathCategory="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"

[h63] >md:record/md:medical</AttributeValue>

[h64] <AttributeDesignator

[h65] MustBePresent="false"

[h66] Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"

[h67] AttributeId="urn:oasis:names:tc:xacml:3.0:content-selector"

[h68] DataType="urn:oasis:names:tc:xacml:3.0:data-type:xpathExpression"/>

[h69] </Match>

[h70] </AllOf>

[h71] </AnyOf>

[h72] <AnyOf>

[h73] <AllOf>

[h74] <Match

[h75] MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">

[h76] <AttributeValue

[h77] DataType="http://www.w3.org/2001/XMLSchema#string"

[h78] >write</AttributeValue>

[h79] <AttributeDesignator

[h80] MustBePresent="false"

[h81] Category="urn:oasis:names:tc:xacml:3.0:attribute-category:action"

[h82] AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id"

[h83] DataType="http://www.w3.org/2001/XMLSchema#string"/>

[h84] </Match>

[h85] </AllOf>

[h86] </AnyOf>

[h87] </Target>

[h88] <Condition>

[h89] <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-equal">

[h90] <Apply

[h91] FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-one-and-only">

[h92] <AttributeDesignator

[h93] MustBePresent="false"

[h94] Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject"

[h95] AttributeId="urn:oasis:names:tc:xacml:3.0:example: attribute:physician-id"

[h96] DataType="http://www.w3.org/2001/XMLSchema#string"/>

[h97] </Apply>

[h98] <Apply

[h99] FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-one-and-only">

[h100] <AttributeSelector

[h101] MustBePresent="false"

[h102] Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"

[h103] RequestContextPath="md:record/md:primaryCarePhysician/md:registrationID/text()"

[h104] DataType="http://www.w3.org/2001/XMLSchema#string"/>

[h105] </Apply>

[h106] </Apply>

[h107] </Condition>

[h108] </Rule>

[h109] <ObligationExpressions>

[h110] <ObligationExpression ObligationId="urn:oasis:names:tc:xacml:example:obligation:email"

[h111] FulfillOn="Permit">

[h112] <AttributeAssignmentExpression

[h113] AttributeId="urn:oasis:names:tc:xacml:3.0:example:attribute:mailto">

[h114] <AttributeSelector

[h115] MustBePresent="true"

[h116] Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"

[h117] RequestContextPath="md:record/md:patient/md:patientContact/md:email"

[h118] DataType="http://www.w3.org/2001/XMLSchema#string"/>

[h119] </AttributeAssignmentExpression>

[h120] <AttributeAssignmentExpression

[h121] AttributeId="urn:oasis:names:tc:xacml:3.0:example:attribute:text">

[h122] <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string"

[h123] >Your medical record has been accessed by:</AttributeValue>

[h124] </AttributeAssignmentExpression>

[h125] <AttributeAssignmentExpression

[h126] AttributeId="urn:oasis:names:tc:xacml:3.0:example:attribute:text">

[h127] <AttributeDesignator

[h128] MustBePresent="false"

[h129] Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject"

[h130] AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id"

[h131] DataType="http://www.w3.org/2001/XMLSchema#string"/>

[h132] </AttributeAssignmentExpression>

[h133] </ObligationExpression>

[h134] </ObligationExpressions>

[h135] </Policy>

[h2] - [h10] The <Policy> element includes standard namespace declarations as well as policy specific parameters, such as PolicyId and RuleCombiningAlgId.

[h8] Policy identifier. This parameter allows the policy to be referenced by a policy set.

[h10] The Rule-combining algorithm identifies the algorithm for combining the outcomes of rule evaluation.

[h11] - [h14] Free-form description of the policy.

[h18] - [h33] Policy target. The policy target defines a set of applicable decision requests. The structure of the <Target> element in the <Policy> is identical to the structure of the <Target> element in the <Rule>. In this case, the policy target is the set of all XML resources that conform to the namespace “urn:example:med:schemas:record”.

[h34] - [h108] The only <Rule> element included in this <Policy>. Two parameters are specified in the rule header: RuleId and Effect.

[h41] - [h87] The rule target further constrains the policy target.

[h44] - [h53] The <Match> element targets the rule at subjects whose “urn:oasis:names:tc:xacml:3.0:example:attribute:role” subject attribute is equal to “physician”.

[h58] - [h69] The <Match> element targets the rule at resources that match the XPath expression “md:record/md:medical”.

[h74] - [h84] The <Match> element targets the rule at actions whose “urn:oasis:names:tc:xacml:1.0:action:action-id” action attribute is equal to “write”.

[h88] - [h107] The <Condition> element. For the rule to be applicable to the decision request, the condition must evaluate to “True”. This condition compares the value of the “urn:oasis:names:tc:xacml:3.0:example:attribute:physician-id” subject attribute with the value of the <registrationId> element in the medical record that is being accessed.

[h109] - [h134] The <ObligationExpressions> element. Obligations are a set of operations that must be performed by the PEP in conjunction with an authorization decision. An obligation may be associated with a “Permit” or “Deny” authorization decision. The element contains a single obligation expression, which will be evaluated into an obligation when the policy is evaluated.

[h110] - [h133] The <ObligationExpression> element consists of the ObligationId attribute, the authorization decision value for which it must be fulfilled, and a set of attribute assignments.

[h110] The ObligationId attribute identifies the obligation. In this case, the PEP is required to send email.

[h111] The FulfillOn attribute defines the authorization decision value for which the obligation derived from the obligation expression must be fulfilled. In this case, the obligation must be fulfilled when access is permitted.

[h112] - [h119] The first parameter indicates where the PEP will find the email address in the resource. The PDP will evaluate the <AttributeSelector> and return the result to the PEP inside the resulting obligation.

[h120] - [h123] The second parameter contains literal text for the email body.

[h125] - [h132] The third parameter indicates where the PEP will find further text for the email body in the resource. The PDP will evaluate the <AttributeDesignator> and return the result to the PEP inside the resulting obligation.

4.2.4.4 Rule 4

Rule 4 illustrates the use of the "Deny" Effect value, and a <Rule> with no <Condition> element.

[i1] <?xml version="1.0" encoding="UTF-8"?>

[i2] <Policy

[i3] xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17"

[i4] xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

[i5] xmlns:md="http:www.med.example.com/schemas/record.xsd"

[i6] PolicyId="urn:oasis:names:tc:xacml:3.0:example:policyid:4"

[i7] Version="1.0"

[i8] RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:deny-overrides">

[i9] <PolicyDefaults>

[i10] <XPathVersion>http://www.w3.org/TR/1999/REC-xpath-19991116</XPathVersion>

[i11] </PolicyDefaults>

[i12] <Target/>

[i13] <Rule

[i14] RuleId="urn:oasis:names:tc:xacml:3.0:example:ruleid:4"

[i15] Effect="Deny">

[i16] <Description>

[i17] An Administrator shall not be permitted to read or write

[i18] medical elements of a patient record in the

[i19] http://www.med.example.com/records.xsd namespace.

[i20] </Description>

[i21] <Target>

[i22] <AnyOf>

[i23] <AllOf>

[i24] <Match

[i25] MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">

[i26] <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string"

[i27] >administrator</AttributeValue>

[i28] <AttributeDesignator

[i29] MustBePresent="false"

[i30] Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject"

[i31] AttributeId="urn:oasis:names:tc:xacml:3.0:example:attribute:role"

[i32] DataType="http://www.w3.org/2001/XMLSchema#string"/>

[i33] </Match>

[i34] </AllOf>

[i35] </AnyOf>

[i36] <AnyOf>

[i37] <AllOf>

[i38] <Match

[i39] MatchId="urn:oasis:names:tc:xacml:1.0:function:anyURI-equal">

[i40] <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#anyURI"

[i41] >urn:example:med:schemas:record</AttributeValue>

[i42] <AttributeDesignator

[i43] MustBePresent="false"

[i44] Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"

[i45] AttributeId="urn:oasis:names:tc:xacml:2.0:resource:target-namespace"

[i46] DataType="http://www.w3.org/2001/XMLSchema#anyURI"/>

[i47] </Match>

[i48] <Match

[i49] MatchId="urn:oasis:names:tc:xacml:3.0:function:xpath-node-match">

[i50] <AttributeValue

[i51] DataType="urn:oasis:names:tc:xacml:3.0:data-type:xpathExpression"

[i52] XPathCategory="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"

[i53] >md:record/md:medical</AttributeValue>

[i54] <AttributeDesignator

[i55] MustBePresent="false"

[i56] Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"

[i57] AttributeId="urn:oasis:names:tc:xacml:3.0:content-selector"

[i58] DataType="urn:oasis:names:tc:xacml:3.0:data-type:xpathExpression"/>

[i60] </AllOf>

[i63] <AllOf>

[i65] MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">

[i66] <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string"

[i67] >read</AttributeValue>

[i68] <AttributeDesignator

[i69] MustBePresent="false"

[i70] Category="urn:oasis:names:tc:xacml:3.0:attribute-category:action"

[i71] AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id"

[i72] DataType="http://www.w3.org/2001/XMLSchema#string"/>

[i73] </Match>

[i74] </AllOf>

[i75] <AllOf>

[i76] <Match

[i77] MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">

[i78] <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string"

[i79] >write</AttributeValue>

[i80] <AttributeDesignator

[i81] MustBePresent="false"

[i82] Category="urn:oasis:names:tc:xacml:3.0:attribute-category:action"

[i83] AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id"

[i84] DataType="http://www.w3.org/2001/XMLSchema#string"/>

[i85] </Match>

[i86] </AllOf>

[i87] </AnyOf>

[i88] </Target>

[i89] </Rule>

[i90] </Policy>

[i13] - [i15] The <Rule> element declaration.

[i15] Rule Effect. Every rule that evaluates to “True” emits the rule effect as its value. This rule Effect is “Deny” meaning that according to this rule, access must be denied when it evaluates to “True”.

[i16] - [i20] Free form description of the rule.

[i21] - [i88] Rule target. The Rule target defines the set of decision requests that are applicable to the rule.

[i24] - [i33] The <Match> element targets the rule at subjects whose “urn:oasis:names:tc:xacml:3.0:example:attribute:role” subject attribute is equal to “administrator”.

[i36] - [i61] The <AnyOf> element contains one <AllOf> element, which (in turn) contains two <Match> elements. The target matches if the resource identified by the request context matches both resource match criteria.

[i38] - [i47] The first <Match> element targets the rule at resources whose “urn:oasis:names:tc:xacml:2.0:resource:target-namespace” resource attribute is equal to “urn:example:med:schemas:record”.

[i48] - [i59] The second <Match> element targets the rule at XML elements that match the XPath expression “/md:record/md:medical”.

[i62] - [i87] The <AnyOf> element contains two <AllOf> elements, each of which contains one <Match> element. The target matches if the action identified in the request context matches either of the action match criteria.

[i64] - [i85] The <Match> elements target the rule at actions whose “urn:oasis:names:tc:xacml:1.0:action:action-id” action attribute is equal to ”read” or “write”.

This rule does not have a <Condition> element.

4.2.4.5 Example PolicySet

This section uses the examples of the previous sections to illustrate the process of combining policies. The policy governing read access to medical elements of a record is formed from each of the four rules described in Section 4.2.3. In plain language, the combined rule is:

· Either the requestor is the patient; or

· the requestor is the parent or guardian and the patient is under 16; or

· the requestor is the primary care physician and a notification is sent to the patient; and

· the requestor is not an administrator.

The following policy set illustrates the combined policies. Policy 3 is included by reference and policy 2 is explicitly included.

[j1] <?xml version="1.0" encoding="UTF-8"?>

[j2] <PolicySet

[j3] xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17"

[j4] xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

[j5] PolicySetId="urn:oasis:names:tc:xacml:3.0:example:policysetid:1"

[j6] Version="1.0"

[j7] PolicyCombiningAlgId=

[j8] "urn:oasis:names:tc:xacml:1.0:policy-combining-algorithm:deny-overrides">

[j9] <Description>

[j10] Example policy set.

[j11] </Description>

[j12] <Target>

[j13] <AnyOf>

[j14] <AllOf>

[j15] <Match

[j16] MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">

[j17] <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string"

[j18] >urn:example:med:schema:records</AttributeValue>

[j19] <AttributeDesignator

[j20] MustBePresent="false"

[j21] Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"

[j22] AttributeId="urn:oasis:names:tc:xacml:2.0:resource:target-namespace"

[j23] DataType="http://www.w3.org/2001/XMLSchema#string"/>

[j24] </Match>

[j25] </AllOf>

[j26] </AnyOf>

[j27] </Target>

[j28] <PolicyIdReference>

[j29] urn:oasis:names:tc:xacml:3.0:example:policyid:3

[j30] </PolicyIdReference>

[j31] <Policy

[j32] PolicyId="urn:oasis:names:tc:xacml:3.0:example:policyid:2"

[j33] RuleCombiningAlgId=

[j34] "urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:deny-overrides"

[j35] Version="1.0">

[j36] <Target/>

[j37] <Rule RuleId="urn:oasis:names:tc:xacml:3.0:example:ruleid:1"

[j38] Effect="Permit">

[j39] </Rule>

[j40] <Rule RuleId="urn:oasis:names:tc:xacml:3.0:example:ruleid:2"

[j41] Effect="Permit">

[j42] </Rule>

[j43] <Rule RuleId="urn:oasis:names:tc:xacml:3.0:example:ruleid:4"

[j44] Effect="Deny">

[j45] </Rule>

[j46] </Policy>

[j47] </PolicySet>

[j2] - [j8] The <PolicySet> element declaration. Standard XML namespace declarations are included.

[j5] The PolicySetId attribute is used for identifying this policy set for possible inclusion in another policy set.

[j7] - [j8] The policy-combining algorithm identifier. Policies and policy sets in this policy set are combined according to the specified policy-combining algorithm when the authorization decision is computed.

[j9] - [j11] Free form description of the policy set.

[j12] - [j27] The policy set <Target> element defines the set of decision requests that are applicable to this <PolicySet> element.

[j28] - [j30] PolicyIdReference includes a policy by id.

[j31] - [j46] Policy 2 is explicitly included in this policy set. The rules in Policy 2 are omitted for clarity.

5 Syntax (normative, with the exception of the schema fragments)

5.1 Element <PolicySet>

The <PolicySet> element is a top-level element in the XACML policy schema. <PolicySet> is an aggregation of other policy sets and policies. Policy sets MAY be included in an enclosing <PolicySet> element either directly using the <PolicySet> element or indirectly using the <PolicySetIdReference> element. Policies MAY be included in an enclosing <PolicySet> element either directly using the <Policy> element or indirectly using the <PolicyIdReference> element.

A <PolicySet> element may be evaluated, in which case the evaluation procedure defined in Section 7.12 SHALL be used.

If a <PolicySet> element contains references to other policy sets or policies in the form of URLs, then these references MAY be resolvable.

Policy sets and policies included in a <PolicySet> element MUST be combined using the algorithm identified by the PolicyCombiningAlgId attribute. <PolicySet> is treated exactly like a <Policy> in all policy-combining algorithms.

A <PolicySet> 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 <PolicySet> element to a set of decision requests. If the <Target> element within the <PolicySet> element matches the request context, then the <PolicySet> element MAY be used by the PDP in making its authorization decision.