See also: IRC log
<jheuer> Hi! Jörg here - it will take some time for me to get the phone connection up. I will follow via IRC first.
<padler> scribe: padler
manu: Manu will chair first part
until David arrives for first two topics..
... Pat will chair second part on architecture with remaining
time.
... David is back..
David: Thanks for starting... any changes to the agenda?
David: Need to add question on liaison to SC7 from group.
<manu> https://www.w3.org/Payments/IG/wiki/Main_Page/FTF_June2015
David: Items on the wiki... scroll to the bottom for agenda notes.
<dezell> https://www.w3.org/Payments/IG/wiki/Main_Page/FTF_June2015
Manu: Need for people to confirm
their time slots and topics ..
... this will help us to firm up the agenda..
... at this point, the agenda is still "Malleable"...
<manu> Pat: When do we want to have the agenda finalized.
Manu: Any other questions?
... Agenda is normally set at least a month prior..
... to allow for prep time and for people to review
agenda..
David: update on Thursday to AC... it is important to get KEY changes to the agenda so that David can talk to it in Paris..
<Zakim> evert, you wanted to discuss whether glossary / definitions should be a separate item
evert: Some discussions on Glossary but not certain that this is a separate agenda item..
dezell: several glossaries floating around and we need to work to align these (ex. Our own, US Fed, ISO, LevelOne project, etc)
<Zakim> manu, you wanted to say that I'd like to have a "glossary" discussion, separately from the other docs.
evert: Need to also decide how we deal with in-line glossary items and how they work with the Glossary documnet
<AdrianHB> +1 for glossary discussion. It's a key foundation for our work. Doing it well greases the wheels for everything else
manu: would be good to have some
time to discuss separately
... any other thoughts on the Agenda?
... key topics need by thursday
<manu> Pat: If they need it Thursday, do we need it done by Wednesday.
Manu: cutoff is actually Wednesday for Key topics..
<manu> Manu: If you have not registered yet, please register: https://www.w3.org/2002/09/wbs/73816/ftf201506/
manu: Please register!!!
<manu> https://leveloneproject.org/
<manu> https://leveloneproject.org/videos/overview/
manu: Introductory Video provides very good context
<manu> https://leveloneproject.org/the-guide/
manu: focuses on bringing financial services to the unbanked/underbanked/poor...
<manu> https://leveloneproject.org/the-guide/user-requirements-behind-the-level-one-project-guide/
manu: lots of good material to
consider here for our work..
... visited Gates Foundation several weeks ago...
... Level one project needs open standards in order to help
make this cost effective..
... Reason that the work is important is that many of the use
cases and requirements match those documented in the W3C
Payments Interest Group
... very exciting... Gates Foundation seems very interested in
working with the W3C to build open standards
... other alignment to discuss is with the US Fed Faster
Payments task force and EPC work...
... much overlap across these initiatives
<dezell> Chair: manu
<Ryladog> +1 to pulling the overlap in
dezell: also interesting
synergies - possibly non-profit efforts around
unbanked/underbanked banking...
... good opportunities here to help use the work of the Web
Payments Interest group to bring these efforts to life...
manu: it would be very
interesting if our standards can be used by these different
groups to promote interoperability... may be good to try to
achieve high scores in these efforts criteria...
... example (Support for Open Loop/Accessible Payment Systems)
is a key goal of several of these efforts
Erik: Please clarify on "open loop"
manu: by open loop they mean not difficult for merchant to integrate with the system.
<Zakim> dezell, you wanted to note the B&MGates Use Cases & need to review
<inserted> scribe: manu
Erik: We should definitely take a look at the "open loop" and other requirements, try to talk about US Fed FPTF
dezell: There are use cases that wes hould take a look at in the BMGF work.
padler: The open loop stuff - the
key - when Gates Foundation says it, or when US Fed says it -
the system is two things 1) it provides a clear set of criteria
that are needed to participate in the system
... A closed loop system creates a tiered system - PSPs would
have to come through another entity to participate. In an open
loop system, once you meet the criteria, you can
participate.
... the other criteria 2) once those criteria are met, those
organizations can get direct access. The goal with an open loop
system is you encourage participation by creating more and more
access to the system.
... Closed loop is not as interoperable.
<Zakim> AdrianHB, you wanted to suggest that "open loop" seems implied if the system runs on the Web using open standards
AdrianHB: We're talking about something that's obvious, implied - wrt. something that runs on Internet/Web - open standards fit the criteria of open loop - the only thing left is legal/social criteria. If we build something on the Web, it covers all the use cases - it's exactly what they're looking for.
Erik: This goes hand-in-hand w/
closed-loop / open-loop - problem is that there are lots of
good standards in fianncial services that are not open. Big
difference between having an ISO spec vs. having an RFC - RFC
is more open.
... There is a lot of discussion going on wrt. user's identity
- as long as you know identity - you can let them participate
in the network.
... BLockchain is open to all, for example - as long as you can
validate the information. We should dive into this deeper -
talked quite a bit with US Fed, other orgs on "openness".
<Zakim> manu, you wanted to close to queue on this topic.
<scribe> ACTION: Manu to find commonalities between US Fed FPTF, BMGF, and Web Payments IG use cases. [recorded in http://www.w3.org/2015/05/04-wpay-minutes.html#action01]
<trackbot> Created ACTION-99 - Find commonalities between us fed fptf, bmgf, and web payments ig use cases. [on Manu Sporny - due 2015-05-11].
padler: There are benefits to closed loop - so, system where critical large value payments go over it - we may not want that to be open loop. Both are complementary - you need both to facilitate different use cases - we shouldn't think /everything/ needs to be open loop. Just that there is choice.
<Zakim> padler_, you wanted to clarify comment on closed loop
<Zakim> evert, you wanted to note that a payment guarantee may be difficult to achieve in an open loop system
<padler_> +1
Evert: If you need to have a payment guarantee - you have to implement the schemes so people are guaranteed that the transaction goes through.
<padler_> Ryladog: different thresholds and non-functional requirements my impact which type of system is used...
Katie: In the instance of open loop - underbanked - there is probably a financial line that could be used - don't know what that could be - underbanked would be using a much smaller threshhold - if it's less than $1K/month - you use openloop, larger value uses closed loop. We use both - no need to pick one vs. other.
<padler_> Ryladog: likely need both kinds of systems
<padler_> manu: any additional comments on Gates foundation work?
<scribe> scribe: manu
padler: During the calls, we had lots of good discussion and updates to material. We've been working to refine those.
<AdrianHB> https://docs.google.com/document/d/1FbHscEFUA1P6Frm9h-98bgBF8oCNNu3_0BZh8l7Aa0c/edit#
Payment Architecture document ^^
Value Web Vision document: https://docs.google.com/document/d/1B7WGoj-5M9X_S0-XZYTw6BWi9WytMXta44lhtqZvRjM/edit#
pat: There are two documents out
there right now - we're doing rapid editing on Google Docs,
we'll move them back into github repository once they are more
solid - if you're having trouble accessing those, let us
know.
... We've settled on a few key comments - key decision points
wrt. payment architecture.
... We have a thing called a "payment agent" - decided on the
last call - 3 core interfaces... interfaces to users...
interfaces to network of other payment agents... interfaces to
manage accounts of value.
... There are all sorts of detail in document if you want to
dig in deeper - look at those, see if first critical boundary
makes sense... if it doesn't, let us know.
<Zakim> dezell, you wanted to +1 the channels
<Ryladog> +1 to great doc
dezell: Great work on the document, it resonated with me when I looked at it - puts our whole architecture into a connectivity model - this is something that works really well on the web. SHould be relatively easy to identify process flows for ISO20022. It will also make it possible for us to model the specifications on some very positive language like "??? calculus" - promise of all of that. Glad to see this document moving forward, think it's good.
<dezell> s/\?\?\?/Pi/
Pat: Quick heads-up on other work
that's being done - document is not complete by any stretch of
imagination - now that we have 3 channels, we're going to go
deeper into payment agent itself - key requirements that a
payment agent needs to a) have access to, or b) support via
comms
... For example, how you get access to identity, how payment
agent itself has to deal w/ content encryption or other things
that need to be stated in the document.
<dezell> Chair: Manu
pat: Things that are mandatory
for payment agent architecture to work - if Payment Agents are
required to forward requests - adrian had a great picture where
a message flows through multiple payment agents - that would be
a key part for the document to include.
... The other key point is that we've been talking about a
vision document - come up with a document that talks to "what
we are trying to achieve" from a vision standpoint.
... So, when we discuss open loop vs. closed loop - what do we
want to support? One, both?
... Ripple has pulled together a draft of a manifesto - a
standalone document to hand out to people - this is what we
want to achieve - vision, reference manifesto in payment
architecture document.
<Ryladog> Vision should support the unbanked/underbanked - maybe not necessary to say open/closed loops
AdrianHB: I sent an email out
last night w/ a link to the Web Payments Vision - my proposal
is that if there is consensus, that we publish it as a note
that is our line in the sand reference document of our vision
for an Internet of Value.
... The work we're doing can then build toward that vision -
let's collaborate on that document as well - if we can get it
finalized by face-to-face, that'd be great.
Ryladog: We should talk about the underbanked/unbanked and it may not be necessary to talk about open loop / closed loop -
<AdrianHB> https://docs.google.com/document/d/1B7WGoj-5M9X_S0-XZYTw6BWi9WytMXta44lhtqZvRjM/edit#
Ryladog: Accessibility should be part of the vision too
<AdrianHB> That's the document
Manu: +1 to accessibility being a part of the vision.
Pat: The key here, if you have a
chance to review the document - we're having another call on
Thursday at 10am ET - and another one on Friday.
... Any comments on documents, let's integrate them soon - we
want both documents in good shape before June meeting. We want
to spend Face-to-face spending time to work on harder items to
get agreement on.
... For example, content encryption and how that's handled -
how loyalty and coupons are handled, etc.
... Gates foundation material has great material on
underbanked/unbanked... Fed has their own faster-payments task
force.
... Facets of agenda that have to be in the document itself -
make sure we can support those - get concrete next steps and
get work handed out to right standards groups.
Erik: A bit of follow-up on
Payment Agent - had discussions w/ chair of IETF and US Fed
CISO - trying to open some of these technologies - so we can
have Payment Agents transparently re-route messages. Another
use case brought up - user display - need to chat about that w/
you Pat - routing info back to browser, can you see account
balances and bank accounts to be viewed?
... We need to talk about actual UI itself - maybe Thursday at
10am ET?
Pat: Yes, right.
... Friday at 9:30am ET - 13:30 UTC
Erik: We should sync offline, perhaps?
Pat: Anyone else is welcome to
participate in that discussion too.
... Reading through some of the LevelOne project stuff - in
their "lessons learned" section - they documented things that
their system would not do - for example, they were not going to
handle things like "return payments" - because it increases
cost.
... Merchant protection laws - as we get into payment agent, 3
channels - what's required to support the 3 channels -
fantastic topic for face-to-face - is it the protocols job to
enforce that an account balance should be displayed/not
displayed?
... Good discussion on what standard needs to support - make it
clear wrt. interoperability - there are a couple of lines that
we shouldnt' cross.
<AdrianHB> +1 for leaving "return payments" and other network/regional mandated behaviour out of scope. They get implemented on top of the technology
Ryladog: Wondering if in vision
of coupons/loyalty - we have the concept of gifts?
Companies/orgs providing gifts?
... If someone wants to provide money, or organization wants to
provide money for underbanked - if people want to provide money
for people to open accounts using new open system - is that a
thing we should we think about - or is that too far out.
Pat: That's an example of Red
Cross or other orgs that accept payments for distribution -
that's where work on Vision/Manifesto glues together payment
networks - if you can accept payments from any payment system
on the planet, debit card, credit, crypto, etc. - if you can
use same protocol to forward payments to end party
... In the most frictionless way possible, what's outlined in
the manifesto - if we can get technology right - there will
always be different networks - it'll be much more efficient to
route from party-to-party w/o having people need to be on the
exact same system.
Ryladog: Do we have a donation use case?
<AdrianHB> +1 for a donations use case
<AdrianHB> (if we haven't got one)
Manu: no, we don't - so we should add that.
Pat: The gifting use case should be supported - but we might get into cases where person receiving payment doesn't want to receive payment. From an estranged parent, and I don't want to take it.
Ryladog: Or a criminal...
<AdrianHB> +1 for considering the requirment for payment agents to reject incoming payments
Pat: So, we get into a channel discussion - in a payment agent - when it receives a payment, is there an authorization that needs to be done?
Ryladog: Accept or reject - not too hard, is it?
Pat: The question is what happens to the reply message - how does it get back to originating source... whole different ball of wax wrt. standard.
dezell: This is an interesting
thing to bring up - about enforcement - there is an old maxim:
Be liberal in what you accept and conservative in what you
send. When we think about agents and how they interoperate, we
need to keep that maxim in mind.
... The other thing, two quick things on AOB.
dezell: We have been granted ISO
liason status - we can appoint experts to review their work.
The experts can share the documents w/ other people in the
IG.
... I'm appointing myself as an expert as a show of good faith
- if they know a couple of us, that'll be a big help wrt.
cooperation. We don't want a bunch of noise from ISO when we
send things to REC, this is the best way to manage that.
... If any of you would like to join me - if you want to
comment on behalf o this WG, send your name to me.
... Next order of business - we're going to go to WebEx - don't
know what this means - WebEx for voice, most likely - they'll
be presenting to AC this week.
<jheuer> +1 for webex - i ahd a lot of trouble just today for connecting via phone.
dezell: Erik, we need to take this into account - don't want people to be blind sided when Zakim ends first of June.
<dezell> next call - May 11
<jheuer> Bye folks - I did hear almost everyhting at least
<dezell> I meant to introduce Manoj
s/topic: Payments Architecture//
s/Topic: Level One Project//
This is scribe.perl Revision: 1.140 of Date: 2014-11-06 18:16:30 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) FAILED: s/\?\?\?/Pi/ Succeeded: s/zakim IPcaller is me// Succeeded: s/that was making too much noise.// Succeeded: s/Looking for an alternative// Succeeded: s/struggling with zakim// Succeeded: s/Manu wil/Manu will/ Succeeded: s/topic: Payments Architecture// Succeeded: s/Topic: Level One Project// FAILED: s/topic: Payments Architecture// Succeeded: s/not good// Succeeded: s/Manu, please take the con// Succeeded: s/Chair: DavidEzell/Chair: Manu, DavidEzell/ FAILED: s/Topic: Level One Project// Succeeded: i/Erik: We should definitely/scribe: manu Found Scribe: padler Inferring ScribeNick: padler Found Scribe: manu Inferring ScribeNick: manu Found Scribe: manu Inferring ScribeNick: manu Scribes: padler, manu ScribeNicks: padler, manu Default Present: padler, dezell, jiajiangtao, Manoj, manu, +1.913.353.aaaa, Matt, Katie_Haritos-Shea, AdrianHB, +31.65.375.aabb, evert, Erik, Joerg WARNING: Replacing previous Present list. (Old list: padler, jiajiangtao_(muted), manu, Manoj, AdrianHB, Matt, Katie_Haritos-Shea, evert, dezell_(muted), Erik, Joerg) Use 'Present+ ... ' if you meant to add people without replacing the list, such as: <dbooth> Present+ Pat, DavidEzell, JiaJiangTao, Manoj, Manu, Matt, Katie, Adrian, Evert, Erik, Joerg Present: Pat DavidEzell JiaJiangTao Manoj Manu Matt Katie Adrian Evert Erik Joerg Agenda: https://lists.w3.org/Archives/Public/public-webpayments-ig/2015May/0017.html Got date from IRC log name: 04 May 2015 Guessing minutes URL: http://www.w3.org/2015/05/04-wpay-minutes.html People with action items: manu WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]