[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: proposal for WI #27
Attached is a proposal for item #27 based on my original mail on this topic. It's purposefully thin on detail since there hasn't been much discussion and I suspect that others will have some opinions. This is not on the list of topics to discuss at the F2F. seth
27: Version number element or attribute in an XACML policy. Some way of indicating the version of a policy having a particular XACML policy id, and a way of placing version constraints on a policy reference. MOTIVATING USE-CASE AND REQUIREMENT A policy is currently referenced with a PolicyIdReference or a PolicySetIdReference using only a single URI. There is no ability to specify which version of a policy is being referenced. Versioning may be implied informally by file names, but that doesn't provide the flexibility to ask for eg. "the most recent policy". There is also nothing within a policy that supplies the version of that policy. From a management point of view, these features are critical. Between different revisions of policies identifiers may change or new features may be added (for instance, required support for new datatypes). More to the point, the meaning of a given policy may change between revisions, making a previously useful reference now unclear. In order to make updates to a policy system clear, there must be some kind of versioning system in place. The requirements are twofold: a way to specify the version of a policy, and a way to specify (optionally) what versions of a policy are acceptable from a reference. This is a requirement that comes from people using XACML 1.0 today. They have asked for a clearer way to manage revisions of policies and references to policies that may be updated. It also has been discussed by many people in the area of tools development. The analogy is to shared libraries, which are managable in large part because of a good versioning system. SUMMARY OF OPEN ISSUES There are no open issues as this topic has not been discussed in much detail within the TC. There is the possibility of exporting version information into a SAML assertion wrapping an XACML policy, which may have some effect on this proposal. PROPOSED SOLUTION <# if more than one> At a high level, a Policy or PolicySet needs a new XML attribute or top-level element that specifies a version. This should include at least a major and minor value. It may be acceptable to provide a default value of 1.0 (for example) if no value is provided. This needs to be discussed. The PolicyIdReference and PolicySetIdReference elements also need a new XML attribute that specifies an acceptable version. By default, these should always refer either to the most recent version of a policy or some fixed value (like 1.0). The value is a simple expression that lets you request a specific version, or some version above or below a given version. This will be defined in detail if others approve of this approach. DETAILED SOLUTION None until there is some agreement on the right approach to take, if any, for this proposal.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]