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

Martin Thomson <martin.thomson@gmail.com> Thu, 07 November 2013 00:38 UTC

Return-Path: <martin.thomson@gmail.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 82F9A21E81AE for <rtcweb@ietfa.amsl.com>; Wed, 6 Nov 2013 16:38:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.527
X-Spam-Level:
X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, 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 59Tis6cBs1EI for <rtcweb@ietfa.amsl.com>; Wed, 6 Nov 2013 16:38:04 -0800 (PST)
Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 2774411E8160 for <rtcweb@ietf.org>; Wed, 6 Nov 2013 16:37:53 -0800 (PST)
Received: by mail-we0-f173.google.com with SMTP id u57so254727wes.32 for <rtcweb@ietf.org>; Wed, 06 Nov 2013 16:37:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XaZteJXB6qtcwxKwhZFZV4WE/0suD7bUHnDu45gHf9Y=; b=kg6X/Gd0G6R2lKpFB0LmE5IcrHKzvA+vTLfGpM7EtBfu360GBBnD3Cjrkvs/T7pOt0 LQx+u3WxQjP3qCxjUPqyZwqZCEG9L3Qdc3TuXf1n/3NtDXUGkGF340/c0Z7rslv2eR3T lyI2y0RMHANGkLXLvjBqae9nKC8WP04gFWxu+BF95NcluRkXij3eYZKwMTSHj/gx5GiD OxYvh+a0HKTB/xkDV4ZkTJJKDSzvA16LxDPkdEObKRHK365NpVN28bg7wdj7sTtYHTpB nJ59oHsgvCl02SsZz5j3ovP8JmFitjR3YZ5tmv0mhK+sqY3VyfZSNU0edDohP89DLIZQ 28Ow==
MIME-Version: 1.0
X-Received: by 10.194.176.163 with SMTP id cj3mr4843260wjc.8.1383784671350; Wed, 06 Nov 2013 16:37:51 -0800 (PST)
Received: by 10.227.202.194 with HTTP; Wed, 6 Nov 2013 16:37:51 -0800 (PST)
In-Reply-To: <CAAJUQMjsgtxdofJ0FDKqM8HxS3nUvQXgq+oWKrvkW3f3c15Rbw@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> <CAAJUQMjsgtxdofJ0FDKqM8HxS3nUvQXgq+oWKrvkW3f3c15Rbw@mail.gmail.com>
Date: Wed, 6 Nov 2013 16:37:51 -0800
Message-ID: <CABkgnnXMaKsCwquMRWdtdSXT98e0tK+KR_z334jO3e2biK85Qw@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Wolfgang Beck <wolfgang.beck01@googlemail.com>
Content-Type: text/plain; charset=UTF-8
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:38:58 -0000

On 6 November 2013 16:04, Wolfgang Beck <wolfgang.beck01@googlemail.com> wrote:
> 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.

There is always a possibility for prefetching user authentication
(with some caveats below).  However, it is only possible to acquire
the assertion after generating an identity assertion.  If you have
done the authentication prior to the call, then the call can proceed
without bothering the user.

The nature of the "log in" experience on the web is highly variable
and flexible.  The class of IdPs that we are talking about currently
use have relatively long-lived authentication cookies, so I would
consider it unlikely that these IdP interactions would require user
interaction, as long as the last login to the IdP - for any reason -
was relatively recent.

For example, if you use Facebook as your IdP and you've been to
Facebook recently, then I'd expect that the IdP would just proceed
maybe after a one-off authorization for the user agent).

And, just in case there is any confusion on the subject, validating an
assertion does not necessarily require that a user log in.  A Facebook
IdP could be used to validate an assertion generated by Facebook,
regardless of whether the relying user is a Facebook user.

The caveat: There is an open question with respect to discovery or
configuration of IdPs.  For what I hope are obvious reasons, we need
to ensure that the identity IdPs are not made public.

That means that an application will be unable to guarantee that a user
is logged in when the call is initiated.  The upshot of that is not so
serious as you might think.  If I read our current discussions
correctly, we are headed toward a situation where calls can be setup
without the identity mechanisms being complete.  (Note to self,
examine trickling identity.)