[Fwd: XKMS 2.0]

FYI:
-- 
_____________________________________________________________________
Shivaram H. Mysore <shivaram.mysore@sun.com>

JavaSoft, Sun Microsystems Inc.     Co-Chair, W3C's XKMS WG
                                     http://www.w3.org/2001/XKMS

Direct: (408)276-7524
Fax:    (408)276-7674
_____________________________________________________________________

Forwarded message 1

  • From: Berin Lautenbach <berin@wingsofhermes.org>
  • Date: Tue, 13 Apr 2004 22:33:18 +1000
  • Subject: XKMS 2.0
  • To: security-dev@xml.apache.org
  • Message-id: <407BDE0E.804@wingsofhermes.org>
Guys,

Don't know if you have been keeping accross it, but XKMS 2.0 is now in 
candidate recommendation status.  The plan is to run interop tests 
between now and (from memory) October.

I thought it might be interesting to try to get an XKMS service and/or 
client up and running to have involved in the interop.

So...

I've been playing with XKMS this weekend.  I'll be checking some new 
(C++) code into CVS sometime soon providing a skeleton message factory 
for reading XKMS messages.  I'll flesh this out over the next few weeks 
to give a reasonably full XKISS implementation of message handling.

I'm also going to put some client code into the library, but my feeling 
is that a server should be a separate code base.  The MessageFactory 
class will provide the basic message handling, but the server will have 
to handle the actual server logic.  Client code is a bit easier - make 
the request and return the result - and really should be in the 
xml-security library.

For the server, my feeling was it needs a couple of components :

1. SOAP listener.  This could be a simple process that accepts 
connections, an apache mod, an AXIS module (once AXIS C++ supports the 
Message service) or any other module that can get the message and strip 
the SOAP envelope to pass it to the

2. XKMS server.  The process that handles incoming XKMS messages and 
returns the answer to the SOAP listener.  It will need to talk to

3. The key service.  This is the service that actually knows about keys. 
   In the simplest form (for interop) it'll just be a connection to a 
database that holds the keys the service knows about.  For more 
complicated situations, this might be an interface to a commercial PKI.

Between 1 and 2 and between 2 and 3 will be defined interfaces that 
allow other key services and/or SOAP listeners to be configured around 
the XKMS server.

Would be interesting to do something similar in Java.  And I'd like to 
work on getting both through the Interop prior to the end of October.

Anyway, very interested in thoughts.  In the first instance I just want 
to create a simple prototype :>.

Cheers,
	Berin

Received on Tuesday, 13 April 2004 11:48:22 UTC