W3C home > Mailing lists > Public > public-webcrypto@w3.org > May 2014

[Bug 25711] Not clear if keys persist across sessions

From: <bugzilla@jessica.w3.org>
Date: Mon, 19 May 2014 22:03:25 +0000
To: public-webcrypto@w3.org
Message-ID: <bug-25711-7213-VUHwIHkLtx@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25711

Matt Miller <mamille2@cisco.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mamille2@cisco.com

--- Comment #5 from Matt Miller <mamille2@cisco.com> ---
(In reply to Ryan Sleevi from comment #3)
> (In reply to Kelsey Cairns from comment #2)
> > So I guess the larger problem is not so much confusion at the level of how
> > behaves. In my mind it's branching into two new directions which should
> > possibly be different bugs. 
> > 
> > I still need to think about the how-keys-behave direction. But the
> > lack-of-clarity direction is more a matter of discrepancy between the actual

> So, trying to unpack this a bit...
> 
> As a result of the TAG review, I'm adding a section that introduces and
> explains some of the terminology used in the document - cryptographic
> providers, key handles, etc. It sounds like an addition to this
> (non-normative, informative) section, a basic description of how key storage
> works with the API and how it conceptually maps to these APIs might mitigate
> the concern.
> 
> That is, explicitly (re-stating) that storage of keys is not provided by
> this API, but it can be implemented using a variety of ways. One way is
> using IndexedDB, which is a per-origin storage mechanism that accepts
> objects that support Structured Clone. Implementations can store, query, and
> delete Key objects from IndexedDB, and these Key objects will only be
> accessible to their origin by virtue of IndexedDB's security restrictions.
> 
> They can also share keys with other origins, but it must be done explicitly
> (at the script's request), using techniques like postMessage, which allow
> you to send any Structured Clone-able object to another origin, provided you
> have a handle to that origin (eg: a cross-origin iframe)

I think adding an informative section on how key storage works would be very
helpful to users of the API.  I am really looking forward to this.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Received on Monday, 19 May 2014 22:03:26 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:17:22 UTC