See also: 30 October minutes and today's IRC log
Nick: Welcome to the inaugural WG
meeting!
... my inestimably charming co-Chair is Adrian Hope-Bailie
<Rouslan> https://www.w3.org/Payments/IG/wiki/Main_Page/FTF_Oct2015#Detailed_2
<nicktr> https://www.w3.org/Payments/IG/wiki/Main_Page/FTF_Oct2015#Thursday.2C_29_October
<m4nu> Lars: Hi Lars from Opera, interested in integrating payments into our browser
<m4nu> Matt: Hi Matt from Worldpay, we're a payment service provider
<m4nu> Adrian: Hi Adrian from Microsoft, on Edge team, interested in shipping a payment API for the browser quickly
<m4nu> Matt: Hi Matt, at Microsoft, lead development team for Microsoft payment services - we're exploring consumer payment scenarios, want to use a standards-based approach.
<m4nu> Nick: Is this a cross-org effort, like mobile?
<m4nu> Matt: I'm on product engineering side - all money that flows through Windows Store flow through our services
<m4nu> Mountie: Mountie from Paygate, interest from payments and settlement standpoint.
<m4nu> AdrianHB: Adrian Hope-Bailie from Ripple, co-chair of this group - focusing on technical work and spec editing, driving more technical side of things.
<m4nu> Nick: Hi Nick, work in technology and innovation at Worldpay, one of the co-chairs of this group - focusing on operational side of this group.
<m4nu> Shane: Hi Shane McCarron, wearing Digital Bazaar hat, assisting w/ spec authoring/editing, I have 30 years of standards experience and Q/A experience, trying to help w/ test development.
<m4nu> Katie: Hi Katie Haritos-Shea, worked w/ JP Morgan Chase for last couple of years but moving on from that, working w. regulators - focusing on accessibility. Liaison from WAI and PF WGs
<m4nu> DavidE: David Ezell from NACS, I chair the Web Payments IG - when I started in 1999 we were working in XML - store operators had to spend 5,000 USD on hardware to support EDI processing... XML changed all of that - we want to remove unnecessary stickiness out of the system. We want to enable people to make payments w/o paying a great deal for that.
<m4nu> Doug: Hi, Doug from W3C, staff contact - newbie to payments, but very involved in W3C.
m4nu: I Chair a number of CGs and
initiatives at W3C. Digital Bazaar hopes to take a number of
standards from this group to market
... for retailers and financial services orgs
<m4nu> Pat: Pat from US Fed, US Fed has undertaken a movement to go to more real-time payment system - interested in standardization and Web technologies - we want to go much faster/safer for payments.
Brett: Am here from Google;
Zach: Google chrome team...improve user experience
Cyril: I work for BPCE innovation
dept
... I have worked in payment system since 1987...SET...card
payments...project manager for SEPA project for my
company
... I am interested in direct debit and credit transfer
issues
... interested in how we manage flows
... also related to merchant accounting relationship to
payments
Jean-Yves Rossi: I have a consultancy...we help people design new payment services
scribe: help people manage
regulatory/supervisory matters in Europe
... I have been involved in French banking groups and
re-engineering of banking oversight in France
<CyrilV> contribution to the Group : SCAI workflow
Kris: From SWIFT representing
ISO20022...standards for 20 years
... I see this as an extension to ISO20022 realm
... am here to help with interop of this work and
ISO20022
... Also Vincent Kuntz will be the primary WG participant (and
I will be the primary IG contact)
Rouslan: I work on Chrome team
Jiangtao: I am from Huawei
Zephyr: From Alibaba...hope to contribute from PSP perspective in China
Yaso: I I wear 2 hats...W3C
Brazil Office and also representing NIC.br
... steering committee of internet in Brazil
... I want to help contribute to the standard and also its
deployment in Brazil.
Dongwoo: Am here from Samsung Pay
Jungkee: Also observing from Samsung.
<dwim_> and, work for Samsung browser team
Jungkee: we'll discuss with the payments team
Laurent_Castillo: Gemalto...we are interested in standardizing APIs for easier payment instrument integration
Nick_S: I am from Apple.
NickTR: Over the next couple of
days we will be looking for volunteer editors, test lead
... think about that as we go along.
... Dinner tonight?
<nicktr> http://www.w3.org/Payments/WG/charter-201510.html
Nick: Good to recall from our
charter that we are standardizing API not UI
... having said that, it is reasonable to hope for a more
consistent user experience for users
... and also good to remember we are not defining a digital
payment scheme.
Charter deliverables:
http://www.w3.org/Payments/WG/charter-201510.html#deliverables
FPWD expected in March 2016
IJ: Is "early implementations one year from now" reasonable?
(Some nodding)
Matt: There is not specified in the charter that there is not a way to register a payment instrument
(Charter says " Registration: A payment provider requests to register a digital payment instrument for use by the payer.")
AdrianHB: I think we are going to have to have registration (but not only through a browser)
MattSaxon: There won't be a way for a DEVELOPER to add a payment instrument
Mountie: Data flow will be
different depending on whether wallet is on client or server
side
... we'll need to be able to talk about registration both
client-side and server-side
m4nu: I think the timeline has a high chance of being unrealistic.
m4nu: given something as complex
as payment
... Microsoft is saying we want to ship quickly, and that's
great, but we don't want to hinder the viability of the Web
Platform for doing payments
... for developed and developing economies
... I want us to be sure to take into account the long-term
future
... so I think the timeline is aggressive, but let's be sure we
make good long-term decisions for the platform
adrianba: Our goal is to iterate. We want to make progress on something useful and expand scope over time
<zkoch> +1
NickTR: The scope is deliberately
narrow.
... scope increase would involve recharter
<Zakim> dezell, you wanted to talk about use case structure for "agile"
dezell: We may need to restructure the use cases to ensure we can shed use cases if we want in order to ship sooner
shepazu: I would not like this WG to spend a lot of time discussing use cases
padler: I'd like to review the flow and also the thing we are going to work on
Quick summary of categories of "capabilities"
padler: We think this framing is
important to coordinate work and prevent redundancy
... and reuse of materials that are related to payments in a
variety of ways
... e.g., payments may require security or credentials
... I think we will encounter accounts and ownership
... I'm going to send a payment request, where do I get details
about accounts and assets in those accounts?
... clearing and settlement is about messages and movement of
funds
... last bucket is commerce (discounts, coupons, rewards,
invoicing)
... those are more "relationship based" and not directly about
transfer of funds
Doug: Is this an agreed upon delineation?
Pat: Generally, though there may be additional (e.g., UI) or refinement, but generally agreed upon that these are part of the problem space
Matt: Cross section of
capabilities in the IG and what the WG says
... how will we keep focus?
padler: Understanding that the IG
is wrestling with other topics and we are also looking at the
scope of this WG
... the WG may find it needs something (e.g., related to
identity) and can raise the question with the IG to find out
who is working on the topic
<m4nu> Ian: One way the IG was coordinating their work - what exists today, what doesn't exist - who should work on it - that's Roadmap, what is capabilities, use cases help refine everything.
<m4nu> Ian: Capabilities help us talk about big vision for Web Payments
<m4nu> Ian: From time to time, we will propose WG charters for gaps in functionality.
<m4nu> Matt: ok, that makes sense - how do we manage the overhead?
<m4nu> Ian: That's the Web Payments IGs job - I don't want IG work to be a burden for the WG. That's not our job here.
<m4nu> NickTR: So, there's a task for the IG to say how capabilities map to Web Payments WG
<m4nu> Ian: Yes, we should figure that out - there is some coordination role.
<m4nu> Matt: So, can we update the charter?
<m4nu> Shane: No
<m4nu> Ian: We will have to adapt how we talk about things in this group based on IG identification of capabilities.
IJ: I expect that the WG experience will flow back to the IG to shape our thinking
padler: When you think about payments and commerce, the reality is that I may start a transaction in a store and then complete it at home in my browser.
<m4nu> Pat: Series of messages between parties - There are lots of cases where you walk into store, get offer, then leave the store. When I get home, I log into browser, I complete transaction.
padler: when you think about
payments and commerce it's a series of interactions between
parties
... I think it's valuable to think about capabilities in terms
of communications between 2 parties
... the WG may have an easier job if we can decompose the flow
into smaller 2-party interactions
... and how they fit together...and then we compose them into
broader functionality
... so rather than look at use cases end to end (as we do today
in the use cases) we want to break down into atomic pieces
<padler> https://github.com/w3c/webpayments-ig/blob/master/latest/capabilities/images/paygent_connect.svg
(Some diagrams)
pat: We have wrestled with what
to call the "thing we are focused on"
... payment agent, user payment agent, wallet
... originally we thought of a payment agent as an abstract
thing that exchange data with other entities (and could be a
browser)
... A wallet is just a specific type of payment agent. So is a
car.
... but we could call this "the payer's user agent" or the
"PSP's user agent"
... that's useful where you are dealing with things like
loyalty coupons
... I think wallet is not useful for some use cases....think we
should have another term but that includes wallet use
cases
... e.g., point of sale terminal.
... I think when we are writing specs it becomes more
useful....I'm just exchanging point it's not a payment or my
wallet, it's a loyalty dialog
<CyrilV> +1 to avoid wallet which is a confusing term
IJ: I don't think we are far enough along to motivate this change from our charter
<nick_s> we can’t avoid wallet, it’s *in the charter*
AdrianHB: Today is a
level-setting day and definitions are part of that...but we
have "wallet" in our charter.
... we are defining things by what they do
... we may decide that there are other functions that wallets
have, but not sure that in this WG we need to do more
mountie: I don't understand
clearly some uses of wallet
... client or server side
... does payment scheme belong to the wallet? to the
instrument?
... I think we need some pictures to help
CyrilV: we need to be sure to be explicit about different actors
NickTR: I hear that we need more work to agree on terminology
<padler> https://github.com/w3c/webpayments-ig/blob/master/latest/capabilities/images/paygentbase.svg
pat: the IG worked early on on
functionality
... payer/payee/psp
... we did this categorization
pat: in order to be able to talk about flows in a consistent way
(Pat walks through flow diagram)
(Different routing option for payment response)
(person-to-person)
MattS: The diagrams are helpful...it's important that we as quickly as possible have flows to focus on
<Zakim> m4nu, you wanted to focus on simple flows first, then more complex and to focus on minimum viable payment flow, but not loose focus on more complex flows.
m4nu: The flows are helpful but
too abstract for me
... I think we should focus on the minimal flow
... understand how it maps to browser API will be helpful
... we should not find every single flow
... we should start on a simple well-known flow like a card
payment online
... we should get comfortable with that.
... then people who know other flows (e.g., ACH) works with the
API we are coming up with
zkoch: The flows are nice as test
cases.
... I think they are useful and send a signal when the designs
don't work with the flows
... also would be useful for our colleagues from Alibaba,
CIPO, etc. to let us know about local flows that we are not yet
addressing
kris: I agree with Manu..the best way is to come up with our flows and then see if our term wallet still works across these scenarios
<Zakim> padler, you wanted to clarify intent of flows..
padler: The reason to work on the
flows originally was to come up with a consistent
taxonomy
... we wanted to be able to focus on specific messages
... it was important to me to have a consistent way to talk
about flows
nick_s: We did define what wallet means in the charter; I'm wary about changing those definitions
(Review charter goals)
(Review of benefits we expect as well from the solution)
AdrianHB: A payment instrument is
a thing with an API, that has execution logic.
... it may store credentials....but it can be communicated
with
... it is a front for a payment service provider
<Zakim> padler, you wanted to comment on slide..
AdrianHB: "Roles" rather than actors. So "role of wallet" may be taken on by various actors
<Ryladog> +1 to Adrian's point
Cyril: W3C should not revisit 20
years of terminology in the financial services industry
... payment schemes include rules
... I strongly disagree with the definitions that Adrian has in
his slides
... people will look at us and say "They don't understand
payments"
... and people will look at the work and not understand it.
AdrianHB: We need definitions for the roles of components in our system
NickTR: There is still work to do on terminology
Cyril: I'm ok with the definitions in the charter; not Adrian's paraphrasing
nick_s: the end goal is to define
standards for users, which here is end users of the web,
developers, financial institutions.
... they all have differing definitions...and I think it will
be difficult to satisfy everyone.
... in Apple pay we expose the term "payment instrument" but it
can be confusing for some
<padler> +1 to Nick's point
jyrossi: I am wary of Adrian's
definitions...can be misleading
... payment scheme implies rules
AdrianHB: Let me explain how I
got to these points...in the charter we talk about a payment
request that comes from the merchant, and lists the payment
schemes that are accepted by the merchant.
... I am trying to simplify for some audiences (perhaps
oversimplifying)
<Zakim> m4nu, you wanted to say we're in a terminology discussion again, we should stop and move on
<nick_s> I am not totally sure we can suspend disbelief of definitions for the next two days if we plan to discuss messaging and architecture in those two days, they seem rather intertwined
<nick_s> …as loathe as I am to spend any more time discussing it
<MattSaxon> +1 to Nick's point
<zkoch> https://drive.google.com/a/google.com/file/d/0B6Su47MQXuKZdVhwd0sta1NBaE0/view
Zach: I will talk about payment
instruments.
... I will talk about them the way users think about them
... I will avoid the word wallet
... I think there are two big goals
<Rouslan> discourse.wicg.io/t/rfc-proposal-for-new-web-payments-api
(Ian note for later based on discussion with MattP on two ways to identify instruments: by name or by class)
Zach: This example assumes we
will define "visa" as a payment instrument.
... we link payment instruments by domain
... but for some well-deployed schemes we may have shorter
strings (e.g., a card network name such as "visa")
Kris: I think what you have shown
is great, and the relation to ISO20022 is that the information
is already described
... if we don't have these things yet in ISO20022 we can
add/extend
Cyril: You need a reference to
the transaction
... data we don't need to describe here, but is important so
that the merchant can map the money they receive to a
transaction
padler: Remittance data about the payment...it's where a lot of legacy systems don't allow passing that payment...it turns out to be critical to pass it along with the payment
<padler> correction.. remittance data is information about the payment and what it is for... not the payment itself..
Zach: I am not sure we need it...but let's come back to it
<Zakim> AdrianHB, you wanted to make an observation about parameter names
AdrianHB: You've got two params:
supported instrument and also "scheme data"
... we are going to have to figure out which is which
Zach: Point taken
Laurent: I love the proposal but have some feedback....
<nick> I will wait until after the next few slides
(We decide to go through the whole presentation)
Zach: First example is simple but
there's no communication channel between browser UI and the
app
... suppose we want to include address which affects
price
... we need to enable the merchant to update the request
... so in the next example we have 2 promises
... original promise returns an object...that object supports
events
... the user agent can alert the merchant that something took
place
... there are methods the merchant can call to update the
original request
... so there is a communications channel between merchant and
user agent
... where there is support for events and callbacks
... you can imagine a world where there is a
paymentInstrumentChange event and the merchant could update the
price based on the selection
... the second promise is the instrument response promise
IJ: So promise 1 is unlimited number of events; promise 2 is the "last thing that is really needed by the merchant"
Zach: Yes
(Review of flow from a high level)
scribe: first promise has any
events (not just shipping address; could be any)
... there's a thing on the diagram "scheme-specific payment
auth"
... from the perspective of our API, we don't care how auth
happens
Zach: Assumption here that the merchant and payment instrument have a relationship and the merchant understands how to parse the response
Pat: the user agent doesn't care
about how the payment method is implemented behind the scene,
but does need to know how information goes back and
forth.
... I would use the phrase "payment method" not "payment
instrument"...
Zach: +1 to continued work on the terminology
(nodding about term "payment method")
Zach: So the merchant is waiting
for the response...they have the reference to the original
request....so that's why it's not clear to me that you need
additional transaction data.
... since the merchant is waiting around for a response to the
original request.
... there are methods for registering payment instruments....I
propose we use a manifest file.
Manifest for a web application
We could also expose registration API on the merchant's web site
scribe: we do this all the time
in user agents.
... the user agent can choose to honor or not
... the site can request to install the payment instrument and
the user can say yes or no
... I think we should standardize ubiquitous responses like
credit cards
... that way merchants don't have to account for PANs in
different ways
... in the base case, a payment instrument could be an embedded
iframe
... works in all browsers and platforms
... Some open questions at the end of the presentation
nick: How do we let merchants know that instruments are available before the payment request?
Zach: I suppose you could return a boolean and stay privacy sensitive.
Nick: Standardizing credit and debit may be interesting...but please note that some methods are ubiquitous in the west but not everywhere
AdrianHB: The charter lets us focus on debit and credit cards (as a Note)
Nick: Could you speak to why this is a javascript only approach rather than any markup.
Zach: I think you could easily do
this as a declarative approach...I don't have a strong opinion
about it.
... I think programmatic access will be common for
developers
Nick: I don't think we need to choose one or the other
Mountie: If the payment process
takes multiple days, or if payment happens in multiple steps,
then your suggest does not cover those scenarios
... do you think that the payment instrument is bound to one
domain?
... not clear that binding payment instrument to domain a good
idea
... third comment - you mentioned iframes. But iframe may not
be enough for security (e.g., keyjacking, etc.)
Zach: I think that the 3Dsecure
case may not be part of this API...we should sit down and walk
through the flows
... and if the approach does not accommodate flows we should
adjust the proposal.
... we can also talk about iframes special cased by the
browser
... regarding binding methods to domain names, a method may
accept multiple schemes
... we might want to accommodate that
... as to the domains themselves, I don't know how to do this
outside of domains.
Mountie: Blockchain?
Zach: Please suggest this as an issue on the github page
<adrianba> GitHub issues page
jyrossi: I like the proposal. The
only thing that makes me a bit uncomfortable has to do with
trends in how merchants do payments...growing risk that payment
could be revoked.
... in the drawing there is one go-and-return
... due to the growing risk that the payment could be revoked,
the payment instrument is providing some kind of insurance
solutions
... but they are costly
... merchants are mitigating between paying for insurance or
taking risk
... if you integrate such a capability, you won't have just one
round trip, you'll have two
Zach: Suggest you add that to the issues list
Matt: Thanks, I think the
proposal makes a lot of sense.
... for payment providers like AliPay and PayPal where there is
a redirect
... in AliPay case, the funds are captured at that point;
PayPal can work that way as well
... I hear in the proposal that you say "Go do AliPay as usual"
and the merchant would do that experience as today
Zach: I can think of multiple
ways to approach this question given this architecture
... e.,g they could transfer funds immediately
... they could also do something where they authorize funds,
generate a key, send back to the merchant, and the merchant
does something with their private key
MattSaxon: +1
Kris: I would like to see whether we are going to use markup
AdrianHB: The purpose of today is
to put all the information we've gathered on the table ... get
ideas together
... and record questions
shepazu: A good thing to do is write an alternate proposal if you think you have different perspectives
NickTR: We need to talk over the next couple of days about how we are going to work operationally
CyrilV: We need a trace of
consent to pay and consent to deliver.
... so I think we need to have transaction information
... I think we need in at least some schemes that we will need
transaction information for merchants (e.g., for
accounting)
... I also want to see flow of credit transfer (and also direct
debit)
m4nu: Overflow idea,
promise-based...love it
... some things seem to me to be the space of credentials
... such as address
... there's shipping address, billing address, proof of age,
etc.
... if we start working on that stuff, it distracts this group
from setting up the payment
AdrianHB: There's a note for discussion about securing data
<Laurent> +1 to Manu, plus it's User credentials, we already have to care about merchant and instruments credentials
<nick> I believe addresses are absolutely within this group’s purview and should not be left to the credentials CG
m4nu: There's a lot of JSON being
suggested; messages need to be extensible however.
... merchants and payment schemes wants something that is
extensible.
... one way at W3C to do this is to use a registry, another is
to use the linked data approach; we will need to discuss
Zach: I want to address shipping address since so critical. I expect that we will have to address extensibility (though I think JSON is extensible)
<ShaneM> As to payment address - it is one of many things that a merchant might request. The API should have a way for a merchant to request X
MattS: I like the flow.
... question about instrument response -is there an option for
the merchant to say "I don't like this response"; I think
that's important to the merchant
Zach: that's not part of this proposal; one assumption of the system is that if you choose to support a payment method you are expected to support what you get back
Discussion point: PSP declines a transaction...there's an authorization failure
MattS: Question is whether the user agent has a response in the case of authorization failure
Zach: After you submit a request in android pay, there's a way for android pay to take action..the more I think about this, the more I think this is a good question.
MattS: There could be some magic on the merchant side that we should be discussing
Zach: I can see an optional layer.
adrianba: We should differentiate in the flow diagram between the the merchant on the server side...and ...
AdrianHB: I think the standard doesn't have to tell the merchant what happens next; the merchant can decide...but it could be in scope to discuss
<adrianba> We should clarify the flow diagram in Zach's proposal to differentiate between the web page that calls the paymentRequest method and the service side communication
MattS: On delegation....
... I'm wondering whether your flow allows the response to be
proxied.
Zach: Right now; no.
... I don't think that it's in our best interest to interject
ourselves into that relationship
MattS: I think that delegates a
lot of work to the merchant; but many merchants prefer
simplicity
... I think we need to look at how the merchant interface needs
to be delegated to the PSP
<Zakim> padler, you wanted to build on Matt's question and tie it back to the flows discussed earlier..
We now have on the white board for flows:
padler: We are trying to fix that
the user does not need to send details to merchant's back end
to be paid
... whether the PSP is locally invoked or remote, that seems to
be the first delineation
... who declines the payment? If I invoke my payment processor
and my payment processor says no, I need as a user to be able
to choose an alliterative instrument.
... how do I reply that the payment was successful? Is it from
the browser? Or do I provide enough information so that the
payment service provider can send information directly back to
the merchant?
padler: It feels to me the key delineation is: (1) how do we prep the payment (2) how do we @@
Laurent: I think we also need to
have a flow where the instrument response goes back to the
merchant on the server side
... I am thinking of the base credit card use case
Zach: I think that this proposal accounts for that...we need to whiteboard the flows
Laurent: Do we want to normalize
these flows or just use them as examples?
... what I like in this proposal is that there are a lot things
left to the merchant side
... but need people in industry to understand what are examples
v. normative
nick: Re shipping address..I
think it's important and should be part of this group.
... when I say it's not always a credential.
... address is a transient location...
... I think we need to cover card payments and billing address
is required
<padler> +1 to comment about transient location being important..
<zkoch> Github issues page for this proposal
<ShaneM> FYI there are terms in the schema.org vocabulary that we should be able to take advantage of.
nick: we'll need to define something for address; I don't want to wait for a group that's not yet be chartered
<zkoch> Post issues there so we can keep track and think about :)
<MattSaxon> +1 for Nick's address point
ShaneM: Some of those things are special cases of a more general activity
Nick: Agreed.
<m4nu> Credentials CG Proposals: https://docs.google.com/presentation/d/1Zx-wbg_vxsEuRInM64Y4xm7SdO_E6KO_qQ8abSExFkU/edit
m4nu: Lot of agreement between
this proposal and Zach's
... the general form of the API
... I will focus on the points that are not as aligned
... the CG has been working for 4+ years...this proposal is the
latest thinking
(Manu walks through presentation)
<ShaneM> There are also lots of E-Commerce vocabulary items at http://purl.org/goodrelations/
https://web-payments.org/specs/source/web-payments-messaging/#message-formats
m4nu: The examples show that
there's a URI for the service for handling payment
requests
... The point is that different organizations would specify
what the data is necessary for different instruments
... Next we look at payment request initiation data blobs
... merchants can include whatever information they want into
the message
... there's a digital signature at the end
<ShaneM> Currency names are in ISO 4217; Country codes are in ISO 3166
m4nu: you shouldn't be able to tamper with the message
<ShaneM> ... note that if we have weird currency names that are outside of ISO 4217, maybe they could be scoped (ala CURIEs)
m4nu: there's another example of
a request with multiple accepted schemes
... there's a longer example of an ISO20022 payment request
that can be translated directly to XML
<nicktr> of course BTC would not be a currency in ISO world
m4nu: So we have extensible messages; the routing is the domain of the APIs
Cyril: You need more information
than "Visa" you need information about the bank that issues the
visa
... you have a "Barclay's Visa"
... Note that ISO20022 is not a scheme
... it's SET
... so you need the scheme but also the issuer
... Things to taken into account...timeout (e.g., bitcoin
request)
... there are periods of uncertainty
... to have a more concrete consent to pay
CyrilV: Signature works for me as a form of consent
MattS: Let's look at example in
2.1
... the payment request service ... is the intention is when I
want to authorize I go to pay.example.com ?
m4nu: Potentially.
MattS: I'm happy with a non-specific response.
Mountie: We need to discuss same origin policy
m4nu: Agreed
Zach: Are you taking a stance on when money is transferred?
m4nu: No.
... In the REST case, it could be that this URI is where you
send the request. But in a promise-based flow the data you
provide could be other.
... so there is no stance...the data that is provided is
whatever people need to provide
AdrianHB: Could be, for example, UI to display....
<Zakim> dezell, you wanted to ask about paymentCompleteService.
m4nu: Payment complete service could be a service where you post information
<nick> I’m happy to wait
m4nu: Message format takes some positions:
- not xml-based
scribe: even though the financial
service industry is powered by XML
... JSON-based messages...extensibility is vital
... we want to future proof the solution
... JSON-LD provides an extensibility story
... communication is HTTPS only
... we need to make sure that we support card, bitcoin, ACH,
SEPA, etc.
... we may also want to support non-scheme digital
signatures
... for things like offers of sale or invoices which we may
pick up when we start work on ecommerce things
(Regarding the APIs)
m4nu: the browser API looks like Zach's proposal
<nicktr> +1 for other transport mechanism supports
m4nu: When the request is sent to
another site...the site needs to be able to say "I've done the
interactions I need to do such as 2 factor auth"
... then the PSP or paypal or google wallet or whoever has
executed the initiation of the payment
... they put together something we call an "acknowledgment" (of
receipt of the request)
... the acknowledgment resolves the promise on the merchant
side
... the only thing that really differentiates the two proposals
is that:
Kris: I think that "supporting
ISO20022 messages" is missing apples and oranges
... do you mean "ACH format"
... if so you need to be clearer that we would be creating an
ACH-formatted message in the payments sphere which doesn't make
sense
... if we are talking instead of payment instruments we need to
fix this
... example, we can do ACH-batched transfers at our company,
and our hope is that our bank would give us a payment
instrument
Cyril: There is no ACH method
NickTR: In the US it's different; that's the source of confusion
Kris: We should clear up slide 5
Laurent: I wanted to highlight an
interesting difference between CG and Zach proposal:
... different prices for different ways to pay.
... that's possible in Manu's proposal
... you may also want to the same for signatures
... the signature itself may depend on the scheme
m4nu: The proposal is to have two
layers : one scheme-specific, but a second one that would come
from this group...
... you can't use scheme specific mechanism for an offer of
sale
nick: Thanks to m4nu and zach for
the proposals. A comment on both. We are missing
"Discovery"
... how a server knows that this API is available
... we need to consider that, which brings me to another point:
i don't see substantial discussion of privacy
... I'd like to see that in more detail
... how we can avoid these APIs being abused
... eg., in the case of a REST API you could rapidly interest
to determine what one has in a wallet
Cyril: I think that we may need
signatures everywhere even if we have HTTPS everywhere.
... the message needs to be protected as well
... the message should be signed
CyrilV: There may be a need for
another layer to parameterize how payment happens (e.g.,
installment)
... lots of merchants ask for that
... and how the user chooses to pay may affect things like
fees
<ShaneM> building discount capabilities into the payment offer.
(More notes on API from Manu)
(Remaining work)
MattS: In section 2...4/5/6
indicate differential behavior.
... that's a fundamental difference in the two flows.
... m4nu has different type of behavior based on instrument
type built-in
... that seems to be a fundamental difference
m4nu: This proposal attempts to
support push, pull, and approaches that are in-browser (e.g.,
built-in bitcoin)
... so this algorithm tries to take that into account.
... the detail in there addresses some of the questions that
have been raised.
MattS: We need to address this fundamental difference.
Zach: The one limit of polyfills
is that they limit us in what we can bring in.
... browser has access to some things like secure elements that
other software may not have...polyfills may limit us
... second point - when we think about deployment --
dependencies add weight.
... JSON-LD dependency for example.
... I would vote that we take Manu's good ideas and put them in
my proposal ;)
m4nu: We do want rapid
deployment....we don't want to leave browsers out in the
cold... polyfills allow older browser support
... I don't think we should propose sem web processing flow
blown; I propose that we should provide hooks for
extensibility
<Zakim> shepazu, you wanted to ask about transforming message serializations (JSON, XML)
shepazu: Should we factor out serialization (and, e.g., be able to provide an XML serialization)?
Mountie: Character encodings are important with respect to signatures
M4nu: JSON-LD is Unicode-based
<Zakim> ShaneM, you wanted to suggest that the request could ask for additional information for each scheme in a merchant request
ShaneM: As the merchant is
offering up information about instruments they accept (e.g.,
variable pricing) it might be additionally interesting to embed
other additional information (e.g., merchant is willing to sell
it for you at this price if you give them your home
address)
... so there might be additional CONDITIONS beyond simply
instrument
m4nu: that may be a pre-step
(Various guests from the TAG - Alex Russell, Travis Leithead, Mark Nottingham, Dan Appelquist)
alex: The TAG's responsibility is
the overall coherence of the Web as a platform
... we collaborate with different WGs.
... the earlier we work with you in your design, the better
DanA: We're the TAG we're here to
help
... we've worked with various groups also on joint
deliverables
... we have expertise in network protocols, javascript,
security, etc.
... our offer is "come talk to us" we want to understand the
problems you are trying to solve; and tie together APIs with
rest of web platform.
... I was happy to see use of promises in early
proposals.
... that's an example of where our work attempted to unify
otherwise uncoordinated bits
... use of WebIDL
(Some discussion about the way things were re: events and callbacks)
scribe: we have a guide now on
how to use promises
... by Domenic Denicola
... I want to say that if you have questions; that's our
job
Alex: Another topic is origin
model.
... how various actors in the system interact and where
information can/cannot be passed
... We've also seen high-level APIs....there are so many
existing systems where it may be inevitable to have a
high-level API
... high level solutions may not serve people
... it's important to have the conversations early about
extensibility
... we worry about the tension between the audio element, for
example and "Web Audio"
<Zakim> m4nu, you wanted to ask about high-level concerns around data security, extensibility, data linkability, credentials, decentralized identifiers.
m4nu: There are a number of high-level concerns around data security. I think there's a unified response to security on the web today which is "use JOSE"
Alex: there are many people who think that's a good thing to do, but some people who think it's too complicated
Manu: We are potentially going to
hit that problem head-on...
... there are many different types of extensibility, e.g.,
linked data, data extensibility
... I don't know if the TAG has any recommendation about how to
look at data extensibility
... when is it ok to have linkability in the platform?
Alex: Our general discussion
tends to revolve around "who the origin is"
... the web platform really has one security model
... this causes real chafing
... it's got weird grandfathered in behaviors
... the more than you can think about "who as an origin did
that map back to?"
... reducing the questions to origins lets you treat it as an
API question and let the browser handle the social aspect
... promises, because they are asynchronous, you can ask the
system or the user to make a choice about whether information
can be shared
... e.g., requests for geolocation...those being async are
important.....
... the architectural principle is "Where you are not sure what
should happen, keep things asynchronous."
m4nu: There are multiple groups
searching for identity/credentials solutions....whether it's
possible to authenticate people cross-domain.
... any input from the TAG on that question would be
welcome.
... the TAG has an ability to say "this area is a problem and
W3C should be spending more time talking about it" more visibly
at the consortium.
... there are three groups currently struggling with it...would
be nice for the TAG to discuss this.
Alex: Yes, where there are
multiple groups discussing something, consistency would be a
good thing
... one thing we are emphasizing is that it's ok to make local
progress.
... don't block on boiling the ocean.
... boil just enough to make tea if you want tea
<Zakim> shepazu, you wanted to ask about message format, and security of polyfill
shepazu: This morning there were 2 proposals. When I looked at them two diffs that stood out for me were (1) zach did not have a message format proposal [Zach: that is to be fleshed out]
Alex: Inside w3c we are not
re-litigating transport. but there are areas for collaboration,
such as out-of-band push notifications
... or working with TC39 on improving WebIDL
... please specify enough to solve the problem.
shepazu: What about
polyfills?
... are there security concerns about delegating to a
polyfill?
Alex: There are up sides and
risks to polyfills.
... upside is obviously earlier visibility....but the downside
is that polyfills can end up with lives of their own
... a polyfill that is widely used has risks.
... e.g., early shadow DOM polyfills led people to think they
were slow, but implemented natively are much faster than other
approaches
<Zakim> AdrianHB, you wanted to ask about the interaction model on different platforms
Alex: just beware of downsides of polyfills
AdrianHB: I want to throw more
specific questions on the table.
... one of the questions that has been thrown around without a
clear answer
... we have a narrow scope of what we want to standardize
(which does not mean narrow in what we want to consider)
... the standard is for the flow between web site and payment
instrument
... how that manifests itself on different platforms will be
different (e.g., on mobile may be native app)
... so, e.g., user selection of payment instrument is selection
of an app
... but we don't have an elegant way to replicate that in a
desktop world.
... how would we achieve the same kind of idea on
desktop?
... as a merchant web site I've provided information about ways
I can be paid.
... let's say for this example the user agent assesses the
list, compares to the list of payment instruments that have
been registered, and provides the user with a set of
choices.
... the user picks one, there's execution of some logic by the
payment instrument (potentially in its own execution
environment) and then returns (via a promise) a response.
... in mobile that pattern is quite familiar.
... one proposal for the desktop is the browser gives you a
selection UI (thus, rendered by the browser)
... now the payment instrument wants to render some UI...is it
sufficient to do so in a frame?
Alex: I hear a couple of questions: (1) how much needs to be in the spec (2) if so, how much needs to be specific
AdrianHB: The definition of the
payment instrument needs to have enough data for whatever the
instrument execution environment needs
... so we need enough information (even if as simple as a
URL)
Alex: In the web platform we are
always mapping things back to URLs. You can map pieces of the
transaction back to URLs and origins...that makes it easier to
talk about "who is doing what with whom and with what
data"
... there's a related question about how to do the selection
dance
... there are various approaches like protocol handlers, custom
url schemes, etc.
... redirecting through the OS to get something
... mobile systems have intent handlers
... those are questions that are a bit out of view from the web
platform.
... there have been ideas proposed like web intents
... there is an itch to re-explore that, but my advice today is
to not try to solve that problem.
... provide enough information to bootstrap ... but also chart
a path forward
... you might uncover latent issues this way ...the exercise is
valuable...but I wouldn't get too hung up about harmonized UI
across systems
AdrianHB: Part of the motivation
for the question is that we are looking at things from the
perspective of the merchant creating things for their sites and
calling this API
... but we are also thinking about how the payment instrument
provider gets their instruments to different platforms
... maybe we don't have to SOLVE it but I think we should think
about it since it will be part of flow.
Alex: I would guess your implementers help address it.
nicktr: Given that we are just starting off, are there pre-requisites or patterns based on successful ones
MarkN: Implementations
Alex: Iteration
MarkN: +1 to iteration
Alex: You can't design something
without implementation.
... So just get started.
Travis: You also need people to do the work
MarkN: Don't boil the ocean
... don't try to accommodate things you don't know.
... Shipping a spec is not a guarantee of success
zach: In our proposal, we took a
hacky approach with a promise...we wanted to open a comms
channel between browser and merchant, so that when an action
takes place we want to emit an event with info that allows the
merchant can respond.
... our approach is to have a first promise that returns an
event target, that becomes the event target.
... a second promise is the instrument response promise.
... that should work BUT you could imagine a world where events
and promises work together.
... any thoughts on this?
Travis: I had a brief look at the API. I think you are modeling the right principles on the right syntaxes. Unless you have a strong motivation I think there's probably not a reason to merge concepts.
Zach: There are some edge cases where having two promises is overkill...so the solution seems a bit ugly.
Travis: We'll stew about this and see if we can come back with something that's a bit better.
(Some design on the fly)
Alex: Promise is a one-shot
response.
... we see this tension all over the place..e.vents have no
historical data....
Travis: You want to return data
back to the platform.
... you are generally responding to a platform event...but here
you are also sending data back.
Alex: In service works we have
"extendable events"...they extend the life of an
operation...they also respond to it.
... that's a way of saying "I'm going to give you a value that
is either a value or a promise."
Zach: If there's a cleaner
implementation let me know.
... also AdrianB mentioned other groups that may be looking at
that.
Travis: Myself and Domenic are collective authors of the API Design Principles
Kris: With my ISO hat one we are
trying to figure out how ISO messages would fit into an API
environment.
... I'd like to speak with you separately about it.
MarkN: Manu asked about
extensibility and I wanted to add to that.
... extensibility has a critical role in what we do (e.g.,
future unintended uses)...but extensibility can be harmful
especially in protocol design
... it can be quite counter-productive.
... there are painful memories of Web Services
... Extensibility can give some players in market extra
power
... e.g., "must understand" flags
... OAUTH2 is also a cautionary tale
... you can't use OAUTH2 unless knowing which flavor.
... so be wary of supporting lots of use cases, but then
supporting none without some out-of-band shared
understanding
m4nu: We plan to have a browser
API but also may need a RESTful API for machine-to-machine
communication....
... e.g., car needs to pay automatically at the gas pump
... to my knowledge W3C has not standardized a REST API....
shepazu: LDP
m4nu: Does TAG have thoughts on RESTful API design?
Mountie: What about CSP?
MarkN: REST is not
well-understood. I would encourage you rather to decide whether
you want to use HTTP and just to use it well
... I'm happy to help with that as well
... there's a list at the IETF coming soon for help on using
HTTP with APIs
m4nu: Is there anything analogous to IDL for HTTP design for APIs?
MarkN: <em>No</em>
Alex: We don't in the TAG do a lot of it so other communities may be more well-suited
padler: Payments touches a lot of
things...a number of the flows we can imagine like for IOT will
become increasingly important.
... we could in the payments IG use the TAG's help
... looking at things like identity and credentials, signing
messages, confirming people are who they claim to be,
ecommerce, etc.
Alex; I have the feeling that when it's easy to pay for things in the browser, people will notice
scribe: feel free to ask us for review of whatever you have at whatever stage
Kris: regarding RESTful
design...you (MarkN) sounded mysterious....
... what's a classic misunderstanding?
MarkN: In the context of
designing an API, "REST" is meaningless. REST is a style. It
happens to be modeled on HTTP but it is not HTTP
... the problem is that many people have different ideas of
what it means...so not useful to communicate with that
word.
<Zakim> AdrianHB, you wanted to ask about declarative requests
AdrianHB: The question came up
earlier about whether we should be considering declarative ways
of doing things.
... e.g., what would be a good way to do something
declaratively?
Alex: Normal declarative style we
see in HTML and CSS...that gets you to a point where you hang
information off the DOM
... that has upsides in that you can easily provide UI for
something in the DOM
... but it's difficult to both build an API that hangs together
as well as the HTML bits...it leaves a lot to come back and
do.
<mnot> The blog entry about extensibility I mentioned: https://www.mnot.net/blog/2006/04/07/extensibility
Alex: Declarative is great
because you don't have to specify much. You can increase what
is specified over time. The <audio> element doesn't give
us a good way to do processing
... so now we have to go figure it out.
... we are moving more in the direction of APIs
... and e.g., using web components.
Travis: If you start with an API you allow for experimentation
scribe: and you can see what
arises in the community and then standardize it declaratively
later.
... declarative is very portable.
Alex; Declarative leaves a lot for interpretation. Browser vendors tend to like declarative but it's painful for web developers.
ShaneM: I think we are smart to start with an API
nicktr: You spoke about asking TAG to review drafts. Is there a practice to getting that review? Or just poke someone on the TAG.
Alex: We are w3ctag on github.
DanA: Opening an issue in our
github repo is the most direct way
... we will address it on our next call
Alex: We are using FTF time to review specs
(Slide illustrating the scope)
<nick> maybe everyone should just buy an Apple TV for all conference rooms
AdrianHB: I want to distinguish Registration from Payment
DISCUSSION POINT: Will there be a "register payment instrument" in the API?
AdrianHB: There may be other execution environments where the payment instrument may be registered differently
(On payment)
AdrianHB: the flow we have agreed on at a high level is:
(Adrian prefers "matching" to "discovery")
scribe: effectively taking the
accepted methods and matching available instruments
... the matching parameters are not surfaced to the user
... if there's a payment instrument from my bank and it uses
Visa and the merchant accepts Visa...it will be surfaced as
"Adrian's Bank"
MattS: I think both options
should be available ("Visa" and "Adrian's Bank")
... I think the flow and the user interface should allow for
either "Barclay Card" or "Visa Card"
AdrianHB: Suppose I install the
"Visa App" and I log into my app and load my cards.
... when I get the choice of which payment instrument, I could
get "Visa" as my choice.
... this is more about the brand than trying to give it a
name
Cyril: Difference between Visa issued by my bank and visa.me
AdrianHB: So per Cyril's point, how you install the instrument may determine naming
MattS: I would not limit to how things work currently....there may be examples where we should not over restrict
AdrianHB: I imagine the user being prompted with a choice "Want to use your Visa?" and "Want to use your Barclay Card?" They could hold the same card information
MattS: I agree with that.
<Zakim> padler, you wanted to ask about loose coupling of registry..
padler: The one thing that popped
into my mind is the question of where the instruments are
actually registered
... are they with the browser? or with a registry service
(which holds them for me)?
... the browser can thus either have stuff or ask a service
provider for the same information
... I don't want to have to register my card again and again
with different devices
AdrianHB: Is that an
implementation detail or does it impact the API?
... We are going to standardize this in the user agent...how
it's supported could be an implementation detail....
... I've wrestled with this a fair amount; I don't think we can
specify it ... although we could recommend that browsers
support services.
padler: I like the idea of a hook
AdrianHB: The payment instrument
is an interface to the payment service provider.
... there is executable logic.
... whether it executes locally or remotely is an
implementation detail.
<zkoch> +1 to being browser decision
nicktr: It sounds like we have a decision to make whether we make it a requirement or a suggestion
DISCUSSION POINT: Do we need to provide a recommendation for how we handle the handoff between user agent and payment instrument?
scribe: for the payment request
padler: I suggest we parameterize so that we can make a choice
Laurent: One whether payment
instruments have execution logic....
... I think the payment instrument is not just one credential;
it's also authorization logic.
... there's also payment initiation logic.
... we want to keep the LOGIC outside of the scope of the
W3C
... the id part is that which we want to register in to the
browser
... that's where the regulatory impact is
... You need to display the brand associated with the
authorization logic...that's typically visa for example...in
this group we need to provide a way for the browser to COMPUTE
this information (even if we don't specify the UI)
... display of authorization logic.
Three things:
Laurent: a payment instrument is
all three; so we need another name for the "data" part since
calling it a "data payment instrument" is a source of
confusion
... we need to be able to provide the BRAND of the
authorization logic.
... it's important to the user experience
<mountie> +1 for Laurent because of same origin policy.
Laurent: When I have to select a visa card through the browser, I want one with visa + my bank brand and visa + visa wallet brand
nick: I'm not sure if I agree
with that.
... I don't know whether PayPal wants the visa brand to be the
authorization brand
... A lot of these discussions are UI-related....it appears to
me that the user agent concern themselves with UI is
potentially dangerous
AdrianHB: Should we allow
browsers to unilaterally decide which brand information to
display?
... that leaves open situations where, e.g., browser favors its
own brand
<Zakim> ShaneM, you wanted to say I don't think we can preclude external resolvers and to disagree with Laurent about attempting to require that the brand is somehow embedded in what is
(Ian did hear that "display of some brand" is important)
<Laurent> +1 to talk about discovery / matching algorithm in the group
Shane: We need expressly to not
preclude solutions that lie outside the browser.
... e.g., "Google, you must not preclude me from using a
different selection mechanism"
(Just to pick on Google as an example)
<padler> +1
<Zakim> m4nu, you wanted to ask browser position on local storage or 3rd party storage of payment instruments.
m4nu: We should very strongly say "This is about user choice."
<Laurent> +1
<padler> +1
<mountie> -1 user consent should be moderated.
<nick> I think it’s a noble goal, but I don’t know if it’s possible for a W3C spec to enforce it in any way
Brett: I want to stay away from specifying UI. If a payment instrument is registered with an Android app, the branding would go along with the branding. If we specify a manifest file, then the logo etc. could be part of the manifest file
<kazue> +1 user choice
Brett: You don't have a canonical representation of a Visa card....you can get a card multiple ways and can't guarantee it will always be displayed the same way
<Zakim> m4nu, you wanted to ask browser position on local storage or 3rd party storage of payment instruments.
m4nu: Will browser vendors only implement local storage?
AdrianHB: May depend on
platform.
... e.g., on mobile it may happen the way it happens today
zkoch: I think it's too early to
say
... we'll share when we get to that point..there's too much
unknown
... more clarity will come as we make progress
lars erik: I strongly feel that a specification SHOULD NOT go into detail about how a browser should display something
scribe: the user registers a
payment instrument
... wherever I find a manifest file and it "installs in my
browser"
... is the idea that this is shared across browsers?
m4nu: We want cross browser and cross device.
<nick> cross browser / cross device has, to me, substantial privacy questions that remain unresolved
AdrianHB: The manifest file could
be stored "somewhere" but not necessarily in the browser.
... the browser could request it from a remote service.
Mountie: User consent should be
moderated
... if the payment instrument is controlled server-side, maybe
we need a different UI
... and in that case there may not be the same need for user
content.
AdrianHB: What is the user consenting to?
Mountie: Both registration and
payment
... When instrument is controlled user side, then we need
agreement on the user via some kind of UI
... but if the instrument is server side (e.g., PayPal) we
don't need UI...it's supported via the server.
AdrianHB: Potentially there are payment instruments built into the browser, rendered by the browser
MattS: I think we should allow all the different various rendering options
AdrianHB: I want us to explicitly not specify UI...just information that enables whoever will render to do their job
Laurent: I think we need to
consider the use case of when I install paypal and
automatically all my credit cards registered with paypal are
registered with the browser.
... open question to the group...I could see a potential need
for a query to find out whether there is "at least one
instrument that matches"
AdrianHB: Payment instruments
will have an origin.
... either the origin where the manifest comes from, or when
you install the app where it came from.
... when you visit a domain, there is some additional
functionality that the instrument provider can execute like "is
my instrument already installed"
... We may want to consider an origin-bound API call. You can
test for the existence of an instrument but only if the origin
of the requestor matches the origin of the instrument that was
registered with it
zkoch: Generally speaking I think that you can rely on the browsers in many ways to address the "no instrument" situation.
<ShaneM> if navigator.paymentRequest...
zkoch: we also would check to see
whether the (payment) API is implemented
... if the user has no payment instrument installed, I expect
the browsers will offer some solution that is a helpful user
experience
... I think we can mitigate this on the browser side without
specifying it in the API
Laurent: Should we recommend it?
AdrianHB: Maybe in the card case
where browsers have card storage mechanisms.
... they could synthesize a payment instrument to support the
legacy schemes
... maybe we provide guidance in the card spec Note
CyrilV: When you take the example
of a paypal account and put lots of instruments in it.
... we should focus on payment instruments that are the "first
instrument used" and if there are different systems in the
background we should forget it
... maybe in the future we look at these "reloading
systems"
... so the case of paypal is that it's an instrument, no matter
how it is reloaded
<ShaneM> +1
rbarnes: What's the value of the "payment agent" level of abstraction?
AdrianHB: As a user I've registered to pay with paypal
rbarnes: There's a slightly higher level point here which is that the payment instrument may have multiple choices
ShaneM: there may be payment instruments that work that way, but paypal is not one of them.
Cyril: Paypal is not authorized to display my account information
Laurent: replace paypal with MasterPass
AdrianHB: Ambition here is to be able to load instruments for example that are more secure
<ShaneM> Dashlane is another example
<ShaneM> oh - and so is LastPass
AdrianHB: payment experience can be upgraded in the background
Mountie: If server wallet exists and there's a payment instrument, how do we discover the payment instrument on the server side?
AdrianHB: CoinBase is an example
of dealing with blockchain.
... you install a CoinBase wallet
... you could have a CoinBase wallet with a bitcoin option or a
coinable option
CyrilV: We have to manage the form of payment instrument and the underlying reloading
AdrianHB: All we care about is matching merchant payment instrument with the instrument (not potential instruments within it)
<dwim_> btw, will AdrianHB share the slide?
MattSaxon: I've written up the actors in a payment
… PSP, Merchant, Shopper, Browser Form Fill
… Legacy card payment
… this isn't technical, just the actors present
CyrilV: are we describing multiple pay flows?
MattSaxon: Merchant (Payee) PSP, Merchant (Payee), Shopper (Payer), Browser Form Fill, Shopper (Payer) PSP
… shopper goes to merchant website
… merchant website makes an offer to shopper
(discussion of flow, photo to follow)
MattSaxon: I'm including Merchant
(Payee) PSP and Shopper (Payer) PSP, because the API
descriptions this morning only included Merchant (Payee),
Shopper (Payer), and Browser Form Fill
... I don't think a "standard credit card flow" exists
<mountie> Legacy Card Payment (Merchant Hosted) : http://goo.gl/C5K0tZ
nicktr: let's look at this as it applies to the 2 models presented today
zkoch: the flow for our proposal is similar, but encapsulates some of the steps as a data blob
(discussion of optional Shopper (Payer) PSP step)
<Zakim> m4nu, you wanted to worry about making phishing easier
m4nu: if we're documenting flows, and this the PAN being returned… we do care what happens in a 3rd-party app
MattSaxon: there are 3 flows here:
… legacy card payment
… automatic form fill
… autofill via a 3rd party app
<Ian> ACTION: MattS to write up three flows around legacy card payments [recorded in http://www.w3.org/2015/10/28-wpwg-minutes.html#action01]
m4nu: let's differentiate this in the spec, this makes it easy to phish
<Ian> m4nu: Heads-up this leads to risk of phishing
<nick> I disagree, I don’t see an increased risk here
m4nu: we make it automated, we make it easier for the user to send their card info
<mountie> http://goo.gl/5Ah5u9
mountie: maybe we should consider the payment instrument … ???
… the money flow changes
MattSaxon: I don't think it does change
… it doesn't mask the card info
nicktr: we're not talking about the future yet
AdrianHB: I think we can achieve both the legacy flow and improve it slightly
… for the PSP to do this, they do need to do something different, like provide a key pair
… it's not much innovation, just encrypting the PAN
<Laurent> +1
… only marginally better, but better
MattSaxon: that's an opportunity with or without this
AdrianHB: I think we need to start prototyping early
nicktr: it would be great to include tokenization into user flows, but let's have that conversation later, it's complicated
<Zakim> m4nu, you wanted to note that encrypting doesn't solve the phishing problem
<mountie> redraw with Token : http://goo.gl/rfMDPS
m4nu: we are going to be sending it back and forth, encrypting to the attacker doesn't help phishing
… we should know we're going to help phish faster
MattSaxon: we have risks, we need to document them and suggest mitigation
nick: autocomplete already autofills forms… but there are ways to mitigate that today
… we can verify actors who claim to be someone
… browsers do offer some solutions today
Rouslan: let's document the questions, and get security / privacy reviews
<m4nu> +1 to Rouslan
<Ian> DISCUSSION POINT: How (much) to secure legacy case (e.g., to avoid phasing)
MattPisut: we need to document how the legacy flow works later
<Ian> (MattP notes this does not include the "registration" bits but otherwise accurately captures legacy flow)
nick: manu, would your proposal change this flow?
m4nu: no, it supports this and more flows
MattSaxon: my read was different… it seemed that the UA reaches directly to the Merchant PSP, past the Merchant
m4nu: no, not for a traditional pull payment
AdrianHB: this is a different
flow, … ???
... this does look like a legacy flow… even if the merchant
isn't involved at all
nicktr: from our perspective, it's the same player
Ian: is there an option that includes return flow?
AdrianHB: if the merchant host the page, the host of the page doesn't see the info
<Ian> IJ: I am hearing that one knob even in the legacy system is "the return origin is different from the initiation origin"
MattSaxon: let's articulate the many existing legacy flows
m4nu: we haven't covered 3D
secure, ???, ??? yet
... there are lots of jumping off points
<Ian> scribe: Ian
MattS: One value of digging into
the flows is to see the subtle differences.
... we need to make explicit decisions whether to allow some
use cases (e.g., the "direct to Merchant PSP" response)
m4nu: I think there are use cases
that are important e.g., that don't put Merchant in PCI
scope
... The CG design of the API is to support both legacy and
future cases.
MattP: I am concerned about putting browser in distributed transaction flow...wouldn't you also have to have PSPs update code?
m4nu: Not necessarily.
... legacy ones get back PANs as-is
MattP: I'd hate to be the browser
in the liability flow.
... or I'd do it twice and be liable.
... PSPs may have mutually authenticated connections to their
merchants
Laurent: I think it's interesting to capture points such as:
Laurent: Maybe if we can look through the perspective of "what should we add/remove from current proposals"?
MORE FLOWS
(We'll try to capture those as well by tomorrow)
CyrilV: If during offer we add public key, the browser could encrypt the PAN
AdrianHB: I think that there's
some value in our recognizing the hats of trying to be PSPs and
trying to be scheme operators here
... if we come up with an abstract flow and we standardize it
today
... we should ask ourselves "What do I care about as Visa? What
do I have to tell to whom? How does it change the flow that
happens out there already?"
... e.g., Visa might say to PSPs "now you need to tell your
merchants to do the following"
MattS: They have solved the problem you are describing
AdrianHB: I think that the flow we design will be simple and these options will be scheme-specific decisions
nicktr: We need to document "silent order post" use case
(Stripe, Braintree)
nicktr: Schemes don't typically
talk to acceptors
... ...can we get Visa Europe to join the WG?
<mountie> 3D Secure Payment Flow : http://goo.gl/pmqTjH
<Rouslan> Everyone, here is what I am thinking about APIs for handling the legacy case: https://docs.google.com/document/d/1pBSMclozKhKlKHxd3MsG4K1bR2zr3j57oBDPKoakltk/edit?usp=sharing . Please let me know if that's we're talking about or I am way off base. Some examples included in the doc.
