26178 2014-06-23 14:44:07 +0000 ECMAScript standard library 2014-10-22 21:33:58 +0000 1 1 1 Unclassified Web Cryptography Web Cryptography API Document unspecified PC All RESOLVED WONTFIX P2 normal --- 1 annevk sleevi allen bzbarsky d mathias public-webcrypto watsonm oldest_to_newest 108220 0 annevk 2014-06-23 14:44:07 +0000 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? 108240 1 sleevi 2014-06-23 19:47:32 +0000 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"? 108261 2 annevk 2014-06-24 08:31:03 +0000 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. 108287 3 bzbarsky 2014-06-24 15:29:47 +0000 Yeah, I was never sure why we hung this stuff off window.crypto, really, since fundamentally these are all static methods.... 108290 4 sleevi 2014-06-24 16:48:06 +0000 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). 111954 5 watsonm 2014-09-22 17:53:30 +0000 Based on comment #4 I suggest we make no change here and close this as 'won't fix'. 111967 6 annevk 2014-09-22 18:07:45 +0000 Note that a low-level API is exactly what should be the same across ECMAScript runtimes... But I guess it's too late now :-( 113607 7 watsonm 2014-10-22 21:33:58 +0000 In the absence of further comments I'm closing this as WONTFIX. If you object, please reopen.