W3C home > Mailing lists > Public > public-webcrypto@w3.org > November 2012

Re: Rethinking KeyStorage

From: Ryan Sleevi <sleevi@google.com>
Date: Mon, 5 Nov 2012 12:24:34 -0800
Message-ID: <CACvaWvakeTC2WEhSGny7B_nCVY3nBybWDAMuwn-AvQ3-o5joqw@mail.gmail.com>
To: Mark Watson <watsonm@netflix.com>
Cc: David Dahl <ddahl@mozilla.com>, public-webcrypto <public-webcrypto@w3.org>, Arun Ranganathan <arun@mozilla.com>, Harry Halpin <hhalpin@w3.org>
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:25:03 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:17:14 UTC