RE: ISSUE-17: Key Attributes - Proposed resolution

Can we use "name-value pairs" instead of "key-value pairs" to avoid confusion about which type of "key" we're talking about?

This doesn't match my read of the API:

> Such attributes may be initialized during the provisioning of the Key object as part of the generateKey(), importKey(), or deriveKey() operations.

AFAICT, generateKey() for example doesn't provide a way for specifying attributes during the generation. Should it? 

Other than that, I agree it captures the distinctions well. It does seem to leave a lot to the implementation with regard to deciding which attributes are read-only and which ones are not. I'd hope that after FPWD we can specify that in a little  more detail to avoid inconsistent implementations.

-----Original Message-----
From: Ryan Sleevi [mailto:sleevi@google.com] 
Sent: Monday, August 27, 2012 6:50 PM
To: public-webcrypto@w3.org
Cc: Mitch Zollinger; Mark Watson; Vijay Bharadwaj; Arun Ranganathan
Subject: ISSUE-17: Key Attributes - Proposed resolution

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?
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 Tuesday, 28 August 2012 14:42:08 UTC