IETF Logo Mail Archive

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

Martin Thomson <martin.thomson@gmail.com> Thu, 07 November 2013 16:32 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 9829821F9A6A for <rtcweb@ietfa.amsl.com>; Thu, 7 Nov 2013 08:32:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.53
X-Spam-Level:
X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.070, 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 7f+O2HbwRTSG for <rtcweb@ietfa.amsl.com>; Thu, 7 Nov 2013 08:32:48 -0800 (PST)
Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id D472221F9A44 for <rtcweb@ietf.org>; Thu, 7 Nov 2013 08:32:47 -0800 (PST)
Received: by mail-we0-f178.google.com with SMTP id q59so796635wes.9 for <rtcweb@ietf.org>; Thu, 07 Nov 2013 08:32:47 -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=TK+PxaxhGHJyXwZ5sprS0MknC2DSswbvSyWkBdGkqi4=; b=tjK66iDWuHAWq7339CaT3Tuc4l3D0aDTjEyncz00OprK/kfTx6Cc8JMyHPgBODm5fD /BqlDnDktHKLnvB7FJgGgbDt88Xk0XVV//oFQGdtmkzasyAS/qINa4h8ISsRMmDZXI7T 7ZjGu7dX71nNLM/92m2IumyvB6WM/+Ou7+NzUIVTZSNLyzvsa+GiSJ0uOmyR6d3Odk1I WAaHR6Q7V8Fl/nM1uaB4/6aldi/gnF8ndcYSkSIM48REPflMeKxHvdepxiZNTgX3Gafk MSrDOG8uIFTPPc0cqhs97AQ1B5lKtr64BqxSDlE4eiT/AuISadvk2QCR1Kmed7br3kjh SRpg==
MIME-Version: 1.0
X-Received: by 10.194.20.170 with SMTP id o10mr8204669wje.4.1383841966935; Thu, 07 Nov 2013 08:32:46 -0800 (PST)
Received: by 10.227.202.194 with HTTP; Thu, 7 Nov 2013 08:32:46 -0800 (PST)
In-Reply-To: <CALu1e3N__0J-LmCcdCT2J2Mbo-tYGKFkQMsyH9=C8ro5+OWJ8A@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> <CABkgnnXMaKsCwquMRWdtdSXT98e0tK+KR_z334jO3e2biK85Qw@mail.gmail.com> <CALu1e3N__0J-LmCcdCT2J2Mbo-tYGKFkQMsyH9=C8ro5+OWJ8A@mail.gmail.com>
Date: Thu, 07 Nov 2013 08:32:46 -0800
Message-ID: <CABkgnnU6p_YoDrgtsj4OQyfaq=k4BgJS1V25x2+JHw=wPu_MYw@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Max Jonas Werner <mail@makk.es>
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 16:32:48 -0000

On 7 November 2013 03:12, Max Jonas Werner <mail@makk.es> wrote:
> I wonder how that would improve UX because the user would probably see
> "identity of your peer is not verified" and some seconds/minutes later "now
> I got the assertion and verified it".

The ability to negotiate codecs and complete ICE are pretty useful.
The actual user impact is that the caller sees black until the IdP
thing completes, information that an application might choose to
suppress.  What is interesting is that the called party can actually
send AND receive media (though sending depends on gUM), because the
calling party will likely have generated an identity assertion.
Validation is quick.  The problem is that the calling party cannot
render it.  That leads to a race: signaling of the identity assertion
vs the first hello.

The good news is that identity can be gotten out of the way prior to
call establishment with a data channel setup.

v2.23.0 | Report a Bug | By Email