Re: New Editor's Draft Published

On Tue, Sep 4, 2012 at 11:44 AM, Lu HongQian Karen <karen.lu@gemalto.com>wrote:

> Hi Ryan,****
>
> ** **
>
> Please see my questions below:****
>
> **1.  **Sec 5.1, level of abstraction “allowing rich web applications to
> manipulate the keys and without requiring the web application be aware of
> the nature of the underlying key storage.” Can applications be aware of
> that if they want to, e.g. query for keys from a particular key store?
>
Knowing whether a key is within a particular storage type by way of a
particular attribute: (Closed)
http://www.w3.org/2012/webcrypto/track/issues/11

Knowing where the key is stored by means other than an attribute: (Open)
http://www.w3.org/2012/webcrypto/track/issues/30

However, the premise still stands - applications should not need to be
aware of the (user-agent/implementation specific) key storage mechanisms to
successfully use this API.


> ****
>
> **2.  **Sec 12.3 event handler attributes, onerror, it can be helpful for
> applications to know what kind (high level) of error had happened, for
> example, invalid key. With the current spec, it is ‘null’.
>
This is something to be addressed at TPAC, I believe. The

Exceptions of the type I understand you to be requesting are generally
discouraged - http://darobin.github.com/api-design-cookbook/#exceptions

3.  **Sec. 18, keyStorage interface, it does not have addKey. Does this
> mean that newly created keys will be automatically added to the key store?
>
Correct.

Keys are not explicitly added to storage - they're implicitly added by the
act of creating them (via generate, import, or derive), and persist either
for the web context ("session") or beyond ("permanent").