Steve,
I agree with your example; it reflects what we do in a number
of paper-world environments today and what we ought to be able to do
in electronic environments in order to not unnecessarily change the
functionality that users expect. I think the work flow products by
Fischer International (and maybe other folks too) do incorporate the
facilities for the designer of a form/transaction to embody the
requisite approval rules and to enforce these rules through the
digital signature process. So, at some level, there are worked
examples of how to do this, albeit in a proprietary way. It may be an
open question how to provide this facility in a more general context.
A product providing secure, vanilla email need not solve this
problem. It may best be solved by applications that ride on top of
email. One can ask whether it is appropriate to add the functionality
to secure email to support these applications, or whether one should
provide a different set of tools that are used by the applications
that need more sophisticated features of this sort. I fear that we
may be overloading the secure email design by trying to provide a
framework to solve a much wider range of problems. Also, in
establishing a very general framework for solving such problems, we
may be underspecifying what is needed for secure email, thus
encouraging non-interoperable implementations that elect to impelement
different approaches to providing conceptually simple, secure email
functionality, all of which all permitted by the spec because it tries
to be very flexible and not forclose any options that might be needed
for other, more sophisticated applications.
Steve