Dezell - confirm agenda

scribe: finalize WG Charter

Confirm Agenda

dezell - main agenda item is proposed re-working of charter

<dezell> https://lists.w3.org/Archives/Public/public-webpayments-ig/2015Sep/0101.html

scribe: Ian sent an e-mail to help the walk-through

dezell - any prelim comments on charter?

scribe: basic thoughts: much effort done by Ian in trying to close the gaps.
... great comments from people whcih we need to include

<Zakim> AdrianHB, you wanted to make some over-arching comments on a) the flow b) the digital wallet and discovery. Will wait for Ian

Adrian: Made comments on last call. Got some actions, not sure to proceed on
... 1st is regarding the flow.

<Ian> EDITOR'S DRAFT -> http://w3c.github.io/webpayments-ig/latest/charters/payments-wg-charter.html

Adrian: proposed flow in new charter is different from previous one.

<Ian> AC REVIEW CHARTER -> http://www.w3.org/2015/06/payments-wg-charter.html

Adrian: previous was a request from payee to payer with response
... response confirmed selection of payment instrument
... following that, wording on execution of the payment (concerns whether that was in scope for the WG)
... we need to look into that wording

<Ian> Problematic language in AC charter was "Execution of the payment by either payer or payee."

<Ian> (under 2.2 Payment Flow)

Adrian: flow was negotiation and the execution and confirmation
... next step was a response "please do the payment"
... with a pull payment, the payee will initiate the request, with a notification following
... in the new charter, the flow is different

<nick> nick s

Adrian: which is limiting to what payers and payees may do after the initiation
... made these comments against the proposal of Google
... may need to repeat these on the mailing list

Zkoch: states that new proposal does not preclude specific flows

<Ian> Zach: we are optimizing for checkout flow

Zkoch: majority transactions will return a blob of data to the merchant which need processing\
... lyalty can be included in the transactions with exchanging further details such as identity
... optimizing user experience and APIs was the goal of the proposal
... now not standardizing loyalty, coupons, etc
... welcomes further input in the incubation community group, where it is posted

<Zakim> AdrianHB, you wanted to respond

Adrian: does not agree
... streamlining of the flow is outside of the UI
... negitiation is outside the UI
... after user selecting payment instrument, a response should be available
... majority of the world prefers push payments, at least in Western Europe
... in push scenario, the payment will be executed before the merchant could do anything

Ian: wonders whether this is a miscommunication or something more deep
... Does not see how the overall protocol was affected by the change in the flow described
... the second part of the dialogue is not dropped from the Charter
... payment completion response can be handled by the payment scheme itself too
... payment schemes managing completion responses may be an item too discuss

zkoch: does not think the proposed text changes should change how things will work.
... numerous discussions with merchants: keep things as less complicated as possible
... single request-response is the simplest

Ian: by removing the sentence on execution, he did not expect that this changed the transaction process

Adrian: (having some IRC issues)
... it is not simply the removal of the sentence
... deliverables of the API - initation and completion request
... with a push based scheme, the payee has to ask the payer to complete the payment

<Ian> Adrian: What was dropped was the "completion request"

Adrian: with card payments, it is just a notification rather than a completion request

<Ian> OLD text: "The payee passes a payment completion request to a payer digital wallet service which returns the details of the payment completion response. If the payment was payer-initiated, this is the trigger for the digital wallet service to execute the payment; otherwise this is a message advising of the result of a payee initiated payment. "

<zkoch> But can’t this be handled by the payment instrument? I still don’t quite understand the need for the extra call

<Ian> NEW text: "After a payer has selected their chosen payment instrument, the payment instrument sends back data necessary that allows a merchant to finalize a transaction or, scheme permitting, proof of an already executed payment. "

Adrian: current charter changes the flow in Adrian's opinion - for push payment instruments
... there needs to be an initation\
... than logic splits between payer or payee initiated transactions

<zkoch> +1

Ian: requests that Zach and Adrian work on this together

<nick> +1, I do think saying it’s “already executed” precludes push payments that won’t complete until the future

Ian: as an editor, I did not perceive to change the protocol
... can Zach an Adrian hammer this out?

