Web Payments Architecture Task Force Meeting -- 15 May 2015

<Ian> agenda: https://lists.w3.org/Archives/Public/public-webpayments-ig/2015May/0110.html

<scribe> scribe: manu

Pat's recent travels

Pat: There is some interesting stuff going on w/ http://txpush.org/

<Ian> Manu: Did you get a sense of their level of activity?

Pat: They're trying to standardize a transaction push hub.

Summarize state of document proposals

Ian: We've been looking at the work being done in Architecture piece, I suggested a different way of approaching things.

<Ian> https://www.w3.org/Payments/IG/wiki/Communications_Strategy_Task_Force/Doc_Relations

Ian: All the pieces are important, we are trying to get better shared understanding of how they fit together.
... Here are the things we're working on - note new documents - Payment Architecture is now split into Vision, Requirements, Capabilities
... Use cases suggest requirements - those requirements are ultimately where source of recommendations for standards work are derived.
... We want to propose new standards work, how do we get there?
... We will be deriving requirements from use cases, then that will be the basis on what we think needs standardization.

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

Ian: At the same time, we have a lot of other discussion going on - we have pieces floating out there - manifesto, architecture document - we all agree that vision is important wrt. payments architecture for the Web - let's make it short and stable and it can guide us - publish it as its own thing.
... This is the current place we've put as of yesterday. My understanding is that Adrian is going to work w/ whoever he can find to bring that to the IG face-to-face meeting - 30-60 minute discussion about Vision. That'll be our guide for our work.
... It's not requirements or capabilities - it's just a vision. Familiar topics have been pulled out up front - W3C members should be familiar w/ that stuff. There are other payment-specific stuff.
... I'd like to see this wiki become that Vision document. By pulling it out, it'll lighten other material.
... People said "enough high-level documents!" let's get to the meaty stuff (apologies to vegetarians)
... We largely know what we need wrt. invoices, payment requests, etc. Let's work on those types of things in parallel. Ian will take the lead on requirements w/ a simple wiki to write down requirements through analysis of use cases. In parallel, the architecture/capabilities document will move forward - focus on capabilities and prioritize them w/o going into too much detail.
... For example, needing a timestamp is too low level - but saying we need a mechanism to do invoices is not.

Pat: I like the idea of having a separate requirements document.
... The more successful systems have been ones that have a vision, w/ requirements and capabilities co-evolve... then you feel good about both.
... I do want to clarify that - we talk about priorities - the priorities themselves are not going to be in the architecture document. Some kind of priority list - capabilities is not temporal - shouldn't have anything that says "when"... just the "whats"

Ian: It may be that there are dependencies that are teased out by documenting capabilities - that sort of specifies prioritization.

<dezell> [+1 to a) fewer documents (whew!) and b) focusing on the three primary segments - use cases, architecture, requirements. My experience is that this is the correct approach.]

Pat: It's a good idea to break out identity/credentials from transactions - it may not be all in a payment agent and an identity agent that cooperate. That capabilities document really has to do a good job of laying out how we want to group responsiblities.
... We want to understand how all these pieces play together in an architecture.

<Ian> ack [IPcaller]

<Zakim> [IPcaller], you wanted to say we need a map in each of these docs.

Pat: I think you were in Paris when we talked about this - when we suggested priority order - that was for sprint planning to focus. I think that was helpful.

ack [IPcaller]

<AdrianHB> +1 for the capabilities doc attempting to define roles and responsibilities of system components

<Ian> Manu: Would like a map of documents in each doc

<Ian> ...so that from any doc you can find your way

<padler> +1 to table of contents/map...

<Ian> [+1]

<AdrianHB> +1

Ian: At the start of rewrite to architecture - I did the map in text - I felt we needed to tell people that - totally agree.

<Zakim> Ian, you wanted to say we are downplaying payment agent and why

<Ian> https://www.w3.org/Payments/IG/wiki/Communications_Strategy_Task_Force/Doc_Relations

