Re: [dss] full schema for signing request, dss-proposal-rsalz-02.xsd

[Rich Salz <rsalz@datapower.com>]

>   - should you send a value for dsig:Reference/@Type on each dss:Document?

We could make it optional, since it's optional in the DSIG spec, sure.

>   - should you include Transforms on each dss:Document, to indicate
> transforms that have already been performed client-side?  These might be
> hard to squeeze in an a dss:Parameter later, so they should probably be
> part of dss:Documents.

That's an interesting idea.  If they're per-document, than it indicates
the transforms have already ahppend, but if their in the Parameters, they
indicate what to do?

>   - you include a value for the server to use as a dsig:Reference/@Id.  I
> think this would be better as part of dss:Property, if it's necessary at
> all, since this is part of the Reference, not the document.

I was thinking that for "embed the sig in doc#3" kind of things, you'd
need an Id.  Also, you want the client to be able to specify the ID
because for things like ws-security, the server won't know all the ID
attributes in the SOAP message, to it can't be sure of avoiding IDREF
conflicts.  Also**2 :), I think giving a way for the server to say, e.g.,
"I could not fetch document #id..." is useful.  We could define a SOAP
fault detail that include the "failing ID" as an attribute, e.g.

>   - If you're sending the URI and Type attributes for each dsig:Reference,
> and Transforms, then it's probably unnecessary for <PreDigested> to include
> the entire dsig:Reference.  You could just send DigestMethod/DigestValue.

Yes, if we do what you suggest above, then it's redundant.

	/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