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

Re: Payments and Trust

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Wed, 26 Sep 2012 20:39:59 -0400
Message-ID: <5063A05F.7000504@digitalbazaar.com>
To: "public-webpayments@w3.org" <public-webpayments@w3.org>
On 09/23/2012 02:59 PM, Amir Taaki wrote:
> Anyway the purpose of this rant is that if we use trust networks for 
> payments, then you better be sure that your trust network is pretty 
> fucking solid. If it can be gamed, then people will put in insane 
> hours to do it for $1 or less. I like the idea of thinking about
> them in terms of sets of overlays, but I feel like perhaps there
> might be more to this story. Perhaps there is a way to describe the 
> relationships between overlays in a set. Or maybe the way nodes in 
> this directed graph weight the trust values that aggregate along 
> them.

This.

We (Digital Bazaar) has been thinking about the trust issue related to
payments for quite a long time. At present, we've conceived of a number
of ideas, but nothing that we would want to depend on as an automatic
part of the transaction process. Trust is not only variable between the
type of operation you're attempting to perform (buy a piece of digital
music from an unknown vendor), it can also be variable based on /who/ is
doing the purchase and /who/ is doing the selling and /what/ is being
exchanged. The saying "Honor among thieves" captures this trust issue
quite well. You can't trust a thief, but some thieves trust each other.

I do think that there is a technology solution for the Web Payments
problem (creating an open, decentralized, payment mechanism for the
Web). I do not think that there is a technology "solution" for the trust
network problem because it is constantly evolving. That is, your trust
network is only good until it gets gamed. Building something that is
game-proof is going to have to be an iterative, long-term effort. An
effort that has no end. It's certainly something worth attempting, but
definitely not something that should be standardized at any point in the
near future.

That said, one of the reasons PaySwarm utilizes URIs for 'Identities'
and JSON-LD to represent information is precisely because of the unknown
nature of the trust problem. The same goes for the payments problem. We
assume that we're not going to get it right the first time, or the
second time, or the third time. You need flexibility in the system to
change over time and URIs and Linked Data empower you to do that.

So, here's what we have in PaySwarm so far that can be applied to make
good in-roads on the trust network problem:

1. People and Organizations can have multiple identities on PaySwarm.
   For example: https://dev.payswarm.com/i/manu
2. Information about that identity can be expressed as Linked Data on
   the site where the identity exists, and on any other site on the Web.
3. Anybody on the Web can make statements about the identity above.
   These statements can include praise, complaints, referrals, and a
   variety of other "signals" that can help an individual decide
   whether or not to transact with the other party.

Given the above, we've been thinking of making PaySwarm Authority
software be able to vouch for identities on the network. For example:

* This identity has performed 104 successful transactions.
* This identity has had 4 complaints logged against it.
* This identity has performed $5,400 worth of transactions without
  complaint (dangerous privacy implications).
* This identity has performed at least 100 transactions in the
  price range that you are about to exchange. 98% of those
  transactions happened successfully and without complaint.

We want to do this in a Web-y way, for example, here's the JSON-LD
expressing the last bullet item above:

{
  '@context': 'http://purl.org/payswarm/v1',
  'id': 'https://dev.payswarm.com/i/manu',
  'price': {
     'amount': '25.00',
     'currency': 'USD'
  },
  'priceVariance': '5.00', // acceptable % variance in price above
  'transactionCount': 100,
  'transactionSuccessRate': '98.0' // % of successful transactions
}

It'll be easier to put this together after we have some good live data
in the system.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Which is better - RDFa Lite or Microdata?
http://manu.sporny.org/2012/mythical-differences/
Received on Thursday, 27 September 2012 00:40:31 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 27 September 2012 00:40:31 GMT