Web Payments IG Payment Agent Task Force -- 17 Apr 2015

<padler> https://lists.w3.org/Archives/Public/public-webpayments-ig/2015Apr/0116.html

<scribe> scribenick: manu

Pat: Today - focus on discussions I've had w/ various folks on requirements space in use cases doc.
... We would like to get a structure in place to provide requirements for architecture.
... We have big picture, we need to make it concrete.
... Changes to document have focused on framing out a way to capture high-level requirements.
... Then figure out how they fit into key principles / overarching goals.
... How are those requirements actually fit into decomposing key concepts... identify contributors, etc. We will go to two calls per week to try and hit publication date we're looking for. Any additional agenda topics?

<padler> manu: wants to start generating content

Pat: This conversation is going to hopefully be the last discussion on doc structure, then we should move into content quickly

<padler> +10 to content generation..

Pat: any other changes to agenda?

Discuss Architecture Requirements

https://dvcs.w3.org/hg/webpayments/raw-file/default/latest/payment-agent/index.html

Pat: In talking w/ various people, we thought it was important to get high-level goals up front. So, introduction - summary requirements.
... Try to summarize key items the document are trying to figure out.
... Architecturally significant requirements - from there it'll talk key architecture concepts and terminology - simple example of how examples could be met - and key concepts.
... For example, symmetry in payment agents - agents can do both sending and receiving of funds... payment relays...
... Two payment agents, but only one has connectivity to the network - how does that work?
... Once we get summary - go back to use cases - for each phase of payment process - structure it so that section-by-section, it'll talk about architecture variants.
... So we introduced a summary requirements section - significant things - first some categories for capturing requirements... categories should allow us to group like requirements.
... Idea behind categories is to synthesize things more easily - look at gaps in other standards. This is not intended to be end-all be-all list, but just a start to help us to get to that.
... Idea is to create a fairly manageable list of summary functional requirements that are architecturally significant - so we can see if architecture meets requirements.

<Zakim> manu, you wanted to ask a few questions.

<padler> manu: needs to focus on bare minimum for just the first release

<padler> manu: move away from acronyms

<dsr> +1 for minimising use of acronyms

<AdrianHB> +1 for minimising use of acronyms

manu: I think we should introduce what we believe the future is early in the document.

Pat: Yes, we should reduce the use of acronyms.
... We shouldn't have those in the final document - key is trying to come up with a shorthand way to come up to refer to those things.
... Need scaffolding for people to contribute -
... Regarding high-level picture before going into detailed requirements - if folks feel like we should have a big picture view first, then I'm not tied into going into requirements too early... then analysis later on.

Adrian: I do have a question on current discussion - common group of people, on use cases document - we talk about functional categories there - payment processing, delivery of receipts - trying to marry that to what we're doing in this document.
... Are we talking more concretely or more abstractly.

Pat: The goal of this document is to use use cases material to generate requirements and material to map out what we thought were a proposed high-level breakdown that would allow for different working groups and task forces of W3C to get engaged to write standards that might be missing.
... There are already existing standards that we should piggyback on - big picture perspective - trying to achieve goals of ubiquity, user privacy, describe what should be there - what has to materialize what's supposed to be there from a standards perspective.
... How do payments on the Web work - part of that - intent summary functional requirements was to link to payer privacy use cases - negotiation of terms... so payer and payee don't need to know each other.

Adrian: I think that functional separation defined in the use cases is valuable - appreciate that we're trying to go down the use cases - this document defines requirements - I could see one working group under each category... what are the specifics? Where four goals are those categories - negotiation of Payment Terms... Payment Terms WG.
... What is still not clear to me, maybe document should say that that a decision should be made - are we trying to glue existing systems together, or are we trying to build something new on the Web.
... Payments are islands of interoperability - are we trying to tie that all together, or do something entirely new?

<Erik> - Hot link acronyms with the glossary

<Erik> - Features shouldnt come before the summary requirements

<Erik> - Detailed requirements

<Erik> - Web ties together existing systems

Erik: Agree with acronyms - put acronym and hot link w/ the glossary - you can click w/ glossary.
... Features - shouldn't come before summary requirements. We should have summary and then go through detailed requirements of the system.
... We're not trying to invent a new island - the Web is the interoperability hub w/ other systems - we're trying to integrate other systems together.

