Re: [rtcweb] Use case change request: Identity in multiuser calls
Harald Alvestrand <harald@alvestrand.no> Thu, 11 August 2011 15:08 UTC
Return-Path: <harald@alvestrand.no>
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 76FA521F8A71 for <rtcweb@ietfa.amsl.com>; Thu, 11 Aug 2011 08:08:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.584
X-Spam-Level:
X-Spam-Status: No, score=-102.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 38+SVm-W1GZU for <rtcweb@ietfa.amsl.com>; Thu, 11 Aug 2011 08:08:26 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 4EE3E21F89C1 for <rtcweb@ietf.org>; Thu, 11 Aug 2011 08:08:26 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 202B139E072 for <rtcweb@ietf.org>; Thu, 11 Aug 2011 17:07:49 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eDmYq-Vgs1tm for <rtcweb@ietf.org>; Thu, 11 Aug 2011 17:07:47 +0200 (CEST)
Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id AD1DE39E0BC for <rtcweb@ietf.org>; Thu, 11 Aug 2011 17:07:47 +0200 (CEST)
Message-ID: <4E43F08A.4010808@alvestrand.no>
Date: Thu, 11 Aug 2011 17:08:58 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <4E4292B2.8000904@alvestrand.no> <4E42A17B.3070004@jesup.org>
In-Reply-To: <4E42A17B.3070004@jesup.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
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 15:08:27 -0000
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
- [rtcweb] Use case change request: Identity in mul… Harald Alvestrand
- Re: [rtcweb] Use case change request: Identity in… Paul Kyzivat
- Re: [rtcweb] Use case change request: Identity in… Randell Jesup
- Re: [rtcweb] Use case change request: Identity in… Stefan Håkansson LK
- Re: [rtcweb] Use case change request: Identity in… Harald Alvestrand
- Re: [rtcweb] Use case change request: Identity in… Stefan Håkansson LK
- Re: [rtcweb] Use case change request: Identity in… Harald Alvestrand
- Re: [rtcweb] Use case change request: Identity in… Harald Alvestrand
- Re: [rtcweb] Use case change request: Identity in… Henry Sinnreich
- Re: [rtcweb] Use case change request: Identity in… Paul Kyzivat
- Re: [rtcweb] Use case change request: Identity in… Igor Faynberg
- Re: [rtcweb] Use case change request: Identity in… Henry Sinnreich
- Re: [rtcweb] Use case change request: Identity in… Igor Faynberg
- Re: [rtcweb] Use case change request: Identity in… Henry Sinnreich
- Re: [rtcweb] Use case change request: Identity in… Randell Jesup
- Re: [rtcweb] Use case change request: Identity in… Igor Faynberg
- Re: [rtcweb] Use case change request: Identity in… Paul Kyzivat
- [rtcweb] Exchange of trusted identities in server… Harald Alvestrand
- Re: [rtcweb] Exchange of trusted identities in se… Igor Faynberg
- Re: [rtcweb] Exchange of trusted identities in se… Paul Kyzivat
- Re: [rtcweb] Exchange of trusted identities in se… Alan Johnston
- Re: [rtcweb] Exchange of trusted identities in se… Randell Jesup