W3C home > Mailing lists > Public > public-webpayments-ig@w3.org > March 2015

[payment agent] Meeting minutes for 2015-03-13 telecon

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Fri, 13 Mar 2015 11:02:43 -0400
Message-ID: <5502FC13.4070909@digitalbazaar.com>
To: Web Payments IG <public-webpayments-ig@w3.org>
The minutes for today's Web Payments IG Payment Agent Task Force telecon
can be found here:

http://www.w3.org/2015/03/13-wpay-minutes.html

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

Attendees

Present: Manu, Pat, Istvan, DaveR, Pascal
Chair: Pat
Scribe: Manu

Topics
1. Agenda Bashing
2. Review of payment agent document/diagrams

<scribe> scribe: manu
<padler> Agenda:
https://lists.w3.org/Archives/Public/public-webpayments-ig/2015Mar/0078.html

Agenda Bashing

Pat: Any changes to Agenda?

Manu: nope, agenda is fine.

Istvan: Yep, fine with me.

Review of payment agent document

<padler>
https://github.com/w3c/webpayments-ig/blob/master/latest/payment-agent/index.html

https://dvcs.w3.org/hg/webpayments/raw-file/default/latest/payment-agent/index.html

Pat: What's currently here and the plans... I spent most of my time
organizing the diagrams.
... I wanted to use diagrams as a way to frame out the rest of the
document. Wanted to list different models on how the Payment Agent would
look.
... Things that are common are consistent across models.
... Dave, I took a number of your suggestions and integrated - things
that are common, go into "required core". Other things may be "optional
capabilities".
... Then we can get into what an API or set of services look like...

<padler>
https://github.com/w3c/webpayments-ig/blob/master/latest/payment-agent/images/model_1A_user_agent_pass_thru.svg
Pat: The idea was to get a consistent way to visualize the payment flows
- what I didn't do was not the current state.
... What happens in this particular model - the customer/user - just to
orient everyone - blue boundary - payer boundary.
... gray is payee boundary
... Boundaries are labeled
... Those changes are based on feedback from discussion - both
boundaries - both of them are running a payment agent (or payment agent
of sorts)
... Something needs to generate the proper format on the payer and payee
side.
... Walking through the picture - user logs into the browser, they
select bits and services they want from merchant's website - web server
itself would have some way of turning that request for goods/services
into invoice... invoice returned in step 4 returned to the browser in a
"Pay" button... based on what Dave was suggesting on call last week.
Browser is calling the wallet running on the same computer... using the
invoice (includes information about the merch

ant, URI for where to send the receipt, tax information, other things
merchant is requesting from the customer)

pat: So the wallet, for whatever instrument is selected, would send
payment information to payment agent/service... payment service would
return digital receipt.
... Request to send payment confirmation to merchant - would forward
goods/services to customer in step 10.

<Zakim> manu, you wanted to react to diagram.
<padler> manu: visuals are great
<padler> manu: number will be difficult to follow without steps... need
to add steps...
<dsr> manu: the diagram visuals are fantastic, the numbers are going to
be difficult to follow unless there is a numbered list accompaning the
diagram
<dsr> manu: at the design high level, steps 2,4 and 8 will need a
browser API or REST API or both. These are the things that we will need
to standardize.
<dsr> manu: wherever there is an arrow, there is boundary that we could
standardize
Pat: yes, makes sense to me and agree.

<pbazin> For security reason, some mechanism should exist between
merchant payment system an payment agent to authorize the payment on a
specific amount
Pat: One of the things I didn't want to spend time doing was going too
deep before use cases were further along.
... I also agree that anywhere there are arrows are the interfaces we're
building.
... This helps call those out.

dave: I tend to think more abstractly - wallet doesn't need to be in the
computer, it could be somewhere else... it complicates things in some ways.

<pbazin> Typically wallet could in a mobile phone
Pat: On that point, the reason I put together the different models - for
the reason you brought up - each image is just one example... we want to
use these things as contextual talking points.
... The core requirement is that the payment agent is not bound to a
particular computer or particular implementation style.
... That's why we call payment agent out in the diagram - payment agent
service at the bottom... Cyril's point - payment agents talking a common
protocol... they move into deployment, speak full dialect of things...
next example, browser itself needs to talk - different boundary between
different cases.

Dave: Next point, about the Payment Agent - payment agent may need to
interact w/ the customer (for example, for authentication... not sure
how to draw that)

Pat: Yes, you're right - there are times in peer-to-peer use case, sign
into phone to tell wallet to do something, may not happen in a browser.
... They're fairly consistent, just a matter of redrawing the arrows...
we can draw a bunch of them out.

Dave: Proof of purchase passed by the payment system to the merchant.

Pat: That's in the next model we're going to discuss... talks about "out
of band confirmation" - good point.
... How does the merchant know that the payment has been successful w/o
confirmation from customer.

Dave: Yes, maybe we need to think about this as a separate communication
channel.

Pascal: I think this is a good way to present the different flows -
fully agree with this way of summarizing the flow.
... I think a link should be added between payment agent and merchant...
in some cases, for security reasons - we may want to have a link between
payment agent and the merchant. The browser may be a weak link in the
security of the transaction. Maybe the merchant first authorizes the
payment to the payment agent by providing the amount that they should pay.

Pat: Ok, that's in the next diagram.

<Zakim> manu, you wanted to agree w/ simplifying by adding multiple flows
<dsr> manu: having several diagrams with specific flows is much easier
for people to understand
<dsr> manu: we may have a section setting out each of the flows we feel
are needed to cover the use cases
<padler>
https://github.com/w3c/webpayments-ig/blob/master/latest/payment-agent/images/model_1B_out_of_band_proof_of_payment.svg
Pat: Ok, so let's look at the next image... pick out a couple of models
that are illustrative
... This is a scenario where the merchant is telling the browser what
the digital receipt is... if you provide a confirmation, I will ship
something to you.
... Payment Agent is called, payment service uses some sort of URI that
the merchant embedded in the invoice, so that in step 7, the payment
agent can send confirmation directly to merchant. Merchant updates
website and all is good. In step 9, the customer receives an email w/ a
digital receipt (or they could get a notification back to the wallet or
some out of band mechanism)
... Flow/confirmation changed from the other one... different scenario.

Pascal: Another remark about the API - the diagram only mentions that
the API communicates w/ the service. The API is also something that
needs to happen between the wallet and the browser.

<padler>
https://github.com/w3c/webpayments-ig/blob/master/latest/payment-agent/images/model_2A_payer_initiated_wallet_access.svg
Pascal: Another reason to be sure that the wallet has an API to the
browser, we may have several wallets in separate environments.

<Zakim> manu, you wanted to mention communication pathways...
<dsr> manu: with the possibility of wallets being local native app,
installed web app or remote cloud based, we need to identify the
interface to the wallet that enables all of these to work
<dsr> manu: it is not clear that W3C has ever tackled this type of problem
<dsr> manu: we tried once with web intents, but it didn’t really get
anywhere …
Dave: I agree with Manu, we need to provide a uniform interface for all
three types of wallets. Challenges are user interface interaction w/
payment agent/wallet.
... If you have a locally installed local app, that provides interface.
... It's a web app, interface question is clear.
... if the wallet is remote, then is it a hosted web app - or what are
the other alternatives. We need to look more closely at use
cases/opportunities there.

Pat: Agree, one of the things in the diagrams that's important - this
link is useful -
https://github.com/w3c/webpayments-ig/blob/master/latest/payment-agent/images/model_2A_payer_initiated_wallet_access.svg
... Payer-initiated wallet access - their wallet is in the cloud -
wallet and computer is in two different places.
... It's running on a different service - what's important is that there
is an API between the browser and wallet API service that's used to connect.
... If you notice, cloud wallet, payment agent API - all three of those
things are payment agents...
... They all implement the standard interface for communicating... the
merchant payment system is also the thing providing the payment service
- the model still works... they're both still talking the Payment Agent API.
... There is a standard group of Payment Agents talking to each other,
we can rearrange where they are w/o regard for what specific
functionality they're doing

<dsr> manu: the task of asking the user which payment agent to use, and
a separate task for the API to send the request to a given wallet/agent
Pat: I think what you're hitting on is that the Payment Agent API is a
core thing... there are probably finer grained collections of API - for
example, one might be a discovery API... one might be a payer API... so,
what I see as core - payer/payee payment service agent might implement.
... You may choose to implement one or more APIs (payer and payee APIs)

<dsr> We should be careful with the APIs to preserve the user’s privacy,
e.g. not to allow merchant to iterate through the user’s set of payment
agents.
Pat: Not only send payments but receive payments... maybe I do some sort
of discovery mechanism... personal finance managers - there might be
some sort of API to poke to figure out transaction history - digital
receipts all in one place.

