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

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


On Thu, Aug 7, 2014 at 6:08 PM, Ryan Sleevi <> wrote:

> On Thu, Aug 7, 2014 at 2:48 PM, Mike Jones <>
> 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 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.

Received on Thursday, 7 August 2014 22:24:47 UTC