25557 2014-05-05 18:42:26 +0000 Spec should allow returning NotSupportedError for reasons other than failed Algorithm normalization 2014-09-29 15:02:25 +0000 1 1 1 Unclassified Web Cryptography Web Cryptography API Document unspecified PC Windows NT RESOLVED WONTFIX P2 normal --- 1 vijaybh sleevi public-webcrypto watsonm oldest_to_newest 105064 0 vijaybh 2014-05-05 18:42:26 +0000 (see discussion in http://lists.w3.org/Archives/Public/public-webcrypto/2014Apr/0085.html) Currently the spec only allows NotSupportedError to be returned if Algorithm normalization fails to produce a registered algorithm. We should give an implementation the flexibility to return this error in other cases as well: 1. If we ever add anything to the registry then old implementations will automatically be in violation of this rule as they will then be returning NotSupportedError for "registered algorithms". 2. An implementation may choose to not support a particular algorithm or operation due to various constraints, and may desire to fail early so scripts can handle errors more easily. 112303 1 watsonm 2014-09-26 19:03:30 +0000 (In reply to vijaybh from comment #0) > (see discussion in > http://lists.w3.org/Archives/Public/public-webcrypto/2014Apr/0085.html) > > Currently the spec only allows NotSupportedError to be returned if Algorithm > normalization fails to produce a registered algorithm. We should give an > implementation the flexibility to return this error in other cases as well: > > 1. If we ever add anything to the registry then old implementations will > automatically be in violation of this rule as they will then be returning > NotSupportedError for "registered algorithms". I don't think that's correct. We describe an internal [[supportedAlgorithms]] object which contains the algorithms supported *by the UA* and you return NotSupportedError for any others. > 2. An implementation may choose to not support a particular algorithm or > operation due to various constraints, and may desire to fail early so > scripts can handle errors more easily. I think these cases end up being OperationErrors right now: you pass all the WebCrypto validation / data manipulation procedures and end up failing at the operation. The problem with allowing implementations to optimize for cases they know aren't supported, whether they return OperationError of NotSupportedError is that we get inconsistent behavior across implementations as there can always be implementations that only discover whether something is supported when the operation is handed off to some crypto library. So, I would suggest Won't Fix here. 112355 2 vijaybh 2014-09-29 07:41:49 +0000 Go for it. This bug predates many changes in the spec which, as you rightly point out, have rendered it obsolete.