Re: [rtcweb] Use case change request: Identity in multiuser calls

[Harald Alvestrand <[e-mail]>]

On 08/11/11 13:33, Stefan Håkansson LK wrote:
> Harald Alvestrand wrote:
>> In draft-ietf-rtcweb-use-cases-and-requirements, I would like to extend
>> one part of the scenario "4.3.3 Video conferencing system with central
>> server".
>>
>> I would like to add one more paragraph:
>>
>> "All participant are authenticated by the central server, and authorized
>> to connect to the central server. The participants are identified to
>> each other by the central server, and the participants do not have
>> access to each others' credentials such as e-mail addresses or login IDs".
> I think this paragraph makes a lot of sense, and would be happy to add it. However, I’m not 100% convinced that it would add requirements that are in scope for webrtc or rtcweb.
>
> When writing up this use case, the architecture in mind was centred around a web server that carries out the functionality of serving the web app, handling users, authenticating them, authorising them, allowing them to communicate and so on. That web server would control the central (media) server, which in turn is responsible only for establishing connections for RTC with browsers, mixing audio and selecting video between the users (browsers) selected by the web server, etc.
>
> This would mean that user management, including determining what user identity is revealed to others, is controlled by the web server. I guess this is done already today for many services. What we will add is the possibility to communicate using audio and video without plug-ins.
>
> Does this make sense or not?
This makes sense. I just want it to be explicit.
It's relevant for the discussion EKR brought up about "who do I 
authorize when I say OK to using a camera" - if it's the far end of the 
connection or the service I'm connecting to.

In the centralized server case, with the added text, it's definitely the 
service, and I'd like to keep it that way. So this is text added in 
order to make sure we don't generate a requirement....