Web Payments IG Telcon
11 May 2015

payment architecture

Manu: Regarding architecture, we have a way of addressing the document that we think will allow us to complete the bulk before the FTF meeting.

<manu> Payment Architecture document: https://docs.google.com/document/d/1FbHscEFUA1P6Frm9h-98bgBF8oCNNu3_0BZh8l7Aa0c/edit

Manu: Pat suggested we start talking about capabilities of the payment agent at a higher level than specific requirements

[+1 to NOT talking about requirements yet....just a little longer after the high-level vision]

<manu> Payment Architecture Feature Priorities: http://www.w3.org/Payments/IG/wiki/Payment_Architecture_Feature_Priorities

Manu: We went through some of the requirements .... things an agent would have to do to achieve level 1 or 2.
... every week we pick a set of capabilities we believe a payment agent will need
... we put in 1 line + a paragraph
... we are hoping that we can fill out a chunk of the capabilities this week and next
... that will allow us to come back and further refine the capabilities
... then we can talk about requirements and features
... we've made a great bit of progress in last 10 days
... we've been able to list some minimum requirements and map them to the use cases
... then we've been able to take that and distill into capabilities that we are putting in the architecture document.

<manu> Ian: Glad to see all the progress - looking forward to catching up.

<manu> Ian: One lingering concern I have is doing this as a top-down exercise instead of a bottom up exercise. I'm glad to hear there are bindings behind use cases and capabilities. Are we on hold for requirements gathering? Are we going to get to that level of detail?

Manu: Yes.
... it's already been started in the wiki page

<AdrianHB> +1 (yes)

scribe: each feature has a set of requirements for each feature

<Zakim> manu, you wanted to respond and to respond to Ian about how the priorities list was created.

Manu: I agree 100%...the architecture page was created using the detailed analysis approach you just described (even if not clear from the page)

[IJ: Thanks!]

scribe: I think we are in agreement...there may be some nuance as to picking out secondary or tertiary requirements.
... I would look at a use case and figure out the main requirements, then prioritize them into the priorities list

<AdrianHB> Ian: We should documented the analysis that took us from use case to requirement to vision

<AdrianHB> Ian: .. this shouldn't stop the work on the architecture vision but the background material will be useful for several reasons, such as ensuring that we've looked closely at each use cases, so that others may verify the work, and to avoid duplicating discussions in the future.

<Zakim> dezell, you wanted to ask for a ~30 word roadmap of the documents.

dezell: Can we review the doc relations?

<Zakim> manu, you wanted to say that we may want to make it machine processable - it's /very/ difficult to keep all these things aligned.

Manu: I agree to what you are saying, Ian. My concern is bandwidth.
... if we are going to get what you are proposing done, we need to figure out how to make this machine processable.
... the use cases started out as a set of requirements.
... we wanted to be able to automate
... we don't have that list anymore.
... we need to talk about how to make this easy on people.

[IJ: +1 to making it easy]

Manu: Concerned about effort to do it manually

<dezell> [+1 to bringing the group along as quickly and effectively as possible]

Erik: The waterfall model is old-skool
... We've not discussed our process

<AdrianHB> +1 for the agile approach, output has been good so far as a result

<manu> Ian: I disagree that we haven't discussed this - as soon as I joined the group, we started talking about planning and document relations.

<manu> Ian: My understanding of doc relations is that they've improved - vision of document and relationships have improved over time. I like the direction it's going - don't know how we can say "We believe this architecture will fulfill the use cases, if we haven't looked at the use cases in detail".

<manu> Ian: There's simply looking at the use cases in detail. It takes time. We can either say "the use cases are just there - we find them useful as a background document, but payment agent architecture is wholly independent."

<manu> Ian: It's more useful to say - "we looked at the use cases in detail, here's how we got from them to the capabilities." We need something that serves as evidence when we send this to other groups - we save them time wrt. the analysis.

<manu> Ian: I don't think it's old-school to progress from higher-level to deeper and deeper analysis.

<manu> Ian: We should find a way to do this so it's not a burden, but we have good evidence.

<manu> Ian: We should figure out a way to keeping these documents aligned... we wanted to do requirements.

<manu> Ian: Manu mentioned that we used to have detailed requirements but we didn't want them. That's not my recollection. I believe we decided that we wanted to keep the use cases simple, and then move on to deeper requirements.

(IJ: I think we can do "arch vision" first and work on requirements into the summer, including the detailed analysis)

<Zakim> AdrianHB, you wanted to ask what is required beyond the priorities page on the wiki

http://www.w3.org/TR/2015/WD-web-payments-use-cases-20150416/

<dezell> Ian: it's hard for me to determine completeness unless I can view the relation from the use cases side.

<manu> Ian: Each part of the use case needs to be examined

<manu> Ian: For example, is "presented with a total amount" - digging into each use case - what might be implied as far as interaction, protocols, etc.

<dezell> [+1 to examining each part - some parts need to be labeled as contextual, others as operational.]

<manu> Ian: I see us prioritizing in this order - vision, capabilities, requirements. If we need to do requirements later in the summer, that's fine. If we've started to work on it already, great.

Erik: We have use cases and we have a model / vision. Requirements have to be generated from something...i think we have to start from the use cases
... what is intention...reaching two audiences?

<Zakim> manu, you wanted to say it's not as thorough - we should jump back to pre-conditions / post-conditions - and put the content in the use cases (and hide the content when we publish

Manu: I think we should have the detailed discussion at the arch call this week.
... I have an idea of how to accomplish this
... Erik, yes we need to generate requirements
... Ian, there's a way to do this so that it's machine processable.
... can we do later this week?

IJ: +1

<AdrianHB> +1

dezell: Agreed.

<Zakim> dezell, you wanted to +1 the idea of a set of steps for people.

June FTF update

https://www.w3.org/Payments/IG/wiki/Main_Page/FTF_June2015

<manu> scribe: manu

Ian: One of the things I plan to do today is assign sessions to time slots.
... Need to get confirmation from folks on leading sessions.

Ian goes through the agenda.

<Ian> ACTION: Ian to assign topics to time slots for FTF meeting [recorded in http://www.w3.org/2015/05/11-wpay-minutes.html#action01]

<trackbot> Created ACTION-100 - Assign topics to time slots for ftf meeting [on Ian Jacobs - due 2015-05-18].

<Zakim> chaals, you wanted to suggest that spending 90 minutes at a stretch in a room is a way to achieve less than if you left after 60…

Chaals: I suggest that you run the Agenda like so - do 60 minutes, then take a break.

Adrian: 90 minutes incorporates Q/A

Ian: There should be around 25 people joining us - there will be discussion on face-to-face about lessons learned.
... WIll have lots of people that are not in the group as guests.
... Lots of influential folks joining. Presentation by CEO on work that group is doing, followed by presentations on work that Interest Group is doing.
... In the full set of 60 people, we want folks commenting on use cases and goals. The end goal is to hear from the industry, feedback on work we're doing - what needs to be prioritized. What needs to be added in our own direction?

DavidE: Looking really exciting to me. I'd like us to think about where we discuss the role of regulation.
... We need to get that on the table.

<Zakim> dezell, you wanted to mention "regulation" issues

Ian: We need a concrete session talking about regulation.
... Does the regulation topic have to do with design, deployment, liasons?

<scribe> ACTION: dezell to figure out where regulation goes in the Agenda. [recorded in http://www.w3.org/2015/05/11-wpay-minutes.html#action05]

<trackbot> Created ACTION-102 - Figure out where regulation goes in the agenda. [on David Ezell - due 2015-05-18].

<Zakim> manu, you wanted to note that regulation goes into the design and deployment, if we want people to speak up.

<Ian> manu: Regulation question has been out there for a while.

<Ian> ...we need to take regulation into the design and deployment discussions

<Ian> ...we need to discuss how these systems plug into regulatory systems

<dezell> [+1 to "hooks" for regulatory.]

<Erik> +1 Manu. Regulation is part of the design.

<Ian> ...we don't want to deploy only to find later that developers need to read 1000 pages

<Ian> ..the proposal is that we tell the regulators that this is the system that will be used before reporting

<Ian> ...we want them to participate in the dialog

<Ian> ...we know we need them at the table

<Ian> chaals: Mostly +1 to Manu

<Ian> ...it's not like we ignore the regulators

<Ian> ...to the extent that we can, it's useful to take the regulatory framework as we are handling other requirements

<Ian> ...I agree we need to tell regulators that they need to talk to developers

<Ian> Magda: Where are you talking about regulators?

<Ian> Magda: Gov, EMV, ....there are many groups

<evert> http://www.eba.europa.eu/regulation-and-policy/consumer-protection-and-financial-innovation/guidelines-on-the-security-of-internet-payments

<Ian> dezell: Regulatory requirements will play a role at various points in the architecture....we can't ignore them...

<Zakim> manu, you wanted to mention which regulators

<Ian> Manu: We care about all the regulators

<Ian> ...there are really two actions we need to take as far as regulation goes

<Erik> Regulators will not regulate until they have something to "regulate".

<dezell> [+1 to manu's starter set of how to look at regulation.]

<Ian> ...if payment is a series of steps, there are regulator actions at various points, either (1) report data or (2) stop the step

<Ian> ...e.g., when money is pre-@@, check with FinCen blacklist, ....etc. if you are sending more than 10K USD, you report to FinCen or some other organization

<AdrianHB> +1 for developing a technical architecture that allows regulation without baking it in (hooks and appropriate transparency/reporting)

<Erik> Regulations will mostly be the burden of the account provider (aka Bank, Exchange, etc(

<Ian> ...in this process, we are looking at where regulators hook in (Report, Halt)

<AdrianHB> +1 to Erik's comment

<Ian> Manu: Too many jurisdictions to look at exhaustively; so just want a framework

<Ian> Magda: +1 to the generic approach described by Manu

<Ian> Chaals: +1 to Manu's description - note that we will need to have a way of describing which regulatory frameworks apply to a given transaction, and how to find the reporting thresholds (frequency, amount, …?) and "stop payment" rules

Updates around the table

<Ian> Manu: Use cases focus is on arch

<Ian> ...I've taken an action to map Fed / Gates use cases

<Ian> ..priority is fed use cases first, then gates next

Manu: I will process comments on Use Cases FPWD first, sorry, forgot to mention that

<Ian> IJ: My concern is prioritization.....

<Ian> ...I think it's more important to get to charters + arch + prioritization of published use cases

<Ian> ...we have a lot to do to get to standards work with existing use cases.

<Ian> Manu: I think the priorities are:

<Ian> * Handle comments on FPWD

<Ian> * get whatever is in the doc stabilized

<Ian> * Pull in new use cases

<Ian> ...hopefully we'll have some to discuss at the ft.

Ian: I want to ensure that we handle the use cases we already have and that the outcome of the FTF meeting is a prioritization. To the extent that we can also get alignment with other sources of use cases, that seems like a good thing and worth pursuing. But I would favor handling the group's current use cases before taking on new ones. I want to note that I do expect us to continue to take on use cases in a rolling fashion, but if the primary goal is starting standards work, we need to prioritize what we have first. ... We need a laser-like focus for existing use cases.
... it's a balance between getting alignment and getting to standards, vs. listening to industry requirements.

<Zakim> manu, you wanted to mention that I don't think we have enough use cases.

<Ian> Manu: Let's move the discussion to Thursday call

<Ian> (+1)

External Reviews

<scribe> scribe: Ian

dezell: We have class D liaison with ISO
... I sent out a request for who wants to be a liaison
... we can get ISO docs for review within this IG
... let me know if you are interested in being a connector

Report from the AC meeting

<manu> scribe: manu

Ian: We met last week - AC meets twice a year and talks about strategic direction. David gave a presentation on status of our work, which seemed well received.
... There were other conversations around document licenses and process revisions and accessibility charters. I didn't have any big take-aways from payments discussion following the presentation.
... I met with a few other groups while I was there - was talking "Payments all the time"(tm)!
... Other large companies were there, talking about their activities around Payments. Nothing extraordinary popped out as result of payments discussion.

DavidE: We had a nice Birds of a Feather lunch discussion - a number of people that were interested and well informed about what we were doing.

<chaals> [+1 to "sounded like DE knew what he was doing"]

DavidE: The AC seems to feel good about this activity moving forward.

<Zakim> manu, you wanted to ask about a few "those that cannot be named"