Re: KeyStorage and Pre-provisioned Keys: A proposal

On Fri, Nov 16, 2012 at 5:35 PM, Mark Watson <watsonm@netflix.com> wrote:
>
> On Nov 16, 2012, at 1:40 PM, Ryan Sleevi wrote:
>
>> On Thu, Nov 15, 2012 at 7:42 PM, Mark Watson <watsonm@netflix.com> wrote:
<snip>
>>> Regarding implementation and experimentation with the WebCrypto API itself (rather than similar functional approaches that I refer to above), this isn't going to happen on TVs and like devices without some guidance from W3C. These are not desktop browsers where the implementors themselves are at W3C meetings and experimental features can be shipped behind compile-time or runtime flags. If the W3C has any ambition to extend the web platform beyond desktop browsers (and I think it should and I believe through the existence of the Web & TV Interest Group and other activities that it does), then this must be taken into account. The early stages of the specification process are exactly the place to do this, by including features for which there is demand and implementation interest and effectively "calling for implementations" through the specification advancement process.
>>
>> While I certainly respect and understand this position, I suspect this
>> highlights are fundamental differences on what we'd like to see as a
>> first version / candidate recommendation. Certainly, some working
>> groups have gone that approach - but I think their charters and timing
>> have reflected their forward-thinking, optimistic, "if we spec it,
>> they will come" approach.
>>
>> Certainly, that's not a view I share, nor do I think is reflected in
>> the chartering timeline. I suspect that, had we realized this
>> disconnect in views, we would have made this position especially clear
>> during chartering.
>>
>> While I certainly can't speak for other members, our interest is much
>> more in the "This is what we're implementing/have implemented/have
>> experience with, and we think/have demonstrated it has value for the
>> web and browser community and ecosystem."
>
> Well, then, we're closer than you think. If you accept that the first "This" in that sentence might be different for different parties, and if you include TVs and Set Top Boxes using web technology in the "web ecosystem", then I'm happy to sign up to the same statement with respect to pre-provisioned keys. That's consistent with what I said above. What I think is unlikely is that you would get multiple or the major TV manufacturers turning up now saying that they plan to ship this in the first half of next year. So I would object to that being a pre-condition to even discussing the technical solutions, as you seem to suggest. By contrast I think we have multiple desktop browser implementors expressing interest in shipping some other parts of the API relatively soon. I'm saying you should not hold TVs, with year long development cycles, to the same standard as browsers working to two-week sprints.
>
> …Mark

Then I think we're in some degree of agreement in sentiment, but in
clear disagreement about execution.

If the work of the Web Crypto WG is to deliver a "future thinking
API", then I think we should have nothing listed in secondary
features, Clearly, everything should be on the table for discussion
for holistic inclusion, and since all (potential) implementers and
timelines are considered equivalent, then I think the needs of all
participants (eg: the Korea use case, the smart card vendors) should
all be in scope.

If that sounds like a lot of work, well, it's because it is. A
tremendous amount of work, which is why the chartering discussions
were careful to try and divvy-up the work and use a milestone-based
approach. It's clear from the mail received from public comment that
there are still potential use cases not even yet considered - such as
the Kerberos use case - which show that there's lots of functionality
that logically falls under "cryptographic API"

That's why I strongly believe in the appropriateness of dividing up
the work, and do not think that TVs, with year long development cycles
and inherently closed ecosystems of vendors and site operators, should
hold browsers, with both rapid releases and a focus on an open web
platform with a strong consideration of user privacy, to the same
standard. I believe that holding the spec on pre-provisioned keys -
which are an optional component for such browsers - to be doing
exactly that.

The solution is, as I've said repeatedly, simple. Start with a core
API that defines common functionality that is suitable for all use
cases, even if it's not comprehensive enough for all use cases. Build
on that functionality iteratively, through multiple specs, to develop
APIs that are appropriate for specific device categories or specific
needs, and in a way that holistically remains consistent. This is the
approach of WebApps - with their many in-progress specs, of CSS - with
their many modules, of the DOM, with its multiple levels iteratively
expanding functionality, and of HTML, with its various tag
specifications.

In terms of focus and execution, I want to make sure that the core
spec (eg: what we published during FPWD) contains a suitable base to
expand on. The best way to do that, based on the timelines set forth
both in the charter and in practice, is to focus the first draft on
what user agents are willing and able to implement. This allows them
to apply their two-week sprints (ok, six-to-eight weeks really) to
ensure, with feedback from the web development community, that this
continues to be the right and desired API.

Meanwhile, Netflix, and other TV/media partners looking at "web
technologies", can iterate and propose their own spec about how to
apply this API to their specific needs - and hopefully with wider
participation in the WG from other vendors of such technologies.

Given that 95% of the spec seems both "obvious" and "uncontroversial",
it seems much more useful to allow progress and implementation on that
spec to continue along the chartered timelines, and allow a *separate*
effort for those features that are inherently complex or necessary
controversial to proceed as separate efforts - preferably with
concrete proposals for discussion.

Received on Monday, 19 November 2012 20:32:57 UTC