Re: [rtcweb] Signalling, SDP, and the way we think about interconnecting RTCWEB applications

[Randell Jesup <[e-mail]>]

On 10/17/2011 2:14 AM, Wolfgang wrote:
> On Mon, Oct 17, 2011 at 5:34 AM, Randell Jesup<[e-mail]>  wrote:
>>> In my model the server would know what type of call was set up as it
>>> always controls both ends of the call. If some other application
>>> controls the calling party, you need some standardized protocol like
>>> SDP.
>>
>> So the server negotiates the parameters?  I'm not sure what "my model" means
>> here (and I reviewed earlier messages from you here).

> I didn't have company email access during the weekend and I'm the author of
> https://datatracker.ietf.org/doc/draft-beck-rtcweb-alt-ic/. The idea
> is to always use
> only one RTCWEB server and authenticate/authorize unknown users by 3rd party
> authentication. Like commenting on a blog using OpenID.

Ok, I looked at draft-beck-rtcweb-alt-ic.

One huge problem with it: it's based on an assumption that for most 
cases of federation and cross-service calls won't hold: that clients 
will use the same client JS app, and the services are just providing 
different realms/methods of authentication and user-lookup.

Also, your draft doesn't explain how A & B came to be talking to the 
same server in the first place.  The draft seems mostly focused on how a 
single provider can use a shared authentication scheme (and I would 
suggest that we try to find a provider-agnostic way to leverage id 
systems such as BrowserID and/or OpenID to provide end-user identification).

You should talk to ekr who's writing the security draft and see if you 
can merge some of these ideas into it.

I don't think it in any way helps our signalling/SDP/etc discussion, my 
apologies.


-- 
Randell Jesup
[e-mail]