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

Henry Sinnreich <henry.sinnreich@gmail.com> Thu, 11 August 2011 16:06 UTC

Return-Path: <henry.sinnreich@gmail.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE78C21F8B67 for <rtcweb@ietfa.amsl.com>; Thu, 11 Aug 2011 09:06:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.076
X-Spam-Level:
X-Spam-Status: No, score=-3.076 tagged_above=-999 required=5 tests=[AWL=0.523, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s7jqnNy4DdVX for <rtcweb@ietfa.amsl.com>; Thu, 11 Aug 2011 09:06:37 -0700 (PDT)
Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 03E6421F8B63 for <rtcweb@ietf.org>; Thu, 11 Aug 2011 09:06:36 -0700 (PDT)
Received: by yie12 with SMTP id 12so1668685yie.31 for <rtcweb@ietf.org>; Thu, 11 Aug 2011 09:07:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=iXElSa8rgOjkMCkkskxDMgrwbxjZMfYcxAkyR8qjkS0=; b=noPPf4DUlBdX45PDOS/Vs9Drcb+JzAY8D5FytyBfyIOuUubuqz40akqhO5kXDcx7XE BYQfp9x0e4j/ivQ3gS9pJ5umAn0j7JwePxgkCMPka4qUzuhASFtyXtX4L2gEiy6mJ0WH e0hr8CuGEfBulIqrUI/hHkYhC6vzxyrmpgV5o=
Received: by 10.151.107.21 with SMTP id j21mr824645ybm.150.1313078831482; Thu, 11 Aug 2011 09:07:11 -0700 (PDT)
Received: from [192.168.15.2] (cpe-76-184-227-249.tx.res.rr.com [76.184.227.249]) by mx.google.com with ESMTPS id m1sm3466930ybe.4.2011.08.11.09.07.06 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 11 Aug 2011 09:07:07 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.30.0.110427
Date: Thu, 11 Aug 2011 11:07:03 -0500
From: Henry Sinnreich <henry.sinnreich@gmail.com>
To: Harald Alvestrand <harald@alvestrand.no>, rtcweb@ietf.org
Message-ID: <CA696857.1CB81%henry.sinnreich@gmail.com>
Thread-Topic: [rtcweb] Use case change request: Identity in multiuser calls
Thread-Index: AcxYQLVQU1k/TX8fykKOzRExDrAJpA==
In-Reply-To: <4E4292B2.8000904@alvestrand.no>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Subject: Re: [rtcweb] Use case change request: Identity in multiuser calls
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Aug 2011 16:06:37 -0000

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

Thanks, Henry


On 8/10/11 9:16 AM, "Harald Alvestrand" <harald@alvestrand.no> 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