Re: [rtcweb] More on authorization and endpoint authentication

[Ted Hardie <[e-mail]>]

On Fri, Aug 5, 2011 at 6:41 AM, Eric Rescorla <[e-mail]> wrote:
> However, the point I was trying to make is that this is distinct from letting
> the Web server that provided the page route the messages itself. You
> might imagine not trusting the page but nevertheless be willing to allow
> it to provide you with an address which you can independently verify
> and derference.
>
> Best,
> -Ekr


Do you really mean "an address" which you can independently verify and
dereference, or an identity you can verify?

Let's take the poker site example.  The web site owner wants to embed
video streams in the poker application, so that the players are
reasonably assured that they are not playing a bot (or, at least, that
the player using a bot must be physically present during the game).
The poker players are likely put into groups based on arrival time,
maximum bid, etc.  in one mode; in another mode, a group of friends
may come and play together.  In the first mode, the players likely do
not want to share any identifying information with each other.  In the
second mode, the first player might invite the other players to a
room, by sharing a URI provided by the web server, or he might pass
their identities to the web server, so it can limit access to those
signing in with those identities.

In neither case, do we really want the web server to pass the video.
It serves as the initial signaling path for the messages among
players, but that's really it for the audio/video streaming part.

I've been assuming that the website would provide an identity in this
case, if one were needed (e.g. [e-mail]) but that
the primary reason for that identity would be outside the connectivity
model (so you know if you're playing the same player again, for
example, and can react if the picture looks different, or you don't
want to play with someone who is better than you).  Anyone in model
one (using a URI to join a specific game) would be assigned an
identity.  Anyone in model two (where the website locks down the game
to specific players) has to know what the player identities are to
invite.

In neither case does this seem to me to map well to SIP identity, and
I'm concerned that if we start with SIP identity as a mental model,
we're going to have softphones in browsers that can't do any of the
more web-based things that we actually want to enable.

regards,

Ted