<Zakim> manu, you wanted to say kill the acronyms early on - or they'll stick.

manu: We should kill the acronyms, use terms like 'payee' - link to glossary

<padler> +1 to getting rid of acronyms...

<AdrianHB> +1 on hotlinking to glossary, +1 on avoiding acronyms (especially avoiding inventing new ones)

Pat: We'll replace acronyms in the next round.

Joerg: Do we want to support legacy? Or just Web? With relation to question - our work is crucial - interaction pattern between user device and payments - NFC technology, expanded by identity expertise - cover lots of online scenarios - that's very client-based. There could be one technology basis to cover new things as well as existing ones. Virtual world transactions as well as real-world transactions.
... On the other hand, we got it easier - we got an implementation - we just wanted W3C support - description of transaction to a web browser, how do I connect so I can connect to a digital wallet / payment agent - that kind of thing is what appeared to us - from an architectural point of view, the entire thing has become far more complicated.
... We should point to a theoretical approach that matches the challenges - we can solve all of this in one application, but that's not what standards are about at W3C.

<Zakim> padler, you wanted to talk about interop..

Pat: The whole vision of what we're trying to achieve here - glue together all distinct systems to make payments - provide interoperable standards.
... re: Payment Agent - we can bring you up to speed - standard / set of standards from a user perspective - paying with cellphone / paying with watch - something that can make payments, those can be consistent from interop perspective.
... This is an integration approach - we're not trying to displace existing standards, we're trying to create a bridge between them. Interop is key - ubiquity is the goal.
... If I go to a store - it doesn't matter which payment instrument I'm using - it should work the same way.

Adrian: No surprises here, I assumed as much - I get it, that's the goal. What I wanted to put out there - general feeling on what Evan put forward.
... To clarify - what I'm doing here - what does Value Web task force trying to achieve - provide interop between different payment systems. We're focused on retail/clearing space - we're not trying to provide a standard around settlement, around actual movement of value. We're trying to standardize more things in the front-end than back-end clearing.
... I'd like to be clear whether we want to pursue that - that's important from Ripple's perspective, there is an opportunity to move value faster - not just put promises in place ... but actual movement of funds.
... We're talking about existing payment instruments, existing payment systems, basic payment flow over the Web... but we're not talking about settlement.
... Need some clarity there.

Pat: Thanks for bringing that up - was wanting to have this discussion. Personally, I see the settlement piece of it as being as important as existing systems. This is what I'd like to suggest to the group - that's why clearing is in the document.
... Something like the Ripple protocol would fit very nicely into that - ancillary parts of the payment process - that might get into more of what you're working on.
... I see settlement as being a part of the architecture. Whatever settlement mechanism you use - for example, Bitcoin, or Cheque/ACH - it's about enabling different choices easily.
... Part of that is seeing settlement pieces being a core part of this document.

dezell: +1 to trying to align with use cases - if Ian was here, he'd be pressing us to choose the mechanisms we're going to use to realize the use cases in the architecture.
... I don't know what that looks like - but sort of like the "micro-use cases"... we should focus on real value-add of W3C - that needs to inform all of the decisions we make. W3C value-add is not security specs, it's not to figure out next tokenization mechanism, W3C's value-add is the ability to serve three audiences - user experience (payers), monetarily we want to serve merchants (called out in charter), and third stakeholder is developer community (making

a payment easy to integrate into app is how we declare victory)

<AdrianHB> +1 - "Victory = integrating a payment into a web application is easy"

dezell: If we get 1000s of developers using Web Payments, that's what we want. What we don't want is for someone to get mired in details of payments. We need something flexible enough to cover everything.
... For example, XML was accessible to a desperate Perl hacker... We want something that's going to be able to be used by a Web developer in an afternoon.
... We need to realize the first-class citizens of our architecture.

<Zakim> manu, you wanted to talk about best path forward for Web Settlement.

<Ian> Manu: We are interested in web settlement discussion, but i don't think we should put it in the critical path

<Erik> +1 I love Manu's statements about moving value vs moving promisses

dezell: We are currently discussing charters - we need some sort of architecture document/consensus in group that sketches out how we get people together to get this started is important.

Ian: Align with use cases - don't want to disrupt the flow - was there a desire to go over our discussion earlier this week.

