See also: Agenda, 19 September minutes, IRC log
<nicktr> Day 2 proposed agenda -> https://github.com/w3c/webpayments/wiki/FTF-Sep2016
<manu> AdrianHB: Are folks okay with the call times?
AdrianHB: Any challenges to
current call? Weekly too often?
... Would like to make it easier for people to provide input to
the agenda
(No change.)
<manu> Web Payments HTTP API Next Steps (Slides)
Manu: We recently published the
two specs. They are designed to mirror payment request
API
... the HTTP API is about how you execute the current browser
flow using purely HTTP
... Digital Bazaar and Worldpay have done basic
implementations
... the orgs didn't chat about their implementations but we are
off to a good start
... three categories of questions arose around the specs:
1) Do they reflect existing practice?
2) What are the use cases?
3) Who do we get relevant parties involved?
scribe: the HTTP API works like this:
* You try to get something and are told you have to pay
* You are told where to send a payment request, which is shipped via HTTP
* You get a payment response and you get access to a resource
scribe: on the question of
whether the API reflects current practice - the flow we are
trying to enable is the SAME flow that we are talking about in
the browser API, just out of a browser.
... the question arose - isn't this about communication between
the payee and the payment service provider? That's not what the
API is about, but we could do that if the group thinks that's a
priority
adrianhb: Let's talk about use cases first
<Zakim> AdrianHB, you wanted to suggest we discuss use cases first
adrianhb: if the use cases are
things that don't exist, then the other questions would be
moot
... so let's start with the use cases
Manu: I think there was a
misconception that the HTTP API is for internet of things use
cases
... while in theory that could work, that's not our
focus.
... the primary focus is automatic payments.
... e.g., your bank software makes monthly payments
... or you want to use an app (not in the browser) to make a
payment
... software running in kiosks...so it's non-interactive but
it's not IOT
... think of paying a utility bill...today you give your
payment instrument information to the utility company....if
your card changes you have to set it up again
... the other thing with utility payments is that they occur
regularly, but you don't know what you have to pay until the
end of the month
... what you could do is having wallet or banking software
where you set up a payment endpoint with your electricity
provider, and your banking software will ping the provider to
get a total. That results in a payment request. The utility
company says "you owe this much this month". Your wallet
software responds to the payment request (using some payment
method) and the utility processes the payment.
... there are various benefits (e.g., your wallet can pay with
your updated card)
zkoch: Is the idea that once it's set up it's automated?
Manu: Yes.
zkoch: It's hard for me to imagine automatically switching underlying form of payment without user consent. I'm having a hard time understanding the line between HTTP/Browser because of the user consent that's likely
Manu: The scenario goes like this: there is prior consent to use different payment methods.
zkoch: So is a key use case that you are delegating to the wallet authority to make decisions on how to pay.
Manu: That is a use case, not the
primary use case.
... the primary use case is "some piece of software other than
the browser" that you have configured to make payments on your
behalf.
... Another use case is a large corporation that wants to pay
vendors automatically
... e.g., a gov agency could ping different suppliers each
month where automatically they ping the vendor for the amount
owed,
... and the system determines whether the value is within an
acceptable range, and if so payment happens automatically
<Zakim> AdrianHB, you wanted to note some similarities with PSD2
Manu: so the primary focus is "smart payment agents making payments on your behalf"
AdrianHB: Understanding the
actors has made it clearer to me parallels to the PSD2
architecture
... you are describing an actor that is authorized to initiate
payments...PISP in PSD2
manu: Yes, the PISP could be using HTTP API
pascal_bazin: Could the HTTP API be used to introduce third party payment methods not managed by the browser?
Manu: The goal is to use any payment method that the browser supports....
pascal_bazin: Could you use the HTTP API implement a new payment method?
Manu: Maybe; but that's a general answer
dezell: NACS is interested in not
forcing merchants to use apps.
... I like the HTTP API and the separation of concerns it
represents.
... it enables us to decompose problems
... in my day job at Verifone we push some L2 processing into
an outside web server
... that's the sort of thing that the HTTP API would enable us
to do
... I also think that conexxus could make use of this
manu: Some addition use cases
(but not an area of focus): in-vehicle, electronic
receipts
... On the question of "do we have the right people in the
group to work on this?"
... we have a healthy list of payment app providers (10),
merchants or merchant reps (6)
... if we wanted to do the new connection between payment app /
PSP we only have about 3 PSPs in the group and we'd need to do
more outreach
... So the question if we have limited resources, should we
focus on "enabling the same browser flow in other software" or
"PSP communication"?
<AdrianHB> ian: thinking about who is in the group
<AdrianHB> ... if I understand the use cases it's focusing on automated payments
<AdrianHB> ... the value of interop for the browser api is small number of implementations and wide user base
<AdrianHB> ... what is the interop gain for http api and therefor who do we need involved in the work?
Manu: Interop is that app providers have common format.
<AdrianHB> ian: who are the companies that would be payment app providers?
IJ: I have not figured out the economic / interop incentives yet.
manu: Anyone who is doing a
wallet app wants to do automatic payments...
... so the incentive for wallet providers is that users stay in
their wallet for all payments
... There is no way today for a wallet provider to hit a
service and get a payment request in a universal format
Shane: Manu mentioned not being
able to hit an endpoint. One thing you can't do today as an
automated service provider...
... there are proprietary ways to do things...but there's no
standard way to do thing
... I can pay mortgage monthly today
... if my wallet had a way to talk to the electric company, get
the amount, and pay them, it would improve user experience and
improve interop for all wallet providers
IJ: Who are the service providers
who want to come together to do this?
... I apologize I am not understanding the incentives yet
Manu: We want to work on a primer and clarify the benefits, then reach out to parties to determine whether this is a compelling use case for them
IJ: +1 to talking to key parties to determine what the interop needs are
Manu: Are org is very interest in
this level of interop...we don't hear enough orgs in the WG
today so we want to go out there and talk with them. If we go
out and find out that this is not something that is broadly
desired, we'll need to change direction.
... so we need more data to find out whether this is a
compelling thing for merchants and payment service
providers
AdrianHB: My feeling is that it's
too early to say what direction to pursue. I think people are
still thinking about the use cases.
... I can understand the question Ian is asking...it's not
about technical benefits of interop...what are the incentives
for the players in the ecosystem to implement the standard?
Ben: I think you need to show what this displaces in the current processing chain. More work on that would be useful
AdrianHB: I think we need to figure out the commercial incentives...
<adamR> …And we seem to be back.
<AdrianHB> ian: I like the idea of doing outreach; I support that as a next step
<ShaneM> Intuit (Quicken), LastPass, Fitpay
<ShaneM> micropayments / paywall access
IJ: +1 to getting feedback from potential implementers on value of the spec and interop.
Ben: I think that users would like the additional automation, what I don't understand is the relationship to current processing and stakeholder roles.
AdrianHB: So Manu, you are driving the work and can continue. I would plan to get more involved once we've addressed other priorities in the WG. Also the Interledger CG is setting up a micropayments breakout tomorrow.
Evgeny: From a PSP perspective. I had not understood previously that HTTP API is for automated payments; I agree that is useful. It would be useful to simplify the API as a starting point. E.g., 2 calls to make a payment.
DavidE: On your point of people who would like this: zipline and P97 are two companies that come to mind. They are the kinds of NACS members who want to innovate in the wallet space.
Roy: See my write-up of the problem statement. Failures in card payment scenario are not that harmful. But for Alipay, SEPA pay, etc. where funds are changing hands before you get the response, there are many failure points in the flow where failure is more harmful. One previous idea to address this would be (1) mediator generated identifier (e.g., UUID) in combination with (2) discovery service
Zach: How are things done currently? How does UUID solve problem? I look at paypal as an example...they provide a callable endpoint ...what is that we are standardizing?
Roy: I think it's the fragmentation problem. A lot of services today use a back-end communication mechanism.
Matt: We do this in the SEPA spec.
Zach: So I can poll a service using a unique identifier?
Rouslan: The other benefit for UUID...the merchant can generate it and bind it to the user IP address. If the user clicks the buy button again, the payment app can detect an attempt to pay twice, and prevent that.
AdrianHB: The value of standardizing this is that you can introduce this identifier earlier in the flow. So you know the merchant has an identifier, and as a payment method provider you can architect around this. If we only standardize it in the payment, you can't rely on it in the same way.
Roy: For me it builds on the theme from yesterday - I hope we can minimize the dev time for merchants to use a new payment app. Payment app standard behavior makes it easier on merchants.
IJ: I think the value starts with open payment methods since the merchant doesn't know what app the user will select.
Rouslan: Where should this go? I see the value of it.
AdrianHB: There would be a need to augment payment request
zkoch: I don't think payment request needs to fulfill the role. We can say that there's a good practice to standardize an identifier.
AdrianHB: But if you want the browser to notify you, you need the event.
zkoch: The "event" about point of control handoff seems generally useful. But I don't think payment request needs to generate the ID.
Rouslan: Does this apply to pull payments as well?
Roy: No, since funds are transferred after funds are complete and so you don't care the same way.
IJ: Might be useful for things like chargebacks. Tracking payment receipt with the transaction.
AdrianHB: Idea is "event" triggered at moment of hand off to an app. (We've not discussed what data can be transferred at that moment; part of upcoming discussion?) So there are two things that are useful - identifier + where control was handed (payment app).
AdamR: But that's useless unless you can get back to that app at some point.
AdrianHB: Or the service provider they speak with. Maybe there's another event on the service worker to process queries.
AdamR: I think that (1) identifying payment app locally and (2) payment app globally those are two separate problems. Service worker lets you address the first one. But for something cross-browser you would need something like a URL.
AdamR: We need both "who control was handed to" and "how I get back to them."
IJ: In Alipay does server ping Merchant or vice versa?
Max: Both exist - alipay server can send notification to a merchant server (called the notification URL). Merchant can also query the status of the alipay server.
@missed@: The business model of the push payment solution is about risk... may not be just a mechanical spec. A merchant might allow a purchase even if the merchant has not received a notification.
IJ: Do you have other use cases, Zach, for a handoff event?
zkoch: Merchants would like more exposure into life cycle of payment request. One thing they can't know yet is what the user chose. They would like visibility into that earlier. Seems like having another reason to do the event I could see doing that.
IJ: So with an event, Roy, do you want to flesh it out further?
Roy: Do we want to go a step further and build it into payment request or at level of payment method. Otherwise we might still find fragmentation.
IJ: I feel like we should start at the payment method level.
MattS: We've seen it twice already.
Roy: I would be happy to look at both specs to see how it works at a lower level.
ACTION: Roy to work with AdamR on revised proposal around push payments.
zkoch: the other open question I have - is there interest from payment method providers in implementing this. My hesitation in putting in payment request is not knowing who wants it. E.g., does Facebook want this to do a push payment method?
AdamR: We have heard it from Worldpay and Alipay
Roy: Everyone is doing this. You have to have something like this to not double charge people.
zkoch: I understand the value, but I have not heard people say "I want this." It seems premature to put this in payment request.
MattS: On the SEPA spec I have a specific issue about this.
zkoch: The industry is handling this today. I don't want to add something to payment request without explicit demand.
Roy: I see this as a potential adoption issue. If I am an emerging business and deciding whether to use payment request v. my own flow, if I have to do a lot of work to integrate payment apps, the less likely I will use the API. The more rolled into the API the better.
zkoch: There's still a lot of individual integration that needs to be done. I think that you would still need individual relationship with providers, they would probably have proprietary endpoints. I don't think we can avoid 1-1 relationships with processors or integrators.
AdamR: But the app can handle the endpoints for you.
zkoch: I don't think so.
Roy: I think it could answer some questions for you.
IJ: I suggest incrementally building it up...start with event and identification of ID...then add UUID later if we detect the benefit.
AdrianHB: Yes, generation of UUID is nice to have. So we need:
AdrianHB: I think we have
agreement that PMIs are URLs that refer to web payment
manifests
... data about how an origin plays in the ecosystem
zkoch: I want to be able to
finish the PMI spec.
... There are a few high level use cases we want to support:
1) For a given payment method, we want to make security assertions about apps
2) Browser wants reliable information about where to get an app
zkoch: I want to get agreement that there will be a manifest file, and secondarily (later) we can discuss what goes in it.
PROPOSED: An identifier is an
absolute URL composed of the schema, origin, path. No query
string params and no fragments.
... these URLs could be used by users to get web pages
PROPOSED #2: At that URL you can append payment-manifest.json which has data describing that payment method.
zkoch: There is precedence for this in Android
<Zakim> ShaneM, you wanted to propose something alternate to that
ShaneM: I don't object to the
hard-coded path, but there are other ways to do this like HTTP
headers
... that gives us the ability to more easily extend in the
future.
... that does imply two round trips.
AdamR: That's not the case for HTTP 2
AdrianHB: So if I visit the site of the PMI I get back an HTTP header?
Shane: Probably multiple headers (e.g., here's information about the payment app, etc.)
AdamR: I get a little heartburn from a hard-coded path
zkoch: There are a couple of
reasons I like the hard-coded URL but I am open to other
approaches.
... one advantage is it's very easy for merchants to
implement....it's harder for merchants to manage headers
... this proposal also lets me do things in a single
request
... it's costly to download a page and parse it to get more
information. This is particularly costly on low-end devices
AdamR: If it were a common operation that would be compelling, but IMO this will happen rarely for a given payment method
<Zakim> AdrianHB, you wanted to emphasize when this happens
AdrianHB: This will happen every time a browser encounters a payment method they haven't seen before
zkoch: Or if they want to refresh.
AdrianHB: This may be happening int he background and therefore needs to happen quickly.
nicktr; I have two practical points. I am really worried about this....what do we think the likelihood that orgs will put a manifest at a URL?
zkoch: We are going to use short strings for the open payment methods; this proposal about URLs is for proprietary systems
nicktr: My second practical
question is - are you introducing a single point of failure for
those payment methods?
... suppose a bad actor takes over the site.
AdamR: You already have that problem with bobpay.com....
<betehess> note that it could at least be /.well-known/payment-manifest.json (that's https://tools.ietf.org/html/rfc5785 )
<adamR> betehess: That only works if you require that each origin has at most one payment method. I don’t think that’s a reasonable restriction.
zkoch: I am open to discussing headers; need to understand more how they work
<betehess> adamR: I see
IJ: Have you talked with Anne/Tab about URL matching?
zkoch: I think there's some
discomfort but this proposal is preferable - string match on
well-defined components
... we'll loop back with Tab and Anne on this
AdamR: I believe that the constraints that zkoch is talking about addresses the points that have been raised
ben: I would like to check with
our security team how they would feel about this.
... from a regulatory perspective, I am pretty sure that the
payment method needs to be identified
zkoch: The URL has to be
HTTPS
... origins will control the shape of the URL
rouslan: I'm happy we seemed to
be agreeing on constrained URLs
... on the second proposal Shane mentioned headers
... I'd like to hear some examples of technologies that are
using header links.
<adamR> Link headers: https://www.w3.org/wiki/LinkHeader
Shane: Web annotation protocol spec specifies that link headers with certain values allow you to discover resources of various types within that ecosystem
<betehess> lots of uses of Link in https://www.w3.org/TR/ldp/
<adamR> HTTP/2.0 server push: https://tools.ietf.org/html/rfc7540#section-8.2
<betehess> Twitter API uses it too https://developer.github.com/v3/#link-header
AdamR: HTTP 2.0 server push...if set up correctly, will let you get a single response rather than two trips
AdrianHB: So I am hearing "one less request" is not a key benefit using HTTP 2
<Zakim> ShaneM, you wanted to point out that this means the URI is BOTH an identifier and a resource
RESOLVED: PMIs are constrained URLs as describe here.
zkoch: For open systems we decided short strings. I suggest that we limit those to [a-z0-9-]+
SO RESOLVED: short strings constrained to [a-z0-9-]+
AdamR: I suggest you talk to TAG about use of headers v. pre-defined URLs
zkoch: I am ok to talk to TAG...but there is a question about ease of implementation by merchants
[We will take Proposed #2 to lunch and possibly the TAG]
AdrianHB: Are we agreeing that the PMI -- through some mechanism to be defined -- will enable someone to find a manifest
<rouslan> +1
+1
<AdrianHB> +!
<AdrianHB> +1
<adamR> +1
AdrianHB: Primary use of the manifest doc is security (which apps are authorized to fulfill the payment method)
zkoch: I think we should aggressively limit the number of short strings that circulate
<Zakim> wseltzer, you wanted to discuss findable vs must be found (and when)
wseltzer: One piece of commentary
from a staff conversation is that just because you have a URL
doesn't mean you have to look it up all the time...they can be
useful because their references are findable by automated
processes.
... but they don't have to do the lookup most of the time
AdrianHB: Our expectation is browsers will cache info they get
<nicktr> nicktr: Notwithstanding the desire to bootstrap the ecosystem, I am worried about W3C claiming a mandate to control and define payment methods that we do not have - the minting of short-strings troubles me
(Interesting question - relationship between PMI and caching if done through headers...)
MaheshK: Suppose I only trust certain apps as a merchant
<Zakim> MaheshK, you wanted to comment on open method without manifest
[Discussion about URLs and short strings some more]
Laurent_: Is it bad to use a URL?
IJ: We heard objection to server
risk.
... It's not clear to me that we need a manifest for open
payment methods
Laurent: An empty manifest file might be useful to tell browser something about the payment method (that it's open)
AdrianHB: We still need to define what goes in the manifest
<Zakim> rouslan, you wanted to comment that URLs are not only for security, but also to define your own payment methods.
rouslan: I heard a comment that
the best use of the URL is to ensure the security of the
payment method and interaction via payment apps. I think an
even better use case is to define your own payment
method.
... I would like to respond to Lauren's comments
... I think it's cool from an engineering perspective to have a
URL like w3.org/visa .. the problem is of course the server
risk.
... we could hard code information into browsers so that there
is no dereferencing.
IJ: Hard-coding in the browser is
equivalent to them implementing a short string but it's harder
on developers
... We've had problems with software downloading DTDs too
often
Nick: Worldpay, too
[Recap]
- PMIs are constrained absolute URLs
- They can be used to get manifests (through mechanism TBD)
IJ: Do you have preliminary ideas on what goes in the manifest?
zkoch: I have a PMI strawman proposal.
AdamR:
- Restricting origins
- Where to get apps
zkoch: I think the two broad categories are:
- platform dependent things (e.g., what you need on Android)
scribe: including something like "where to get in the app store)
- web assertion model (I delegate to other origins)
AdrianHB: Are we happy to restrict by origin? Or specific apps?
<nicktr> See Zach's manifest strawman.
AdamR: Are we relying on origins for native apps?
AdrianHB: I am suggesting we say things in two parts (1) identify origins (2) identify where to get apps associated with those origins
IJ: The other piece I've thought about for payment method manifest is "Here is the payment method spec."
[Discussion about payment app data]
AdrianHB: Some data about apps
can be part of the service worker code (rather than external
file)
... but there's a use case where the browser can go get data
about an app before executing a service worker
IJ: E.g., recommended payment apps
<Zakim> rouslan, you wanted to talk abut restricting by origin
rouslan: I agree that those three
pieces of information in a manifest (trust, apps, payment
method spec) would be useful
... regarding trust representation..I am ok to drop path
part
<adamR> basically, something like this: https://pastebin.mozilla.org/8911575
rouslan: in terms of service
worker and manifest file relationship...I think you are right
that we will need some info about the App BEFORE the service
worker is invoked.
... I think that service workers can update the manifest
files.
... this allows payment apps to push updates to the browser
AdrianHB: As a payment app publisher I want to avoid saying the same thing twice
<Zakim> questions, you wanted to comment on manifest
AdrianHB: We have more work to do on what data is specific to browser-based payment apps.
MaheshK: What about native apps?
AdrianHB: That's platform specific...and we have more work to do on the payment app spec to put hooks in place
MaheshK: Samsung had different apps (for different regions)
IJ: Interesting....it's one thing
to say the apps are allowed and another to say "You can't use
this app in this region" I don't know where that's
implemented
... Actually, use server-side filtering
AdamR: What I want is to know all the apps that are allowed. And a second concern is "For your region, here's where to get an app"
AdrianHB: Is origin-based constraint sufficient?
<adamR> https://pastebin.mozilla.org/8911575
<adamR> zkoch: https://www.w3.org/wiki/LinkHeader
<zkoch> here was my original straw man.
zkoch: Web app manifest has a way
to go from web app to a native app
... my straw man speaks to this
... we can probably define a platform that is "web"
... I agree we can strip the path (as Rouslan pointed out) when
delegating authority to other origins
Max: In yesterday's demo we used
this mechanism!
... so it works
<zkoch> +1
AdrianHB: I am hearing manifest has these sections:
- allowed origins (for app distribution)
- getting apps
- payment method documentation
IJ: So do we partner about the payment app data bits (that might be in a manifest or in a payment app manifest)?
zkoch: Partner
Q1: Should payment app data be both available inline or by ref?
Q2: Should the manifest spec define both types of data
zkoch: What I will probably propose first is to put everything in the PMI spec...we can then see if payment apps also want it and we can pull it out as needed
<adamR> zkoch: Re icons — https://www.w3.org/TR/html5/links.html#link-type-icon
zkoch: Propose everything be in PMI spec to start
+1
IJ: +1 to including the payment method and payment app data in the PR API + Basic card + PMI spec to start...and pulling out as needed as payment apps proceeds
zkoch: +1
adamr: If we take what adam proposed, it's mostly about icons
<scribe> ACTION: Zach to work with Max to revise the payment manifest proposal [recorded in http://www.w3.org/2016/09/20-wpwg-minutes.html#action01]
<trackbot> Created ACTION-37 - Work with max to revise the payment manifest proposal [on Zach Koch - due 2016-09-27].
Manu: Not much has changed at a high level to Web Payments Overview 1.0 since June. I did update some links to TR specs
PROPOSED: Publish this as a NOTE in TR space, and update it as other specs are updated
MattS: I have some minor edits to suggest.
Manu: You can suggest those changes during the CFC
<AdrianHB> +1
<MattS> +1
<ShaneM> +1
<Roy> +1
<Max> +1
<lbolstad> +1
<rouslan> +1
<nicktr> +1
IJ: +0 (no objection; but think it does not need to be a TR doc)
<bensmith> +1
RESOLVED: Issue a CFC for overview specification
IJ: Proposed CFC in 5 weeks. Also PR API would not leave CR until payment apps enters CR
AdamR: Would rather have all specs leave CR at the same tine
<Zakim> Mike, you wanted to comment
Mike5: The way I think PLH would
articulate it is that you should not start CR until you know
when you are going to leave CR.
... I think that you should have a test suite before leaving
CR
... we don't have two implementations yet that we know about
that we can test; we only have one that we know of.
<adrianba> I think you need to know _how_ you are going to leave CR - i.e. what are the exit criteria but not when
Mike5: in short - I think the focus should be on getting the test suite to advance in order to have a concrete discussion about when to leave CR
<adrianba> you also need a minimum CR time period
nickS: I would have some concerns about gating payment request (which is implemented) against something that is not implemented (payment apps)
<adrianba> exit criteria should outline how you're going to determine that you meet the PR entry criteria, which is likely to include a test suite
NickS: ...I would be concerned about introducing that dependency
Manu: I don't understand what going to CR buys us. It's usually used to demonstrate that the group is done with the work and we are fairly sure what we have. Why do we want to move to CR? What does it buy us?
zkoch: I think what CR buys us is
some stability.
... people are confident that we won't introduce breaking
changes unless really necessary...and those are based on
implementation issues.
... Today we have one implementation. I think others would like
more confidence in the stability of the API
MaheshK: We are concerned about going public with our implementation unless it is a CR
AdrianHB: Who do you think is looking for the stability? Merchants or browsers?
zkoch: Both
<adrianba> we definitely are looking for stability - want to avoid rework
<adrianba> when we talk to partners they want to avoid rework too
zkoch: I believe from Editor perspective we are ready from a spec perspective
IJ: Note that having a test suite is not prerequisite for entering CR
ShaneM: I think it's fine to set
goals (e.g., go to CFC in 5 weeks)
... wrt testing, I think having a test suite will be easier
with two implementations available
... I am happy to having a test suite available in 5 weeks if
we have two implementations available
... finally, I'm ambivalent about whether to push to CR because
of payment apps
IJ: Charter milestone is CR in
Nov 2016
... I believe stars are aligned to go to CR (1) charter (2)
implementations (3) stable spec trajectory
Manu: I hear people saying that
some other things may destabilize payment request API...payment
apps could destabilize payment request API
... that's what I'm hearing.
MattPi: +1 to IJ and ZK points about CR and stability...I think it will send an important signal to our partners
IJ: I think that payment apps and payment request API do relate closely hence proposal that PR API not leave CR before other in CR
MattPi: I'm not sure of the dependency.
[Summary of CR]
nicktr: I am hearing two
different accounts: some want to go to CR (implementers in
particular who are talking to customers) and those who do not
(notably around payment apps)
... so one question is "when will payment apps be ready"?
... I think personally that there may be some things in payment
apps that affect payment request API
zkoch: We've tried to design
payment request API with all this in mind - how things work in
the real world.
... it's based on that confident and we are confident about
moving forward
... this is an opportunity to say "we are not going to add new
features"
... my other point is that these are independent
specifications.
... we believe in the open ecosystem, but the specs are
independent.
... we can make a best effort to go to CFC in 5 weeks to
motivate ourselves
... and see where we are in 5 weeks
... it doesn't seem negative to me to aim for a target
date.
AdrianHB: Something Zach said -
what is the expectation at the end of the 5 weeks?
... I want to be clear what the expectation will be in 5
weeks.
... I don't think we are in a position to say "We will issue a
CFC in 5 weeks." I think we are in a position to get things
done and then check then
... whether we are ready to go to CFC.
AdamR: I am concerned that when we get further into payment app spec, we may find we will make breaking changes to payment request API
zkoch: I'm aware of that.
<adrianba> I think the proposal for the timeline encourages people to file their issues rather than holding on to them
zkoch: I think we've tried to
design with this in mind.
... Payment request API is built to solve a real problem
independent of payment apps
... there are goals that it independently accomplishes.
... I think there is value pushing PR API forward and getting
implementation
AdamR: I think there are dependencies that are not as stable as some are asserting
AdrianHB: So we have an impasse
regarding the dependency on payment apps
... Perhaps we should accelerate both
AdamR: That seems realistic
zkoch: I support 5 weeks as a motivator to move the specs, test suite forward
AdamR: What is the expectation of what happens at the end of the timeline?
AdrianHB: I feel like the two groups (PR API and payment apps) need to help each other advance
AdamR: I feel that payment request API is not stable due to payment apps state
NickS: Payment request API exists independently of the payment app spec. I am not convinced that PR API should be held until the payment app spec is ready
Adam: Yes, I propose both enter CR together
NickS: I think it's odd that have that API that has implementers in the wild and we are going to gate moving into CR with a spec that depends on it
AdamR: I think there are mutual
dependencies..we want an ecosystem that includes payment apps
with PR API
... if we discover the shape of the API is not suitable, we may
need to be changes
AdrianHB: I hear AdamR's point about going to CR sending a signal of stability that is not accurate given state of payment apps
NickS: You're implying that there is a technical dependency
AdrianHB: An example is push
payments.
... does it require a new feature in payment request API (e.g.,
an event)
NickS: There does not seem to be
a clear timeline for payment apps, but we have a much clearer
timeline for PR API
... both chrome and edge are implementing. It seems like we are
doing a disservice not going to CR as quickly as possible
AdrianHB: We want implementers to look at the payment app spec and say "this is on the right track"
<Zakim> Mike, you wanted to comment
Mike: [Speaking personally] Please find a precedent in W3C where a spec is held until another one is ready
Manu: WebRTC (IETF and W3C discussions)
Mike: Show me precedent; I think the burden is in part showing this has been done in the past.
<ShaneM> I disagree with Mike - this isn't about process precedent
Mike: I think that it's reasonable who feel that we should start CR (for PR API) to ask that we get some Director input on this.
Rouslan: There was a question
about implementers giving a signal to the payment apps task
force
... several weeks ago I reviewed that spec and I made several
comments ... I think they were taken into account and
incorporated
... I think the task force is on the right track.
... the technology that's being described in the payment app
task force is the basis of the demo for Alipay
... so I don't know that there are a lot of changes in payment
apps that would break payment request API
Manu: I think there are two
points of trepidation (1) we don't have implementations of
payment app spec
... the easiest way is to get at least an implementation of the
payment app spec done at which point we'll be far more sure
about the decision
NickTR: I am not hearing consensus
AdrianHB: I think we do want to set goals
<ShaneM> I disagree with Ian. The spec in CR is meant to be stable except for things that are marked as at risk.
IJ: You can make changes in CR. I
am proposing we set the expectation both that changes may occur
due to implementation of PR API and also payment apps
... Given that people agreed to read the spec yesterday by 3
October, we can have a payment app FPWD easily by second week
of Oct
MattS: Should we set the
criteria?
... Maybe there are 2-3 key issues to address.
<AdrianHB> Goals following F2F:
<AdrianHB> 1. Review of Payment Apps spec (Zach, Max, Shane)
<AdrianHB> 2. Proposal to address push payments (Roy)
<AdrianHB> 3. Payment Method Identifiers (Zach)
<AdrianHB> 4. FPWD Payment Apps
<AdrianHB> PROPOSAL: Accomplish goals 1 - 4 in 5 weeks and if they are concluded assess readiness of Payment Request for CR
AdamR: I am more comfortable saying "let's review the landscape in 5 weeks and see if we have got those things done"
<ShaneM> GREAT EXPECTATIONS
<adrianba> the most critical part of a roadmap to CR is getting people to file issues with time to resolve them
IJ: Proposal ok with additional expectation that reviews AFTER that period will not arbitrarily suggest large breaking changes
MattS: Other things we wanted during this time
- confirm that we have a second implementation
- test suite progress
<rouslan> +1
AdrianHB: People ok with this proposal?
<AdrianHB> +1
<adamR> +1
<nicktr> +1
<ShaneM> +1
+1 since I think it's as far as we will get today
Shane: Service workers makes testing easier
[Light minuting]
<Mike5> for the record, zkoch and rouslan noted that clicking Buy button to initiate a payment request is not a trusted click event
<Mike5> can be initiated programatically (which makes it possible to automate that part of tests when we need to)
Roy: I am still available as a test reviewer
Shane: I would like a way to refer to a "known" payment method (for testing) and to be able to turn on/off support for that
Rouslan: Why not just "basic-card"?
zkoch: there should be a blocking user consent thing
<Mike5> [discussion about Chrome adding an optional flag to enable test to automate the step that requires user action otherwise]
Shane: Sounds like we've agreed to use basic card, with some user interaction
http://www.planetpdf.com/codecuts/pdfs/tutorial/CredCard.pdf
more test numbers:
https://stripe.com/docs/testing
<pascal_bazin> EMV specification is that the PAN can be 12 to 19 digits
implementation expectations of w3c process
https://www.w3.org/2015/Process-20150901/#implementation-experience
[Mike shows what we have so far]
[ADJOURNED]