Comments

[Tommy Lindberg <tommy.lindberg@gmail.com>]

Here are some comments on the latest draft.

Manifest:
Manifest processing is currently geared towards the client generating the Reference's and subsequently dropping them
into an InputDocument in a Sign request. In line with DSS goal of simplifying client processing, a client should also have
the means to delegate Manifest generation to the service. The Reference generation should be parameterizable with respect
to where the Reference ends up - SignedInfo or Manifest - and whether or not the Manifest should be referenced from
SignedInfo; in the typical case it would be.  From the looks of
it, DocumentBaseType could carry the additional information.

The Manifest related features of the Verify protocol also need alignment with the Manifest related processing
model set out in XML Signature section 5.1.  Specifically, Reference validation in a Manifest is not covered by
the XML Signature core validation. For example, a Manifest.Reference that fails validation does not necessarily
result in an overall signature validation failure - this is left for the application to decide upon. In order to
support this, the DSS Verify protocol must communicate which references succeeded and which didn't, so that the
client can make the appropriate decision.  I imagine an additional OptionalOutput would do the job along with some
adjustments to section 4.6.1.

<Schema> element:
I still think the multiplicity associated with the Schema element is wrong.  The responses to initially 
raising this issue was that ID-type attributes can be established in different ways - I agree with
this.  However, if the method used is to send a schema in-band, then DSS should support multiple schema
in order to facilitate schema re-use (by  applications).

Canonicalization:
In the case of XML signature, the canonicalization algorithm appears to
be somewhat hardwired to C14N.  I'd be in favor of using exclusive
canonicalization - I know others have expressed the same opinion. 
It may be enough to loosen up the text so that the service can choose
the type of canonicalization used, as part of a policy or service
agreement established out of band.

Regards,
Tommy