Re: Some ideas abouth web payment architecture

On 2015-01-15 19:38, Antonio Ruiz Martínez wrote:
> Hi Anders,

Hi Antonio,

>
>
> 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 :)

Just a short return here.  IMO, a universal payment API or framework
would need to standardize quite a bunch of things in order to be worthy
the title "standard".  I think that even this group would have huge
difficulties uniting on messages and security solutions.

Regarding security I believe the solution must be on par with Apple Pay
and that's out of scope for the Web Payment CG since it requires
control of the device including the CPU and OS.  Maybe like this:
http://webpki.org/papers/SKS-KeyGen2_FullStack.pdf

Anders

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

Received on Thursday, 15 January 2015 19:53:37 UTC