See also: 23 March minutes · group photos · IRC log
[Ian slides on Payment App issues]
ian: going to go through main
issues and look for WG feedback
... 4 main themes used to regroup these issues
... 1. Reuse web tech
... 2. Impact of Payment Req spec
... 3. Data exchange with PR API
... 4. Merchant preferences
[ian talking through latest proposals - see slide 5]
ian: Regarding presentation of finer grain instruments in the browser sheet: if you can see detail and click directly, you can reduce the total number of clicks to make a payment.
zkoch: there's a few aspects to
the options discussion. It's fundamentally a UX thing so we
can't have normative reqs
... why I don't like it in practice:
... 1. space limited on mobile
... 2. consistency in display of same instruments (cards shown
differntly by diff apps)
... 3. high likelihod of duplicates
... 4. not convinced by benefit if you still have to end up in
the application
... chrome has strict design rules and others have other rules
we should let everyone deal with this themselves (including
apps)
rouslan: i often hear argument that the browser can decide if it displays options or not but I think that is poor as apps will need to define two handlers
zkoch: you'll usually find the ecosystem settling on lowest common denominator so if one browser doesn't support then none will
tommy: I disagree with zkoch on point 4 above. If the user has configured the app for optimized flow then the app may never even need to show UI.
zkoch: agree this is possible but don't see this being used in the real world.
tommy: for low sums (micropayments) then I see this happening
zkoch: this is an optimization. I see the challenge of simply getting the apps into the selections screen as hard enough. lets do that first
adamR: this is a checkout flow and clicks increase abandonment. we don't want this to be worse than the current web experience.
dick: +1 to adamR
... user experience where options are surfaced early is v
important
... the options the user has are hidden which is also
problematic
zkoch: this pushes the UX
problems onto the browser. The app can have defaults set at
registration so that the user doesn't need to choose an
instrument.
... payment apps still need to solve UX problems at
registration
mathp I foresee UX problems if each payment app can show, say 3-4 instruments inside the browser UI
dick: issue is that the user may not understand what options they have available if they pick the payment app (they don't remember what instruments they registered)
cyril: this seems like the
discussion is about the merchant concerns (i.e. cart
abandonment) whereas for financial service providers we care
about the user's concerns like consent of the payment
... it is important that we don't forget that the user always
consents to a payment
manash: stats on conversions show that card on file converts 40% whereas for example PayPal 1-touch has 80% conversion so there is evidence that conversion is impacted by clicks
zkoch: when a PayPal user pays
with PayPal they just pick PayPal. They seldom care what the
underlying instrument is.
... this optimized checkout flow is still possible.
ian: we have in the spec a
definition of a data structure and no UX reqs. We have 3
options to go forward:
... 1. drop the part of the spec that enables payment apps to specify instruments in detail
... 2. keep that part of the spec, so payment apps can provide that data to browsers. But browser chooses what depth
of display they implement
... 3. keep that part of the spec, so payment apps can provide that data to browsers. Browsers must make available to user all the instrument details (in some way)
[ian takes a strawpoll on the WG feeling about these options]
alan: could option 2 include
guidance on display?
... there is a power shift from merchant to browser. We are
giving browsers more control than they have today.
12 votes for option 1
12 votes for option 2
4 votes for option 3
manu: for those in favour of option 1, is the primary concern implementation complexity?
ian: I heard many concerns (beyond that)
nicktr: I'd like to point out an inconsistency in the existing implementations - essentially "basic card" handler is extra privileged because it displays all the instruments, whereas the other handlers (bobpay, androidpay as examples) only display origin/handler name
marcos: my experience is that we
are trying to do too much too fast. We should be more
incremental.
... we have good infra in place. We still have many things to
solve so let's start with option 1
rouslan: +1 to marcos. primary
concern is complexity. Let's do 1 first then expand to 2
... also UX concern on mobile
... in chrome we prefer to not use basic card so they get
pushed to the bottom fi there are other options
<nicktr> notes (in response to Adrian's question) that this does seem to be another example of the basic card fudge getting in the way (see also short names, filters...)
dezell: most money spent on payment apps (traditional) is spent on preventing user deception
adamr: I don't think option 1 is backwards compatible with 2 or 3
<zkoch> finnneee
adamr: i think 3 is the way this should work but I have sympathy for implementers. I see option 1 as deviation from the correct order of constituencies
mike_mastercard: I can sympathize
with both sides of this
... apps in market today have their own experiences that
differentiate them
... so I am inclined to say 1 but I also sympathize with the
desire to have an equal positioning with basic card
... there is always a learning process the first time you do
something so we should not neglect the opportunity to optimize
that
ian: propose the TF will take
this input and come back with updates
... [discusses new issue - 116 which we'll not cover now]
... another new issue which needs to be logged relates to
syncing of state between payment app window and payment app
service worker
marcos: there are many other issues we need to still figure out like additional permissions and other overlay windows etc.
ian: yes, so let's pick this up
in the TF
... big issue to discuss is impact of payment handler on PR
before PR can go to CR
[back to slides - do we have what we need?]
<zkoch> ^^ yes
<marcosc> MC: should also mention memory issues on mobile with running 2 browser windows at the same time each running a service worker
<marcosc> (adding to minutes)
<dezell> May I suggest (I know everybody knows about this ) https://www.owasp.org/images/f/f8/OWASP_Top_10_-_2013.pdf especially focusing on A10, A8, and maybe A3.
ian: have those that have done payment app testing got feedback on PR API?
rouslan: no problems for us. no changes needed to PR API required
ian: confidence in PR API has gone up since Lisbon
<Zakim> manu, you wanted to waaait and to ask whether we're actually going to discuss that last item.
nicktr: we will discuss later
ian: propose that PR API spec removes mention of using line items for details of products
zkoch: okay but had assumed that is just Google's position
marcos: people will use this for product items
<Zakim> manu, you wanted to mention that I thought we WERE going to use this for product details.
manu: this is why we objected to this before
nicktr: implementors are saying that if it exists people will use it but the WG wants to give strong guidance on how to use it
PROPOSAL: Drop the mention of "products" in the displayItems definition
[filed as issue 477]
ian: can the payment app get permission to get user data like email and shipping from the browser
marcos: this is already available through autofill
nicks: sometimes this data is not just auto-fill data. eg: current location
rouslan: I have heard more important than shipping is email. This allows payment app to optimize user experience
frank: I disagree that autofill is enough. If the user chose an address already then why make them choose it again in the payment app
zkoch: a) the privacy consent messaging sees very hard to figure out b) why is that critical information?
frank: b) we use it for real time credit?
marcos: there are ways to hack around this anyway
<Zakim> manu, you wanted to agree w/ Marcos, note that we may be working on that via Verifiable Claims or Credential Management API, multiple reasons for it to NOT be dealt with in this
manu: there are not core use
cases that require this
... and it feels like we could push it off until later
adamr: for things that don't change often it's likely that the app will already have this info
<nicktr> notes that as push payment use cases increase, the requirement to do fraud screening against things like shipping address will increase on the payment app side. In other words, more use cases like Klarna...
adamr: second, this is not trusted info so we shouldn't treat it as such
<zkoch> AdrianHB: We’re taking first world, card-centric view of this whole thing. Real time credit is a reality of developing world. Becoming a big industry … every scrap of data increases chance of credit. Making this more difficult is just making it more difficult to give people credit. I think we're taking a very first world, client-centric view of this. Realtime credit is a big thing in the developing world, it's important that a provider can get any scrap of data they can get to. Making it difficult for them to collect that data is going to make it difficult for them to provide credit.
<nicktr> +1 to adrianHB's point - this is another example of the inherent skew to cards in the spec
frank: we still do verification. we don't assume the data is trusted
adamr: this sounds like an optimization
frank: yes, but so is a lot of what we are discussing
nicktr: are there implications for Payment Request API?
ian: no, this would all be spec'd in Payment Handler spec
ian:
... point has been made that merchant ordering of payment
methods may be sufficient
... also there is a complex layering of preferences between
methods, apps and browser preferences (e.g. rouslan said
that Chrome puts its own stored basic cards at the bottom of the
list))
alan: Use case: Merchant wants
the user to use the merchant issued instrument. Also express
that a 3rd party app should use that instrument.
... also notion of instant credit may be available for specific
merchants
1. express pref as an app
2. express pref for instrument within 3rd party app
3. express pref for payment method from specific app
ian: browser can try to match app and request based on origin and merchants can also define their own payment method and have their own app that is the only app supporting that method
nicktr: there is a way to order by method but not by app/handler or instrument
ian: observation, on the question of do we have what we need to take PR to CR, let's have that chat later
+1
manu: we want to deploy this
using web apps and we don't see a clear path to doing so.
... so the question is are we interested in doing a
polyfill. There is a tradition in W3C that we give a polyfill to people
so they can experiment. I think it easier to go to CR if the group
knows there is a polyfill for handlers being developed in
parallel
ian: I think we may learn more from the polyfill but not in time to impact a decision about going to CR
manu: is anyone else interested in working on a polyfill?
marcos: I agree with manu but don't have the same conclusions. There are payment apps already working using PR API so I like the idea of a polyfill but not as a means to help learn more about PR API
manu: not enough web based payment apps and those being done are all on Tommy's build
ian: Getting implementation experience is critical, and so I support getting that. But I don't think we need to slow PR API getting to CR while we get payment handler experience.
nicks: I am wary of tying PR and payment handlers together because of dependencies on Service Worker in payment handlers and not in PR API
nicktr: any other strong feelings
about readiness of payment handler impacting PR readiness for
CR?
... my sense is thag the handler spec is much more mature and
the general confidence in it is sufficient
... to take PR API to CR
ian: I advocated taking PR API to CR last September but there was pushback. And in hindsight it seems the WG made a good choice. Is PR API much improved?
marcos: yes but it could still change a lot. CR doesn't mean it won't change.
ian: testing is not on the agenda but we have made a small amount of progress on it. there are companies that can help with this if any members want to sponsor this.
marcos: remember we can't leave CR without a full test suite
adamr: if we go with option 1 (earlier) then we have a lot of revisions to make to the payment handler spec
<Zakim> manu, you wanted to clarify that his position has softened.
manu: I am not saying we can't take
PR API to CR without a payment handler polyfill.
We should set realistic expectations
about how long we might be in CR
... this impacts merchant merchant adoption
... how easy we can show devs that this works
ian: do groups publish "official" polyfills?
marcos: some do. WhatWG has a great streams polyfill. so good.
ian: What is not a W3C Working Group, and that is outside the Rec track requirements.
ian: alan raised issue yesterday about apps exposing functions they have to browser
alan: happy to take that into TF dicussions
<nicktr> About the Basic Credit Transfer Payment payment method specification.
vkuntz: Here's how we came up with the data fields => Common global implementation market practice group (CGI-MP) did this work. CGI-MP is driven by customer demand for multi bank coordination of implementations
[Vincent reviews a bit of the history of the CGI-MP; will defer to slides once available]
vkuntz: We validated the previous
SEPA draft against CGI-MP and found only a small number of
discrepancies that we addressed
... CGI-MP has produced templates for ACH payments, for
cross-border payments, etc.
... For me a recurring payment is a direct debit
nicktr: I would say rather that a direct debit is a kind of recurring payment
adrianhb: Who are likely implementers of the credit transfer spec
cyril: Companies in europe are
developing APIs to initiate credit transfer
... The timing is good to share with European companies this
work since they are working on this sort of thing
adrianHB: We need to validate the payment method with Atos or Sofort or Ideal or a bank
Ian: We are starting to do that (cf. outreach to NACHA); more necessary.
CyrilV: BPCE will consider implementing this
vkuntz: 30% of payments in Belgium on the internet today are done through transfer
zkoch: Looking at the spec, does
it make sense to have a generic credit transfer spec, or should
there be a series of scheme-specific specs?
... I am not sure how IBAN is required in practtice
vkuntz: What is required is account number.
(Vincent shows the ACH documentation and mappings to CGI-MP)
MattS: We want to get to FPWD to
get feedback from ACH and BACS and SEPA and other
schemes.
... we have sense that there's commonality; need to verify
this
zkoch: We support credit transfer and want to publish this....I am happy to advocate getting feedback
<manu> Ian: Zach had mentioned, "can you find a common data set"? We had the word of Cyril and Vincent, but that's what led to the NACHA outreach, that's what led to Todd getting this document to us. I think FPWD would help us to raise awareness. It would also help wrt. other Credit Transfer systems. We're in the early phases, filtering (here, on networks and countries) looks like it could be useful here.
Frank: We can help implement to validate the spec
MattS: Worldpay (and other aggregators) would be interested in implementing this. We will need a polyfill to experiment
vkuntz: Today people are routed to banking sites to log in
AdrianHB: That arose in 3DSecure...it required a redirect...do you know if the schemes have a way to get to the bank without a URL?
nicktr: Berlin group and other groups are trying to build read/write APIs....so you don't need to screen scrape web sites
adrianHB: I suggest that part of validation of this payment method involve a native payment app
CyrilV: In the spec, we may need
to change the name from IBAN to "payeeBankAccount" and then
include comments about what that will mean in different
jurisdictions
... so yes, we may need to review the field names to make them
more generic
<zkoch> Random question: Do we have a known set of possible “networks” that would be in here? SEPA, ACH… are there others?
<zkoch> Would we define those somewhere on w3.org like we do for card networks?
<Ian> Yes, as we have done for card networks. We don't have an approved list yet. We just have examples in the spec.
<zkoch> The bit in the appendix? ACH, SEPA, BACS, and CHAPS?
<zkoch> Yes
<zkoch> Cooool
<Zakim> AdrianHB, you wanted to say that example requests per scheme may be easier than actual implementations as a start
AdrianHB: Please put examples in the spec for different transfer networks
vkuntz: I would be reluctant to
put examples in the spec since they are changing rapidly
... but +1 to examples, but maybe inked
mweksler: Why is this about credit transfer between two entities. The merchant is more fixed.
vkuntz: What you are describing is called direct debit.
CyrilV: It's hard to authorize a
direct debit due to accounting challenge
... we have more credit transfers in france than card
payments...lots of b2b credit transfers
vkuntz: Direct debits can be
revoked up to 60 days; another reason people like credit
transfers
... credit transfers are generally not revokable (except for
some exceptions)
<MattS> Added issue 46: Push, Pull, Sync or Async?
Tokenized Card Payment method specification
roy: the spec has changed a lot;
mostly things have been deleted.
... it's now an extension of basic card
... the filter is supportedTokenTypes (which takes two
values)
... The other three fields are cardLast4, tokenType,
tokenRequesterId
nickTR: TokenrequesterID is who the token service provider gave the token to
Roy: Spec shows some examples of inputs and outputs
MattS: The PMI is card-token....how does this spec relate to what others are doing?
Roy: This spec has no notion of merchant onboarding
MattS: So is FB PMI a specialization of this?
Roy: Yes
... It's easy to adopt this spec
... this doesn't require other steps like merchant onboarding
that involve friction
... this supports easy one-time use tokens, auth for certain
amounts, ....
nicktr: I am really glad that
we've got this payment method but I think there's a lot of work
still to do on this
... one of the concerns that I have is that it's a bit uneven.
We talk about EMV tokens and issuer tokens
... but the Stripe token is a gateway token (not in
scope)
... issuer tokens are effectively proxy cards...you can run
those on basic card.
... merchant can't tell in that case
... There's also a mismatch between "emv" with our card network identifiers (some of which are not emv)
... we are extending a spec that isn't bound to emvco to a
domain that is
... and also the extension of the spec to use CVV for a token
makes my hair stand up
... that's not where token would sit in an emv transaction. I'm glad we have a framework to have a
crack at this, but I think there's more work to do to align and
make it complete. Regarding EMV and this
spec; this would fall within the scope of a W3C/EMV
conversation
alyver: Nick said my part....regarding terminology....for android pay....I've seen "network" and "gateway" tokens and we should perhaps use those terms
Roy: Gateway tokens not included
here since inputs and outputs are so different
... each would likely be its own payment method
AlanSamsungPay: I don't see what the goals of this spec are.
NickTR: The use case we are
trying to cover is that the payments industry is pushing
towards tokens....
... you can't process a tokenized card payment with basic card
data alone
... you need (at least) the cryptogram
Alan: Is this in the category of dynamic tokens and dynamic CVVs
AdrianHB: What entity would
provide a token for this spec?
... Is the same question as for credit transfer....who would
write a payment app for this and what feedback will they give
us
Roy: It's feasible (can be done) that FB could create tokens
mweksler: When I think about how
this would be implemented at airbnb, I think a slightly
different version could be useful - gateway
... if we had ONLY the token and not the PAN
... I'm curious what is the use case of having a token
alongside a full PAN?
... second question is how this would apply to the token-only
case
[Discussion of likely lack of commonality among gateway token inputs]
pascal: Having at the same place a checksum and a token is considered a weakness and is forbidden by PCI/DSS. It depends on how the token is produced
zkoch: I think the use case you
outlined is what we want...right now merchants have to
establish N relationships and this is costly
... I'd like to figure out how to move this spec forward to
something useful
... I think it would be useful but want industry experts to
step up to help fix it
nickTR: That's the motivation for
this spec. Matt and I would be happy to volunteer for
this!
... I'd like to hear from the other XPay vendors
zkoch: It is helpful to have something to point to when we have internal discussions
PROPOSED: Take up Tokenized Card Payment as a work item
AdrianHB: I want to clarify that the scope includes gateway tokens
PROPOSED: Take up Tokenized Card Payment as a work item with gateway tokens in scope
MattS: I think a lot of discussion has jumped around....in the case of Credit Transfer we've established that there is commonality
PROPOSED: Take up Gateway tokens
(and NOT issuer or network)
... Form a tokenized payment task force
oyiptong: Zach mentioned a desire
to move forward. I agree. +1 to gateway token flavor and I
volunteer.
... once we support tokenized cards we can make it easier for
merchants to accept payments
nickS: I'd rather this be framed
in terms of networks and gateways
... it's not particularly helpful to speak to XPay.
... Apple Pay supports other types of cards than EMV
cards
... a lot of wallets like to add additional security
features
<MattS> +1 to Nick's reframe
nickS: I could see people using
the responses with custom data
... want to see more input from networks on this spec
<Zakim> Manash, you wanted to discuss cloud based tokens.
Manash: Once MC joins the group
we'd love to contribute
... tokenization is important both for XPay and browsers
NickTR: I hear consensus that we should do this work. The proposal is to form a tokenized payment task force. They would take the draft as input but could explore areas like different flavors of tokens
Interested in participating: NickTr, Olivier, Roy, Michel, Andre, DavidM, Ken, NickSFence, MattS
<manu> Ian: Roy, are you going to take charge of that Task Force?
Roy is the chair of that task force
<manu> +1
PROPOSED: Do that task force!
<rouslan> +1
<oyiptong> +1
<AdrianHB> +1
<pascal_bazin> +1
<nicktr> +1
<zkoch> +1
<mweksler> +1
<dezell> _1
<dezell> f+1
<alyver> +1
<dezell> +1
<DavidM_GSMA> +1
<fdold> +1
<frank> +1
<Max> +1
RESOLUTION: To create a tokenization payment method task force
Payment Method Manifest File proposal; goal is to replace with a new proposal.
Max: We have a new proposal. Have not yet updated the draft spec
Ian: Use cases involve authorizing payment apps (especially those associated with proprietary payment methods). Alipay wants the browser to verify applications are in fact released by Alibaba.
Max: Second use case is for
payment method owner to authorize other parties to distribute
payment apps that support the payment method
... Third use case is for mediator to provide improved user
experience by enabling run-time registration
... Here's how it works:
* Payment method identifier combined with HTTP Header enables browser to get the payment method manifest (JSON) file
* File includes two instructions: (1) pointer to apps from the origin that can be used (2) list of other origins that are authorized to distribute payment apps
zkoch: Web App Manifest gets a
lot of the job done, plus a couple of fields we need.
... Use case - user likes bobpay...gets a new phone....would
like to be able to install bobpay on the fly...this is do-able
with payment method manifest file
... Use case for supported origins - most of the time in the
world there is a 1:1 relation between method/payment app
... but there are cases like masterpass where there are
multiple apps for a given payment method
... we need alipay or masterpass to be able to indicate trusted
app distributors
... supported origins is just origins, not a URL
... we prefer a looser coupling so that origins can update
their manifests independently
... we piggyback on the origin model.
[Zach reviews three use cases (1) limit apps (2) the "masterpass use case" (3) runtime installation]
zkoch: The way you get the payment manifest file is by doing a HEAD on the payment method identifier
manu: Is there a use case where you have multiple link headers?
zkoch: I think that we are asserting a 1:1 mapping between origin to manifest file
rouslan: There are already points
where we can fork supported applications (1) we can mint
multiple PMIs or (2) we can add links to multiple apps in the
array
... Web app manifest has an extension point....tells you where
to add extra data
<Zakim> AdrianHB, you wanted to clarify defaults vs restrictions
IJ: I want to say out loud please require an explicit way to say in a payment method manifest file "I allow any origin to distribute an app" rather assume that is true based on lack of information in the file. This is a security issue.
<AdrianHB> propose to call it "allowed_origins" or similar
nicktr: Do we need new explicit language in PR API to talk about the behavior of the mediator
IJ: There MAY be a dependency of PR API on this ... or at least we want to make clear that this can affect matching. That is: if a payment method restrictions the origins of eligible apps, those apps should not show up as matching apps. Thus the mediator needs to know about the payment method manifest instruction. It could be that there is no hard dependency on payment method manifest, but a reference to it might suffice. See issue 478.
mattS: Are there performance issues?
rouslan: Maybe for more than
10000
... maybe useful to have a server-side solution in some
cases
... but there are also limitations there
zkoch: I think caching plays a role in implementation
NickTR: Should PMM be in PMI?
Ian: I prefer not since PMI mature; let's get that to CR
zkoch: Agree that PMM should be separate
zkoch: Do people feel this is a
good idea?
... We need this to do third party payment apps; Alipay needs
it too
... I would like to do this in a way that plays nicely with
Payment Handler
PROPOSED: Take up payment method manifest as a work item with Zach and Max as Editors
<AdrianHB> +1
<nicktr> +1
<Ian> +1
<rouslan> +1
<alyver> +1
<Max> +1
<manu> +1
<DavidM_GSMA> +1
<pascal_bazin> +1
<fdold> +1
<dezell> +1
<jean-yves> +1
<zkoch> +1
<mweksler> +1
<Roy> +1
<Tommy> +1
nickTR: Anyone see this as a bad idea?
(NO hands)
RESOLUTION: To take up payment method manifest as a work item
Ian's presentation on getting to CR, which includes a checklist and a first pass assessment of how we are doing.
Ian: Getting to CR...
... Good to understand what the process requires for CR... CR
means "Candidate Recommendation", which means - we're ready to
implement.
... But first, getting to CR.... administrative things, we make
a decision - it's a "call for consensus" - Chairs assess
consensus, it's our guide for talking w/ the Director.
... We need documentation on substantive changes, we'll point
to Github repo for that.
... We have 3 issues lists, we are going to postpone issues,
closed all other issues... That's the role of the issues
list.
... Are there any formal objections on the work? Not aware of
any.
... Even though we don't have provably interoperable
implementations yet, we should show them the demos for
PaymentRequest API.
... For CR specifically, have you met WG requirements, have
there been changes to dependencies?
... How long will CR last - during that time, you receive
comments on the spec... those comments will typically be from
outside of the group.
Marcos: We have to keep a list of that... disposition of comments.
Ian: Before you go to CR, we need
wide review... pretty good footing, but least good
footing.
... I sent out note to groups for review... have met with
Privacy Interest Group... we're on the W3C Technical
Architecture Group of groups list...
... We go on Github issues list, and get feedback... Baron and
Leithead have actions in the TAG.
... a11y folks provided feedback, we want more formal eval from
EMV, PCI, implementation from parties not in the room.
... I think we're okay there, but external review would be
helpful.
... CR enables this ability to say features at risk, if we
don't get two interop implementations, we'll drop them.
... Are there features at risk. Default expectation for leaving
CR is two implementations. We may want to say more.
... progress on payment apps, add requestID, test suite
progress...
... Do we need to invest more in testing to get our of CR, do
we do that?
nicktr: CR provides IP exclusion opportunity.
Ian: There is a new window for
exclusions that is 60 days long, covers differences between
FPWD and CR.
... In the first window of opportunity Visa exercised
their right to exclude which we addressed in the PAG.
A new exclusion window opens up for 60 days at CR.
nicktr: Orgs need to figure out
how to deal w/ IP issues and CR.
... How quickly do we want to go through CR?
Marcos: We would like to be a part of CR testing... we'd like to wait even longer if we could get more.
AdrianHB: You listed test suite as implementation experience, test suite isn't implementation expereince.
Ian: Test suite is not itself a requirement. The requirement is to show interoperable implementations, and a test suite is useful for doing that. Typically a group creates an implementation report that includes (perhaps among other things) indication of which implementations passed which tests of the test suite, or explanations of why some tests were not passed.
AdrianHB: What about coverage?
Ian: The default is that we cover (normative) features in spec.
AdrianHB: Can you do normative but optional.
Marcos: We don't have any of those.
AdrianHB: People have feature detection, payment handler is an example, this is how we want wallet to work, possibly.
Ian: You should have implementation experience for optional normative features.
AdamR: If necessary we could split the optional features out into another spec.
dezell: Are there no features at
risk?
... Things like the wallet could be a feature at risk... if you
have things that you think might be optional, it's a good idea
to make them features at risk.
Ian: Expectation is basic card is
a note
... So, we don't need to do anything w/ that...
AdrianHB: It's a note, do we write tests for it?
Marcos: We may want to make it a spec
nicktr: We may not want to do that conversation now.
zkoch: currencySystem
Ian: A reminder about this feature: it allows people to refer to currencies not yet in the ISO standard by pointing to other repositories and entries in those repositories. I don't know if we have any experience yet with people using that feature. It was for things like Bitcoin and Ethereum at least.
marcos: We need implementation experience to understand it better.
Roy: The billing address concept seems problematic...
Ian: That feature isn't in yet...
so it wouldn't be a feature at risk.
... If we're in CR for a year, and we define that feature and
get impelmentation experience, at that time we can find the best process
for including it...
... Any objections to marking currentSystem as a feature at risk?
(No objections)
Ian: Are there any other features?
zkoch: That's the only one I can think of...
Marcos: It'll be marked in the spec as feature at risk...
AdrianHB: If it's marked as at risk - provides additional incentive to show that it's useful.
Ian: The minimal expectation in the W3C Process is "two interoperable implementations." Is that the only thing we expect to show when we request to advance to the next level?
nicktr: We had a conversation
about payment app, and in terms of ordering, can we take Payment Handler API to
FPWD first.
... We need to examine if we want to put exit criteria to CR to
PR on maturity of Web App piece.
AdrianHB: We want implementations
on mobile and desktop?
... I think we need two implementations on both.
zkoch: No
Ian: We have implementations on mobile, some on desktop...
mattP: We have implementations on both mobile/desktop - it'll be there, Windows works on both.
Marcos: Who wants to tie implementations together Payment Handlers and Payment Request?
AdamR: Yes, me.
marcos: Different DNA in implementations is good.
nicktr: Any other exit criteria
Rouslan: Two implementations, one from Samsung/Chrome - not same rendering engine... browser process is different.
Ian: Two things - do we have
confidence in Web App manifest in some way, then what to say
about mobile vs. desktop.
... Two of each, any strong objections?
A few objections noted ... unclear whether they're strong.
Alan: Is there criteria for the assertion of leaving... test suite?
Ian: Usually, showing "all green" (i.e., tests passed) in the implementation report.
AdrianHB: We're saying what we hope to achieve...
zkoch: Everyone has minimal time, priorities, etc... that doesn't reflect nature of the world... traditional is two implementations, that seems sufficient.
AdrianHB: Mobile vs. desktop... implementations differ between desktop and mobile.
Marcos: We turn off UI... that's what we're testing.
adamR: I've heard issues raised
pertaining to user experience to justify design experience...
that makes it valid to say we need to have multiple renderings
of this, multiple form factors before we consider this
done.
... We don't want to get into a position of where we don't have
experience before exiting.
MattP: It's the same code base for us... if we pass test criteria, it's not going to matter...
<AdrianHB> manu: I thiught we already had 2 impl on both desktop and mobile
<AdrianHB> Are we saying 4 different companies with 2 diff form factors?
<Zakim> manu, you wanted to ask if we don't already have two different implementations.
Ken: From an Amex point of view - we'd be advocates that mobile and desktop are done... device doesn't always provide distinction between mobile/desktop... desktop transactions and purchasing behavior, have legs... product development perspective would be good.
David: I understand where AdrianHB is coming from, proven product that works... two different code bases, solution is the same... if you are implementing on desktop, implement it on mobile.
<Zakim> AdrianHB, you wanted to say that implementation experience can't just be technical compatibility with spec as it is today
<Zakim> manu, you wanted to ask AdrianHB which implementations he thinks we have on mobile AND desktop...
AdrianHB: If we limit ourselves to do implementations are one for mobile and one for desktop, we may not have it complete.
Marcos: It has to interoperate... it doesn't happen in vacuum.
AdrianHB: We need to have two implementations so there is discussion around things that are happening.
mweksler: Another perspective,
tension I sense is between how much we want to constrain the
exit criteria, trusting our future selves for exit
critiera....
... The counter proposal seems to be a bit more strict.... I
like the proposal with more wiggle room.
AdrianHB: As with everything, when we leave wiggle room, why bother... if committment is when we get there.
zkoch: Let's just do 2 and 2.
PROPOSAL: Two implementations from two different vendors on both mobile and desktop.
<adamR> With that proposal, I see no reason to push my point. If the proposal changes, I’ll want to requeue
That proposal carries based on number of hands raised.
Ian: What's the goal of Web-based Payment Apps exit criteria?
nicktr: We're trying to protect that charter requirement...
nicks: I would have to discuss w/ my WebKit colleagues ... we may object to that.
Ian: I'm not hearing objections to take Payment Handler to FPWD. This is a separate question about the relationship between Payment Request API CR exit and Payment Handler.
Roy: I disagree that there is no dependency between PR and PH APIs... there is a lot of useless stuff if we don't have web-based payment apps... so, I think we've failed if we never get web-based payment handlers implemented.
zkoch: We'd love to see a 3rd
party ecosystem...
... Mozilla is in favor... we don't want to create dependencies
on one or the other... let's get payment request out there,
move it forward... happy to support PaymentHandler, let's think
about them separately.
... I support 3rd party, separate and move foward...
adamR: I wanted to agree mostly with Roy... I think we failed to get a good 3rd party ecosystem out there... the right answer may bear on PR API.... how do we expres sfilter/matching criteria, it bears on PR... there are real dependencies here. We may need to change it. I agree with Nick, we need some kind of interlock so we don't need to change it.
Ian: We might set an expectation that they go to REC at the same time. We have all implementation we need before we do REC... they're both important.
AdrianHB: Part fo the motiviation
for multiple implementations on both form factors, PR API may
change when we implement 3rd party apps.
... If we have existence of decent number of Payment Apps,
maybe we can tie CR to that.
<Zakim> manu, you wanted to support what AdrianHB is saying.... exit criteria more about implementation xperience.
<Roy> +1, I assumed spec process was a good proxy for third-party implementations existing, but the latter is the goal
AdrianHB: if we combine it with multiple implementations on mobile - web-based as well, would prefer... hard requirement for Web Handler spec.
nicks: I disagree, don't see PR to have exit criteria on apps... we don't need that.
Marcos: We don't need that dependency.
AdrianHB: That would be a bad spec.
Roy: I think the problem is not that AndroidPay is good or not. it's that they're tied to a specific form of payment request.
nicks: To be clear, that is not technically true... webkit is open source, you can see that.
Rouslan: Firefox could support android pay tonight.
zkoch: You shouldn't confuse business policy decisions with implementation decisions...
MattP: It's an interesting conversation, as a group, we said payment methods and support... support of 3rd party payment apps... multiple demonstration of 3rd party payment apps, that original intent is there. Sad irony is that we're not pushing to CR.
zkoch: What's limiting ability to do it in some cases is not technology, it's business.
Rouslan: Alipay has exposed android intents in a way that's interoperable with any application out there... need to have an agreement with whoever calls them... calls into Alipay... they are a 3rd party payment app. Anyone could call into Alipay, get Alipay in their browser... Alipay needs to knonw where money is going.
nicktr: I'm finding it difficult
how this helps us meet demands of our charter.
... First deliverable (listed in the charter)
is registering digital payment
instrument... I can't see how we can object tieing these things
together... maybe right time to tie them together is not CR or
PR, want to deliver what we're chartered to do rather than
limited subset.
nicks: Our charter doesn't specify
the order of delivery
... What's in the charter that says spec A and spec B should be
tie together
... We (Apple) don't have service worker, this makes this a much taller
ask.
adamR: There are dependencies, technical dependencies.
nicks: What's in the charter that stops this from happening?
AdamR: We may shoot ourselves in the foot if we do that. where we keep changing things.
AdrianHB: There is not a
dependency between the specs, ther eis a dependency on PR on
supporting payment apps... that's the technical dependency.
Some concept of apps.
If Safari supported apps, that would probably be sufficient to
say that PR API is fully implemented in Safari.
... while I appreciate the concern that Nick raised, that there
are risks here, Zach and Rouslan make a good point, business
relationships that we can't influence directly... design specs
that don't prejudice people. Lot's that are left up to
impelemntations.
Rouslan: I thought we made a
decision to implement PR API then Payment Handler, for sequential delivery of both
implementations. this decoupling ended up making specs
orthogonal.
... We don't have payment apps? No, we do - it's hard to
integrate... kinda... intents makes it easier.
roy: Why do we care about this process status?
marcos: IP committments
AdrianHB: To implement PR, you have to get Payment Handler forward, and Apple can't implement.
nicks: We want to lock this down, multiple reasons, you end up adding something that implementers can't achieve... we did separate these two specs out, we should have put them together.
MattS: When we separated them, we wanted to progress them at a different pace...
Ian: I think we should set an expectation but not a hard requirement about getting payment app implementation to inform the PR API implementation phase. If we get to a point where there is a desire to exit CR and advance to Proposed Recommendation, those who feel we do not yet have adequate payment app implementation (to inform PR API) can object in the corresponding call for consensus. In other words, let's send a signal now that people should implement PR API, and also set an expectation that people might object to the next PR API transaction (to Proposed Rec) if they don't feel we have enough payment app experience.
AdrianHB: In the status of the document, we expect to show implementations of payment apps to demonstrate implementability of this API.
<Ian> PROPOSED: Set expectation at CR of implementation experience of payment apps (native and/or web based) to demonstrate stability and usefulness of PR API.
<Ian> (Noting that people can object when the CfC happens to go to PR)
<zkoch> +1
<AdrianHB> +1
<rouslan> +1
<mathp> +1
<DavidM_GSMA> +1
<Manu> +1
<Roy> -1, want more aggressiveness
<mweksler> +1
<Ian> SO RESOLVED: Set expectation at CR of implementation experience of payment apps (native and/or web based) to demonstrate stability and usefulness of PR API.
Ian: I'd like to hear from editors first wrt. what needs to happen before CfC.
Marcos: We have a CR list on Github (see also full issues list)
nicktr: I see 7 open issues [goes through the issues]
MattS: Also some outstanding pull requests
Ian: Also some things that have been noted (e.g. editorial stuff, other questions)
Marcos: We should issue them ASAP and assign people to work on them
Ian: Happy to help
Marcos: Over next year we can fix editorial, but we have to identify critical. We have 7 there. Are there others?
<Ian> For CR consideration, please include issue 478. Given that we know we’re going to do method manifest, we should at least look at it.
Alan: Would like clarity on one
issue: the requirements in the spec that dictate or guide the
user agents on how they will display the payment apps
... what is the current spec on that
... im unsure of where that is
Ian: I thought you were going to point to 10 of 3.3
<Ian> "The user agent MAY show payment methods in the order given by supportedMethods, but SHOULD prioritize the preference of the user when presenting payment methods and applications. "
Alan: I’m in the right section now, thanks!
nicktr: Any issues that anybody things need fixing before CfC should be marked as such. 2 week timeframe. Give editors 2 weeks to respond
Ian: Some minor concerns about
100 new issues.
... There is a balance between existing implementations and
stuff. We should note spec has been in development for a year.
So people should act in good faith. Do homework. See if issues
have been raised and resolved.
AdrianHB: Amendment. IF you want to raise issues, tag with milestone, editors may say no. Chairs can make call if disagreement
MattS: Not everyone has ability to add milestone label
AdrianHB: Raise issues and ask
for CR rec
... if disagreement, chairs can make a call
Ian: What is the statement about when?
Nicktr: 2 and 2, but open to challenges. In light of IETF, 1 week to raise issues too small
<Ian> NickTR: Please raise your issues by 6 April WPWG teleconf when we will review them to determine what issues make the list
Ian: Summarizing, 1 at risk
feature, things in status section about exit criteria (one
expectation, one # of implementations)
... didn’t say how much time. Why don’t we say on 6 Apr as
other piece of discussion editors or implementors can have
opinion on CR expectation
... todo list is essentially the issues list
... other reviews. may hear back from TAG. privacy review. can
fix those comments into the 2 week window
nicktr: lampshade where we are,
feels like there is expectation that we are moving towards
CfC
... sounds like that will happen ~4 weeks from now
AdrianHB: Would be good to know if others will object
matts: Thank you for the summary. Are we taking about PR API only?
AdrianHB: What about short strings?
Marcos: Probably too late
IJ: Features at risk is about implementation, not features we don't like. We already have implementation of short strings
Features at risk? [None]
Ian: Align with PR API
AdrianHB: Regarding payment method manifests, I think PMI depends on it
RESOLUTION: For PMI to exit CR, need at least FPWD of payment method manifest spec
AdrianHB: What is an implementation of PMI?
Marcos: There is an algorithm for
URL matching
... should just be parsing and matching
... implementation expectation is 2 interoperable
... 6 April todo list
... I need to check the spec...and am comfortable by 6 April
doing so
<AdrianHB> https://github.com/w3c/webpayments-method-identifiers/issues/
IJ: note that if we change the expectation about going to Rec, we trigger IPR things
(No move to make a Recommendation)
<manu> Ian: Who would object for Payment Handler going to FPWD?
<manu> Marcos: We have to look carefully for what's going out there.
IJ: Any objections to going to FPWD?
Marcos: My concern is going out "too soon"
Marcos...we can help with big warnings
<manu> No objections for going to CfC for FPWD for Payment Handler API
<AdrianHB> no objections to taking Payment Handlers API to FPWD
MattPi: When we went to FPWD for PR API we had implementers. who are the implementers in this case?
Rouslan: Google is one implementer
MattPi: Do we have app developers?
Ian: (We heard "yes" from: Mozilla, Worldpay, Ripple, Gemalto, Digital Bazaar, Facebook, and Klarna.)
<manu> Ian: When CfC comes up, you can say +0 or +1....
* wallet granularity: none or some but not required to display
* payment app instrument ordering (and relation to payment method order)
* event.OpenWindow()
https://github.com/w3c/webpayments-payment-apps-api/issues
NOTED: Nobody asked that these be RESOLVED before going to FPWD.
Frank: Please add the issue about payment apps getting customer data; I'll add to the issues list
Ian: We will ensure that these four issues are called out in the spec and perhaps general shape as well
rouslan: None of the issues have an impact on PR API.
Marcos: Please also get rid of respec warnings
Ian: +1
Marcos: We also need a stricter
review process
... Please also rename the repo to reflect new spec name
NickTR: Time scale?
Manu: Can we do it after PR API?
MattS: Would rather see them all the same time
Ian: I will try to get Payment Handler API to FPWD sooner than the CR. That may be easier because we won't have to resolve issues, just ensure they are marked in the spec.
<nicktr> notes a strong preference to CFC Payment Handler API FPWD _before_ the CFC for PR API to go to CR
Ian: It seems we will not request FPWD of the tokenized card payment spec until the task force has had a chance to meet to discuss. But we resolved to take this up as a work item.
<scribe> ACTION: Ian to work with Roy to set up a repo for future tokenization spec(s) [recorded in http://www.w3.org/2017/03/24-wpwg-minutes.html#action01]
Adrian: I think the Credit Transfer task force is going to look for implementations
Ken: I wanted to share some
thoughts in the last session but did not have a chance.
I support this effort and
think that the success of this effort can be enhanced by
greater support from the card payment industry
... here's an issue that I have with the specs
... there's a potential commercial advantage given to merchants
given their ability to specify payment method preferences
... my proposal is to remove the language
... in show() 3.3, step 8
... the ask to the group is to remove the merchant preference
language
Ken: That would result, for example in the sentence being something like: "The user agent SHOULD prioritize the preference of the user when presenting payment methods and applications."
nickS: I am ok with this change; some others may object
Alan: Payment method ordering can also be used to guide merchant preferences
Ken: Language that encourages one use case may conflict with another. My proposal is to eliminate language and allow different market behavior.
<zkoch> FYI: filed issue 481
<manu> Ian: I am hearing the comment from Ken to be: if the merchant can express a payment method order preference, the user agent could use use the API that way despite a contractual obligation to do something else.
dezell: Merchant interests are important per our charter; just a reminder. just noting that our charters - intentionally or not - favor customers and merchants.
mweksler: Is not having any statement about merchant preference more problematic?
Ken: No, it is preferable to say nothing
Marcos: I think removing the
language gives user agents more flexibility
... I want the flexibility
<jean-yves> About choice of PI, as far as the EU is concerned, have a look upon art 8.6 of Regulation (EU) 2015/751 on interchange fees for card-based payment transactions: http://eur-lex.europa.eu/eli/reg/2015/751/oj
Manash_MC: Payment app exclusion is a related topic
adrianHB: We have an order of
constituents that we speak to, leading with users
... we don't have detailed naming of some parties in the
ecosystem
IJ: I think language in our charter is about which use cases the WG should address (e.g., b2c rather than b2b). I don't think it's about the order of constituents.
nicks: One other point in favor
of omitting the language....regulatory requirements can be very
different in different parts of the world.
... omitting the language might help us avoid conflicts
AdrianHB: By omitting the language we put the onus on the browsers.
NickS: Omitting language doesn't prevent providing an order.
David: Be aware also of regulatory impact on mobile money
Alan: I don't think there's a lot of retail representation in the room. They are going to be interested in expressing preferences.
Ian: We have no time for my presentation on the merchant adoption task force. I want to be sure people are aware of the FAQ which has about 60 questions in it. Please review and send comments (or edit). For API usage scenarios, we have a FAQ, let's keep building it up.
Ian: Should we meet in the last half of July? We have a possible host in Paris.
Noting for the meeting record:
* Not much enthusiasm in tired room for July FTF
* Prefer to decide later based on need whether to hold a face-to-face meeting before TPAC 2017.
No WG meeting 30 March
Next WG meeting is 6 April
AdrianHB: Another topic is what
to do since mozilla may not be at Thursday calls
... Thanks to everyone! Seeing implementation is exciting.
Seeing apps is exciting!
IJ: I am happy to have a call with Marcos, and others who cannot make the weekly call.
Marcos: Let's make more explicit that WG decisions are asynchronous.
IJ: Should we do a press release and other communications at CR of PR API? (Ian observes support in the room.)
<scribe> ACTION: Ian will work with Marcomm on comms plan for CR for PR API [recorded in http://www.w3.org/2017/03/24-wpwg-minutes.html#action02]