<trackbot> Date: 03 June 2013

<wseltzer> scribenick: ddahl

welcome

web crypto API (futures, wrap/unwrap...)

<rsleevi> https://dvcs.w3.org/hg/webcrypto-api/rev/9a993888347c -> KeyOperation

virginie: requests went out to people on the status of features
... how do they integrate into the spec
... all needs a review by the TAG
... seems to be a consensus on promises or futures
... (as the way forward)
... some folks think it might be risky to go in that direction

israelh: is there a spec for futures to point to

<arunranga> israelh, TC-39 will also take this on as language specific work.

<hhalpin> The TAG is not doing the spec, and Futures will keep "promises" name.

<hhalpin> TC-39 is looking at promises to my understanding

rsleevi: tc39 is taking on js spec work
... all of this is being integrated into the w3c dom spec

<arunranga> Between DOM Futures and TC-39, that'll be the "Futures spec" stuff.

israelh: was unaware that anna was an editor of the dom spec any longer

virginie: are you thinking this will be not well integrated?

israelh: MS does not like to implement non-W3C specs
... want to be sure there is someome as point person around future

s

hhalpin: scheduling will work this out, we want to make sure technical problems are figured out by the time we get to lacst call, not sure about anna's work right now

<hhalpin> in other words, this will be sorted soon in TC39, keepthe TAG and TC39 in the loop with any technical problems.

arunranga: anna is now a mozilla emplyee
... is editing DOM futures in WHATWG
... MS's feedback is important to all of us, etc, what we can do about this being in WhatWG
... Anne does not go to tc39 meetings, but your feedback about this not happening in W3C is important to us

MichaelH: is there an update on cancellation of operations?

rsleevi: no way to wait for cancellantion ,still have abort()

arunranga: thanks

virginie: confident in promises being the right tech. and integrated into W3C
... there may be a weird overlap between Promises spec and our own
... what you recommend about this?

rsleevi: there are already other apis moving over and being updated
... the current spec points to the DOM spec on whatwg
... we should continue this even as this is being worked on in whatwg, and w3c

israelh: MS is not part of the whatwg
... we should in parallel iron out this issue

hhalpin: we should make a quick note that Promises has home outside of the whatwg

<arunranga> happy to take an action or whatever; as discussed if israelh sends me email, I'm happy to follow up.

virginie: next item to discuss the recent changes in the spec

rsleevi: I have pushed the Futures-enhanced version in 2 phases

the normative part becomes simpler

rsleevi: we have a few diff, ways a key op can fail, how do we represent this and communicate this back to callers?
... do we use DOMError or a more specific error?
... if a keygen fails because of whatever reason, how do we signal the specific error conditions?
... not a blocker for a publication of a heartbeat
... will echo this on the mailing list
... 2nd issue is the cryptooperation's process and finish, have some examples that will be pushed soon.
... looking for feedback on this

israelh: what else would we use byt DOMError?

rsleevi: there is a case were we reject with (a property) set to null
... should we formalize specific errors and codes?

israelh: do we specify errors based on alg or ?

rsleevi: not sure about all of the errors that are anticipated
... there are a variety of errors here to deal with - do we enumerate all of them in the spec?

virginie: how are we going to track any of this?

rsleevi: not sure if this is an action yet, going to post to the mailing list,
... don't think this will block a draft being published

<MichaelH> http://www.w3.org/TR/dom/#interface-domerror

rsleevi: this seems to be underspecified right now

virginie: anything else to track here?

rsleevi: the issue of whatwg publishing the futures spec shouldn't block. if this is a serious issue for MS we should figure that out now

israelh: willwe figure this out by last call?

rsleevi: yes we have to
... this needs to be available in the heartbeat draft, must be resolbved b4 last call

israelh: what time frame do see a resolution?

rsleevi: next publication is 2 weeks till review and maybe by the next call
... otherwise we proceed with this unaddressed
... hoping this is resolved in the next few weeks

<hhalpin> We need June :)

israelh: july or august
... ??

rsleevi: no, june, very soon

israelh: we all agree that a new heartbeat should happen soon

rsleevi: we should see more frequent editor updates
... tricky bits are key import wrap unwrap and futures
... hoping for a july / early aug heartbeat as well

