Payment Architecture Task Force - Thursday -- 14 May 2015

<manu> scribe: padler

today is review of first work sprint.

need to discuss high level of Ian's draft document

manu: also will review this week's sprint to see what worked well, what needs to change etc...

Work Sprint Update

manu: suggests that we cover Joseph's input regarding general architecture..

<Ian> scribe:Ian

Pat: Want to talk about identity
... Identity / identifiers
... worth covering today
... Maybe we can use the Thursday calls for "big topics" and Friday calls for "sprint planning and sprint review"

<padler> manu: over last 2 weeks, trying something new..

<scribe> scribe: padler

manu: using work sprints ...

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

manu: use capabilities and priorities document to try to prioritize work..

<Ian> padler: I added to the document.....broke it out into four sections

<manu> padler: I added some core sections around payment agent core capabilities - things that were common to all 3 interfaces, listed those things out per use case.

<manu> padler: Went into payment agent - user agent to payment agent capabilities - payment agent to accounts - those three interfaces were defined.

<Ian> manu: I looked at sections you added; looked good

<Ian> ...but I have a question

<Ian> Manu: We talked about capability overview

<Ian> ...I like the capability requirements and interviews

<Ian> interfaces

<Ian> ...on page 13 you talk about getting and account and transaction management...helptul to point out but I was a bit lost about where we are defining interfaces

ian: going to make higher level comments

<manu> Ian: Higher-level comments - not interrupt the work sprint.

<Ian> padler: If you look at page 12 ... User to Payment Agent Capabilities

<Ian> ...later we'll look at format of offer

<Ian> ....coming up with interfaces helps determine what's needed for different actors

<Ian> ...core is more abstract (higher-level abstract requirements)

<Ian> ...we can only get so far with abstractions like "extensible format"

<Ian> ...and the interface-specific sections will have more details

<Zakim> AdrianHB, you wanted to say that I haven't made changes directly to the document yet

AdrianHB: was a bit limited in terms of time to work on this..
... trying to elaborate on some ideas and model how value web fits in with Payment Agent Architeture.
... will be adding more comments/details, tomorrow..

manu: looking at how to move "uncategorized" section into the document...
... do we think that we want to focus more time on this now that there is more meat on the bone... or do we need to pivot to other document?
... perhaps we should briefly discuss Ian's document..

Ryladog: on page 12 do we want to assign account instruments...

<Ian> evgeny?

<Ian> you can unmet by writing "zakim, unmute me"

<Ian> you can unmute by writing "zakim, unmute me"

Ryladog: need to add "assign preferred payment order instrument"
... need to add information to allow user to tell payment agent what you need it to do..

manu: would be good to standardize on which capabilities are mandatory versus optional..

<manu> pat: It's important that for each interface, some kind of standard structure/data format as well as the interface.

<manu> Pat: When you pass payment information, mandatory vs. optional interfaces - mandatory attributes, optional attributes.

<manu> Pat: For example, you have to have an account identifier / account balance, but nicknames for accounts is up to the payment agent.

What we need

Ian: read the document, and was having trouble with it...

<Ian> https://docs.google.com/document/d/1U8ajx-6XY0CIGDSFPXNbetpea0ngYNreniMCXM2PQeo/edit#

Ian: wanted to propose some suggestions without disrupting good thinking...
... took the approach of putting into separate document to help fully express thoughts..

<Zakim> Ian, you wanted to make higher level comments

ian: seems that the three channel model may have overly constrained us..
... should we move more to just talking about requirements?
... versus trying to talk about a single thing...
... here are the services that we need to receive..
... should we focus on priorities?
... need a common set of attributes within the architecture... versus talking about detailed fields..

<Zakim> manu, you wanted to provide high-level feedback.

<Ian> (MY doc does not express what I just said)

manu: have only been able to briefly review the document...
... was with you until the document started to talk about Payment Agent services..

<Ian> (Question: Can we create a 1 page vision document and separate it?)

manu: feel pretty strongly about using page 1-4 of the document in the architecture document verbatim...
... concerned though that this overlaps quite a bit with the vision/manifesto work that Adrian is working on ...
... we need to resolve where we are putting things/how many documents..
... feels like talking about services may aid the work, thought concerned that we can draw workgroup lines by services..

<Ian> (I like "services" (or some other term) since we can find the granularity we need and prioritize)

manu: services may allow us to add new content in without a lot of mental efforts..
... felt it was a bit high level..

Ian: moving towards trying to get nice, terse vision, and then figure out how to talk to people about what we need and how we need it..
... need to have right balance of detail and abstraction..
... how can we free ourselves up to talk with people..

manu: feedback from reviewers is that "we want to have more detail" because it helps people see how this could possibly work..

<Ian> (I am fine if you want to substitute the word "capability" for "service")

manu: helps defines which API's or interfaces are needed...

<Ian> (Same idea for me...these are functional blocks of some determined granularity)

manu: really liked the concept around capabilities..
... questioning whether the group needs yet another high level document..

Ryladog: what we want is different than what the architecture capabilities should do..
... we are getting stuck between trying to discuss capabilities and trying to figure out how to communicate this to different communities..
... we know that a payment agent is going to be one of the components and we need to discuss more details, constraints, and capabilities around these..
... otherwise not one will take us seriously..

<Zakim> AdrianHB, you wanted to suggest that the payment agent is a great concept but it is premature to be designing the architecture

AdrianHB: several comments to make..
... we need to focus more on concrete real things...
... we have not gone through requirements even though we have an architecture..
... in web architecture we have clients and servers...
... key difference is that Payment Agent is BOTH..

<Zakim> padler, you wanted to talk to functional breakdown/conceptual integrity of documents...

Adrian: are we premature in documenting architecture..

<Ian> padler: Where I would agree is that....

<Ian> ...we have a couple of things we are trying to achieve...

<Ian> ...review use cases, elicit requirements, determine capabilities

<Ian> ...and frame them in a way that provides some conceptual integrity

<manu> padler: Several comments - I agree w/ the way Katie phrased it - we have a couple of things we're trying to achieve here - we're going through use cases and figuring out what capabilities are required and frame them in a way that provides conceptual integrity

<manu> padler: We want the groups that implement this stuff to have an idea of how all of this stuff fits together... for example, if we have an identity agent and a payment agent - documenting responsibilities.

<manu> padler: part of this sprint was putting /some/ meat on the bones, there isn't enough there wrt. whether what we're doing is premature or not.

<manu> padler: We're going to have several conversations as we go through here - as we've documented, we're starting to see a separate module as an identity agent - identity and identification, identification is a key thing. Being able to identify two devices - knowing right endpoint - doesn't mean it goes into one large bucket called "Payment Agent" - supporting services, core services of payment agent... provide just enough detail so credentials group can focus on stuf

<manu> f, or payment agent group implements.

<manu> padler: This document did think about use cases, not in depth, but they weren't ignored.

<manu> padler: What are the capabilities that the architecture needs to support - how can we group things so that they're covered. Maybe this is too much info for a single document.

<Zakim> Ian, you wanted to say let's not call it an architecture document and to talk about REDUCING number of high-level documents

Ian: on q for a couple of items
... agrees that we need to reduce number of documents
... can we come together on core terminology..

<manu> Ian: I want to reduce the number of things - valuable exercise to hammer something out that's useful. Maybe we can agree on terminology - heard agreement that we should have an ambitious vision for a payment architecture - vision piece is very high level.

Ian: I've heard several things: 1) High level Vision document/content - should live separately as we are less likely to update frequently..
... what is the difference between Vision document and Manifesto?

<manu> Ian: It satisfies existing schemes, meet regulatory requirements, etc. We should have that content separately. Once we say it, I doubt we'll read/manipulate it again. In practice, it's unlikely to affect other material. Let's publish a "Vision for a Web Payments Architecture" as a Note... what's the relationship between that and the manifesto. Manifesto has much of the same content... don't know if we need to call it a Manifesto - stuff in the document is standard

<manu> Web Architecture stuff.... we should focus on Payment-specific stuff.

Ian: we want to focus on Payments specific stuff..

<manu> Ian: I propose that Adrian and I work with a vision for Web Architecture is a high-level set of ambitions for what Web Payments should be.

Ian: happy to work with Adrian to get to great high level vision..
... second key thing is requirements list based on use cases

<manu> Ian: Second deliverable is "what are the requirements" that analysis of use cases reveals... that's a lot of hard work - we've jumped to 3rd thing... a set of X - different terms, functionality/capability/services - they're all useful ways to describe things that software will need to do.

Ian: third thing is how do we capture capabilities and blocks of functionality..

<manu> Ian: Manu has written a prioritization of them - can we come up with capability blocks w/o details - loyalty / identity / etc. - put the blocks out, prioritize them.

FYI... Time Check..

Ian: if we can get to key building blocks...

<manu> Ian: It's not clear to me wrt. 20 blocks we need - that's a useful starting point. That's still separate from where they're instantiated w/ 4 phases. Capabilities are beginning to emerge - don't know what they are - not trying to throw away work that's been done, but I think it is... understanding those blocks is the 3rd deliverable.

<Ian> use cases

Ian: understanding blocks of functionality will help with third deliverable..

<Ian> vision

<Ian> requirements

<Ian> capabilities

<Ian> (+1 to digesting!!!)

<Ian> Ugh, I"m not available at 2pm ET

manu: we have a lot to talk about so willing to do another call to discuss..

<Ian> (2 hours from now)

<Ian> let's meet here then

<manu> padler: I feel that we can't just do capabilities - we need to talk about how all of this fits together. We need to talk about the abstractions /and/ how they fit together.

<manu> AdrianHB: I agree - we are saying they sit inside the same thing called the Payment Agent - rather than having a list of capabilities and separating them out among roles - this system has this capability, this other system has another - Payment Agent is constraining us.

<manu> padler: We need to decompose broad Payment Agent concept. Ideally we get to handful of core concepts - core functionality must be broken out.

<manu> padler: If we go into that - is there an identity agent, is there a typed verison of a payment agent - superset of functionality that includes a number of services.

- DRAFT -

Payment Architecture Task Force - Thursday

14 May 2015

Attendees

Contents

Work Sprint Update

What we need

Summary of Action Items

Scribe.perl diagnostic output