[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dss] FW: Here is the TimeStamp scope question to post to the list.
> 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]