W3C

- DRAFT -

Web Payments IG Work Session

08 Oct 2015

Agenda

See also: IRC log

Attendees

Present
CyrilV, ShaneM, Manu, Laurent_, Vincent, Kuntz, AdrianHB, DJackson, Stephanie, dezell, (briefly)
Regrets
Chair
SV_MEETING_CHAIR
Scribe
AdrianHB

Contents


<manu> scribe: AdrianHB

manu: majority of agenda is review of WG charter to review changes based on feedback from AC
... followed by tpac agenda discussion

Review Web Payments WG Charter changes

manu: any other items?

<manu> Latest charter is here: http://w3c.github.io/webpayments-ig/latest/charters/payments-wg-charter.html

<manu> All changes since IG signed off on the charter for vote: http://manu.sporny.org/tmp/payments-wg-charter-diff.html

<manu> Here are all of the changes that we'll be reviewing today: https://lists.w3.org/Archives/Public/public-webpayments-ig/2015Oct/0032.html

manu: plan is to go through changes top to bottom. On Monday the group must decide if it supports the revised charter.
... any q?

<manu> Starting from the top: http://manu.sporny.org/tmp/payments-wg-charter-diff.html

<DJackson> Meeting number = 647 262 873

manu: goals have been simplified a lot to make the document easier to digest
... if you look at diff marked version you'll see all the areas highlighted in pink have been removed
... focus is on new types of payment instruments rather than customer satisfaction (hard to gauge)
... also changed language from "standard" to "recommendation"
... all happy with the changes?

+1 on those changes

manu: 3 major changes in scope section
... simplified to say the WG will work on messages, message flows and an API

<Zakim> ShaneM, you wanted to ask about the scope of the API work

shanem: it's not clear what the scope of the API work is?

manu: In section 3.2 the API is outlined more specifically
... in the scope section we say that the WG will work on APIs as opposed to UIs and then defers to later section for specifics

kketels: seems to me this is like the orchestration of a payment interaction as opposed to an api. Seems to describe the behaviour of both ends of the API. A transaction flow.

manu: it is orchestrating the flow on the front-end
... the flow is defined but also the API
... section 3.2 says there may be many delivery mechanisms but one that will be specifically addressed is the browser
... we may do server to server flows but limited to initiation through the web and if the instrument supports it notification of the payment
... did that address the q?

kketels: agree there is a need to describe all of these things I am just not sure that I agree with the terminology

manu: this is sometimes confusing to people unfamiliar with W3C work. We are talking about 2 types of API. Browser based and a REST API. We're not talking about native APIs

kketels: happy to take offline to clarify terminology

laurent_: there is still a use of the word "standardise" in the scope

manu: will change
... any other comments?

<CyrilV> * CyrilV has to leave the Telcon- sorry

manu: section 2 has new language "mediating" when referring to the user agent. is everyone happy with that language?
... also that user agent is not limited only to a browser

laurent_: is a mobile OS a valid UA?

manu: I think so. It's not supposed to be limiting
... big change to digital wallet definition.
... (reads new definition)
... any concerns over that definition?
... section 2.2 - required capabilities has 4 major changes
... first is a simplification of intro text
... second is related to registration. Concern that the registration is done "with" the user agent as opposed to "through"

laurent_: do we need to reference the @@ from the IG work as they are not referred to in the charter
... we should link to the IG use cases doc or remove

<ShaneM> +1 about "through" the user agent. That makes more sense to me.

<manu> AdrianHB: I want to agree with Shane, we shouldn't say "with the user agent" - we should say "through the user agent"

<DJackson> +1

<manu> +1

manu: any objections to changing to through the user agent?
... (notes no objections)
... lots of simplification in this section (2.2)
... (reads flow)

<manu> AdrianHB: There was a bit of discussion around the flow - mentioned on the mailing list - catching up after being away for 2 weeks - that section it seems like we've narrowed ourselves down to a flow where the payee can initiate a push payment immediately as soon as they get a request from the payer. If the payer has a push payment, the payer may just make the payment.

<manu> AdrianHB: If the payer wants to defer the payment - the payer doesn't execute the payment - they return a response to say they want to use the 'push payment method' - that was the major change. Previous flow was always a response back first - we had language around payment completion - notifying the payer - a lot of people didn't like we didn't like the word "completion" - payment execution happening in what we were describing.

<manu> AdrianHB: There was a flow that was the same whether push vs. pull - now we have a flow that can change slightly - we have a good compromise here - accomodating of UX concerns from folks like browser vendors - a lot of back and forth could be bad for user experience.