Ian: We are reaching consensus on the mapping of a different set of documents, listed here ^^
... We're trying to organize material in a nice way - we're on the topic of capabilities.
... One of the things we wrestled with - wrt. Payment Agent - having a simple notion - web of payment agents - while nice, it's a bit cart before horse.
... We've moved from talking about container talking about functionality to break out a set of capabilities. It's a more natural way to describe what we need and achieve vision and satisfy requirements.
... This is an iterative process - it doesn't mean Payment Agents go away - we free ourselves up wrt. constraining it to a Payment Agent - we may decide that we don't need to talk about Payment Agents in some places. Or that Payment Agent shrinks in functionality to the part that's the interface between merchant / browser /etc.
... We should turn our attention to capabilities.

<Zakim> Manu, you wanted to say avoid payment agent, focus on capabilities/services.

<Ian> Manu: I like the concept of the payment agent, but agree with Ian that it's constraining the discussion. I do like the idea of focusing on capabilities. Ian proposed services and I pushed back, but now I'm changing my mind.

<Ian> Manu: We might say therefore that 'these services need to exist' and maybe we can map to various concepts like "payment agent for the user" later in the doc

<Ian> ...so +1 to services that we need

<Zakim> AdrianHB, you wanted to get consensus on the scope of the capabilities doc

<Ian> ...I did a pass through the doc to check whether that would work and it seems to

AdrianHB: Can we define the scope of what's in the capabilities document?
... I like Pat's idea - define roles of each service -where they fit into the map of actors.
... I think it would be good to have that in the document as well.

manu: +1 mapping services/capabilities to actors.

<Zakim> padler, you wanted to talk about capabilities and services and composition...

Capabilities document

Pat: I like not focusing exclusively on a Payment Agent. I don't think a document w/ just services and capabilities is complete enough.
... When you apply services/capabilities to specific constraints - those constraints influence requirements - particular aspects of the services that have to be accounted for. How do we functionally compose an architecture out of the services - module for doing transaction stuff - container for doing collection of capabilities/services.
... It's going to influence the way it's going to communicate - we want to get to a point where we grow, then tease parts apart, etc.
... I think it's going to be important - capabilities/framing - it's a collection of capabilities/services that we find in the architecture - it's critical to get cohesive picture at a high level - how is it composed?

<Ian> (+1 to needing to describe composition in some capacity)

Pat: Those microservices - considerations for deployment - that'll make it useful.

<Erik> Service is a container of features and capabilities but bound by use cases and requirements. Payment agent is an implementation of a service.

<Ian> (Ian hear's Erik's +1 to doc organization)

Erik: I didn't get a reply back on security/messaging

Ian: Erik sent detailed requirements about authentication, messaging, security, etc.
... I have not studied that yet, it's a detailed document and it belongs in the "Requirements" document that we're talking about.
... What's interesting though is that at one level it belongs in requirements, on the other hand, it's grouping things together functionally.
... I don't agree w/ all of it - but it may also be a capabilities thing - we need to do the work in parallel - where do things fit in most neatly?
... We'll create a wiki page where these sorts of things should go.
... I'll look at your document and weave those things in.

Erik: These are base requirements for web interfaces to connect to their systems.

Ian: Good news is it's big long list - but we have to prioritize them.

Erik: Let me know where you want these and which documents to weave them into.
... Didn't want to send this out before we understood where they'd go.

<Zakim> Manu, you wanted to set a timeframe to get a first draft for each of these docs.

<Ian> Manu: Good discussion; hearing consensus for this approach

<Ian> ...people seem to agree also on capabilities scope (services + composition)

<AdrianHB> +1

<Ian> ...we have 2 weeks to get these docs into shape so people can review before the FTF

<Ian> ...PROPOSED: Docs to share on 1 June

Ian: it's more important that it be available to read - wiki is fine.

<jheuer> My phone got disconnected... sorry

<AdrianHB> [Thanks Ian for doing all the hard work]

<padler> +1 to idea of focusing on WIKI as delivery tool..

<padler> for June 1...

<jheuer> my connection seem really bad!

<Ian> https://www.w3.org/Payments/IG/wiki/Communications_Strategy_Task_Force/Doc_Relations#Core_Deliverables

<jheuer> What are you charginf me for - or with? ;-)

<jheuer> I can't understand a thing

<jheuer> I will just participate via IRC until the phone thing is solved...

<Zakim> Ian, you wanted to talk about payment-specific and general services

Ian: Glossary - not seen many updates.

<Zakim> Manu, you wanted to mention that we're biting off a lot.

