[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dss] a few outstanding issues
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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]