<jiajiangtao> manu，hello，i am jia jiangtao from huawei，i have requested to jion wpay IG，i am sorry that the huawei's w3c manager didn't confirm my request.

jiajiangtao: ok, thanks for identifying yourself Jia - we were wondering who you were on the last call.

<jiajiangtao> manu:thanks

<scribe> scribe: manu

Pat: Quick suggestion to timebox discussion on tools/documentation/workflow.
... We want to get to more important stuff - core payment agent stuff - discussion around Vision/Manifesto/Inter-network payments.
... Any other topics that we should cover today?

Manu: I want to make sure we stay focused on Payment Architecture document.

Pat: We're going to spend the first big chunk of time going through the current document - Payment Architecture. We want to make good progress on it.
... I want to focus on consensus on how we break down the things that the Payment Agent needs to do or have access to.

Payment Architecture

Pat: We have 3 communication channels now... let's try to capture some of those capabilities in the group in their areas of expertise to contribute.
... Not only have we agreed on those interfaces - how do we handle discovery of payment agent, communication of loyalty information, etc.

<padler> zakim?

Pat: A good way to do that may be to do that - contribute in those sections - all facets are represented

https://www.w3.org/Payments/IG/wiki/Payment_Architecture_Priorities

<padler> manu: put together a wiki page at the above link..

<padler> manu: trying to map use cases to requirements to capabilities

<padler> manu: trying to create an iterative version of the architecture to illustrate working payment agents in an incremental way

<padler> manu: propose using wiki to work requirements and then move them into architecture document

Adrian: Some thoughts - great job, linked to use cases, lot of work thanks for that. Haven't got all the way to the bottom of it. In our architecture document, it shouldn't be talking about things that we're putting on a timeline.

<ShaneM_> +1 about timelines never being accurate.

Manu: W3C groups tend to not do well w/ timelines... we can just prioritize, that should be good enough.

Adrian: I don't know if we should put priorities in the architecture document.

Pat: I agree, priorities are important - but I'm concerned about not having people contribute/participate because loyalty/coupons are not in the first priorities.
... We don't have the "what" defined first - we need to define that... We could be emergent "architecture will come out of what we're doing"... or we have a complete concept - may not be implemented yet. We may want a hybrid.

<Zakim> padler, you wanted to talk about priorities

<padler> manu: it sounds like we need both architecture document and priority/roadmap document

padler: There is a need for both a full view and a list of priorities.
... We need a way to identify the actors in the payment process - if we don't have that, we can't really do much else.
... Payment Architecture document would define capabilities - identify people and other payment agents - and other things like guiding principles. For example, people working on priorities - discover and identify payment agent.

pat: Does that mean there needs to be a way to route identifiers to endpoints? I see those things in business perspective - payee sends payer something - we may need to talk to IETF about DNSSEC / routing payment addresses. I see architecture document being the "what" along w/ guidance. We need to talk about how to expose data, content encryption of payment information, we need to frame that. That has to be a holistic part of the architecture.

<AdrianHB> +1 to having priorities which inform a roadmap document (how and why) AND architecture document (what)

pat: So everything needs to work on same goals.

<Zakim> manu, you wanted to ask about which section we're specifically talking about now?

Erik: Diagrams are used to tell a story - reinforce a story. For example - payment architecture version 1, then version 2?

<ShaneM_> +1 to the need for credentialing from the start

Manu: This is exactly the type of discussion I wanted this document to create.

Erik: Credentials are absolutely required in version 1.0 - credentials is a part of this, credentials is a part of this.
... If this is the document we're using for requirements/priorities - I'll help fill out this document. When I go from use cases to requirements, I break down the requirements document next - waterfall - use cases, requirements don't really work in industry anymore.
... If requirements are next - I'm fine w/ that, just want to make sure we're doing this the way the group works.
... Waterfall doesn't work very well these days.

<Zakim> manu, you wanted to ask about which section we're specifically talking about now?

<padler> manu: created priority document to help focus the work on the document

<Zakim> AdrianHB, you wanted to ask if the intention is to only document v1 priorities in v1 of document

Erik: I think Pat wanted to talk about features, then requirements.

Pat: The part we're on to now - on page 8 "What's needed to achieve this vision"? I changed it from requirements to capabilities of the Payment Architecture.
... The reason I think the section is so important, we're going to hand this stuff off to multiple groups. We need a cohesive vision of how all this stuff fits together, we're going to have the groups go off in different directions.
... The priority - what do we want to say about payment agents, how devices that are hosting them - what are their capabilities? If it's a payment agent, how do we see these things?
... If payment agent has to relay information to other payment agents, switch schemes in the middle, what do we want to say in the document?
... The Priorities is important, but we need a holistic view.
... Maybe we need likely groups or likely parties next. If we hand off a big section to identity/credentials - for each interface, what does a payment agent need - need a way to consistently identify entities w/ strong authentication.
... Credential WG - please give us the solution - we're looking for that.

Erik: So let's start putting in features, and then requirements

Pat: It's the rationale... not just the requirements. "Here's what we think the payment agent needs to do, and here's why..."
... I think if we go into the solutions, we're going too far.

Erik: Requirements are more high level - we don't need to say specifically what data formats we need to use.

Pat: Yes, we don't need to get into ISO20022 - we need to be aware of it, but what happens when ISO20023 comes around?

Erik: So language like "Must have a decoupled messages to massage data structures into other structures." There are many different types of asset classes out there.
... Not everyone supports everything.

<Zakim> AdrianHB, you wanted to ask if the intention is to only document v1 priorities in v1 of document

AdrianHB: Regarding priorities in the document - it's starting to feel like we're doing quite a bit of handwaving - it's high level - we're trying to put down an architecture document that's considering over 100 use cases. That's what value of what Manu has done feeds in to the Architecture document.

<padler> +1 to focusing architecture work on what is needed based on priority document...

AdrianHB: We can trim down the scope of what we need to do in architecture document - we need to make expectation clear about this being a first cut of version 1 architecture.
... Right now, we're designing version 1.

Pat: anything like merchant, vendor, we need to abstract out to payment architecture document right now.
... For example, cryptotoken to establish funds to send to merchant. I like the Payment Architecture Priorities - barebones core support version 1 - focus architecture work on this is great. I think we should take first section to populate whats needed to achieve the vision. The abstract concepts - basic proof of payment from use cases document, what's needed to achieve this - we need a data format for this. Adrian, looking at your comment in the document - we ne

ed a messaging format - standard communication format.

Pat: It needs to support payment-specific metadata
... If you want interop, and you want to have a payment agent communication mechanism - it requires you to have this concept of a "message envelope"

Adrian: On the basis of that - let's provide feedback on what Manu's done on the wiki, that'll inform what needs to be in the architecture document... so for example, coupons/loyalty comes in v2, we need to know that's coming but maybe we focus on v1 now in the PA document.

<Zakim> manu, you wanted to propose what we are going to write next.

<AdrianHB> +1 to defining a manageable scope for the next few weeks

<Ryladog_> Got dropped.

<AdrianHB> manu: the arch doc needs to be high level

<Ryladog_> +1 to identifying capabilities generically

<AdrianHB> manu: I like the "capabilities" language vs requirements and features yet

<AdrianHB> manu: when we are done with that we can expand the scope

AdrianHB: Yes, that's what I'm suggesting - gives us a narrower scope to focus on, helps us iterate quickly, even though we have a week between calls - the job is overwhelming, considering too many use cases.

Pat: yes, agreed - I like that - waterfall comment - this looks like a sprint plan on how we're going to tackle payment architecture document. By next week, we want people to run through payment architecture v1 - it reflects all capabilities required for v1, if we can call that done - that gives us a good scoping mechanism to focus the work.
... Other comments - if people have a burning passion for things like loyalty - work on that. We're just trying to focus on v1 stuff for this sprint.
... This helps us make sure we're making good progress - good development of the document happening via face-to-face. Only comment is that as we put those features in, we should be thinking about how groups developing pieces of architecture - functional decomposition of these things - how is it going to be consumed by those groups?
... for example, one section for credentials, another on payment agent - we need to think about how best to do v1, iterate on that quickly via functional breakdowns - section of the document that talks about identity/privacy, focuses on stuff across the entire payment architecture.
... I agree w/ priority list - if others agree w/ that, great way to frame the work.

Erik: I want us to summarize what we're going to do.

PROPOSAL: Take the version 1.0 Payment Architecture Priorities and convert them into "Capabilities" in the Payment Architecture document. Do not elaborate on low-level requirements, but rather keep the capabilities short and high-level.

