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

[Rich Salz <rsalz@datapower.com>]

> You'd like to see a sorta "micro-core" which has the *bare minimum* 
> required to process signatures.  Maybe this is just the ability to send 
> document(s) and get back a signature/signed document or verification 
> response?

Yes.  Let's get the bare minimum specified so that products can be built 
and applications deployed.

> Then everything else would be relegated to options, and profiles would 
> mix-in some set of options into the micro-core?

Yes.

> If this makes sense, what exactly do you see in the micro-core?  For 
> example, where would you allocate these things -

Well, let me take a look.  Just my opinion, not any more valid than 
anyone else's.

>  - RequestID (to correlate requests/responses)

If we define DSS to run over SOAP (we are doing that, right?)  Than this 
isn't needed.  SOAP over HTTP is request/response.  Bindings for other 
transports will have to be able to correlate request/response, so I 
don't see a need to put this into the application protocol.   Unlike 
XKMS, we're not defining a "I will get back to you" protocol, where 
clients can get asynchronous responses.

>  - ClaimedIdentity (the requestor's identity)

Not in core.

>  - IntendedAudience (who the signature is meant for)

Not in core.

>  - KeySelector (which key to use)

Yes, a ds:KeyInfo can be a parameter.  DSS servers MUST support at least 
the ds:KeyInfo/ds:KeyName element.

>  - SignedProperties/UnsignedProperties (explicit properties to add into 
> signature)

I'm not opposed.  They are really ds:Object's, with a boolean saying 
whether or not the server should add a ds:Reference to them or not.

>  - SignaturePlacement (where to stick the signature)

I don't think we should require servers to have to be able to rewrite 
input documents, so this is not in core.  However, the server does need 
to know whether it is generating an enveloped signature or not, so I 
added that.

>  - SignatureContents (what the signature covers, and what transforms to 
> apply to each thing)

We need something like that, but I wonder how much of this is overlap 
with the SignedProperties?  I also want to look at the Document types in 
more detail.  I think there are really only five types to support in the 
core:
      embeded base64 which server decodes to get the bytes to be signed
      embedded xml fragment which is "safe" since user will use a c14n
      embedded text fragment
      external URI
      a wrapper around dsig:DigestMethod and dsig:DivestValue elements 
(I like the name dss:PreDigsted, myself :)

>  - OutputOptions (what outputs to return - just the signature?  the 
> document containing the signature?  The post-transformed Input documents?)

Not sure yet.  post-transformed input seems like overkill; we shouldn't 
require DSS servers to basically be XSLT engines.  In most cases I 
believe the signature will be detached, so just returning the signature 
should be in core.

> I'm just curious what's the bare essentials you think our "core" or 
> "micro-core" or whatever should support.

These are, of course, just my opinions.  I think the hard part for us 
would be to come to consensus on what the minimal set is -- what meets 
the 80/20 rule.  For example, I would not want to require every 
conforming DSS server to have to be able to meet the international 
post-office requirements.

I've attached a schema fragment that expresses all this.  If there is 
interest, I'll develop this into a more complete proposal analogous to 
the dss-core-schema-01.xsd document in the WG repository.
	/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