More requirements

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.

13. Multiple Site Unlinkability (MSU)
The user should be able to visit multiple sites without the
sites
being able to collude to correlate the data provided by the
user. This
is a weaker requirement than SSU (that is, MSU does not
guarantee
SSU). Again, this protects the user's privacy.

14. Attack Resistant Credentials (ARC)
Credentials should be such that the (computationally
limited) verifier
cannot reconstruct the original credential by brute force.
Note that
the impossibility of this may rely on the user choosing
strong
secrets, which is often unlikely, for example where the sole
source of
entropy is a password.

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.
_______________________________________________
Ietf-http-auth mailing list
Ietf-http-authosafoundation.org
http://lists.osafoundation.org/cgi-bin/mai
lman/listinfo/ietf-http-auth

"Ben Laurie" <benlgoogle.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. 


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

-Ekr


_______________________________________________
Ietf-http-auth mailing list
Ietf-http-authosafoundation.org
http://lists.osafoundation.org/cgi-bin/mai
lman/listinfo/ietf-http-auth

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

I think many of the requirements (no, haven't made a list
yet) have the 
assumption of "when appropriate", or "when
desired", where "desired" is 
some combination of what the user wants and what the
application wants or 
will permit.

  - RL "Bob"

_______________________________________________
Ietf-http-auth mailing list
Ietf-http-authosafoundation.org
http://lists.osafoundation.org/cgi-bin/mai
lman/listinfo/ietf-http-auth

On 7/14/06, EKR <ekrnetworkresonance.com> wrote:
> "Ben Laurie" <benlgoogle.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
>
>
>
_______________________________________________
Ietf-http-auth mailing list
Ietf-http-authosafoundation.org
http://lists.osafoundation.org/cgi-bin/mai
lman/listinfo/ietf-http-auth

RL 'Bob' Morgan wrote:
 >
 > I think many of the requirements (no, haven't made a
list yet) have the
 > assumption of "when appropriate", or
"when desired", where "desired" is
 > some combination of what the user wants and what the
application wants
 > or will permit.

Indeed, many of these are distinct "security
properties". Note in the intro to 
his note, ekr termed the content of his note as:

   "a taxonomy of requirements/features and technical
options"


JeffH




_______________________________________________
Ietf-http-auth mailing list
Ietf-http-authosafoundation.org
http://lists.osafoundation.org/cgi-bin/mai
lman/listinfo/ietf-http-auth

> Indeed, many of these are distinct "security
properties". Note in the intro 
> to his note, ekr termed the content of his note as:
>
>  "a taxonomy of requirements/features and
technical options"

Right, a problem we often have with stating requirements is 
differentiating between "X is required to be
possible/negotiable" and "X 
is required to always be done"; where the first of
these produces 
derivative requirements about the nature of the negotiation
of and/or 
policy around the feature.

  - RL "Bob"
_______________________________________________
Ietf-http-auth mailing list
Ietf-http-authosafoundation.org
http://lists.osafoundation.org/cgi-bin/mai
lman/listinfo/ietf-http-auth