Re: [rtcweb] usability of IdP concepts in draft-ietf-rtcweb-security-arch-07

Wolfgang Beck <wolfgang.beck01@googlemail.com> Wed, 06 November 2013 13:59 UTC

Return-Path: <wolfgang.beck01@googlemail.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 5851211E8165 for <rtcweb@ietfa.amsl.com>; Wed, 6 Nov 2013 05:59:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.815
X-Spam-Level:
X-Spam-Status: No, score=-1.815 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
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 HJoag-K1cbOm for <rtcweb@ietfa.amsl.com>; Wed, 6 Nov 2013 05:59:13 -0800 (PST)
Received: from mail-vc0-x236.google.com (mail-vc0-x236.google.com [IPv6:2607:f8b0:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 6E25F21E80D3 for <rtcweb@ietf.org>; Wed, 6 Nov 2013 05:59:13 -0800 (PST)
Received: by mail-vc0-f182.google.com with SMTP id if17so6709174vcb.13 for <rtcweb@ietf.org>; Wed, 06 Nov 2013 05:59:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hoiE/GvH6xz/t/DLxsoDxfzD0DrMMb3pd/cOaCpXF0s=; b=D1BKRRHxWCym8lY+FdbH4NFDyKaPFjjTCHqOoXHowBVbtd/akYYdfoQls/f+V596mx B/YO/vyTtL2GYTrH7OG7UIFQIPhmzt5MEceuYUyUTObrN8IN4bjTZOvpnMjzEQxuoeO6 wJ3vUEYd8JCukUeTSxgwnb9wIX8GvFKqdBlMpEOytQUSrf6sYzbCcsRG7qRd5F2kIhpB GHgWFRXj79K8fkEcYDQoDWclE28hathWyDuCbLyToit9nwWsIu328PWtVuABafVwFuQl ihfwfru9fKZwUKVnRbjQy0k7tA1Uf9OZTt9otmyUd93RTBoOXJNoZe2q3njLqmEky4QC eUQQ==
MIME-Version: 1.0
X-Received: by 10.220.74.69 with SMTP id t5mr2558144vcj.18.1383746352897; Wed, 06 Nov 2013 05:59:12 -0800 (PST)
Received: by 10.58.45.169 with HTTP; Wed, 6 Nov 2013 05:59:12 -0800 (PST)
Received: by 10.58.45.169 with HTTP; Wed, 6 Nov 2013 05:59:12 -0800 (PST)
In-Reply-To: <5279FF69.5040206@makk.es>
References: <CAAJUQMgRqOggVzviMPnvpkwSzYJeEe_1S5K00chdGq-Hghq3Dg@mail.gmail.com> <52795BF0.1020207@makk.es> <CAAJUQMj2_sXtyTf=SugJWA81Ho_+G5WJN4QCfv1Z1FQdZL=Reg@mail.gmail.com> <5279FF69.5040206@makk.es>
Date: Wed, 6 Nov 2013 14:59:12 +0100
Message-ID: <CAAJUQMiyuj9HSzhNeFzCe_fadw=B0G+9yr5UADtGwJWUV1wQtA@mail.gmail.com>
From: Wolfgang Beck <wolfgang.beck01@googlemail.com>
To: Max Jonas Werner <mail@makk.es>
Content-Type: multipart/alternative; boundary=047d7b624cbed311fb04ea828d42
Cc: "<rtcweb@ietf.org>" <rtcweb@ietf.org>
Subject: Re: [rtcweb] usability of IdP concepts in draft-ietf-rtcweb-security-arch-07
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: Wed, 06 Nov 2013 13:59:14 -0000

You explanation matches my understanding. See my mail to Martin why you
still can have two user  dialogs with your idp.  And the life time of your
idp's cookies can be shorter than the liftetime of the webrtc  server's
session cookies.

Wolfgang Beck
Am 06.11.2013 00:35 schrieb "Max Jonas Werner" <mail@makk.es>es>:

> Wolfgang,
>
> On 05.11.2013 23:03, Wolfgang Beck wrote:
> > According to the draft and the w3c doc, the Idp exchange is completely
> > hidden from the JS. I don't see how a web server could use the result to
> > verify the user without looking at the SDP. Or how the peerconnection
> could
> > reuse the result of an Idp exchange that authenticated the user towards
> the
> > server. Did I overlook something?
> >
> > Having to log in twice will only be tolerated by a small minority of
> > people.
>
> I propose you read the draft again since perhaps you overlooked
> something. Let me give you an example:
>
> You have a WebRTC application that's served from your domain
> example.com. Perhaps you've implemented some kind of login mechanism so
> the user logs in (using an HTML form perhaps) resulting in e.g. a cookie
> being saved in the user's browser carrying a session ID (again, this is
> just _one_ possibility).
>
> Your application creates a PeerConnection object and calls
> setIdentityProvider with the parameter "domain" set to "example.com" and
> the parameter "protocol" set to "proto" because you want to be your own
> IdP. When creating an offer the browser will then load the code from
> https://example.com/.well-known/idp-proxy/proto into an iframe or such
> and send a message to that code asking for an assertion. Since the IdP
> proxy code is served from the same origin it may read out the cookie
> value set earlier when logging the user in.
>
> This cookie value can now be used on the server side to automatically
> (as in without user interaction) create an assertion since the server
> already knows who the user is (from the cookie).
>
> This also works with using another IdP (say Facebook) with your
> application served from example.com. If the user is already logged into
> Facebook: no interaction needed.
>
> Max
>
>