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

[Henry Sinnreich <[e-mail]>]

> 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"?

The most credible e2e identification that comes to my mind is Phil
Zimmermann's Zfone technology:

http://www.ietf.org/id/draft-johnston-rtcweb-media-privacy-00.txt
http://zfoneproject.com/

Definitely not relying on any "trusted" server :-)

Thanks, Henry

On 8/11/11 11:50 AM, "Paul Kyzivat" <[e-mail]> wrote:

> 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
>> 
> 
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb