26458 2014-07-29 19:22:28 +0000 Are all the API methods really returning Promise<any>, or can the return value be specified more precisely? 2014-09-25 23:09:04 +0000 1 1 1 Unclassified Web Cryptography Web Cryptography API Document unspecified PC All RESOLVED WONTFIX P2 normal --- 1 bzbarsky sleevi public-webcrypto watsonm oldest_to_newest 109519 0 bzbarsky 2014-07-29 19:22:28 +0000 For example, I would expect that verify() actually returns a Promise<boolean>. 109523 1 sleevi 2014-07-29 19:58:54 +0000 I intentionally did not do that for Verify(), in order to support Signature-with-message-recovery schemes. 109524 2 bzbarsky 2014-07-29 20:03:52 +0000 What would such a scheme return instead of a boolean? 109525 3 sleevi 2014-07-29 20:11:19 +0000 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. 109526 4 bzbarsky 2014-07-29 20:37:03 +0000 OK. So what about encrypt()? Are there cases when it's not an ArrayBuffer? 109529 5 sleevi 2014-07-29 20:53:04 +0000 (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. 111962 6 watsonm 2014-09-22 18:03:58 +0000 Based on Comment #5 I'd suggest won't fix for this. Any objections ?