Adrian: OK

<Ian> ACTION: Adrian to work with Zach on payment completion language for charter [recorded in http://www.w3.org/2015/09/21-wpay-minutes.html#action01]

<trackbot> Created ACTION-159 - Work with zach on payment completion language for charter [on Adrian Hope-Bailie - due 2015-09-28].

<AdrianHB_> AdrianHB_ is AdrianHB

On wallets

Adrian: second remark is on multiple wallets
... some semantics of what "wallet" actually encompasses
... we need to put a name on the entity who does the "discovery"

<Ian> Adrian: Role of wallet is "discovery"

Adrian: takes the lists of available instruments and facilitates the choice of the instrument

<Ian> ...matches the "intents" pattern

<Ian> ll

Adrian: a pattern well known in the mobile world
... knowledge of installed payment instruments the user has and matches this to those of the payee
... at the moment we have given this the name "digital wallet"
... where does it sit? browser, server, separate process, ...

shepazu (Doug): a digital wallet can mean different things, this is one definition

<Ian> -1 to removing wallet

scribe: we mean it as one specific thing, and should remove the broader term (digital wallet)

<Zakim> Ian, you wanted to ask if we should say more explicitly that in this charter wallet primary role is discovery

scribe: use a more precise, simpler term

Ian: wonders whether clarifying the role we expect from the wallet
... wallet primarily the means of discovery
... how we communicate with whoever handles the authentication
... the wallet or the payment instrument
... possibly via the wallet (flexible)
... leave that to the eco system
... pass the token

<AdrianHB__> +1 for that is out of band of our flow unless the scheme defines a way to pass it inside the messages that are part of the flow (i.e. auth is "directly" between instrument and auth service)

Ian: is there a concrete proposal? The charter should be clear about the role of "that thing"

Dezell: supports the discovery role of the wallet. Agnostic of the term "wallet"

<Ian> (I suggest we use "wallet" and only clarify what needs to be clarified in the charter.)

<Zakim> padler, you wanted to remind folks of payment agent term and why we moved away from wallet initially..

Padler: various back and forth on use of the term wallet vs "payment agent"
... wallet came back into the scope with 1st phase of WG
... being less abstract than "payment agent"
... payment agent focuses on both ends of the payment transactions
... in some cases it may be a wallet

<dezell> +1 to making the selection of term secondary to getting the definition right.

Padler: more in the interface definition
... "wallet" is not relevant for each and every case

<Ian> -1 to reopening the discussion

Padler: so prefers a more generic term

<Zakim> dbaron, you wanted to reply to Ian

Dbaron: concern about "wallet" as an implementor
... seems to be a separate piece of software
... which we do not see how to implement
... such as plug-ins or other pieces of software

<AdrianHB> "digital wallet" needs to be able to do discovery which means it MUST have knowledge of available payer payment instruments.

Dbaron: the roles the charter talks about must be part of a user agent

<AdrianHB> That is a limitation on what CAN be a wallet (taking privacy etc into account)

Dbaron: hard to understand to what other people see the wallet being

Ian: not intended to preclude how the browser would fulfil its role
... why is this unsaperable from a user agent?

Zkoch: user agent handles discovery
... efg appley pay is the wallet

and the cards inside are the payment isntruments

<padler> the key rationale for the term "payment agent" before was that it did not force a specific implementation... in other words it could be implemented as a part of the browser or user agent, but it could also be implemented in non-browser scenarios such as either native apps or back end server software..

<Ian> Zach: Key is for wallets to say back to user agent what payment instruments they support; I think a lot needs to be handled by the user agent itself (e.g., computation of intersection)

scribe: intersection of instruments requested and supported should be handled by the payment agent itself

rbarnes (Richard Barnes, Mozilla) - as an implementor

scribe: building an API for user agents needs to know what roles a user agent will play

<collier-matthew> tt

scribe: a wallet may introduce levels of redirection which we do not need
... layers before getting to the actual payment instrument

<zkoch> +1, I’m also okay with that :)

<rbarnes> zkoch: \o/

