DRAFT 23 November 2004 XKMS Teleconference Minutes
Chairs: Stephen Farrell, Shivaram Mysore
Note Taker: Stephen Farrell
Last revised by $Author: smysore $ $Date: 2004/11/11 18:40:01 $
Participants
- Shivaram Mysore
- Jose Kahan, W3C
- Pete Wenzel, See Beyond
- Guillermo Alvaro, Trinity College
- Tommy Lindberg
- Rich Salz, Datapower
- Stephen Farrell, Trinity College
- Yunhao Zhang, SQLData
Agenda
- Announcements
- Review last telecon AIs
- Interop schedule
- AOB
Minutes
- In the last
telecon we had the following AIs:
- AI Stephen: Check on OCSP
issue with IETF, ETC, DSS and other groups and report back.
DONE. Stephen sent a proposal
to the list that we delete the reference to OCSP, which was agreed on
the call and will be adopted so long as there's no objection raised
to these minutes.
- AI: Implementors - Upgrade to the new schema.
DONE all report they're done or about to test with the new
schema.
AI: All Send comments
onupdated
schemato the list CLOSED too
late, unless they're bugs.
- AI: Chairs/Jose - Chairs and Jose will propose a
deadline for the end of the interop exercise. DONE see
below
- Open
enumeraitons in the schema. AI: Tommy - say if
this issue is closed or what pieces of the schema should move to use
OpenEnum. CLOSED says Tommy.
- AI: All - Don't forget to start thinking and
writing down your ideas on what should constitute a compliant XKMS
and/or XKRSS clients/servers based on your experience. Do we need to
have several levels of compliancy or just one? Should they always
support asynchronous, synchronous, and compound requests?
STILL OPEN
- Yunhao said that the spec doesn't say anything on how many times
should a client send a Status Request in order to complete a request.
Rich sugges that maybe we should add a non normative choreography
section or appendix to the spec to describe this. STILL OPEN
- Yunhao to propose some guidance for inclusion in the test spec. and
send to list
- AI: Tommy & All - Provide more tests
incorporating the new schema especially related to: Registration -
which are very few currently, Compound Messages, SOAP specific tests
- ex. expected behavior for Must Understand, Version, etc DONE
proposal being worked on the list.
- AI: Tommy - Use of AlgorithmIdentifier
- propose new schema which uses ds:digestMethod CLOSED no
action required
- AI: Shivaram - make spec changes accordingly.
STILL OPEN (for now, will be done in the next few days)
- AI: Jose - update issues list - to follow after item 9 above
and thus STILL OPEN.
Scheduling
We discussed the schedule going forward and agreed:
- AI: Guillermo, Tommy and Yunhao (and whoever else is willing to
devote effort) will work out the additional tests and other test spec
changes over the next week. The work will take place on the list,
giving everyone else a chance to see what's up.
- We will freeze the test specification just before our next call
(currently scheduled for Dec 7th)
- There will then be a 30-day period for carrying out interop
testing (probably ending mid-January), the additional time allows
for the Christmas/New Year break.
- AI: Shivaram, Stephen and Jose will start to prepare documents
etc for the formal request for transition to PR. (We don't have a
deadline there, but I guess the same mid-January one would be
right.)
- AI: Jose will check whether we need to extend the charter
for this (we're formally to-be-done by year's end at the moment)
AOB
- AI: Jose will add another question to the questionaire about
compliance.
- We discussed some of the propsed new tests and concluded:
- We can omit the tests to do with SOAP versioning etc since that's a
potential rathole and is really outside of XKMS for many
implementations
- The new proposed XKISS test is supererogatory
so we'll create a new test specification section (or class, whatever
the Editor prefers) for those types of "above and beyond the call of
duty" tests (which are therefore OPTIONAL to perform and have no real
impact on our progression to PR)
- For XKRSS tests, we agreed that where a ds:Signature is used to
authenticate something that the tests should be based on MACing with
a shared secret. Potential signature variants (e.g. authenticate the
registration of this key with a signature verifiable using a
previously registered public key) go into the supererogatory
bucket.
- For security bindings, we agreed to test TLS and XKMS-native
mechanisms and to leave others (e.g. SOAP signature based) for later.
The spec. also needs some work in that section, an issue
already raised by Jose).
- As before, Tommy will generate some new samples and Shivaram will
try to incorporate those into the XKMS spec itself as he does other
edits.
Next Telecon
- Next
Telecon(s)
- Date: December 7th, 2004; Time - 4:30pm GMT/Dublin (if you're unlucky
enough not to live in Dublin, you can check time for your local area here:-)
- Zakim Bridge (617) 761-6200 Code: "XKMS"
- Future telecons at the same time on December 21st (more likely
in the new year).
- Agenda: Frozen Test spec, Interop Matrix; issue list, Moving to PR