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: Proposed XACML 1.1 Solution: References to Rules

Proposed XACML 1.1 Solution for "References to Rules"

Problem Description

XACML 1.0 allows a PolicySet to include other Policies and
PolicySets by reference, but there is no provision for a Policy
to include Rules by reference: all Rules for a Policy must be
literally contained in the Policy.

Allowing references to Rules could make Policies shorter, allow
sharing of Rules between multiple Policies, and allow Rules for a
single Policy to be defined by multiple authorities.

This extension has been requested by Farrukh Najmi, who is
writing an ebXML Profile for XACML.


Allow XACML <Policy> elements to contains references to isolated
<Rule> elements, identified by their "RuleId".

Proposed Solution

Summary: Add a RuleIdReference element to the policy schema along
same lines as current PolicyIdReference and PolicySetIdReference

The following detailed proposal is fully backwards compatible.

1. Define new element in policy schema:

   <xs:element name="RuleIdReference" type="xs:anyURI"/>

2. Change definition of PolicyType:

   <xs:complexType name="PolicyType">
         <xs:element ref="xacml:Description" minOccurs="0"/>
         <xs:element ref="xacml:PolicyDefaults" minOccurs="0"/>
         <xs:element ref="xacml:Target"/>
!        <xs:choice minOccurs="0" maxOccurs="unbounded">
!           <xs:element ref="xacml:Rule"/>
!           <xs:element ref="xacml:RuleIdReference"/>
!        </xs:choice>
         <xs:element ref="xacml:Obligations" minOccurs="0"/>
      <xs:attribute name="PolicyId" type="xs:anyURI" use="required"/>
      <xs:attribute name="RuleCombiningAlgId" type="xs:anyURI" use="required"/>

    [! lines were previously:
         <xs:element ref="xacml:Rule" minOccurs="0" maxOccurs="unbounded"/>

3. Changes to specification:

   -. Section "3.1 Data-flow model", following line 558, "Figure
     1-Data-flow diagram", change label on line connecting PDP to

         1. rule, policy, or policy set

   -. Section "3.1 Data-flow model", lines 567-568

      1. PAPs write rules,    policies and policy sets and make them
         available to the PDP.  These rules,    policies, or policy
         sets represent the complete policy for a specified

   -. Section "3.3.1 Rule": Revise 1st paragraph, lines 612-615:

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

   -. Section "3.3.2 Policy": Remove 1st two sentences from 1st
      paragraph, lines 666-667:

     From the data-flow model once can see that rules are not
     exchanged amongst system entities.  Therefore, a PAP
     combines rules in a policy.]
     A policy comprises four main components.

   -. Section " Policy target": Revise last sentence of 
     3rd paragraph, lines 694-695:

     Such <Rule> elements inherit the <Target> of the <Policy> in
     which they are contained or referenced.

   -. [Section "4.2.3 Example plain-language rules" needs no
     change.  It already says (line 1029) "These rules may be
     written by different PAPs operating independently, or by a
     single PAP."]

   -. Section "5.20 Element <Policy>", replace 2nd paragraph,
     line 2064-2065:

     The main components of this element are the <Target>, <Rule>
     or <RuleIdReference>, and <Obligations> elements and the
     RuleCombiningAlgId attribute.

   -. Section "5.20 Element <Policy>", lines 2072-2083

     Replace schema fragment for Policy element with new schema
     fragment listed above.

   -. Section "5.20 Element <Policy>", change lines 2102-2104:

     The <Target> element MAY be declared by the creator of the
     <Policy> element, or it MAY be computed from the <Target>
     elements of the referenced <Rule> and <RuleIdReference>
     elements either as an intersection or as a union.

   -. Section "5.20 Element <Policy>", lines 2105-2109, reword as
     follows (consistent with description of <Policy> within


        A rule component that is included in this policy.

   -. Section "5.20 Element <Policy>", add new description after
     lines 2109:

     <RuleIdReference> [AnyNumber]

        A reference to a <Rule> component that MUST be included
        in the policy.  If <RuleIdReference> is a URL, then it
        MAY be resolvable.

   -. New Section to follow "5.22 Element <Rule>":

     5.23 <RuleIdReference>

     The <RuleIdReference> element SHALL be used to reference a
     <Rule> element by id.  If <RuleIdReference> is a URL, then
     it MAY be resolvable to the <Rule>.  The mechanism for
     resolving a rule reference to the corresponding rule is
     outside the scope of this specification.

         <xs:element name="RuleIdReference" type="xs:anyURI"/>

     Element <RuleIdReference> is of xs:anyURI simple type.
   -. Section "7.6 Policy evaluation", modify lines 2887-2889:

      A Rules value of "At-least-one-applicable" SHALL be used if
     the <Rule> or <RuleIdReference> elements are absent, or if
                [^insert...........]        [^^^^plural]
     one or more of the rules contained in the policy is
     applicable to the decision request (i.e. returns a value of
     "Effect", see Section 7.5).

   -. Section "10.2.1 Schema elements", line 3311 (table following)

     xacml:RuleIdReference                   M


As I recall the discussions, when we added PolicySetIdReference
and PolicyIdReference, we talked about adding RuleIdReference,
but felt that it was not needed: we already had enough levels of
composable elements.  We had just added <PolicySet>, and were
very leery of making more additions unless there was a real need.
There was no real semantic objection.  Please correct me if I am

Anne H. Anderson             Email: Anne.Anderson@Sun.COM
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311     Tel: 781/442-0928
Burlington, MA 01803-0902 USA  Fax: 781/442-1692

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