This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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.
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.
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.
Alias support seems clear in the algorithm normalization. Suggest we leave the spec as is: resolve won't fix.
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.
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.
Shall we mark this as a feature-at-risk ?
(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.
(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" }
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.
(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.
List and conf call discussion concluded on removing support for Aliases: https://dvcs.w3.org/hg/webcrypto-api/rev/a0373bd1637b