RESEND: New proposal for ISSUE-25 (Globally unique identifiers)

[Correct issue number in subject]

All,

Here is the new text to address ISSUE-25 [1], based on the discussion this week. I will endeavor to get feedback from the Web&TV group as to the applicability of this proposal to their use-case.

1) To Section 6, Privacy Considerations, replace the last sentence of the "Super-cookies" section ('This is especially true for keys that were pre-provisioned for particular origins and for which no user interaction was provided') with a more detailed separate section:

"Pre-provisioned keys

Pre-provisioned keys may be long-lived and may be securely associated with specific hardware elements. Without sufficient safeguards it may be possible for an origin to identify a user or device without the knowledge or consent of the user. Access to pre-provisioned keys SHOULD require explicit user authorization on a per origin basis. User Agents supporting pre-provisioned keys SHOULD ensure that each origin for which keys are pre-provisioned receives unique origin-specific pre-provisioned key(s)."

2) To Section 10 (Key interface) [or wherever is most appropriate], add new sub-section, as follows:

"10.2 Pre-provisioned keys

User Agents MAY expose origin-specific pre-provisioned keys as Key objects [within tbd storage API]. Examples of pre-provisioned keys include keys stored in secure hardware elements.

10.2.1 Pre-provisioned symmetric keys and identifiers

Pre-provisioned symmetric keys are frequently provisioned with associated identifiers. Where an identifier exists that uniquely identifies the key amongst all keys pre-provisoned in the same storage location (in the widest sense, across devices, UAs etc.) and if this identifier can be canonically expressed as a sequence of no more than 256 bytes, then this identifier SHOULD be exposed, base64 encoded, as the "uid" property within the extra attribute of the Key interface. If no identifier matching these conditions exists, the "uid" attribute SHOULD NOT be present."

Note: when the key storage API issue is decided, we should clarify the meaning of "storage location". For example if we are using IndexDB the location is a specific "key" in a specific "object store" in a specific "database" (IndexDB terms in quotes).

…Mark

[1]  http://www.w3.org/2012/webcrypto/track/issues/25