Needs to be more clearly described

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