Re: Possible "key discovery" specification

On Dec 10, 2012, at 1:25 AM, Ryan Sleevi wrote:

> On Sun, Dec 9, 2012 at 11:34 PM, Mark Watson <watsonm@netflix.com> wrote:
>> All,
>> 
>> To further this discussion, I created a draft of a possible "key discovery"
>> specification. This draft covers only named origin-specific pre-provisioned
>> keys, since this is the case I am familiar with. However, I would see no
>> problem extending this for other forms of key (so long as there are
>> proponents prepared to do the implementation and specification work on the
>> appropriate timescales.)
>> 
>> I couldn't get this committed to a repository giving you all access via a
>> URL, so the HTML of the specification is attached.
>> 
>> Best regards,
>> 
>> Mark
>> 
>> 
>> 
> 
> Mark,
> 
> Thanks for this. We should make sure you have appropriate Mercurial
> access (everyone in the WG should).
> 
> A few thoughts:
> 1) KeyArray seems to implement a read-only pseudo-array. It seems like
> you could just have the IDL say "void complete(Key[] keys)", and let
> it be a "Real" array type. After all, once it's returned to the
> caller, just let them treat it like a normal array type (and do things
> like slice and splice and whatever other array modification they want)

Ok.

> 2) There's no form of error feedback (eg: an onerror callback). It
> would seem applications would have to, at best, guess by using
> .setTimeout(). Is that intentional?

Yes and no. It's intentional that there's no error callback. But the intention is that the single callback will always be called, possibly with an empty list.

I'm not sure there are any "error" cases as such. Either the key can be found, or it cannot (for some reason). Can you think of any cases where we want to expose the difference between key-not-found and some error case ? Are there any "temporary" errors that might be resolved by retrying ?

> 3) It's not available to Workers, as I understand it. Perhaps you
> could have WorkerContext implement WindowCryptoKeys, although I'm not
> sure how SharedWorkerContext behaves there.

Are you proposing that it should be available to Workers ? (btw, how is the Crypto object itself made available to Workers, or is it ?)

> 4) Having getKeysByName() return multiple keys seems a little
> confusing. For example, if getKeysByName({ name: 'myKey', ... }), and
> I get two keys back:
>  4.a) Are they ordered in a particular order. For example, is
> keys.get(0) always going to be the public key, and keys.get(1) always
> going to be a private key?
>  4.b) Are they supposed to be disambiguated via another means (such
> as an id attribute?). In the latest ED, I removed the ID attribute
> because it doesn't quite fit in the realm of 'arbitrary keys and
> arbitrary key storage'.
> 
> One way to resolve this might be
> interface NamedKey : Key {
>  readonly attribute DOMString name;
>  readonly attribute DOMString id;
> };

I assumed they would have attributes that disambiguated them, but the NamedKey suggestion is better.

> 
> With supporting text to provide clarification on what name contains
> and what ID contains (as well as structured clone definition, I
> believe)
> 
> With Key being structured cloneable, I just want to confirm that it's
> fine if someone does a .getKeysByName(...), gets a series of Key (or
> NamedKey) objects back, and then sticks them into IndexedDB. At that
> point, they "never" have to call getKeysByName() again, unless
> IndexedDB is cleared. That seems a nice "feature", but I wasn't sure
> if your use case dictated that Key/NamedKey objects returned by this
> should NOT be structured cloneable. If so, we'll have to proceed
> carefully here.

Yes, the intention is that you can structured clone these like any other Key. The only constraint with pre-provisioned keys is that the keying material itself stays where it is, but structured clone doesn't move the keying material, IIUC.

btw, I must say I find the structured clone algorithm itself rather abstruse. Is there any material which explains why it is the way it is ? (the 'structured clone' and 'internal structured clone algorithm' links in your draft don't go anywhere).

>

Received on Monday, 10 December 2012 17:21:30 UTC