Participants

Regrets

Tommy Lindberg

Agenda

Announcements

Review last telecon AIs

Current issues list

Interop Matrix

Minutes

In the last
telecon we had the following AIs which are still carried forward:

AI: All suggest possible events/venues for doing
face-to-face interop testing within the next six months. Post
suggestions to the list. Leave OPEN. - CLOSED - since we've
agreen on-line testing in September

AI: Jose turn Guillermo's XML into an on-line questionaire -
IN PROGRESS STILL OPEN

AI: Tommy: As a result of
the schema update (namespace URI changed), all examples have to be
regenerated. Thanks to Tommy for volunteering to do this. STILL
OPEN

AI Jose: How we get the new schema to be placed in
this new location - http://www.w3.org/2004/07/xkms.xsd ? Shivaram:
Just update the exisiting one till the spec gets Recommendation
status STILL OPEN (though maybe we won't need it - AI
chairs: re-check with list as to whether anyone's product code
requires this given current issue resolutions.)

AI: Jose and Guillermo to work on the interop
document associated with the Interop Matrix which will help walk
thro' the interop scenarios. STILL OPEN

AI: Rich Salz - Send a proposal to resolve the QName
issue in schema which is not allowing extension for non-repudiation
usage. STILL OPEN, though maybe no longer needed - check when
Shivaram posts the new schema/spec edits.

AI: Guillermo - Add more test messages to the interop
matrix. Send out a template to the list so that others can contribute
test messages easily. STILL OPEN

Since Patrick understandably wasn't familiar with XKMS we described the
issues we have with QA to Patrick who mainly is going to go away in think
whether there're similar things he's seen in the past and continue the
discussion via email. The non-trivial issues are:

Writing tests/scenarios for handling compound messages. Patrick
didn't like this feature since it makes the spec. quite hard to test
(and at least one chair agrees with him:-). He figured our scenarios
approach might be the best that can be done, but may come back to us
with additional advice later on.

The WSDL issue (how a client can know whether a server does XKRSS
and/or XKISS) also came up. This is somewhat easier and Patrick's
recommendation was that we mandate that if some descriptive mechanism
is to be used, then that MUST be WSDL. Shivaram pointed out that we
have to allow non-SOAP bindings, but Patrick said that in that case,
even though its not automatable, mandating that implementors MUST
somehow publish a list of which interfaces they support is useful -
e.g. in the HTTP case, if there're a set of human readable web pages.
AI: Shivaram check what we currently say in the specs
(particularly the bindings) and suggest chages as required. AI:
All/any - anyone want to publish a WSDL spec. for XKMS 2.0?

After that we had a few status reports:

Shivaram will post a revised editor's copy of the spec in the next
few days including resolutions to all open issues. Checking this
ought to be the main agenda item for our next call.

Shivaram/Stephen desribed the chats we had in San Diego (incl.
Phill part of the time)

Qname -> URI stuff

Order of encryption/signing is fine as is, maybe the spec could
be clearer but its there already

We figured some wording to say what MUST be input to the
signing process when XKMS messages are signed - Shivaram has the
words, but basically it amounts to: the entire message and no
messing with XPath etc and leaving out bits of the XKMS message.
The reason this needs saying is that the signature could be in
the SOAP header or elsewhere, so we can't mandate only one single
scheme.

We'll mandate that everyone MUST support private key encryption
(for recover and centrally generated keys) using shared secrets,
that is, a client/server which only supported asymmetric
de/encryption of private keys would not be compliant. (Roland
- is that ok?)

Guillermo and Tommy have been doing more interop (Tommy's
now/soon-to-be on vacation). XKISS working out fine, some issues to
be with Guillermo's use of crypto for PoP, not protocol things
though, just crypto-use stuff.