Launching discussions on objectives and extent for the face-to-face meeting

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

Dear all,

Below follow my first thoughts on the issues that we should
deal with in the f2f meeting. As agreed in our last conf call
we should open now a process that, starting in this message
would lead to the production of the agenda, by commenting and
ammending the content of this message.

* Focus and scope of the meeting.

Section 3.10 of the requirements document identifies two work products,
namely Protocol and Core Elements and Protocol bindings and signature
profiles.  My proposal is to try to first specify the extent of the CORE and 
to cover it during the meeting so that we can end it
having enough material as to be able to produce a first version of a
specification
without needing big efforts.
Now below follow some thoughts on the components of this work product.


Issue#0. Relationship between the Timestamp protocol and the
signature protocol.
A number of emails have gone through the list on this issue.
As we are facing the actual production of the DSS core protocol, it
would be taken into account.


Issue #1. TIER APPROACHES FOR THE REQUESTS (BOTH, SIGNING AND VERIFYING)?:
the messages by Tim and John Messing deal with
an important issue: how complicated should our protocol requests
be?. Looking at the requirements document a great number of different
possibilities appear, derived from the identified use cases.
So, on one side we have the problem of specifying complicated protocols
from the client point of view. On the other the fact that some of these 
complexities come from different use cases exposing 
actual requeriments on what has to be signed or verified...
I guess that it would be possible to follow a tier-approach where we could
start with very simple requests for the easiest cases and then define 
different tiers by adding optional components to the request so that only
those who really need would implement them.

If this approach seems OK we should then spend some time
trying to:
	1.Defining these tiers and 
	2. Identifying their specific components.

And these two steps should be done on both, requests for
signing and requests for verifying. This would be done by 
going through:
   3.3 (Common request requirements)
   3.4 Signing request requirements.
   3.6 Verification Request Requirements.

Issue#2. AUTHENTICATION MEANS.
This seems a rather important issue that deserved
lots of discussions trhough the list... We could spend some time on that
and be
sure that the solution taken accommodates most of the views.


Issue#3 CORE SIGNING RESPONSE BY THE SERVER.
So far, our requirements document identifies few requirements on 
this part of the protocol, and the ones identified seem quite obvious.
Taking this into account it does not seem one of the most dificult
parts of the work, although perhaps it can be influenced by the
work on the tiers in the request...


Issue#4. CORE VERIFICATION RESPONSE
Here we have  a number of points that have been commented so far.
I think that we could try to reach an agreement on whether which ones
should be covered by the "core" protocol and be specified in our
f2f meeting
	.Convenience and granularity of Individual reports.
	. Inclusion of cryptographic material used for verification (CRLS, OCSP, etc)
	. Inclusion of time-stamps on the former.
	. Inclusion of Time mark (should not a time-mark format be required?)

Issue#5.  Work on WSDL. Assuming that we are able to progress enough then
we could deal with initial steps dealing with the WSDL....


COuld you send to the list any comment, proposal for addition, proposal for
deletion, proposal for further details, etc that you may have? 

Regards
Juan Carlos.