Re: Rethinking KeyStorage

Hi Ryan,

I don't think we could agree to the removal of KeyStorage unless you're replacing it with something equally functional. I like the idea of using existing web storage mechanisms, but if there is no solution for exposing pre-provisioned symmetric keys, then it's not going to fly.

Given your comments below, I think the best compromise would be to make KeyStorage read-only as I suggested below, and to specify the structured clone algorithm so that other storage can be used for other kinds of keys.

…Mark

On Nov 5, 2012, at 12:24 PM, Ryan Sleevi wrote:

> On Mon, Nov 5, 2012 at 11:44 AM, Mark Watson <watsonm@netflix.com> wrote:
>> 
>> On Nov 5, 2012, at 8:59 AM, David Dahl wrote:
>> 
>>>> 
>>> Perhaps, as the result of such experimentation, we could link to an "Editor's Note" in the spec that explains how a set of pre-provisioned keys might be implemented? This is something of a half-measure, (and speaking out of ignorance) but I understand that this is sometimes done in the case of features that the spec does not include, but some implementations find necessary.
>> 
>> We have a great deal of implementation experience already with pre-provisioned keys and it was a requirement that we raised at the very first workshop which lead to this group, so I think it's reasonable to continue to consider them in-scope so long as there is a use-case, proponents and people prepared to do the specification work.
> 
> No matter how prepared people are to do the specification work, I
> think we should be more concerned with people prepared to do the
> implementation work. It's very clear from our face to face, and from
> comments you made, that there are some features that are not desired
> nor planned to be implemented by all user agents. I strongly believe
> that those features should be omitted from the first version of the
> spec, and should be moved either to a supporting document (profiling
> the API for a particular set of use cases) or postponed for a separate
> and optional document, rather than being introduced into the primary
> document.
> 
>> 
>> I have no problem using existing web storage mechanisms for storing Key objects. This seems very reasonable.
>> 
>> I am only asking that the means by which pre-provisioned origin-specific Key objects are exposed be clear in the specification after this change is made, just as it is clear now with the KeyStorage object. The re-use of existing key storage mechanisms is one thing, the support for pre-provisioned keys is another. When you change the first you should not 'accidentally' remove the second.
>> 
>> If it is reasonable, from an API definition and implementation perspective, for pre-provisoned origin-specific Key objects to appear 'automatically' in IndexedDB or whatever other storage API is available, then this is fine. This could indeed be mentioned in an informative note.
> 
> I would strongly object to such a note being added to the primary
> spec. The whole point of removing KeyStorage is to specifically avoid
> needing to mandate any particular storage type for Keys. I feel like
> recommending IndexedDB in a particular scheme, beyond crossing over
> into land that might be better co-ordinated with WebApps, sort of
> defeats that goal/concern.
> 
>> 
>> Another possibility would be to retain the "keys" array as a read-only list of pre-provisioned origin-specific Key objects (so Key objects could be retrieved but not stored here).
>> 
>> Regarding schedule concern, the best approach is to drop features where there is low support or an absence of people prepared to do the specification work.
> 
> There are two very different types of support - support as "that would
> be nice" - which is very easy to for people to express positive
> feelings towards, like moms and apple pie - and support in the sense
> of "This will be implemented (and in line/in time with the chartered
> schedule)".
> 
> The more "informative but not implemented" features incorporated into
> a spec, regardless of how valuable or nice, the worse the spec
> becomes. Equally, each supplementary-but-not-essential feature
> increases the time for review and, particularly if the feature is
> controversial (such as on grounds of privacy), the greater the chance
> of Formal Objection being raised for a feature that is otherwise
> possible with the existing API.
> 
> The Spec does not and should not be required to list or enumerate,
> normatively or informatively, how certain solutions would prefer to be
> implemented. As long as the spec permits the desired operations, which
> I believe it does, I feel we're better off as a WG to postpone the
> detailed discussions until the basics are in place.
>

Received on Monday, 5 November 2012 20:36:27 UTC