> I'm not sure I see the "feature-mixing" problem. Sorry. Perhaps an
> example would help. If an additional option in a new profile requires an
> additional request type and an additonal response type ... no problem. If a
> profile requires several new features, presumably driven by new options on
> our primitives, then either existing, extensions on existing, or entirely
> new type structures must be introduced to support the new features. Each
> profile extends only the core.
It's like multiple inheritance.
Suppose profile "A" extends the sign operation to add an Expiration
element -- some special information that results in a signature only
being valid for a certain time period. Suppose profile "B" extends
the sign operation to add an EncryptFor element -- the signature is
encrypted so that only certain folks can read it.
Suppose I want to do encrypted expiring signatures. I have to define
a whole new profile that defines how to combine A and B into a new
request element. If more options get defined, we end up with a
combinatorial explosion of profiles.
If I present any of A, B, or A+B to a "classic" DSS server,
that server will just have to say that it doesn't recognize the
request. It would be better if the server could respond "Option
A not supported" but it can't do that. If my A+B server wants to
support A,B,A+B, then it has to recognize three different URI's
for the three different sign operations.
If instead A and B are elements that appear in the defined-in-core
Options container, then all these problems are avoided.
Make sense?
/r$
--
Rich Salz Chief Security Architect
DataPower Technology http://www.datapower.com
XS40 XML Security Gateway http://www.datapower.com/products/xs40.html
XML Security Overview http://www.datapower.com/xmldev/xmlsecurity.html
