Re: [dss] FW: Here is the TimeStamp scope question to post to the list.

[Rich Salz <rsalz@datapower.com>]

> So the idea is to make most everything optional?

That's not quite the right spin.  Think XML-DSIG Transforms.  The idea
is a framework with, like, one thing specified (c14n), and a standard
place to put extensions (like SOAP:Header).  Separate documents could
define each extension.

> You can leave everything else up to the server.  There is the *option* for
> clients to control various things.   But a profile could chop out that
> optionality, and restrict clients to just sending the above.

Yes, but see below.

> I guess the rationale for adding features into the core, and letting
> profiles remove them, is that these are features that different profiles
> might want to use, so we might as well tackle the problems once and solve
> them in a consistent way.

My proposal also enables this.  The more you put into the core, the more
everyone has to understand, implement, test, etc.  Make each thing
a separate spec and conformance point.

> Also, if the core was simple enough that toolkit
> developers could implement the whole thing, then application developers
> could use that toolkit with any particular profile.

My concern is that with all the options being proposed, the core is not
simple.  Every time the core provides an option -- "a server MAY or
MAY NOT support the foofoofoo option" -- you double the possible number of
conformance points.  The marketplace will be confused:  two different
conforming implementations could provide totally different services.

Pull each option out of the core and make it a separate spec. Then it
is painfully clear to the customer (a) what to ask for; and (b) what the
server provides.

I am terrified of too many choices leading to market confusion, and
customers once again running away because "PKI is too complex."  Again,
we don't have to provide a core "box" with enough "dials and levers" so
that every possible signature for every possible use-case can be generated
in the core.  We can provide a "box" with extensible space for "your dial
here" and let the marketplace determine which use-cases have market
demand, and which ones are just whiteboard/conference call doodlings.

> What's the difference between having an optional
> ProcessingOptions/Timestamp element that takes one of the values
> Timestamp/Don'tTimestamp, and having an optional <dss:Parameter
> URI="#TimeStamp> element that takes one of the same values?

See above.  Does the reasoning 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