IETF Logo Mail Archive

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

Wolfgang Beck <wolfgang.beck01@googlemail.com> Wed, 06 November 2013 13:45 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 AE05211E8210 for <rtcweb@ietfa.amsl.com>; Wed, 6 Nov 2013 05:45:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.788
X-Spam-Level:
X-Spam-Status: No, score=-1.788 tagged_above=-999 required=5 tests=[AWL=0.189, 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 IY-nVOaA90GP for <rtcweb@ietfa.amsl.com>; Wed, 6 Nov 2013 05:45:34 -0800 (PST)
Received: from mail-ve0-x232.google.com (mail-ve0-x232.google.com [IPv6:2607:f8b0:400c:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 08DCB11E81AC for <rtcweb@ietf.org>; Wed, 6 Nov 2013 05:45:33 -0800 (PST)
Received: by mail-ve0-f178.google.com with SMTP id db12so3533236veb.23 for <rtcweb@ietf.org>; Wed, 06 Nov 2013 05:45:33 -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=dh/ECCF1bIMoCPpuGvUa7jifTlTkQSO9k+3XIWC/lXg=; b=qzsWYzXuGRBCJSTRIsXOjfqm1PwLa4Yd0ZBn/fQCC6bvN9/E9Qa2jEHGfb9kEu6StR 1aMZ4OSJ7LE9iX4PYGuSCOKkbi6RFKfIFthgSfwGk4ZfbWkBMv90fvORp5clCfQ6inFz YEyMWIg62QXLOLupVWqy7FJoLtZgOhMxyUcKLeUR54x2OML9LNoM4gvWPhVHllqw96mX 9bQ1hLZycJcZJE0XifWNofMLjBgzZr9G9PKdHFPeNzfgIki/fFfQ+y0ecpcQ78FYVnRN wMs3xlj9STAQ2egC/dpI7KVYAQwjMR31FTLd2R5NSsvS5kVceGwYRY/YBY60auViE4bE cMTw==
MIME-Version: 1.0
X-Received: by 10.58.144.168 with SMTP id sn8mr430100veb.33.1383745533416; Wed, 06 Nov 2013 05:45:33 -0800 (PST)
Received: by 10.58.45.169 with HTTP; Wed, 6 Nov 2013 05:45:33 -0800 (PST)
Received: by 10.58.45.169 with HTTP; Wed, 6 Nov 2013 05:45:33 -0800 (PST)
In-Reply-To: <CABkgnnXMM6eMFcHJSPOy6oKo_SNEC0+08RMWXAdeBPtubNrjyQ@mail.gmail.com>
References: <CAAJUQMgRqOggVzviMPnvpkwSzYJeEe_1S5K00chdGq-Hghq3Dg@mail.gmail.com> <52795BF0.1020207@makk.es> <CAAJUQMj2_sXtyTf=SugJWA81Ho_+G5WJN4QCfv1Z1FQdZL=Reg@mail.gmail.com> <CABkgnnUJSWz9fqUNSp3+RGyFpHVddXWHq9Y2nMTMUf9n2H798Q@mail.gmail.com> <CAAJUQMjmWsTmvkWDgJeNuocWYAiTerT=P7fMHbXRx6mjfe9DMg@mail.gmail.com> <CABkgnnWv5DkD+hhadhB2juNP+kAzNn2wK895FKVMO_OEohv=MA@mail.gmail.com> <CAAJUQMgnoSOh+mWP9zv8P=LcLjkCcJL-t35FnWZ6JZxw0KEudQ@mail.gmail.com> <CABkgnnXMM6eMFcHJSPOy6oKo_SNEC0+08RMWXAdeBPtubNrjyQ@mail.gmail.com>
Date: Wed, 06 Nov 2013 14:45:33 +0100
Message-ID: <CAAJUQMgXX1+7xa2pOioZBhMO9h9m71xian8kEaFNr+O=cvqLyQ@mail.gmail.com>
From: Wolfgang Beck <wolfgang.beck01@googlemail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Content-Type: multipart/alternative; boundary="047d7b5da93bfa9d0a04ea825cb6"
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:45:34 -0000

Let's say the user authenticated with my webrtc service using google
openid. The webrtc server asked for the attribute 'display name'. The
OpenID server asks the user:'Can I tell webrtc server your display name
y/n?'. Now the peerconnection object asks the openid server for
authentication and the attribute 'email address', to get an rfc822 style
name it can return to the JS. This is a new permission the user has to
grant. And I dont know which openid attribute the peerconnection obj is
going to use. It can even change dynamically when google changes the
.well-known/idp document.
Am 05.11.2013 18:41 schrieb "Martin Thomson" <martin.thomson@gmail.com>:

> On 5 November 2013 18:15, Wolfgang Beck <wolfgang.beck01@googlemail.com>
> wrote:
> > What if the server requests a different set of meta data from the idp
> than
> > the peerconnection object? The idp will have two ask for permission
> twice.
>
> The number of questions the browser asks the IdP is completely
> independent of the number of times that the user is required to log
> in.  If you are both generating and validating assertions with the
> same IdP, you can ask it twice.  THe validating IdP does not require
> login.
>

v2.23.0 | Report a Bug | By Email