- From: Rich Salz <rsalz@zolera.com>
- Date: Tue, 27 Nov 2001 20:23:46 -0500
- To: Yassir Elley <yassir.elley@sun.com>
- CC: www-xkms-ws@w3c.org
The (sic) key point is that a trust policy is identified by a URL, and that common client code can just invoke the appropriate server-based evaluator; if a new policy is needed, at least the problem is reduced to a new URL, as opposed to new code. That in and of itself is a major benefit. But it needn't always be a new URL. My guess is we'll see the following types of XKMS deployments: 1. An enterprise with its own server. Doing things like adding a trust route should only need minor configuration on the server, client code and URL knowledge need not change. 2. General utility-type outsourced servers. If private labelled, this becomes like #1, but if a general Internet wide service, then there are URL configuration issues, etc., which will probably fall under the "get what you pay for" metric. 3. Application-specific, e.g. an Identrus application might be hardwired to go to http://xkms.identrus.com/identity-assurance, e.g. Hope that adds a little light to the gloomy picture you seemed to be implying. /r$ -- Zolera Systems, Securing web services (XML, SOAP, Signatures, Encryption) http://www.zolera.com
Received on Tuesday, 27 November 2001 20:23:54 UTC