Re: ISSUE-31 Re: KeyStorage and Pre-provisioned Keys: A proposal

On Nov 19, 2012, at 11:30 AM, Ryan Sleevi wrote:

> 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.

Ok. I think in this case most of what you say above about "optionality" becomes moot. If a device doesn't have, doesn't support, doesn't care about some particular kind of key, then any kind of key query is going to return "not found". If it reduces "optionality" we can specify that this is what should be returned in all cases where a Key object can't be returned, and don't break out "algorithm not supported" as a separate case.

I appreciate that we should not introduce optionality through our work on the API, but there do exist things that are beyond our control, like devices with different capabilities.

…Mark

>

Received on Monday, 19 November 2012 21:15:16 UTC