Re: Key Discovery

On Wed, Aug 21, 2013 at 9:22 AM, Martin Becker <
Martin.Becker@ruhr-uni-bochum.de> wrote:

>  Hi,****
>
> I’ve just read the Key Discover Document and I’m a little confused about
> how to obtain the name of a key.  Since you have to pass the name of the
> key to getKeyByName, you have to know the name of the key you want to use.
>
>

Yes.


> In my opinion the web application has to identify the user agent in some
> way (e.g. cookies, username). In this case the “User Tracking” part
> confuses me, because if I delete the cookie used to recognize the key, the
> key can’t be used for tracking anymore. ****
>
> Did I miss something about the name discovery for key discovery?
>

The idea is that a User Agent implementor might embed a key specifically
intended for a particular service (origin). This is pretty common for CE
devices such as TVs etc. which have embedded keys for the various services,
Netflix etc., that they support.

That key would only be available to that origin and the script from that
origin would know what to expect the key to be called, since they will have
told the names to the TV manufacturer. For example, in the Netflix case
there are two keys are called "Kph" and "Kpe". (A device that wants to
support Netflix or similar services needs to meet a number of requirements
and we are not yet in a position where being compliant to a bunch of public
specifications is enough - we have to talk to them anyway. This goes for
desktop UAs too.).

Another model is that the UA implementor provides automatically generated
keys for all origins, using names that the UA implementor decides. For
example, the UA implementor may have a single master key which they hash
with the origin to obtain an origin-specific key that they call "K" (for
want of a better name). The UA implementor would need to publish a
specification to tell people about the availability of this key, its name
and its properties. If an application (such as Netflix) chooses to use that
UA-specific key then the application would need to recognize the type of UA
and look for "K" instead of the application-specific names.

So, the "names" for pre-provisioned keys are not meant to be arbitrary, in
need of discovery. They are static, specific to an origin and/or UA.

Now, there was a use-case circulated where a device supporting WebCrypto
was (effectively) composed of a number of distinct pieces of hardware,
linked in a proprietary way, where the use-case required pre-provisioned
keys on the distinct hardware elements to be exposed. The hardware elements
could be added and removed, so if that use-case is accepted there would be
a need to discover the names of the keys that are present. That would need
an extension to this API.

...Mark 



> ****
>
> ** **
>
> Regards****
>
> Martin Becker****
>