Re: [rtcweb] Signalling, SDP, and the way we think about interconnecting RTCWEB applications

Wolfgang Beck <> Mon, 17 October 2011 17:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6837421F8772 for <>; Mon, 17 Oct 2011 10:10:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id m0Jrjx-jlzJO for <>; Mon, 17 Oct 2011 10:10:51 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5187121F86C1 for <>; Mon, 17 Oct 2011 10:10:51 -0700 (PDT)
Received: by qadb12 with SMTP id b12so2951719qad.31 for <>; Mon, 17 Oct 2011 10:10:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=KiDnG8z6F305e8XqjRV8DKGx+YAW5xc5+j0m+wM2Mks=; b=r7aiaX390FwITvQ+2hRt+uC/7UTOXC1UMVqNrS5nT6bAc8TvUh9uAkQ4E5xfiwNDSF ItIJu+/wOIepqomh0TGwDsi3GA4wy2n/tCg17ph1bHpxC4ivMKu+4K5r6ognxPz1/Rk0 KcfLAJiDe9gh/a5YqpuhThf4jOJxZFefpTv5Q=
MIME-Version: 1.0
Received: by with SMTP id s7mr31630744pbk.33.1318871450443; Mon, 17 Oct 2011 10:10:50 -0700 (PDT)
Received: by with HTTP; Mon, 17 Oct 2011 10:10:50 -0700 (PDT)
In-Reply-To: <>
References: <AAE428925197FE46A5F94ED6643478FEA925614C6A@HE111644.EMEA1.CDS.T-INTERNAL.COM> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
Date: Mon, 17 Oct 2011 19:10:50 +0200
Message-ID: <>
From: Wolfgang Beck <>
To: Randell Jesup <>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [rtcweb] Signalling, SDP, and the way we think about interconnecting RTCWEB applications
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 17 Oct 2011 17:10:52 -0000

On Mon, Oct 17, 2011 at 5:00 PM, Randell Jesup <> wrote:

> Ok, I looked at draft-beck-rtcweb-alt-ic.
> One huge problem with it: it's based on an assumption that for most cases of
> federation and cross-service calls won't hold: that clients will use the
> same client JS app, and the services are just providing different
> realms/methods of authentication and user-lookup.
> Also, your draft doesn't explain how A & B came to be talking to the same
> server in the first place.  The draft seems mostly focused on how a single
> provider can use a shared authentication scheme (and I would suggest that we
> try to find a provider-agnostic way to leverage id systems such as BrowserID
> and/or OpenID to provide end-user identification).
Ok, here's an example that works today. Let's assume you have a yahoo
account and want to post a comment on
You just point your browser to the url [i.e. user
location]. Now you log in using your yahoo account as OpenID. The
browser loads the stackexchanges's JS client that enables you to post
your text.  There is no comment-posting-protocol required between
yahoo and
stackexchange. They only have to agree on an 3rd party authentication protocol.

If stackexchange extends its functionality, let's say with real-time
chat (which they did), your browser will load the appropriate JS
the next time you load the page.  All parties in the chat will use the
same JS client under stackexchange's control, regardless whether
people have
used google, yahoo, or facebook to log in. There is no need to
standardize anything that crosses stackexchange's servers.

Now you want to make a comment on some blog at You point
your browser at the blog's URL and log in using your Yahoo OpenID.
The browser loads blogspot's JS client. The GUI looks quite different
but you can post your comment as well.

With the current RTCWEB thinking, we would have to specify an intra
server protocol that covered stackexchange's discussion and chat
systems as well as blogspot comments. Such a protocol would soon get
very complex.

> You should talk to ekr who's writing the security draft and see if you can
> merge some of these ideas into it.
> I don't think it in any way helps our signalling/SDP/etc discussion, my
> apologies.
Thanks for reading and commenting on the draft!