Re: Call for Single Media Type Design for Payments

Hey Mike, sorry for the delay, responses to your thoughts on messages:

On 12/31/2013 03:45 PM, mike amundsen wrote:
> 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.

Right, and the Mozilla articles don't go into depth about that. Here is
some information on the messaging model:

I'm not saying that they're fully baked at all, but it should give you
some idea of the sorts of payment messages that pass over the network.

> 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.

Hydra is an option, but the "action" you take with the message depends
entirely on exactly what you want to do with the message and which
system you want to process it through. A message in the system can be
processed by more than just one payment processor (because they're all
theoretically interoperable).

In general, I think we're open to things like Hydra as long as it makes
sense to use Hydra to express the hypermedia API. The reason we don't
have that in there is that 1) we've been able to get what we need to get
done w/o Hydra, and 2) it's not clear what integrating Hydra would
achieve (other than making the protocol more theoretically pure).

If you could drop an example in this conversation, we could use that as
a starting point.

> 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.

Could you provide some examples of the alternative? I could try and
generate something, but it would be better for you to put forward an
example that reflects what's in your mind.

> 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.

There's nothing that I can think of that prevents this protocol from
being adapted to WebSockets or XMPP, per-se... I'm just struggling to
understand why someone /would/ run the payment messages over those
less popular/used protocols because:

1. They're going to have to use HTTP at some point to access some of
   the payment/identity/banking information.
2. You're not going to be interoperable with the people running
   the payments over HTTP.
3. You're going to be using a protocol that isn't as widely deployed
   and understood as HTTP.
4. It would fragment the protocol that the payment messages run over.

That said, I think it's important that the payment messaging protocol is
capable of running over other lower-level transport protocols. If
someone wants to try to tackle that work, great - we really need some
help in that area because we're stretched pretty thin as it is. One
thing that would be helpful is to point to where VoiceXML is run over
two different protocols (where that was considered a good thing -
performance, cost savings, etc).

> 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?

HTML+RDFa is strictly a read-only experience... it's only used to read
assets and listings from a page. We're considering removing it.

The reason we haven't yet is because it may be that sites can't modify
their code to do content negotiation. Google's infrastructure is a good
example of this - a number of their sites (including can't
content negotiate (for a variety of scalability/legacy reasons). So,
while their web developers can dump HTML+RDFa into their pages, they
can't necessarily content negotiate for JSON-LD descriptions of
products, listing, assets, services, etc.

There is no "scripted HTML" requirement. The page you get back better
have HTML+RDFa in it w/o any Javascript or the client isn't going to be
able to read the product information off of the page.

There is a part of the JSON-LD specification that allows you to embed
JSON-LD in HTML... we may use that instead of HTML+RDFa since it would
remove the requirement for an HTML+RDFa processor. That said, this part
of the spec is only for reading asset / listing data from HTML pages
that describe the item for sale.

> 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.

Yes, that would be very limiting and short sighted. That's not how it
works. :)

That's probably our fault as that section is /really/ old and needs to
be updated. All interaction (so far) is based on REST interactions. So,
that "doPurchase()" call constructs a purchase request and sends it off
to the buyer's payment processor (in a standard message format over
HTTP). The payment processor (or buying software) then reads the asset
from that URL and provides the buyer with a description of the item
(after reading the HTML+RDFa from the vendor's page).

So, I think it works like you want it to, modulo the HTTP requirement.
The implementation of doPurchase() is up to the web developer as long as
the request that is sent to the payment processor is compatible with the

> 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.

I think I know what you're saying, but it's still a bit vague. What
would "communicating interaction specifics" mean in a concrete sense?
Could you throw a few examples in here?

> 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.

Thanks for the input, and it's very much appreciated. I think we're
already doing some of what you're saying, and for the bits that I'm not
quite sure, it's certainly worth exploring. We're interested in doing
the right thing, and if it means that we've made a mistake, we should
correct that ASAP before moving forward. I think it would be foolish of
us not to. :)

Feel free to drop into the weekly telecon to discuss in a more
high-bandwidth way if you'd like. We can put aside time for that if you
think it would be helpful.

-- manu

Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: The Worlds First Web Payments Workshop

Received on Monday, 13 January 2014 20:27:23 UTC