Key Opacity/Identification Issue - Web Cryptography Charter Updated

I've updated the Web Cryptography Charter based on feedback from various 
people, both in and off list. The new version is here:

http://www.w3.org/2011/11/webcryptography-charter.html

I'd like in particular to point out that one of the most issues has the 
been the keys having "opaque" identifiers. In this, I'd like to clarify 
that the keys be opaque *to the API*.

If a key is pre-provisioned in the key-store of the browser or if the 
key generation is done outside (say pre-provisioned a USB key) and then 
somehow "imported" into the keystore, the API should maintain whatever 
identification scheme that belonged to the key when it was first minted. 
However, making the code connecting preprovisioned keys with particular 
identification schemes will not be the responsibility of the 
implementers of the API, but will rest will whoever wants to provision 
the keys.

By saying "opaque", I only mean that there should be *no* special key 
identification schemes natively promoted or understood by the API and no 
special routines for handling that. So for the API the identification 
scheme is opaque, but it can be non-opaque as the key-related 
information is handled "downstream" by the application.

Thus I have "specification in API of special handling for non-opaque key 
identifiers" as out of scope. Also we have moved "information about the 
destination and provenance of a key beyond the enforcement of the 
same-origin policy" back into out of scope.

Received on Friday, 9 December 2011 12:32:44 UTC