[dix] Re: [Ietf-http-auth] More requirements

"Ben Laurie" <benl@google.com> Fri, 14 July 2006 14:23 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1OZS-0005jI-Mr; Fri, 14 Jul 2006 10:23:10 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1OZS-0005g2-5r for dix@ietf.org; Fri, 14 Jul 2006 10:23:10 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1N4M-0005Ws-GY for dix@ietf.org; Fri, 14 Jul 2006 08:46:58 -0400
Received: from smtp-out.google.com ([216.239.45.12]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G1MwG-0004aM-6y for dix@ietf.org; Fri, 14 Jul 2006 08:38:36 -0400
Received: from lois.corp.google.com (lois.corp.google.com [172.24.0.50]) by smtp-out.google.com with ESMTP id k6ECcPxm003973 for <dix@ietf.org>; Fri, 14 Jul 2006 05:38:26 -0700
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=received:message-id:date:from:to:subject:cc:in-reply-to: mime-version:content-type:content-transfer-encoding: content-disposition:references; b=PhbR4wgaTuHwzPikbTxlHwRZ4/UjuRmTJpoNCUFqowOq6IpbwGjjAu4zofB54Okut Im8of+WtTo3RX0T6snXaA==
Received: from smtp-out2.google.com (fpe16.prod.google.com [10.253.5.16]) by lois.corp.google.com with ESMTP id k6ECQfgX032765 for <dix@ietf.org>; Fri, 14 Jul 2006 05:38:20 -0700
Received: by smtp-out2.google.com with SMTP id 16so221284fpe for <dix@ietf.org>; Fri, 14 Jul 2006 05:38:18 -0700 (PDT)
Received: by 10.253.29.11 with SMTP id c11mr64190fpc; Fri, 14 Jul 2006 05:38:18 -0700 (PDT)
Received: by 10.253.14.2 with HTTP; Fri, 14 Jul 2006 05:38:18 -0700 (PDT)
Message-ID: <1b587cab0607140538y3fd02c10i7f20b6270591003f@mail.google.com>
Date: Fri, 14 Jul 2006 08:38:18 -0400
From: Ben Laurie <benl@google.com>
To: EKR <ekr@networkresonance.com>
In-Reply-To: <86wtag5r75.fsf@delta.rtfm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <1b587cab0607131743g36c96314ta9b3a0a90aa871e0@mail.google.com> <86wtag5r75.fsf@delta.rtfm.com>
X-Spam-Score: -2.5 (--)
X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4
Cc: Digital Identity Exchange <dix@ietf.org>, IETF HTTP Auth <ietf-http-auth@lists.osafoundation.org>
Subject: [dix] Re: [Ietf-http-auth] More requirements
X-BeenThere: dix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Digital Identity Exchange <dix@ietf.org>
List-Id: Digital Identity Exchange <dix.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dix>, <mailto:dix-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dix>
List-Post: <mailto:dix@ietf.org>
List-Help: <mailto:dix-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dix>, <mailto:dix-request@ietf.org?subject=subscribe>
Errors-To: dix-bounces@ietf.org

On 7/14/06, EKR <ekr@networkresonance.com> wrote:
> "Ben Laurie" <benl@google.com> writes:
>
> > On the plane to IETF I realised that there were several more potential
> > requirements to add to ekr's list:
> >
> > 12. Single Site Unlinkability (SSU)
> > The user should be able to visit the same site multiple times without
> > the site being able to tell that it is the same user, even if the user
> > is, for example, asserting the same external claims each time. This
> > protects the user's privacy. Obviously if data provided by the user is
> > unique to that user (for example, age and address combined are often
> > sufficient to uniquely identify a person) then no amount of cleverness
> > can provide SSU, but SSU should be available to the extent permitted
> > by the uniqueness of the data provided.
>
> This is an interesting requirement and obviously of value, but
> it's worth noting that there are contexts in which linkability
> (CI) is precisely what's desired--blog comments, for example.
>
> So, you wouldn't want to design a system that always provided
> SSU. :)

Totally agreed.

> > 15. Claim Minimality (CM)
> > The ability to show only exactly what is needed, (for example, the
> > user is over 21 rather than the user's exact age, or if there are
> > mutlple claims the ability to show a subset). This improves privacy
> > and reduces linkability.
>
> Note that this ties in with IAC.

Right - the distinction is that rather than merely separating claims
you want to be able to prove properties of claims instead of revealing
their actual content.

>
> -Ekr
>
>
>

_______________________________________________
dix mailing list
dix@ietf.org
https://www1.ietf.org/mailman/listinfo/dix