Re: [saag] Liking Linkability

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


-- 

Regards,

Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen