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 25557 - Spec should allow returning NotSupportedError for reasons other than failed Algorithm normalization
Summary: Spec should allow returning NotSupportedError for reasons other than failed A...
Status: RESOLVED WONTFIX
Alias: None
Product: Web Cryptography
Classification: Unclassified
Component: Web Cryptography API Document (show other bugs)
Version: unspecified
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: Ryan Sleevi
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-05-05 18:42 UTC by vijaybh
Modified: 2014-09-29 15:02 UTC (History)
2 users (show)

See Also:

Attachments

Description vijaybh 2014-05-05 18:42:26 UTC 
(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.
Comment 1 Mark Watson 2014-09-26 19:03:30 UTC 
(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.
Comment 2 vijaybh 2014-09-29 07:41:49 UTC 
Go for it. This bug predates many changes in the spec which, as you rightly point out, have rendered it obsolete.