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

Max Jonas Werner <mail@makk.es> Thu, 07 November 2013 11:13 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 8EC0211E80E4 for <rtcweb@ietfa.amsl.com>; Thu, 7 Nov 2013 03:13:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.626
X-Spam-Level:
X-Spam-Status: No, score=-1.626 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=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 6bPhNw-U-6-D for <rtcweb@ietfa.amsl.com>; Thu, 7 Nov 2013 03:12:55 -0800 (PST)
Received: from lupus.uberspace.de (lupus.uberspace.de [95.143.172.176]) by ietfa.amsl.com (Postfix) with SMTP id D5D4311E80FE for <rtcweb@ietf.org>; Thu, 7 Nov 2013 03:12:54 -0800 (PST)
Received: (qmail 24950 invoked from network); 7 Nov 2013 11:12:50 -0000
Received: from unknown (HELO mail-vc0-x236.google.com) (2607:f8b0:400c:c03::236) by lupus.uberspace.de with SMTP; 7 Nov 2013 11:12:50 -0000
Received: by mail-vc0-f182.google.com with SMTP id if17so247087vcb.41 for <rtcweb@ietf.org>; Thu, 07 Nov 2013 03:12:47 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=X7ZwxHIgZT3OCfjnoYh1QGL/8Xy2BksZ6h56KTY7e3w=; b=eyvDc5cP5H/uTVUiUzHtMyvkMfiPUnGTGPQS+C4Pl7Njn2o69Qvz6V2Uz8xra1TG+n b3/+aXMDwaJ0V3t2ZKZWkyIGN03qB8hZ02Pjg+gy4R/thA5lk1os/LYtpAhViAGAwmlk FfFs/2XqIQxxVNCUYPBzlvo3B1zxT61xCLrBfh3DkK6QmPSbsIPplkWS0u+tW0yZEGpH T35LIuWxC2L3kQV4A8suYD3DCNZEU6cwiPqDfiUe3xjt4tZhEv8+Je2uX9psEBOGycLr J3DwXtSecOgXoY3aOjWJOh7qiOKi/+lWdkhUBXfsAOgtAJVJGhCh6H3LoxlL//grsyVm OVhQ==
X-Gm-Message-State: ALoCoQnrlcFJY4fKkJ/8CD64ttKegC4JH0oc+BLHebPLRutxeioEGFAx51y1LMlsEkAlYUrZrwUO
MIME-Version: 1.0
X-Received: by 10.221.44.136 with SMTP id ug8mr6320877vcb.13.1383822767410; Thu, 07 Nov 2013 03:12:47 -0800 (PST)
Received: by 10.58.172.165 with HTTP; Thu, 7 Nov 2013 03:12:47 -0800 (PST)
In-Reply-To: <CABkgnnXMaKsCwquMRWdtdSXT98e0tK+KR_z334jO3e2biK85Qw@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>
Date: Thu, 7 Nov 2013 12:12:47 +0100
Message-ID: <CALu1e3N__0J-LmCcdCT2J2Mbo-tYGKFkQMsyH9=C8ro5+OWJ8A@mail.gmail.com>
From: Max Jonas Werner <mail@makk.es>
To: Martin Thomson <martin.thomson@gmail.com>
Content-Type: multipart/alternative; boundary=001a113378d87bea9804ea945853
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 11:13:00 -0000

On 7 November 2013 01:37, Martin Thomson <martin.thomson@gmail.com> wrote:

>
> 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.)
>

Interesting. Currently the API spec demands that upon creating
offers/answers an identity assertion is requested. Trickling this process
would mean re-negotiation of the call using updated offers/answers, right?
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".

Max