<github-bot> [13webpayments-ig] 15pat-adler pushed 1 new commit to 06master: 02https://github.com/w3c/webpayments-ig/commit/590208236f3e3f84529159cf578c2c5b8d7bbc30
<github-bot> 13webpayments-ig/06master 145902082 15Patrick Adler: Adding initial payment agent conceptual diagrams for discussion purposes. These will need to be update still to reflect any changes to use cases and feedback received.
<github-bot> [13webpayments-ig] 15pat-adler pushed 1 new commit to 06master: 02https://github.com/w3c/webpayments-ig/commit/fe490d528e3ad5d7cdac03ca7d5ac8508f488a02
<github-bot> 13webpayments-ig/06master 14fe490d5 15Patrick Adler: Fixed Issue with SVG export which excluded steps/flows for this diagram
<github-bot> [13webpayments-ig] 15pat-adler pushed 1 new commit to 06master: 02https://github.com/w3c/webpayments-ig/commit/edc714ecd49a95c869c21c919352c80b17448368
<github-bot> 13webpayments-ig/06master 14edc714e 15Patrick Adler: Corrected additional issue with shared layer which prevented steps flows from being exported correctly
<github-bot> [13webpayments-ig] 15msporny pushed 1 new commit to 06master: 02https://github.com/w3c/webpayments-ig/commit/9fa4f1ff95252b67794c7d66dcae1de9ed698896
<github-bot> 13webpayments-ig/06master 149fa4f1f 15Manu Sporny: Update micro use case layout based on 2015-03-12 telecon.
<scribe> scribe: manu
<padler> https://lists.w3.org/Archives/Public/public-webpayments-ig/2015Mar/0078.html
Pat: Any changes to Agenda?
Manu: nope, agenda is fine.
Istvan: Yep, fine with me.
<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...
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
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.
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.
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.
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.
s/[webpayments-ig] pat-adler pushed 1 new commit to master: https://github.com/w3c/webpayments-ig/commit/590208236f3e3f84529159cf578c2c5b8d7bbc30//
This is scribe.perl Revision: 1.140 of Date: 2014-11-06 18:16:30 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/Visa card/credit card/ Succeeded: s/threat/threat and fault/ WARNING: Bad s/// command: s/[webpayments-ig] pat-adler pushed 1 new commit to master: https://github.com/w3c/webpayments-ig/commit/590208236f3e3f84529159cf578c2c5b8d7bbc30// Found Scribe: manu Inferring ScribeNick: manu Default Present: padler, manu, Istvan, Dsr, +33.1.55.01.aaaa, Pascal Present: Manu Pat Istvan DaveR Pascal Agenda: https://lists.w3.org/Archives/Public/public-webpayments-ig/2015Mar/0078.html WARNING: No date found! Assuming today. (Hint: Specify the W3C IRC log URL, and the date will be determined from that.) Or specify the date like this: <dbooth> Date: 12 Sep 2002 Guessing minutes URL: http://www.w3.org/2015/03/13-wpay-minutes.html People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option. WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]