<Ryladog_> +1

<Ryladog_> generic capabilities

<padler> Proposal: Use priority document as a release plan for work on the Payment Architecture document

<AdrianHB> I would combine what pat and manu have proposed

<padler> :)

Pat: We should use this as a sprint planning tool.

PROPOSAL: Use the Payment Architecture Priorities document as a "sprint plan". The first sprint will take the version 1.0 Payment Architecture Priorities and convert them into "General Capabilities / Features" in the Payment Architecture document.

<Ryladog_> +1

<AdrianHB> +1

+1

<ShaneM> +1

<padler> +1

<padler> :)

RESOLUTION: Use the Payment Architecture Priorities document as a "sprint plan". The first sprint will take the version 1.0 Payment Architecture Priorities and convert them into "General Capabilities / Features" in the Payment Architecture document.

<Zakim> AdrianHB, you wanted to ask how we handle disagreement with priority list

Adrian: Manu has put this list together, there are folks that don't agree w/ those priorities now.

AdrianHB: Let's focus on getting agreement around v1 priorities.

Erik: It's a sprint plan, we don't have to agree, necessarily.

AdrianHB: Well, for example Credentials isn't in there, we may want to put that in there to ensure that we don't have to do lots of rewriting.

Erik: It's just a two week sprint cycle, doesn't mean we won't get to credentials - ready to jump in, want to make sure we're at the point wrt. who is accountable for that two week cycle.

<padler> Proposal: Finalize Sprint 1 scope on tomorrow's call

AdrianHB: My concern is mostly around rewriting. I appreciate that sprints are not ordered/hierarchical - if you give a bit of thought up front to the order, it helps not have to rewrite stuff.
... I like Pat's proposal - high level consensus around first two sprint cycles. What we are going to do now, and what we plan on doing two weeks from now.

Erik: What we deliver on this current cycle may change what's going to happen in two weeks.

AdrianHB: Great let's set aside some time tomorrow for sprint planning.

Pat: If we can get people to look at v1 sprint plan, people will need to provide input. If focus on call is on v1 tomorrow, and we can figure that out - then we know what work we'll need to do over next few weeks.
... May 7th now... by face-to-face, two sprints under our belt, meaty topics to discuss. By iteration 3, that would be good.
... If we get consensus on the call tomorrow on next week sprint - we should have iteration 1 done.

<Zakim> manu, you wanted to comment on how things are organized in the document.

Manu: This document "work priorities" is not something I completely agree with (even though I put it together). It's just a cold hearted look at what technologies need to happen first, second, etc.

Pat: If we get people contributing and being overly vocal about certain topics, that person needs to contribute to the work. We're going to have to scope it to the people available during the two weeks.
... They don't have to be the same person, but if there is a topic there, we have to have an accountable editor/contributor responsible for contributing during the two weeks.

Erik: I agree, if someone says "loyalty" is important - someone has to do the work.

Pat: If someone finds topic X really important - someone needs to step up and do it.
... if we find that there are 15 things on the list, but only one person to do them, then that's not a realistic goal - rethink the scope at that point.

<Zakim> AdrianHB, you wanted to share a doc for homework (not the manifesto)

<AdrianHB> https://docs.google.com/document/d/1-eV4rB-mh4l8zYnU5q_ZzHcShTvQCIa_aRx46AB0Mrs/

AdrianHB: About the email I sent today - I'm trying to draw use case / story - put together a script of a bunch of participants - send it out if it's a format that someone finds useful - it's a way of abstracting away technology, understanding interactions, then understand how technology enables interaction.

Pat: We're out of time, we're back tomorrow at 9:30am ET. Anything else to share?

<padler> have a great day everyone!

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/it should be talking about things/it shouldn't be talking about things/
Found Scribe: manu
Inferring ScribeNick: manu
Default Present: padler, manu, jiajiangtao, DavidJ, Adrian, Katie_Haritos-Shea, ShaneM, Erik
Present: Pat Manu Adrian Shane DavidJackson Katie Erik Jia
Agenda: https://lists.w3.org/Archives/Public/public-webpayments-ig/2015May/0047.html
Got date from IRC log name: 07 May 2015
Guessing minutes URL: http://www.w3.org/2015/05/07-wpay-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.