Re: [rtcweb] More on authorization and endpoint authentication

[Igor Faynberg <[e-mail]>]

There are many interesting points here (as there are elsewhere on this 
thread).

Just to pick one, I wonder if it is an appropriate time to start zeroing 
in on acceptable identities as well as on the way of mapping them to a 
specific "person" (including bots).
There are two aspects to it. One is authentcation (i.e., a sort of a 
transitive closure reliance: if I know that A and B are different 
identities of P, and I have authenticated P based on A, I may , in 
certain circumstances, trust what comes from B), and the other is 
actually the choice of identifier.

Of course, I realize that this question sort of strays off the thread...

On the identifer choice, in direct response to Ted's last point, I would 
think that using SIP identities has much merit in several deployments. 
One is mobile telecom, where incidentally an end-point device is always 
sufficiently authenticated, with a  straight-forward extension to the 
person's authentication as the next step.

(By the way, when I read the quoted paragraph from Eric, I did assume 
that he meant "identity." )


Igor

On 8/5/2011 1:38 PM, Ted Hardie wrote:
> 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
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb