W3C home > Mailing lists > Public > public-webpayments@w3.org > September 2014

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

From: Anders Rundgren <anders.rundgren.net@gmail.com>
Date: Tue, 23 Sep 2014 07:12:24 +0200
Message-ID: <54210138.60305@gmail.com>
To: Kingsley Idehen <kidehen@openlinksw.com>, public-webpayments@w3.org
On 2014-09-22 21:15, Kingsley Idehen wrote:
> On 9/22/14 11:32 AM, Anders Rundgren wrote:
>> On 2014-09-22 13:16, Kingsley Idehen wrote:
>>> On 9/22/14 2:31 AM, Anders Rundgren wrote:
>>>> I'm by no means an enemy to Linked Data, I just don't see what it
>>>> would do for *conventional* payments except for introducing privacy
>>>> and access control concerns.
>>> Please take time to digest:
>>> [1]
>>> http://bit.ly/enterprise-identity-management-and-attribute-based-access-controls
>>> [2]
>>> http://bit.ly/loosely-coupled-read-write-web-and-web-access-controls-using-webid
>>> .
>>> You cannot make a moderately usable system without an identification
>>> mechanism that isn't yet another data silo.
>>> *conventional* payments are an application of data driven
>>> identification, interaction, and management.
>> My only ambition has been describing how you could "webify" an
>> existing payment system,
>> *without* changing data ownership, relationships, business-, trust-,
>> or privacy-models.
> You can't achieve that goal, in any non contradictory way, if you've
> somehow convinced yourself that Linked Open Data and Webify aren't
> inextricably linked.
> "*without* changing data ownership, relationships, business-, trust-, or
> privacy-models." is just another way of saying: structured data
> representation + entity relationship semantics, without
> data-silo-fication. That's exactly what RDF based Linked Open Data is
> fundamentally about, period [1].
>> Since the main problem with identity information is not the
>> information itself but
>> how it will be used after being submitted, it seems like a safe(r) bet
>> minimizing
>> exposure of such data.
> Linked Open Data never means "uncontrolled or unconstrained access to
> data" [1].
>>    This is a corner-stone of my write-up.  Another example is
>> FIDO which (at least on paper...) is the opposite to Linked Data since
>> each site
>> is supposed to be an identity silo.  In practice FIDO doesn't work as
>> Google claims
>> but that's altogether different discussion :-)
> You can conditionally constrain access to data using data access policies.

Yes, but if there is a way getting away from that by for example doing
what my write-up does (encrypting the user's response and identity so that
it is only readable by the sole party that needs it), I think it is worth

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:


> [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
Received on Tuesday, 23 September 2014 05:13:12 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:03:39 UTC