See also: IRC log
<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
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"
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]