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 26458 - Are all the API methods really returning Promise<any>, or can the return value be specified more precisely?
Summary: Are all the API methods really returning Promise<any>, or can the return valu...
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-07-29 19:22 UTC by Boris Zbarsky
Modified: 2014-09-25 23:09 UTC (History)
2 users (show)

See Also:

Attachments

Description Boris Zbarsky 2014-07-29 19:22:28 UTC 
For example, I would expect that verify() actually returns a Promise<boolean>.
Comment 1 Ryan Sleevi 2014-07-29 19:58:54 UTC 
I intentionally did not do that for Verify(), in order to support Signature-with-message-recovery schemes.
Comment 2 Boris Zbarsky 2014-07-29 20:03:52 UTC 
What would such a scheme return instead of a boolean?
Comment 3 Ryan Sleevi 2014-07-29 20:11:19 UTC 
For a message recovery scheme, "probably" a Bool or ArrayBuffer. Or a tuple of Bool & ArrayBuffer. It's unclear, and gross, but the alternative would be creating some new VerifyWithSignatureRecovery method, with some new key usage, to support something that's logically a Verify.
Comment 4 Boris Zbarsky 2014-07-29 20:37:03 UTC 
OK.  So what about encrypt()?  Are there cases when it's not an ArrayBuffer?
Comment 5 Ryan Sleevi 2014-07-29 20:53:04 UTC 
(In reply to Boris Zbarsky from comment #4)
> OK.  So what about encrypt()?  Are there cases when it's not an ArrayBuffer?

There was the debate about whether Encrypt should return a single ciphertext, or ciphertext+tag for AAD. Ditto for input.

Rather than going piecemeal through these, a more useful exercise might be to compile a table. My gut reaction is negative, but part of that may be change aversion, and part of that is knowing that the moment we restrict the API to some single return type, someone will inevitably show up with a use case that doesn't fit in cleanly.
Comment 6 Mark Watson 2014-09-22 18:03:58 UTC 
Based on Comment #5 I'd suggest won't fix for this. Any objections ?