Web Payments IG: Payment Agent Task Force -- 27 Feb 2015

<padler> can anyone help get the bridge connected to the IRC channel?

<padler> thx..

<padler> Zakiim, aaaa is me

<scribe> scribe: manu

dezell: Pat and I will chair today - I'll start, Pat will do the technical discussion part.
... I sent an agenda out very late - not heard from Joerg - did hear from him this morning, which I'll get to in a minute.
... This is not a detailed Agenda, no clear directives. We haven't met since face-to-face - it may be good to fine-tune what it is we plan to accomplish over the next month.
... Hope we can talk about that today.
... Two major topics: 1) What work has been done since face-to-face, and 2) Pascal should give us an update on where he's coming from.
... Joerg is going to probably not be able to be here until after March 20th. We have 4 meetings where we need to make progress during that time.
... We need to figure out what kind of progress we want to make in next couple of weeks.
... Patrick, this has your name all over it. :)

padler: I can cover in the interim.
... I should be able to get back on these calls regularly, I can chair in the interim.

Progress Report

padler: Since Utrecht, there was a conversation that took place after the face-to-face - Joerg and several others, including Floris discussed a couple of diagram updates.
... Between originals that Joerg had done, Payment Agent itself - version we had been talking about most recently.
... Looking at use cases discussion over last couple of weeks, we need to align payment agent w/ what's reflected w/ use cases document so far.
... Ian had a great point, payment agent diagrams are not really in line w/ use cases at this point.
... What I wanted to do w/ this call is come up with a prioritized list w/ this group - what's the best way to do that?
... Not just outlining the diagrams, but talk about specific requirements - what the use cases are suggesting. Look at key conflicts/mis-alignments and things that need clarification.

<dezell> manu: my main concern is that we don't have an actual document to look at, so that we can comment on the diagrams in context.

padler: If we can get there by the top of the hour, it would be good.
... Yes, I agree - that's the key concern. What could this look like big picture, but we need to focus this into requirements of payment agent - get a document to iterate on. Rather than just a bunch of diagrams, we need to structure the discussion.

<dezell> Ok, this didn't work - https://lists.w3.org/Archives/Public/public-webpayments-ig/2015Feb/0085.html

<dezell> The images are not in the email.

padler: What document do those go into?

manu: They should go into Payment Agent document, I feel strongly about that.

padler: Ok, so they go into Payment Agent document, but cross-reference to use cases.
... Diagrams that David just posted into IRC
... Joerg captures what we talked about in Utrecht - this is good.
... I'll send out raw whiteboard sketch after the call.
... What we're trying to do here is reflect payment agent and payment agent architecture that aligns well w/ what Ian sent out - this is how a payment agent works that aligns with use cases.
... You'll see this on the raw sketch that I'll send out. The idea is to have a simplistic diagram on how payment agent interacts w/ payer/payee.
... Reflected payer processing payee - payment agent description on payer and payee side.
... On payer side - it could be running on mobile phone. On payee side, it could be on payment terminal.
... So, abstract those out - make them a part of core docs for payment agent itself. Merchant layer that sits on top of payment agent. Consumer layer that sits on top of generic payment agent.

<dezell> pointer to Ian's proposal: http://www.w3.org/2015/Talks/ij-usecases/

manu: Two questions on the diagrams - 1) what's the processing block? 2) where is the expanded view of the image on the left.

padler: Here's an attempt at harmonizing 1 and 2 above - payment scheme in the middle - payer on one side and payee on the other. They agree on some mechanics on how funds move, and what would happen is when payment agent decides - processing block in middle is dependent on payment instrument chosen.
... If you do it w/ cards you do it one way, if you do it w/ digital cash, that may be done some way else.
... The specific payer block - that's where you'd see a slimmed down version of diagram I did which has more of the specific components in there that are payment agent specific. Payer pays payee - you may have an overlay that describes that we're using a browser + local payment agent server process + how does that flow happen?

dezell: Comment on Ian's proposal - there's an example on slide 10. We have not had this level of discussion on Ian's proposal yet. These are two different/alternative views of the universe - like wave vs. particle theory.
... Depending on how you look at the problem, you can see it one way or another. Ian's view is "events that are seen by the primary stakeholders".
... The payer knows about vs. payee knows about. These are things that enter the outside - payee and payer - these are things that touch the stick people on the edges.
... This does not address what happens in the processing block... there may be a way to make that point crisp so that we don't get lost between what look like two alternatives.

<Zakim> manu, you wanted to mention that maybe processing is on the side, not the middle.

