On 18/10/2012 18:33, Kingsley Idehen wrote:
On 10/18/12 12:56 PM, David Chadwick wrote:
and if the user puts his/her email address attribute in the U-Prove
token???

Then they've broken un-linkability since a mailto: scheme URI is the
ultimate unit of privacy compromise on today's Internet and Web,

yes I know. My main point was that using U-Prove or Idemix is employing a very sophisticated privacy protecting encryption scheme that can easily and trivially be undone by everyday users who provide their email address attributes inside the tokens. So I suspect the applicability of these tokens will be quite limited

regards

David

 bearing
in mind the state of the underground personal information networks.
Every social network uses your mailto: scheme URI as a key component.
Even if they don't share this data with 3rd parties, other pieces of the
puzzle come together quite easily due to the fundamental semantics
associated with mailto: scheme URIs i.e., you only need to have them in
an inverseFunctionalProperty relationship for entropy to drive the rest
of the profile coalescence.

The world I envisage starts with the ability to generate (with ease)
X.509 certificates bearing WebIDs in their SAN slots. We will have many
such certificates for a variety of purposes. An email address or any
other overtly identifiable data isn't a mandatory component an X.509
certificate  :-)

If I want to send something that's only readable by You, I would encrypt
that email via S/MIME. When I make an access policy or resource ACL I
tend not to require email addresses, for instance [1].

Links:

1. http://bit.ly/Rbnayv -- some posts about the use of social entity
relationship semantics to constrain access to my personal data space on
the Web.

Kingsley

David

On 18/10/2012 17:52, Kingsley Idehen wrote:
On 10/18/12 12:06 PM, Ben Laurie wrote:
On 18 October 2012 16:41, Kingsley Idehen <[email protected]>
wrote:
On 10/18/12 11:34 AM, Ben Laurie wrote:
On 9 October 2012 14:19, Henry Story <[email protected]> wrote:
Still in my conversations I have found that many people in security
spaces
just don't seem to be  able to put the issues in context, and can
get
sidetracked
into not wanting any linkability at all. Not sure how to fix that.
You persist in missing the point, which is why you can't fix it. The
point is that we want unlinkability to be possible. Protocols that do
not permit it or make it difficult are problematic. I have certainly
never said that you should always be unlinked, that would be stupid
(in fact, I once wrote a paper about how unpleasant it would be).

As I once wrote, anonymity should be the substrate. Once you have
that, you can the build on it to be linked when you choose to be, and
not linked when you choose not to be. If it is not the substrate,
then
you do not have this choice.




Do you have example of what you describe? By that question I mean:
implicit
anonymity as a functional substrate of some realm that we experience
today?
That's what selective disclosure systems like U-Prove and the PRIME
project are all about.



Ben,

How is the following incongruent with the fundamental points we've been
trying to make about the combined effects of URIs, Linked Data, and
Logic en route to controlling privacy at Web-scale?

Excerpt from Microsoft page [1]:

A U-Prove token is a new type of credential similar to a PKI certificate
that can encode attributes of any type, but with two important
differences:

1) The issuance and presentation of a token is unlinkable due to the
special type of public key and signature encoded in the token; the
cryptographic “wrapping” of the attributes contain no correlation
handles. This prevents unwanted tracking of users when they use their
U-Prove tokens, even by colluding insiders.

2) Users can minimally disclose information about what attributes are
encoded in a token in response to dynamic verifier policies. As an
example, a user may choose to only disclose a subset of the encoded
attributes, prove that her undisclosed name does not appear on a
blacklist, or prove that she is of age without disclosing her actual
birthdate.


Why are you assuming that a hyperlink based pointer (de-referencable
URI) placed in the SAN of minimalist X.509 certificate (i.e., one that
has now personally identifiable information) can't deliver the above and
more?

Please note, WebID is a piece of the picture. Linked Data, Entity
Relationship Semantics and Logic are other critical parts. That's why
there isn't a golden ontology for resource access policies, the resource
publisher can construct a plethora of resource access policies en route
to leveraging the power of machine discernible entity relationship
semantics and first-order logic.

In a most basic super paranoid scenario, if I want to constrain access
to a resource to nebulous entity "You" I would share a PKCS#12 document
with that entity. I would also have an access policy in place based on
the data in said document. I would also call "You" by phone to give you
the password of that PKCS#12 document. Once that's all sorted, you can
open the document, get your crytpo data installed in your local keystore
and then visit the resource I've published :-)

Links:

1. http://research.microsoft.com/en-us/projects/u-prove/
2. http://en.wikipedia.org/wiki/Zero-knowledge_proof -- I don't see
anything about that being incompatible with what the combined use of
de-referencable URIs based names, Linked Data, Entity Relationship
Semantics, Reasoning, and existing PKI deliver.






Reply via email to