- 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