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