- From: Ryan Sleevi <sleevi@google.com>
- Date: Mon, 19 Nov 2012 11:30:13 -0800
- To: Mark Watson <watsonm@netflix.com>
- Cc: Harry Halpin <hhalpin@w3.org>, "public-webcrypto@w3.org" <public-webcrypto@w3.org>
On Mon, Nov 19, 2012 at 10:27 AM, Mark Watson <watsonm@netflix.com> wrote: >> >> As mentioned previously, this does not sound like a suitable approach >> to addressing the technical concerns raised. > > You mentioned that you did not like overloading the existing import/export, but I didn't see any comments from you against the idea of casting different query/discovery mechanisms as 'algorithms'. Do you object to that approach generally ? Could you elaborate ? > > …Mark Every browser vendor that has commented has (rightfully) raised concerns about optional algorithms. "Optional" is generally seen as bad for the web platform. I've already received suggestions from some that the way to address algorithm regulatory/technical concerns motivating algorithm optionality would be the wholesale enabling/disabling of the feature, rather than having algorithms be optional. This is conceptually similar to WebGL, in which if a video card does not support feature X, the entire WebGL suite is disabled (or the browser software-fills it in). While not wanting to re-open the algorithm debate at this point, I provide it as a reasonable point to demonstrate the growing concern about how effective the API will be with optionality, and why more optionality is a non-starter. As related previously, I've hopefully made it clear my own view that a model of optionality - modeled after algorithms or otherwise - is pretty much a non-starter for the main spec from an implementer's perspective, for reasons such as above. If the WG reaches consensus to going further down the rabbit hole of "optionality", then we should be talking modules and separate specs (each of which MUST be wholly implemented), rather than a giant mix-and-match free for all in a single spec. Regardless though, given the significant (complete?) overlap between pre-provisioned and pre-existing keys, it seems like a single, common, mandatory API is absolutely possible to devise.
Received on Monday, 19 November 2012 19:30:45 UTC