Re: Call for Single Media Type Design for Payments

Manu:

good to see your reply.

CODE, NOT MESSAGES
The mozilla articles are interesting for those who want to review the
*code* for enabling payments, but I find those articles underwhelming when
it comes to understanding how *messages* are used to express payment data
and actions. I know there are many folks focused on the code but, IMO, that
is an implementation detail. There will be very many "code models" for
handling payments (as many as there are languages, frameworks, and
operating environments) but, for things to work well, they will all use the
same "message model." That's the item I am focused on ATM.

JSON-LD and Hypermedia
2) While I find JSON-LD very good at expressing object models, I find it
quite lacking in expressing actions. In the specs examples you cite, I am
unable to find anything that describes the action to take, the protocol
details, the arguments to pass, and the expected results. I think this is a
serious problem for the spec family. I'd be interested in seeing how
leveraging Hydra[0], RDF:FORMS[1], or other specifications could fill in
the missing action desrciptions.

HTTP-ONLY CRUD
I understand that the current habit is to instruct client developers to
_assume_ a single protocol (HTTP) and _assume_ a limited set of methods on
that protocol (GET, PUT, POST, & DELETE) and to also _assume_ all of these
actions are possible at all times. I also understand there is nothing in
the responses that tells client developers which arguments are used with
which methods and which objects. This, IME, results in hard-coding these
assumptions into client apps and leaves these apps vulnerable to
malfunction when the servers change the rules on protocol, arguments, and
return state. If these assumptions on my part  are incorrect, feel free to
point me to the specs that show how servers can communication this
information at runtime.

XMPP and WebSockets
In the long term, I think linking the entire spec to a single protocol
(HTTP) and a small set of methods therein is problematic. I can easily
imagine a time when servers and clients will want to use XMPP or WebSockets
and then the baked in assumptions here will not apply. I like the current
of focus here on a payment vocabulary since that can be format and protocol
agnostic. But I am (again) missing the "action" details and instructions on
how those are described in responses.

RDFa and GET/POST
I see references to RDFa[2] and it is not clear to me how the base
interaction assumptions (esp. regarding PUT and DELETE) are to be handled
consistently when using HTML+RDFa. IME, HTML+RDFa is either relegated to a
read-only experience or client developers have to rely soley on scripted
HTML to interact via the spec. Is that the case here? or is HTML's GET/POST
considered compliant?

DANGER OF OVER-SPECIFYING STATIC CONTRACTS
For example, i see code references (e.g. onlick="doPurchase") in HTML+RDFa
samples[3], but am not able see where the arguments and protocol details
are expressed in the message. Am I to assume that the Purchasing
Algorithm[4] is the only possibly way to execute a purchase? That all
clients and servers will ONLY use these arguments? in all cases? for all
time? This seems very limiting and, in the long term, short sighted.  I
think you'd do better to describe the machine-readable way clients and
servers communicate interaction specifics rather than defining the
exact interactions themselves.  This will result in a more flexible and
more stable spec that can accommodate changes over time and variances
between payment vendors w/o the need to alter client apps to "know" each
variant. This was one of the key successes of the VoiceXML[5] spec I
referred to earlier.

Finally, I mention these things here only in an effort to help improve the
functionality and reach of the payments system. I appreciate the chance to
post my POV and am more than happy to discuss these items further. I also
appreciate that you've been at this for close to 1/2 a decade and may not
be interested in opening a new line of discussion.

Cheers and best of luck to all.


[0] http://www.markus-lanthaler.com/hydra/
[1] http://www.markbaker.ca/2003/05/RDF-Forms/
[2] https://web-payments.org/specs/source/web-commerce/#html-rdfa
[3] https://web-payments.org/specs/source/web-commerce/#the-purchase-process
[4]
https://web-payments.org/specs/source/web-commerce/#the-purchase-algorithm
[5] http://www.w3.org/TR/voicexml20/



mamund
+1.859.757.1449
skype: mca.amundsen
http://amundsen.com/blog/
http://twitter.com/mamund
https://github.com/mamund
http://linkedin.com/in/mamund


On Tue, Dec 31, 2013 at 1:52 PM, Manu Sporny <msporny@digitalbazaar.com>wrote:

> On 12/28/2013 05:03 PM, mike amundsen wrote:
> > Think of this as a kind of "HTML" for payments. A single payments
> > media type would be able to express all the payments vocabulary
> > (data) and handle all the possible use cases (actions).  Client apps
> > would only need to "recognize" the data and actions and could work
> > with any server regardless of the data that appears in a response or
> > the order of the actions for any server.
>
> Mike, Steve, Anders,
>
> This is very close to the design behind many of the specs that this
> group is working on. The markup mechanism is JSON-LD, which uses a
> payments vocabulary to express assets (things for sale), listings (the
> terms under which a sale can occur), and digital receipts (the result of
> a transaction).
>
> You operate on these documents by just using standard HTTP action verbs
> (GET / POST / DELETE / PUT / etc.).
>
> If you haven't already read these articles, they may help you understand
> how everything fits together (currently, anyway):
>
>
> https://hacks.mozilla.org/2013/04/web-payments-with-payswarm-identity-part-1-of-3/
>
> https://hacks.mozilla.org/2013/04/payswarm-part-2/
>
>
> https://hacks.mozilla.org/2013/04/web-payments-with-payswarm-purchasing-part-3-of-3/
>
> Mike, we can do all of this without the need for a mimetype by using
> just plain 'ol JSON-LD. Here's how you'd describe an item for sale, for
> example:
>
> https://web-payments.org/specs/source/vocabs/payswarm#Asset
>
> or the terms under which it can be sold:
>
> https://web-payments.org/specs/source/vocabs/payswarm#Listing
>
> or the digital receipt of sale:
>
> https://web-payments.org/specs/source/vocabs/payswarm#Contract
>
> We could create a mimetype, but it's largely unnecessary.
>
> I'll leave this here for now, don't know if you were aware that we're
> already well down this road (and headed down it almost 4+ years ago).
>
> -- manu
>
> --
> Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
> Founder/CEO - Digital Bazaar, Inc.
> blog: The Worlds First Web Payments Workshop
> http://www.w3.org/2013/10/payments/
>
>