RE: [dss] Further - Request for inclussion to the requirementsdocument

[Juan Carlos Cruellas <cruellas@ac.upc.es>]

I think that we should try to get a consensus on the roadmap defining
the scope of what we would like to produce and if possible on the terminology.

As I see the messages going back and forward, I think that there is
quite a lot of common in both views as Trevor says.

I would suggest then, based on Trevor's roadmap and on our proposal:

1. Core  Protocol. This would include to specify: 

     - request/response protocol for getting and verifying signatures.

     - Format of the signature: XMLDSIG plus three elements:
         - XML simple (but extensible) time-stamp and time-mark elements
         - XML requestor identity element
         -XAdES Signature Policy Identifier

2. Extensions to the protocol for managing additional signature elements 
(and here I propose to substitute the term "profile" and use the term
"extension"
as a way to try to overcome the problems that seem to be with that term).
   -XAdES elements
  -CMS elements
 -Other parts of other specifications?. (the "bindings" that Trevor
mentions, and
that are not very clear for me.. perhaps you could explain Trevor?)..

3. That would finish the "normative" part of our work. At this stage we
would have
defined a protocol allowing the requestor to request to the service the
production
of XML (orCMS) signatures with a number of additional elements.
Now, specific applications being present in different environments should
make their
choice of additional elements for incorporating to the signatures for that
particular 
environment, and this selection on all the offered possibilities would
constitute a 
profile lead by the environment. 
What I think is that likely the TC does not have to produce such documents,
but just
to give some guidance on how to produce them, and that perhaps it would be
worth
to produce some example (non normative) based on one of the use cases.

Could we agree on that?

Regards

Juan Carlos.