<Ian> Manu: These are a lot of docs for the number of people we have assigned.

<Ian> ...my hope is that they will be as short as possible

<Ian> ...I think Vision can be rev'd quickly

<Ian> ...this means that our time will be split pretty badly

<Ian> ...won't be able to help each other out as much as we have been

<Ian> (+1 to enlisting more help!!)

<Ian> ...my hope is that Adrian can be done by next week.

<Ian> (Ian plans to ship the URI to the group and ask for people to dive in)

<Ian> ...so I propose we ignore the roadmap for now and look at the priorities

Ian: We need something done w/ Roadmap
... We need to have some draft charters ready by face-to-face... maybe capabilities folks can enumerate the blocks w/o detail first. See if you're comfortable w/ that first.

<Zakim> padler, you wanted to ask that requirements are labeled with an ID for traceability to the capabilities document..

Pat: as we write capabilities doc, we can point to requirements/rationale

Ian: So, good point - we need categorization so we can be systematic

<jheuer> what kinds of capabilities are we talking about? Do device capabilities play a role?

<Ian> Yes, I can have IDs. And will have a scheme for organizing

Pat: We have to figure out categorization and how to tie all of these things together.

<jheuer> (Sorry, I gave up on the phone...)

Pat: how is information passed between different actors in the system - that's going to be hard to do when we're capturing requirements.
... Base architecture - we had consistent agreement w/ 3 interfaces - how does this thing, collection of things - user-facing requirements - what do browsers or other devices need to call/get access to the service.
... We're treating other systems as having different interfaces.

Ian: I don't know in advance what right categorization is - let me try it out - do the analysis
... I don't know a-priori what perfect categorization is.

Pat: Without categorization - when you talk about security/accessibility - "of what" - the system must be secure - what does someone do w/ that. It's not implementable.

Ian: I don't know if all requirements we articulate in requirements wil be implementable - so we need to explore what the right state is. It's inappropriate to say "at this level, you must use JSON-LD" - but having a general format requirement "like extensibility" - may be possible.

Erik: We can coordinate all these things at the face-to-face.

<padler> agreed that we don't want to talk about very specific things, but a consistent understanding of interfaces and boundaries is extremely important..

dezell: great work - this is all looking good - want to echo what Pat was saying about "visible requirements" in our specs.
... Other requirements - may be requirements on financial service providers - don't think W3C will be the place that W3C puts on financial service provider - seeing two things separately will help us. I had a heated/extended conversation w/ a member - most everything he was complaining about was about requirements that are not visible in our specs. There are things that FSPs have to do, but it's not necessarily about web payments - web payments is not browser

payments. The browser is an agent, that's it - the Web is more than that.

<jheuer> +1 to not limiting our work to the browser

<dezell> Please think of how to use telcon time Monday to best effect since we're short.

<AdrianHB> +1

<Zakim> AdrianHB, you wanted to ask what we're doing with the glossary and to propose that we describe services as <entity>'s <service-type> service

Adrian: Where we're trying to define roles/responsibilities - rather than trying to be specific, we could say "payee's credential service needs these capabilities" - set of services that all actors have access to. Doesn't specify how they're interrelated. Next step is to figure out how they tie together. Just a proposal.

<Zakim> Manu, you wanted to ask for specific deliverables by end of next week.

Next work sprint

Manu: Adrian will work on Vision document and have it more or less done by next Thursday.
... Ian will work on Requirements and Roadmap w/ Manu and Charter.
... Pat will work on capabilities and move that further along.

<Ian> Manu: We need to specify actors, capabilities, composition. Pat will focus on that

