> 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
