Re: [saag] Liking Linkability

Henry Story <henry.story@bblfish.net> Mon, 22 October 2012 10:33 UTC

Return-Path: <henry.story@bblfish.net>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D89E21F88FC for <saag@ietfa.amsl.com>; Mon, 22 Oct 2012 03:33:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.299
X-Spam-Level:
X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_25=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kmodJRgc4usc for <saag@ietfa.amsl.com>; Mon, 22 Oct 2012 03:33:20 -0700 (PDT)
Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3B16B21F8798 for <saag@ietf.org>; Mon, 22 Oct 2012 03:33:19 -0700 (PDT)
Received: by mail-bk0-f44.google.com with SMTP id jc3so806353bkc.31 for <saag@ietf.org>; Mon, 22 Oct 2012 03:33:19 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=jnsVPx4NCR1kU9y6fsg282xNrM4Ae3+QdeeXw4tmnAU=; b=VUlmaKu9nFZwJ4MDx72pjHUAq1TFlI9OCYoEAU6ZoXWWo9CGLuUGUK7gIgfbCz0tmm bxfNXUlU9bnFBIkuOrft/ZInVNkYSNIYUdJfOjiIipYVaMaUESLP9MubeFKsiyCUMdWZ gbEEv0EM3tOSYH7yyS69d5QFGJnX/EsiMHf066w/4/AkenFdNqN7Fxm5ixC4QRGem+Ju QO6jIBIKxJZzzG15etE7/PJndizWhXmIi79ibNOI/vb9F0ZMvZdCQS8t/YTTAlX2+3ZZ zoqchydrAb+9cozdYKs+m2GPawDLCPGoxboPWsIJXYsw/VBcDT4hQJshvvNobsBheUS0 dOxg==
Received: by 10.204.146.10 with SMTP id f10mr2434855bkv.98.1350901999006; Mon, 22 Oct 2012 03:33:19 -0700 (PDT)
Received: from bblfish.home (AAubervilliers-651-1-132-122.w86-198.abo.wanadoo.fr. [86.198.99.122]) by mx.google.com with ESMTPS id ia2sm3095496bkc.11.2012.10.22.03.33.08 (version=SSLv3 cipher=OTHER); Mon, 22 Oct 2012 03:33:09 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
Content-Type: multipart/signed; boundary="Apple-Mail=_E42F4074-0A40-49D7-B029-5B8C9E3FEBC4"; protocol="application/pkcs7-signature"; micalg="sha1"
From: Henry Story <henry.story@bblfish.net>
In-Reply-To: <CABrd9SRNVLbWxifQAQ6iuX4qMeFmZVD6rO_q=L348G1UZzr9tg@mail.gmail.com>
Date: Mon, 22 Oct 2012 12:33:06 +0200
Message-Id: <7F0FE9D3-995B-4B32-97CB-3B82F590FE92@bblfish.net>
References: <CCA5E789.2083A%Josh.Howlett@ja.net> <tslzk3jsjv8.fsf@mit.edu> <201210181904.PAA07773@Sparkle.Rodents-Montreal.ORG> <FB9E461D-CA62-4806-9599-054DF24C3FD9@bblfish.net> <CAG5KPzxGz+4MywjP4knfbDr2gyvqUZc1HEBXgtaDfYT+DPg5yg@mail.gmail.com> <8AB0C205-87AE-4F76-AA67-BC328E34AF5E@bblfish.net> <CABrd9SQghpi6_rVQKxYXZDtM5HwvE7Kq7SUw5zi41ZRd3y2h9A@mail.gmail.com> <4324B524-7140-49C0-8165-34830DD0F13B@bblfish.net> <CABrd9SQU1uYVaVPedokHxeYkT=759rkPFfimWK1Z8ATzo3yNFA@mail.gmail.com> <5083CCCF.2060407@webr3.org> <50842789.3080301@openlinksw.com> <50845268.4010509@webr3.org> <5084AC77.8030600@openlinksw.com> <50851512.9090803@webr3.org> <CABrd9SRNVLbWxifQAQ6iuX4qMeFmZVD6rO_q=L348G1UZzr9tg@mail.gmail.com>
To: Ben Laurie <benl@google.com>
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQnAqQjyqk4nhyYqQ5qVCZkqsfl+86hId89xZ+RRa5mN6z3cs6Uf5SxiTbOoUix9VbTsR1q6
Cc: public-identity@w3.org, saag@ietf.org, public-webid@w3.org, "public-privacy@w3.org list" <public-privacy@w3.org>
Subject: Re: [saag] Liking Linkability
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/saag>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Oct 2012 10:33:21 -0000

[cutting down on the mailing lists]

On 22 Oct 2012, at 11:54, Ben Laurie <benl@google.com> wrote:

> Where we came in was me pointing out that if you disconnect your
> identities by using multiple WebIDs, then you have a UI problem, and
> since then the aim seems to have been to persuade us that multiple
> WebIDs are not needed.

There is a happy medium on UI experience. For the UI experience
there are two seperate issues, one of which I proposed a fix for
and the other of which is a browser UI issue.

A. Number of WebIDs
-------------------

1. WebID per web site:

You don't want to have one WebID per site you go to, since the point 
of WebID is to allow you to authenticate across sites using the same 
ID ( in the case of TLS, a URL embedded in an X509 Certificate's SAN 
field ).

2. One and only one WebID for the whole internet per person

 WebID does not force any such restrictions (neither would OpenId
or BrowserId for that matter ). 

3. As many WebID's for the whole web as the user feels worth investing in

The first sentence of the spec says so ( http://webid.info/spec/ )

 [[
The WebID protocol enables secure, efficient and maximally user friendly authentication on the Web. It enables people to authenticate onto any site by simply clicking on one of the certificates proposed to them by their browser. These certificates can be created by any Web Site for their users in one click. The identifier, known as the WebID, is a URI whose sense can be found in the associated Profile Page, a type of web page that any Social Network user is familiar with.
 ]] 

( so we are looking for help improving the wording)

Finally, (3) above does not mean that the user can only use WebID. He can still use
all the existing technologies for authenticating to web sites where he 
wishes to have non cross-site linkable identities - e.g. cookies, with username
password for example if needed, ...

UI Experience
-------------

There are two elements to the UI experience

1. Certificate selection

  If the server requesting the certificate from the user makes a CertificateRequest
by leaving the certificate_authorities field blank ( or null, not sure what the
correct wording is ) as explained by the spec currently
 http://www.w3.org/2005/Incubator/webid/spec/#requesting-the-client-certificate

then users with multiple certificates - some of which may not be WebID enabled -
then those users will be presented with a selection box containing certificates
that are not in fact ones the server will accept - leading to confusion and a 
bad UI. I just proposed on the WebID mailing list that WebID certificate chains
be signed (at some point) by CN=WebID,O=∅ to solve this issue.
  http://lists.w3.org/Archives/Public/public-webid/2012Oct/0188.html

2. Transparency of Identity

 It is not clear currently when you go to a web site if you are authenticated or not,
or with what identities you are. Even Google Chromes' Profile feature does not do so.
This is something I really hope they will fix by inspiring themselves from Aza Raskin's
work 
  http://www.azarask.in/blog/post/identity-in-the-browser-firefox/


I hope this helps,

	Henry

Social Web Architect
http://bblfish.net/