- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Mon, 17 Sep 2012 10:59:38 -0700
- To: public-webrtc@w3.org
I hope that this (and the followup discussion) helps clarify things a little. * Control connection establishment based on certificate This item actually covers a range of topics related to identity. To some extent, this crosses over into IETF territory, but the first part of this item is especially relevant to the API. (I'll also concede that it presupposes something about the solution.) It is desirable for applications to be able to control (permit or deny) communication with peers based on their identity. An application might have its own idea about what identity a particular session participant is providing. Identity assertions alone are not sufficient to determine whether to allow access to the session. In some applications, access to media might need to be controlled based on identity. If an identity assertion is found to be invalid, can the session continue? Is it a case of identity or bust, or are we just using identity to provide source attribution? The former choice simplifies things greatly, but it may be a little restrictive. The latter option implies that we need to give the application control to allow it to perform session-level access control. The current work on identity does not permit the presentation of a domain certificate for the termination of a media stream. This is a case that I raised a couple of times in discussions in the IETF, with what I perceived to be a favourable response. This enables basic contact centre applications without the need for additional infrastructure. Being able to talk to "example.com" also has specific meaning over simply talking to "service@example.com", which - depending on example.com name registration policies - could just be some dude with an account. * Related identity issues In the same area, it's also unclear how an application learns of the set of available identity providers that are able to assert a user's identity. And how does an identity provider "install" itself? I always imagined an OAuth-like arrangement for the acquisition of identity assertions, but it seems that Eric has a more direct model in mind. That probably needs resolution. * Split SDP between PeerConnection and MediaStream I suspect that this one was mistranslated somewhere. This speaks to the architectural issue. RtcPeerConnection embeds a number of things, each with non-unity cardinality. Part of the API proposal was to provide a separation of the discrete parts. The immediate impact of this would be to improve reporting, but it would also facilitate re-use. That would allow for a better separation of things like the data channel. * Serialization of duplicated tracks I think that Cullen already dealt with this one. I don't recall where the decision was documented, but apparently, one was made. It's a non-issue, and certainly not an API one. * Programmatic description of described streams When you receive SDP from someone, what can you learn of the effects of that SDP prior to actually using it? As the API stands, nothing. Unless you know a little about SDP. Even then, it's probably nothing unless you know a LOT about SDP. This is unacceptable from an application perspective. A few options have been discussed. My understanding of the imagined SDP usage is not sufficiently clear to come to a conclusion on this question. --Martin
Received on Monday, 17 September 2012 18:00:06 UTC