Re: Possible "key discovery" specification

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)
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?
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.
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;
};

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.

Received on Monday, 10 December 2012 09:25:47 UTC