<dezell> manu: spent time with Ian over this week talking about use cases and how they're set up.

<dezell> manu: I think DE is right - it looks like two completely different models.

<dezell> manu: I'm concerned about the "processing block" in the middle might be something we can move off to the side.

<dezell> manu: the processing will look quite different between e.g. ACH vs. BitCoin

<dezell> manu: for example, there's a fairly simple flow in the use cases - 3 or 4 phases, flow left to right, kicked out exceptions (until later), and we hope to do the same thing with the PA.

<dezell> manu: theory - processing block is something we could abstract out of the picture. The information passed matters, but how the internals work is not so important.

<dezell> manu: I think we need to acknowledge it, but we need to be careful.

dezell: I think that makes sense - what's on the top of my mind is - simply because we have payer and payee - and they look a lot like Ian's left and right, I want to propose that we may have a different way to think about this. The IG should mainly be interested in events and actions they're able to absorb/take.
... If we segregate that from discussing the process, then we have a clean place to pass things off to a WG. If we get deeply into processing, we need a WG to get further into the trenches of the technical problem. That may be a bogus way of looking at it, but it makes sense to me.

padler: I think hearing Manu and David, the purpose of the processing block was not to describe the processing mechanisms in the middle - the original conversation reflected the fact that when you see the use case view - Ian's slide 10 - what's interesting is that between the payer and payee - when request gets made on payer/payee side. There are a series of things that need to be provided for - listen for and respond to the request.
... Particular function that needs to be provided by somebody - browser vendor that - payment agent that is an extension of plugin or http protocol for example - there needs to be something that the payment agent that's running needs to respond to - payment requests. So the processing block as you see it - is not about credit card processing, ACH processing - processing block in middle has two halves. Payer has a server that they're interacting w/ payee has so

mething similar - system that's being used to interact with it. You've got your response. It doesn't mean that both sides need to be doing this synchronously.

padler: Somewhere in the processing realm - I have your request and these actions have been completed - there is an actor in the middle that's providing those functions for payer/payee - unless it's person-to-person, maybe it's not going over Internet - maybe BTLE-to-BTLE - there needs to be something to accept the payment request.

pbazin: I'm ok that processing is not what we have to define - don't you think the interface, even though process is different, I/O are the same whatever the processing is.
... What we have to define is the API/interface - not how the processing works?

manu: +1 to pbazin

<padler> +1

<pbazin> https://www.w3.org/Payments/IG/wiki/Payment_Agent_Contributions

pbazin: I tried to show interactions between payee and payment agent - so, we just need the main functionalities to payment agent, there are not so many of them.

jean-yves: I don't share thoughts of Pascal - I'm convinced that inputs and outputs from payee and payer side will be different according to processing rules, but main configuration of processing. Depending on the process, input and output will be quite different.
... I'm concerned that if we state that we have an abstract approach, if we forget the differences, we will be more confused than abstract.
... I suggest that we keep on going on Joerg's proposal - I don't buy the idea that inputs and outputs are the same if we don't check it.

pbazin: yes, I'm sure you're right -
... we need to end up with something that's universal.

jean-yves: I'm not sure there is real unity between peer-to-peer payment and processing like a card scheme. That's not my experience. Even if we try, we won't be able to make both fit into something practically usable.
... I'd like to see a demonstration.

pbazin: What's the use of a payment agent that can't work w/ all these schemes. The idea here is defining a payment agent has to be connected easily to both sides.

padler: Let me try and harmonize what the diagrams are trying to state - maybe answer some of Jean-Yves comments.
... Each diagram is reflecting the same facet, they're all saying something really important - we want to harmonize those. I think the reason we're talking about these abstractions is to get to something that a browser could interact in a standard way to get to a core API. How do browser vendors today, or wallet providers interact today? There are too many to align w/ all of them. This is defining an on-ramp to all those different payment vehicles that we're t

rying to change the business process of how card, ACH works.

padler: We're just saying there is a common core of things that are done on each use case.
... There are subsequent packages that are used - if you choose to do Bitcoin transaction, you'd use some subsequent spec to collect whatever you need for a Bitcoin transaction.
... If we're saying there are too many payment types and you cant integrate them, then that ignores some of our goals.

pbazin: We should try to find common part of all those flows.

