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/Overview.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
>>>
>>>
>>
>

Received on Wednesday, 26 June 2013 20:43:57 UTC