Re: Some ideas abouth web payment architecture

Hi Anders,


El 14/01/2015 a las 15:26, Anders Rundgren escribió:
> 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?

A pleasure to comment different approaches :)

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

Yes there are many variables. But, from my point of view, the work of 
this group like others (such as in e-signatures) is to define a 
rationalisated framework that limits the exponential growth. 
Furthermore, the use of payment modules that implement the generic 
payment web API would hide this complexity. Thus, for a web developer 
who wants to support different payment systems in its web shop, the 
invocation would be the same. On the other hand, for the payment systems 
providers suppose to create a module that support this API (in its 
simple form could be a wrapper of the current development) and that 
could hide the complexity that you mention.

>
> PKCS #11 is actually a great example.

Sure.

>It is not a core of Windows, iOS,
> OS/X or Android

PKCS#11 could be use in a number of solutions such as Thunderbird 
(Windows/Linux), Firefox (Windows/Linux), OpenSC, etc.

It is not core of Windows or OS/X because both Microsoft and Apple 
decided not to adopt it. They decided to define their own new solution 
to the same problem. Thus, Microsoft developed CAPI/CSP and CNG, Apple 
for OS X has it own (CDSA?). Then, all of them agree that we need this 
kind of API for cryptographic devices: they have developed their own API 
for solving the same problem. However, they do not want to agree the 
definition of this common API. Result: the support of a cryptographic 
device for different OS is a headache (although at the end some 
developers develop the PKCS#11 and then, in base to this module, they 
create the CSP).

The success or not this kind on API in this group will depend on whether 
the main stakeholders are interested in agree this kind of API or not.


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

I agree in the reusable components indeed. The payment module of each 
payment system according to the generic API is a reusable module to be 
used in different browsers. Also as you mention in your proposal the 
definition of trust mechanisms is fundamental so that the user can be 
sure whether the payment module installed is safe or not.

Best regards,
Antonio.

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

-- 
--------------------------------------------------------
Antonio Ruiz Martínez
Department of Information and Communications Engineering
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
http://ants.inf.um.es/~arm/ or http://webs.um.es/arm/
e-mail: arm@um.es or arm [at] um [dot] es
--------------------------------------------------------

Received on Thursday, 15 January 2015 18:39:15 UTC