Use Cases Again

I've gone through the note a few times now.  I'm still confused as to the
overall goals of the document and where the use cases are supposed to fit
in.  Rather than asking how we can improve the use cases, if we have the
right twenty cases, or how we can link them to other structures, I think we
should reconsider the use cases as a starting point.  Are the use cases as
they appear in this note are the right way to think about defining the
problems we want to solve and evaluating solutions?

It appears I'm not the only one who can't keep twenty use cases in my head
at once.  I think it's quite telling that we don't actually refer to a
single use case anywhere in the document other than the location we
enumerate them.  I posit that if we had a good model for thinking about the
problems we want to solve, we would be able apply that model
elsewhere---such as when we talk about the failures and benefits of the
status quo in solving these problems.

Furthermore, I've not seen any proposal for how these use cases can be
applied for evaluating solutions.  Will we say that a proposal helps for use
cases 2, 3, 6, 8, 9, 10, 11, 16, 19, and 20?  We will evaluate proposals by
counting the use cases they address?

The structure I proposed was to replace the "actual interaction" in the use
case dimensions with the threat trees.  We keep the rest of the use case
dimensions, but don't enumerate individual use cases until we need examples.
Such a lazy algorithm will greatly reduce the number of cases we need to
enumerate.

While the use case dimensions and threat trees are far from ideal, they do
provide more structure for scoping problems and understanding solutions.
One can look at problems as branches and compare solutions by the portions
of the tree they are intended to cover.  Unlike the twenty use cases, I can
immediately see how structured information would interact with the rest of
the note.

For example, in the section of the note on merits of the status quo, we
could better explain the problems that existing solutions are intended to
solve, and where they fall short, using the threat trees.

==
In [8.1] Widely deployed, strong cryptography
"When SSL/TLS is active, cryptography and PKI work to mitigate the threat of
man-in-the middle impersonation attacks (Threat 1.B) and network
eavesdropping attacks (Threat 4)."

In [8.4] Password management
"Password managers enter passwords on behalf of users and associate
passwords with domain names.  They will not automatically enter a password
for a user if the user is lured to an impersonation site with a different
domain name (Threat 1.A)."
==

Received on Wednesday, 18 April 2007 15:12:14 UTC