See also: IRC log
[David walks through the agenda]
https://www.w3.org/Payments/IG/wiki/Main_Page/FTF_Sep2016#Agenda
David's presentation: https://www.w3.org/Payments/IG/wiki/images/c/cc/IG-mission2.pdf
[Dinner for 10]
[IG status]
[DavidE refers to use cases document http://www.w3.org/TR/web-payments-use-cases/ ]
David: We have made some progress in liaisons (notably with ISO)
[David reviews some additional potential topics]
David mentions https://www.w3.org/community/browserext/
[Introductions around the table]
[Slide: Strategy Management]
dezell: Wendy Seltzer is the new
strategy lead
... her responsibility is to understand new work coming into
W3C
... "steps" are Investigation, Incubation, Evaluation, WG
Deliverables
... e.g, for digital offers we are still in "Investigation"
phase
... there is no one way to do things, e.g., might use a
Workshop for investigation, or might use it later in process to
help with incubation
Kanchang: Suggest a liaison to ITU-T
<Kangchan> Focus Group on Digital Financial Services -> http://www.itu.int/en/ITU-T/focusgroups/dfs/Pages/default.aspx
Kangchan: They are looking at landscape...they are not doing standards
<AdrianHB> +1 to kangchan (I have been tracking this work and there is a lot of overlap)
IJ: Any specific people we should reach out to?
<manu> Ian: Some of the organizations that show up on the Focus Group page - World Bank, Huawei, multiple useful organizations/people we should talk to
<scribe> ACTION: Ian to look into reaching out to the ITU-T forum for a briefing on w3c payments [recorded in http://www.w3.org/2016/09/22-wpay-minutes.html#action01]
<trackbot> Created ACTION-184 - Look into reaching out to the itu-t forum for a briefing on w3c payments [on Ian Jacobs - due 2016-09-29].
<Kangchan> Contact person of FG on DFC, Secretary : tsbfgdfs@itu.int
<manu> Ian: I'm not convinced the harmonization task force does anything
<manu> Ian: Let's take actions and do those instead.
<Zakim> manu, you wanted to mention workshop may be unnecessary if you have enough supporting data, request addition to IG process - identify W3C staff member to champion work (or recruit
Manu: Workshops are optional
<manu> Ian: I think the expectation is that we have a number of tools available to us
<manu> Ian: When we discussed digital offers - maybe we need to do survey - workshop might help, but we decided to do a Blockchain workshop - not process consideration, resource consideration. Digital offers decided to not wait and meet anyway. There is no expectation that it's obliged, it may be useful.
<Zakim> manu, you wanted to identify staff member to champion work as process consideration
Manu: I think it's important to identify a team contact to help champion work.
<manu> Ian: This is a good point
<manu> Ian: CGs were designed for scalability, one of the key properties they have is that there is no obligation to have team in them.
<manu> Ian: At some point, when it comes time to integrate them into the W3C process, you have to interact with the team. Early in the process, you should be identifying team and knowing where things should go. For example, for Verifiable Claims, I had to hand off to other security folks on staff. The earlier you can get the team onboarded, the better it will be - gradual exposure is a good thing to do.
dezell: For new folks here, Team is a unique component of w3c work (compared to other orgs)
Digital Offers Task Force Update (slides)
Joerg: There has been a task
force led by Linda Toth that has put this together; Linda could
not attend
... the deck has my company branding but this is the result of
the task force work
(slide 2)
scribe: goal of this work is to
build community around improving e-commerce
... specifically improving digital offers, and to identify
standardization opportunities for w3c
... our plan at a high level is to start a CG, with some
momentum around some starter discussion points we will discuss
today
... we want feedback on the discussion points (and their
organization)
... please feel free to interrupt
dezell: Just wanted to underline goal is to identify interop challenges and standardization opportunities
joerg: We organized our topics into three topics: (1) management and distribution, (2) user action, and (3) settlement.
[slide 4]
Joerg: Here's what we've done so
far: reached out to somewhere between 30-40 companies
... heard back from 20 or so, most indicating interest
... we received 1 response with detailed input which we've
integrated into the text of our discussion points
... we reached out to some members and some non-members
<manu> Ian: When you say you don't understand where the comments came from? Do you mean, you don't know the person? Or do you mean you didn't understand the points?
<manu> Joerg: Oh, I wasn't in the email thread.
<manu> Ian: We didn't ask if they were okay to share their name publicly, but one person responded in a personal capacity with good information. It was a digital offers peer and an individual expressing those thoughts.
Joerg: looking now at discussion topics that would be seeds for the community group discussions
[Decentralized lookup]
<manu> Ian: We have roughly 12 discussion points, we're going to start a CG - we're trying to socialize topics in advance, and see which ones people care about.
<manu> Ian: We can grow from there, from the perspective of what the IG should do - we should determine what we care about, add missing items, clarify, that's the type of feedback we'd like.
<manu> Ian: This will shape the initial CGs work.
<Zakim> manu, you wanted to provide examples of the types of organizations involved in each category we're discussing.
Manu: as we go through these I
think it would be helpful to identify the types of
organizations that are relevant to the topic
... this will help us with outreach to make them aware of the
work
<ShaneM> (ShaneM has to go to another meeting to present. Back in a bit. Sorry!)
dezell: For decentralized lookup, I think consumer packaged goods companies, merchants that sell those goods, service providers
Joerg: I would say issuers of coupons&vouchers, those who communicate them (including apps), and networks that support the processes, redemption
<manu> Ian: Are we talking specifically about decentralized lookup? Or generally about the topic?
nick: Have you given consideration to the discoverability of these offers
<Erik> Decentralized Lookup will need to have a local element. brick and mortar are local.
<manu> Ian: The three words there are about digital offer flow - discoverability is a part of the first part of the flow.
<Erik> Merchants need a local/location lookup
dezell: In Chad's parlance, discoverability is part of the "reach" part of "reach, resonate, react"
<Erik> It came up at the July F2F, customers want to scan regionally but purchase locally.
<Zakim> manu, you wanted to note discoverability of offers
Manu: For Web discoverability,
the schema.org is a good starting point
... one idea is to extend schema.org for digital offers
[IJ is hearing "web discoverability" should be a discussion point for the CG]
<manu> Ian: It's good to know who the players are - there are organizations that distribute these databases, they're not going to be interested in us to find other ways to work directly with merchants.
<manu> Ian: There are smaller merchants that might be interested in more real-time lookups w/ direct interactions. We need to understand who these organizations are, and do outreach. Is this a problem that we should be discussing? Who should come to the CG?
joerg: I know of a German company
that aggregates offers from CPG..but they have a few shops as
well ... they could be interested in this topic
... in Germany we have some loyalty programs that work across
brands (they have their own brands)....that's a different
approach...and these loyalty aggregators might be
interested
dezell: Some of these are companies we have on our list...e.g., Catalina Marketing, Valpak
Chad: Valpak is owned by Cox media
dezell: Most CPGs don't want to do this directly
joerg: Ocado is an aggregator; but they don't distribute...they deal with acceptance
[Distribution to mobile devices without installation]
Joerg: In some contexts people may not want to go through the friction of downloading an app. How can we get digital offers to them?
(IJ: note that Web apps are interesting here)
<manu> Ian: One of the use cases I found compelling - you're in a convenience store, there is a coupon that's relevant, you could download the app from the app store, but that is a high friction process.
<manu> Ian: If instead you use a browser and you get a digital offer, that could reduce friction. Non-install use cases.
<manu> Ian: That's this topic - you may have to setup something once, but it works in a lot of places.
<manu> Zach: Is there a physical Web WG here?
<manu> Ian: Not a WG, but a CG, maybe.
<manu> Zach: Physical web is about beacons, broadcasting information.
<Erik> The Stock Exchanges, especially with Commodities with an old fashioned trading pit, are trying to bring back proximity trading (electronic trading in a local proximity). Not sure how a Web digital offers fits in a local wall street trading pit. They use apps not browsers.
<manu> Ian: The question is what happens after that?
<Erik> They might be interested
<manu> Ian: That's the focus of this topic.
(IJ: Another technology of interest: Push API)
IJ: The interesting thing here is everyone has a browser ... can help resolve the "no app install" goal...question is what happens and what technologies are needed to get data on phone, provide UI for user interaction, and then put offer in payment flow
Joerg: Some identity topics come into play to link offers as they go from physical to digital world, and for connecting transactions (e.g., to loyalty)
<manu> Ian: This slide is about a flow question
<Erik> In the case of a Wall Street proximity trading pit, the app vs browser is fine. Main 2 key points would be #1 who is the user, #2 what "topic" are they interested in getting offers for.
<manu> Ian: I'm in the store, I want to get the offer into my mobile phone, I want to store it, I want to use it at checkout... how do I do that?
<manu> Ian: That's what this focus of this slide is about.
<manu> Ian: That's not the focus of this slide - not how do you take physical coupons and convert them into digital.
<manu> dezell: This slide has a number of accessibility components to it.
[Controls on Distribution]
Joerg: Not everybody should get
every digital offer
... in the world of paper coupon distribution, there are
establish ways to control distribution, and also to measure
effectiveness
... in the digital world it is more challenging.
... there are challenges to setting limitations in a world of
digital offers
... There are two angles to this conversation - intention from
the merchant, needs to control who gets what
dezell: two aspects of this come to mind for me...people don't want to spam recipients of digital offers
katie: You don't want to get consumer protection to come after you
dezell: Also brand
management
... but there are regulatory issues here - for example,
regulation preventing the wrong people from getting coupons
from their web site
<manu> Ian: I wanted to emphasize the point Joerg was making - there are instances where people shouldn't be able to redeem the coupon and ones where the offer shouldn't even be extended due to regulations.
<manu> Ian: The CG should look to what exists today and what standard may be needed - it was a regulatory surprise that drove this use case.
nick: I think that controls on
"not getting" relates closely to rights management....
... I would be wary of bringing rights management into
this
... I think it comes down to what constitutes an offer
... if we are talking about "an offer" as a digital thing that
can be shared
... we have to consider what kind of standards we would want to
define around rights management
... Suppose I have a paper coupon that gives me $5 off. The
coupon says "1 time only"
... if I print this I can use security printing, use serial
numbers, etc....I have some mechanisms for control
... the problem still exists in the digital world....
... I think there are some cases where you would distribute "an
offer to get a coupon" rather than the coupon directly
Joerg: Some offers are "broadly
there to attract" and relate more closely to the marketing,
e.g., to drive people to a store
... there are different motivations - broad and more targeted,
for example
<Zakim> manu, you wanted to agree with NickS and Katie and not delve too deeply into rights management. Equivalent of "payment method data".
Manu: I agree with Nick and Katie
that rights management is a well we don't want to fall
down
... one idea would be that rights data would not be
standardized but could circulate through the systems with an
offer
[Interoperable clip and save]
<manu> Ian: The concrete use case is: You're browsing a merchant site, they show you a coupon that you might want, you click on it, and now you have it. Overall flows and the problems that you perceive in them, how do you get an offer into checkout - payment request v2 - what's necessary so that it's as easy to apply offers when you pay.
<manu> Ian: What if you are browsing a website, you want to get something from a page, store it, and use it at checkout.
Nick: IOS supports dragging
coupons into a wallet
... I think Google supports it as well
... nick we have our own mime type for offers
... it's publicly documented (though not a standard)
... you could see how it would work for web wallets
[Redemption of offers out of app]
Joerg: see earlier "getting into phone without app" ... this is the counterpart "getting that thing into checkout"
[Streamlined redemption during standardized checkout]
(IJ: This is "add a digital offers layer on top of payment request API + payment apps work going on in the WG)
<Zakim> dezell, you wanted to talk about "out-of-app" briefly
<manu> Ian: This is specifically about PaymentRequest API
<manu> Ian: We want merchants to know how that looks like from a UI perspective.
<manu> Ian: It's going to be one click heaven - for digital offers, we want redemption of digital offers to be the same. We want a consistent harmonized way, that's what this is about.
AdrianHB: One particular
challenge has to do with the fact that payment request API is
unidirectional
... but digital offers involve updates and more chatty
communication back to the merchant
dezell: One way to do this is expanded PSP capability. Merchants want coupons settled in real-time
AdrianHB: I am merely speaking about recalculation of totals based on interactions of digital offers and payment methods
[Multi-tender payments]
scribe: combining coupons and
payment methods
... more logic at checkout to determine "the best offer"
[Controls on redemption]
Joerg: A variety of limitations
(age, region, 1-time use, 1-per family, etc.)
... other requirements like resident of a region, need to show
loyalty card, etc.
... also important to me that users have what's necessary to
have a clear understanding of the offer
... I think we can do better than we do today in the paper
coupon world
[Near real-time funding]
scribe: here valuable to distinguish networks that distribute from networks that redeem
(IJ interprets that comment from Joerg as referring to "who should participate in the CG")
[Ability to distinguish funding sources]
<dezell> (I believe IJ is correct)
dezell: This is a complex topic, and could be more complex the more open the system is
mountie: We have to consider compliance as well
[Other topics and resources]
<manu> Ian: At one point, I mentioned that one topic wasn't our problem, but if through good practice notes we help merchants deploy a good ecosystem, they may appreciate that, so that may be a part of our work.
Joerg: There are some interesting use cases there,e g.., around privacy protection in EU
[Plan for next steps]
Joerg: Timeline is 10 October
launch of a CG
... timeline on slide 20 takes us to a proposed WG 1 year from
now
AdrianHB: Is there an intention to liaise with Andrew Betts and his paid content initiative?
dezell: Yesterday we discussed the role of digital offers in accessing paid content; we can bring it up with him in today's meting
https://www.w3.org/Payments/IG/wiki/Main_Page/DigitalOffers2016
https://www.w3.org/Payments/IG/wiki/Main_Page/Loyalty2016/Charter
<manu> Ian: We're going to study the ecosystem a bit more, do a gap analysis, and in a year, if we have traction and incubated work, we could go to a WG. A lot of it depends on your priorities, please look for the launch of that CG and join if your group is interested.
[break]
https://docs.google.com/presentation/d/1lebhIPXa1eQ7B0jiFdnuij17QwdMeIZwkoaCDcm3S9w/edit#slide=id.p
Manu: We went over this material
in yesterday in the breakout session; sorry to those who have
already seen it
... this session is a status update to show that there is
support
... and an upcoming meeting at Internet Identity Workshop in
2016
Participating organizations: https://docs.google.com/presentation/d/1lebhIPXa1eQ7B0jiFdnuij17QwdMeIZwkoaCDcm3S9w/edit#slide=id.g1144b8ab8b_0_102
scribe: we have broad
participation by a variety of stakeholders
... we have asked industries what they want to see about a
verifiable claims initiative
problem statement: https://docs.google.com/presentation/d/1lebhIPXa1eQ7B0jiFdnuij17QwdMeIZwkoaCDcm3S9w/edit#slide=id.g1144b8ab8b_0_50
katie: How is this different from using blockchain?
Manu: The proposed format can be used in conjunction with blockchain...e.g., dept of homeland security in the US requirement that someone is "actually an emergency responder"
52 orgs agree with problem statement; 2 have made clear they do not
charter scope -> https://docs.google.com/presentation/d/1lebhIPXa1eQ7B0jiFdnuij17QwdMeIZwkoaCDcm3S9w/edit#slide=id.g1144b8ab8b_0_75
Manu: Focus on data model and
serialization
... out of scope - exchange protocols and browser APIs
... the model can be used in a variety of systems, e.g., SAML
systems, blockchain, those using JSON Web tokens
... meant for lots of contexts
... limited focus of charter is due to (1) some pushback on
larger scope and (2) desire to demonstrate market acceptance
prior to larger scope
katie: Is privacy IG aware?
Manu: They are listed as a dependency
Mountie: Is verification for in-browser or out-of browser?
Manu: Could work anywhere you can
verify a digital signature
... to be clear, you are verifying that "something was signed
and has not been tampered with" (and not the veracity of the
signed assertions)
Level of support for scope and deliverables -> https://docs.google.com/presentation/d/1lebhIPXa1eQ7B0jiFdnuij17QwdMeIZwkoaCDcm3S9w/edit#slide=id.g1144b8ab8b_0_69
Manu: So broad support for what we are proposing
Architecture (forward looking) -> https://docs.google.com/presentation/d/1lebhIPXa1eQ7B0jiFdnuij17QwdMeIZwkoaCDcm3S9w/edit#slide=id.g1144b8ab8b_0_158
Manu: Issuers issue claims (with assertions) to holders
Holders present claims to inspectors ("verifying parties") by the way, this model and these roles are similar to those we've discussed this morning in digital offers discussion (coupon issuer, coupon holder/customer, inspector/merchant)
Mountie: For the model you showed, what is the relationship to the initial charter scope?
Manu: the data the flows through the system
Mountie: Do you expect there to be a variety of identifiers?
Manu: Yes. Including email
addresses, URLs, etc. We don't take a position
... we have a need for identifiers, but are not seeking to
standardize that
... There will also be great variety among registries (e.g., in
a company, in a country, distributed on a web)
... registries will range from highly centralized to highly
decentralized?
... Note that a single party might play more than 1 role.
jyrossi: How do you deal with security and privacy?
Manu: The group is concerned
about security and privacy...the architecture enables the
holder of credentials on what they share
... e.g., looking at only sharing minimal amount of information
to respond to particular requests from an inspector (e.g.,
assertion one is "over 18" rather than a birthdate)
jyrossi: How do you intend to
manage these?
... how will you specify the access?
IJ: Pieces are digital signatures and origins
Manu: And user consent
jyrossi: Some issues of collusion
<dezell> scribenick: dezell
jean-yves: very concerned about privacy, and we will be disappointed if we rely on external groups to solve all the problems (like web crypto).
manu: can you please try to formulate this idea into the charter?
jean-yves: yes.
<scribe> ACTION: jyrossi to format text for possible inclusion in the charter to help with the logistics of verifying a claim. [recorded in http://www.w3.org/2016/09/22-wpay-minutes.html#action02]
<trackbot> Created ACTION-185 - Formate text for possible inclusion in the charter to help with the logistics of verifying a claim. [on Jean-Yves ROSSI - due 2016-09-29].
[timeline discussion]
Web payments started in 2012, Credentials CG in 2014, survey and research 2015-16, expect W3M feedback any time now.
manu: we're interested in cross pollination with other expert groups, like Internet Identity.
dezell: are there unresolved concerns.
manu: some W3C members think
there is not enough incubation. There is also concern to reuse
previous efforts.
...: problem is getting general agreement on which efforts to
reuse.
... basically Certification Authority systems vs. other kinds
of verification mechanisms.
... we don't expect all of these issues to be solved
immediately, until we move work into public.
wendy: I've been examining the
work, and I'm not yet convinced that we can do this work
yet.
...: I believe you saw the "funnel" earlier, and I'm working to
make the process straightforward, and transparency is a large
part of that.
... communication should be improved, also.
... in the evaluation phase, we are taking the readiness
criteria into account (the AB has recommended this
approach).
<wseltzer> https://www.w3.org/Guide/standards-track/
...: also, does the work have adequate buy-in to make the work
successful.
... I think overall the recommended charter and incubation are
good. My question, is are there enough grounding of components
to make a workable system.
... specifically, is the work too similar to other efforts.
manu: I think we're responding to
specific concerns, for instance allowing JWT as a signature
method.
...: we also compared our use cases to Oauth, and haven't had
any real feedback.
... we have educational testing (giants) who are committed to
use the work, which would be enough to boot-up an
ecosystem.
... we're focused on education and payments.
... so we have narrowed the scope based on feedback.
wendy: ... the piece of the ecosystem that is missing is the security reviewers. For instance, WebAppSec is not convinced.
manu: we have several security experts engaged.
wendy: so "verifiable claims" puts a lot of stress on the "verifiable" piece.
manu: It's not clear how much of this work we should pre-do. I believe we have engaged the security community. We'd like to know what you need.
wendy: we are viewing our
community as a finite resource, so we would implicitly assign
work to our security community.
...: so I'm looking to the internal security community for
support.
nick: can you speak to how this group relates to the FIDO alliance?
manu: it doesn't relate directly. FIDO doesn't specifically address the use cases we have.
nick: so if several members of the FIDO alliance don't believe that the work is ready, would it mean we should continue to try to engage?
manu: absolutely, but we haven't heard from any folks who have concerns.
wendy: Jeff Hodges has expressed concerned.
manu: frustration is the group is that direct concerns have not been expressed, even after a lot of circulation of the ideas (AC forum, etc.)
katie: so what is the status.
manu: we have IG approval, waiting on W3M.
joerg: I've been in innovation
for a while. The argument that "this thing isn't solved yet, so
it must not be solvable."
...: the fact that the dataset is not directly tied to
browsers, it puts it into a special discussion level.
... so I don't understand why we don't move forward.
wendy: so it's not whether it's in the browser or not. But innovation is different from standards track.
<Zakim> dezell, you wanted to remark on "vague"
katie: I think W3C is about
innovation, doing things other groups haven't done before. It
seems this group is doing the kind of thing W3C >should<
be doing.
...: if the group falls short of the charter, then that is the
time to pull back.
... this work is important across a lot of different groups at
W3C - I think W3C is the right place.
... I think it should be sent to the AC.
manu: I think we have ample
feedback that this work is wanted. We want to do this work, but
it seems that you are unconvinced.
...: the group doesn't want to stop now.
... we have made many changes to the charter (see the list in
presentation).
dezell: I feel that it would be a shame to use this work.
wendy: I apologize that it hasn't moved more quickly.
David Faidella (Reuters): I think some of the
confusion is in communication of the scope.
...: the process by which validity of a claim is proven needs
to be defined.
Payment system accessibility presentation (slides)
<Ian> [Going through slides]
<Ian> Payment Accessibility User Requirements
<Ian> http://rawgit.com/w3c/apa/master/payment-accessibility-reqs/index.html
<Ian> Shane: Most of these issues do not require changes to Web Payments WG specs, but we (as developers of software) need to keep them in mind
<Ian> Shane: What I want from this group is your input.
<Ian> ...we need concrete user experience things that have happened (to your customers) that can be improved through this process
<Ian> ...we could imagine that W3C payments could improve user experience for users with accessibility issues
<Ian> ...any information you have to illustrate that would be helpful
<Ian> dezell: I want to turn the question back around - have people done usability reports about various (real-world) web sites?
<Ian> ..do you have examples of things that have been improved to help inform this discussion?
<Ian> Janina: Digital shopping has a higher chance of being an accessible experience than in-store (unmediated)
<Ian> Janina: Here's an example of what would be an improvement in POS....mobile devices can help improve the experience....better than handing a physical credit card and getting a piece of paper back.
<Ian> ...it would be cooler to pay with my mobile device and store a receipt in my mobile device.
<Ian> Manu: I am hearing digital receipts are interesting from an accessibility perspective.
<Ian> Janina: I suggest "digital receipts" is a "relatively near term" priority
<Ian> Shane: I think that digital offers also can have strong accessibility benefits
<Ian> Anders: Receipts can be sent directly or in the cloud.
<Ian> IJ: I understand the APA wants to map accessibility guidelines to concrete payment scenarios
<Ian> Katie: Yes, it does not yet.
<Ian> ...today is a call for action, but we won't discuss the content of the payment accessibility user requirements
<Ian> Janina: We are starting to look at "cognitive" disabilities, which W3C has not yet endeavored to address.
<Ian> ...one of the things that group is talking about is how people can "resume" experiences rather than starting again (e.g., don't make someone start a purchasing flow from the start if they have stepped away for a few hours)
<Ian> IJ: Are there other specs that say "When you do a UI, do it accessibility"
<Ian> Shane: Yes
<Ian> Shane: So we are looking for participation; contact information in the slide deck
<Ian> Andrew: Recurring payments and contracts to pay are distinct
<Ian> ...renewals typically come with a price change
<Ian> ...different payment methods
<Ian> [Recurring payment issues]
<Ian> Andrew: Variability of value, schedule, strength of the authority
<Ian> [Potential models]
<Ian> Andrew: Different models to explore
<Ian> - open-ended subscription (the goal standard)
<Ian> ...note that publishers are not super excited about micropayment, as they don't lend themselves to users developing habits
<Ian> ...if people think about paying each time they access content, they are less likely to return again and again
<Ian> ..having said that, micropayments are interesting for some use cases
<Ian> ...for example, we would be interested in selling long-form reports (e.g., weekend magazine piece)
<Ian> - first term subscription (e.g., day pass)
<Ian> ....there's a granularity issue in economics ...merchants need to sell enough of something to make money, e.g., Netflix
<Ian> IJ: Think of newspaper as "continuous". Is there still a value to a "day pass"
<Ian> Andrew: there are different granularity needs:
<Ian> - single article
<Ian> (useful, eg., to sell something people visited from a tweet)
<Ian> - "daily bundle of news" is still viewed by some people as a thing....some users engage once a day
<Ian> ...there's also a psychology of "completion" as in "people had a chance to read it all"
<Ian> ...so the "day pass" helps bundle content in a manageable amount that meets a need of some users
<mountie> link to slide?
<Ian> - Fixed fee rental (e.g, film from iTunes, Kindle)
<Ian> [Discussion of trade-off between "what users want" and "what merchants offer that enables them to do business"]
<Ian> [Discussion of micropayment]
<Ian> Andrew: I like micropayments; my point is that they are not the best solution for all problems we want to address
<Ian> Andrew: Other forms of payments - donations/tipping
<Ian> Andrew: Donations and tipping do not work for anything but the cheapest content
<Ian> [Business model issues]
<Ian> - cancelations (difference between those who start and those who end a subscription in a given month)
<Ian> - psychology of "bundled value"
<Ian> [Example - you can't just by "House of Cards" on Netflix]
<Ian> - habit forming
<Ian> - long term revenue stability
<Ian> Andrew: Mother Jones did an interesting study - cost of an investigative report that cost $350K and ad revenue was $5.
<Ian> ..in that case, Mother Jones follows a "patron" model
<Ian> Another example: Chilcot Iraq report
<Ian> ....2.6 million words...so for reporting on it, the cost of just reading it is quite high
<Ian> ...Guardian also has a donation model, but less successful than Mother Jones
<Ian> ...in general, ad revenues declining, content revenue is going up
<Ian> ...but production costs also going up.
<Ian> ...so my concern is that unless we make it easier to do paid content, we will end up with fewer sites online with quality content, and that content more likely to be partisan
<Ian> [Things to discuss]
<Ian> Andrew: I want to do more outreach to orgs that are interested in this, and bring them to the table to develop use cases
<Ian> zkoch: Were there interesting discussions in the breakout yesterday? Anything related to web payments WG?
<Ian> ....where do people drop off in practice? Are people dropping off in checkout? Or they don't push the subscribe button?
<Ian> Andrew: Biggest drop-off is the paywall itself. Having said that, once you subset the people who decide to enter into a subscription,
<Ian> we still see a substantial drop-off due to a tedious subscription form
<Ian> ...we need information about the user (to target ads) as well as credentials
<Ian> ..it is possible that if we have streamlined payments, more publishers could give up some front end data collection about subscribers in order to increase convergence
<Ian> zkoch: Do you have data about desktop v. mobile drop-off?
<Ian> Andrew: Anecdotally, I think we see greater conversation on desktop than on mobile
<Ian> ...a common pattern is someone gets content on mobile and then goes to desk top for subscription
<Ian> Andrew: Regarding feedback on web payments WG from discussion yesterday, no red flags for payment request API
<Ian> Andrew: I have some ideas of how to use payment request API, but it's an easier sell when it has even more features to address our use cases
<Ian> Andrew: Also, there's some crossover between pricing metadata and digital offers; I need to investigate further
<Ian> ..for example discoverability of premium content
<Ian> ...relates to first click free
<Ian> ..if the crawler were informed that the content with subscription information, that might help the search engine provide a better user experience.
<Ian> [Slide deck shows a mockup of how this might work in search engine results]
<Ian> Erik: We have a different business model
<Ian> ....what we've seen is that users do research on tablets
<Ian> AdrianHB: What data do you collect at subscription?
<Ian> Andrew: The data is mostly for figuring out what targeted ads...so demographic information
<Ian> ..I don't think front-loading subscription is a good user experience or privacy protecting
<Ian> Andrew: If you add an extra step at subscription you lose 20% of potential subscribers, so losing the data collection step would be helpful
<Jurgen> quit
<Ian> AdrianHB: My feeling is that the Web Payments WG took a position that recurring payments is not generic across payment methods, so not part of the core API
<Ian> ...we could ease the integration burden for different payment methods...we have a payment method good practices doc
<Ian> [Ian and Max wake up at mention of payment method good practices]
<Ian> AdrianHB: Next work for and extended web payments wg could involve more complex payment terms (e.g., recurring payments0
<Ian> ...knowing the market wants something can help drive priorities...it would be useful to hear "We will use payment request API if it has this feature."
<Ian> Andrew: +1 to explicit support for subscriptions
<zkoch> :’(
Capturing card data can be risky for any given site, if that's the mechanism for recurring payments. Options might be for a user to give explicit consent for a tokenized capture on demand.
<Ian> Shane: Paypal has a complete solution ... when we look at it as a community we should be sure to consider that as an existence proof
<Ian> zkoch: Did you have other feature requests for payment request API for your use cases?
<Ian> ..if you have a doc, please send to public-payments-wg
<Ian> Andrew: I will send you more details
<Ian> zkoch: Tricky thing with subscriptions is that the relationship it out of our control
<Ian> AdrianHB: I think the CG's existence can help prioritize use cases
<Ian> Andrew: I think this becomes increasingly important as we move away from people handing credentials to merchants and we move to something else
<nick> booooo
<Ian> AdrianHB: You can treat recurring payments today as payment method specific data.
Note that paypal is PCI approved, and accepts the risk.
<Ian> ...with some experience we could describe some good practice
<Ian> ...and suggest subscription terms that might be useful
<Ian> ...the impact of moving it to the top-level API is that browsers can provide useful UI
<MattS> scribe: MattS
Stefan to present
Stefan: Primary issue,
disconnected payment networks
... ad hoc integrations, not standardised as yet. We want to
add a standard for interconnectivity between these payment
networks
... So how do you get across networks? Add a connector into the
architecture
... However, connectors do scale due to the n squared network
relationship
... So we can add multiple hops to the architecture
... We need to add an address to interledger to enable this
sort of connectivity
... this address (and the value) passes along the chain
... But what happens if the link is dropped?
... We add "on hold" capability to each ledger in the chain,
and the value is held until necessary to ensure the chain has
not been broken
... this is done by a 'condition' which passes along the chain.
It actually passes back down the chain from the
destination.
... Connectors do take risk in this model
... but can mitigate it, for example by charging
... So that's the recap, whats new? I realised that we have just
a protocol based on other observations
... How do we build a 'system'
We have been partnering. 2 ledgers enabled after a year. So we need a faster approach
scribe: We look to the internet
to see what works. For example mass internet connectivity
started with the audio coupler (modem)
... what is the equivalent of the modem for ILP? We need to
take the payment schemes that exist today as a given.
... we create a virtual ledger to add to this. But settlement
occurs via existing schemes
... settlement occurs after typically in batches. We are still
using ILP Universal Mode. So we can transact through the ILP
system. This works around "holds" not being universal in today's
systems.
[Stefan moves to demo]
Stefan: Five Bells ledger as
you've seen before
... User wants to consume content, publisher wants to get paid.
We have a pay wall.
... Pay via ILP available (using PaymentRequest API?)
... ... we have an add-on that has a polyfill for ILP
(specifically ILP-micropayments)
<ShaneM> (I need to go to another meeting to make a presentation :/)
Stefan: this fills my ledger via existing means, e.g. SEPA
Demo shows payments every second coming in
scribe: this is coming via ILP,
not via settlement
... browser is paying via 'invisible' payments so no user
interactions
Zach: What is user consent model?
Stefan: Yes, we expect to have one, perhaps to set up limits though.
Zach: Lack of explicit user consent is somewhat concerning
Evan: We need to express the payment requirements, there is room for multiple user experiences.
AdrianHB: There is a requirement to be able to express payment terms to include more than just value, perhaps value per second etc.
Erik: Media publishers are going to like this.
Stefan: We want devs to be curious enough to 'dive in'. We can't make this happen alone.
Zach: Seamless of payments is key goal? Users may not want it that simple from our research.
Evan: Consider how electricity works, this is because price point is such that you don't mind using your laptop without consent, but you think twice about plugging in an air conditioner
Zach: Good analogy, but does regulation provide that 'trust'?
Evan: Its the tick rate
MattS: Yes, just like how electricity meters used to work
Evan: Paywalls could be less binary, but enhanced experiences, compared with airlines Gold cards, you don't get much more, but you like it
Stefan: Different monetisation models work in different ecosystems
Zach: What's the minimum we need to do to make this happen?
Stefan: Onboarding needs. 2
people on the ILP that share a traditional payment scheme
... extension support manual or automatic settlement. Demo uses
Ripple for settlement (automatic). PayPal may not accept this,
so you would get a prompt to settle.
... requirements for payment network means that crypto currency
fits the bill well for settlement
... for users there are various smaller payment networks that
have a good API that supports what we need
... Our next 9 months will probably be about making this easy
to consume, i.e. develop against
... In terms of partnership, one category being banks, for bank
to bank settlements. We have some central bank interests for
x-country
... I'm talking at Chicago payments symposium coming up. We have
interest in micropayment providers. Many have local reach and
we can extend it via ILP.
... we have interest from block-chain companies who want to
integrate across various distinct block-chains
... marketplace companies are interested in this to minimise
the number of integrations
... basically, lots of interest over last 9 months. So our
focus has shifted from convincing people it will happen to
making sure it happens right, e.g. security, ease of use
etc.
Erik: How about making available in various Docker registries
Evan: We have a bunch of Docker containers for various components already on DockerHub
Erik: Paid Content providers will really like this
Stefan: There is no lower limit
or fixed cost to payment which is why this works well.Then the
fixes cost occurs on the aggregate settlement payment.
... trust friction is also a problem. So this model allows a
per paragraph consumption rather than either the consumer or
the publisher taking up front risk
... this is a nice open approach that doesn't depend on
proprietary app store
<Ian> [ADJOURNED until 9:00 on 23 September]
ISO and W3C Presentation (Slides)
(William Vanobberghen)
William: What is ISO20022?
... there are a lot of commonalities with W3C work
... universal standard (cross industry, international in
scope)
... it is a common repository for reusable components
... model to map business needs to messages
[View of spec components of ISO20022]
[View of definition of a component]
Manu: You are looking at JSON serialization, right?
William: There is a draft report
from a study group.
... a potential decision would be to allow JSON as a
serialization, and all existing messages would be expressible
that way.
... I think there is a strong recognition of the RMG of the use
of JSON in APIs
(Benefits of ISO 20022)
scribe: interop
... originally ISO20022 targeted parts of the financial
services industry, but not cards
... due to SEPA, there was pressure to go from 8583 toward
20022
<dezell> Note use of "Envelope Data" using CMS to secure regions of data, especially PII required for AML.
<Erik> Erik: I uploaded ISO 20022 for dummies back in 2014. Here is the link. https://www.w3.org/2014/09/ISO20022_fordummies.pdf
scribe: 8583 was a bitfield
technology and needed modernization
... a study group recognized the ability to use ISO20022 for
cards
<manu> Ian: Friendly comment, because we've covered some of this material at other meetings - I want to make sure we get to stuff like W3C/ISO Liaison
<dezell> Reason for all this machinery - regions (nations) can create new exchange strategies without negotiating the track to international standard. Only RMG approval is needed.
[Structure of ISO TC68]
<Zakim> AdrianHB, you wanted to ask if the card standard is specific to "card" or could be used for other retail payments?
William: I convene TC 68/SC7/TG1
Mountie: Browsers are not likely
to encode/decode ASN.1
... do you expect browser to support ASN1?
William: Ten years ago XML
processing was too slow, so for card processing we proposed an
ASN1 format. But these serializations are choices
implementations make...and as I mentioned JSON is being
proposed as a new serialization option
... I do not expect W3C (or browsers) to push for ASN1
... (I don't see many new implementations of ASN1 in other
parts of the industry either)
[Value Chain of Card Payments]
William: CAP, ATICA
William: We see today some banks may not be able to process ISO20022 directly, so they are using gateways to do conversions
William: ATICA covers business of big networks (Amex, Visa, MC, ...)
(Potential for TG1 / W3C cooperation)
Commonalities:
- goal of universality, openness
<manu> Ian: Typically when we get into an ISO discussion, there are some differences between the organizations
<manu> Ian: We have a particular definition of "open standard"
<manu> Ian: I'll point you to that without debating levels of openness
<manu> Ian: When you say "all actors", ISO is based on countries, W3C may have a different definition of "all actors".
<manu> Ian: At the highest level, there are the same goals.
William: Nexo is a non-profit
international org, open to all (fee-based)
... that's for the acceptance work
(CAPE)
ATICA is a "fast track" process which is not bound to the country-based process
scribe: and any expert can work
in TG1 on ATICA
... they work through liaisons as well
... so in practice we see more expert representation than
country representation
IJ: Previously issue also raised about references to ISO specs
William: Messages specs are freely available
[Rationale for a potential cooperation]
scribe: so opportunities and connections include:
* Terminology harmonization
* JSON serialization
* W3C as front end to lead to generation of ISO 20022 messages
William: We have some connections
today via RMG (Lauren Jones, liaison) and RA (Kris and
Vincent)
... David, Ian, and now me
(The way forward)
<Zakim> manu, you wanted to ask why ATICA and JSON harmonization is an area of focus
Manu: Question about
ATICA....
... the focus of the Web Payments WG is not between acquirer
and issuer
... why is this an area for harmonization in w3c?
William: I take your point
... I think it may be more about acceptor-to-acquirer, but they
do fit together
... in CAPE there are additional messages and
protocols....
... terminal management system
... we have been designing TMS which works in parallel..
... and there's another protocol that might be of
interest...the retailer protocol
... I think it's a masterpiece for expressing sale application
token to payment token
... very interesting for big retailers
... another thing important to the financial industry is
ATS....ATM industry
... relationship between ATM and acquiring bank
<manu> Ian: I'm happy to see a proposal put forward for work items for the ISO20022 Harmonization Task Force
<manu> Ian: That group was active a while ago
<manu> Ian: We're operating at two different layers, I hope through different conversations that we assuage some concerns. You're saying that there may not be a lot of overlap because we're operating at different layers of the ecosystem.
<manu> Ian: I hope you take back the message that this is an opportunity to collaborate and is not threatening to ISO.
<manu> Ian: I'm not convinced that all of these suggestions are the right thing, but I'd like to hear from others in the IG for opportunities to coordinate so that the Task Force can pick up that work.
<Zakim> AdrianHB, you wanted to ask if the card standard is specific to "card" or could be used for other retail payments?
William: Yes
AdrianHB: ISO 8583 was very card-specific, involving PAN in every message. One question I have for the new standard - are they more generic and could they handle other payment methods?
William: Absolutely
... W3C could even design its own ISO 20022 messages if they
felt it was needed
AdrianHB: The Web Payments Working Group is working on the
"pre-acceptor" phase
... we are defining a set of data capturing standards between
user and merchant
... would be some value in harmonization for the message then
from the merchant to the acquirer
dezell: US may use CAPE rather than ATICA for historical reasons
AdrianHB: I think this is
probably more closely related to HTTP API .... which is closer
to the wire
... so I think there is an opportunity for us to push message
change requests to ISO
dezell: Absolutely
IJ: I believe Kris has emphasized this opportunity (to augment the registry)
William: I didn't address this because I thought the group would focus on APIs, but nothing prevents the group from also addressing messages, and letting us know which are missing in the ISO repository
AdrianHB: How similar are things like CAPE to credit push methods?
William: If we find that consensus is possible we can look at convergence
<Erik> Erik: We have covered ISO 20022 every F2F Web Payments meeting over the past 2+ years. There has been nothing tangible. The main roadblock to finding something tangible is the usability of ISO 20022 for Web (i.e., JSON). This has been thoroughly discussed yet no tangible progress toward providing the message definition, business areas, or JSON schema. ISO 20022 is a very large spec, however the card
<Erik> payments, debit, account balances, etc is a smaller subset. At least a good starting point will be to deconstruct the ISO 20022 payments structures we need and publish on http://schema.org. As we make extensions we need for 20022 we can publish back to schema.org.
<manu> Ian: I'd like to take that as a rhetorical question that's input for the Task Force
AdrianHB: I think it's worth exploring modeling ISO20022 messages in schema.org
[Intro by Angel Li, W3C]
Angel: In China I sometimes see
the opposite of the "abandonment" problem
... we'll speak to that today a bit
... today we will hear from various vendors about their
perspectives.
... there are 400-550M online payment users in China
... 420M people using mobile payments
... those are significant numbers; we want to understand how
W3C standards can support them
[Max, Alibaba]
Max: Alibaba is known as an
ecommerce provider, but we also strive to provide
infrastructure for all phases of commerce
... logistics, marketplaces, financial services, technical
infrastructure, and services
... e.g., cloud computing
Presentation -> https://www.w3.org/2016/Talks/TPAC2016_Alipay.pptx
[Max points out that many Alibaba logos represent animals...it's a zoo :) ]
<wydong__> where to find the ppt?
Presentation -> https://www.w3.org/2016/Talks/TPAC2016_Alipay.pptx
(Max goes through different services provided by Ant Financial)
<angel> Max's slides - >https://www.w3.org/2016/Talks/TPAC2016_Alipay.pptx
<wydong__> thanks ~~
Max: Alipay app is a "lifestyle
super app"
... 450M active Alipay users
<manu> Beijing metropolitan area, tier 1 city, 21 million population
<manu> says wikipedia
<manu> Shanghai, tier 1, 23 million people
Max: Stay tuned for online shopping festival (11.11) and offline festival (12.12)
[IJ is minuting lightly as we are walking through slides that mostly cover what is being said]
[Demos of payment scenarios and authentication methods]
Manu: What information is in the
QR code for offline-offline?
... is it card info? token?
max: Information related to the user's account
Manu: Are there security issues?
Max: The QR is 1-time
... we have a lot of mechanisms in place to ensure security
<manu> I'd like to know more about the security mechanisms as that might affect PaymentRequest.
[Max demos various authentication methods using QR, audio, fingerprint, smart watch]
[Smart bracelet payment]
Max: Here is what we think about
use of standards from W3C in payments
... the traditional web payment is not convenient on
mobile.
... we have a web browser to native approach but not secure
enough
... we like payment request API because it combines usability
with security
... that will benefit the whole ecosystem
... we think that it will be easy to bring to other platforms
than Android as well
<manu> I'm hearing that the Web Payments IG might want to push for browser to native app and native app to browser messaging.
***Moving on to WePay
Chao Gao: WeChat is a social app with 800M active users
scribe: Wechat pay is integrated
into the social app that makes it easy to pay
... secure storage of user data, and secure transactions
... Wechat supports Peer-to-peer (social) payments
... you send a message to make a payment
... the toolbar has a convenient button for 1-click p2p
payments
... you can also pay to people you are not directly connected
with ... this is widely used by small merchants
... one use case is to send a "red packet" to children during
the spring festival
... this was done, for example, 8 BILLION times during spring
festival 2016
... review of four payment methods enabled
... first is "official account payments"
... payment through Wechat browser
... the second one is the "App Payment"
... after choosing wechat payment as the payment method, we
chat app is invoked to complete the payment
... after paying, the user is redirected to the vendor
... fourth is quick pay
... scanning a QR code
<angel> Chao Gao's slides - >https://www.w3.org/2016/Talks/TPAC2016_Wechatpay.ppt
scribe: WeChat pay widely used in
various activities - food, clothing, housing, etc.
... becoming the most popular payment method in China
[We move on to Baidu]
<angel> Haibin Huang's slides - >https://www.w3.org/2016/Talks/TPAC2016_Baidu.pptx
Haibin: Baidu is largest search
engine in china
... Baidu wallet provides a full payment solution
... manages card payments, etc.
... merchants can use Baidu wallets for various purposes
... developers have an openAPI and SDK
[Baidu video shows how it works]
[Video / audio trouble :( ]
[Demo on HCE/NFC]
scribe: the user experience looks
like android pay
... the demo shows someone using their phone with NFC to
authorize payment at a merchant physical terminal
... also have a demo with HCE
... flow - phone in contact with POS sends token to POS.
... then POS sends token to acquiring bank....bank communicates
with HCE gateway
... which speaks to the Baidu payment server
We are also working on face-recognition systems
[Demo shows real-time camera capturing face information.
scribe: ]this face identify information can be used to authenticate users
[Qihoo 360]
Songfeng - 360Pay provides bank level security
scribe: discussion of basic payment flow and quick payment flow
Nick: Question for Baidu...when
you do HCE, what network are you using?
... China Union Pay or another?
Haibin: CUP
Nick: For 360...is this a new product?
Songfeng: It's been in use for several years
Nick: Cool
<Zakim> manu, you wanted to ask a question at the end - are these QRCodes interoperable? Do they need to be? If so, is there an open QRCode format? If so, what data is in the QRCode?
<AdrianHB> manu: is there a standard QR code payment initiation or does the merchant need to implement a different code reading logic per provider?
Mountie: I believe there are QR code standards; not sure how widely adopted in China
Max: The information in the QR
code is token information bound with the user account and that
transaction
... we use standard QR decoding/encoding mechanisms
... here are my thoughts on whether additional standardization
is required....whether we need to standardize the *content* in
the QR code...I don't have a strong opinion on whether to do
that
... from my understanding,I think most of the use cases are in
closed systems without interop needs
... To use QR code with Alipay you need to provide data that
Alipay requires
Manu: Do we need a standard way
to express payment request data in a QR code?
... that would make it easier for different payment service
providers to reach payment request data in one format
<jyrossi_> +1 on Manu's suggestion
<mountie> +1 for QRCode with payment request.
Crest: China is defining the QR code payment national standards, but currently there's no standard data format for initial payment req in QRCode /me missed
mountie: My question is about encodings...we need to consider non-unicode encodings
Max: Internationalization is very important
jheuer: I see QR codes are used in a variety of situations
Max: We can use a technology
called real person face-recognition
... that's how you confirm you are not a fake representation of
a face
<Zakim> AdrianHB, you wanted to ask about ecosystem
AdrianHB: Thank you for the
presentations. It's fairly obvious that a lot of us are stuck
in the "stone age" in other parts of the world
... I am interested to hear from you ...when you roll out new
payment methods, where do you encounter the most friction
... in my experience, one of the biggest points of friction is
convincing merchants to adopt systems
Max: How to motivate the merchant
is a very good question. In China for Alipay, we address the
challenge because own the merchant relationships :)
... are also looking at how to implement payment request Api in
our ecosystem
... we have a middle page that can be used for introducing the
standard
... and then merchants can see the value
Crest: WeChat has millions of users...we do a lot to connect merchants to users
<manu> Ian: I have a few market survey questions
<manu> Ian: Mobile payments are clearly interesting. Are desktop payments interesting? Do you see a value for web-based payment apps in China?
<manu> Ian: We saw a lot of mobile payment demos in mobile applications.
<manu> Ian: We hope native applications will be using Payment Request API
Max: nearly 80% of payments happen on mobile
<manu> Ian: The question is about Web Payment Applications, is there interest in that in Alibaba?
scribe: through native app
Nick: What you need to understand
when you look at apps like wechat is that most of the content
is web-based
... the application is web-based
... so I think there is a huge market for a web payments API in
china...it's just that the ecosystem is different
... you have monolithic applications like wechat or alipay etc
that do many things
<manu> Ian: I think that means they're web apps, or hybrids?
<manu> Ian: Maybe there is, for mobile, a place for payment request API. What about desktop?
<manu> Ian: If only 20% of payments happen on desktop... that's GERBILLIONS and GERBILLIONS of payments.
<manu> Ian: Do people pay via their laptop, for example?
<nick> I also had a point for Adrian
Max: In PC and desktop you can use a
qr code.
... to use wechat to pay
... in wechat browser we have a JS to invoke the
application
... out of wechat browser, let's say safari or chrome, we can
use some thing to call the wechat payment app
... the standard can help some problems we have
Haibin: Young people have only mobile devices
Angel: When I use my laptop to
shop online...when it's time to purchase, I use my phone to
make the purchase since it's easier.
... so people do commerce more frequently in their "fragmented
time" when they are using their mobile devices
Max: Quick feedback to NickS's
comment
... yes, I agree with Nick ... we think that our apps are
closer to "pure native' to "pure web"
... regarding the value of PC based payments - yes, I think
it's still important
<jheuer> I understand that cross-device scenarios play an important role... QR codes are just one possible technology to connect
Max: when I am browsing on my laptop, I will shop there...but when I go to pay I use my phone to scan a qr code
<chunming> a CNNIC report on payment (sorry in Chinese), 455M online payment users, 424M has the experience of using mobile payment. http://www.199it.com/archives/502921.html
Max: PC with browser interaction with user remains important
Kepeng: Regarding current deployment - we have more mobile...we might want to investigate expanding the scope of w3c work a bit into native app payments
Nick: Regarding Adrian's question
about merchant adoption....
... merchants are incentivized to take up these payment
approaches through huge discounts
... regarding the 12.12 payment holiday, for example...users
get massive discounts .. the app provider is funding the
discount
... so when I dine in China I use a payment app from China for
the discount!
AdrianHB: Building on Ian's
point...this has come up tangentially before...there are a lot
of native apps that are embedding web things
... is there interest (or even an expectation) that payment
request API would be exposed in these embedded web
components?
... so for example, you can think of the native app as a
hosting environment, ... is there any interest in interop
across these hosting environments?
... so one could create an app that runs easily in different
hosting environments
... should we expect Alipay to implement requestAPI inside the
Alipay app
Max: That's a very interesting
idea.......
... but.....
... what problem exactly are you trying to solve?
AdrianHB: If I initiate a payment
from within Alipay I guess you want to "encourage" Alipay...so
the interop benefit would just be having a single API
... and can use that in multiple environments...
... I understand it's not as rich an interop value
Max: Let's continue to discuss
<Erik> Erik: https://www.w3.org/community/browserext/
<Erik> https://github.com/browserext/browserext.github.io/wiki/2016-TPAC-Agenda
<Erik> https://browserext.github.io/browserext/
Chunming: I'd like to ask our colleagues - what do you think the right line of the standards should be so that we can promote innovation...and not limit it...what's the best way to enable the payment providers to compete...what should NOT be standardized?
Max: Wonderful question. Alibaba
is a platform for vendors...we like openness (and joined w3c
for that)...we think that standards can make it easier to
participate in the ecosystem that brings us benefits
... our customer is small and medium enterprises using our
platform....
... the standards are also important to improving the end user
experience as well
... we will compete, but that does not prevent us from creating
high-quality standards
[Summary by Angel]
Angel - population of online payers in China is huge; mostly mobile
scribe: a few vendors dominate
the user and merchant relationships
... we have some unique ways to do things (e.g., QR
codes)
... as the WPIG considers future directions, please continue to
think of the implications on this ecosystem
<scribe> scribe: Manu
jyrossi_: We've had a number of
issues brought up around Regulatory
... Why are regulatory issues important?
... Let's sum up the main position so far
... Some have said it's out of scope or out of reach for
groups
... That experience of the way that W3C goes along on the
standards gives a high level abstraction that could leave the
task for managing regulatory issues to PSPs
... We regularly have questions about regulatory issues.
... This morning we talked about ISO20022, as far as Europe is
concerned, it's a regulatory issue.
... at the end of the day, an authority has to validate the
work
... who will define the APIs that will unleash the power of
PSD2?
... If we take EBA's work in progress from European Banking
Authority website
... This one that is drafting the technical regulations
... This is the most important one, draft under development -
strong user authentication. Pay attention to the guidelines for
internet security - work that has been done, at first sight,
it's abstract
... when you go in the document, you won't see them as relevant
or compelling for what we are doing,
... The papers basically say that it's up to the banks to
define the security procedures. This is just a matter of what
institutions can do. EBA is regulating banks, so they say it's
for banks.
... If you dig deeper - they talk about authentication codes,
if changes to the amount are made - the auth code must change,
fraudulent payment transactions should be blocked. There are
thresholds proposed for exemptions for strong authentication -
50 Euro for some cases, 100 for others, whitelist is possible
for payer.
... such elements are relevant for the work that we're
doing
... European Central Bank will block any payment method that
will not comply - even for things that are minor gaps wrt.
regulation.
... postal payment services - project gathering a hundred
countries, 19 European countries have agreed to allow those
sorts of postal payments in Europe.
... ECB explained that individual states rules (national rules)
must be taken into account and be allowed.
... There were 3 minor gaps, for postal payment services, that
was it - finished, so not bad as far as modifications go.
... will what we produce work in the more global context?
... for example, cross-jurisdiction transactions - you have to
comply with both sides rules
... We have talked about card-centric operations in the group -
it's easier than other payment instruments because there is a
huge set of roadblocks by visa, mastercard, PCI DSS - they've
taken care of all of the regulatory issues. Worldwide common
context making it smoother for us. But if we want to go to push
pull payments or non-card centric payments. We wont have a
worldwide framework
... What will happen if we adopt options that are orthogonal
with certain regulatory issues - the answer is clear - it won't
work.
... We have to consider these regulatory issues - how could we
do that? We don't want to boil the ocean.
<dezell> to paraphrase Jean-Yves - with card payments, we are somewhat inoculated from local regulations. That protection from worry goes away with alternatives to cards so we must study more.
jyrossi_: mapping all of the
rules - the suggestion is to try to gather survival kits - find
links linking to what repository is - like central banks - I do
think that a basic mapping of what could matter would
work.
... If you agree with that, we'll need volunteers
Jean Yves shows basic map of main rules and area
jyrossi_: list of regulatory
bodies, rules, etc.
... We want to mitigate the risk upon eventual usability of
major regions
... Less easy than card centric approach
... What could this mean for Europe as the first regional
example?
... PSD has been created to foster innovation in 2007
... PSD2 is an update of PSD
... PSD has been a major change in Europe, as soon as PSD
entered into force, there is not any more national rules - same
rules for 500 million people
... SEPA is a single market in which the rules for payments are
the same.
... Access to the SEPA market requires compliance with a set of
common regulations
... It includes things like PSD, EMD, AML Directive, PSD2, GDPR
2016
... These are the kinds of regulations we have to take into
account, expecting technical regulation to come from the EBA -
it's not that much
... To have the basic reference for this regulatory issue isn't
so out of scope (large?)
... for payment instruments, where can we find useful
information. There are no PSD2 payment instruments -
introducing two new categories for PSP, account information,
these new players PISPs/AISPs help people use SEPA Credit
Transfer and SEPA Direct Debit, standard was defined 10 years
ago, they didn't hit the kind of success that the EPA was
expecting (European Payment Authority)
... Keep in mind that consumer will be prone to adopt such
payment instruments.
... This is a major opportunity, the way you have to comply -
you can't just focus on PISPs and AISPs, you have to apply all
regulations applying to those.
... About the choice of the payment method, regulation says
orgs must not insert automatic mechanisms or software or
devices that limit the choice of the application by the
payer,
... practically speaking, we don't quite know what this means,
but the general text is there
... It's mandatory for PSP, if PSP doesn't get such information
through the API, they can't use it.
... more regulation - merchant needs to know price for scheme,
interchange, and PISP - those three pieces of information are
compulsory. We have to check to see if such kinds of regulatory
issues can be pulled through the main architecture.
... What do we want to do? Pay attention? Feasibility in
building basic regulatory maps? Do we have volunteers?
<AdrianHB> +1 to manu
<Zakim> manu, you wanted to agree that it would be helpful to have a regulatory map, but more helpful would be examples like you provided
<Ian> Manu: Thank you, Jean-Yves...good to see relevant regulations
<Ian> ...I agree it would be helpful to have a basic regulatory map
<Ian> ..what would be helpful is to identify issues...e.g., "Not restricting the choice of payment apps"....being able to point to regulation specifics and checking boxes to make sure we are doing the right thing might be helpful
manu: I think a general regulatory landscape chart would help, but more helpful would be specific examples of things we should and should not do tied to specific text
jyrossi_: The relevance of the work will need cross-examination
Max: Thanks, that was useful -
it's important for the IG to look at that - we can volunteer
to help.
... As far as ISO20022 - what is the regulation landscape
around that?
jyrossi explains regulations around 2012 and ISO20022 - specifically around payment service providers
<Ian> This seems relevant -> https://www.dnb.no/en/business/transaction-banking/international-payments/sepa-end-date.html
jyrossi: This is a work in progress wrt. the reach of the law and how it happens
<Ian> "For the Eurozone, the deadline was 1 February 2014 (with a possible extension to 1 August 2014) and for EEA countries outside the Eurozone the deadline is 31 October 2016."
<Ian> Companies and institutions (with the exception of microenterprises) need to comply with the following requirement:
<Ian> Use of ISO 20022 XML message format when sending files containing SEPA payments to their bank
<Ian> This requirement does not apply for microenterprises.
Max: The regulation policies for the new payment service providers, they change very fast - how can we document that?
<Ian> ----
jyrossi_: that's an important point, the flexibility of the regulatory industry is not good/fast - how can we stay flexible on such options? That might be a key to success.
AdrianHB: I'll volunteer for
South Africa
... I think concrete cases would be helpful
... We had a payments camp and a technology camp and we're
coming closer to understanding where we do and don't step on
toes.
... I think the approach is to get something out there and get
feedback.
... I think that runs counter to other standardization
approaches, if the feedback is that "we can't use this because
of X, the WG would change it"
... Someone made the comment about there not being a place
where an open standard body in the payments industry. With
Interledger, we've been wondering where we could go to do
non-technical standards but with the same kinds of structure as
W3C.
... It's hard to roll things out iteratively in financial
services.
dezell: I think our US Fed folks
should take first crack at that.
... We need to be clear - any developer that develops a web app
must follow regulatory requirements where their apps are used,
W3C is not responsible. We can help speed their implementation
by giving guidance. We want to give guidance, but not take
responsibility
jheuer: I saw one of the
requirements here - provide a reference to the end user /
payee.
... The whole thing is going to get complicated if we need to
track fees, etc. - may interfere w/ communication if one of the
parties decides that they don't want a particular fee
... I think it's important to have a reference ID in Payment
Request so we're not forced to have one round trip... we may
need a more chatty protocol.
... Therefore we may need IDs for these payment requests
... I doubt we'll be able to do this with one monolithic API -
we should follow this rule and have a reference that can be
used by everyone in the transaction so people can say "I did my
part"
<Erik> Erik: There is no global payment authority and the burden for fraud has fallen on the organization that owns the payment scheme. However payment fraud does not always occur solely within a given payment silo. In the case of a browser payment API, the implementer of such a spec will enter the fraud liability chain. The implementer will, under certain situations, fall under what's called a
<Erik> cross-channel liability. Cross-channel liability generally falls under the principle of assigning liability to the control point best suited to prevent fraud. Cross-channel situations are handled on a case by case situation.
jyrossi_: That's an important
point
... There is a fear of using new instruments... another fear is
financial reputation - if something bad happens, you may have
to live with that for a long time
Erik: If there is no global authority, and the advice given is not clear, the burden falls on the implementer.
<ShaneM> ScribeNick: ShaneM
Ian (Chairing the session): Welcome Brad, Mike, Daniel.
Ian: Thanks for coming. We have
had discussions for a while about Verifiable Claims. Use cases,
characteristics of the system, approaches. We are sort of at an
impasse.
... What I would like to get out of this session is what we
agree to and what needs to be done.
... so we can conclude there is no chance of coming to an
agreement, or it needs to happen in a working group, or we need
to talk more...
... I would like to start with WebAppSec; what are their
concerns?
Brad: I am not familiar with the
latest version of the spec
... so am not prepared to voice current concerns.
<bhill2> where can I find the document?
<bhill2> is it linked from https://w3c.github.io/vctf/ anywhere?
Mike: I skimmed something earlier this morning. If that is right? Looks like you are not doing stuff with Browser side APIs and only doing model. Is that right?
manu: Yes
Mike: My concerns were with the API, not the format. It is a format for something that concerns me. But I don't have an opinion on the format.
Ian: would you say Manu that there are future browser implications?
manu: Yes... If I understand the
original concerns, there were some issues with cross origin
identifiers. We have removed any preference. The spec doesn't
make any statements about the types of identifiers that you
might use.
... we would have the discussion in the working group. If there
were a browser API that was proposed.
Mike: There don't seem to be any
browser implications for the stuff that is being
proposed.
... but if all you are doing is making a format, then it is not
solving any use cases.
<manu> https://w3c.github.io/webpayments-ig/VCTF/
Ian: How do you see this evolving?
manu: we had a set of use cases
that drove the work. The needs of the community. We try to make
statements that we are signature format agnostic.
... does your question remain?
Mike: What I want to avoid is rubber stamping a format from a security perspective, because we are suggesting the format doesn't have any format on browsers. Then in the future just moving ahead and putting it in browsers because WebAppSec blessed it.
Ian: These blobs are not being in browsers, right?
manu: correct. But in the future, there might be some browser implication. The data formats might only be used on the backend. But there might be some future mediator role.
Ian: As in a pipe for data through the system?
manu: yes.
AdrianHB: But the mediator has to look at something in the data to do it's job.
manu: Only to the extent that it is passing data from the users claim wallet to a consumer.
Mike: I don't want to see
credentials exposed to the browser in a way that they are used
like certs have been used recently. But as long as we are
talking about exchanging data over the network in the way we
have always exchanged data over the network, I don't have
concerns.
... I think as the formats evolve we need to look at them
closely.
... if all you are doing is providing a way for backend servers
to exchange data, then.... backend servers will be backend
servers.
Ryladog: do we have a WebAppSec liaison?
Ian: what groups seem to do is invite other groups in. If things evolve, then coordination points are in the charter.
marta: there is also the security review questionnaire that people should look at
Ryladog: yes, that is valuable.
Ian: I have seen feedback like
"please don't pick a particular tech. We like ours" so the task
force has distanced itself from that and said there can be
whatever serializations...
... are there remaining comments on serializations?
... Or was that move to abstract it out adequate.
"I don't think that is a security issue. From a security point of view if there were only one we could review it more closely."
Ian: I mixed contexts here. That was more of an IETF style comment.
<Zakim> manu, you wanted to clarify server to server.
manu: server to server comms thing. We are looking at other things. We have some polyfills where a claim moves through the browser (as a mediator). But there is no implication on the browser at this time.
Mike: I understood that, which is why I am being careful about how we talk about WebAppSec's comfort.
Ian: I am trying to figure out if we agree that it is okay to go to the membership for a broader charter review.
Mike: Does the document right there have security implications that I am worried about? No. But the obvious uses for Claims do have concerns for me.
<Ian> bhill2: If this is just server-side, why not SAML?
brad: if we are talking about exchanging claims between servers, they why are we not just using SAML?
manu: is the question Why aren't you using SAML?
bhill2: what does this give you that SAML doesn't?
manu: we did a number of surveys.
The work CAN be encompassed in SAML. But users said SAML was
too restrictive in some ways. Nothing prevents from using SAML.
You can do other things. Like blockchain, etc.
... the general feedback was yeah we could use SAML, but we
want something that is more extensible. That can carry more
semantic meaning. That can work cross systems.
Ian: Does that answer your questions?
<Ian> IJ: I am hearing some more visibility of use cases may be helpful
<Ian> bhill2: Wondering if success/failure about economics or formats.
bhill2: Sort of. If I had a lot of more time I might drill down into what the objections are to SAML? I have seen a lot of things like this tried and succeed or not succeed. The success is the economics of the models, not the underlying format.
bhill2: what is meaningfully different than other previous attempts?
manu: We did a gap analysis
looking at OpenID Connect, SAML, infocard... we did it a year
ago. I can share that. We went through an extensive thought
process. There have been a lot of attempts at solving this
problem.
... we have a big grid where we evaluate the solutions.
wseltzer: do we have security experts who are excited and willing to review this. We don't have all of the security experts in the world in this room... Not even all of WebAppSec
wseltzer: do we have people willing to conduct the security reviews.
<dveditz> manu: thanks
<Ian> Mike: Security review would likely be around signatures (if just a data format)
Mike: if we are only talking about a data format, the reviews are only about the signature format and proving that the signatures actually sign the things you think.
Mike: it is not the problem like
cross origin etc.
... there is also the web crypto group that has expertise in
signatures.
Ian: one thing I infer is that
the level of comfort has to with use cases and an evaluation of
existing technologies and economic implications of those use
cases.
... and Mike said if it is mostly server to server it is one
thing, but other uses might require different types of
reviews.
... make part of this groups effort (or before) would be a
close analysis of existing technologies to see where things
fall.
... narrowing use cases might help make things easier to
review and get minds around.
Mike: Looking at the doc as it
exists today, there is not a lot to review. You are defining a
format and you are not defining an API for the format. And then
leaving it up to the users to do things with that.
... on the one hand that seems reasonable. On the other hand,
it seems less useful than it would be if there were some
interop requirements that you could actually test.
... my feeling is that at some point you are going to want to
actually do something and then it will need to be talked about
again.
... I don;t think there are implications on the browser.
... I think there are things this group wants that DO have
browser implications.
<Zakim> ShaneM, you wanted to talk about tests
<Ian> ShaneM: (I have to leave.)
<AdrianHB> shanem: there are ways we can test vocabularies, that demonstrate various important properties
<dezell> scribenick: dezell
<AdrianHB> ... this includes ensuring that the terms match real-world use
<AdrianHB> mkwst: and hence the need for experts
<scribe> scribenick: AdrianHB
erik: I had some similar
concerns.
... if we scope it to data structure first then we can keep it
isolated and build on it later
... the goal is to define a primitive data structure that is
not bound to SAML etc
<Zakim> manu, you wanted to mention why we've scoped so narrowly
manu: we do want this to work in
a larger ecosystem but we got a lot of push back that we were
trying to do too much
... we are building with this stuff already and getting implementation
experience but aren't ready to propose that work to W3C yet
mkwst: If you want to define the
format that's great but my concerns are the implications of
that format when it is used in the ecosystem with IdPs and
claims providers etc. I remain concerned about the cross-origin
data leakage
... but if we can separate the conversations then I am happy to
have that conversation when it comes along
ian: sounds like Hardware Sec had similar concerns can we follow some of the same paths they took to call out the implications for SOP
mkwst: WebAuthN are a good WG to look at in this regard
jeff: would there be a place in the WC spec to put non-normative text that warns against SOP violations that could come up
mkwst: I'd expect that to also be
in the use cases, hence my concern. The use cases already raise
these concerns.
... discussing the use cases and implications is a very
reasonable thing to do
marta: can we prevent people from
doing this? Seems like if we have a standard or not we can't
stop people doing this.
... Creating a good standard seems better than doing
nothing
... Not sure if we are there yet
... We should be working on a standard, there is a need for
this so we should define a standard
bradh: many questions about liaison. Charter scope limits what we can do. As chair, I can't commit resources to this. The Wg will need to find experts themselves which is tough given the demand for these skills
ian: Web Sec IG seems like the more appropriate group at W3C
bradh2: Resourcing will still be a challenge
<Zakim> dezell, you wanted to relate experience with browser implementation in a PCI-PTS environment
dezell: Not security expert.
Verifone builds credit card terminals. Very secure devices. I
tried to put a browser on one once and was immediately shot
down by internal security team. We managed to do it but the
devil is in the details. Security is not a lightweight
exercise. The right way to do this will be to do some threat
modeling in the spec.
... high bar for the WG but I think achievable
ian: where are we now?
mkwst: caveat that I haven't looked at this extensively. Defining a data format for something y'all find useful seems like a good use of a WG's time
bradh2: Neat idea. I have been involved in trying similar stuff for over a decade. I'd like to help if I had bandwidth. This doesn't seem directly threatening to the security model of the Web.
jeff: would the WG put the security self assessment in it's charter as an exit criteria.
mkwst: not sure that would have value, it's very browser focused
<Ian> MikeW: Focus on signing...signing arbitrary data is hard
mkwst: seems like the key considerations for security are in the sig algos which are defined in other specs.
marta: would it be valuable to propose a security expert to assist in the review process?
mkwst: webappsec is not a
roadblock that needs to be passed. The work, as scoped, has no
impact on Web sec.
... the concerns I have are specific to use cases for this
format
dan: getting an expert to verify the signature mechanisms would be a good idea.
ian: I hear no objections to
taking this to membership
... I hear pointing to use cases as an important aspect of
this
... there is a lot to flesh out during the WG's work which
might be called out too
... we must also consider the required liaisons and the resource
dependencies of these
bradh2: I don't see WebAppSec2 as a roadblock or enabler here. At the point that the work of this group is used in contexts that are in scope for WebAppSec we'd be more involved.
ian: Is there anything you (wendy) need to take this to W3M?
<Ian> [Process summary]
<wseltzer> wseltzer: the next steps are: take it top W3M for notice to the membership of advance review of the charter
<wseltzer> ... then send that advance notice to the AC
<wseltzer> ... bring it back to W3M for review of the final charter, with all its details, e.g. chairs
<wseltzer> ... and then to the AC for review/approval of the proposed charter
<wseltzer> ... I'll take it to W3M for the advance notice this Wednesday
<Ian> (Marta presenting; slide not available online)
<Ian> scribe: Ian
Marta: I co-Chair blockchain CG
with Mountie and Doug
... we met 2 times this week in our CG
... the blockchain workshop in June had about 100
attendees
... discussion revolved around identifying discussion topics
for the CG
... this week we had lots of attendees...we had 30 people who
met for 5-6 hours
... we are looking at what we want to do, how to
self-organize
... we noted that the traction after the workshop was not as
strong as we had hoped...despite an enthusiastic participation
at the workshop
... we realized we had not adequately identified use
cases
... so we are planning to produce a report on good,
interesting, and bad scenarios for applying blockchain
... the CG intends to serve an education function (when to use
blockchain and not)
... we have started to gather "as many use cases as
possible"
... and we'll triage them
... e.g., things that make good sense, no sense for the web (or
harm the web), etc.
... after that triage we will then prioritize
... this approach will give us a reference document for the
future
... our goal is to have the "broad" use case document by the
end of the year
... then we expect to meet face-to-face again (within the next
6 months)
... we are more confident now that we have a plan
... we took advantage of weds breakout to do some education
around blockchain
... I was very happy with the opportunity to raise awareness
within the w3c community
... we are refraining from talking about "what is blockchain",
versioning, and other topics
... I believe our CG will not ONLY be focused on currencies and
financial services use cases
<Zakim> manu, you wanted to ask about gap analysis wrt. use cases
(Looking at slide)
(Showing use cases in different categories)
<Zakim> ShaneM, you wanted to ask about VClaims and about overlap with the Linux Foundation work
ShaneM: Several topics came to
mind - relationship of ILP to blockchain, and verifiable claims
to blockchain
... also digital offers work of the IG
... I think we may have more use cases for you
Marta: Please send us your use cases
ShaneM: What about hyper ledger foundation relationship?
Marta: I think w3c and hyper ledger foundation will address different layers
<Zakim> manu, you wanted to ask about gap analysis wrt. use cases
Manu: Any consideration of doing
a gap analysis before the workshop?
... suppose someone is using a web site and wants to write
something to a blockchain, but there's not a unified HTTP API
to do so
shepazu: We can look to existing projects as a source of gap analysis
<shepazu> https://www.w3.org/community/blockchain/
<shepazu> https://lists.w3.org/Archives/Public/public-blockchain/
<marta> https://letstalkpayments.com/wp-content/uploads/2015/09/Untitled2.png
shepazu: I realize there is a lot
that people might want to do. There are also many competitors
with W3C in this space...some orgs, some communities,
etc.
... personally I would like to focus on (1) things that are
close to w3c's known expertise re: the Web and (2) how ready something is for
standardization...including number and diversity of orgs who
wish to work together
scribe: Chainpoint folks have
formed a community group we'll be working with
... their interest is proof of existence / receipt
... that would be a good starting point and indicator that
people can get work in this space done at W3C
AdrianHB: What are the next steps for the IG?
marta: For now there is nothing
we need from the IG
... but bring use cases to us
AdrianHB: Sounds like similar relationship with the ILP CG
shepazu: Makes sense to bring
chain point discussion at some point to the IG for discussion
of receipt use cases
... another idea is pointing to a license (may be relevant for
payments...)
marta: There's also a distinction between doing something on a blockchain v. "have a more advanced distributed ledger"
<manu> Ian: I heard her say - if you want to do stuff, do it in the appropriate venue, and then bring it back to us.
Marta: Please send ideas to the mailing list otherwise they will get lost
AdrianHB: It sounds like one place where W3C could play a role is in vocabulary definition
<dezell> Note: no action for the IG from Blockchain. Action only to individuals to provide input to the community group, if applicable.
[We are updating here => https://www.w3.org/Payments/IG/wiki/Main_Page/FTF_Sep2016#Next_Steps_-_For_Discussion ]
<Zakim> manu, you wanted to make a note about use cases
Manu: I am concerned about bandwidth
IJ: I have very strong reservations about top-down approach
dezell: I am thinking a simple model for communication
<Zakim> manu, you wanted to be concerned about bottom up, but re-using existing stuff
IJ: I have serious doubts about
the ability to create a broad encompassing overview
... e.g., web arch took 3 years 15 years after the invention of
the web
===
Focus IG effort in these areas, per discussion at the f2f
Digital Offers
Champion: Linda Toth
Next steps: Digest the IG discussion, meet as a task force, launch CG around 10 october
Regulatory Review
Champion: Jean-Yves
Next steps: Set up a place to gather materials from contributors in order to build a regulatory mapping
ISO TG1/ISO20022 RMG+RA/W3C Liaison
Champion: TBD.
Next steps: David Ezell to talk to Kris Ketels about champion role
Vision
Next step: Ian to help organize a review of our Vision piece with a view to updating it. Also review role of use cases document.
Communications
Champion: David Ezell
Next step: David to work on an overview of W3C payments (and related) activities and how they relate.
Watch these spaces
Verifiable claims
Next steps: VCTF to work on a package of information (charter, use cases) to request W3M review.
Paid Content CG
Blockchain CG
ILP CG
====
[Logistics]
* We will continue to meet at 10:00 ET on Mondays
* We will continue to call meetings as needed
* We expect most work to happen in "task force" meetings, and periodically the IG will convene.
scribe: so task forces can use that slot when the IG is not using it
[Next FTF]
dezell: I think it's helpful to co-locate with the WG
AdrianHB: My expectation would be early next year...but we have not yet discussed
Katie: China?
IJ: A variety of considerations, including Host (e.g., Korea, China), alignment with other meetings (e.g., April in Beijing)
3 October
