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] | [Elist Home]

Subject: [xacml] Attesting implementations and <type>-map,Match arg order issues

This mail is addressed to implementors of potential "attesting
implementations" (any others, please speak up!).

Let "attesting implementation" mean an implementation being done
by or for an OASIS organizational member that plans to attest to
"successfully using" the XACML 1.0 specification (defined as
"passing the Conformance Test Suite") by December 12.

I believe the XACML TC must decide on two issues very soon if we
are to have 3 attesting implementations:

The two issues are:
1. "<type>-map" vs. "map" functions

   The specification currently uses a single "map" function.  The
   proposed change is to use "<type>-map" functions for each of
   the primitive types.

2. The order of the arguments in a Match element.

   The specification currently uses
   Match(AttributeDesignator,AttributeValue).  The proposed
   change is to use Match(AttributeValue,AttributeDesignator).

If you are an attesting implementation, would you be able to
adapt your implementation by December 12 if the TC decides to
make these changes on:
  Dec. 2: <type>-map?
  Dec. 2: Match(AttributeValue,AttributeDesignator)?

  Dec. 5: <type>-map?
  Dec. 5: Match(AttributeValue,AttributeDesignator)?

  Dec. 9: <type>-map?
  Dec. 9: Match(AttributeValue,AttributeDesignator)?

If we have not made a decision by the last date where at least 3
of you could adapt by December 12, then it seems to me we have to
live with the current specification or else slip our
standardization schedule by one month.

Some Conformance Test nitty details:

  The TC has said there will be no new Conformance Tests required
  for "successfully using" added after the end of November,
  although we can fix bugs in existing Conformance Tests.

  I think this means that, if the TC decides to accept
  "<type>-map", I will simply delete the existing "map" test.
  There would be no tests for "<type>-map" that would be required
  to be "successfully using".  Perhaps if at least 3 attesting
  implementations were willing to have <type>-map tests added
  after the end of November, then we could do it.

  If the TC decides to accept
  "Match(AttributeValue,AttributeDesignator)", then I believe it
  would be possible to change the order of the Match arguments in
  the existing tests after the end of November under the category
  of "fixing bugs".

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] | [Elist Home]

Powered by eList eXpress LLC