[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.
> Tim suggested the same approach at the F2F. Sorta like pizza toppings - > you've got a pizza, you've got some toppings, and the Profiles just name a > set of toppings - Hawaiian = ham+pineapple, etc.. Cute analogy. Yes. > Another view on this stuff - there's 3 categories: > 1) the micro-core, really core stuff > 2) some important "core options" that we define, and that lots of profiles > would re-use > 3) other options that profiles introduce > > So is (2) more like (1) or more like (3)? I was thinking the "core > options" would be part of the core schema (more like 1), and you're saying > the "core options" should be treated like other options (more like 3). Or > rather - looking at your schema - that *everything* is just options. Yes, everything is an option (Parameter, in my terminology). I think those questions you asked are excellent ones, and agre that we'd need to get a bit further before having more answers. But do not that the "lax" element on the schema means that if you happen to have the schema available for what you were given, you can validate. A server would have to be able to import schemas for all the Parameter elements it supports in order to validate them. I htink that's reasonable. > >Yes, a ds:KeyInfo can be a parameter. DSS servers MUST support at least > >the ds:KeyInfo/ds:KeyName element. > > I'd leave this out of the minimal core, since the server will usually > decide which key to use. Okey dokey. > So you view the core server as generating signatures, not signed documents? > > I think a server that takes a document and returns a signed document would > be more useful to stupid clients. Then the client doesn't even have to > know where the signature goes. My bet is that most signatures will be detached. Things like WS-Security, S/MIME, etc., are all detached signatures. While walking the dog tonite, I tried to think about how you would specify "put it here". It's not immediately obvious -- you need both an XPath expression to specify a node, and an attribute that says "sibling-before/ sibling-after/first-childof/last-childof, and I think one of those can be eliminated. > Even if it's detached, does the client know where/how to splice it in? Presumably the client knows the semantics of the XML document it is processing, so it should know where to stick the signature, even if it doesn't know what a signature is. > Yeah, exactly. And if all our use cases are different enough, there may > not *be* an 80/20 solution that we can agree on. Then it's pistols at 20 paces. > For example, my minimal schema would focus entirely on the Input/Output of > Documents. In fact, I'm inspired to make one. I'll send it in another mail. Great. I'll look at it tomorrow -- too late tonite. /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]