<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.

Goal of Payment Architecture Document

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.

Key Concepts and Framework

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: