OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: [xacml] Proposed XACML 1.1 Solution for Item F2:Properties for newcombining algorithms

Since my original draft proposal on properties for new combining algorithms
included two different items, I call it Item F1 and F2 as below:

Item F1: Properties for new combining algorithms
Item F2: Environment in Target element

This proposal is about Item F2: Environment in Target element. I will post
the proposal for F1 in a separate message. The origianl draft proposal is

Proposed XACML 1.1 Solution for Item F2:"Environment in Target element"

Problem Description

The current policy model allows policy writers to specify policy about
subject, resource, and action using target element. Policy regarding
environment is not allowed to specify in the target element. The reasons
behind this decision was that 1) usual access control policy consists of a
access triple, that are subject, resource, and action, 2) target
specification should be as simple as possible to enable each implementation
to make an index on parameters specified in the target element, and 3)
environment variables such as current time do not fit the limitations set
on the target element.

However, some application will benefit if XACML supports environment in the
target. For example, privacy protection policy often consists of four
arguments, that are subject, resource, action and purpose. In most cases,
purposes used in a certain policy are pre-defined and they are checked just
using equality checking (e.g. if subject is Operator and purpose is order
fulfillment, then permit the access). This extension just gives
alternatives in the case that the performance is improved using index
mechanism for environment axis. This does not mean that every environmental
expression should be specified in the target. So this extension does not
conflict with the second and the third reasons above.

Thus, allowing environment in target could improve the performance of
finding the applicable policy from the policy storage. This extension will
not add extra complexity to the existing implementation because the
existing code for implementing the target class can be reused for
implementing this extension.


1. Change definition of <Target> element to optionally include
<Environments> element.
2. Define new elements <Environments> and <Environment> in policy schema.
3. Define new element <AnyEnvironment/> in policy schema.
4. Define new element <EnvironmentMatch> in policy schema.
5. Change to specification.

Proposed Solution

1. Change definition of <Target> element to optionally include
<Environments> element.

<xs:element name="Target" type="xacml:TargetType"/>
<xs:complexType name="TargetType">
            <xs:element ref="xacml:Subjects"/>
            <xs:element ref="xacml:Resources"/>
            <xs:element ref="xacml:Actions"/>
            <xs:element ref="xacml:Environments" minOccurs="0"/>

- minOccurs="0" is added for backward compatibility.

2. Define new elements <Environments> and <Environment> in policy schema.

<xs:element name="Environments" type="xacml:EnvironmentsType"/>
<xs:complexType name="EnvironmentsType">
            <xs:element ref="xacml:Environment" maxOccurs="unbounded"/>
            <xs:element ref="xacml:AnyEnvironment"/>
<!-- -->
<xs:element name="Environment" type="xacml:EnvironmentType"/>
<xs:complexType name="EnvironmentType">
            <xs:element ref="xacml:EnvironmentMatch" maxOccurs

3. Define new element <AnyEnvironment/> in policy schema.

<xs:element name="AnyEnvironment"/>

4. Define new element <EnvironmentMatch> in policy schema.

<xs:element name="EnvironmentMatch" type="xacml:EnvironmentMatchType"/>
<xs:complexType name="EnvironmentMatchType">
            <xs:element ref="xacml:AttributeValue"/>
                  <xs:element ref="xacml:EnvironmentAttributeDesignator"/>
                  <xs:element ref="xacml:AttributeSelector"/>
      <xs:attribute name="MatchId" type="xs:anyURI" use="required"/>

5. Change to specification

Line 278-279: Target - The set of decision requests, identified by
definitions for resource, subject, action, and environment that a rule,
policy or policy set is intended to evaluate.

Line 610: Figure 3, Environment box should be added and linked to Target
box with 1 : 0..*

Line 623-624: Add environments

Line 627: Add <AnyEnvironments/>

Line 628: Add environments

Line 677: Add environments

Line 1851: Add <Environments>

Line 1860: Insert a line of <xs:element ref="xacml:Environments"/>

Line 1871: Add the following
<Environments> [Optional]
Matching specification for the environment attributes in the context.

Line 2047: Insert sections for "Element <Environments>", "Element
<Environment>", "Element <AnyEnvironment>", and "Element
<EnvironmentMatch>". The text can be copied from descriptions for actions,
for example, and appropriately replaced with Environment without any

Line 2849: Add environment.

Line 2851: Add environment.

Line 2852: Add <EnvironmentMatch>

Line 2856: Add <EnvironmentMatch>

Line 2858: Add <EnvironmentMatch>

Line 3529: Add <EnvironmentMatch>


- Since <Environments> element in <Target> element is optional, this
extension does not affect the existing policy set, policy, and rule

- Anne responded that this is a reasonable extension in

Michiharu Kudo

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]