How to communicate error details for failed crypto operations

When a cryptographic operation fails, it rejects the Promise with null.

There is an editorial note to "Determine whether to reject the algorithm
with a DOMError or a null result."

Has there been any further consensus on how to communicate errors?

------------
Background
------------

I am a developer for Chromium's (Promise-based) Web Crypto implementation.

My experience while writing tests is that the lack of error information can
be a real difficulty when using the API.

There are a large number of errors that contribute to rejection of the
Promise, and without details it is frustrating to pinpoint the problem. A
simple typo on an AlgorithmIdentifier can have you bug hunting all over the
place.

As a temporary measure during development I made Chromium throw exceptions
synchronously with a descriptive error string for many types of errors:
particularly AlgorithmIdentifier validation to check that required
parameters are present and make sense, but also for key usage and
extractability mismatches.

However I realize this is not in line with the spec, and I am now resolving
the issue by switching to reject(null) throughout. I want to preserve the
error information somewhere though, since I found it to be very valuable as
a web developer.

At a minimum I can shove the error strings into the browser's devtools log.

Certainly this works, and doesn't require any changes to the spec. However
the implication is that each implementation of Web Crypto may develop its
own mechanism to surface error information for developers. So I want to
bring this issue to the attention of the working group.

An alternative would be to pass error context to the reject() handler
instead of null.

Not having followed the history of this decision, I appreciate that passing
error information to reject() opens up a big can of worms with regard to
which errors are enumerated, whether they are mandatory (which would be an
implementation nuisance), and what impact it would have on web
compatibility if different implementations surfaced different error details
in a way that was inspectable by running applications.

------------
Sample errors
------------

To give a taste of the flavors of error being represented by reject(null),
here some examples:

* Key usages does not allow for this operation
* Key is not valid to use with this algorithm
* Key is not extractable
* Did not specify the "optional" algorithm when importing a key (and it
couldn't inferred from the data).
* The "optional" algorithm was inconsistent with that of the key data when
importing key (ex: JWK).
* A large slew of failures when interpreting the AlgorithmIdentifier's
parameters for an operation (for instance specified an HMAC algorithm but
the "hash" property wasn't a valid digest operation).
* Unsupported key length
* Invalid key length
* Unsupported algorithm
* Internal implementation failure
* A large slew of JWK parsing errors when importing keys.
* Wrong sized "iv" when calling AES-CBC
* Invalid authentication tag length when calling AES-GCM
* Plain text was too long when doing RsaEs
* Ciphertext was too short
* Public exponent too big when generating a keypair.
.....

The majority of these are programmer errors (invalid inputs), and I feel
the granularity of error detail should be up to the specific implementation.

There is also a class of implementation failures relating to unsupported
algorithms/parameters, or internal failures.

Thanks for any feedback!