Re: [saag] Liking Linkability

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