Ian: delicate balance between an open architecture and bumping into business models
... architecture should allow for variety of models
... be clear on browser role vs. wallet functionality
... enable a flourishing market of solutions
... browser can eg sotre credentials

s/store.store/

dezell: a browser may implement anything for the discovery process

<Ian> Ian: My point to Richard was mostly that I am concerned about an architecture that forces too much functionality into the browser

<rbarnes> btw, the ApplePay analogy that zach brought up prey well aligns with what i was thinking -- except we also need a web API for how cards get into the wallet

dezell: we seem to be very restrictive in what the WG is going to talk about
... give enough leeway

Adrian: agrees with Ian that not too many things have to be in the browser

<Ian> I think these things *Can* be in the browser (and that might even be very useful)

<Ian> ...I won't want the architecture to over constrain how the system works, however.

Adrian: than all browsers must be aware of all payment instruments the users hold
... and keep up to date with developments in that area
... wallet vendors are specialized in these developments
... intention was that the browser is simply a proxy, which as an option can build this in
... and what to do with a user holding multiple wallets
... eg paypal and apple
... the paypal wallet cannot just be seen as a payment instrument
... we may re-word the wallet as the "discovery agent" if necessary

<CyrilV> +1

<Ian> Adrian: Don't want to force things to be part of the browser

Nick: significant objections when payment instruments must be registered in the browser
... some need specific hardware, for instance
... and it would complciate the charter
... when api's must support lifecycle management
... such as postponing an instrument

<Ian> Nick: Don't want to enshrined "centralized wallet in the browser" in the charter

Richard: there will be special cases with "out of band" payment instruments which must be supported
... you start with a non-configured pristine browser and configure that to process payments

<Ian> Richard: I hear agreement browser provides discovery service

<zkoch> I feel as though we could still handle the case of platform-dependent payment instruments given the text of the current charter

Richard: browser need to lknow about instruments supported then
... using a reigstration api

Ian: hears re-iterated Dbarons suggestion that the charter should allow some of these functions be executed by the browser
... goals: browser make clear that the user agent fulfils some of these roles
... 2) user agent is NOT the only way to support these roles

<zkoch> +1

<dezell> +1 to Ian's proposal

<Laurent_> +1

Ian: are david/richard OK with that path forward?

<dbaron> I'm not sure I got the wording

<AdrianHB> +1 (this was always our view, perhaps not well articulated in the charter)

<CyrilV> +1

<Zakim> AdrianHB, you wanted to say I think the sticking point here is how does the browser integrate with the "discovery agent"

Ian: for that what we call a wallet, be clear in the charter that the browser may perform those roles, but other parties can perform those roles as well

Adrian: browser api may receive these messages, but disagreement on what happens after the browser receives the payment initiation message
... than the discovery process must be clear where that happens
... how does this message get from the browser to that component (when not built in the browser)?
... challenge to decide on how much be described now or in the recommendations of the Working Group
... similar to what is happening in the web notifications api recommendation
... "call the platform API"
... Wonders where we need to draw a line in being fully prescriptive
... keeping user's choice and an opportunity for implementors of payments, wallets and instruments

richard: seems like the product of this group will be API's
... must expose new capabilities on the web
... what are these new capabilities?
... be helpful to clarify what role the user agent takes in those capabilities
... not every user agent has to play all of those roles
... but define an overall set of payment actions the browser must facilitate

dezell: asks Ian if all we need was discussed

Ian: this goes a bit beyond a clarification on the roles the browser should perform
... what people can work together on concrete language on how to achieve that?

<nick> can we maybe see proposed amends from mozilla to the charter to better understand the ask?

<rbarnes> honestly, polyfills are great, but the point of a spec is to define platform APIs.

Ian: does not want to make the charter too much browser centric
... could work with richard and david on some more concrete text
... that is OK
... with richard

