RE: [dss] a few outstanding issues

[Trevor Perrin <trevp@trevp.net>]

At 09:09 PM 6/1/2003 -0400, jmessing wrote:


>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>

It's a good question whether this is an optimization we need.  I think it 
would be useful though.  Suppose the client asks the server to
- sign a resource, at some URI, that is very large, or the client
- sends some very large document to the server for signing, or the client
- sends a document hash to the server for signing.

In the first 2 cases the client might want to only receive back the 
signature and splice it in himself (for efficiency).  In the last case the 
client has no choice but to splice the signature in himself, since the 
server doesn't even have the full document available.  So my vote would be 
to leave this in for now, but if it becomes too complicated, we could 
re-evaluate later.

><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>

The authentication event is how the client proves his identity.  So it 
seems okay to call things like the X.509 certificate used, or a SAML 
Assertion, "information supporting the name".  It's Nick's formulation and 
I think it's a good one.

Elsewhere the document mentions "authentication methods", but here we're 
talking about "authentication information".  They may use the same piece of 
data - like an X.509 client certificate that the client authenticates with 
in SSL, and which then gets presented as "authentication information".

However, they may be different - the client may authenticate with a 
Kerberos ticket, or password (via a WS-Security token), or an X.509 
certificate, and then have the "authentication information" be a Liberty 
Alliance Authentication Context, or a SAML Assertion.  And even when the 
same piece of data is used (the X.509 cert), it's being used in a different 
context, for a different purpose.  So I think we need to mention 
"authentication information" here.

Trevor