<manu> dsr: We may also want to cover the security diagrams that Erik sent out.
<padler> https://dvcs.w3.org/hg/webpayments/raw-file/default/latest/payment-agent/index.html
<manu> https://dvcs.w3.org/hg/webpayments/raw-file/default/latest/payment-agent/index.html
<Istvan> I am on mute
Patrick summarises the agenda. He has updated the payment agent document for sections 2 and 3
… following feedback in last week’s call.
<Zakim> manu, you wanted to say he likes the diagram
Manu: I really like the diagrams, they summarise all the information we would expect.
We may want to group the interfaces as a way of simplifying the document
<padler> +1
Joerg: I have yet to read the document through and wanted to clarify that there could be many payment agents sitting in a wallet, right?
Patrick: a wallet might implement a payment agent, but a payment agent could also be a point of sales terminal
Joerg: so it is more a systems view
Patrick: last week’s diagrams may help explain the change
Are P1-N something they are required or are that optional?
Patrick: this is just a framework. The services that are required depends on the use cases.
The standards you need to follow depend on the selected payment instrument.
<Zakim> manu, you wanted to ask if the Payment Agent is a 'router' or an 'endpoint'
Manu: one thing missing from the diagrams is how messages are routed from the app to the selected payment instrument
I want to better understand what is doing the routing
Patrick: I totally agree, the 3rd diagram provides some answers
Cites restaurant scenario where several different payment instruments may be used. I called the routing function a “payment relay”
This gets more interesting when you have a group dinner and they all want to pay individually.
<manu> dsr: The model I've been thinking of - routing to the wallet itself - browser can manage that. Then there is the routing to the selected payment instrument.
<manu> dsr: We talked about native apps - local web apps - remote web apps. By defining these APIs at a level above that, the stuff underneath can be separated off.
<manu> dsr: We need to figure out the proper layering.
Patrick: you’re right, and the one I focused on is an ecommerce example.
Sally is shopping and selects what she wants to buy (online) and wants to apply a discount coupon she has.
The website would return an invoice to the browser/app. When you interact with it a wallet is located (e.g. Cloud Co in this example).
The payment details would then be passed through the wallet to the payment instrument.
… after the use has selected which one to use. Once the payment dialogue completes along with transaction a proof of payment is passed back to the merchant and to the webapp.
Joerg: this is nice and thorough, but is perhaps making our life a little harder than it needs to be.
I would propose that we stick with what we need to do for the browser/web app and later study what changes if any are needed for use with payment terminals
<Zakim> manu, you wanted to discuss "solving the whole problem"
Manu: I understand what Joerg is saying, and
partially agree, but at the same time, we want people to pick up our
work and see it through. Experience has shown that starting form one
scenario and later extending to others tends to hit scaling problems.
... I also agree with Dave about the need to figure out the layering
We don’t have to solve the whole problem, but do need to check for road blocks
How do we route the requests through the browser or through the NFC context.
<jheuer> Create a comprehensive abstract view: OK for me
Joerg: this is okay for me. We should check that the abstract description works across contexts and later drill down to specific technologies.
Patrick: yes that is absolutely right. If we just start with the abstract view we risk missing something, so looking at a few concrete examples and looking for what breaks.
Dave agrees and that’s where the simple user narrative are rather effective.
It doesn’t cost much effort to translate these into more detailed technical accounts.
<jheuer> Could we call the 'abstract view' a 'reference architecture' rightfully?
<Zakim> manu, you wanted to provide an abstract example that doesn't work.
Manu: I agree with what Patrick says. We can create the abstractions in a variety of different ways. One is via the browser scenario. Another is via an NFC scenario. We wouldn’t want to put the browser in control in the NFC case.
Another example is where the operatig system routes messages. This again isn’t great for the browser scenario when the payment agents are in the cloud.
<jheuer> Routing to the cloud could be a job for the payment agent
Dave: the wallet can play the message routing role at an abstract layer perspective.
Patrick: HTTP was successful as it isn’t restricted to the browser. We need to define what information has to be transferred and make this independent of the bearer protocol.
Other groups can define this binding to the underlying protocols.
<Zakim> manu, you wanted to note that the data format and the HTTP protocol are probably easier than the 'routing' (which is an unsolved problem)
Manu: the messages themselves and use of
HTTP is a solved problem. Routing in general has yet to be solved for
the Web. (cites web intents as an example). We need a solution that
works for local and cloud based implementatons
... I fear that this could be pain point for us really soon.
Patrick: we need to see which standards are in place and what’s missing
… and then forward our use cases and requirements to the relevant groups.
Payments requires prevention of double spending, and clear transaction rollback when errors occur
Joerg: our experience with implementing payment agents on different contexts has shown that it is possible, and relies of the details on the context.
In the big picture, we can talk about an ideal solution, although not everything is in place yet.
<padler> +1
<padler> +1 to open-ness
Joerg: we should take legacy environments into account, but keep the door open for new ideas, and not try to solve every thing at once.
David: I have sympathy for both views, but am excited about the work on an abstract framework. We want a model on messaging that can be applied to many contexts.
<padler> +1
<jheuer> +1 on models applicable to many contexts
<padler> idempotency is as important as orthogonality!
David: I think we do need an abstract
<Zakim> dsr, you wanted to note that other groups have their own use cases and priorities which can make it hard for them to accept new ones from other groups
<manu> dsr: When it comes to other groups in W3C - when they take on new requirements - they tend to already have use cases and priorities. For example, BTLE group already has different use cases than we have right now.
<manu> dsr: Painting an abstract is good, but we also have to convince these other groups that these are an important set of priorities to take on.
Patrick: we need to be flexible in what we forsee and keep a balance.
<Zakim> manu, you wanted to mention how this usually happens wrt. Web standards (polyfills, shims, etc.)
Manu: W3C has a well established approach to this, e.g. with polyfill/shims as JavaScript libraries that support new APIs on old browsers.
<jheuer> let's pull the unique challenges of our group out and oput them in the wiki
The new capability we need is inter app communication whether to local native apps or to cloud apps. We do need to study what strategy we need on this.
David: is that what Anders has been talking about?
Manu: yes
Patrick: next week we will meet on Friday at the same time, and I hope to move to Wednesday in due course.
Please send feedback in the meantime.
… end of call …
