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