[payment agent] Meeting minutes for 2015-02-27 telecon

The minutes for today's Web Payments IG Payment Agent Task Force telecon
can be found here:

http://www.w3.org/2015/02/27-wpay-minutes.html

Full text of the meeting follows:
--------------------------------------------------------------------
Attendees

Present: Manu_Sporny, Dave_Raggett, Pat_Adler, David_Ezell, Jean-Yves,
         Pascal_Bazin
Regrets: Joerg
Chair: dezell, padler
Scribe: manu

Topics
1. Progress Report

---------------------------------------------------------------------

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

Received on Friday, 27 February 2015 15:53:21 UTC