See also: IRC log
<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.
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.[End of scribe.perl diagnostic output]