- From: Adrian Hope-Bailie <adrian@hopebailie.com>
- Date: Mon, 13 Jul 2015 13:30:19 -0700
- To: David Ezell <David_E3@verifone.com>
- Cc: "public-webpayments-ig@w3.org" <public-webpayments-ig@w3.org>
- Message-ID: <CA+eFz_LvPWaOp8niaCQsTfx+wdTKeXPD6fv7NGs-gdBPb+bEpQ@mail.gmail.com>
On 12 July 2015 at 12:14, David Ezell <David_E3@verifone.com> wrote: > Dear Web Payments IG members: > > My apologies (especially to Adrian) for being late with this submission. > > Here are my comments on the charter on behalf of NACS. > The document I'm commenting on is here: > > http://w3c.github.io/webpayments-ig/latest/charters/payments-wg-charter.html > > Best regards, > David > > <snip/> > > General comments > -------------------------- > * Great job Adrian. > * We should choose either UK (standarise) or US (standardize) spellings. > Sorry, my natural tendency is for en-gb but I think W3C standard is en-us so will update where I find incorrect spellings. > > "Note" at the top > ------------------------- > Can we call the glossary something other than "Web Payments Interest > Group's Glossary" and adopt a common glossary? > > Suggestion: call it "Unified Web Payments Activity Glossary" > > https://lists.w3.org/Archives/Public/public-webpayments-ig/2015Jul/0063.html Will integrate the new unified glossary as discussed. > > > 1. Goals > ----------- > * Shopping cart abandonment is a controversial benefit. A large portion > of mobile abandonment is simply > price checking - a behavior not likely to stop. I'm just not convinced > it belongs in the very first goal. > I agree that cart abandonment won't go away but I'd expect it to still significantly decrease right? The wording is "reduce" not "eliminate" or "eradicate" so I'd suggest we leave it as is. > > * Need a more "merchant focused" goal, always customer service or saving > money - e.g. > "Standardized interfaces will reduce merchant costs through faster > adoption, easier certification, and improved > choice of provider." > I see the major benefit to merchants being a more competitive landscape for provision of payment instruments because a standard makes it easier for merchants to accept many new instruments. More competition naturally means lower costs. Need to give some thought about how to express this as I think the direct benefit is not obvious and may need to be explained in detail. > > * Suggest changing "on topics such as security" -> "covering topics such > as security" > +1 will change to "covering topics such as security" > > 2. Scope > ------------ > * Change "on it's way to the payment processor" to "on its way to the > payment processor." > + 1 will change to "on its way to the payment processor" > > * Suggest a slight edit, from > "Unfortunately, these efforts all suffer from a lack of standardization > of the high level flow of a Web payment, > of the interfaces between the various parties, the user agent and the > Web application, or of the messages > exchanged between these parties over the Web." > to > "Unfortunately, these efforts all suffer from a lack of > standardization: standardization of the high level flow of a > Web payment, of the interfaces between the various parties, of the > user agent and the Web application, and of > the messages exchanged between these parties over the Web." > + 1 that sentence is too long and cumbersome. Will revise. > > * What does "Web Context" mean? I don't think we're creating things > inside and outside the web context, are > we? We need a way to describe normal Web Server functionality (HTML, > etc.) and Web Services. > We are not creating things inside and outside the Web context. We are defining the interfaces between the Web context and other contexts. i.e. The WebIDL API is an interface between the Web context (applications on the Web) and whatever service the browser proxys those API calls to (example: a native wallet). Any suggestions from the group on how to re-word that sentence? > > * This sentence is hard for me to parse easily: "The interfaces between > the payment schemes and the Web are > via the user agent and the Web application, therefore the scope of the > initial charter is focused on the > interactions between these two components and the external actors that > will interface directly with them." > I think I understand what it's trying to say - I think "Web" in the > first clause is really "Web context" (see note > above). > I changed this from Web context to Web at Manu's request. I think either work but I also think a diagram here will be worth a thousand words. I have attached a swim-lane flow diagram to try and illustrate the payment flow, does this work? > > * At "a message flow for the initiation..." the punctuation seems to be > missing between "initiation" and > "confirmation" - a small dot (might be a period) appears in my browser. > Should be a comma, fixed. > > * Suggest rewording this sentence: "The group will aim to standarise..." to > "To support use cases where messages are proxied between payer and > payee, the group will aim to use > technologies such as WebIDL APIs and Web Services in the classic REST > pattern. Such use will support > varied implementations such as via a Web Browser, or between two > agents using APIs." > Not sure if that is exactly what I was going for but I agree that the sentence could use some tweaking. Will review and try to find something along the lines of your suggestion. > 2.1 Payment Flow > ------------------------ > * Is "credit push" really the dual of "debit pull?" I haven't heard the > latter term that much. > That's my understanding. Credit push = A credit to the payee pushed by the payer. Debit pull = A debit of the payer pulled by the payee. > > 2.2 Security and Privacy Considerations > ----------------------------------------------------- > * Suggest "...critical in payments and while the initial..." to > "...critical in payments. While the initial..." > + 1 changed as suggested > > * Suggested change: "...financial impact therefore message integrity and > verification of all message originators..." > to "...financial impact, the ability to prove message integrity and to > verify all message originators..." > +1 changed to "...financial impact. Therefore the ability to prove..." > * Suggested change: "...payment process defined by the group should not > disclose..." to "...payment process > defined by the group should not require disclosure of..." > +1 changed as suggested. > > * Suggested change "participants identity" to "participants' identity". > +1 changed to " details of any participants' identity" > > * Suggested change "...without their explicit consent and the design..." > to "...without their explicit consent. The > design..." > +1 changed as suggested > > * I'm not sure the final clause "... , or that can be used across payment > schemes." actually adds value. > +1 Removed. > > 3. Wallets > --------------- > * What are "stand alone applications"? I think this means "native > application". > +1 changed to "The standards from this group may be implemented in a variety of ways, including within native applications, applications in the cloud, or user agents such as Web browsers." > > * Suggested change: "Some of the functionality..." to "Some of the > capabilities..." > +1 changed as suggested > > * Suggest change: "can be useful" to "is useful". > +1 changed as suggested > > * Suggest change: "... this charter includes a definition to clarify the > intent of this group." to "this charter includes > the following definition to clarify the intent." > +1 changed as suggested > > * Suggest change: "...holds..." to "...holds and allows access to..." > +1 changed as suggested > > * Suggest change: "...supports certain payment schemes..." to "...provides > logic to support use of instruments in > specific payment schemes..." > +1 changed to add "provides logic". The latter part of the sentence talks about instruments and there relation to schemes so it felt redundant to mention them twice. > > * Suggest change: "...may hold one or more balances of some digital asset > that can be used to make payments." > to "may hold digital assets, in the form of account balances, that can > be used to make payments." > > +1 changed as suggested > * In the phrase "...any conforming Web application running in a conforming > user agent..." I'm not sure why > "Web" is in there. It begs the question "what is a web application" and > I think we avoid that by just saying > Application. > +1 dropped "Web" > > * Suggest change: "... or by other aggregating services available to the > user." to "...or by other services available > to the user." > +1 changed as suggested > > * Suggest change: " ... look for standardization opportunities..." to > "...look for opportunities to standardize..." > +1 changed as suggested > > 4.1 Recommendndation-track deliverables > --------------------------------------------------------- > * Suggest change: "Payment Term Description" to "Payment Terms Description" > +1 changed as suggested > > * Repeated question: is "debit-pull" a standard term? It's just not > familiar to me, and seems easy to confuse > with "debit". > I have always understood it to be. Do we need it in the glossary? > > * Suggest dropping "EMVCo" from tokenization. Just plain tokenization > should be investigated, including EMVCo. > This is specifically referring to the EVMCo tokenisation standard so I have left it in there. Are there other tokenisation standards we should be considering? I'm not aware of any. > > 5.1 W3C Groups > ---------------------- > * Suggest adding at least one WAI group to this list. > Ian said that there is a list of W3C groups that are part of all charters (like WAI) and these will be added. > > 6. Participation > -------------------- > * Suggest making the second sentence "Effective participation in Web > Payments WG may consume .1FTE for each > participant: for editors this commitment may be higher." I'm not > exactly sure what was intended here. > Not sure either. This is boiler-plate stuff that Ian added and there is probably a lost placeholder there. > > * Suggest giving a separate section in section 4 (deliverables) to "The > Web Payments Working Group will allocate also the necessary resources for > building Test Suites for each specification." > > +1 added > > > ________________________________ > This electronic message, including attachments, is intended only for the > use of the individual or company named above or to which it is addressed. > The information contained in this message shall be considered confidential > and proprietary, and may include confidential work product. If you are not > the intended recipient, please be aware that any unauthorized use, > dissemination, distribution or copying of this message is strictly > prohibited. If you have received this email in error, please notify the > sender by replying to this message and deleting this email immediately. > >
Attachments
- image/png attachment: WebPaymentsBasicPaymentFlow.png
Received on Monday, 13 July 2015 20:30:49 UTC