[xacml] Minutes of February 6, 2003 meeting...

[Carlisle Adams <carlisle.adams@entrust.com>]

Title: Proposed Agenda February 6 Concall. QUORUM REQUIRED...

Minutes of XACML Meeting, February 6, 2003

(See agenda, included below)

 

Attendees:  Hal, Carlisle, Tim, Michiharu, Steve Anderson, Simon, Bill, Steve Crocker, Polar, Anne, Gerald.  (Quorum achieved.)

 

Vote to approve minutes of Dec. 5, Dec. 12, Jan. 9, and Jan. 23 meetings:  moved (Hal); seconded (Anne); no dissention.  (Minutes approved.)

 

ISTPA discussion with Michael Willett:  ISTPA looked at the "Fair Information Practices" and found that they were too high-level (not detailed enough to help developers).  ISTPA is building a framework to allow programmers to implement some of these privacy requirements.  Important requirement is to bind personal information to preferences of user.  Privacy policy/preferences/permissions bound to personal information.  Note that "bind" includes cryptographic techniques as well as pointer to database, etc. (i.e., notion is meant to encompass "bind", "associate", "affiliate", etc.).  ISTPA has designed about 10 privacy services and capabilities; there are lots of examples in the document.

[NOTE:  the above ISTPA notes are a bit sketchy.  See the document and the accompanying slides that Michael has circulated for further details.]

Anne:  "rights management" deals with the handling and transfer of rights throughout the life cycle of the content; "access control" deals more with the expression of policy.

Hal:  suggestion to Michael:  what you're looking for (i.e., binding of preferences to personal information) may be more in scope for the Rights Language TC.  However, they've recently backed off a bit on their language being a rights language, and now talk about it as a general-purpose authorization language.

Michael:  thanked everyone for their time and input and signed off.

 

Discussion regarding negative vote on XACML 1.0:  people preferred option 1 over options 2 and 3 below.  Hal suggested replacing the first sentence of the third paragraph with something about many members believing that useful RF implementations of XACML 1.0 can be created.

After some discussion, the following wording was APPROVED as a replacement for the first sentence of the third paragraph of option 1 below:  "It is the belief of the TC that useful and fully-compliant implementations of XACML 1.0 can be created that are royalty free."  Carlisle will send the official response to Karl Best and copy the TC.

 

Discussion regarding revisions to the spec:  Hal:  it would be good to have the official document (as approved) on the Web site, as well as a separate errata document.

Anne (after some discussion regarding what is allowed to be changed in the 1.0 spec):  what we need is an official decision from the OASIS board.  We'll do whatever they allow.

Hal:  motion:  make official spec as updated as legally allowed (this might be nothing, typos, or minor corrections; we'll let them tell us) and ensure that all corrections are available to developers on Web site.  Seconded (Anne?); no dissention.  (Motion approved.)  Carlisle will contact Karl to find out what changes (if any) we can make to the 1.0 Standard.

The next TC meeting will be February 13, 2003.  At that meeting we will discuss errata and the creation of a going-forward draft.

 

Discussion regarding future work:  Anne:  SAML profile; XML Signature profile; etc.

Hal:  let people propose additional work items ("unfinished business") to the list over the next week.  On the 13th we can decide what to do with these (1.1?  2.0?).

 

Motion to adjourn.

 

Proposed Agenda:
10:00-10:05 Roll Call and Agenda Review
10:05-10:15 Vote to accept minutes of December 5, December 12, January 9, and January 23 concalls
http://lists.oasis-open.org/archives/xacml/200301/msg00003.html
http://lists.oasis-open.org/archives/xacml/200212/msg00091.html
http://lists.oasis-open.org/archives/xacml/200301/msg00007.html
http://lists.oasis-open.org/archives/xacml/200301/msg00019.html
10:15-10:25 Discussion of ISTPA and possible collaboration with XACML (Michael Willett)
10:25-10:35 Discussion AND VOTE regarding what to do with negative ballot on XACML (Carlisle) **
10:35-10:55 Discussion of errata list and Tim's OS 1.0 specification (Simon, Tim)
10:55-11:00 Discussion of next steps for XACML:  nothing?  1.1?  2.0?  (Carlisle)

Carlisle.

** One OASIS member organization cast a negative ballot on XACML 1.0.  The reason given in the ballot was "We think, OASIS standards must be royalty free."  It seems to me that we have three possible options for a TC response:

1) Dismiss the comment on the basis that the TC has already done its best with respect to this issue:

An implementation of any standard, in some particular way, may infringe on some intellectual property, whether that IP has been disclosed to OASIS or not.  Each implementation must take appropriate steps to determine whether or not it infringes on valid IP claims.

The XACML TC has taken reasonable steps to ensure and to document that all features of this language are derived from previous work in the field that is not under patent restrictions.  We intentionally made one feature of the language - Obligations - not mandatory to implement in order to make it easier for implementations to avoid a particular feature that might, in some cases, infringe on a known IP claim.

It is the belief of the TC that broad, vague statements of IP claims should not be allowed to block progress of a specification where there is no evidence that those claims apply to typical implementations of the specification.  The TC therefore requests that OASIS adopt the XACML 1.0 specification as submitted.

2) Dismiss the comment on the basis that it is impossible and unnecessary to satisfy the comment:

With respect to the negative vote cast, the XACML TC feels that it must dismiss the comment because
(a) no specification can ever guarantee that it is royalty free (since someone can always show up a month from now claiming some just-issued IP that relates to any specification under consideration), and

(b) current OASIS policy (to which we, as members, must all adhere) does not require, or even encourage, royalty-free specifications.

The TC therefore requests that OASIS adopt the XACML 1.0 specification as submitted.

3) Agree that OASIS Standards should be royalty free and withdraw XACML from consideration as an OASIS Standard.  [This one is undesirable to me because it implies that XACML cannot be implemented in a way that is free of royalties, but no one has ever claimed that this is the case.]