This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Crypto seems like something that would benefit node.js and company too. Can we still place it somewhere where it can be uplifted into ECMAScript proper?
I don't feel confident that this WG is able to accommodate this request, in charter or scope. Consider, for example, the notoriousness that has been the algorithm selection discussion. If you rule out the concerns of UAs - or if you rule, in scope, the concerns of server-side deployments such as node.js - you end up with a significantly different set of criteria and interoperability concerns, ones which no doubt will cause significant (continued) hurdles towards adoption. Considering the threatened formal objections over algorithm selection as case in point of this. I'm not sure what you mean by "place it somewhere where it can be uplifted into ECMAScript proper". Are you referring to the SubtleCrypto interface being attached to window/worker global scope? If so, is the suggestion to make it "Yet Another Global"?
It is already a global > "SubtleCrypto" in window true So instead of var enc = crypto.subtle.encrypt(...) you'd have > var enc = SubtleCrypto.encrypt(...) which would be similar to how other built-in libraries work, such as Math. I realize this might be too late at this point though.
Yeah, I was never sure why we hung this stuff off window.crypto, really, since fundamentally these are all static methods....
The logic behind the decision that got us here: 1) Earlier drafts introduced specific notions of key storage (eg: yet another web storage mechanism), and thus hanging off window (indicating there is logical storage attached to the current document) was seen as appropriate 2) As a consequence of that storage choice, there was a distinction between what was available to window and what was available to workers (how to handle locking of the storage database and signals of storage database changes) 3) The window.crypto.subtle is a reflection of the WG's decision to pursue a low-level API at present, but still leave flexibility for a 'high-level' API - one which might include device-level interactions (such as being discussed during the upcoming September workshop) (In reply to Anne from comment #2) > It is already a global Unintentional, but I suspect a consequence of omitting NoInterfaceObject, because callers were going to be allowed to override the .prototype to extend the algorithms (however, in practice, this doesn't work; one cannot define a new hash/digest algorithm and then have it work with RSA, for example).
Based on comment #4 I suggest we make no change here and close this as 'won't fix'.
Note that a low-level API is exactly what should be the same across ECMAScript runtimes... But I guess it's too late now :-(
In the absence of further comments I'm closing this as WONTFIX. If you object, please reopen.