Draft Minutes May 5, 2003

["jmessing" <jmessing@law-on-line.com>]

Hello All:

Here are the draft minutes:


Date:  Monday, May 5, 2003, 12:00-1:00 pm Eastern time. 
1.  Welcome by chair.
 	-Approve agenda. 

A new agenda item 6a was added. See below.

2.  Roll call. 

Voting Members 

Carlisle Adams, Entrust 
Steve Anderson, OpenNetwork Technologies 
Dimitri Andivahis, Surety 
Juan Carlos Cruellas, self 
Frederick Hirsch, Nokia Mobile Phones 
Merlin Hughes, Baltimore 
Burt Kaliski, RSA Security 
Andreas Kuehne, self 
Hal Lockhart, BEA Systems 
John Messing, self 
Anthony Nadalin, IBM 
Trevor Perrin, self 
Nick Pope, self 
Rich Salz, DataPower Technology 
Simeon Sheye, Cryptomathic A/S 
Krishna Yellepeddy, IBM 
Gideon Yuval, Microsoft 
Robert Zuccherato, Entrust 



3.  Approve minutes of previous meeting.
 	-Minutes of DSS TC Meeting April 7, 2003 available at http://www.oasis-open.org/apps/org/workgroup/dss/download.php/1462/meeting%2040703%20minutes.txt 

The minutes were approved by consensus.

4.  Linking-Based Timestamping Protocols  (Continued from last meeting)
 	-As a general principle, the standard of the TC should be broad enough include to support for existing use cases and 	forseeable future use cases, without however making additional formal declarations that duplicate existing standards. 	The timestamping issue is one example of this principle.

5.  XKMS Last Call Draft
 	-The XKMS WG requested comments on their Last Call Working Draft.  
 	 After discussion on the list, Robert posted a suggested response that
  	 indicated it might be nice to query a DSS client's key and receive
  	 information on the DSS server to which the client has delegated
  	 signatures.  Robert asked: Are we okay with this response? 

	 Krishna suggested as a refinement adding to the request element a parameter for the RespondWith element.After 	 discussion, Krishna agreed to provide comments to the list in time for Robert to submit to XKMS list before 23 	 	 May. 	 


6.  Identifying Requester
 	-There had been quite a bit of discussion on methods for the DSS server
 	 to identify the signature requester.  Note was taken that in his latest requirements draft
 	 Trevor suggested that we leave the question entirely to higher-level
 	 standards (See http://lists.oasis-open.org/archives/dss/200304/msg00123.html.)
 	 Robert had suggested a compromise position in which we specify an extensible
 	 list and leave it up to higher-level standards how to deal with them.
 	 (See http://lists.oasis-open.org/archives/dss/200305/msg00005.html.) 	 
	 During the meeting, the following were suggested as possible candidates for such a list:
		name of requestor
		authentication information
		other information to be specified
		whether this was to be part of the core protocol
	Mention was made by Fred Hirsh of an authentication level context in the Liberty Alliance, which could include the
	kind of information associated with a registration authority of a CA.
	It also dealt with security of key storage.

	There was consensus that more discussion on the list was needed. Nick Pope indicated he wanted to review the Liberty 		Alliance material and consult with others, including John Messing before the TC reached a conclusion.

6a. Nick and Juan Carlos submission. This involved a paper that Juan Carlos had submitted to the TC on May 5. See http://lists.oasis-open.org/archives/dss/200305/msg00015.html

	In discussing this item it was agreed that many of the subjects related to agenda item 6 and were useful to help resolve differences but While agreeing generally, Juan Carlos and Nick also emphasized that the document went beyond just Signer Identification. One proposal is to make signature policy NOT REQUIRED but NORMATIVE. Would this be part of the core protocol or a profile?

Discussion on the list was to follow.

Juan Carlos agreed to annotate the new submission with references to the paragraph numbers of the emerging requirements document to show how the individual parts of latest work product could benefit from the new submission.

7.  Next Steps 	-Robert undertook responsibility to verify IP declarations on the various protocols as a step preliminary to identifying probable candidates for drafting the protocol itself.

8.  Next meeting two weeks

9.  Close.