Re: WebCrypto Spec Error Types feedback from MS

All,

In implementing this, I see that we do not have a distinction between the
following two cases of operations with syntactically valid input parameters:
- the operation just doesn't make sense (export a public key in format
"pkcs8")
- the operation is not allowed because of policy set by the user of the API
(export a non-extractable key, sign using an RSA-SSA key that has only
"verify" usage)

Both are returning InvalidAccessError in my current text.

Do we need to distinguish these two ?

...Mark


On Wed, Mar 5, 2014 at 2:29 PM, Mark Watson <watsonm@netflix.com> wrote:

> So, we have:
>
> NotSupportedError
> SyntaxError
> InvalidStateError
> InvalidAccessError
>
> from DOM4. We need new errors for "unknown error" and "data error".
>
> Is there any reason we should not use the WebIDL predefined exception (
> http://heycam.github.io/webidl/#dfn-predefined-exception) Error for the
> "unknown error" case ?
>
> Should we generalize "data error" to include any cases where the operation
> itself encounters a fatal error ? E.g. OperationError (which would be a new
> DOMException defined in our specification.)
>
> WebIDL says that the correct way to throw an exception is like this:
>
> "Throw a DOMException with name<http://heycam.github.io/webidl/#dfn-exception-name> HierarchyRequestError
> and message <http://heycam.github.io/webidl/#dfn-exception-message> "Cannot
> append that Node here".
>
> We want to return the error, not throw. But the above seems a bit of a
> mouthful to distribute throughout our specification. IndexedDB, for
> example, doesn't bother with this level of detail. If we want to be more
> rigorous, though, we could define terminology:
>
> "When this specification says to return an OperationError the user agent
> must return a DOMException with name OperationError and message "...".
>
> or
>
> "When this specification says to return a NotSupportedError, SyntaxError,
> InvalidStateError, ... or OperationError the user agent shall return a
> DOMException with name NotSupportedError, SyntaxError, InvalidStateError,
> ... or OperationError respectively and message as shown in the following
> table ..."
>
> I think this gives us a solid basis to go to Last Call and we can easily
> hone the precise errors later.
>
> [Btw, SyntaxError is defined as a DOMException in DOM4, but WebIDL says
> that there is a predefined exception of the same name and that new
> exceptions must not have identifiers that are the same as the predefined
> ones. Anyone know how/if this is going to be resolved ?]
>
> ...Mark
>
>
>
>
>
>
>
>
>
> On Wed, Mar 5, 2014 at 8:09 AM, Mark Watson <watsonm@netflix.com> wrote:
>
>>
>>
>>
>> On Tue, Mar 4, 2014 at 6:32 PM, Ryan Sleevi <sleevi@google.com> wrote:
>>
>>>
>>>
>>>
>>> On Tue, Mar 4, 2014 at 6:23 PM, Israel Hilerio <israelh@microsoft.com>wrote:
>>>
>>>>  As promised, below is MS feedback on the types of error we believe
>>>> are useful to expose to web developers.  We correlated this information
>>>> with what was done on IndexedDB.  In addition, we when through Section 14.3
>>>> and mapped our proposed error types to steps on each section:
>>>>
>>>>
>>>>
>>>> Error Type
>>>>
>>>> Description
>>>>
>>>> Spec Mapping
>>>>
>>>> NOT_SUPPORTED_ERR
>>>>
>>>> The Algorithm is not supported
>>>>
>>>> 14.3.1 through 8, 11:
>>>>
>>>> * Step 6
>>>>
>>>> 14.3.7:
>>>>
>>>> * Step 7
>>>>
>>>> 14.3.9:
>>>>
>>>> * Step 5
>>>>
>>>> 14.3.12:
>>>>
>>>> * Step 6
>>>>
>>>> * Step 7
>>>>
>>>> SYNTAX_ERR
>>>>
>>>> Missing parameter errors.  For example, you fail to provide an IV for
>>>> CBC Mode or not providing a key length when one is needed.
>>>>
>>>> 14.3.1 through 12:
>>>>
>>>> * Steps 1 and 5
>>>>
>>>>
>>>>
>>>> INVALID_STATE_ERR
>>>>
>>>> An invalid operation was performed on an object instance. For example,
>>>> you have exceeded the number of operations allowed with a key.
>>>>
>>>> 14.3.1 through 4, 8, 11:
>>>>
>>>> * Step 8
>>>>
>>>> 14.3.7:
>>>>
>>>> * Step 12
>>>>
>>>> 14.3.10:
>>>>
>>>> * Step 6
>>>>
>>>>
>>>>
>>>> DATA_ERR
>>>>
>>>> Data provided to an operation does not meet requirements. For example,
>>>> your plain text is not padded to the correct size.
>>>>
>>>> 14.3.1 through 5:
>>>>
>>>> * Step 8
>>>>
>>>> 14.3.6:
>>>>
>>>> * Step 7
>>>>
>>>> 14.3.7:
>>>>
>>>> * Step 9
>>>>
>>>> 14.3.9:
>>>>
>>>> * Step 6
>>>>
>>>> * Step 7
>>>>
>>>> * Step 8
>>>>
>>>> 14.3.10:
>>>>
>>>> * Step 5
>>>>
>>>> 14.3.11:
>>>>
>>>> * Step 7
>>>>
>>>> 14.3.12:
>>>>
>>>> * Step 9
>>>>
>>>> * Step 10
>>>>
>>>> * Step 11
>>>>
>>>> * Step 13
>>>>
>>>> UNKNOWN_ERR
>>>>
>>>> This is a system level transient failure that don't necessarily
>>>> indicate a failure in the program logic. For example, out of memory
>>>> conditions.
>>>>
>>>> This could happen in any step
>>>>
>>>> INVALID_ACCESS_ERR
>>>>
>>>> An invalid operation was perform in an object type.  For example, you
>>>> try to encrypt with a signing key.
>>>>
>>>> 14.3.1 through 4, 8, 9:
>>>>
>>>> * Step 7
>>>>
>>>> 14.3.7:
>>>>
>>>> * Step 8
>>>>
>>>> 14.3.11:
>>>>
>>>> * Step 8
>>>>
>>>> * Step 12
>>>>
>>>> 14.3.12:
>>>>
>>>> * Step 8
>>>>
>>>>
>>>>
>>>> Remember you'll need to update step 4 on each 14.3.x to return DOMError
>>>> and remove editorial note.
>>>>
>>>>
>>>>
>>>> We were also wondering if the following steps should be in the spec
>>>> (they seemed redundant):
>>>>
>>>> ·        Section 14.3.11 Step 13
>>>>
>>>> ·        Section 14.3.12 Step 12
>>>>
>>>> ·        Section 14.3.12 Step 14
>>>>
>>>>
>>>>
>>>> Let us know if you have any questions.
>>>>
>>>> Thanks,
>>>>
>>>>
>>>>
>>>> Israel
>>>>
>>>
>>> Regarding UNKNOWN_ERR and DATA_ERR, doesn't that require taking a
>>> normative dependency on IndexedDB, which defines UnknownError and
>>> DataError? I do agree it's useful, I'm just not sure how to handle this. Do
>>> we equally define an UnknownError? Is such a thing even possible?
>>>
>>> Regarding the redundant sections, I agree, they seem redundant, because
>>> it seems to be covered by Section 14.3.11 Step 4 ("If an error occurs, run
>>> these substeps and then terminate the algorithm")
>>>
>>> That said, we probably need to smith the language, since really it seems
>>> like Step 4 will never be hit (except perhaps in Step 5?) For example,
>>> Steps 6, 7, 8, 9, 11, and 12 all separately say "Terminate this algorithm
>>> with an error" - which presumably means _don't_ run Step 4.
>>>
>>> Spec bug!
>>>
>>
>> How about, in Step 4, we say 'If the steps below say "return an error",
>> execute the following substeps and terminate the algorithm'.
>>
>> and then in the remaining steps we say "return an xxx error" instead of
>> "terminate this algorithm with an error".
>>
>> ...Mark
>>
>>
>>
>>
>