Re: crypto-ISSUE-28: Short-names for algorithms [Web Cryptography API]

Personally, I like the idea of short names as for the majority of cases people will be using one of a few common algorithms/parameter sets. Indeed, developers should only be messing with the detailed parameters if they really know what they are doing.** Short names give a simple and less error-prone way for people to communicate about what to use.

Another option would be that the algorithm is specified in most of the API as a simple DOMString short name and we have a separate API method to bind a new short name to a specific set of parameters specified as a dictionary (I guess this binding would be origin-specific).

This way 
- we can specify short names only for the most common cases with standard default parameter values
- there is no loss of flexibility for the advanced users who want to tweak parameters
- we don't need to define cumbersome short names that embed different values for parameters that don't often need to take different values

…Mark

** yes, I know, developers should not be using this API at all unless they really know what they are doing. But in practice there will be developers using this API who are told what to do by someone who really knows what they are doing. Then the simplicity of short names aids communication.

On Aug 22, 2012, at 1:46 PM, Web Cryptography Working Group Issue Tracker wrote:

> crypto-ISSUE-28: Short-names for algorithms [Web Cryptography API]
> 
> http://www.w3.org/2012/webcrypto/track/issues/28
> 
> Raised by: Ryan Sleevi
> On product: Web Cryptography API
> 
> As part of ACTION-7, the API was adjusted such that "AlgorithmIdentifier" was a WebIDL union of (Algorithm OR DOMString). The use of DOMString was to allow a short-hand symbolic name to be supplied for an algorithm, as opposed to requiring a complete algorithm name. The intent is that the DOMString can be translated into a qualified Algorithm that is fully initialized.
> 
> For example, a string of 'RSA-PSS-SHA1' might be translated into an Algorithm equivalent of
> { 'name': 'rsa-pss',
>  'params': { 
>    'hash': { 'name': 'sha1' },
>    'mgf': { 'name': 'sha1' }
>  }
> }
> 
> However, that fails to identify the saltLength passed as part of the RsaPssParams.
> 
> One option would be to encode the missing parameters as part of the string identifier, essentially adding an alternative syntax to Dictionary to pass objects. For example, 'RSA-PSS-SHA1-20', would be parsed as ('rsa-pss', (hash = mgf = 'sha1'), saltLength = 20)
> 
> Another option would be to allow the DOMString identifier to be passed as the 'name' of an Algorithm, thus permitting the following:
> { 'name': 'rsa-pss-sha1',
>  'params': { 'saltLength': 20 }
> }
> 
> Both solutions have the downside in that they're resorting to string-encoding the parameters, rather than specifying the object. However, for parameters that may be repetitive, such simplification may lead to an easier programming experience.
> 
> A third solution would be to remove short-names, as they originated in part due to a desire to use JOSE algorithm names. The result of ISSUE-13 appears to suggest this use case may not be as significant.
> 
> 
> 
>

Received on Wednesday, 22 August 2012 21:19:58 UTC