RE: [dss] a few outstanding issues

["jmessing" <jmessing@law-on-line.com>]

I think the spec is coming along well. A few points.

<draft 6>
3.5.1 Signature Placement
 Detached
 Enveloping – Server only returns signature
 Enveloping – Server returns signature with embedded input document
 Enveloped – Server only returns signature
 Enveloped – Server returns input document with embedded signature

3.4.3 Output Delivery
 How to return output
 Immediate or delayed

The client may specify whether he just wants to receive the signature back, and splice it into (or send it alongside) the documents himself, or whether he wants to receive the document with the signature embedded in it (for enveloped; vice versa for enveloping).  The server may return the signature immediately, or may return a transaction identifier, which instructs the client to check back periodically and see if the signature is ready yet.
</draft 6>
<jm>
My question is whether the potential trust issues between the server and the client make the return of a signature to be spliced into a document a real world use case such as to justify the effort to conduct interoperability for them, or whether we can pare down the possibilities to include only those where the non-detached signatures are affixed by the server. (E.g., if the server cannot control the placement and a signature fails to verify, does the owner of the server have some responsibility?)

</jm>

<draft 6>

3.2.1 Requestor Identity
If the server is not signing with a key specific to the requestor, then the server might want to represent the requestor's name, and possibly details of how the requestor authenticated, in a signed attribute.  We will define an XML element for this purpose, which will contain:
 Requestor Name (in a type/value format such as a SAML NameIdentifier)
 (Optionally) Information supporting the name (such as a SAML Assertion, Liberty Alliance Authentication Context, or X.509 Certificate)
</draft 6>

<jm> The optional information in the second paragraph really relates to authentication information, not the requestor's identity. The only thing that logically can support the requestor's identity is the identity itself. Isn't authentication information covered elsewhere in the spec? Why should it be here as well?
</jm>