Re: [dss] Use-cases and requirements - observations

["jmessing" <jmessing@law-on-line.com>]

I tend to agree with Tim. A user of a DSS should generally be like rider on a bus who "leaves the driving to us." The complexity of the protocols and proof that the service did it right should be able to be produced by the service if and when something needs to be established as proof, but that should be the service's undertaking and problem, not the client's. The client should have a very simple result: the signature is affixed for signing; and the signature is validated for validations. The commitment of the service is to assure the client and a relying party that the steps in-between were done properly, upon penalty of being held liable if they were not. 

---------- Original Message ----------------------------------
From: Tim Moses <tim.moses@entrust.com>
Date:  Tue, 8 Jul 2003 08:55:15 -0400 

>Colleagues
>
>The rationale behind a services-oriented architecture is cost-reduction: the
>cost of maintaining complicated clients.  The instant a complicated client
>is deployed, it is wrong.  And the activity of replacing wrong clients is
>costly and unreliable.  Hence, the argument goes, deploy clients that are so
>simple, they can't possibly be wrong, and do the complicated stuff in a
>server setting, where there will be many fewer instances of the function and
>the software environment will be much more stable and predictable.
>
>The client function implied by the DSS use-cases and requirements is
>incredibly complicated.  Just from memory, the client has to decide whether
>to request enveloped or enveloping signatures, it has to decide which
>elements it wants to be signed, it has to decide what policy is appropriate
>to its needs, and more.  If we can cost-effectively deploy and maintain
>clients with this sort of complexity, why don't we just get them to create
>and verify their own signatures?
>
>Consider this exercise: suppose 10 million small and medium-sized companies
>were to use signatures on their electronic transactions.  Suppose that each
>company were to deal with 100 trading partners in this way.  That's 1
>billion pairs of security policies that have to be coordinated.  Suppose
>each coordination exercise takes one working day for an expert in digital
>signature standards and protocols, charging (oh, let's say) $1,000 per day.
>That's 1 trillion dollars to set the security infrastructure up (the first
>time!).  That's the GDP of France.  If each contractor goes crazy after
>doing 100 such assignments, then it will take 10 million experts to
>implement a secure e-commerce infrastructure for small and medium-sized
>companies.  That's the global supply of experts in this field for the next
>100 years.  Will DSS be lauded as the breakthrough that finally made secure
>e-commerce possible?  Maybe not!
>
>Consider the model provided by GSS-API.  The client tells the service to
>whom it is trying to talk (GSS_Init_sec_context) and the data it wants to
>send (GSS_GetMIC).  The service figures out what needs to be done: simple
>client, complicated service.
>
>The DSS use-cases and requirements do not necessarily disallow such a
>division of responsibilities.  But, it seems like an appropriate time to
>point out that DSS will not be successful unless it can be compatible with
>simple, inevitably-correct, clients.
>
>All the best.  Tim.
>
>-----------------------------------------------------------------
>Tim Moses
>613.270.3183
>
>You may leave a Technical Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/dss/members/leave_workgroup.php
>
>