24878 2014-03-01 16:35:32 +0000 Remove algorithm aliases 2014-10-22 21:23:17 +0000 1 1 1 Unclassified Web Cryptography Web Cryptography API Document unspecified All All RESOLVED FIXED P2 minor --- 1 rlb sleevi ap virginie.galindo watsonm oldest_to_newest 101700 0 rlb 2014-03-01 16:35:32 +0000 Is there a strong use case for algorithm aliases? There are none defined in the spec, and the Chromium implementation just fails if you pass it a string. (Polycrypt only accepts strings, but that's clearly wrong anyway.) It would simplify the API if we could drop the DOMString alternative in AlgorithmIdentifier. 101803 1 ap 2014-03-04 00:30:34 +0000 The spec used to say that passing "foo" is equivalent to passing {name: "foo"}. Was dropping this while adding the more general aliases mechanism just an editorial mistake? I think that allowing crypto.subtle.digest('sha-1', myArray) in place of crypto.subtle.digest({name: 'sha-1'}, myArray) is desirable. There is no need to expose a silly looking API to people who just want to compute a hash, and don't care about the full complexity of CryptoAlgorithms being dictionaries. 107913 2 sleevi 2014-06-16 23:21:59 +0000 https://dvcs.w3.org/hg/webcrypto-api/rev/71498804a64d addresses the case of "SHA-1" === { "name": "SHA-1" } It has not, however, removed support for aliases. There are no aliases defined, so I'm happy nuking that part from the spec entirely. 111943 3 watsonm 2014-09-22 17:40:04 +0000 Alias support seems clear in the algorithm normalization. Suggest we leave the spec as is: resolve won't fix. 111977 4 rlb 2014-09-22 21:05:59 +0000 Do any implementations support aliases, or plan to? (I, for one, do not.) Do any applications want/need it? If there's no customer for this feature, let's please take it out. 112268 5 watsonm 2014-09-26 16:44:38 +0000 There are no aliases defined, so I would not expect implementations to support any. The question is whether we want the possibility for future algorithms to define aliases, or whether we want to introduce aliases for the existing algorithms. 112791 6 watsonm 2014-10-07 14:44:45 +0000 Shall we mark this as a feature-at-risk ? 112931 7 sleevi 2014-10-09 21:35:43 +0000 (In reply to Richard Barnes from comment #4) > Do any implementations support aliases, or plan to? (I, for one, do not.) > Do any applications want/need it? If there's no customer for this feature, > let's please take it out. Do you implement the spec-defined behaviour that allows "SHA-1" to be equivalent to { "name": "SHA-1" } ? (In reply to Mark Watson from comment #6) > Shall we mark this as a feature-at-risk ? I'm fine with taking out aliases. It was syntactic sugar proposed early on for the JOSE case, but I don't think it's good, and it inherently couples UA implementations to JOSE implementations with respect to JWE/JWS, which we have so far (intentionally) avoided normatively requiring support for. So I'm in favour of taking it out over feature at risk, but with the caveat of the "foo" -> { "name": "foo" } as sugar that we need to figure out whether to keep or also toss. 112933 8 rlb 2014-10-09 21:48:11 +0000 (In reply to Ryan Sleevi from comment #7) > (In reply to Richard Barnes from comment #4) > > Do any implementations support aliases, or plan to? (I, for one, do not.) > > Do any applications want/need it? If there's no customer for this feature, > > let's please take it out. > > Do you implement the spec-defined behaviour that allows "SHA-1" to be > equivalent to { "name": "SHA-1" } ? Yes: http://dxr.mozilla.org/mozilla-central/source/dom/crypto/WebCryptoTask.cpp#121 And that seems like it covers the biggest "I don't want to write out the whole object" case. > (In reply to Mark Watson from comment #6) > > Shall we mark this as a feature-at-risk ? > > I'm fine with taking out aliases. It was syntactic sugar proposed early on > for the JOSE case, but I don't think it's good, and it inherently couples UA > implementations to JOSE implementations with respect to JWE/JWS, which we > have so far (intentionally) avoided normatively requiring support for. > > So I'm in favour of taking it out over feature at risk, but with the caveat > of the "foo" -> { "name": "foo" } as sugar that we need to figure out > whether to keep or also toss. +1 to taking it out, but keeping "foo" -> { "name": "foo" } 113071 9 virginie.galindo 2014-10-14 08:51:55 +0000 In order to progress towards exit to Last Call for the Web Crypto API, the chair suggests the following resolution for that bug. Resolution : Bug RESOLVED as WONTFIX. If none objects before the 20th of Oct @20:00 UTC, this resolution will be endorsed. 113386 10 rlb 2014-10-17 18:35:34 +0000 (In reply to virginie.galindo from comment #9) > In order to progress towards exit to Last Call for the Web Crypto API, the > chair suggests the following resolution for that bug. > > Resolution : Bug RESOLVED as WONTFIX. I'm pretty surprised by this, given that there seemed to be agreement that we should take out aliases, except for "name" -> { name: "name" }, which can be handled with much less machinery. So I would oppose resolving as WONTFIX. 113602 11 watsonm 2014-10-22 21:23:17 +0000 List and conf call discussion concluded on removing support for Aliases: https://dvcs.w3.org/hg/webcrypto-api/rev/a0373bd1637b