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

[Harald Alvestrand <[e-mail]>]

On 08/10/11 17:19, Randell Jesup wrote:
> On 8/10/2011 10:16 AM, 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".
>> This is necessary in order to drive use cases that resemble Google
>> Hangout, where it is a requirement that people are able to participate
>> without disclosing their Google login IDs to each other.
>> (in the particular case of Hangout, the display name on their profile
>> *is* disclosed ... but that's a different matter)
>> The reason I think this is important is that it feeds directly into the
>> discussion of what WebRTC needs to authorize: The final source or
>> destination of media, or the identity of the handler at the first hop.
>> In at least the case of Hangouts, the requirement is to *not* authorize
>> the final source or destination.
> Could this be handled by defining this case as a central server which is
> the target of the "call", and which provides in response 1 or more video/
> audio streams to the caller.  So you're only authenticating the 
> server, and
> the server is responsible for stripping and replacing the authentication
> info for the forwarded streams.  The conferencing aspect is merely an 
> aspect
> of the service the server provides.  It might merge the video streams,
> selectively forward them depending on speaker or on preference of the 
> viewer,
> and do similar things with audio.
I think parts of that is an implementation strategy for the scenario in 
4.3.3 - it doesn't have to be that way, so we shouldn't define it as 
part of the scenario.
>
> While in theory it's largely covered by the point-to-point case (for 
> example,
> a point-to-point call should support multiple streams), a separate
> use-case is still useful here since it both highlights 
> conferencing-specific
> issues (such as larger numbers of streams, etc).
>
> We should consider ways for a client to indicate how many simultaneous 
> decodes
> it's willing/able to handle.  This lets the server be smart about what it
> sends (it may be as simple as rejecting video streams on 
> re-negotiation of o/a
> - and that may help handle things such as where the number of streams 
> supported
> varies with the type of encoding/resolution/frame-rate, or other 
> client-side loads).
If we do multiple video streams inside an RTP session, we don't need 
re-negotiation of o/a to add more streams. We might consider the 
proposed extensions in 
draft-westerlund-avtcore-multistream-and-simulcast to add information 
about number of streams to O/A (he suggests that for max backwards 
compatibility, we should assume that no more than one stream per RTP 
session can be handled unless the extension is used, but that might be 
an overly conservative suggestion).

>
> For example, as people join a "Hangout", the server would re-negotiate 
> to add
> a video/audio pair (using SDP grouping I assume).  If the client can't 
> handle
> another one, it could reject the add (or renegotiate to lower the 
> complexity/size
> of existing streams, perhaps).  The server might then send the N most 
> "interesting"
> streams, or combine streams, etc.  SDP+o/a may not be optimal here but 
> I think it
> would get the job done.
Hangouts put all the video streams into one RTP session, and all the 
audio streams into another RTP session. Renegotiation would be needed if 
it didn't.
>
> Note that this requires the central server to decrypt and re-encrypt the
> streams (as I believe Harald's wording above would).
Not necessarily - if key negotiation goes via the server, the server 
could make sure the key used in the server-to-client direction is the 
same key as that used in the client-to-server direction - but if you 
want to put 2 media streams into the same RTP session, and do keying per 
RTP session, the server would have to decrypt-then-encrypt.
>
>
> The "and authorized to connect to the central server" I think is 
> unneeded -
> that's up to the policy of the server; there's no reason it can't allow
> arbitrary (non-authorized) connections if the service/server so choose.
> The same for authenticating the users - that's up to the server/service.
> One can run encryption without authenticating the users.
>
Yup - when I was writing "authorized to connect", I was thinking of 
anonymous/open access as "policy: everyone's authorized". Similarly, 
authentication - not authenticating is usually easier than 
authenticating, so we don't need to add extra text to cover the 
unauthenticated case.
(showing my age: FTP doesn't really do unauthenticated mode; it just has 
the convention that "anonymous" has a blank password....)

                  Harald