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

Wolfgang Beck <wolfgang.beck01@googlemail.com> Thu, 07 November 2013 00:04 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 6A19E21E80D0 for <rtcweb@ietfa.amsl.com>; Wed, 6 Nov 2013 16:04:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.835
X-Spam-Level:
X-Spam-Status: No, score=-1.835 tagged_above=-999 required=5 tests=[AWL=0.142, 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 calLJLoTWGfG for <rtcweb@ietfa.amsl.com>; Wed, 6 Nov 2013 16:04:46 -0800 (PST)
Received: from mail-vc0-x22d.google.com (mail-vc0-x22d.google.com [IPv6:2607:f8b0:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id BB03D21E80CE for <rtcweb@ietf.org>; Wed, 6 Nov 2013 16:04:46 -0800 (PST)
Received: by mail-vc0-f173.google.com with SMTP id lh4so167558vcb.4 for <rtcweb@ietf.org>; Wed, 06 Nov 2013 16:04:46 -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=SAkx/FoLZd40aHqm8wO3aO7xlxfXLhDY9678KJHS9wQ=; b=WVw36CEObz2+EsczWcD9PwZKgcfJvJMK+TbE7UJ6MRdz8LKE7K9jd8DEu/Z1DBnKvq 3nR8w8Roh2NlA6Z8fFgaTGp5BA6or+ua/7JLCMT85q2CxFESV83rF5i+E9a3AUU2aIY5 bKMlhXqoVllJugLN9zOYTqWmEWNsfcPf9wDguzhJmXBbY3flgqUkAPU2ntRSscaWjIFa 1VUjJHxzeUXAN3MrLuhP/AlU1OCWxWAe4S4uEh4e2WXL6yGPWf0efTex+Dm2Gaeu60aR tv/bO0ToPH0RCWEjAFRMQPqRcQnA63bEYxVMhzaxRnFX67zeCvNg6xoSQ54RlLaV2H7Q T0Dw==
MIME-Version: 1.0
X-Received: by 10.220.10.70 with SMTP id o6mr534524vco.45.1383782685843; Wed, 06 Nov 2013 16:04:45 -0800 (PST)
Received: by 10.58.45.169 with HTTP; Wed, 6 Nov 2013 16:04:45 -0800 (PST)
Received: by 10.58.45.169 with HTTP; Wed, 6 Nov 2013 16:04:45 -0800 (PST)
In-Reply-To: <CABkgnnUvSfHD7LQKnO=Ss_3m3Et3=iDE5t99gHRDNvTfzecX5A@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> <CAAJUQMgXX1+7xa2pOioZBhMO9h9m71xian8kEaFNr+O=cvqLyQ@mail.gmail.com> <CABkgnnUvSfHD7LQKnO=Ss_3m3Et3=iDE5t99gHRDNvTfzecX5A@mail.gmail.com>
Date: Thu, 7 Nov 2013 01:04:45 +0100
Message-ID: <CAAJUQMjsgtxdofJ0FDKqM8HxS3nUvQXgq+oWKrvkW3f3c15Rbw@mail.gmail.com>
From: Wolfgang Beck <wolfgang.beck01@googlemail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Content-Type: multipart/alternative; boundary=001a11c3b8786fa5bc04ea8b032b
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: Thu, 07 Nov 2013 00:04:47 -0000

Probably not. It depends on the idp and browser settings. I'd rather fix
the problem than limit the frequency of its ocurrence. Maybe it's as easy
as having way for  the webrtc server to determine  what attributes the
idp-proxy is going to request, so it could 'prefetch' it.
Am 06.11.2013 11:14 schrieb "Martin Thomson" <martin.thomson@gmail.com>om>:

> On 6 November 2013 05:45, Wolfgang Beck <wolfgang.beck01@googlemail.com>
> wrote:
> > 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.
>
>
> This is, overall, correct.  However, do you think that you have to
> login every time that you load or reload a webpage?
>