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

On 08/23/2012 03:39 AM, Ryan Sleevi wrote:
> On Tue, Aug 21, 2012 at 5:15 PM, Mark Watson <watsonm@netflix.com> 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.
Just to clarify, in the charter we originally specified that a 
standardized notion of  "identity" (i.e. of users, client devices, etc.) 
would be part of the scope, but then decided that that would be out of 
scope: "features including special handling directly for non-opaque key 
identification schemes, access-control mechanisms beyond the enforcement 
of the same-origin policy". So thus, I think "identity" information will 
for the time being have to be done in a custom key attribute.

That being said, we recognize this is sub-optimal for Web developers who 
don't have the implementation experience of folks like Netflix. Thus, it 
makes sense for the W3C at some point to form another Working Group on 
this topic, once the work around Web Cryptography is more mature. I will 
suggest that we discuss this in the plenary session at the W3C TPAC.

   cheers,
      harry

[1]http://www.w3.org/2011/11/webcryptography-charter.html




>
> 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 Monday, 27 August 2012 19:07:25 UTC