- From: Harry Halpin <hhalpin@w3.org>
- Date: Tue, 06 Jan 2015 10:30:30 +0100
- To: Ryan Sleevi <sleevi@google.com>, Justin Uberti <juberti@google.com>
- CC: Eric Rescorla <ekr@rtfm.com>, Martin Thomson <martin.thomson@gmail.com>, "public-webcrypto@w3.org" <public-webcrypto@w3.org>, "public-webrtc@w3.org" <public-webrtc@w3.org>, Richard Barnes <rlb@ipv.sx>
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-constituencies >
Received on Tuesday, 6 January 2015 09:30:40 UTC