W3C home > Mailing lists > Public > public-wsc-wg@w3.org > April 2007

Re: Use Cases Again

From: Mary Ellen Zurko <Mary_Ellen_Zurko@notesdev.ibm.com>
Date: Mon, 23 Apr 2007 08:50:28 -0400
Cc: Web Security Context WG <public-wsc-wg@w3.org>
Message-ID: <OFC437C00F.3F8696C7-ON852572C6.0045E0D7-852572C6.004688EF@LocalDomain>
To: ses@ll.mit.edu
> 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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 5 February 2008 03:52:47 GMT