Re: Failure mode for Key-based operations

Ryan,


On Jun 4, 2013, at 6:52 PM, Ryan Sleevi wrote:

> As mentioned on our call yesterday, I'm curious for input on the
> expected failure mode for key-based operations
> 
> https://dvcs.w3.org/hg/webcrypto-api/raw-file/0e4d8673531e/spec/Overview.html
> 
> For example, generateKey describes the error handling mode as invoking
> the resolver's reject algorithm, with 'null' as the value.
> 


Can this discussion also apply to encrypt(), decrypt(), sign(), verify(), and digest()?


> A thought occurred to me as to whether or not we should be generating
> a DOMError when rejecting - eg:
> https://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#interface-domerror
> 
> This would be akin to the FileReader interface (eg:
> http://dev.w3.org/2006/webapi/FileAPI/#ErrorAndException ), which
> describes a mapping between particular DOMErrors and states of the
> FileReader.
> 
> However, to be clear: I'm NOT trying to advocate the "Let's introduce
> 100 unique error codes for <insert vendor solution> here".
> 
> Unless there are compelling answers to the following questions, I
> consider the reject-with-null to be the most appropriate response.
> 
> 1) What are the types of errors that can occur when performing Key operations

generateKey -- no meaningful error outside of WebIDL or the spec. (which can handle parameter inconsistencies by throwing, like algorithm normalization failure).

deriveKey -- there's one fail state which involves "terminating this algorithm with an error" (step 6) which isn't defined (although "terminate the algorithm" is defined).  Do you mean to throw an InvalidStateError exception here?    Can Step 6 be part of the error steps in Step 5, in which case you'd return an InvalidStateError DOMError?

importKey -- probably nothing more than JWK or format errors, which the spec. already solves for.  If "KeyFormat" is "jwk" keyData still has to be an ArrayBufferView?

exportKey -- same as in deriveKey, there's a "terminate this algorithm with an error" in step 7.  Exception?  Can it be rolled into the error steps with a DOMError?

> 2) If an error is generated, can the script author take any form of
> action based upon understanding the nature of the error? eg: Can they
> alter input parameters such that it succeeds, or is it a "Failure is
> failure" mode?
> 

Only in changing Key.extractable OR .keyUsage; I think everything else is format diligence, so a null result will probably mean reworking code to look at those things.


> As much as I'm all in favour of exposing additional data, if the error
> status cannot result in actionable distinctions, I think it merely
> complicates the API for now end-user improvement.

+1.  I'm not pushing strongly for DOMError, only pointing out what caused me a reader's blip.

-- A*

Received on Tuesday, 11 June 2013 20:22:19 UTC