Re: Uses cases around secure conferncing

One of the many faults of the "dearly departed" Secure Communications use case was that it mixed somewhat different scenarios (such as both mesh and centralized conferencing) in the same use case. I am assuming that in this PR the intent is to focus on centralized conferencing, with mesh being out of scope, correct?

So as to enable easier discussion and analysis, I would suggest separating out Secure Communications into sub use-cases, so we can  distinguish requirements arising from the "JS has access to keys" use case from the requirements of the "browser-only access to keys" use case.  I would also suggest that the use cases be clarified with respect to their transport requirements (e.g. is the desire to support multiple transports, or just RTP).

One question that has come up for both sub-cases is whether they are really new use cases, or just improvements upon existing use cases.

For example, the "JS has access to keys" sub-case could potentially be implemented today using canvas and/or WebAudio to obtain access to media, WebCrypto, and a suitable transport, such as WebSockets. That begs the question of what new requirements are arising from it.

Similarly, the question has arisen as to whether the "browser only access to keys" is satisfied (or even subsumed) by EME/MSE, which can potentially support multiple key management mechanisms and can use hardware as the "root of trust" so that even the browser cannot have access to keys.