Re: On Registries

This seems very much "six of one / half dozen of the other".  From a web
development perspective, it's just a question of whether the branch of the
if-statement sets a string or makes a different method call.  From an API
implementor perspective, it's just a new method vs. a new branch of an
if-statement.

In terms of actual API, it makes sense to me to keep the idioms we have
right now, i.e., crypto.subtle.encrypt(alg) rather than
crypto.subtle.alg.encrypt().  But in terms of managing extensibility, I
agree with Ryan that it's prudent to take a consensus-based approach rather
than a more liberal registry-based approach.  At least for "official"
algorithms that web developers can expect to have support for across the
web (vs. vendor-specific or experimental algorithms).

--Richard



On Thu, Aug 7, 2014 at 6:08 PM, Ryan Sleevi <sleevi@google.com> wrote:

>
>
>
> On Thu, Aug 7, 2014 at 2:48 PM, Mike Jones <Michael.Jones@microsoft.com>
> wrote:
>
>>  Simple.  In the first case, the algorithm is a data value.  In the
>> second case, it’s encoded in an API.  Data values are easily extensible.
>> APIs are not.  That’s why extending the space of algorithms by registering
>> new data values makes a world of sense.  Expending the algorithms by adding
>> new APIs for each would be clunky, procedurally slow, and mostly unworkable.
>>
>
> Mike,
>
> I'm sorry, but this doesn't make any sense to me.
>
> To a web developer, this abstract notion of "data value" you keep talking
> about doesn't exist.
>
> It's a specific API that I'm writing code to. If I write an application,
> and I wish to use AES, I expect it to be available as "AES-GCM". At that
> point, it's an API. The latter (subtle.aes_gcm.encrypt) is far, far more
> idiomatic JS in many respects, since it allows compositions that our API
> lacks.
>
> That "clunky, procedurally slow, mostly unworkable" process is exactly how
> the web works.
>
> I suspect you're thinking of a use case outside of the web, because the
> moment I go to https://www.example.com and it attempts to use the
> "AES-GCM" algorithm, there is no way you can reasonably call it a "data
> value". It's a fundamental API of the web, and not supporting "AES-GCM" is
> no different than not supporting window.location or window.performance
>
>
>>
>> Note that the kinds of errors you get back the two are very different as
>> well.  In the first case, it would be “unsupported algorithm”.  In the
>> second case, your code would be treated as having invalid syntax.  The code
>> is much more straightforward to handle the first kind of errors, which are
>> expected, than the second, which are unexpected.
>>
>
> No, it's not more straightforward. The entire Web relies on and recommends
> just that!
>
> var obj = (window.performance || window.someVendorPrefix_performance ||
> window.someOtherVendorPrefix_performance || my_polyfill())
>
> The testing is far, far simpler, and matches every other aspect of the web.
>
> I can't help but feel like you're still approaching the registry problem
> as seeing WebCrypto as a JOSE API. There's no question that JOSE, as a
> protocol, precisely has those algorithm names as data values. They are
> encodings of particular bits. But this is not a protocol. It's an API.
>
> When I write my code to use "AES-GCM", I expect it to work. If it does not
> exist, the API is not supported.
>
> Every UA is going to have to implement specific processing to handle each
> algorithm. As such, it's not a "data value" - it's very much an API.
>