<Ian> ACTION: Ian to work with Richard on concrete language to elucidate potential browser roles in the charter. [recorded in http://www.w3.org/2015/09/21-wpay-minutes.html#action02]

<trackbot> Created ACTION-160 - Work with richard on concrete language to elucidate potential browser roles in the charter. [on Ian Jacobs - due 2015-09-28].

<collier-matthew> +1

<Ian> https://lists.w3.org/Archives/Public/public-webpayments-ig/2015Sep/0101.html

<Ian> I have been incorporating feedback into the editor’s draft of the charter:

<Ian> http://w3c.github.io/webpayments-ig/latest/charters/payments-wg-charter.html

ian: the work is supported by the community overwhelmingly
... edits been made, a few are not quite resolved yet

<shepazu> (fyi, overwhemling response: http://www.w3.org/2014/dashboard/ac-reviews.html )

<Ian> IJ: Note incorporation of Software and Doc license in updated editor's draft

Ian: some organisations now prefer that work be socialized in a more light weight fashioo before WG take up the work

<Ian> ====

<Ian> "The Working Group will actively seek to base its deliverables on specifications that have been socialized in Community Groups

<Ian> or contributed as Member Submissions. When no relevant specifications are available, the Working Group may proceed to develop

<Ian> its own Working Drafts."

<Ian> ====

<rbarnes> do we happen to have any use cases written down?

<Ian> http://www.w3.org/TR/web-payments-use-cases/

<rbarnes> ian: great, thanks

<rbarnes> (sorry, didn't mean to interrupt the flow)

Ian: second issue has to do with implementation experience

<Ian> (On implementation)

Ian: questions on polyfill usage

<Ian> <new2>

<Ian> The Working Group will fulfill the <a href="http://www.w3.org/2015/Process-20150901/#implementation-experience”>implementation

<Ian> experience required by the W3C Process</a> as follows:

<Ian> * The Working Group will develop test suites for Recommendation-track specifications.

<Ian> * The group will seek independent interoperable implementations by two user agents and two services that enable payers to use digital payment instruments.

<Ian> * One of the user agent implementations must be native (that is, part of the distributed user agent code).

<Ian> * For any non-native implementation, we will ask user agent developers to attest to the suitability and traction of the proposal.

<Ian> * For any native implementation, the Working Group will work with the WAI Protocols and Formats Working Group (or its successor) to help

<Ian> communicate accessibility issues to the user agent developers.

<Ian> </new2>

Ian: 3rd: issue on accessability
... we not do interface work ourselves but should ensure accessability
... not written as a "blocker"
... inclined to include these texts in the charter

Adrian: Does polyfill need specific wording? ("implement this as polyfill when possible")

Ian: does not see how this wording would be a problem for polyfill

Adrian: so the answer is No.

<Ian> ACTION: Ian to check with the reviewer for more information about request to remove card payments spec [recorded in http://www.w3.org/2015/09/21-wpay-minutes.html#action03]

<trackbot> Created ACTION-161 - Check with the reviewer for more information about request to remove card payments spec [on Ian Jacobs - due 2015-09-28].

<Ian> trackball, close action 153

<AdrianHB__> trackbot, close action 153

<trackbot> Sorry, AdrianHB__, I don't understand 'trackbot, close action 153'. Please refer to <http://www.w3.org/2005/06/tracker/irc> for help.

<AdrianHB__> close ACTION-153

Ian: AOB?

<trackbot> Closed ACTION-153.

Ian: next meeting is 10 AM thursday

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)

Succeeded: s/Preset+ Nick//
Succeeded: s/+present Vincent Kuntz//
FAILED: s/sotre.store//
Succeeded: s/sotre/store/
Succeeded: s/tt//
Succeeded: s/wording/path forward/
Succeeded: s/asnwer/answer/
No ScribeNick specified.  Guessing ScribeNick: evert
Inferring Scribes: evert
Present: dbaron hober AdrianHB Jurgen Spaanderman Zach Erik Evert David Ezell CyrilV MattC Linda Toth rbarnes Jiangtao Ian Nick Shearer padler yaso Vincent Kuntz
Regrets: Manu JHeuer
Agenda: https://lists.w3.org/Archives/Public/public-webpayments-ig/2015Sep/0102.html
Got date from IRC log name: 21 Sep 2015
Guessing minutes URL: http://www.w3.org/2015/09/21-wpay-minutes.html
People with action items: adrian ian