Re: Failure mode for Key-based operations

On Jun 12, 2013, at 2:49 PM, Ryan Sleevi wrote:

>> 
>> 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?
> 
> https://dvcs.w3.org/hg/webcrypto-api/raw-file/0e4d8673531e/spec/Overview.html#SubtleCrypto-method-deriveKey
> 
> So, Step 5 is meant to describe what "terminate with an error" does.
> This is why, for example, wrapKey repeats this phase (Step 7, 9, 11 of
> wrapKey)
> 
> The question is, if a DOMError is to be run through the rejection
> algorithm, what do we expect the DOMError to be? Or is your thinking
> that just any error case should be a DOMError?


The thought here is that failing with a null is not as good as failing with a reason, although DOMError doesn't serve as a terribly *good* reason.


> 
> I'm trying to find if there's any discernible differences that can
> lead to an author changing code to work.
> 

Only in reconstituting a key with the right key attributes, which presumes code that gets key usage wrong before it gets it right.  If that doesn't seem likely, we're probably ok leaving a null value during resolve.


>> 
>> 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?
> 
> Thanks for bringing this up again. This was something that went
> unresolved in discussions with Mark, and may be worth discussing
> again. The question was whether to allow (DOMString ||
> SomeNewDictionaryType) to be specified as KeyData when using a JWK. If
> it is a DOMString, what does it mean - something that will parse with
> JSON.parse()?

Yes, this was my thought.  Simply make it DOMString.  Of course, if it's a new dictionary type, it could be stringified back to JSON, but it seems the spirit of "jwk" would lend itself to a DOMString.

-- A*