W3C home > Mailing lists > Public > public-webcrypto@w3.org > February 2013

Re: PROPOSAL: Close ISSUE-18: Should it be possible to perform CryptoOperations as a 'streaming' operation with URI semantics?

From: Ryan Sleevi <sleevi@google.com>
Date: Mon, 4 Feb 2013 13:42:17 -0800
Message-ID: <CACvaWvbCUOfwrR-1Emq5yvdwEnWONnjXs=Jnije-n1sB3DdJ4Q@mail.gmail.com>
To: Richard Barnes <rbarnes@bbn.com>
Cc: public-webcrypto@w3.org
On Mon, Feb 4, 2013 at 11:53 AM, Richard Barnes <rbarnes@bbn.com> wrote:
> On question related to this issue that arose as we were implementing:
>
> If a 'progress' event is sent to a listener while a progressive operation is in progress, what is the expected content of the 'result' attribute?  It seems like the developer might expect partial output to be available, but that might be possible in all cases.

By definition, progress should *only* be fired when output is
available. Can you provide a more concrete definition of the problem
you're imagining?

Not all implementations can support progressive output (ex: AES-GCM or
other AEAD decryption, which requires the full ciphertext for the tag
validation). So in those cases, the progress event is not fired until
the CryptoOperation is finish()'d.

The same (non-progressive output) also applies to hash operations, for example.

>
>
>
> On Jan 31, 2013, at 2:08 PM, Ryan Sleevi <sleevi@google.com> wrote:
>
>> http://www.w3.org/2012/webcrypto/track/issues/18
>>
>> I would like to propose that we CLOSE ISSUE-18.
>>
>> The current API already incorporates supports for progressive
>> operations, such as encryption or hashing. Alternative semantics, such
>> as those afforded by the Streams API proposal, have not progressed in
>> their relevant working groups. Further, proposals for URI-like schemes
>> (such as createObjectURL) have already shown to be significantly
>> complex to implement correctly and efficiently.
>>
>> As such, I do not believe this is an issue for this working group to
>> resolve, unless we're willing to hold further activity until the
>> alternative specifications are proposed.
>>
>
Received on Monday, 4 February 2013 21:42:45 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 4 February 2013 21:42:45 GMT