Pat: Some sort of up-front summary of what we think the architecture and requirements would look like based on synthesis we've done, then go into the details.

Ian: Ok, we'll talk offline about that.

<Zakim> dsr, you wanted to suggest including a web developer perspective

Pat: Basically, the vision of what we're trying to achieve - then talk about how we got to that vision.

<AdrianHB> +1 to an opening paragraph in the doc titled "Vision" or "Goal"

Raggett: Earlier in the document, you should talk in terms of web developers to get them engaged - we have lots from financial background, but few from web developer background. We need to write document from their perspective to motivate them.

<padler> +1 to developer perspective..

Erik: +1 to manu's statement on "moving promises" vs. "moving value"
... Look at the web as a front-end to the back-end clearing/settlement systems. We're providing an interface into those systems.
... Can we go into how we're going to map payment agent to use cases - come up with summary requirements - please involve me in that - I want to help move that piece forward. You need requirements, then you need summary requirements before going into details, then architecture diagram... and then details at the end.

<Zakim> padler, you wanted to talk about orthogonality of functional groupings

padler: Quick note - to get to Adrian's point - on settlement stuff - priorities - one of the reasons to break out specific sections of document, to provide an opportunity to provide feedback on those parts of the system.

Pat: We want items specific to clearing and settlement. The goal is to provide enough scaffolding to allow people to contribute as much as they could on actual content.
... We'll have more specific things to work with once we have more content.
... Web developers on front-end - very important ... but recipient side is very important as well.
... Can we move once we have these items carved out int he document, then we can divide and conquer.

<Ian> [Ian hopes that everyone agrees that ALL stakeholders here are important and we best take them into account to help ensure adoption]

AdrianHB: A couple of quick points - getting clarity... "moving promises" vs. "moving value" - that's the difference between clearing and settlement. If we are only talking about "clearing", then we don't get to "settlement".

Adrian: I want to make sure we get to a position where we're talking about "settlement"

manu: I've added a "members" entry to "Web Settlement Task Force"

<padler> +1 to standardizing how settlement between 2 parties works

manu: and placed both Adrian and myself on the members list.

Adrian: When I send you something - I want to make sure we're clearing. Next steps for task force - we need to recruit - then we need to create the charter.
... If there are other people involved - let me know - Manu mentioned Bitcoin, Stellar, Ethereum - want to do aggressive recruiting before June.

<Ian> Adrian, please check out this timeline for getting draft charters together (at least a first round of them): https://www.w3.org/Payments/IG/wiki/Communications_Strategy_Task_Force#Timeline

Adrian: It's a task force today - but I see us putting a working group together to standardize access to settlement systems.

<Ian> (my recommendation would be to have a draft charter for the IG to look at at the June FTF)

Adrian: I'll see you at the face-to-face in NYC.

Ian: One quick note - for Adrian - Ethereum - are they of interest?

Adrian: Yes, absolutely.

Ian: Ethereum has joined, someone to reach out to right away.
... I heard David Ezell talk about security - W3C not doing security - we have a security activity, we have security work going on - Web security is something tremendously important across all WGs. There are existing industry standards around security, but it doesn't not mean we shouldn't be doing security - very important to look into that stuff.
... So, W3C is very active in the security space - we need to work constructively w/ other groups to make that work. Let's be cautious about saying W3C should not be doing security, just want to make that clear.

dezell: I was trying to emphasize strong value-add in developer community.

pat: if we're looking for end-to-end - payer / payee for example - rather than creating a separate document for settlement, we want some sort of reference back to architecture document. If possible, please go through requirements and start sending in comments or update github repo broken down by category... write them down, that'll help us get to a vision statement we can agree on.
... We're going back and forth on too much semantic stuff - we need to start collecting quickly so we can figure out what architecture components are.
... That's all we have for today - if you can do that by Thursday, that would be good.
... I'd like to update document w/ feedback - thanks everyone for your time today - hit me on mailing list or reach out.

<padler> Thanks everyone!

<scribe> Chair: Pat and Joerg

- DRAFT -

Web Payments IG Payment Agent Task Force

17 Apr 2015

Attendees

Contents

Discuss Architecture Requirements

Summary of Action Items

Scribe.perl diagnostic output