W3C home > Mailing lists > Public > public-webcrypto@w3.org > September 2012

Re: Use Cases | ACTION-13 Revisited

From: Ryan Sleevi <sleevi@google.com>
Date: Tue, 4 Sep 2012 16:04:23 -0700
Message-ID: <CACvaWvaySsfGgopon_VTC+_VErdVDim7H0FtBXLH0AKs59v2OQ@mail.gmail.com>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:17:13 UTC