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

Max Jonas Werner <mail@makk.es> Tue, 05 November 2013 20:58 UTC

Return-Path: <mail@makk.es>
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 18F2D11E8196 for <rtcweb@ietfa.amsl.com>; Tue, 5 Nov 2013 12:58:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.505
X-Spam-Level:
X-Spam-Status: No, score=-1.505 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599, HELO_EQ_DE=0.35]
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 MxhPnBDQ87N7 for <rtcweb@ietfa.amsl.com>; Tue, 5 Nov 2013 12:58:31 -0800 (PST)
Received: from lupus.uberspace.de (lupus.uberspace.de [95.143.172.176]) by ietfa.amsl.com (Postfix) with SMTP id CC8A111E815B for <rtcweb@ietf.org>; Tue, 5 Nov 2013 12:58:29 -0800 (PST)
Received: (qmail 14020 invoked from network); 5 Nov 2013 20:58:26 -0000
Received: from unknown (HELO ?192.168.0.20?) (31.18.104.182) by lupus.uberspace.de with SMTP; 5 Nov 2013 20:58:26 -0000
Message-ID: <52795BF0.1020207@makk.es>
Date: Tue, 05 Nov 2013 21:58:24 +0100
From: Max Jonas Werner <mail@makk.es>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: Wolfgang Beck <wolfgang.beck01@googlemail.com>, "<rtcweb@ietf.org>" <rtcweb@ietf.org>
References: <CAAJUQMgRqOggVzviMPnvpkwSzYJeEe_1S5K00chdGq-Hghq3Dg@mail.gmail.com>
In-Reply-To: <CAAJUQMgRqOggVzviMPnvpkwSzYJeEe_1S5K00chdGq-Hghq3Dg@mail.gmail.com>
X-Enigmail-Version: 1.6
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="EuxQs5SHU05kxwCCSa2SLfweJQ9bMF8wP"
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: Tue, 05 Nov 2013 20:58:37 -0000

Wolfgang,

On 05.11.2013 18:06, Wolfgang Beck wrote:
> What I am missing in this draft is the link between authentication towards
> the web server and signing of DTLS info towards the remote party. To make a
> call, a user will have to
> 1) log into the web server application
> 2) permit the browser to access camera/mic
> 3) log into the IdP to sign the DTLS info
> 
> To receive a call, I will have to
> 1) log into the web server application
> 2) permit the browser to access camera/mic when there is a call
> 3) log into the IdP to sign the DTLS info
> ..and hope the caller has not given up before I clicked all permission
> boxes and entered all user credentials.
> 
> Can 1) and 3) be merged somehow? How would you explain 3) to a user?

1) and 3) can be merged if

a) the user is already logged from the IdP's point of view prior to even
visiting the site (using either built-in browser logic or manually)

or

b) the IdP is the able to identify the user from step 1) somehow (e.g.
when the web server is run by the IdP).

Keep in mind, though, that the user to be able to provide an identity to
the other WebRTC peer that is different from the identity of step 1) is
exactly what the user wants sometimes.

Max