Re: crypto-ISSUE-25 (Global Unique ID): How do we provision Global Unique ID for pre-provisionned symetric keys [Web Cryptography API]

On Tue, Aug 21, 2012 at 5:15 PM, Mark Watson <> wrote:
> On Aug 21, 2012, at 4:09 PM, Ryan Sleevi wrote:
>> If Netflix (or more likely, their device manufacturers) wanted to
>> expose device unique keys, then I would propose that they could
>> together propose text on how devices supporting such keys
>> 1) Be exposed to user agents
>> 2) Be exposed to web applications if supported by user agents.
>> Including, but not limited to:
>>  2a) Their presence in window.crypto.keys (or some other object that
>> implemented the KeyStorage interface)
>>  2b) The presence of read-only KeyAttributes
>>  2c) Optionally, the 'well-known names' of these attributes, along
>> with their possible values
>> Such an effort would be complementary to the Web Crypto API, but not
>> an essential part of it for implementers. That seems to highlight your
>> remarks as an "optional" piece.
>> I would rather the spec, to the degree possible, focus entirely on the
>> mandatory parts that MUST be implemented by conforming user agents.
>> That is, this is how the interfaces MUST behave and this is what MUST
>> be exposed, and to the best degree possible, avoid any MAY language.
> I appreciate the desire to maximize the normative mandatory capabilities and minimize the normative optional capabilities. But there are inevitably going to be normative optional capabilities (as you say, "UAs MAY implement X like this…" means either you don't implement it or you implement exactly what is specified.).
> There may be advantage in editorially separating the normative mandatory from the normative optional. Maybe separate documents, maybe a separate section in our one document. Normative mandatory parts will likely be implemented first. This is something we should discuss with the group. But it's unrealistic that the normative optional set is empty.
> I'm perfectly happy to propose text as you describe above for the normative optional part, but it should be part of our activity here, not outside the W3C.

I would have to defer to the chairs on this, but I would think
specifying such an attribute may or may not be within the scope of our
work, and thus would likely need consensus about being a use case that
this group would want to adopt and support.

If I understand your response correctly, we've identified and agreed
that pre-provisioned key attributes would offer sufficient flexibility
for your immediate needs. You now wish to have this WG, as part of its
work product, specify the exact format of these attributes, for the
subset of user agents that support pre-provisioned keys of this
particular nature (stored in secure elements, device storage, etc),
either as part of the primary specification or as an additional work
product of this group. Is this correct?

Such work naturally has profound privacy implications, since
supporting such a scheme implies the ability to track individual
secure elements or devices for which the user may not be aware of nor
have explicitly granted access to. This privacy requirements would
need to be carefully considered and documented.

Considering that the working group has not yet even begun to broach
the topics found in our Secondary API functionality, I could not
support such work, especially not under the timelines set forth by our
charter. At best, I would support the documentation of this need in
the supplementary Web Cryptography Use-Cases and Requirements
document, and as a possible topic for future WG activity following the
advancement to CR/PR of the primary API.

Received on Thursday, 23 August 2012 01:39:39 UTC