Web Cryptography API: Howto discover supported algorithms?

Question

The Web Cryptography API supports the usage of the browsers native cryptograhic functionality through JavaScript, for example a reliable random number generator or the possibility to use different algorithms for encryption or signing.

The spec lists an overview of algorithms as a starting point for implementers, but has the following editorial note added:

Note: All algorithms listed should be considered as "features at risk", barring implementors adopting them. Their inclusion in the Editor's Draft reflects requests for their inclusion by members of the community, and are included as an exercise to ensure the robustness of the API defined in this specification.

As such, the list of algorithms, and the recommendations, may be significantly altered in future revisions.

As far as I understood the idea behind the specification is to provide an interface for cryptography, not write down specific algorithms (which makes totaly sense!).

How do I determine if a client supports a specific algorithm? It is good practice to hide implementation details, but since an algorithm has to have an so called recognized algorithm name I don't understand why you wouldn't want to expose the registered algorithms. Still there is no interface specified and the object where you register the algorithm is described as follows:

This specification makes use of an internal object, [[supportedAlgorithms]].

This internal object is not exposed to applications.

The only possibility to discover available algorithms at the current state would be to catch the NotSupportedError of the subtle interface.

From my point of view the discovery is simple program flow and errors should be handled as an exception, not to implement logic.

Any hints or suggestions? Links to proper w3c-mailinglist discussions are also appreciated.

Answer 1

Support for an algorithm discovery interface is not planed.

The problem is discussed in length on the w3c working groups mailinglist in 2012, which brings up some of the problems, see the Threads "RE: Strawman proposal for the low-level API - about the interoperable set of algo and algo naming" and "RE: Algorithm Discovery (was Re: Strawman proposal for the low-level API - about the interoperable set of algo and algo naming)".

One point of the discussion sums up the problems with a discovery mechanism:

(1) Discovery as I read the various appends, deals with the algorithms not the permutations of parameters that may be allowed or supported, so thus discovery of the algorithm may be successful but may still fail, and thus the extra effort for discovery is overhead and extra code path

The problem was partly again discussed with "Bug 25985 - WebCrypto should be inter-operable" and during a phone conference in July 2014 the working group decided to "Resolve the problem later" by the usage of profiles. This is also mentioned in the specification:

In particular, we are expecting a "browser profile" to be created of interoperable algorithms for Web browsers.

The idea is to create profiles for example traditional web browsers, smart tvs, etc. If a specific profile is present, it would be mandatory to support certain algorithms. This will be decided in the future after a testing phase.