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