Re: [saag] Liking Linkability

On 10/21/12 3:52 PM, Nathan wrote:
> Kingsley Idehen wrote:
>> On 10/21/12 6:22 AM, Nathan wrote:
>>> Ben Laurie wrote:
>>>> I'm getting quite tired of this: the point is, you cannot achieve
>>>> unlinkability with WebID except by using a different WebIDs. You made
>>>> the claim that ACLs on resources achieve unlinkability. This is
>>>> incorrect.
>>>
>>> You're 100% correct here Ben, and I'm unsure why it's so hard to 
>>> convey!?
>>>
>>> If you use the same identifier for more than one request, subsequent 
>>> requests can be associated with the first request. An identifier 
>>> here is any identifying, stable, information - key parts and URIs.
>>>
>>> If the issue is only unlinkability across sites, then you just have 
>>> a keypair+uri per site. Or better, key-pair only, and that's 
>>> associated with an identifier for the agent behind the interface.
>>>
>>> You're correct that ACLs won't cut it.
>>>
>>>
>>>
>>>
>>>
>> Nathan,
>>
>> What is the subject of unlinkability ?
>>
>> I am sure you know that Henry and I are fundamentally referring to 
>> nebulous real-world entities such as "You" and "I". A composite key 
>> of: machine name, user agent name, and a document referrer links != 
>> said neboulus entity. Even further away in today world of multiple 
>> form factor devices that interact with the Internet and Web.
>>
>> There is no precise mechanism for electronically nailing down 
>> nebulous entity "You" and "I". We aren't of the Internet or Web, so 
>> you can apprehend us in person. At best you can speculate that we are 
>> the subjects of tokens comprised of composite keys.
>>
>> Unlinkability is subject to context fluidity and temporality once you 
>> add neboulus congnitive entites (not of the Web or Internet) to the 
>> equation. I believe you know this anyway :-)
>
> We cannot say that a URI refers to "you" or "I" in one breathe, and 
> say it doesn't (or may not) in another.

You raise a good point, Now let me clarify, I don't believe (unless in 
utter error) that I've ever claimed that a URI definitively refers to 
"You", "Me", or "I". Of course, I cannot claim to have not made the 
careless utterances such as "Your Personal URI" , for instance.

A URI that serves as a WebID has always been a denotation mechanism for 
a composite key comprised of:

1. private key
2. public key
3. URI that resolves to a profile document that describes a subject via 
an entity relationship graph.

The subject of an X.509 certificate is a nebulous entity. This entity is 
associated with attribute and value pairs that comprise the profile 
graph imprinted in said certificate. The semantics of an X.509 
certificate don't change the nature of the certificates subject.

>
> There is a use case which provides a technical requirement here, one 
> which is simply to not use identifiable information between requests 
> to different origin servers, and sometimes more granular, not using 
> the same identifiable information between requests to the same server.
>
> WebID, just like any auth protocol can be used, it just means using it 
> on a one time basis, or only for a particular origin.

WebID is a part of the picture, not the picture in its entirety. I've 
pretty much tried to encourage others to be careful about conveying the 
misconception that WebID (solely) resolves the issues at hand. It is 
just a critical piece of the puzzle, that's it.

You don't need to have a single WebID. Such a thing fails the most 
mundane alter ego test re. 'Clarke Kent' and 'Superman' or 'Peter 
Parker' and 'Spiderman'.

Privacy is about the aforementioned personas not being comprised, under 
any circumstances. The fact that DC world entities 'Clark Kent' and 
'Superman' used the same Web browser shouldn't comprise the alter ego 
relationship between these personas.

Unlinkability is about the alter ego paradox.

>
> Personally I feel there are still questions here with WebID, as 
> currently people use usernames/emails and passwords almost everywhere, 
> and they can pick different usernames/emails/passwords on every 
> site/origin. Suppose WebID was to gain 100% adoption overnight, we'd 
> suddenly be in a position where everybody usually used the same 
> identifier (rather than usernames and email addresses) and the same 
> key (rather than multiple passwords) - because we've never been in a 
> world like that, we don't know the consequences yet.

See my comments above. Such a system is dead on arrival re. privacy. 
There have to be multiple WebIDs and the exploitation of logic when 
dealing with data access policies, and all of this has to occur within 
specific interaction contexts. For instance, if I want only you to see a 
document, I could knock up the require security tokens and send them to 
you via a PKCS#12 file. You open the file then go GET the document in 
question. Being super paranoid, I would more than likely speak to you 
via phone about the username and password combo for opening up the 
PKCS#12 file.
>
> Thus, when security and identity experts suggest that we need to 
> handle unlinkability, or consider that we may often need per origin 
> WebIDs (or even have that as the default mode), then we may be wise to 
> say "okay", go away and find our options, then report them back for 
> consideration and review.
>
> It by no means limits WebID, rather it just makes it applicable to a 
> broader range of use cases.

We need others (note: expert is utterly subjective to me) interested in 
these matters to be constructive rather than dismissive. I chime in most 
of the time because I see Henry going to immense pains to explain 
matters only to be summarily dismissed in manners that I find 
cognitively dissonant.

A basic RDBMS product doesn't depend on single attribute/field primary 
keys, why would such thinking even apply to the complex matter of 
privacy. When I use the term composite, I am pretty much referring the 
the same concept well understood in the RDBMS world. You can have a 
'super key' comprised of elements that are of themselves unique 
identifiers.

I don't believe in a single WebID neither does Henry. We just believe 
that Web-scale verifiable identity is a critical part of the required 
infrastructure. We also believe that a de-referencable URI (e.g., an 
HTTP URI) is a very powerful vehicle for this endeavor, even more so 
when combined with structured data and first-order logic.

I only know of one way to deal with context fluidity at the software 
level, and that's via logic integrated into data which produces self 
describing data objects .
>
> Best as always,
>
> Nathan
>
>
>
>


-- 

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