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

[Paul Kyzivat <[e-mail]>]

On 8/11/11 12:07 PM, Henry Sinnreich wrote:
>> The participants are identified to
>> each other by the central server
>
> There may be no contradiction, but just to make sure the scenario, such as a
> confidential business meeting is included (not necessarily a social network
> scenario).
>
> A confidential conference MUST assure that all participants can also be
> safely identified first to each other, not necessarily by the server, end to
> end, to the full satisfaction of all the participants, who would otherwise
> refuse to continue  to speak up or continue to attend at all.
> Who provides for the e2e identification? A 3rd party? Inside the app?
>
> Did I understand correctly there is no contradiction?
> Any problem in clarifying this?

This is an example of the sort of thing I was speaking of in my earlier 
reply - that there are differing levels of identity that may be desired.

In some cases, participants may want to be fully anonymous. But even 
then, it will typically be important that one participant be able to 
identify *which* of the other (anonymous) participants it is receiving 
media from. (E.g. by noting which participant in the roster is the 
current speaker - anon1, anon2, ...)

In other cases the participants *true* identities are hidden, but 
handles/nicknames may be used to identify them in the roster and in 
chats. ("snoopy" and "red barron" rather than anon1 and anon2.)

But in that case there are issues of how the handles are associated with 
participants. It could be that handles are permanently assigned to real 
users by the server. Then you can be confident that when talking to 
"snoopy" it is always someone well defined - same as the last time - 
without awareness of who that person *actually* is.

Alternatively, the server might allow handles to be used on a fcfs basis 
per conference. Or it might allow handles to be non-unique, so that you 
could have two "snoopy"s at the same time, bound to unrelated users.

Henry - what sort of mechanism did you have in mind for these anonymous 
participants to identify themselves to one another? Are you talking 
about the exchange of credentials using the server as an intermediary in 
the exchange? Or did you have in mind an exchange outside the server. 
(E.g. Bob establishes a secure connection to Alice and over it tells her 
"I'm anon2 in conference foo right now"?

	Thanks,
	Paul

> Thanks, Henry
>
>
> On 8/10/11 9:16 AM, "Harald Alvestrand"<[e-mail]>  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.
>>
>> Not sure yet how to formulate that as a requirement, and not sure yet if
>> it applies to the cases without a central server, such as 4.2.6. We may
>> have to decide.
>>
>>                           Harald
>>
>>
>> _______________________________________________
>> rtcweb mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtcweb
>
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>