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

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