This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 26178 - ECMAScript standard library
Summary: ECMAScript standard library
Status: RESOLVED WONTFIX
Alias: None
Product: Web Cryptography
Classification: Unclassified
Component: Web Cryptography API Document (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Ryan Sleevi
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-06-23 14:44 UTC by Anne
Modified: 2014-10-22 21:33 UTC (History)
6 users (show)

See Also:


Attachments

Description Anne 2014-06-23 14:44:07 UTC
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?
Comment 1 Ryan Sleevi 2014-06-23 19:47:32 UTC
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"?
Comment 2 Anne 2014-06-24 08:31:03 UTC
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.
Comment 3 Boris Zbarsky 2014-06-24 15:29:47 UTC
Yeah, I was never sure why we hung this stuff off window.crypto, really, since fundamentally these are all static methods....
Comment 4 Ryan Sleevi 2014-06-24 16:48:06 UTC
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).
Comment 5 Mark Watson 2014-09-22 17:53:30 UTC
Based on comment #4 I suggest we make no change here and close this as 'won't fix'.
Comment 6 Anne 2014-09-22 18:07:45 UTC
Note that a low-level API is exactly what should be the same across ECMAScript runtimes... But I guess it's too late now :-(
Comment 7 Mark Watson 2014-10-22 21:33:58 UTC
In the absence of further comments I'm closing this as WONTFIX. If you object, please reopen.