padler: That's kind of the goal - Joerg's original picture - view from wallet provider - how they might implement something.
... How do they spend the payment? That's great, good perspective - next diagram is there a unifying view - not just device-based wallets - cloud-based wallets...
... Payment agent running as someone on device - discussions have evolved since then. Shows a need for what Pascal is demonstrating. Break the processing block up, show payer API, payee API as part of that - server vendor wants to pick this up and implement, how do they do it?
... It gives them something concrete to work with - doesn't mean payer API connects directly to ACH/Bitcoin.

<Zakim> manu, you wanted to say that I like pbazin's diagrams.

<dezell> manu: wanted to respond to Pascal and Jean-Yves. They're both right.

<dezell> manu: Pascal is right that we need a generalized architecture in order to claim success.

<dezell> manu: but JY is also right that such an architecture is a pipe-dream until we can prove that work with all the instances required.

<padler> +1

<jean-yves> +1 to manu's synthesis

<Zakim> dezell, you wanted to comment on the "Payment Flows" vis-a-vis the taxonomy for use cases.

dezell: I agree with Manu
... Looking at Pascal's diagram - here's the thing that jump out at me - something is calling 2-3 different payment agents - different arrows into payment agent are ways this could be called.
... Web or native shopping agent - until we have a good thought model, some of our use cases may have components that belong on the outside - the meta region that we care about, but they're not central to the design.
... Looking at your second diagram - payment flows diagram, the abstraction point here is the payment agent - the thing that's missing is that the most important other is that the merchant gateway, while I do understand that it's aligned with payment gateway, it's not aligned w/ mechant.
... That would make it difficult to see the taxonomy that Ian has described. I can kind of see how these steps fit into that taxonomy.
... If payment agent is interface to user, and merchant agent is interface to merchant - if use cases align, then we have something powerful here.
... There could be thousands of these sorts of patterns -

jean-yves: Convinced that we're trying to head toward the same goals.
... We want abstract, universal, but something that's going to work. My question is which way shall we go forward - how do we work on this? We have two possible directions - bottom-up or top-down.
... Let's try to define an abstract design and then let's try to fit it with reality.
... we need to make sure it maps to industry as it exists today.
... Let's try to define 2-3 main abstractions - universal agent - is it possible to have a universal agent without a level of input/output - w/o a universal scheme.
... universal agent should work w/ largest part of industry. As a matter of fact, universal agent should have basic input/output toward some kind of a "universal scheme". Maybe we can start bottom-up - generic kind of inbetween processing schemes. Let's try as a second step to merge these 2-3 main schemes w/ diagram.
... A hint; an approach is not the one we need - but it could be useful for Cyril or others that are asking for opportunities and designs in order to put down the state of our program. How do we pave the way for them to be a part of how to use the universal agent tomorrow.

dsr: regarding innovation in wallet/api - minimal API is connections between browser/wallet and brick-mortar store/wallet.
... That interface between wallet and payment instruments is also important - we can use this back-end, through the internet, payment instruments. So one area we have to look at.
... Looking at wiki page - support for vouchers, coupons, loyalty cards - identity agents - that needs some drilling down and detail.

padler: Some of the payment agent concepts - there needs to be a minimal core set of things that sit between browser and wallet - if that means there is a process running somewhere that's listening and responding to requests, that's a key part of it.

<jean-yves> +1

padler: What we have to crystalize here - how does the wallet plug in to the things that already exist. There is some minimal back-end interface - systems that exist today, companies that write adapters - they write wallet to card adaptor, wallet to bitcoin adaptor, standards set of interfaces that they can use to make those requests. I agree with what you're saying.

manu: +1 to Dave Ragget's comments - we should focus on interfaces and message to/from those interfaces in wallet and merchant-side.

padler: What facilitates payment proces sint he middle.

<Zakim> manu, you wanted to mention to dsr that they need to talk about identity/credentials.

<jean-yves> * s/state of our program/state of art in our coomon works/

padler: Closing thoughts - we'll try to get a better agenda out - we need to do some stuff in interim. We can work in wiki - we need to structure document Manu is talking about.
... Existing diagrams into more of a message-oriented view - what does the wallet need to accept/provide. We need more crystal clear working examples. How are use cases facilitated.
... If there are topics on the mailing list - please raise them.

dezell: Let's try to talk next week and send agenda out - thanks to Pascal for joining the group and send the material!

<padler> +1 to Pascal's work!

manu: +1 to Pascal - thanks for the diagrams!

dezell: I assume this time is ok for folks.

padler: Maybe we can do a quick doodle poll for alternative times.

<padler> -padler

- DRAFT -

Web Payments IG: Payment Agent Task Force

27 Feb 2015

Attendees

Contents

Progress Report

Summary of Action Items

Scribe.perl diagnostic output