- From: Mary Ellen Zurko <Mary_Ellen_Zurko@notesdev.ibm.com>
- Date: Mon, 23 Apr 2007 08:50:28 -0400
- To: ses@ll.mit.edu
- Cc: Web Security Context WG <public-wsc-wg@w3.org>
- Message-ID: <OFC437C00F.3F8696C7-ON852572C6.0045E0D7-852572C6.004688EF@LocalDomain>
> 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?
Having concrete scenarios is useful to thinking about both
recommendations, and testing proposals. I do not believe they need to be
the only way, and I have stated several times that we need to be both
concrete and abstract in our recommendations.
> 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?
See
http://www.w3.org/2006/WSC/drafts/note/#relevance
and
http://www.w3.org/2006/WSC/wiki/PersonallyIdentifiableInformationEditorBar
(paragraph 4)
> 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.
I don't quite see what you're getting at. Can you draft some literal text?
> 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)."
> ==
That might have helped with at least one comment in the review of
wsc-usecases. I suggest drafting up the change, and tracking it in an
issue.
Mez
Received on Monday, 23 April 2007 12:50:41 UTC