- From: Ryan Sleevi <sleevi@google.com>
- Date: Tue, 4 Sep 2012 16:04:23 -0700
- To: Mark Watson <watsonm@netflix.com>
- Cc: "public-webcrypto@w3.org Working Group" <public-webcrypto@w3.org>, Arun Ranganathan <arun@mozilla.com>, "estark@mit.edu" <estark@mit.edu>, Vijay Bharadwaj <Vijay.Bharadwaj@microsoft.com>, Mitch Zollinger <mzollinger@netflix.com>
On Tue, Sep 4, 2012 at 12:35 PM, Mark Watson <watsonm@netflix.com> wrote: > Here's a revised shortened proposal for the use-case text (including Vijay's > suggestion) > > "Use case: Secure application protocol with user and device authentication > > Using the Web Cryptography API, a web application implements a secure > application protocol in Javascript, supporting confidentiality, message > integrity and authentication for both user and for the device. Device > authentication is based on pre-provisioned keys, when they are supported by > the device. Pre-provisioned keys enable the service to establish the > identity of the device into which the keys were originally embedded, thereby > establishing a level of trust based on prior knowledge of that device and > its security properties. The level of service provided is adapted to the > type of device and level of trust established. > > For the purposes of this use-case, pre-provisioned keys need only have > origin scope and thus need not lead to cross-origin tracking concerns. > > When a user navigates to the site making use of these capabilities using a > device supporting pre-provisioned keys, the User Agent provides the > Javascript application with access to the corresponding pre-provisioned keys > through the Web Cryptography API. Before doing so, the User Agent obtains > user consent through8 the use of context-specific mechanisms (possibly > including UI prompts)." > > …Mark Thanks for providing this text, Mark. My concern with the addition of the Netflix use case is: As it relates to Netflix's proposal specifically, my concerns are: - The existing use cases try to focus on the client/user-agent behaviour, while the Netflix proposal seems more focused on the service provider. - The existing use cases try to describe novel constructions of a series of operations, whereas the Netflix proposal seems to broadly focus on everything, but without quite describing what operations are actually necessary to perform. - The existing use cases try to describe generic services that can be implemented whether you're 15 or a Fortune 500. The Netflix use case does seem inherently tied to pre-provisioned keys (exclusively), and thus is not something that anybody can necessary implement, since they have to work with device manufacturers-et-al to actually discover these pre-provisioned relationships. Broadly speaking, I think the API use cases should focus on use cases that can operate regardless of the provenance of the key - that is, whether it be pre-provisioned or generated. Obviously pre-provisioned can be used to bootstrap some trust, but the more focus on pre-provisioned we as a WG place, the further away from having any compelling story to be said to the broader Internet community about the interoperability of these APIs. In looking at the existing use cases, I'm trying to figure out what operations that are present in the Netflix case that are not already captured. The use of pre-provisioned keys is mentioned in the Multi-Factor Auth use case, and then again in the Document Signing use case. The key derivation scheme has been previously acknowledged as something more Netflix specific, so I'm not sure if it needs a special use case. Are there other operations you desire?
Received on Tuesday, 4 September 2012 23:04:51 UTC