vincentK: in ISO20022 model the starting point is an obligation and the flow follows from that
... the neg of terms is linked to this too
... so there are elements that are still missing in the charter
... compared to ISO20022 the whole flow is not defined

manu: yes, this is by design. You should still be able to execute the whole flow but only the elements of the flow that we can define technical standards for are in scope. i.e. the flow we define is a subset of the complete flow
... there is a new section on deferred payment execution which allows some flexibility on the flow

do you (vincentk) feel that we are not going to be able to implement the ISO20022 flows?

vincent: there are some links that are missing between the elements?

manu: do you have some suggested changes that would correct this?

kkettels: perhaps it is unclear what the purpose of the charter is in relation to what the WG will do?

manu: the charter is not intended to explain the WG work in detail. the WG will look at these and make decisions about how to acheive the capabilities in the charter. W3C charters are seldom prescriptive but rather set boundaries
... if the WG wants to map the flow to ISO20022 then that will be done within the group

vincent: suppose the charter does not mention a capability and we decide that there is one required what happens?

shepazu: the charter is there to set the scope. to both define what the WG should and shouldn't work on.
... there is a some wiggle room if the WG agrees that to achieve one of their goals some new scope is required
... if the WG doesn't agree then you need to recharter

manu: item 10 on the list. deferred payment execution
... any concerns?
... next is digital wallets
... definition has been shortened
... (reads definition)
... other change is that the WG may define an API that may be used outside a user agent

shepazu: all the things mentioned are user agents so perhaps this langauge needs to change

manu: agree, will raise the change
... we have been clear about what is out of scope wrt wallets
... any concerns?
... moving on to security and privacy
... (section 2.4)
... minor changes
... into section 3.1. minor changes. have explicitly called out that the messages we are standardising could be used in server to server comms
... concerns?
... 3.2 is a lot of simplification but again nothing controversial

shanem: (reads back end of section 3.2) suggest that this should refer to "user agents" (plural)

manu: will add to changes
... deliverables, stating that we would like to see specs that have already had some form of review as a starting point. Usually this means going through the community groups
... also changes for interoperability success criteria. sets a high bar
... a number of things must be achieved to consider the work a success
... (reads through reqs)

<Zakim> ShaneM, you wanted to ask about native implementation

shanem: when you say native do you mean native code on the device or must it be build into the platform from the platform vendor

shepazu: by native, we mean something other than interpreted javascript within the browser

manu: the language is getting around this being acheived only through polyfills.
... thats the top of the hour

shepazu: we could consider any number of apps as native. the credibility of the app is also considered. The deployment numbers of the implementation is important

dezell: do we need to continue this discussion on Monday

manu: 1 item left, will take a few minutes

dezell: do we need time for agenda development for the IG on Monday

shepazu: yes lets set some time aside

manu: please all note that the licensing has changed in section 9. we are using the very permissive W3C licensing. Be aware that the WG deliverables will be under a very permissive license

<ShaneM> its very similar to the X Window System license.

manu: any strong objections to the changes covered today?

<manu> PROPOSAL: Suggest that the new Web Payments WG Charter with the changes discussed today be sent to the Web Payments IG for approval.

<Laurent_> +1

<manu> +1

<DJackson> +1

+1

<dezell> +1

<manu> RESOLVED: Suggest that the new Web Payments WG Charter with the changes discussed today be sent to the Web Payments IG for approval.

<kketels> +1

<manu> Changes suggested by the group:

<manu> 1. Remove last 'standardize'

<manu> 2. Link payment phases to IG use cases document for context

<manu> 3.Change "with the user agent" to "through the user agent"

<manu> 4. Make disctinction between a user agent and a service - Relation to  Digital Wallets

<manu> 5. "mobile device's user agent." -> "user agents"

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.140 (CVS log)
$Date: 2015/10/08 15:08:06 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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)

Found Scribe: AdrianHB
Inferring ScribeNick: AdrianHB
Present: CyrilV ShaneM Manu Laurent_ Vincent Kuntz AdrianHB DJackson Stephanie dezell (briefly)
Agenda: https://lists.w3.org/Archives/Public/public-webpayments-ig/2015Oct/0030.html

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Got date from IRC log name: 08 Oct 2015
Guessing minutes URL: http://www.w3.org/2015/10/08-wpay-minutes.html
People with action items: 

[End of scribe.perl diagnostic output]