OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dss message

[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]