Re: Rethinking KeyStorage

On Nov 5, 2012, at 8:59 AM, David Dahl wrote:

> ----- Original Message -----
>> From: "Ryan Sleevi" <sleevi@google.com>
>> To: "Mark Watson" <watsonm@netflix.com>
>> Cc: "<public-webcrypto@w3.org>" <public-webcrypto@w3.org>, "David Dahl" <ddahl@mozilla.com>, "Arun Ranganathan"
>> <arun@mozilla.com>
>> Sent: Sunday, November 4, 2012 1:44:16 AM
>> Subject: Re: Rethinking KeyStorage
>> 
> ...
>> I should note that postponing would also provide Netflix and other
>> implementers the opportunity to experiment with various approaches to
>> the problem, and will likely lead to a better, more implementable
>> solution than if this WG were to attempt to spec something up front
>> that may not be implemented for quite some time.
>> 
> 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.

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.

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.

…Mark

> 
> Regards,
> 
> David
>

Received on Monday, 5 November 2012 19:44:44 UTC