Re: Unlinkability. Re: Building Linked Data into the Core of the Web

On 9/27/14 2:53 AM, Anders Rundgren wrote:
> On 2014-09-24 14:09, Kingsley Idehen wrote:
>> On 9/23/14 1:12 AM, Anders Rundgren wrote:
> <snip>
>>
>> You don't need to encrypt a subject's identity. Just as you don't need
>> deeply personally identifiable data in a security token e.g., and X.509
>> cert.
>
> In this particular demo, the user has at least a credit-card identity.
> If you are going to shield the merchant from this information (and only
> return a payment token a la EMV tokenization) you have two options:
> 1. Having the client go to the bank and collect the token and hand
>    it over to the merchant.
> 2. Encrypt the client's data and push it through the merchant which
>    in turn talk to the bank.  This is the scheme I implemented.
>
> Version #2 has several advantages because it saves one network round
> and also delegates the final operation (the actual transaction) to the
> merchant which is logical and more reliable than using the client
> as middleman.
>

This is fine. That's how I would expect a "zero knowledge" system to work.

>>
>> When you purchase a Ticket [1] for an event, does that ticket contain
>> personally identifiable data that goes beyond enabling the ticket-holder
>> attend an event? Does the event organizer know the name, home address,
>> email address etc.. of the ticket-holder at row #7 seat #2 ?
>>
>> A ticket is like a security token, and vice versa.
>
> Yes, this is also what the demonstrated scheme does.  But the steps 
> before
> you get the ticket ("PaymentToken" in the state diagram) are those that
> I primarily cater for.

Yes, and all I did was show you the description of a Ticket in Linked 
Data form. As I've said from the get-go, Linked Data isn't an issue here :)

>
> Cheers
> Anders
>
>>
>> Links:
>>
>> [1] http://linkeddata.uriburner.com/c/9G36GVL -- About Ticket .
>>
>> Kingsley
>>>
>>> Anyway, since my write-up is fairly complete, would it be possible 
>>> to get
>>> concrete input on how it could be improved by adding Linked Data or do
>>> we always have to start from zero?
>>>
>>> BTW, I think this is VERY important because I'm surely not the only one
>>> out there who do not necessarily understand what the WebPayments CG
>>> is saying.  Personally, I think it would be quite useful if somebody
>>> did a simple write-up of how *they* would address credit-card payments
>>> on the web because then we would have something to compare with. If we
>>> are lucky we may even find a way combining the old and the new :-)
>>>
>>> If nothing helps we will surely go into the black:
>>> https://www.youtube.com/watch?v=0O1v_7T6p8U
>>>
>>> Cheers
>>> Anders
>>>
>>>>
>>>>
>>>> [1]
>>>> http://bit.ly/enterprise-identity-management-and-attribute-based-access-controls 
>>>>
>>>>
>>>> -- presentation that covers Linked Open Data and Attribute based 
>>>> Access
>>>> Controls working in tandem.
>>>>
>>>>
>>>> Kingsley
>>>>>
>>>>> Anders
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> Your point is inherently contradictory.
>>>>>>
>>>>>> -- 
>>>>>> Regards,
>>>>>>
>>>>>> Kingsley Idehen
>>>>>> Founder & CEO
>>>>>> OpenLink Software
>>>>>> Company Web:http://www.openlinksw.com
>>>>>> Personal Weblog 1:http://kidehen.blogspot.com
>>>>>> Personal Weblog 2:http://www.openlinksw.com/blog/~kidehen
>>>>>> Twitter Profile:https://twitter.com/kidehen
>>>>>> Google+ Profile:https://plus.google.com/+KingsleyIdehen/about
>>>>>> LinkedIn Profile:http://www.linkedin.com/in/kidehen
>>>>>> Personal
>>>>>> WebID:http://kingsley.idehen.net/dataspace/person/kidehen#this
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>


-- 
Regards,

Kingsley Idehen 
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog 1: http://kidehen.blogspot.com
Personal Weblog 2: http://www.openlinksw.com/blog/~kidehen
Twitter Profile: https://twitter.com/kidehen
Google+ Profile: https://plus.google.com/+KingsleyIdehen/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen
Personal WebID: http://kingsley.idehen.net/dataspace/person/kidehen#this

Received on Sunday, 28 September 2014 00:38:38 UTC