RE: [dss] Core versus Extended Profile Handling

[Rich Salz <rsalz@datapower.com>]

>    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