- From: Ben Laurie <benl@google.com>
- Date: Mon, 22 Oct 2012 10:54:35 +0100
- To: nathan@webr3.org
- Cc: Kingsley Idehen <kidehen@openlinksw.com>, Henry Story <henry.story@bblfish.net>, Ben Laurie <ben@links.org>, "public-philoweb@w3.org" <public-philoweb@w3.org>, "public-identity@w3.org" <public-identity@w3.org>, "public-privacy@w3.org" <public-privacy@w3.org>, Sam Hartman <hartmans-ietf@mit.edu>, "public-webid@w3.org" <public-webid@w3.org>, "saag@ietf.org" <saag@ietf.org>, Melvin Carvalho <melvincarvalho@gmail.com>
On 22 October 2012 10:42, Nathan <nathan@webr3.org> wrote: > Kingsley Idehen wrote: >> >> 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 . > > > I agree on all counts and feel/think the same, So do I, more or less (except the last sentence, which I don't think I really understand, and if I do, seems too sweeping), which surprises me. > so I think I'll need to go > and re-read this thread and see where the confusion is. Possibly something to do with the fact that of all of Kingley's posts so far this is the only one I haven't found either incomprehensible or wrong. Where we came in was me pointing out that if you disconnect your identities by using multiple WebIDs, then you have a UI problem, and since then the aim seems to have been to persuade us that multiple WebIDs are not needed. > > Best, Nathan
Received on Monday, 22 October 2012 09:55:07 UTC