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

Harald,

There was a lot of consideration of similar issues in the discussions 
around draft-ietf-simple-chat-*. What I took away is that conferencing 
implementations often want something like this, and they all spin it in 
slightly different ways. I *suspect* that in many cases the differences 
were gratuitous at the start, but that ultimately the chosen semantics 
become entrenched. As a result, it may be necessary to support an 
assortment of identity semantics - some of which may not make a lot of 
sense when looked at closely and critically.

This centered on "nicknames" to be visible in the conference, and to be 
used to support private communication between individuals in the 
conference without disclosing their actual addresses. (I guess the 
display names you mention below may be an instance of this.) We got into 
all sorts of discussions of scope of uniqueness of nicknames.

	Thanks,
	Paul

On 8/10/11 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.
>
> 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
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>