See also: IRC log
<trackbot> Date: 09 July 2012
<self-issued> Microsoft is Mike Jones
<ddahl_> just dialed in
<cjkula> A little frightened!
<cjkula> (Haven't studied)
<asad> I can do that next week. Today I am under the weather a bit.
<hhalpin> scribe: wseltzer
<hhalpin> scribenick: wseltzer
virginie_galindo: Minutes will be circulated for approval next week.
... Welcome IBBT, Philippe De Ryck.
... First, review use cases, then technical discussion.
virginie_galindo: Channy and Jim are not on the call.
... Perhaps we can get a written update.
sdurbha: No update. Working with Jim if he needs help.
virginie_galindo: Anyone to add use case to the wiki?
<hhalpin> http://www.w3.org/2012/webcrypto/WebCryptoAPI/
ddahl_: I have updated the spec with Ryan's low-level proposal
... Adding outlines, issues under discussion and contention.
... It's in cvs, looking for feedback from editors, then mailing list.
... Originally, I proposed high-level API; Ryan proposed low-level
... For now, just want to get all the issues into the document.
... Two actions: ACTION 6, allow for access to private key material, added to the spec.
... ACTION 9: proposal for adding key ID and handling methods in there as well.
... Put everything in one place, add missing items.
hhalpin: To help people understand the issues, we should put alternatives into FPWD
... don't prematurely optimize.
ddahl_: Ryan's proposal was well-received and well-designed.
... Put everything in one place (the draft) to help reviewers.
ddahl_: editing via hg or cvs
<ddahl_> rsleevi: i would also prefer hg:)
rsleevi: we can use mercurial for making rapid changes in response to ongoing discussions
... just sent mail with strawman on identifying algorithms
... haven't yet gotten to add those to the draft
<virginie_galindo> http://www.w3.org/2012/webcrypto/track/
<scribe> scribenick: rsleevi
virginie_galindo: Discussion actions list https://www.w3.org/2012/webcrypto/track/actions
<drogersuk> Will aim for action number 8 to be completed by the next call
rsleevi: Actions 3, 4, 5, and 7 were duplicated. Actions 3-5 have been closed, ACTION-7 will continue the discussion
ddahl_: ACTION-6 has updated the draft with a proposal for optionally keeping keying material inaccessible
drogersuk: ACTION-8 will be updated for next week with sdurbha
ddahl_: ACTION-9 has been incorporated into the draft and is pending review
sdurbha: Discovery has been a hard topic on the mailing list. Should we open an action?
virginie_galindo: Looking for suggestions to take up the action
rsleevi: Should it be an ACTION or an ISSUE?
hhalpin: ISSUES are where there are multiple design options, ACTIONS are where a concrete proposal is needed
virginie_galindo: Perhaps both
rsleevi: May just be an ISSUE?
ddahl_: Key discovery or algorithm discovery?
hhalpin: algorithm discovery
mike_jones: Regarding ACTION-7, proposal for using JOSE names for lookups seems acceptable. However, algorithm discovery may not add value, just add code. That's because even if you have an algorithm, it may not be usable with a key
sdurbha: Possibly two issues: 1) Mandatory/expectability of algorithms 2) What to do when the algorithm is not supported?
... Two different ways of discovering algorithms have been proposed. The 'objectability' (window.crypto.enc.rsa_oaep) or via a method (as proposed in the low-level API)
<sdurbha> OK
Karen_: Question about getKey() - how does the caller get access to a key?
ddahl_: The idea with using a DOMString, the idea was that you could possibly get a key pair. Is it a question of naming the method?
Karen_: The naming seems fine. One question is that it returns a "void", which seems confusing. Another question is how is access to the key managed? Can any application get that key? What if that key is pre-provisioned?
ddahl_: The return of "void" was so that the actual keying material is returned during the oncomplete event
... The current proposal does not address the ACLs or how the raw key may be accessed.
... Pre-provisioned keys will require more thinking through. How exactly access controls will be managed - such as an explicit list of domains - as well as how to handle things such as expiration.
Karen_: Raising it as a discussion point for now. Currently no proposal to address this
There was also the KeyQueryList proposal as a way to identify and discover keys
ISSUE: How to address pre-provisioned keys and managing ACLs
<trackbot> Created ISSUE-2 - How to address pre-provisioned keys and managing ACLs ; please complete additional details at http://www.w3.org/2012/webcrypto/track/issues/2/edit .
<ddahl_> rsleevi: yes, indeed. I forgot to go back over that in my latest editing
virginie_gemalto: Are there any other proposals for addressing discovery?
<ddahl_> rsleevi: perhaps I should add the KeyQueryList as an additional sub-proposal for key discovery?
hhalpin: The key for the API making it through the W3C process will need to be interoperability and testability. If browsers and implementors are suggesting it's too much to implement, then that will ultimately come out in the test cases
ISSUE: Decide whether algorithm discovery is necessary
<trackbot> Created ISSUE-3 - Decide whether algorithm discovery is necessary ; please complete additional details at http://www.w3.org/2012/webcrypto/track/issues/3/edit .
Karen_: Right now we're proposing a high-level and low-level API. They both have their own duties. Do we want to combine them, or will they be kept at two levels?
ddahl_: There have been ongoing discussions about this. We've had more people introduced in a low-level API, but there were still a number of people interested in a high-level API. It's possible that a high-level may be implementable in terms of a low-level in content JS, but for now and the sake of discussion, it may be good to keep them both in the draft
virginie_gemalto: Even if we keep the high-level API, we should focus on solving the issues of the low-level API first, but it does not prevent discussion of the high-level API
hhalpin: At this time, for the sake of public discussion, it would be good to keep both
virginie_gemalto: Thanks to David and Mozilla for offering to host.
... It will look to be two full days, starting around 9:30 - 10 and running until 5
... If people want to speak about particular technical items, bring them up on the mailing list so we can have as much input as possible
ddahl_: There will also be a teleconference line for remote participants
virginie_gemalto: harry or wendy to setup the details. Will work with David to setup the details
... Any other items?
... Thanks to everyone for participating. Next call will likely take another look at the ACTIONs and begin to come up with the agenda for face to face
<self-issued> Mike Jones has to sign out
ddahl_: finalize the details for mercurial vs cvs