Re: ISSUE-31 Re: KeyStorage and Pre-provisioned Keys: A proposal

On Nov 19, 2012, at 10:22 AM, Ryan Sleevi wrote:

>>> Is it possible that Netflix can come up with a solution to pre-provisioned same-origin keys
>> 
>> We're working on a couple of options and will send these out today or tomorrow.
>> 
>>> that involves "getKey/getKeyByID" that handles ISSUE 31, i.e. "a way to discover keys based on particular attributes, either intrinsic attributes or custom, user-defined attributes". Note that this ISSUE 31 would still stand when KeyStorage is removed and all keys are in localStorage/IndexedDB.
>> 
>> Our proposals would replace KeyStorage for pre-provisioned keys, so if one of them were agreed, KeyStorage could then be removed. I don't think there's any proposal to store "all keys" in IndexedDB - this certainly wasn't what was agreed at the f2f - and I don't think local storage can be used to store keys, because the values are just DOMStrings, right ?
> 
> As was discussed during the F2F, all Key objects can be stored in
> IndexedDB (or any other storage mechanism supporting the structured
> clone).
> 
> As was described during the F2F, having a Key object presumes that the
> caller is permitted to know about the Key's existence. That is, there
> is no need for a page to "re-discover" a key on every page load, which
> may, depending on user agent, involve additional prompts and/or
> permissions. Storing it in an appropriate web storage system allows
> the caller to retrieve and/or share access to the key, until such a
> time as storage is revoked.
> 
> But yes, the proposal is exactly that - the only *storage* of Key
> objects be accomplished via existing web storage mechanisms. Any
> discovery of any pre-existing keys (inc. pre-provisioned) be
> accomplished via key discovery mechanisms.
> 
>> 
>> I'm looking at options where different methods for querying and discovering keys can be added as "algorithms". This avoids introducing a new pattern for optionality and means we can address simple cases with a simple algorithm without having to address the entire key discovery problem captured in ISSUE-31.
>> 
>> …Mark
> 
> As mentioned previously, this does not sound like a suitable approach
> to addressing the technical concerns raised.

You mentioned that you did not like overloading the existing import/export, but I didn't see any comments from you against the idea of casting different query/discovery mechanisms as 'algorithms'. Do you object to that approach generally ? Could you elaborate ?

…Mark

> While I wait to see a
> proposal, I would simply request that an approach that is internally
> and externally consistent with the needs raised in ISSUE-31 be
> proposed.
>

Received on Monday, 19 November 2012 18:27:37 UTC