<padler>
https://github.com/w3c/webpayments-ig/blob/master/latest/payment-agent/images/model_2B_sso_via_payee_site.svg
Pat: The other scenario - user is selecting payment agent...
... There may be a scenario where merchant is initiating - customer logs
in to browser, mechant website presents options for them to pay with -
pays w/ credit card...
... Merchant redirects to cloud-wallet provider - some provide wallet
credentials to wallet provider - browser doesn't necessarily need
capability.
... The user logs into a browser, for one reason or another - after
merchant generates necesarry invoice - what they need to send the good.
... Merchant provides payment services that they're willing to accept -
payment services sent back to browser... merchant's website could
re-direct user to wallet service provider they selected on screen...
... Payment processes normally, sends acknowledgement back to merchant -
in this case, browser doesn't do discovery - it's being driven by a
"Payee-initiated request" to wallet service provider.
... Customer is selecting wallet service provider, then you're sent to
wallet service provider.

<Zakim> manu, you wanted to raise event-based APIs.
<pbazin> preselecting the agent would make more difficult for new
commers to enter the game
<dsr> Manu: 4 basic APIs with built in extensibiity through the message
structure
<padler> +1 to manu's description!
manu: I also don't agree with having customer "select their payment
provider" - NASCAR problem all over again.
... I think extensible messaging w/ minimal API is the way to go. So...
3-5 API calls... 10-20 different types of messages.

Dave: So, agree with Manu - we should put information in events/messages.
... We want to protect people's privacy

<pbazin> +1 on simple API with open messages
Dave: Put information in the message, don't expose information to
merchant that they don't need to know.

Pat: Very much agree with what both of you are saying. Next step is to
figure that stuff out.
... Diagrams are not there to say what the API surface should look like.

<dsr> The merchant could pass the extra fees with the message that
correspond to the use of different kinds of payment, e.g. debit vs
credit payments
Pat: So, to Manu's point - we should document which models are not good...
... One last diagram to share.

<padler>
https://github.com/w3c/webpayments-ig/blob/master/latest/payment-agent/images/model_3_P2P_Payment_Proximity.svg
Pat: Same kind of setup - but both payer and payee are using different
devices. Let the payer know what wallet address... they're sending via
browser - a URI to send payment to... payer's mobile app is used to send
app to payee. Payer's wallet communicates w/ payment provider... payment
provider sends message to payee's payment provider, who sends message to
payee's wallet.
... This one needs a bit more work to figure out exact flow. We're
trying to illustrate that payment agents run on any device - POS
terminals, servers, native apps, collection of payment agents - these
are litmus tests defining the API boundaries and how those things might
function - what's the core collection of models that is going to help us
flesh this stuff out.
... What's the first step for getting an API published

Manu: This is peer-to-peer w/ backchannel messaging?

Pat: Backchannel clearing - until you can store value in your wallet -
there is still something in the middle.
... There is still a payment system (unless you're using a
cryptocurrency) - presumably the same mechanisms could take place.
Instead of calling a card payment service - it could access crypto
payment system w/ immediate clearing.

<dsr> manu: in the CG we discussed another scenario where one phone
shares the network access with another phone.
Manu: What about payee-only communciation w/ both online wallets...

<dsr> manu: this could use some kind of masked messaging akin to
tokenisation in EMVco
Pat: yes, we don't have that particular diagram here... if we can get
additional use cases like that - show the flow for those sorts of use cases.

Istvan: Yes, good diagrams - are we assuming based on the last diagram -
between two mobile diagrams - would we consider two mobile devices?
... What about mobile interacting w/ POS?

Pat: Yes, absolutely - we really don't care what the devices are - the
dashed lines are just there to point out that user's are interacting w/
different devices... for example, new watches used to make payments -
watch talks to mobile device... there's a payment agent wallet talking a
standard protocol between those two devices.

Istvan: On point #5 in the diagram, what sort of security is employed here.

Pat: Absolutely - we get the flows down, then we need to harden them w/
security. For example, do we really trust that the browser is going to
pass a payment confirmation that hasn't been hacked.
... This particular deployment is not faked... we need to make sure that
the information only flows to those that need it, and when it does flow,
it's secured.

Istvan: The sooner the better we get the security stuff in here, the
better. We don't want to tack on security at the end.

<dsr> We need to do a thorough threat and fault analysis
manu: +1 to Istvan

Pat: Good example is replay attack on NFC token - device wasn't checking
to see if it was the same device coming back for the second payment...
it would allow a double-spend scenario - very important that we prevent
stuff like that.
... Thanks for the feedback/use cases - leave comments on diagrams on
mailing list.
... Want to keep these moving fairly quickly - so we have a good body of
things to work off of.

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: The Marathonic Dawn of Web Payments
http://manu.sporny.org/2014/dawn-of-web-payments/
Received on Friday, 13 March 2015 15:03:09 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:08:33 UTC