Use-cases and requirements - observations

[Tim Moses <tim.moses@entrust.com>]

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