Re: [saag] Liking Linkability

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 <kidehen@openlinksw.com>
>>>> wrote:
>>>>> On 10/18/12 11:34 AM, Ben Laurie wrote:
>>>>>> On 9 October 2012 14:19, Henry Story <henry.story@bblfish.net> 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.
>>>
>>
>>
>
>

Received on Thursday, 18 October 2012 18:18:27 UTC