proposal for #27

[Seth Proctor <Seth.Proctor@Sun.COM>]

Work Item 27 proposes a version string for policies, such that revised
policies can be recognized in a standard way. This will also allow
policy references to specify version constraints, which is especially
important if the referenced policy may change in ways that the
referencing policy can't handle. In brief, the new features are:

  1. Define a new type that describes a dotted version string (eg 1.2.3),
     and a couple of very simple regular expression characters to match
     these version strings: * for a single value, and + for any trailing
     values. For example, both 2.*.4 and 2.+ match 2.3.4. I think that
     using a full-blown regexp syntax is overkill and will make this less
     useful, but since there is already a requirement in XACML to support
     pattern matching, I'm willing to discuss this issue.

  2. Include a new XML attribute in Policy and PolicySet that uses the
     new version type to optionally declare the policy's version. If not
     included, then the version is defined to be "1.0".

  3. Include three new (optional) XML attributes in PolicyIdReference and
     PolicySetIdReference. One attribute defines a single version string
     (or regular expression) that matches a required version or set of
     versions. The other two attributes decribe the earliest and latest
     acceptable versions (or regular expressions). Any combination of
     these attributes may be used. If none of the three is included, then
     any version is acceptable (this is like using "+" in all three
     attributes). In all cases, the most recent version available should 

     be used.

If none of the attributes from items 2 and 3 is used, then policies
and references look and act exactly as they do in 1.0/1.1. I think that
this is the right way to go.

The schema changes might look something like this (note that I haven't
run these through a schema checker, but I think they're about right):

   <xs:element name="PolicySetIdReference" type="xacml:IdReferenceType"/>
   <xs:element name="PolicyIdReference" type="xacml:IdReferenceType"/>
   <xs:complexType name="IdReferenceType">
     <xs:simpleContent>
       <xs:extension base="xs:anyURI">
         <xs:attribute name="Version" type="VersionMatchType"
                       use="optional"/>
         <xs:attribute name="EarliestVersion" type="VersionMatchType"
                       use="optional"/>
         <xs:attribute name="LatestVersion" type="VersionMatchType"
                       use="optional"/>
       </xs:extension>
     </xs:simpleContent>
   </xs:complexType>


   <xs:complexType name="PolicyType">
   ...
     <xs:attribute name="Version" type="VersionType" use="optional"
                   default="1.0"/>
   ...


   <xs:complexType name="PolicySetType">
   ...
     <xs:attribute name="Version" type="VersionType" use="optional"
                   default="1.0"/>
   ...


   <xs:simpleType name="VersionType">
     <xs:restriction base="xs:string">
       <xs:pattern value="(\d+\.)*\d+"/>
     </xs:restriction>
   </xs:simpleType>

   <xs:simpleType name="VersionMatchType">
     <xs:restriction base="xs:string">
       <xs:pattern value="((\d+|\*)\.)*(\d+|\*|\+)"/>
     </xs:restriction>
   </xs:simpleType>


Given this, there is a very simple system for defining the revision
number of a policy, and for ensuring that you're referencing an
acceptable version (if needed). This is also very useful for policy
writers and management tools. Comparison is done using simple equality
and greater-than/less-than, and the regular expressions are fairly
trivial to use. Thoughts?

Note that this intentionally doesn't say anything about how policies are 
retrieved. As with the current mechanisms, the version tags can be used 
as hints in indexing policies or in deciding which policies to fetch, 
but only one policy may be presented for evaluation. Also, while it's 
probably best to present the most recent version of a policy, a custom 
retriever may decide to use some other heuristic (eg, the oldest one) 
that makes sense in a given environment.


seth


ps  I'll be (mostly) on vacation until the new year, though I'll try to 
keep up with my email for the next week. Happy holidays all!