18:03:57 <RRSAgent> RRSAgent has joined #crypto
18:03:57 <RRSAgent> logging to http://www.w3.org/2012/11/26-crypto-irc
18:03:59 <trackbot> RRSAgent, make logs public
18:03:59 <Zakim> Zakim has joined #crypto
18:04:01 <trackbot> Zakim, this will be SEC_WebCryp
18:04:01 <Zakim> I do not see a conference matching that name scheduled within the next hour, trackbot
18:04:02 <trackbot> Meeting: Web Cryptography Working Group Teleconference
18:04:02 <trackbot> Date: 26 November 2012
18:23:19 <ddahl> ddahl has joined #crypto
19:00:38 <hhalpin> trackbot, start meeting
19:00:40 <trackbot> RRSAgent, make logs public
19:00:42 <trackbot> Zakim, this will be SEC_WebCryp
19:00:42 <Zakim> ok, trackbot; I see SEC_WebCryp()3:00PM scheduled to start in 60 minutes
19:00:43 <trackbot> Meeting: Web Cryptography Working Group Teleconference
19:00:43 <trackbot> Date: 26 November 2012
19:00:44 <hhalpin> Zakim, what's the code?
19:00:45 <Zakim> the conference code is 27978 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), hhalpin
19:49:26 <virginie> virginie has joined #crypto
19:51:06 <mountie> mountie has joined #crypto
19:52:31 <virginie> zakim, what conferences do you see?
19:52:31 <Zakim> I see Team_(privacy)19:00Z, T&S_EGOV(Eurasian)4:00AM active
19:52:32 <Zakim> also scheduled at this time are XML_CG()3:00PM, WAI_PFWG(A11Y)3:00PM, RWC_Audio()2:00PM, SEC_WebCryp()3:00PM, WAI_AUWG()3:00PM, XML_QueryWG(fttf)2:00PM
19:54:16 <mountie> hi
19:54:45 <virginie> Zakim, this conference will be SEC_WebCryp
19:54:45 <Zakim> ok, virginie; I see SEC_WebCryp()3:00PM scheduled to start in 6 minutes
19:55:20 <Zakim> SEC_WebCryp()3:00PM has now started
19:55:25 <mountie> am i in right channel?
19:55:27 <Zakim> +ddahl
19:55:48 <ddahl> mountie: yes
19:55:57 <virginie> agenda+ welcome
19:56:06 <mountie> ok hi david
19:56:08 <ddahl> hi mountie:) how's SF?
19:56:14 <virginie> agenda+ mercurial repository
19:56:33 <mountie> not so cold. good climate
19:56:41 <virginie> agenda+ Use case (if arun shows up)
19:56:52 <ddahl> mountie: I asked a few mozillians about meeting up with you but never heard back - I saw that you were in contact with Gen, so thats good
19:57:03 <virginie> agenda+ action list
19:57:12 <markw> markw has joined #crypto
19:57:26 <Zakim> + +1.512.257.aaaa
19:57:30 <virginie> agenda+ how to move forward on key storage
19:57:46 <mountie> ddahl i don't mind
19:58:03 <virginie> agenda+ low level API and next working draft
19:58:22 <Karen> Karen has joined #crypto
19:58:31 <virginie> agenda+ Group Life
19:58:42 <virginie> agenda?
19:59:30 <Zakim> + +1.650.525.aabb
19:59:50 <pal> pal has joined #crypto
20:00:29 <Zakim> +??P3
20:00:50 <wtc> wtc has joined #crypto
20:02:19 <Zakim> +??P5
20:02:41 <virginie> who is on the call ?
20:02:52 <virginie> zakim, who is on the call ?
20:02:52 <Zakim> On the phone I see ddahl, +1.512.257.aaaa, +1.650.525.aabb, ??P3, ??P5
20:02:59 <rsleevi> rsleevi has joined #crypto
20:03:07 <virginie> zakim, ??P5 is me
20:03:07 <Zakim> +virginie; got it
20:03:17 <mountie> mountie is online
20:03:22 <rsleevi> Zakim, who is on the phone?
20:03:22 <Zakim> On the phone I see ddahl, +1.512.257.aaaa, +1.650.525.aabb, ??P3, virginie
20:03:29 <rsleevi> Zakim, aabb is Google
20:03:29 <Zakim> +Google; got it
20:03:43 <Karen> 257.aaaa is probably Karen
20:03:44 <Zakim> +WSeltzer
20:04:00 <pal> zakim, i am aabb
20:04:00 <Zakim> sorry, pal, I do not see a party named 'aabb'
20:04:01 <Zakim> + +1.408.540.aacc
20:04:10 <markw> Zakim, aacc is Netflix
20:04:10 <Zakim> +Netflix; got it
20:04:23 <markw> Zakim, Netflix has markw
20:04:23 <Zakim> +markw; got it
20:04:26 <pal> zakim, aabb is pal
20:04:26 <Zakim> sorry, pal, I do not recognize a party named 'aabb'
20:04:53 <virginie> zakim, who is on the call ?
20:04:54 <Zakim> On the phone I see ddahl, Karen?, pal, ??P3, virginie, WSeltzer, Netflix
20:04:54 <Zakim> Netflix has markw
20:05:28 <virginie> zakim, who is on the call ?
20:05:28 <Zakim> On the phone I see ddahl, Karen?, pal, Google, virginie, WSeltzer, Netflix
20:05:31 <Zakim> Google has wtc, rsleevi
20:05:31 <Zakim> Netflix has markw
20:05:47 <rsleevi> mountie: Are you on the phone?
20:06:24 <mountie> mountie has joined #crypto
20:06:25 <mitchz> mitchz has joined #crypto
20:06:28 <markw> Zakim, Netflix has mitchz
20:06:28 <Zakim> +mitchz; got it
20:07:09 <virginie> zakim, who is on the call ?
20:07:09 <Zakim> On the phone I see ddahl, Karen?, pal, Google, virginie, WSeltzer, Netflix
20:07:12 <Zakim> Google has wtc, rsleevi
20:07:12 <Zakim> Netflix has mitchz
20:07:58 <virginie> agenda?
20:08:45 <wtc> I can be the scribe
20:09:11 <virginie> chair Virginie
20:09:13 <rsleevi> scribe: Wan-Teh
20:09:15 <rsleevi> scribenick: wtc
20:10:48 <hhalpin> hhalpin has joined #crypto
20:10:53 <wtc> virginie: the agenda: mercurial repository, use cases, key storage, low-level API, etc. Anyone would like to add something else to the agenda?
20:11:05 <wtc> virginie: the agenda is approved.
20:11:12 <hhalpin> Zakim, what's the code?
20:11:12 <Zakim> the conference code is 27978 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), hhalpin
20:11:17 <virginie> http://www.w3.org/2012/11/12-crypto-minutes.html
20:11:46 <wtc> virginie: the minutes of the previous meeting are approved: http://www.w3.org/2012/11/12-crypto-minutes.html
20:11:58 <wtc> virginie: we can go to the first agenda item.
20:12:09 <wtc> virginie: mercurial repository'
20:12:15 <virginie> http://lists.w3.org/Archives/Public/public-webcrypto/2012Nov/0115.html
20:12:49 <wtc> rsleevi: harry has set up the mercurial repository. It allows the editors and authors to move away from CVS for revision control.
20:13:00 <hhalpin> Just tell me if you need any help!
20:13:14 <wtc> rsleevi: mercurial allows us to post a URL that shows the diffs of a change to the spec.
20:13:42 <wtc> rsleevi: mercurial also facilitates making incremental (smaller) changes rather than a big change.
20:13:55 <wtc> virginie: who is able to use it?
20:14:13 <wtc> virginie: is it just the Editors? Can a member make changes?
20:14:23 <hhalpin> Yes, any member can make changes
20:14:24 <hhalpin> Non-members can't
20:14:31 <hhalpin> but they can follow commits
20:14:33 <hhalpin> make sense?
20:15:06 <wtc> rsleevi: the editors should be responsible for incorporating changes to the documents.
20:15:44 <rsleevi> @hhalpin: I suppose the question is "can" and "should". Any member today *can* make changes via CVS, but that hasn't happened
20:15:52 <Zakim> +[IPcaller]
20:16:00 <hhalpin> Zakim, [IPcaller] is hhalpin
20:16:00 <Zakim> +hhalpin; got it
20:16:04 <wtc> hhalpin: any member can make changes. Non-members can't, but they can follow commits.
20:16:14 <hhalpin> Thus, the process does not change re editors
20:16:24 <hhalpin> If another member of the WG makes changes, we can follow it
20:16:28 <hhalpin> and its tracked
20:16:31 <hhalpin> so there should be no problems
20:16:36 <hhalpin> i.e. the editors can delete changes
20:16:43 <hhalpin> if say, a "rogue" member does a commit :)
20:16:51 <hhalpin> (apologies, very bad voice connection)
20:16:56 <rsleevi> Resolution: The process continues with editors making changes to the spec based on WG consensus
20:17:16 <wtc> rsleevi: Resolution: The process continues with editors making changes to the spec based on WG consensus [12:17] * rsleevi Zakim, close this agendum [12:17] * Zakim I do not know what agendum had been taken up, rsleevi
20:17:49 <virginie> http://www.w3.org/2012/webcrypto/track/actions/open
20:17:49 <wtc> virginie: skipped Use Cases because Arun is not here.
20:18:00 <wtc> virginie: Action List
20:18:20 <hhalpin> ddahl - any idea what happened to Arun?
20:18:21 <wtc> virginie: does anyone have an action to close?
20:18:30 <amorgaut> amorgaut has joined #crypto
20:18:34 <ddahl> hhalpin: unfortuantly, no
20:18:35 <virginie> http://www.w3.org/2012/webcrypto/track/actions/57
20:19:08 <hhalpin> If you need any help re HG, ping me rsleevi
20:19:09 <hhalpin> it should just work :)
20:19:16 <wtc> virginie: what's the status of http://www.w3.org/2012/webcrypto/track/actions/57?
20:19:45 <rsleevi> http://www.w3.org/2012/webcrypto/track/actions/open
20:19:52 <wtc> rsleevi: I already made some edits before the mercurial repository was set up, Will migrate my edits to Mercurial
20:20:28 <hhalpin> Note I will delay my blog post item till we publish our second heartbeat in Dec.
20:20:30 <wtc> virginie: next agenda item: key storage
20:21:02 <wtc> virginie: we have the proposal from Mark Watson.
20:21:25 <wtc> virginie: Mark made it clear that it is important for Netflix to have key storage.
20:21:55 <wtc> virginie: But the privacy concerns must be considered and addressed.
20:21:58 <mountie> keystorage is also important in Korea UseCase.
20:22:17 <wtc> mountie: keystorage is also important in Korea UseCase.
20:22:48 <hhalpin> q+
20:22:52 <wtc> virginie: this issue is difficult to resolve and make progress on.
20:23:14 <mountie> q+
20:23:24 <wtc> virginie: issues: key discovery, key import, and privacy
20:23:52 <hhalpin> Note that  "key import/export, a common method for accessing and defining properties of keys" is a secondary feature
20:23:59 <hhalpin> but obviously, lots of folks want key import/export.
20:24:02 <wtc> virginie: I would like the parties involved to work together on this.
20:24:25 <rsleevi> q+
20:24:35 <wtc> virginie: would it be OK to work together, with more time (say, two months), on this?
20:24:55 <mountie> agree. need to work more.
20:25:10 <wtc> hhalpin: I just wanted to point out "key import/export, a common method for accessing and defining properties of keys" is a secondary feature
20:25:34 <wtc> hhalpin: I don't want it to delay our progress on the first version.
20:25:37 <markw> q+
20:25:46 <mountie> we need to list up every available issues related keyStorage.
20:26:21 <hhalpin> My concern is that we will not 1) respond to reviews from first draft and 2) we need to cover primary features by mid-Dec.
20:26:29 <wtc> hhaplin: (quality of the voice connection was poor so the scribe may not have fully captured his words)
20:26:47 <hhalpin> I am just wondering if rsleevi thinks we can still do a second heartbeat
20:26:51 <wtc> hhalpin: My concern is that we will not 1) respond to reviews from first draft and 2) we need to cover primary features by mid-Dec.
20:26:52 <hhalpin> that covers the above
20:27:11 <wtc> hhaplin: I am just wondering if rsleevi thinks we can still do a second heartbeat that covers the above
20:27:37 <wtc> rsleevi: our proposal has been that the spec does not address key storage.
20:28:26 <wtc> rsleevi: we define the key object but don't define where the key objects come from. This is consistent with other W3C APIs such as the File API and WebGL.
20:29:06 <wtc> rsleevi: our proposal has been to take any proposal for key storage as a separate proposal due to the WG charter and timeline.
20:29:44 <wtc> rsleevi: to clarify, I see the key storage as a separate specification. It doesn't need to be part of the core API,
20:29:47 <pal> is this the current charter? -> http://www.w3.org/2011/11/webcryptography-charter.html
20:29:53 <Zakim> -WSeltzer
20:30:05 <pal> q+
20:30:12 <mountie> I know the keystorage will not be addressed in the spec.
20:30:31 <wtc> rsleevi: the timeline and opportunities for implementors to experiment with different methods of implementation are the reasons.
20:30:33 <mountie> but I need to know how keyStorage is secured.
20:30:41 <pal> Primary API Features [...] key storage and control beyond the lifetime of a single session
20:30:46 <virginie> q?
20:31:36 <wtc> markw: key import and export are necessary for access to pre-provisioned keys.
20:32:16 <Zakim> +WSeltzer
20:32:30 <hhalpin> Yes, but that "key storage and control beyond the lifetime of a single session" is handled by structured clone, if that's what the WG wants
20:32:40 <wtc> markw: we understand pre-provisioned keys to be in the API. We object to removing support for pre-provisioned keys (by removing the key storage API).
20:33:05 <hhalpin> q+
20:33:22 <wtc> markw: I understand from rsleevi that Google isn't interested in working on that. I think we should let parties interested in that feature to work on that.
20:33:44 <hhalpin> I mean, we could branch things out into different specs, vote, etc.
20:34:07 <wtc> markw: whether this (key discovery) would be a separate document depends on the timeline.
20:34:08 <hhalpin> There are no process problems with a separate document I believe, although it may not be Rec-track.
20:34:13 <Zakim> -WSeltzer
20:34:31 <wtc> markw: but I happen to believe we can get it done within the timeframe.
20:34:32 <hhalpin> Its hard to change Rec Track docs due to IP commitements to charter, but Working Group Notes are always possible
20:34:59 <hhalpin> Another possibility is to work it out in a separate document and then bring the document at a later point to the WG.
20:35:04 <wtc> pal: just wanted to confirm the charter does list key storage as a primary feature.
20:35:07 <rsleevi> q+
20:35:13 <markw> @hhalpin: 'although it may not be Rec-track' would count as a 'process problem', IMO
20:35:23 <wtc> pal: wanted to understand the reluctance to support it.
20:36:37 <wtc> hhalpin: (explained the the charter (the initial draft) but the voice was barely intelligible)
20:37:02 <Zakim> +WSeltzer
20:37:05 <mitchz> Harry: really difficult to understand you
20:37:30 <hhalpin> As I said, key storage means putting keys in local storage
20:37:45 <wtc> pal: I heard some statement that key storage is not primary work.  I just wanted to point out the charter states in plain English that it is in the primary features.
20:37:54 <Zakim> -hhalpin
20:38:08 <wtc> hhalpin: key storage means putting keys in local storage
20:38:15 <markw> q+
20:38:29 <virginie> ack hhalpin
20:38:55 <wtc> rsleevi: providing a structure clone algorithm using existing storage mechanism such as Indexed DB meets the "key storage" requirement in the WG charter.
20:39:17 <wtc> rsleevi: "key storage" as in secure elements and smart cards is out of scope.
20:39:26 <hhalpin_> hhalpin_ has joined #crypto
20:39:54 <hhalpin_> Note that key storage is covered by localStorage/structured clone technically, but again, hoping we can get something more sophisticated
20:39:55 <wtc> rsleevi: I'm trying to provide an incremental solution in the API based on our timeline.
20:40:19 <virginie> q?
20:40:53 <wtc> virginie: when we wrote the charter, we said we would not write anything that is secure element specific.
20:41:05 <hhalpin_> Zakim, what's the code?
20:41:05 <Zakim> the conference code is 27978 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), hhalpin_
20:41:36 <wtc> markw: both the key storage and pre-provisioned keys are in the first public working draft.
20:41:44 <ddahl> q+
20:41:51 <wtc> markw: the Lyon meeting was the first time anyone proposed to have them removed from the API.
20:41:57 <virginie> ack markw
20:41:58 <Zakim> +[IPcaller]
20:42:01 <Zakim> +[Microsoft]
20:42:08 <hhalpin_> Zakim, [IPcaller] is hhalpin
20:42:08 <Zakim> +hhalpin; got it
20:42:11 <hhalpin_> q+
20:42:36 <wtc> markw: smart cards (not origin specific) are a different problem from pre-provisioned keys in the first public working draft.
20:42:52 <wtc> markw: we should try to address the technical issues.
20:42:56 <virginie> zakim, close the queue
20:42:56 <Zakim> ok, virginie, the speaker queue is closed
20:43:19 <hhalpin_> My belief is that we need to prioritize the second heartbeat requirements
20:43:26 <hhalpin_> for the next few weeks
20:43:38 <hhalpin_> and that in makes sense however to revisit
20:43:57 <hhalpin_> the key storage questions (and import/export variations, which to me seem rather sensible as proposed by MarkW)
20:44:05 <hhalpin_> after the second heartbeat, and go for these on the third heartbeat
20:44:11 <hhalpin_> and see if we can get consensus
20:44:18 <wtc> ddahl: in the high-level API we could use a local storage. I can see we need some kind of key ID that is implicitly drawing from some kind of key storage mechanism, however...
20:44:25 <hhalpin_> q?
20:44:31 <hhalpin_> ack ddahl
20:45:20 <virginie> tentative of resolution : the pre-provision key topic will be adressed in separate specification
20:45:32 <ddahl> hhalpin_: you are voiping bad
20:45:35 <hhalpin_> In IRC
20:45:49 <wtc> hhalpin: the WG, the people who are interested in key storage and pre-provisioned keys (the voice connection was broken...)
20:46:16 <markw> +
20:46:18 <pal> q+
20:46:20 <markw> q+
20:46:23 <wtc> virginie: markw, what would you put to support pre-provisioned keys?
20:46:40 <hhalpin_> PROPOSAL: Pre-provisioned keys and key import/export addressed in second document and interested WG members can work on it, and we revisit after second heartbeat once primary features are covered.
20:46:40 <hhalpin_> The reason is we obviosly don't have consensus!
20:46:49 <hhalpin_> I.e. the editor and one implementer (Google) object
20:47:14 <wtc> hhalpin: the reason for proposing this be a separate document is we obviosly don't have consensus!
20:47:21 <hhalpin_> revisit = try to get consensus again
20:47:33 <markw> well, there are details we have to discuss first ...
20:47:58 <hhalpin_> the idea is that folks in the WG should not be blocked from making progress on their proposal due to current objections
20:48:36 <hhalpin_> Normative documents need to track on same timeline, non-normative do not.
20:48:45 <wtc> microsoft: if the reason is the schedule, would the separate document tracking the same time line, would it divide the work?
20:48:50 <ddahl> in the high level API I can see where we will need to specify private keys via an ID generated via a generate key API. The storage is implicit and I will imagine the browser will have to provide a management interface to handle key deletion, etc. There would be no additional API to manage keys, import/export, etc
20:48:58 <hhalpin_> i.e. different document would track to same timeline if we get consensus on it, otherwise it does not matter.
20:49:07 <wtc> virginie: we have some motivated people...
20:49:27 <wtc> hhalpin: different document would track to same timeline if we get consensus on it, otherwise it does not matter.
20:49:35 <hhalpin_> The W3C does work by consensus, but we want people to make progress.
20:49:55 <wtc> virginie: the problem is that most of the people who want this feature think it is a primary feature.
20:49:55 <pal> q-
20:50:02 <hhalpin_> ack hhalpin_
20:50:20 <virginie> PROPOSAL: Pre-provisioned keys and key import/export addressed in separet document and interested WG members can work on it, and will be worked in parallel
20:50:45 <markw> q+
20:50:57 <rsleevi> Note: We're very interested in this feature, but think that minimally the scope and use cases are clearly more than just Netflix's use cases, and thus potentially require a separate timeline. But +1 to separate document for separate discussion
20:51:26 <hhalpin_> The problem is that the main document needs to reflect current consensus
20:51:49 <virginie> PROPOSAL: Pre-provisioned keys and key import/export addressed in separate document and interested WG members can work on it, and will be worked in synchonisation
20:52:19 <wtc> markw: what we didn't want to see is to remove something from the first public working draft and move it to a second document. I still don't see why we can't just address the technical issues.
20:52:20 <hhalpin_> Because document we have needs to reflect consensus and this proposed feature has an objection.
20:52:41 <virginie> PROPOSAL: Pre-provisioned keys and key import/export addressed in separate document and interested WG members can work on it, and will be worked in synchronisation
20:52:43 <wtc> hhalpin: Because document we have needs to reflect consensus and this proposed feature has an objection.
20:53:15 <mountie> +1
20:53:41 <wtc> rsleevi: we've been from the start very interested in alternative key storage.
20:54:15 <wtc> rsleevi: it's not that I'm opposed to the idea. But the timeline and the implementation constraints make this difficult.
20:54:52 <wtc> rsleevi: we think a separate document to address this is a way to build consensus, while allowing the primary API to make progress and gain implementation experience.
20:55:18 <virginie> PROPOSAL: Pre-provisioned keys and key import/export will be addressed in separate document and interested WG members can work on it, and will be worked in synchronisation with the low level API
20:55:21 <wtc> rsleevi: we don't want the primary API to be blocked on this.
20:55:50 <hhalpin_> MarkW, feel free to salt and pepper the proposal to taste, since you are the main one driving this
20:55:57 <rsleevi> @virginie: I would define it as "Key discovery will be expressed in a separate document ..."
20:56:06 <wtc> markw; the ability to create the key object associated with a pre-provisioned key.
20:56:06 <Zakim> -WSeltzer
20:56:11 <rsleevi> @virginie: Import/Export in the primary doc, and storage is already addressed via structured-clone
20:56:12 <virginie> PROPOSAL: Pre-provisioned keys related features (create key, find a key)  will be addressed in separate document and interested WG members can work on it, and will be worked in synchronisation with the low level API
20:56:29 <wtc> markw: and leave key wrap/unwrap in the main document.
20:56:57 <wtc> markw: we should agree now that a draft for this document should be created.
20:57:12 <virginie> PROPOSAL: A draft specification will be created about pre-provisioned keys related features (create key, find a key)  and interested WG members can work on it, and will be worked in synchronisation with the low level API
20:57:12 <hhalpin_> sounds good to me, I can set up another HG repo for this documet.
20:57:35 <wtc> virginie: PROPOSAL: A draft specification will be created about pre-provisioned keys related features (create key, find a key)  and interested WG members can work on it, and will be worked in synchronisation with the low level API
20:57:47 <Karen> q+
20:57:56 <markw> The group will decide when they have seen the draft whether to remove the material from the main document
20:58:01 <hhalpin_> Noting we timing we need to do this all before our next hearbeat, i.e. mid-Dec.
20:58:03 <rsleevi> markw: The text was already removed per our previous resolution
20:58:19 <virginie> PROPOSAL: A draft specification will be created about pre-provisioned keys related features (create key, find a key)  and interested WG members can work on it, and will be worked in synchronisation with the low level API. Once principle of the draft approved, those features will be removed fofrom Low level API
20:58:22 <markw> otherwise we are not 100% clear on the scope of the material that is moving from main draft to new draft
20:58:25 <wtc> markw: when we see that draft, the WG will decide whether to remove the material from the main document
20:58:56 <virginie> PROPOSAL: A draft specification will be created about pre-provisioned keys related features (create key object, find a key)  and interested WG members can work on it, and will be worked in synchronisation with the low level API. Once principle of the draft approved, those features will be removed fofrom Low level API
20:59:21 <rsleevi> -1
20:59:22 <wtc> Karen: to clarify: "create key" means creating the key object, because the key already exists.
20:59:45 <markw> +1
20:59:48 <mitchz> +1
20:59:51 <hhalpin_> What bit do you disagree with rsleevi?
20:59:56 <hhalpin_> i.e. the "removed"
21:00:00 <hhalpin_> or something else?
21:00:01 <Karen> +1
21:00:05 <johnsim_> johnsim_ has joined #crypto
21:00:06 <rsleevi> @virginie: The objection is "key discovery" instead of pre-provisioned, and the added text regarding "removing features" was already addressed in a previous resolution
21:01:04 <wtc> rsleevi: the objection is: "key discovery" instead of pre-provisioned, and the added text regarding "removing features" was already addressed in a previous resolution
21:01:18 <wtc> rsleevi: so it's procedural.
21:01:19 <markw> No, have not agreed to remove KeyStorage
21:01:24 <markw> It is in the draft up on the web
21:01:34 <hhalpin_> There is editors draft and next heartbeat
21:01:46 <hhalpin_> i.e. "heartbeat" = Working Draft
21:01:48 <markw> http://www.w3.org/2012/webcrypto/WebCryptoAPI/#KeyStorage-interface
21:01:52 <hhalpin_> Working Draft needs to reflect consensus
21:01:57 <rsleevi> @virginie: PROPOSAL: A draft specification will be created about key discovery and interested WG members can work on it, and will be worked in synchronisation with the low level API
21:02:00 <hhalpin_> Editors Draft not necessarily so
21:02:05 <hhalpin_> How about times for next meeting?
21:02:09 <markw> Well, there's certainly no consensus to publish a heartbeat without it, right now
21:02:16 <hhalpin_> I suggest given things up in the air, we meet next week.
21:02:24 <wtc> virginie: our next call is the 10th of December, in two weeks.
21:02:29 <johnsim_> i agree
21:02:44 <wtc> virginie: we will address the items we didn't have time to address today.
21:03:00 <hhalpin_> q+
21:03:13 <hhalpin_> We are in a bit of a mess, Virginie, given we need a heartbeat by mid-Dec.
21:03:19 <hhalpin_> We need to have that doc ready by next call
21:03:23 <hhalpin_> Rsleevi, do you think that's possible?
21:03:31 <Zakim> -Google
21:03:34 <Zakim> -virginie
21:03:35 <Zakim> -ddahl
21:03:36 <Zakim> -[Microsoft]
21:03:37 <Zakim> -Karen?
21:03:37 <Zakim> -Netflix
21:03:48 <rsleevi> @hhalpin: The update? Yes.
21:03:59 <Zakim> -pal
21:04:01 <hhalpin_> Given a review by Alex Russell as well?
21:04:19 <hhalpin_> I.e. we need to address 1) Security considerations 2) usability and 3) IRTF comments
21:04:23 <rsleevi> hhalpin_: Yes, there's a lot of stuff to propose there
21:04:25 <virginie> @harry yeap, sorry that we could not adress that topic
21:04:50 <rsleevi> hhalpin_: regarding usability, I don't know if we'll have that fully in the next heartbeat
21:05:04 <rsleevi> hhalpin_: That obviously requires more discussion than we've had thus far :)
21:05:07 <hhalpin_> rsleevi, if you get Alex's comments in, I can also run it by Robin Berjon etc.
21:05:10 <virginie> harry, ryan, david d, what do you think about a call to define what is feasible for our next heartbeat ?
21:05:25 <hhalpin_> yes, the problem is that this KeyStorage discussion continously distracts us from primary features
21:05:25 <RRSAgent> I have made the request to generate http://www.w3.org/2012/11/26-crypto-minutes.html rsleevi
21:05:41 <hhalpin_> I think we should at least do a call next week with the editors to prepare for the next heartbeat
21:05:47 <hhalpin_> trackbot, end meeting
21:05:47 <trackbot> Zakim, list attendees
21:05:47 <Zakim> As of this point the attendees have been ddahl, +1.512.257.aaaa, +1.650.525.aabb, virginie, wtc, rsleevi, WSeltzer, Karen?, +1.408.540.aacc, markw, pal, mitchz, hhalpin,
21:05:50 <Zakim> ... [Microsoft]
21:05:55 <trackbot> RRSAgent, please draft minutes
21:05:55 <RRSAgent> I have made the request to generate http://www.w3.org/2012/11/26-crypto-minutes.html trackbot
21:05:56 <trackbot> RRSAgent, bye
21:05:56 <RRSAgent> I see no action items