Re: Some ideas abouth web payment architecture

Hi Antonio,
There are indeed folks who work (and promote) the idea of a universal payment API.

I hope you don't mind a disbeliever (heretic) responding as well?

IMO there simply too many parameters involved for making a payment API
manageable and understandable, not to mention getting the actual payment
networks to agree on anything.

On top of my head I see variables like

- Formats of messages (XML, JSON etc)
- Vocabulary of messages
- Securing messages
- Message flows
- User interface-related things

as major hurdles; each of them actually :-(
Combining them would be exponentially more difficult!

PKCS #11 is actually a great example.  It is not a core of Windows, iOS, OS/X or Android
in spite of cryptographic operations being technically well-defined since EONs of time back
(as a crypto-user I have BTW found out that stuff like Google's U2F isn't supportable
by none of the existing APIs including PKCS #11 which shows the awkwardness of API
standardization).

So what you could do is creating a very high-level (and abstract)
"framework" that indeed could address the entire spectrum of payments.

My objection to that is simply: What does this bring to the table except
a lot of work?

So what's the "Right Solution(TM)" then? I can only speak for myself but
I still think that reusable components and core technologies are more
important given the current state of things.  The W3C have nothing
addressing: http://webpki.org/papers/web-browser-security-enigma.pdf
so there's a lot of hard and difficult work to do if you want.

Regards,
Anders

On 2015-01-13 17:19, Antonio Ruiz Martínez wrote:
> Hi all,
>
> I have some news of this project recently. Then, I have started to read
> the different documents you published.
>
> I made some research on this topic and I have some ideas that I would
> like to share in case they could be useful.
>
> They where published through two articles that you can find in:
>
> [1] Payment frameworks for the purchase of electronic products and
> services. Computer Standards & Interfaces 34(1): 80-92 (2012)
> A draft can be found in:
> http://ants.inf.um.es/~arm/PayFrameworks.pdf
>
> [2] “Design and implementation of a generic per-fee-link framework”.
> Internet Research, vol. 19, no. 3 (2009) 293-312.
> A draft can be found in:
> http://ants.inf.um.es/~arm/PaperEPP.pdf
>
> To sum up the ideas (some of them I have seem that are already
> considered in the project) that we consider:
>
> 1) The access to a payment-based service/product should be based on a
> special URL. For example, instead of http://resource something like
> phttp://.... This URL should be annotated with semantic information that
> easy the payment process.
>
> 2) I think that the definition of a payment-indepedent API is
> fundamental. There are other models that we could use as inspiration.
> For example, the PKCS#11 interface hides the complexity of the
> cryptographic device we are using. In my case, I mean to model any
> payment protocol as a finite state machine. Another approach could be
> based on the kind of transaction (payment, refund, etc).
>
> 3) I think I good idea for making payments could be have a
> session-oriented protocol. This protocol would be used to negotiate
> payment mechanisms, make the payment, to exchange additional information
> such as receipts or loyalty information and to make additional
> (repeated) payments in the same way. Besides, following this idea the
> protocol could be used to make payments on the Web or any other
> environments not based on HTTP.
>
>   From now on I would try to participate in the different documents you
> are working.
>
> Just my two cents.
>
> Best regards,
> Antonio.
>
>
>

Received on Wednesday, 14 January 2015 14:26:57 UTC