- From: Ryan Sleevi <sleevi@google.com>
- Date: Mon, 5 Jan 2015 17:24:49 -0800
- To: 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 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 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 01:25:16 UTC