Re: [dss] Comments on Core WD 01 3 Oct 03

[Trevor Perrin <trevp@trevp.net>]

At 10:09 PM 10/12/2003 +0100, Nick Pope wrote:
>Content-Transfer-Encoding: 8bit
>
>I propose the following comments on the Core protocol and elements document:
>
>Nick
>
>Comments on DSS Core
>
>WD 01 3 Oct 03
>
>1) Introduction
>
>Frederick Hirsch produced some further introductory text (including further
>notation requirements on URU time etc, as well as an intro to the DSS
>protocol) that was in the outline distributed immediately following the F2F.
>Can this be added to the introduction with an note that the introductory
>text is to be revised once the rest of the document is further matured.

Yes.


>2) 2.2.1 enveloped document
>
>If DocumentHash is used the input document cannot be enveloped as it is not
>available.
>
>add “…. and DocumentHash is not used ….”

I sent a message to Juan Carlos, where I suggested removing this 
auto-enveloping of Input Documents, and adding an option where the client 
can explicitly send things to be enveloped.  Alternatively, the client can 
just envelope things himself, once he receives the signature back.

This simplifies core processing, and avoids these complications with the 
auto-enveloping that you and Juan Carlos have brought up.  What do you think?

http://lists.oasis-open.org/archives/dss/200310/msg00030.html




>3) 2.2.2 Minor editorial
>
>The common elements are listed below and so are not “in addition”.
>“(in addition to the common ones listed in 2.2.1)” should be deleted.

They're listed in the schema fragment, but that text was referring to the 
list immediately following.


>4) 2.2.3
>
>The input document has two URIs (URI as an element, and RegURI as an
>attribute).  What is the relative role of these two URIs?  What if they are
>different?

RefURI tells the server what to put in the corresponding ds:Reference's URI 
attribute.  The <URI> element tells the server where to retrieve the 
document.

RefURI gives the relative position of document wrt signature - for example, 
RefURI may be a same-document reference like "#doc1", whereas <URI> is just 
used as a mechanism to transfer the document from client to server.



>5) 3.3 Basic Processing
>
>I suggest that add a Mention that “additional processing may be carried out
>as indicated by the <ds:options> or implied by the selected application
>profile, signature policy / implicit parameters ….(to be updated based on
>implicit parameters discussion)

Okay.


>6) 3.3 Notes
>
>a) Can the notes be given an item reference “a),b) …”

Okay.


>b) First note bullet.  Where is this transform indicated.  If it is with the
><dss:Documentxx> structure then isn’t the transform to be carried out before
>the signature is applied.  Please clarify.

Yes, it's with the Documentxx structure.  The Enveloped Signature Transform 
just excises the signature from the document.  If the client sends a 
document and indicates that the EST has been applied, the server will 
include the EST in the ds:Reference's ds:Transforms.  Then the client, upon 
receipt of the signature, can splice the signature into the document.

Since the signature has an EST, a verifying party will excise the signature 
before hashing the document.

So basically, when the client wants to envelope a signature inside a doc, 
the client just adds the EST to the document's <dss:Document*>, and then 
can splice the signature in himself.


>c) Does the client have to provide the RefURI?  Isn’t better for the “dumb
>client” philosophy to let the DSS server do the work.

The server doesn't have the context to figure this out - as things stand, 
the server has no idea where the signature is going to end up being, in 
relation to the Input Documents.    For example, the signature could end up 
in the same document as some of the Input Documentd, in which case it 
should use a same-doc URI reference, or they could end up different 
places.  Also, the server doesn't have schemas available for the Input 
Documents to figure out which are the ID attributes to use to refer to the 
Input Documents.



>d) Are these notes for reviewing or final notes?

Reviewing.

>Can this be differentiated
>e.g by using Editorial notes if the notes is for reviewer.

Okay.


>7) 3.4.2 Request ID
>
>It is suggested that this is put in the top level of the protocol structure
>so that it can be used at the basic level of the DSS protocol handler.

Lots of profiles might not need this, though, if the underlying binding 
(SOAP, HTTP over TLS, whatever) correlates requests with responses.


>8) 3.4.4 Claimed Identity
>
>This should to structured as proposed in the dss requirements document
>(3.2.2).
>
>·       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)

That's for *Requestor Identity*, not necessarily claimed identity.  The 
information supporting the name (certificate, assertion, etc.), should be 
delivered by the underlying binding, I think.  So can we get by with just a 
string here?

Trevor