| Code-Review | +1 |
Promise<boolean> verify(Hrm, is there a semantic difference between rejecting this promise and resolving it with `false`? `Promise<boolean>` always seems weird to me.
(Not asking for a spec change, just curious)
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Promise<boolean> verify(Hrm, is there a semantic difference between rejecting this promise and resolving it with `false`? `Promise<boolean>` always seems weird to me.
(Not asking for a spec change, just curious)
Hrm, is there a semantic difference between rejecting this promise and resolving it with `false`? `Promise<boolean>` always seems weird to me.
A rejected promise = "the parameters for running the crypto are set up wrong"
resolved promise with false = "we ran the crypto without error, but the signature doesn't match the data"
https://www.w3.org/TR/webcrypto-2/#SubtleCrypto-method-verify
Why exactly its that way, I don't entirely know the history behind it. I believe it has something to do with the entire API being async (which I believe happened because "crypto is expensive lets make it async, but I haven't actually looked into the spec history to verify that).
davidben@ has a lot of complaints about the design of this API, in case you're curious. https://github.com/w3c/webcrypto/issues/167#issuecomment-3806830422
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
[WebCrypto] Change return type of SubtleCrypto.verify to match spec
Change return type of SubtleCrypto.verify away from Promise<any> to
Promise<boolean>, as described by the spec
https://w3c.github.io/webcrypto/#subtlecrypto-interface
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |