Re: verify method

In my opinion it would be most natural that any error condition triggers the rejectCallback. The rejectCallback can have an arbitrary number of arguments, just like the fullfillCallback (if I'm reading the specification correctly), I think we should standardise on errorCode argument (or similur) that will be provided to the rejectCallback (maybe even a second argument that is an errorMessage). The only difficult part here is, what kind off errors do we support (are they general or precise), do we leave it open to the implementor to extend the set of error codes?

Nick

On 28 Jun 2013, at 05:10, Jim Schaad <ietf@augustcellars.com> wrote:

> It might be more useful to return a false for signature validation as oppose
> to the signature algorithm is not supported.  Part of this is the fact that
> when something fails, there is no indication of what the failure is.  If the
> false half of the then returns an error code this is no longer a problem.
>
> Jim
>
>
>> -----Original Message-----
>> From: Ryan Sleevi [mailto:sleevi@google.com]
>> Sent: Wednesday, June 26, 2013 1:44 PM
>> To: Richard Barnes
>> Cc: Jim Schaad; public-webcrypto@w3.org
>> Subject: Re: verify method
>>
>> Can you explain why you see it as marginally more useful?
>>
>> ISTM that
>>
>> validate(things).then(handleSuccess, handleError) is much more intuitive -
>> that is, regardless of the error cause, errors are handled.
>>
>> Otherwise, you run into situations like
>>
>> validate(things).then(result => (result ? return handleSuccess() :
>> return handleError()), handleError);
>>
>> Especially if you want to have an error chain with error fastforwarding.
>>
>> On Wed, Jun 26, 2013 at 1:26 PM, Richard Barnes <rbarnes@bbn.com>
>> wrote:
>>>
>>> On Jun 26, 2013, at 3:20 PM, Ryan Sleevi <sleevi@google.com> wrote:
>>>
>>>> On Sun, Jun 23, 2013 at 11:23 AM, Jim Schaad <ietf@augustcellars.com>
>> wrote:
>>>>> Ryan,
>>>>>
>>>>> It is not clear to me if a verify operation where the finish
>>>>> operation fails because the signature values do not match, if the
>>>>> promise fails or succeeds and returns a fail result.
>>>>
>>>> Reasonable question.
>>>>
>>>> There are two options here. This would also apply to authenticated
>>>> encryption modes
>>>>
>>>> 1) Resolve the promise with a failure result (eg: an empty
>>>> ArrayBuffer, a boolean false)
>>>> 2) Reject the promise, with some sort of indicative error code
>>>>
>>>> It seems more useful to authors to reject the promise, as that allows
>>>> for an easier .then() flow. This would then argue for some sort of
>>>> distinguishing error code, to distinguish between a promise being
>>>> rejected for other reasons (unsupported alg? invalid params?) versus
>>>> being rejected because a signature/mac/tag didn't validate.
>>>>
>>>> Thoughts from the WG?
>>>
>>> It seems marginally more useful to me to resolve if the validation
> proceeds
>> correctly, returning a boolean with the result of the validation.  There
> are
>> effectively two returned values here:
>>> 1. Reject / resolve
>>> 2. Value returned on resolution
>>>
>>> ISTM that it would make sense to make those values equivalent to:
>>> 1. Whether validation proceeded correctly (reject if not) 2. Whether
>>> validation was successful
>>>
>>> That separates cryptographic errors from mechanical errors.  It seems
>> marginally nicer to program with:
>>>  validate(things).then( handleValidationResult ) As opposed to:
>>>  validate(things).then( handleValidationSuccess,
>>> handleValidationFailure )
>>>
>>> But I don't feel very strongly one way or the other.
>>>
>>> --Richard
>>>
>>>
>>>
>>>
>>>>
>>>>>
>>>>> Also, it might be good to document what the value returned is for
>>>>> each operation to tell me what the expected prototype is for the
>>>>> fulfill and reject callbacks are.
>>>>
>>>> Agreed - this is what the algorithm sections already try to do in
>>>> https://dvcs.w3.org/hg/webcrypto-api/raw-
>> file/0956666e55e0/spec/Overv
>>>> iew.html#algorithms
>>>>
>>>> Do you see a place where this is missing or under-specified?
>>>>
>>>> In some ways, the result is contingent upon the operation. eg: the
>>>> discussion of AES-GCM, where both a tag and ciphertext are returned
>>>> by encrypt.
>>>>
>>>>>
>>>>> Jim
>>>>>
>>>>>
>>>>
>>>
>
>
>
>


________________________________

Inventive Designers' Email Disclaimer:
http://www.inventivedesigners.com/email-disclaimer

Received on Friday, 28 June 2013 05:59:21 UTC