Comments on Core WD 01 3 Oct 03

["Nick Pope" <pope@secstan.com>]

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.

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 ….”


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.

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?

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)

6) 3.3 Notes

a) Can the notes be given an item reference “a),b) …”

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.

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.

d) Are these notes for reviewing or final notes?  Can this be differentiated
e.g by using Editorial notes if the notes is for reviewer.

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.

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)