- From: Harry Halpin <hhalpin@w3.org>
- Date: Thu, 08 Jan 2015 15:19:23 +0100
- To: Ryan Sleevi <sleevi@google.com>, GALINDO Virginie <Virginie.Galindo@gemalto.com>
- CC: Justin Uberti <juberti@google.com>, public-webrtc@w3.org, "public-webcrypto@w3.org" <public-webcrypto@w3.org>, Martin Thomson <martin.thomson@gmail.com>, Richard Barnes <rlb@ipv.sx>, Eric Rescorla <ekr@rtfm.com>
On 01/07/2015 07:14 PM, Ryan Sleevi wrote: > I actually oppose such a call. > > I think too much of the discussion has happened on calls and conversations > that lack sufficient record to provide guidance on the goals and > requirements. The main purpose of calls and face-to-face is to move past issues that people are unable to do via email, as some email conversations can go on forever and a teleconference can act as a forcing function. That being said, having the WebRTC WG formulate their goals and requirements via email is of course preferable - and your take on the requirements are a good start. I'm happy to delay (a month?) any telecon, but the option is open if people want it. cheers, harry > > The original message I set forth tried to document the requirements as I > had collectively had them presented over nearly half a dozen conversations > with various participants. While I can understand the benefit of a > high-bandwidth conversation, I would hope that taking a step back and > looking at what is trying to be accomplished - divorced of any particular > embodiment - would be more fruitful. > On Jan 7, 2015 3:01 AM, "GALINDO Virginie" <Virginie.Galindo@gemalto.com> > wrote: > >> Hi all, >> >> I am supporting the idea to set up a call between webRTC and Web Crypto >> folks as suggested by Harry. >> I think that to move forward the discussion, it would be helpful to >> understand what are the special requirements that Web RTC keys do require >> (a pointer to previous discussions would help me at least). >> >> We could also envisage to address special requirements in the next Web >> Crypto WG deliverables, as Web Crypto WG is in the process of rechartering. >> >> Regards, >> Virginie Galindo >> Chair of Web Crypto WG >> >> -----Original Message----- >> From: Harry Halpin [mailto:hhalpin@w3.org] >> Sent: mardi 6 janvier 2015 10:31 >> To: Ryan Sleevi; Justin Uberti >> Cc: Eric Rescorla; Martin Thomson; public-webcrypto@w3.org; >> public-webrtc@w3.org; Richard Barnes >> Subject: Re: WebRTC Certificate Management - a plea to NOT use Web Crypto >> >> >> >> On 01/06/2015 02:24 AM, Ryan Sleevi wrote: >>> On Mon, Jan 5, 2015 at 4:42 PM, Justin Uberti <juberti@google.com> >> wrote: >>>> We did talk about it, and my takeaway at the time was that the best >>>> path forward would be for WebRTC to define its own key-generate >>>> function, and return an object that was API-compatible with WebCrypto >>>> (so that we didn't have two different objects in the web platform to >>>> represent 'key'). As Eric says, this became the basis of the current >>>> proposal, so you can blame me for any misinterpretation. >>> >>> Without trying to set out blame (since this was a conversation held >>> with multiple people), I think the important thing to focus on here is >>> "so that we didn't have two different objects in the web platform to >>> represent 'key'" >>> >>> My original message, and my point of view, is to challenge >>> 1) the idea that what WebRTC is dealing with is logically a 'key' >>> 2) the idea that it's a bad thing to have two different objects for >>> these two different APIs >>> >>> Put differently (to avoid both double negatives and ambiguity) >>> - I do not think that WebRTC is dealing with anything that logically >>> makes sense to be dealt with at a 'key' level binding >>> - More importantly, that users and developers are better served by >>> treating these two different APIs as different objects with different >>> use cases >>> >>> I'm not sure how best to move this conversation forward. I see there >>> being at least two areas of disagreement on this thread: >>> - Cullen's assertion that WebRTC serves as a form of a crypto API, and >>> thus we should strive for alignment >>> - Richard's assertion that Web Crypto designed CryptoKey to be the >>> basis for key objects >>> >> >> Although the larger question (should WebRTC use WebCrypto) is clearly a >> WebRTC question, if people in both WebCrypto and WebRTC want to set up a >> joint teleconference to sort this out, I'm happy to set it up at a time >> convenient for both parties. >> >> In general, it should be expected that other standards in the future build >> on WebCrypto. That being said, with W3C hat off, I think Ryan's objections >> in this case make sense but again, we don't want two kinds of 'keys.' >> >> cheers, >> harry >>> The former is a question for WebRTC WG, the latter is a question for >>> the Web Crypto WG. >>> >>> While these could benefit from more discussion, I think the most >>> important thing to do would be to keep in mind the priority of >>> constituencies [1], and in particular, asking how the different >>> proposed solutions work with developers' expectations. I think a >>> solution that uses CryptoKey for WebRTC is going to fly in the face of >>> a lot of expectations, and the only way in which it seems to align is >>> in theoretical purity (since it provides no practical value to >>> developers and nominal value for _some_ implementors) >>> >>> [1] >>> http://www.w3.org/TR/html-design-principles/#priority-of-constituencie >>> s >>> >> >> ________________________________ >> This message and any attachments are intended solely for the addressees >> and may contain confidential information. Any unauthorized use or >> disclosure, either whole or partial, is prohibited. >> E-mails are susceptible to alteration. Our company shall not be liable for >> the message if altered, changed or falsified. If you are not the intended >> recipient of this message, please delete it and notify the sender. >> Although all reasonable efforts have been made to keep this transmission >> free from viruses, the sender will not be liable for damages caused by a >> transmitted virus. >> >
Received on Thursday, 8 January 2015 14:19:58 UTC