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

Re: crypto-ISSUE-17: Define the scope and API for custom key attributes [Web Cryptography API]

From: Ryan Sleevi <sleevi@google.com>
Date: Sun, 5 Aug 2012 22:31:42 -0700
Message-ID: <CACvaWvYzKEqHTAHe6DBDRs5ax06p27-YzZ5__3nRg62oq-y0-w@mail.gmail.com>
To: Web Cryptography Working Group <public-webcrypto@w3.org>
Cc: Vijay Bharadwaj <Vijay.Bharadwaj@microsoft.com>, Mitch Zollinger <mzollinger@netflix.com>
On Sun, Aug 5, 2012 at 10:26 PM, Web Cryptography Working Group Issue
Tracker <sysbot+tracker@w3.org> wrote:
> crypto-ISSUE-17: Define the scope and API for custom key attributes [Web Cryptography API]
> http://www.w3.org/2012/webcrypto/track/issues/17
> Raised by: Ryan Sleevi
> On product: Web Cryptography API
> During the July Face-to-Face, vgb proposed a definition of key attributes grouped into three categories - functional, advisory/supplementary, and scope.
> Of these, only functional attributes (such as the algorithm family, size, usage) were seen as immutable attributes. Advisory/supplementary and scope represent potentially mutable attributes for an application. Some may be provided, but not enforced, by the user agent, whereas others may be wholly defined and enforced by the underlying application.
> For attributes defined by the application, the question is whether to define a custom storage mechanism on the Key object, or whether they should be implemented by applications via existing web platform APIs. An example of an existing API might be utilizing localStorage ( http://www.w3.org/TR/webstorage/ ) or IndexedDB ( http://www.w3.org/TR/IndexedDB/ ) to associate attributes with the key, using the Key's ID as a key with the underlying storage mechanism.
> Arguments In Favor:
>  - It tightly couples supplementary attributes with Keys, allowing pre-provisioned Keys to have pre-provisioned attributes exposed via the API.
>  - Clearing the IndexedDB or Web Storage will not erase application-critical attributes for keys.
> Arguments Against:
>  - It represents yet-another-Key-Value-storage mechanism, except this one tightly coupled to Keys

My preference is to leave the storage of these attributes up to the
application, using either Web Storage or IndexedDB.

If defining a custom user agent that is robust enough to support
pre-provisioned keys, it should be possible to define pre-provisioned
IndexedDB values that are keyed off the... key.

Considering the existing platform fragmentation between Web Storage,
IndexedDB, and Web SQL, it seems very undesirable to introduce
yet-another-key-value store.
Received on Monday, 6 August 2012 05:32:09 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:01:25 UTC