Use Cases | ACTION-13 Revisited

While working through the use cases (per [ACTION-13]) with Wan-Teh (wtc), we came up with the following:

1. The use cases rsleevi added to the draft [spec] are pretty solid;  they are only missing a "local storage" scenario, first mentioned on the Wiki [cf. local].

2. I think our use cases should account for cross-origin keys.  This should make its way into our security considerations section as well, but by mentioning them in the use cases, we mention an important scenario that we are building this API for.  Either wtc or I will update the spec to account for this (probably in Use Case 2.1).

"Strawperson text" can be simple and terse.  For instance, from Use Case 2.1:

"A web application may wish to extend or replace existing username/password based authentication schemes with authentication methods based on proving that the user has access to some secret keying material, possibly available across multiple origins."

For ordered grouping of use cases, we may wish to move Cloud Storage next to Protected Document Exchange, simply because of how similar these use cases are (Cloud Storage may be seen as a special case of document storage, covered in the other scenario).

3. Both of us wrestled with the fact that currently, the number of ways to protect decrypted content from a web application are limited.  This isn't quite a fully-fledged use case, but is a caveat first raised by Emily Stark when discussing use cases [Stark Caveat].  One way to do this might be to use the "File | Save As" or "File Upload (file picker)" UI provenances in web browsers today, obliging users to treat decrypted content as files, thus allowing for them to at least be treated differently as readable variables in web application space.  But this is clearly overkill for OTR messaging, a use case covered in the specification (and in general, seems problematic).  

Keeping decrypted content from web applications, and ONLY making them available to the user, may be something that we don't account for, leaving web applications vulnerable to getting at decrypted content via fairly well understood ways (negligence, getting pwnt, etc.).  In order to prevent this kind of access, we'd need to make some changes that include both UI (which we've discussed as important, but not a WG activity) as well as creating a class of content that's not generally readable by web content.

We may wish to just state this as a caveat for developers to consider.

-- A*
[spec] http://www.w3.org/2012/webcrypto/WebCryptoAPI/#use-cases
[cf. local] http://www.w3.org/community/webcryptoapi/wiki/Use_Cases#Storing_local_storage
[Stark Caveat] http://lists.w3.org/Archives/Public/public-webcrypto/2012Jun/0065.html
[ACTION-13] https://www.w3.org/2012/webcrypto/track/actions/13