- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Thu, 18 Oct 2012 14:27:33 -0400
- To: David Chadwick <d.w.chadwick@kent.ac.uk>
- CC: Ben Laurie <benl@google.com>, Henry Story <henry.story@bblfish.net>, "Klaas Wierenga (kwiereng)" <kwiereng@cisco.com>, "public-identity@w3.org" <public-identity@w3.org>, "public-philoweb@w3.org" <public-philoweb@w3.org>, "saag@ietf.org" <saag@ietf.org>, "public-webid@w3.org" <public-webid@w3.org>, "public-privacy@w3.org" <public-privacy@w3.org>
- Message-ID: <50804A15.8030701@openlinksw.com>
On 10/18/12 2:17 PM, David Chadwick wrote: > > > 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 David, Correct! My apologies for misunderstanding the position you were taking :-) Kingsley > > 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
Attachments
- application/pkcs7-signature attachment: S/MIME Cryptographic Signature
Received on Thursday, 18 October 2012 18:27:58 UTC