<Ian> (Ian reiterates his request that "high level capabilities' should be set forth before details)

<Ian> Adrian on vision (due next week)

<Ian> Ian and Erik on Requirements

<jheuer> I can help with capabilities

<AdrianHB> +1

<Ian> https://www.w3.org/Payments/IG/wiki/Communications_Strategy_Task_Force/Doc_Relations#Requirements

Adrian: I'll help w/ capabilities once I get done w/ vision.

<Zakim> padler, you wanted to ask what the priority information needed for June f2f is..

Pat: We're moving back to getting a bunch of documents done in a row - wrt. priority iterations - are we using v1 v2 to go through rough order we go through these things on.

<jheuer> If we start top-down, loyalty, coupons, vouchers need to be mentioned, but shouldn't get deeper coverage, right?

Ian: Regarding a work plan, in order to get stuff done in two weeks - do all capabilities - or guess that certain capabilities will not be version 1.

Manu: jheuer, +1 - yep, I think so.

<jheuer> Sorry guys - I can't stay any longer. Speak to you on Monday

Pat: When we think about what's required for the June meeting vs. work going on wrt. WGs - we're taking a shotgun approach - can we clear up what absolutely needs to be done for June so we run a good meeting vs. what we need to prep beyond June. Payments roundtable - first draft of requirements out there - it feels like we're trying to get those documents so far forward - I'm having a hard time where the priorities are.

Ian: Yes, that's a good conversation for Monday. I am trying to drive the group to express the first WG charter - that's what our mission is - that's what W3M wants - I want to get us there.
... Timing so we can meet at TPAC means that we have to have something by June - we need to know what groups are going to do. If we're proposing a charter mid-august to the membership, we have two months to work on charter - we will not be done w/ taking feedback on use cases, elaborating requirements, etc.
... If the group first meets the last week of october, we have from June to October to take stuff into account.

Pat: Is the bigger priority for us to have a well structured/formed way of capturing requirements and have a solid start on them before June.
... If we're saying "here's the workplan approach" - then we have another two months after June with people contributing - refine the documents - it feels like we're prioritizing something that we need by october.
... The requirements - how much time do we put into requirements being exhaustive? or is it to focus on getting core of that in - at the meeting, following the meeting -

Ian: I need one or more draft charters that we're happy with by June - we get there by describing capabilities and getting requirements together. That is the most important thing we can do in June. The requirements can happen in parallel.
... The requirements, as we start to write them down, we'll have questions - for example "standard vocabulary" - go through use cases through next level of detail. That may be a good use of the face-to-face time. We don't need a mature set of requirements by the face-to-face meeting. I need to spend some time on requirements, doing the work in a vacuum is unhealthy - but accept that they're being done in parallel for a long time.
... There are lots of ideas already circulating - people imagine that those capabilities are necessary.

Pat: I need a good read on where we're spending time.

Ian: We need a healthy understanding of functional blocks and capabilities - but not so far as API or format requirements. Prioritized use cases.
... Manu and I were chatting yesterday - "who needs to be doing what for us to get payments deployed to the Web"... we were looking at different v1 scenarios - who would that involve - that are the capabilities that we would need.
... If a minimal implementation would involve payment agents in the cloud, where we're using standard web protocols - native implementation of payment agent - we don't have a way to communicate to a native agent.
... We were playing around w/ what it would actually look like to setup something that implements these standards. It's an interesting way to prioritize.
... We're going to focus on smallest set of things to enable payment from end to end.
... How do we get deployment of a system.
... What do we need to get done first, and who do we need at the table.

<Zakim> AdrianHB, you wanted to ask what draft charters we are currently thinking of putting forward

Pat: We need to align expectations w/ the larger group.

AdrianHB: We're talking about having draft charters at the face-to-face.

<dezell> [Monday-review what's being done, who's doing it, and who can help?]

Ian: One of them is a Payment-focused group.
... This is what we expect the group to do in v1.
... it sounds like there'll be a Payments Working Group
... There is authentication work that needs to happen.
... There's also credentials stuff - what we need them for, etc. That should inform that discussion.

Adrian: Ok, that's fine, just trying to get where the thinking is.

Ian: That could also be a Monday chat.

Pat: Agree, that would be very helpful - does W3C already have groups to do that? That may help us as we're composing things / re-composing things.
... That's helpful to understand.

Ian:

- DRAFT -

Web Payments Architecture Task Force Meeting
15 May 2015

Attendees

Contents

Pat's recent travels

Summarize state of document proposals

Capabilities document

Next work sprint

Summary of Action Items

Scribe.perl diagnostic output

- DRAFT -

Web Payments Architecture Task Force Meeting 15 May 2015

Attendees

Contents

Pat's recent travels

Summarize state of document proposals

Capabilities document

Next work sprint

Summary of Action Items

Scribe.perl diagnostic output

Web Payments Architecture Task Force Meeting
15 May 2015