<hhalpin> Everything is spec-specific

MichaelH: clarification: do these errors as specified go to our spec only or DOM-wide?

rsleevi: these are types of errors that are DOMErrors
... string desire to not introduce spec-specific erros

MichaelH: do we have to possibility of introducing new DOMerrors?

rsleevi: yes, but is very much discouraged

israelh: there are some interesting examples like indexedDB where we can draw error codes from

rsleevi: lets start figuring out what errors we need and see if we actually need to introduce new erros

virginie: vijay can you make a status about key lifecycle? has it been integrated in any spec?

vgb: have not noticed if the key agreement parts were updated
... planning to update things today

virginie: should we wait till the next heartbeat?

vgb: should ask rsleevi

rsleevi: will review this and figure out what this can be incorporated into

virginie: of we can integrate this easily, ok, otherwise delay it
... discussion related to wrap unwrap is not so appropriate without netflix
... ok for next heartbeat in August
... worried we will not get much feedback in August

<hhalpin> we need the heartbeat in June IMHO

virginie: we will have to have a June heartbeat
... net one in august but need participation
... any objections to a heartbeat in JUNE?

<nvdbleek> +1

<virginie> +1

virginie: and august

<hhalpin> +1

<MichaelH> +1

+1

<mountie> +1

<rsleevi> +1

<sangrae> +1

virginie: next status about use cases
... arun can you note thie changes?

arunranga: I have been updating the use cases draft
... the format has changed
... using respec.js
... mainly a text migration
... the controversial threat module around localstorage attack being changed to keeping a distribution or cdn code safe by checking it against a hash
... also working on fileAPI
... the smaller changes have landed not big changes

<mountie> please send link of recent work

virginie: can we push a heartbeat at the same time for use cases?

arunranga: i think so, ryan what is the date we are targeting?

rsleevi: can we vote on this next call?

<virginie> usecases spec https://dvcs.w3.org/hg/webcrypto-usecases/raw-file/tip/Overview.html

rsleevi: to clarify: the WG should be reviwing this stuff now for the next heartbeat
... 2 weeks from now we publish the latest and greatest

arunranga: yes, if th edraft is ready for the next call, then yes we can push it, otherwise wait

virginie: do you have 2ndary use cases in another document or wiki?

arunranga: just in the wiki

<hhalpin> Thus, we are aiming after AC

karen: arunranga what about the cross-origin use case?

arunranga: yes, this is covered in the "BrowserID" use case

high level api

virginie: next on agenda: high-level work, assume this work is not progressing
... ddahl do you have any view on this?

<hhalpin> mike jones and richard barnes are missing

<hhalpin> and they expressed interest.

<wseltzer> ddahl: Some of my upcoming work will be with high-level shims on top of polycrypt

<hhalpin> next monday :)

<hhalpin> ?

virginie: will call for another phone call on highlevel apis

<hhalpin> June 24th?

wseltzer: note that I have been talking to rbarnes about high level work with polycrypt
... perhaps we can use this to get more feedback from the crypto community

virginie: F2F discussion: mainly negative feeback mainly
... we will be cancelling that meeting

<hhalpin> in good news mountie, it appears WWW2014 will be in April in Korea.

<hhalpin> So perhaps that would make sense as a time to have a Korea meeting.

virginie: participation in IETF JOSE discussions is encouraged
... any other business?

rsleevi: 2 notes: hoping for more review of rbarnes random source proposal
... 2: around implementation: chromium team has indicated that they are committed to implement

<wseltzer> trackbot, end teleconference

This is scribe.perl Revision: 1.138  of Date: 2013-04-25 13:59:11  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/israeli/israelh/
Succeeded: s/tinking/thinking/
Succeeded: s/Anna/Anne/
Found ScribeNick: ddahl
Inferring Scribes: ddahl
Default Present: jyates, Michael, [Microsoft], Virginie, ddahl, mountie, nvdbleek, Karen, arunranga, Google, Wendy, vgb, hhalpin
Present: jyates Michael [Microsoft] Virginie ddahl mountie nvdbleek Karen arunranga Google Wendy vgb hhalpin
Found Date: 03 Jun 2013
Guessing minutes URL: http://www.w3.org/2013/06/03-crypto-minutes.html
People with action items: