Payment Architecture Task Force -- 28 May 2015

<padler> Agenda is here... http://lists.w3.org/Archives/Public/public-webpayments-ig/2015May/0213.html

<manu> Agenda: https://lists.w3.org/Archives/Public/public-webpayments-ig/2015May/0213.html

<scribe> scribe: Ian

For FTF topic: draft materials, presentations

<Zakim> padler, you wanted to add agenda item

<inserted> /www.w3.org/2015/07/zakim.html/Topic: Zakim End of Life

http://www.w3.org/2015/07/zakim.html

<manu> Ian: Zakim, end of life page ^^

<manu> Ian: We're closing it down in 33 days - I was planning to do this after the face to face meeting.

<manu> Ian: So, short answer is we're planning to use WebEx - I'll take an action to do it after the face-to-face meeting.

<scribe> ACTION: Ian to write up teleconf transaction plan [recorded in http://www.w3.org/2015/05/28-wpay-minutes.html#action01]

<trackbot> Created ACTION-106 - Write up teleconf transaction plan [on Ian Jacobs - due 2015-06-04].

<manu> Ian: Some functionality, bridge-bot and rrsagent will still be available - functionality of muting, who is making noise, we will rely on WebEx to do that.

Finalizing CfC for Vision Document

<manu> https://www.w3.org/Payments/IG/wiki/Payment_Agent_Task_Force/Vision

Vision draft -> https://www.w3.org/Payments/IG/wiki/Payment_Agent_Task_Force/Vision

<manu> Ian: Partly also speaking on behalf of Pat - Pat has sent an alternative proposal for bullets 3 and 6 - we should go over those.

<manu> Ian: Don't know if that made it to the mailing list.

<manu> AdrianHB: I have a to-do to review - if we have time, can we do that.

<manu> Ian: Can we review that now? Pat's proposal (which was not sent to the mailing list) - needs to go to the mailing list.

<manu> Ian: Bullet 3 is about security/privacy - bullet 6 is about regulatory.

<manu> Ian: Pat's bullet 3 makes an interesting shift to "Trust" - nice framing. Especially in payments, trust is fundamental - provides a great starting for needing security, don't share sensitive information, etc.

<manu> Ian: I gave a couple of +1s w/ editorial tweaks.

<AdrianHB> Suggested from Pat with Ian's tweaks:

<manu> Ian: Pat's #6 is close to what was proposed. Most of the concerns were raised by Erik - people have done a nice job at incorporating Erik's comments.

<padler> +1

<AdrianHB> Trust in the Web of payments is critical to its success. Because of this

<AdrianHB> the architecture must provide the ability for participants in the payment

<AdrianHB> process to confidently, securely and accurately identify and connect to

<AdrianHB> other participants that are party to the payment. The architecture should not disclose private

<AdrianHB> details of the participants identity or other sensitive information as

<AdrianHB> part of the payment process unless required by operational, legal or

<AdrianHB> jurisdictional rules, or when deliberately consented to (ex. as part of a

<AdrianHB> loyalty program) by the owner of the information. The Web payments

<AdrianHB> architecture should make it easy to issue, exchange and verify credentials as part of

<AdrianHB> a payment transaction, as well as a secure mechanism for the exchange of

<AdrianHB> Identity information when it is explicitly required as part of a payment.

<AdrianHB> To accomplish this, it is expected that the architecture will also need to

<AdrianHB> support an evolving variety of authentication and identification

<AdrianHB> techniques (multifactor, biometric, etc.) which can be used independent of

<AdrianHB> or in concert with a participants Identity data.

<padler> we can take this to the list..

<manu> Ian: I wanted to make sure Erik was satisfied w/ changes.

<manu> Erik: I'm fine w/ the wording... more wordy.

[No objections articulated for the draft]

<padler> +1

Adrian I will incorporate changes in wiki with Ian's suggestions and let chairs + TC know; then chairs can send email

RESOLUTION: Start call for consensus after Adrian's final edits

<manu> RESOLVED: Adrian to make final changes to Vision document, Chairs to send the email for CfC for Vision document soon after.

capabilities

<padler> https://docs.google.com/document/d/1FbHscEFUA1P6Frm9h-98bgBF8oCNNu3_0BZh8l7Aa0c/edit#heading=h.gn0ex7y2p7d6

Web Payments Capabilities

Pat: Main question is whether to include prioritization in this doc or roadmap
... One concern I have is that by putting version information in the doc it takes away from the roadmap document.

Roadmap -> https://www.w3.org/Payments/IG/wiki/Roadmap

scribe: roadmap lays out the priorities + groups
... capabilities is just the capabilities in brut form

<Zakim> Ian, you wanted to discuss my changes to document

<manu> Ian: Pat made some changes after my changes.

<manu> Ian: Edits to the capabilities document - how much of the prioritization information to have in the document vs. the roadmap.

<manu> Ian: Roadmap was supposed to be a layer on top of "unnumbered" capabilities... when I was editing yesterday, it was quite noisy to list all capabilities for a given topic. Some of them may be several years out - presenting capabilities w/ priority was helpful for presentation purposes. Organizational details can be put in the roadmap.

<manu> Ian: It would make this document easier to read - expressing it in a way that's easier to digest. In a nutshell, it meant that one could read on a single page what we could expect to be standardized.

<AdrianHB> -1 to priority in capabilities at this stage, I think we can group by role and payment flow stage to make more digestable

<Erik> I made Pat's changes to https://www.w3.org/Payments/IG/wiki/Payment_Agent_Task_Force/Vision

<Erik> Please review

<manu> Ian: I don't think you can get that if you merge everything. Roadmap can still be where to map everything - but I would include prioritization in the capabilities document.

<Zakim> manu, you wanted to discuss organizational structure.

Manu: I'm going to +1 at least the organization that Ian did ... I think Ian is right...having edited it before, it was difficult to understand if there was any organization in the document. It was not evident before.
... people who are not familiar with payments will be confused if hit with a wall of capabilities that we envision.
... the organization into areas is fine, but without more guidance it doesn't help groups see clearly what they will need to do
... if we replace Ian's structure with something else, it's still valuable to be able to read the first 5 pages and know what will happen over the next few years.
... so I'm sold on not having a merely large list of capabilities (even if organized by topic)
... those sections will be large if we conflate all the versions
... if folks don't want to see "by version" organization, then please propose a different classification. Also, "by topic" is not sufficient to help the reader

<Zakim> padler, you wanted to suggest reading order... and discuss fragmentation...

padler: I am not suggesting that we throw away Ian's draft. But from a prioritization perspective, we start with that one. And have an outline of features. And the capabilities doc has a more complete view.
... The goal of the org was to make it easier to hand material off to other groups (e.g., with charter borders clear)

(I think that Manu and Ian and pat agree with that goal and that approach of group-oriented presentation)

padler: I don't see people starting with the capabilities document.

<Zakim> manu, you wanted to say the roadmap doesn't help this document become readable.

manu: The roadmap doc (in my view) is giving an order of capabilities and mapping to groups
... i agree that there's a tiny bit of information in the roadmap that is leaking into the capability doc
... but I think that we need to ensure the capability doc is readable and stands on its own
... we should NOT assume that people will read the documents in a particular order
... if there is not a cohesive narrative that's self-contained people will be lost
... even if we recommend a particular order.
... we should also NOT be creating a document that requires you to jump around.
... with any document of size you should be able to organize the information so that people reading it can process the information

padler: It feels like there is some context missing
... I think you are right we need some top-level narrative and top-level picture to help people see a gentle introduction that describes at a high level what the thing might look like....in the first incarnation

<Zakim> Ian, you wanted to say that having loads of links into a doc does not make it usable

<manu> Ian: Manu touched on one of my points - a roadmap that makes you go into the capabilities document to understand it is not a useful document.

<manu> Ian: I don't feel absolutist about any of this - the Roadmap as we started to evolve it is what Pat is describing. But, having tried to organize the capabilities document - I find it quite useful to do prioritization inside. There is a quick summary view that basically says "this is how we're organizing capabilities into versions". Below is all the capabilities we expect to have in detail.

<manu> Ian: You can choose how deep you want to go in a single document. That's a more manageable approach - the roadmap can simply say - 'you know the stuff we talked about over there - these are the groups that are working on it'

<manu> Ian: It was, as Manu describes, a lot of going back and forth if we put the prioritization outside - it makes it hard to understand what we're doing now in the capabilities document.

<Zakim> AdrianHB, you wanted to motivate for grouping by flow

<manu> AdrianHB: I believe the right way to organize is the same grouping as in the use cases document.

AdrianHB: I think we should be grouping things based on flow
... first of all there's consistency then when you read the documents.

<manu> -1 to grouping by flow - we tried that before... too much information in each grouping - information overload.

AdrianHB: the second reason is that it makes more sense since it relates more closely to the end-user experience.

Adrian: So I'm not in favor of too much versioning in the capabilities doc
... nor am I absolutist about it
... I would prefer that things be organized based on flow

Erik: Are there examples of good documents ?

Ian: I don't have any

Manu: Most of the groups that I've seen do not go into the level of detail we are doing
... I think it is good we are going into this level of detail

AdrianHB: I think we are trying to deal with a vast domain, which may be why we are concerned by the encyclopedic nature of the doc

Manu: Pat, any suggestions for how to move forward over the next week?

Pat: I think what i just heard (which is helpful) is having multiple organizational approach (e.g., organization by flow, organization by priority, organization by topic)

padler: We need to figure out whether we want all those things in a self-contained doc.

<manu> Ian: Let's get something to the group - let's get to meat of capabilities.

(Ian and Pat will take the org question offline)

(and we can keep others in the loop)

New Charters / Face-to-face planning

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

<manu> Ian: Meeting structure is designed to get us to draft charters after 2 days - what's coming next. Prepare for the roundtable.

<manu> Ian: We want to get feedback on consensus direction from broader community - we have 15 more attending - we have 30 invitations out.

<manu> Ian: That's how the meeting is structured. Day 1 - there is a section - capabilities for payments. Pat will lead that, go through capabilities document - my sense is that it includes prioritization bits or bulk capabilities.

<manu> Ian: If we're in agreement on core capabilities to bring payments to the Web. next is closer to prioritization - look at capabilities and use cases - which use cases do we believe should be addressed in first round of standards?

<manu> Ian: The goal is to expect following minimum viable payment.

<manu> Ian: In essence, the morning is there to work through use cases and capabilities on what we want to standardize in round one.

<manu> Ian: Google will be talking about web security model constrasted w/ card security model (same origin vs. cross origin)

<manu> Ian: We want to see if we can find a path forward

<manu> Ian: Then we have a credentials discussion - Manu is taking the lead on that - need more discussion on that. There is a piece of the capabilities document focused on credentials.

<manu> Ian: So, when we express a credentials charter, it aligns w/ payments capabilities. Adrian asked to discuss settlement task force - ambition of linking disparate payment schemes through standardization - is that in v1?

<manu> Ian: So, this is building the case for the set of charters that we'll try to get agreement on by the end of the meeting. Given all that information, here are some groups that do things - have dinner, adjourn - we should be writing down the hard questions that the group will have to address or get feedback from roundtable participants.

<manu> Ian: Mark Tiggus will do a presentation - lessons learned from their standardization experience. I'm hoping we'll learn more about relationship w/ our work and theirs.

<manu> Ian: Erik has arranged for breakout rooms - we could use those rooms to discuss.

<manu> Ian: Where are we on the map to standardization - main part of agenda may stop. Afternoon has lots of time if we still need it - we may spend a lot of time on capabilities - more use cases to entertain. I think it looks a little open right now - in practice, we'll want that time.

<manu> Ian: We'll have something on security next steps - we should be able to have security discussion - Laurent will do that presentation.

<manu> Ian: Use cases next steps - look at other efforts like US Fed and Gates foundation - get better alignment from their direction. All organizations seem to believe that they'd like stronger alignment.

<manu> Ian: If we want to get this off of the ground, what are we going to do - what will it mean in practice to get our stuff adopted. This happens along the way. We should do this now in the IG work - show realistic plan for deployment.

<manu> Ian: Then we have the roundtable - prepare questions - what we want to get out of participation of roundtable - lunch and wrap up - next meeting. Break, then roundtable starts.

<manu> Ian: In addition, we're in discussion w/ Adrian - post-roundtable snacks

<manu> Ian: Where presentation/materials are necessary - Manu and I will work on adoption/deployment considerations.

<Zakim> AdrianHB, you wanted to ask about glossary

AdrianHB: I didn't hear you mention the glossary or anything about the external liaisons
... is there time set aside for those topics?

<manu> Ian: if you scroll down in the wiki - there's some stuff there. I did not emphasize either of those topics - we have time if people here have very specific things they need to go over.

<manu> Ian: No objection from me personally, I'd like it to inform the meetings - what are the topics, who will prepare presentations, etc.

DavidE: There are couple of options
... one is the breakout session
... another is we have "more discussion" time that could be allocated

IJ: When is task force meeting by phone?

<slaory_> sorry, i am off the line. we have just added 4 new capabilities for the “Payment Architecture Priorities”, which are qrcode payments, payment under guarantee , risk monitoring and provisions transferring, please review them.

<manu> slaory_, yes, I will review and attempt to integrate by F2F

IJ: Please in task force decide what you want to bring to the meeting and who will bring it.

<manu> Ian: From Utrecht meeting - we want shared glossary that's mechanically imported. We had a new effort to try and map our terms to a set of related industry terms.

<manu> Ian: That's still useful, but not clear that it's critical for June F2F meeting.

<ShaneM> Note that PF has a script that brings in the common glossary and filters out terms that are unused in the local document.

<manu> Ian: It's not critical path for June meeting.

<manu> Ian: We would need someone to step up and hunt around for terminology that's confusing.

<manu> Ian: We need a volunteer for that.

<manu> AdrianHB: We need to make sure we're not making term definitions up ourselves - need to consider external sources.

IJ: Ping Evert

<manu> Ian: Liaise w/ Evert on the glossary. Alignment with industry terms is important, internal alignment is important too - may not be able to get both done before the F2F.

agenad?

agenda/

Manu: Should we move some of these docs to respec?
... maybe not capabilities yet

- DRAFT -

Payment Architecture Task Force

28 May 2015

Attendees

Contents

Finalizing CfC for Vision Document

capabilities

New Charters / Face-to-face planning

Summary of Action Items

Scribe.perl diagnostic output