RE: XKMS

You wouldn't actually need to have a different WSDL description per URL.
WSDL is actually well structured for this type of thing.  You can have a
single WSDL file describing the message structure with Binding sections
for each URL, annotated (using WSDL supported extensibility), as to the
associated trust model. 

Either suggested approach for handling multiple trust models would work.
I think the real issue is whether the folks planning to build such
services believe one of them makes their life simpler.  I tend to favor
the URL model, but admit this view is based on fairly limited thinking
about how I might want to deploy such a system.

One other comment, Phill stated that using the 'id parameter' approach
might create a need to be able to query for supported trust models.  I
suspect this is not the right model.  Client apps need to know the
appropriate trust model for their needs up front and then be configured
for an appropriate XKMS service.  I can't imagine clients trying to deal
dynamically with what trust models are supported by a given service.
Going to web page to get info on supported trust models (like current
CPS docs for CAs) seems adequate to me.

Blair

-----Original Message-----
From: Rich Salz [mailto:rsalz@zolera.com] 
Sent: Monday, November 26, 2001 12:51 PM
To: Hallam-Baker, Phillip
Cc: 'Mike Just'; www-xkms-ws@w3c.org
Subject: Re: XKMS

I'm not sure if having n-zillion WSDL files that import the service
definition, but each with a different URL is a good thing or a bad
thing.

(Ir)Regardless, it seems the XML way would be to identify trust models
via URI, with an omitted value meaning "default trust provided by this
service."  Perhaps adding something like this to *all* requests and
responses:
  <element name="TrustModelIdentifier" type="xsd:anyURI" minOccurs="0"/>

	/r$

-- 
Zolera Systems, Your Key to Online Integrity
Securing Web services: XML, SOAP, Dig-sig, Encryption
http://www.zolera.com

Received on Monday, 26 November 2001 16:48:50 UTC