See also: IRC log
<trackbot> Date: 17 September 2012
<selfissued> Mike Jones joined before you did
<rsleevi> Hrm, Zakim does not have us listed. I suspect we may have been the P7
<virginie> Hi all, we will wait few more 1 minutes and than start
<wseltzer> scribenick: mitchz
<hhalpin> chair: virginie
<hhalpin> scribe: Mitch
<hhalpin> PROPOSAL: Approve http://www.w3.org/2012/09/10-crypto-minutes.html as the official meeting minutes
<virginie> Hi all, we will wait few more 1 minutes and than start
<hhalpin> RESOLVED: Approved http://www.w3.org/2012/09/10-crypto-minutes.html as the official meeting minutes
<wseltzer> trackbot, close ACTION-45
<trackbot> ACTION-45 And wseltzer to move the Editors Draft to TR space and communicate to the email@example.com, the Director, and Comms Team over the FPWD publication closed
<wtc> Do actions also need to be closed with a vote in general?
<virginie> - http://www.w3.org/2012/webcrypto/track/actions/open
wseltzer: patent stuff taking a
... hoping to bring to group soon
<wseltzer> trackbot, close ACTION-14
<trackbot> ACTION-14 Change naming scheme to use a "createX" approach rather than just "X" closed
rsleevi: actions ... 43, 14, should be closed
<wseltzer> trackbot, close ACTION-33
<trackbot> ACTION-33 text proposal for key pair handling closed
rsleevi: 42 should also be closed
<wseltzer> trackbot, close ACTION-42
<trackbot> ACTION-42 Normative description of the algorithm for key generation, derivation, importing, and exporting closed
<wseltzer> trackbot, close ACTION-41
<trackbot> ACTION-41 Propose text for key neutering closed
<hhalpin> agree, we should only give the editors actions when there's clear WG consensus on putting the text in.
<hhalpin> otherwise its still an open issue.
virginie: we should start taking
action to fulfill needs of issues
... we still have pending review actions
<trackbot> ACTION-16 -- Ryan Sleevi to add the key query mechanism to editors draft, checking in with ddahl's edit -- due 2012-08-20 -- PENDINGREVIEW
virginie: should be closed
<wseltzer> trackbot, close ACTION-16
<trackbot> ACTION-16 Add the key query mechanism to editors draft, checking in with ddahl's edit closed
rsleevi: can close ACTION-16
virginie: we can switch to the issues
virginie: we need to make some noise about the FPWD
virginie: started to list the
actions to make noise
... need to gather comments & deliver something usable
selfissued: will send the FPWD to the IETF group
virginie: Oxford U. is
... b/c they're working a lot on security
<wseltzer> [FPWD link: http://www.w3.org/TR/WebCryptoAPI/ ]
virginie: gathering together
Gemalto, G&D and others
... want to see if it maps with secure elements
<hhalpin> I have already emailed IETF Web Security (Web Sec) Group, IETF SAAG (Security Area), Ron Rivest, and NIST (John Kelsey).
virginie: and Sony which is working on JS draft API which may use some of WebCrypto
<zooko> Who proposed whgat?
virginie: pinging people from
Twitter & elsewhere
... and Financial Times
... also sent to webappsec working group
... need to ask the group to do more
... if you have any way to communicate out or take the message to conferences, that would be "really great"
<ddahl> virginie: ddahl just blogged this http://monocleglobe.wordpress.com/2012/09/17/w3c-web-crypto-api-first-public-working-draft-published/
hhalpin: there was a debate
around "Is JS security possible"
... in the blogosphere last year
<ddahl> my blog is also in the planet mozilla feed
Harry dropped off the line
<hhalpin> yes I've noticed
<hhalpin> have JimD and asad go first :)
<hhalpin> I'll be back in a sec
JimD: going to publicize to US govt related agencies
<ddahl> virginie: that was just an announcement - i plan on blogging more about the API soon
<zooko> The same debate was still ongoing this year, centered especially around Nadim Kobeissi's cryptocat app
virginie: can do something for France
asad: chip security in Nice
... can also bring to app security conference in Austin in Oct.
... "chip to cloud" conference in Nice
hhalpin: the JS security debate has died
would be useful to get folks who looked at original proposal to look at WebCrypto
hhalpin: people from Wired were
... the more eyes the better
... Harry needs some quotes from people
... please email Harry directly
<ddahl> hhalpin: I am sure quinnorton will be happy to tweet a link to your post
hhalpin: is the list interested
in talking to others about WebCrypto
... worth mentioning that the APIs will be used
... not just theoretical
Harry: let's talk offline
we're clearly going to do WebCrypto
<hhalpin> not a theoretical product, but something that will actually be used.
<zooko> If the JS security debate has died, then it has ended with the majority of security experts concluding that the "JS crypto is useless" side was right.
<hhalpin> Just email firstname.lastname@example.org
selfissued: how should we publicize this to ??
<asad> AppSecUSA link is http://www.appsecusa.org/
<Zakim> rsleevi, you wanted to respond to selfissued
rsleevi: the public webcrypto comments list would work to help publicize
<hhalpin> zooko, that's why I thought this API+CSP that mean it was time to reignite the debate :)
rsleevi: jose would be interesting to have review esp. the algorithms
zooko: the CFRG is the
Cryptographer Consultants, part of IETF
... they will review WebCrypto for us
... zooko will send WebCrypto for review
<hhalpin> It would also be useful to get some broader review from JS app developers as well, arun?
<asad> Chip to Cloud link is http://www.chip-to-cloud.com/
<wseltzer> [Wiki with contacts; http://www.w3.org/2012/webcrypto/wiki/Gathering_public_comment_for_FPWD]
<zooko> hhalpin: I agree. I hope the debate will be reignited.
<wtc> David McGrew is a member of the CFRG and is already on our mailing list.
<zooko> FWIW, I think a lot more invention needs to be completed before the current expert consensus will no longer be correct... But that's probably out of scope for this meeting...
<zooko> wtc: Yes.
virginie: this is a
... we can have debate about this
... perhaps Ryan can describe the classifications
rsleevi: trying to break into
... crypto are things that require understanding of crypto
... if you don't care about crypto, you can ignore
... functional is core to the api
... it's about the functionality of the API
... and is closely related to usability
rsleevi: usability about JS
... single threaded issues
... rendering and scrolling & how it affects these
... access control fits into keys and key management and determining how they're accessed
... key tainting, multi-origin, etc.
... design category is about broad questions about API
... high level vs. low level
... "next" is about the next set of issues that may actually be primary features, but depend on the other issues
markw: "key" vs. "functional" is
... and then I have comments on prioritization
virginie: key domain was my proposal
trying to isolate problematic issues of pre-provisioning
markw: "key" fits functional
virginie: any reason to merge / not merge?
rsleevi: the split has some
... trying to separate distinction btw. functional for "web platform" vs. ...
... not related to keys themselves
... conversation about indexDB, web storage, etc.
... about functionality of overall web platform
... but we can merge if we need to
virginie: the "key" domain is
something we can work on in parallel
... if that's agreeable
... it's not to isolate and forget
markw: it's not clear enough that
it's useful for organizing our work
... we can work on issues whatever category they're in
asad: why a separate
... after hearing this, it makes sense to separate
... we would be able to more easily focus on the segregated issues
vijay: utility of dividing into
domains is to focus attention
... dividing the issues is good
... for "keys" perhaps have a "key storage" category
... for origin, access, etc.
perhaps this conflicts with "access control"?
virginie: this would bring in
some of "access control" into "key storage"
... we can do that
... is that ok for you, Mark?
markw: could make sense
... there are related things in functional section, also
<zooko> To me, access control and key management are so interrelated that they are almost the same thing.
markw: not clear that this helps split things up.
<rsleevi> The solution: tag clouds ;)
virginie: other way is to keep
... we need to think a bit more on this
... let's check back in one week
... ranking was to increase priority of items that are dependencies
markw: how do priorities relate to next deliverables?
virginie: goal was to resolve all the issues for next draft
markw: if we will deal with all issues, then this seems fine
hhalpin: 3 months is standard for next draft
wseltzer: prioritizing certain things above others is for handling dependencies, not because other issues are unimportant
hhalpin: we should publish once
every three months
... so long as we are targeting the primary features
... people will hopefully implement
... for secondary features, we should avoid them until we get through all the issues in primary use cases
... these questions are tricky, so let's get them sorted with consensus by next working draft if possible
<wseltzer> [W3C Process steps: http://www.w3.org/2005/10/Process-20051014/process.html#rec-advance ]
virginie: targeting everything
except things marked as in domain "next"
... for next public working draft
rsleevi: don't know how much can
be done in 3 months
... as we start getting comments from community, there will be more work
... no support for smart cards or pre-provisioned keys
... want to be able to polyfill impl in JS
... these are high priority to get something useful
... after that we can address pre-provisioned keys, etc.
... important to get developers to vet this
... doesn't mean things like device specific or pre-provisioned keys are not important
... but want to get implementers started
markw: understand why we want to
get something implemented in JS
... not sure why this precludes pre-provisioned keys
... we're planning to implement this
... and be user of the API
... if you include us in that then pre-provisioned keys are a necessary part
<sdurbha> +1 for pre-provisioned keys
markw: it can be done & there are people who want it immediately
virginie: we need to be careful
excluding these use cases for a number of organizations
... b/c they may find the API N/A for them without including pre-provisioned keys in scope
... we need some volunteers to draft proposals to editors & to mailing list
... we won't discuss the actual issues right now
... people should check to see if the priorities are reasonable as proposed
... please volunteer
... so we have actual actions
rsleevi: we can't do polyfill for pre-provisioned keys
markw: everything has different properties when implemented in polyfill
Agreed: we should consider the non-browser use case as in scope "\n"
<trackbot> ISSUE-6 -- Concern around KeyQueryList being synchronous -- raised
if there is large latency we would be concerned about this being synchronous
would prefer an async call
rsleevi: agree about latency
... this is not a latency concern
... this is an action about an API that is not specified
<ddahl> rsleevi: trying to implement an object that decends from eventtarget will be less than optimal to not really that doable in a polyfill
rsleevi: we need to create a new issue that is async
virginie: agreed that new issue should point out async
works for us
<ddahl> i guess it can be faked a bit with a web worker
<rsleevi> ddahl: Yes, that's something I was looking at related to our callback/event handling.
<wseltzer> ISSUE: how should we define key discovery, noting asynchronicity
<trackbot> Created ISSUE-40 - How should we define key discovery, noting asynchronicity ; please complete additional details at http://www.w3.org/2012/webcrypto/track/issues/40/edit .
virginie: will open a new issue & close the old
<wseltzer> trackbot, close ISSUE-6
<trackbot> ISSUE-6 Concern around KeyQueryList being synchronous closed
I wish I could attend TPAC :(
<zooko> I wish.
<asad> not sure
<wseltzer> [TPAC attendance]
(vote was on who is attending TPAC)
<selfissued> Can someone post a link to the TPAC registration information?
<wseltzer> [Register: http://www.w3.org/2012/10/TPAC/#Registration ]
virginie: please register
... one set fee per day
<ddahl> rsleevi: this might help with updating DOMCrypt to be like the new API: https://bugzilla.mozilla.org/show_bug.cgi?id=731746
virginie: technical session on
... on general strategy of w3c
... it's very interesting
... lot of events, beers, etc.
wseltzer: if you haven't been to
TPAC, the Wednesday meeting is an "unconference" event
... you can choose sessions to attend
... if someone wants to propose something about WebCrypto, that would be a place to propose that
virginie: pool of exchanges, very lively and interactive
<zooko> Thank you mitchz.
next conf call in one week on monday
<wseltzer> trackbot, end teleconf
This is scribe.perl Revision: 1.136 of Date: 2011/05/12 12:01:43 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/paten/patent/ Succeeded: s/??/webappsec/ Succeeded: s/??/JimD/ Succeeded: s/if possible/"\n"/ Succeeded: s/note sure/not sure/ Found ScribeNick: mitchz Found Scribe: Mitch WARNING: No "Present: ... " found! Possibly Present: Google Harry IPcaller ISSUE JimD Microsoft P11 P17 P7 PROPOSAL aaaa aabb arunranga asad cjkula ddahl emily hhalpin https is markw mitchz netflix perhaps rsleevi scribenick sdurbha selfissued trackbot vgb vijay virginie wseltzer wtc zooko You can indicate people for the Present list like this: <dbooth> Present: dbooth jonathan mary <dbooth> Present+ amy Agenda: http://lists.w3.org/Archives/Public/public-webcrypto/2012Sep/0148.html Found Date: 17 Sep 2012 Guessing minutes URL: http://www.w3.org/2012/09/17-crypto-minutes.html People with action items:[End of scribe.perl diagnostic output]