Re: New Editor's Draft

On Thu, Aug 9, 2012 at 12:29 PM, Arun Ranganathan
<aranganathan@mozilla.com> wrote:
> Ryan,
>
> A few comments and observations based on the latest Editor's draft:
>
> 1. You raise the issue (within an Editor's Note) about CryptoOperation being clonable or transferable.  It would seem to me that CryptoOperation objects are "readonly" objects, which suggests that there's no point invalidating them on the sending side.  It may be possible for the implementation to share data between two threads anyway.
>
> The Key object, a readonly attribute of the CryptoOperation, *should* be close-able.  This ties into Issue 16 (https://www.w3.org/2012/webcrypto/track/issues/16).  Additionally, if we think of the Key object as a sort of special-case file, we may want to crib some of the semantics of Blob, which is close-able.  I think my vote is for"Application Semantics" *and* "Implementation Semantics."  We can have a lifetime stipulation on Keys, as well as a close().  I'm not sure what that lifetime should be exactly, but this is something we should discuss.  I wonder if Keys should last past a microtask checkpoint.
>
> Of course, having both an init() and a close() is unusual, but I think I can stomach it :)

If Key were simply a DOMString (referencing some identifier), would
these same concerns apply? My thinking of the Key object is that it's
really just a lightweight property bag - more expressible than a
DOMString, but lighter weight than a File - more akin to a Blob URI
(eg: DOMString) than the Blob itself.

Of course, I'm not sure the best way to prose this concept up, or if
it's the right approach, so I definitely agree more discussion re:
ISSUE-16 is good.

>
> 2. Is it worth overloading processData to take a Blob argument?  And, should we allow "result" to return a Blob argument?  This would then mean, of course, that in order to process a "payload" you'd have to read* it as a certain type.  Which may be overly complex, but it does allow us to work at the level of more things other than ArrayBuffers.

I think this question is related to the concerns raised in ISSUE-18.

Perhaps I've misunderstood the File API spec, but my concern with
taking a Blob is that the Blob, AIUI, has no defined canonical format
(hence the "readAs" methods). In particular, it opens up the
possibility for lossy transformations (due to creating a Blob from
DOMStrings).

>
> 3. We may wish to define init() in terms of the lifetime of a Key.  How we define init() might be useful for expiration questions.

I'm not sure I understand this comment. Were you talking init() on a
Key object (as described in point 1), or init() on the CryptoOperation
object? If the latter, then I'm definitely confused.

>
> 4. If dictionary members like "label" are to be interpreted as an opaque series of bytes, we should just use ArrayBuffer.  This is applicable for RsaOaepParams.  I don't think we gain that much more simplification with Base64 or with char conversions.

ArrayBuffer or Blob? :)

Received on Thursday, 9 August 2012 19:43:21 UTC