- From: Ryan Sleevi <sleevi@google.com>
- Date: Mon, 29 Oct 2012 07:12:53 -0700
- To: public-webcrypto@w3.org
- Cc: David Dahl <ddahl@mozilla.com>, Arun Ranganathan <arun@mozilla.com>
Within the current draft API, there is an IDL specification for
KeyStorage [KEYSTORAGE] that is largely modelled after the Storage API
[LOCALSTORAGE].
There are several concerns with this approach:
1) The normal concerns regarding synchronous vs asynchronous
interfaces ( ISSUE-31 )
2) The "weirdness" of acquiring a Key via a numeric ID
(window.crypto.keys[3] / window.crypto.keys.getKey(3) )
3) That it introduces yet-another-tracking mechanism by providing a
persistent storage space for web applications to use and possibly
abuse. ( [PRIVACY] )
4) Confusion regarding there being (string) keys to lookup values that
are Key objects (name/value pairs is an alternative name for key/value
pairs, but it's still a little confusing)
5) Ambiguities regarding "temporary" ('session') keys and "permanent"
('persistent') keys and how one acquires references throughout.
6) The general sentiment that "Storage API is a bad API" (from
Mozilla, Chromium, Apple, and Opera) - see
https://www.w3.org/Bugs/Public/show_bug.cgi?id=12111
I'd like to propose an alternative means of dealing with KeyStorage,
which involves entirely removing the KeyStorage object.
Rather than introducing a new storage type, I'd propose we make use of
existing web storage mechanisms to store Key objects. This *does not*
require storing the raw keying material in the same implementation
used to back the various storage APIs - just that the object has
defined semantics with regards to the structured clone algorithm. This
is similar to how both Blob and File objects can be stored in existing
storage APIs, without requiring that the raw data be persisted through
those implementations.
For details on the structured clone algorithm -
http://www.w3.org/TR/html5/common-dom-interfaces.html#safe-passing-of-structured-data
. This would allow them to be stored in IndexedDB [INDEXEDDB], along
with any number of attributes or other associated data.
Based on the feedback I've received internally, I think there is
significant concern that KeyStorage is not a generally workable
solution, so I feel we'll need to rethink key storage mechanisms if
this proposal is unacceptable.
[KEYSTORAGE] http://www.w3.org/2012/webcrypto/WebCryptoAPI/#KeyStorage-interface
[LOCALSTORAGE] http://www.w3.org/TR/webstorage/
[INDEXEDDB] http://www.w3.org/TR/IndexedDB/
[PRIVACY] http://www.w3.org/2012/webcrypto/WebCryptoAPI/#privacy
Received on Monday, 29 October 2012 14:13:20 UTC