Re: [saag] Liking Linkability

and if the user puts his/her email address attribute in the U-Prove token???

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

Received on Thursday, 18 October 2012 16:57:08 UTC