See also: IRC log
<Wseltzer2> Can't get in
<virginie> none of us can :)
<markw> While we're waiting, I noticed that the link for my wrap/unwrap proposal in the agenda is wrong. It should be: http://www.w3.org/2012/webcrypto/wiki/KeyWrap_Proposal
<markw> If you haven't already, please read it while the bridge gets sorted out ;-)
<hhalpin> Apparently Zakim didn't keep our booking.
<hhalpin> For this slot in 2013 :(
<hhalpin> I'll check n this
<hhalpin> is Virginie on the phone?
<jyates> aadd is jyates
Virginie: Welcome Joan
Joan: from MIT
<hhalpin> agneda -topic
... Item 2: low level API, unwrapping
<hhalpin> PROPOSE: Approve minutes http://www.w3.org/2013/01/07-crypto-minutes.html
Virginie: Mark presents proposal
<hhalpin> RESOLVED: Minutes approved http://www.w3.org/2013/01/07-crypto-minutes.html
Mark: key wrapping and unwrapping, use cases and requirements
... our case has secrets on the clients. need quickly key unwrapping to use
... req. is to support keywrapping/unwrapping, both symm and asym algorithms
... what is the format of the when the key is wrappinged
... defined the format
... properties of key is constructed with the key
... need to define additional json key structure
... need to decide what kind of keys to wrap, restrictions?
Sorry, I did not catch all of it
harry: should we include key wrapping? anyone don't want to include key wrapping?
Mike: in Jose, there is a key wrapping format
there are background noice
scribe: expecting next WG meeting by March
<selfissued> The JOSE wrapping draft will apply JWE encryption to a JWK format key
Ryan: not objection to wrap/unwrap. we still have issues in coding. there is question of time line, stability
<hhalpin> I apologize, I was trying to figure out if there was any actual objections to the feature.
Ryan: if we couple with Jose, there are issues in timeline and feature
<hhalpin> Note that our schedule can be flexibleto some extent.
Mark: there is difference of what we original proposed and Jose. Originally, JSON key format and wrap with AES wrapping.
... there are other key wrapping that is not related to Jose, and there are parts that are independent of the key format.
Harry: we should make a decision
... JOSE should not be a problem here
... Our charter is flexible
<hhalpin> (looking at new JOSE charter now)
Mike: JOSE is listening to W3C and doing things in a timely way
<markw> yes, this is what we proposed
Mike: webcrypto group can choose to use JWK format without using JOSE key wrapping
<rsleevi> I am concerned with the mix and match approach even more than I am with the blocking on the timeline :)
Mike: no one is proposing only JOSE way
Virginie: would like more discussions on the mailing list
Mark: three levels of interactions with JOSE
... main one: key wrapping is applicable to any key format, no interaction with JOSE
... missed level 2
... level 3: api level
Ryan: my concern with mix and match approach - high burden on explain the design.
... better off defer
... in absent of JOSE, there are still questions on key format to be answered. It is not as simple.
... my big concern goes to timing aspect
<hhalpin> So according to JOSE charter, all of this should be done July 2013.
Ryan: if we do go forward, need to mark as feature at risk
<hhalpin> I do agree we should get format questions answered outside of JOSE as well ASAP.
Mark: agree we should spend more time
<hhalpin> +1 more time for technical discussion
Mark: we already have dependency on JWK. we are not introduce more dependence
<hhalpin> just wondering, who plans to implement?
Virginie: let's schedule more discussion
Mike: high level API
... David had a draft, will propose next week
... has discussions on if high level api is restrictions or confinement of low level api
Mike: they are diff. The high level api should be built using low level api
Virginie: how to get more feedbacks?
... low level api, key discovery, use cases
<hhalpin> I can ask for a formal review by WebApps and HTML WG
Virginie: each of you go and see one or two developers, ask them to read and give feedbacks
... have not see feedbacks
<hhalpin> ACTION: hhalpin to ask for a formal review of WebApps and HTML [recorded in http://www.w3.org/2013/01/21-crypto-irc]
<trackbot> Created ACTION-73 - Ask for a formal review of WebApps and HTML [on Harry Halpin - due 2013-01-28].
<mountie> WebAppSec and SysApp groups
<hhalpin> ACTION: hhalpin to contact PING over privacy [recorded in http://www.w3.org/2013/01/21-crypto-irc]
<trackbot> Created ACTION-74 - Contact PING over privacy [on Harry Halpin - due 2013-01-28].
<hhalpin> no problem, can wait a bit
Virginie: next F2F
... April 23,24,25 seem to be good
<hhalpin> I'd like to note there's a WebAppSec meeting/HTML WG/WebApps meeting
<hhalpin> 23-26th of April
<hhalpin> Paypal willhost
Virginie: proposal: Boston, April 24,25, proposed by Richard, not confirmed yet
Harry: if we can move to west coast, there are other meetings there. Paypal can host.
... if Richard, and no one object, will confirm with Paypal
Virginie: we have to define activities of 2013
<hhalpin> I.e.in the next week or two
Virginie: will discuss in next call
<hhalpin> would it be good to move back to weekly calls?
Virginie: timing of the call
<hhalpin> if we need more time for technical discussion?
Virginie: no more asia people join, except mountie. So will go back to US friendly timing
Harry: okay with bi-weekly call. have a single time of the call will have less confusion
<hhalpin> 20:00 UTC is better than current time?
<hhalpin> ah, better than 19:00 UTC?
Mountie: if we keep current time, will get more people. If not, 20 UTC is better
<hhalpin> also, wondering if we should go to weekly calls?
<hhalpin> What do folks think?
<virginie> on weekly calls
<hhalpin> Well,it seems the main use of meetings is to force issues
<arunranga> -1 (not in favor of weekly calls)
<hhalpin> to closure
<hhalpin> 2 not in favor, given both are editors, makes sense.
<hhalpin> to keep biweekly
Virgine: US friendly timing, biweekly
... can make additional calls when needed
<hhalpin> So shall I move the booking of Zakim to 20:00UTC?
<virginie> (ok for 20:00 UTC
<hhalpin> 19:00 UTC
<hhalpin> I am a bit confused as well.
<mountie> +1 for 20:00 UTC, -1 for 19:00 UTC
<hhalpin> Mountie, 19:00 UTC is better for you?
Moutine: 15UTC is best, 20 UTC is better
<hhalpin> So 20 UTC
Virginie: keey 20 UTC
<hhalpin> (let me check current booking time)
<ddahl> hhalpin: hey there. I should mention that if we do west coast Mozilla can host again, np.
<hhalpin> hey ddah
<hhalpin> if you wish to sync up on the high level API tomrorw
<hhalpin> just tell me when