Re: Focus for payment standards

On 08/25/2011 12:06 PM, Pelle Braendgaard wrote:
> There are many different use cases for web payments. Here are just a few:
>
> - pay as you go for content, which is where I think most of the focus
> has been so far.
> - shopping carts
> - subscriptions
> - fund transfer via the web (remittences etc.)
> - invoicing/payments
> etc. etc.
>
> If we do a good job this standard can work these and 100s of other use
> cases that no one has even thought about yet.

Agreed. :)

> How do we do that?
>
> Lets try and analyze each of these use cases to find common areas first.
>
> Work on developing these common areas in such a way that they can be
> used either separately or together and then put them back together to
> provided recommended flows for each use case.

I agree that this would be a good approach to the problem. Keep in mind 
that we have a set of use cases here as well:

http://payswarm.com/specs/payswarm-use-cases

We also have the list provided by Steven Rowat that was sent to the W3C TAG.

> COMMON DENOMINATORS OF WEB PAYMENTS
>
> For web payments there is at least one common denominator of all the use
> cases, the simple payment.

True. Keep in mind that there is a spectrum of how one can handle and 
verify the simple payment - although, like you, I think that should be 
our primary focus. PaySwarm, as well as Open Transactions, seem to deal 
with the payment as a digital contract containing a signature. 
OpenTransact seems to push the digital signature to the OAuth layer, and 
I'd be very interested in hearing how that works when you have to verify 
a payment.

We seem to have a fairly wide swath of possibilities depending on how 
decentralized the system is supposed to become and where trust must 
exist in the system. For example, OpenTransact and PaySwarm require a 
certain level of trust at the Asset provider IRI, or the PaySwarm 
Authority. Bitcoin and Open Transactions require no trust at the "Bank", 
but do require everybody to have some piece of software that manages 
their private and public keys.

I have a feeling that we may need to nail this down over the next couple 
of weeks. Who you trust in the system seems to be one of the fundamental 
drivers of the design decisions made when building these systems. We 
have found that the more centralized that you make the system, the 
easier the implementation, and the more decentralized, the more difficult.

> Almost all will also need some kind of discoverability which is where
> the RDF and talk of directories come in.

Yes, this is also a big concern and is the reason we got involved in the 
RDFa work in the first place. PaySwarm currently doesn't rely on 
centralized directories and instead is capable of listing the assets and 
listings in a decentralized manner. We depend on RDFa to express assets 
for sale. Here is a sample Asset (in JSON-LD-like form):

http://purl.org/payswarm#Asset

and a sample Listing (in JSON-LD-like form):

http://purl.org/payswarm#Listing

Here is a page that contains both an asset and a listing:

http://recipes.payswarm.com/?p=8924

If you look at the source, you will see a digitally signed asset and 
listing expressed in RDFa. We can take this RDFa markup and generate a 
JSON-LD formatted asset and listing shown above. The underlying data 
model is RDF - if you want to describe the asset in an HTML page, you 
use RDFa. If you want to make a REST Web services call, you use JSON-LD. 
Both the RDFa and JSON-LD representations use the same digital 
signature, which means that the information can be expressed in both 
HTML and JSON without requiring different digital signatures.

That is, the information is cryptographically verifiable (a certificate 
of authenticity) in both HTML and JSON.

> In the OpenTransact lists we have recently started work on discussing
> what makes an offer and language surrounding it, this is also an
> important area that would be useful to many but not all of the above use
> cases.

In PaySwarm, being able to express assets and offers in a Web page is 
central to the design of the system. Instead of re-inventing how the Web 
works, we use the same publishing mechanism that has worked for millions 
of people around the Web - HTTP, HTML and JSON. We believe that we have 
the technical details of how to do this worked out, but of course, need 
input from the broader community at this point.

> I personally think fraud and DRM are separate issues that may be better
> discussed as best practices rather than standardized. But I may be
> wrong. If we do work on this it should like almost everything else be an
> optional building block in the standard.

I agree that DRM is a separate issue. Fraud is a tricky one... you have 
to make sure that people cannot perform fraudulent transactions with the 
system. For example, you have to make sure that not just anybody can 
post a digital contract to a service and withdraw money from your 
financial account. However, committing fraud by faking copyright 
ownership over a particular piece of content should be out of scope as 
that problem isn't easily addressed using technology. So, we need to be 
more specific about what we mean by "fraud".

> An initial list of items I think we need to for a web payment standard:
>
> - Value transfer ( core payment)
> - Discoverability of assets and payment methods
> - Offer creation and discoverability
> - Offer acceptance

This is a good list... let's use it as the starting point for our 
discussion on the upcoming telecon.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Uber Comparison of RDFa, Microformats and Microdata
http://manu.sporny.org/2011/uber-comparison-rdfa-md-uf/

Received on Sunday, 28 August 2011 19:26:02 UTC