Re: ISSUE-17: Key Attributes - Proposed resolution

On 8/28/12 10:50 AM, Ryan Sleevi wrote:
> Based on the discussion over the past weeks, I'd like to propose a
> resolution text for ISSUE-17.
>
> Individual requests for comments from the people cc'd follows
>
> Proposal:
>
> Interface:
> // Uses the Storage interface, from
> http://www.w3.org/TR/webstorage/#the-storage-interface
> // Given the concerns re: Storage, this may need to become an
> IDBObjectStore, from http://www.w3.org/TR/IndexedDB/#object-store
> interface KeyAttributes : Storage {
>    // Note: I'm not sure if these overrides are necessary, but because
> I'm changing behaviour, documenting it as such.
>    // For the full set of methods, see the Storage interface, from
> which this derives from.
>    setter creator void setItem(DOMString key, DOMString value);
>    deleter void removeItem(DOMString key);
> };
>
> Normative Text:
> The KeyAttributes object provides origin-specific storage for extended
> key attributes. Unlike existing name/value storage mechanisms
> (WebStorage, IndexedDB), the duration of attribute storage is tied to
> the lifetime of the Key. If the Key has been marked as temporary,
> attributes that are set persist until the Key is removed at the
> completion of the top-level browsing context. If the Key has been
> marked as permanent, attributes will remain accessible until the Key
> has been removed via KeyStorage.removeKey.
>
> KeyAttributes may contain read-only name/value pairs. Such attributes
> may be initialized during the provisioning of the Key object as part
> of the generateKey(), importKey(), or deriveKey() operations.
> Additionally, for user agents that support the pre-provisioning of
> Keys using implementation-specific mechanisms, both read-only and
> read-write attributes may also be provisioned using out-of-band,
> implementation-specific mechanisms.
>
> The setItem(key, value) method must first check if a key/value pair
> with the given /key/ already exists in the list associated with the
> object. If it does, and the /key/ refers to a read-only property name,
> the method MUST throw a NoModificationAllowedError. Otherwise, it
> shall follow the algorithm described in WebStorage.
>
> The removeItem(key) method must first check if a key/value pair with
> the given /key/ already exists in the list associated with the object.
> If it does, and the /key/ refers to a read-only property name, the
> method MUST throw a NoModificationAllowedError. Otherwise, it shall
> follow the algorithm described in WebStorage.
>
>
>
> Mitch, Mark: Does the above normative text address your concerns about
> permitting read-only attributes with respect to pre-provisioned keys?

Yes.

However, I believe that the "standard identifier for a symmetric key" 
should still be discussed, though. As Mark mentioned previously, there 
is a parallel to be drawn:
* Public Key & Private Key / Certificate
* Symmetric Key / Identifier
We would like to see a standard way to identify a symmetric key, just as 
we have a standard way to identify a public & private key pair.

> Vijay: It seems the above text should adequately cover the
> origin-specified & origin-authorized distinctions. Do you agree?
> Arun: While deriving from "Storage" is nice, I get the impression
> WebStorage is the black sheep of web APIs at the moment - in part, due
> to its synchronous nature. It seems overkill, but an alternative would
> be to expose an entire IndexedDB IDBEnvironment on every Key. Am I
> crazy for thinking that?
>

Received on Thursday, 30 August 2012 11:37:43 UTC