- From: <bugzilla@jessica.w3.org>
- Date: Wed, 14 May 2014 16:14:55 +0000
- To: public-webcrypto@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25711 --- Comment #1 from Ryan Sleevi <sleevi@google.com> --- (In reply to Kelsey Cairns from comment #0) > It isn't clear whether key objects are intended to persist after a > session is closed. If they do, how are they re-identified? Will the > browser guarantee they always get the same handle? If not, are you > supposed to re-key each time? Also fairly certain this is an INVALID bug. That is, each question seems to stem from a lack of understanding about the language or operating environment. I'm curious if there is a concrete proposal to reduce this confusion, but at the same time, the spec should be able to reasonably assume familiarity with it's normative dependencies. 1) Do Key objects persist after a session is closed? No, ECMAScript makes it quite clear the lifetime of objects, and HTML/DOM make it quite clear how that applies to the top level browsing context. Changing the top level browsing context by definition invalidates all objects. 2) If they do, how are they re-identified? The specification provides a definition for Structured Clone Algorithm of DOM. Structured Clone can be used with a variety of other APIs, such as Message Ports / Message Channels / postMessage (from the DOM spec), or with storage APIs such as IndexedDB. The identification of Key objects is left to callers, who can apply their own semantics (IDB storage key, associated meta-data in a postMessage) 3) Will the browser guarantee they always get the same handle? The spec is clear that they will refer to the same cryptographic key material - https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html#key-interface-clone - and present the same observable object. However, Structured Clone is quite clear that it does not require the same equivalence in a language sense. -- You are receiving this mail because: You are on the CC list for the bug.
Received on Wednesday, 14 May 2014 16:14:56 UTC