See also: IRC log
<padler> Agenda for todays call has been posted here: https://lists.w3.org/Archives/Public/public-webpayments-ig/2015Apr/0148.html
<padler> https://lists.w3.org/Archives/Public/public-webpayments-ig/2015Apr/0148.html
<scribe> scribenick: manu
Pat: We had a good discussion
last week - was not able to document yet, we should talk about
that now.
... We're going to discuss Adrian's request - document goals
vs. architecture goals
... Key concepts/framework for requirements capture - Ian and I
met and talked about what we thought were core foundational
concepts.
... If we can agree to those things, we can divide and conquer
- concepts... section 2 will take up significant chunk.
... Section 3 of agenda - likely interfaces/communication
boundaries.
... What do actual requests look like - what's talking to
what?
... Suggestion by manu - prioritization/docs - high priority
vs. low priority needs - iterate document to try this approach
out.
... Lastly, scaffolding - as we go through use
cases/architecture iterations - do we need X, and Y...
etc.
... This list is not meant to be final/concrete... they are
suggestions for discussion...
... Want to try to break down work so we can put something
out.
... We need volunteers on each section.
Pat: Goal is to describe what
we're trying to achieve - what's the vision for Web Payments
from a high-level narrative, across different WGs.
... Maybe another requirements document... this is the glue
that provides the unified vision.
... Specifically, what sections - document what's on the call -
what do people want from this document?
AdrianHB: Then the goal of this document is to define the vision?
Pat: Yes, I think that's where
it's going - executive summary / use cases.
... "This is what the group feels like payments on the Web
should look like - doesn't go into detail on 'how', but 'what
we want to achieve'" - SMTP for payments - this document
captures that. Terms/concepts that we want to reinforce.
... WGs should be able to look at this document and understand
what they need to produce from a technical perspective to
achieve what's in this document.
AdrianHB: So, that's what this document is going to define... are we only talking about technical perspective? Anything more? Are we calling this the architecture document?
Pat: The key is that there is some high-level conceptual construct - maybe the "vision" document - architecture crept in ... maybe it's not architecture, it's technical vision for the Web Payments work.
AdrianHB: Then, this document will contain a vision statement - then more technical stuff around definitions - players/entities - terminology stuff so we're all talking about the same things - common glossary - two parts of the document, then?
Pat: yes, you want every WG that picks this up to look at the document - "here's what's needed from an identity perspective" - how do we identify accounts in an interchangeable way - key concepts we want to connect, goals.
AdrianHB: That's three parts - vision, definition/glossary, then there's a high-level requirements piece.
<Zakim> manu, you wanted to say the goal should be to outline the technical vision.
<Ian> [Sounds reasonable to me: what we want to accomplish; how we will talk about it; requirements that are derived from use cases]
<Ian> Manu: we have goals: https://www.w3.org/Payments/IG/wiki/ExecSummary
<Ian> ...we could refine that
<Ian> ..but I think we need an architecture document; how things fit together
<padler> +1 to making this a "technical" vision as opposed to just a vision...
<Ian> ..i would be concerned if we avoided enough detail
<Ian> .e.g, we need to be able to say that we need an extensible data format; and crypto to ensure that it's secure in transmission, etc.
<Ian> ...you want the WG to address a clear set of problems
<Ian> (IJ agrees that we should get to some technical detail about requirements, but not stating how those requirements will be met (except for seeding ideas))
<Ian> Padler: There is a high-level conceptual architecture...but not protocol details
<Ian> ...it's the mental model for what we want to achieve
Pat: That's the way I see this too - high level conceptual - not protocol/weed-level architecture - more like conceptual architecture - mental model - it's documented and crisp - outlines what we want technical WGs to do.
<Ian> ...it's documented, crisp, and says clearly what we need the WGs to do
Pat: If people need to know what the Payment Agent does - it specifies what it is at a high-level.
AdrianHB: I agree that we have an executive summary, and a vision - but that's just sitting in the wiki - if people are fine w/ that, then that's okay... but that needs to go somewhere.
manu: +1 for working executive summary in wiki into an actual document.
<padler> +1
AdrianHB: That should be
somewhere
... The scope of this document is growing very quickly - just
highlighting the concern.
Pat: Everyone should feel free to update that document - payment agent document.
Ian: AdrianHB - one of the things
about that goals wiki page - the group said it wanted to create
a more endorsed version of that. I have an action to work on
that - we could discuss having it as architecture document.
It's useful as a stand-alone short document.
... I'd like for it to be more refined/prominent document -
wouldn't put it in architecture document.
... What I found compelling in discussion with Pat this week -
talking w/ media and prospective members - lots of recurring
questions. One question is "What will be different? Things work
pretty well, it better be very improved in order for there to
be industry adoption. What will the experience be as a consumer
or retailer or bank?"
... So, we don't know the answer to that yet - there's been
enough discussion about Web of Payment Agents - that's how
group is answering the question. How do we tell that
story?
... What's the information in a payment request? It's not
idempotent - common story is quite powerful - I have thought
about it as a communications tool - also as a shared model,
next level down.
<Ian> Manu: I agree with Adrian that we need to take exec summary and move to a doc
<Ian> ...I agree with Ian we should not put that vision in the architecture document
<Ian> ...doc needs to convince customers, merchants, and banks that this will be useful
<Ian> ..they will be protected by extra security and much less friction to do payments
<Ian> ...for banks, this is a great option for them to continue to have strong customer relations
<Zakim> manu, you wanted to agree w/ AdrianHB - where do we put it?
<Ian> Manu: So we need to answer the questions Ian asked in one doc, but arch is separate
<padler> +10 to interoperability!!
pbazin: The thing we're expecting from W3C is interoperability, mainly - it's important that every service provider, any retailer will be able to use this (especially on mobile). The very important thing from W3C is standardization of interoperability of all those modules.
<Ian> +1 to interop as the ultimate _technical_ goal
<Zakim> AdrianHB, you wanted to ask about handing a Value Web Manifesto (developed by Ripple) over to the W3C to publish as a group note
AdrianHB: We have a "Value Web
Manifesto" at Ripple - a vision statement around exchanging
value as easily as email. Couldn't we take that work and hand
it over to W3C? Could we publish that as a group note?
... People seem pretty happy to do that - if group is
comfortable with that - I think I can make that happen.
... Would people be comfortable with that?
<AdrianHB> +1 to interoperability (to me the only people who should be worried aboutwhat we are doing are integrators not banks, retailers etc)
padler: I'd like to take a look
at it... don't want to just have a payment system to just
exchange value w/ customers... but want to exchange value w/
employees, merchants, partners, etc.
... Even though there are definite use cases at POS - the goal
here is "SMTP for Money" - outlined via Ripple document - there
should be a way to pass value.
... As I think about the vision - we need to hit those things
pretty hard. Different groups prioritizing different things -
core concepts are very important. If we don't unify, we won't
be relevant.
Ian: AdrianHB, one idea is for
you to do a blog post using the IG blog where you put forth
Ripple's vision and say that you're excited by this vision and
why. Bringing this to WPIG because you see this as a forum to
achieve this vision. That establishes it as a Ripple thing,
doesn't preclude getting more IG buy-in, and also is a good way
to seed that discussion faster.
... Just wanted to mention that before I go.
<Ian> +1 to checking it out
AdrianHB: I can send this up to have a look at it - can do a blog post, look at it, not a Ripple thing at all.
<padler> +1 to Generic Document!!!
AdrianHB: It doesn't talk about Ripple / ledgers / etc. It's basically about value-exchange on the Web.
<Zakim> manu, you wanted to say that Value Web document should be an input, but not directly published.
manu: I'm concerned that we're talking about "vision" stuff, rather than "Payment Architecture" stuff. We need vision, but this call is supposed to be about Payment Architecture.
Pat: if we can get agreement on key concepts - we can move forward.
manu: +1 to moving on to second topic.
Pat: Discussion around payment
architecture and narrative - want to describe them at a high
level.
... If that's a good starting point, we can iterate on it
quickly.
... We're trying to boil this down into a series of simple
standards... five key concepts. If we get these right, we can
start to build around the key concepts.
... Interoperable payments on the Web can flourish if we get
this right.
... So, "Payment Agent" - a wrapper for a thing that exchanges
information around payments and accounts on the Web.
Responsible for high-level communication between payment
agents. It can run as native mobile app, browser app, part of
car dashboard. Payment Agent uses standard/consistent set of
request and response and with accounts that they're interacting
w/ in a standard way.
... "Accounts" are representations of value - accounts are
provided by somebody - "Account Provider" is organization or
person or thing that's responsible for maintaining rules and
state of account. A couple of things may illustrate this - one,
account providers like banks - banks provide accounts, you
deposit money into accounts...
... you can make requests from your phone to send money from A
to B. If it's two people, peer-to-peer, you may have a local
store of value (local account - app provider owns payment
agent, because they're responsible for store of value - submit
requests to transfer money from local/app accounts)
... Merchant scenario also applies - run agent in the cloud -
shop via browser or in store. Payment Agents talk to each
other, are provided by an entity that's responsible for account
information that they have access to.
<Zakim> manu, you wanted to ask about Payment Agent.
<padler> manu: need to disambiguate Account from other non-money accounts..
<AdrianHB> +1 for value account unless we are only focusing on money
<AdrianHB> account provider -> custodian ?
Pat: The Payment Agent has two communication boundaries - maybe three - one is that payment agent is a piece of software that interacts with a user agent. Car/browser - payment agent talks to user agent and interacts with other payment agents/accounts.
<AdrianHB> account -> value store?
Pat: Bank is responsible for that - in that scenario, I might use carphone/browser to make a request to the payment agent to pay - pay gas pump/merchant - payment agent that I interact w/ will send request to bank payment agent and bank endpoint where bank's payment agent will instruct their systems to affect the change. The account provider, we don't care about implementation details. When PA communicates that state, it's consistent. Payment Agent construct can b
e used interoperably whether they're using a DDA account at a bank, or a Visa account. Instruct Visa to move value in their network. In both cases, value is moved and result sent back to Payment Agent.
Pat: The three interfaces are 1) user agent to payment agent, and 2) payment agent to payment agent, and 3) payment agent to account.
Manu: Account or Account Provider?
Pat: We'll get into more
discusison around rules associated with what Payment Agent is
able to do to an account. For example, if I have a scenario
where I have an app - transfer value from bankCo to mobileCo
account. MobileCo is on the hook to protect their account -
responsible for updating state of that account, their payment
agent is bound to perimeter. They're responsible for the
boundary.
... Account providers are in charge of managing accounts.
... Accounts can have Authorized Users - DDA account at bank,
two people can be authorized to access the same account. State
change all happens via bank's payment agent, and then returns
status of what happened.
<Zakim> manu, you wanted to mention that "Account provider" may not make sense in cryptocurrency scenarios.
<AdrianHB> +1 "provider" is probably the wrong term
Pat: "Account Provider" and "crypto" - same thing, I'm going to transfer value - if I want to transfer Coinbase - they're responsible for store of value and what happens there. Same thing w/ Ripple trade account. Some software provider, some provider helps you access the value. We may want to think about terminology - maybe "cryptocurrency account" "cash account" "credit account"... scenario like Mint or Quicken, use some abstract term for account. Interchangeably
, we can integrate all those mechanisms because they're all sharing a common format.
<AdrianHB> +1 for ledger
<Zakim> AdrianHB, you wanted to ask if payment agent can be the account provider
AdrianHB: I agree with Manu, cryptocurrency scenario - bitcoin/blockchain is the account provider - you can trade directly.
manu: +1 to what Adrian is saying - exactly my point.
AdrianHB: Instead of "provider" maybe something like "custodian". In some cases, Payment Agent is speaking to provider - but in some instances the agent holds whatever it needs to execute a transaction directly against the ledger. Difficult to have both worlds have a common set of terminology. If we acknowledge the cryptocurrency use cases, we can come up with good terminology.
Pat: Yes, I like "custodian" - those things represent the account or amount or value - what's available on the network.
AdrianHB: In the world of value exchange, I like ledger - ultimately that's what people that exchange value, you're writing to a ledger.
<padler> +1 to ledger concept
AdrianHB: "Who can write to the
ledger" is who is the custodian... banks can write to internal
ledgers, Bitcoin/Ripple can write to public ledgers. Banks are
custodians of their ledgers. Bitcoin clients are the custodians
of their accounts on the public ledger.
... If there is no intermediary, then payment agent is the
custodian.
jheuer: There are some topics
that we're not covering - giving power to user - level playing
field - we're going too generic? We can process the payments,
where do credentials get aggregated, where do I hold my payment
instruments,
... We're mixing up terminology - we really need to take care
of user view - that's not in the narrative now.
Pat: That's not the focus of
conversation right now - the key is "payment agent" is an
abstraction that allows users to use same constructs to
communicate value.
... If I want to pay via "credit cards" or "ripple" mechanisms
- we want agents to be able to interact with one another -
distributed vs. centralized.
<Zakim> manu, you wanted to agree with jheuer
<jheuer> sounds a bit like "it's payment agents all the way down" - but where does it start?
Manu: Like Joerg, I'm concerned about not doing "user-first" design too. I think it's in there, but it's a bit hidden now.
Pat: Yes, we want the same
construct to be used. We're wildly successful if we can enable
broad adoption and choice.
... That's where that scaffolding comes in - how do payment
agents exchange information about loyalty, coupons, identity of
the agent, authorization data. Three boundaries - checklist -
how do agents find each other. How do you make sure there
aren't "payment agents in the middle"? It's more about
scaffolding - but we're definitely going toward what you want,
Joerg.
<jheuer> No contradiction - just think we should address it. Probably just point me to where it's supposed to be - underneath the scaffolding.
Pat: Adrian, what we're trying to
get to with "provider" concept - they're going to be providers
- Coinbase is acting as provider of software - affecting value
change on some store of value.
... The key is that two things need to be decoupled - rules
provided for money transmission (regulatory), and things that
probably relate to things that happen (store of value itself).
So, you're right - bank as custodian has regulatory
requirements, some are scheme-dependent.
... So, we have a construct - three surfaces that exchange info
w/ other pieces of software - speaking a certain dialect -
ledgers - do like that term. Ledgers, I should be able to
combine all of them together into "my net worth" whether a
person or a company.
... If this is moving in a good direction - put in some
synonyms - "account" "ledger" "value account" - concepts are
clear at least as a starter - put them in document.
manu: +1 to putting it into the document and going from there.
Pat: Adrian's going to send value
web manifesto
... I'm going to add glossary to document soon-ish
... Send comments to mailing list
Manu: If people could look at
this:
https://www.w3.org/Payments/IG/wiki/Payment_Architecture_Feature_Priorities
... I think we need to discuss Payment Architecture (how all
this fits together) - that's the most important thing we can
do.
... Are we putting out a FPWD before June?
Pat: If we can get those three
things into the document, I think the group will be able to go
faster.
... "What credentials are required for payment agents?" - we'll
be able to start talking about stuff like that if terminology
is set.
... I would like to push for a FPWD before the face-to-face.
Personally, if it's just Pat and a couple of others doing this
- it'll be difficult.
<padler> 1?
<Zakim> AdrianHB, you wanted to ask about using GitHub for document collaboration
AdrianHB: is everyone comfortable w/ using github? Easier than mailing list - commentary/collaboration is tied to content.
manu: +1 to using Google
Docs
... We failed w/ Github
<padler> +1 to using either github or google docs..
<Erik3> Sorry, not in the office today.
<Erik3> Call is now?
<Erik3> Payment Agent call I mean
<padler> just wrapping up..
Manu: We shouldn't wait for more people to contribute, let's move now. We should use Google Docs - personal account is fine.
Pat: Ok, I'll setup google doc
and we'll do collaboration there.
... Good comments/input on synonyms. - will update
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) Succeeded: s/zakim aabb is me// Found ScribeNick: manu Inferring Scribes: manu Default Present: padler, manu, Davd_Ezell, dezell, +33.1.55.01.aaaa, pbazin, AdrianHB, Joerg, Ian, Dsr, +1.614.588.aabb, jackson, DavidJ Present: Pat Manu DavidEzell Adrian DavidJackson Joerg Pascal Ian DavidRaggett Agenda: https://lists.w3.org/Archives/Public/public-webpayments-ig/2015Apr/0148.html Got date from IRC log name: 24 Apr 2015 Guessing minutes URL: http://www.w3.org/2015/04/24-wpay-minutes.html People with action items:[End of scribe.perl diagnostic output]