Re: comments on the charter

On 13 July 2015 at 01:54, <Joerg.Heuer@telekom.de> wrote:

> Hello Dave, all,
>
> Great work, Adrian. Actually I have more comments on other's people
> comments than on your original texts... ;-)
> Sorry for obviously being late. I had the 14th as a deadline on the top of
> my head...
>
> Trying to add my view to Dave's review.
>
> See below:
>
> Cheers,
>         Jörg
>
> -----Original Message-----
> From: David Ezell [mailto:David_E3@VERIFONE.com]
> Sent: Sonntag, 12. Juli 2015 21:15
> To: public-webpayments-ig@w3.org
> Subject: comments on the charter
>
> 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.
>
> "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
>
> 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.
> JH> Even if we can address just a fraction of the abandoned transactions,
> it's the one effect that most directly translates into dollars - and fits
> people's current understanding. So, while Dave's comment is absolutely
> right, I wouldn't change the text though.
>

+1


>
> JH> I'd add 'transparency and confidence in digital payment' to the
> 'customer satisfaction' sentence. While satisfaction is nice, it's very
> generic, Raising people's confidence and feeling of security, privacy,
> trust, etc. promises to have much more of a practical effect to attract
> more customers.
>
>
Added: "Improved transparency and confidence in digital payments for
consumers as a result of increased choice and
    standardised flows and experiences."


> * 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."
>
> * Suggest changing "on topics such as security" -> "covering topics such
> as security"
>
> 2. Scope
> ------------
> * Change "on it's way to the payment processor" 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."
> JH> I'd like to take an even more user-focused view and add "leading the
> user through entirely different flows and verification routines" before
> talking about "high-level processes", "interfaces" and such.
>

Added: "The result is that users
are lead through entirely different flows and verification routines every
time they make a payment on the
Web."


>
> * 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.
>
> * 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).
>
> * 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.
>
> * 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."
>
> 2.1 Payment Flow
> ------------------------
> * Is "credit push" really the dual of "debit pull?"  I haven't heard the
> latter term that much.
>
> 2.2 Security and Privacy Considerations
> -----------------------------------------------------
> * Suggest "...critical in payments and while the initial..." to
> "...critical in payments.  While the initial..."
>
> * 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..."
>
> * Suggested change: "...payment process defined by the group should not
> disclose..." to "...payment process
>    defined by the group should not require disclosure of..."
>
> * Suggested change "participants identity" to "participants' identity".
>
> * Suggested change "...without their explicit consent and the design..."
> to "...without their explicit consent.  The
>    design..."
>
> * I'm not sure the final clause "... , or that can be used across payment
> schemes." actually adds value.
> JH> if I got the meaning right, I'd propose to say "...or that can be
> unified across payment schemes."
>

I have dropped this per David's suggestion as I'd expect there to always be
a single scheme but in the future there may be a scheme that is open (as
opposed to defined by a closed group like VISA or PayPal) and unifies or
connects closed schemes.

Happy to revise again if others feel this is still missing the point.


>
> JH> I'd propose to add a hint to hardware security capabilities of
> devices, especially since we have a TF for this. Proposal to add after the
> first paragraph: " The specifications put forwards will take into account
> hardware capabilities found on devices to raise security beyond what pure
> software solutions can provide. In particular hardware to securely generate
> and store secrets for secure transactions and hardware to verify a user's
> authenticity via biometry or other mechanisms, will be considered."
>

We want to leave a lot of this up to the payment schemes and wallet
services (they will interface with the hardware devices) but I agree that
it's worth including to ensure the group is considering these things and
where they might fit in.

I have added a paragraph similar to yours into the security section.


>
> 3. Wallets
> ---------------
> * What are "stand alone applications"?  I think this means "native
> application".
> JH> As a wallet could be another web app, perhaps running on the same
> device, a sandbox or a server in the net, I thought the term 'standalone
> application' fitted pretty well, actually.
>

I have changed it to stand-alone Web or native applications and tweaked
that sentence a little.

>
> JH> I propose to add another bullet saying: "It may also serve as a
> concept to allow enrichments of payment - and other transaction -
> experiences through the addition of business logic for loyalty, coupons,
> login, ticketing, and others." In exchange, the next paragraph could be
> shortened a bit, e.g. dropping the first sentence entirely. The background
> for this proposal is: people tend to take bullets as central elements of
> what's being said, dropping all the rest. Since people have so many
> different views of what wallets are and could be, keeping a sentence like
> this in the bullet list might help a lot.
>

This is a good point (ito what is perceived by the style of the text). I
have added a bullet and emphasized that this is a function we are not
standardizing in this charter.


>
> * Suggested change: "Some of the functionality..." to "Some of the
> capabilities..."


> * Suggest change: "can be useful" to "is useful".
>
> * 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."
>
> * Suggest change: "...holds..." to  "...holds and allows access to..."
>
> * Suggest change: "...supports certain payment schemes..." to "...provides
> logic to support use of instruments in
>    specific payment schemes..."
>
> * 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."
>
> * 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.
>
> * Suggest change: "... or by other aggregating services available to the
> user." to "...or by other services available
>    to the user."
>
> * Suggest change: " ... look for standardization opportunities..." to
> "...look for opportunities to standardize..."
>
> 4.1 Recommendndation-track deliverables
> ---------------------------------------------------------
> * Suggest change: "Payment Term Description" to "Payment Terms Description"
>
> * Repeated question: is "debit-pull" a standard term?  It's just not
> familiar to me, and seems easy to confuse
>    with "debit".
>
> * Suggest dropping "EMVCo" from tokenization.  Just plain tokenization
> should be investigated, including EMVCo.
> JH> Comment on Dave's comment. Stating an example might still be helpful
> as 'tokens' and, thus, 'tokenization' are frequently used in other contexts
> and might lead to misunderstands if people are not too familiar with
> payment technologies and its most recent developments.
>

I have left this in because this is a reference specifically to the EMVCo
standard which is the proposed way (by the card associations - EMVCo) to do
more secure card payments online.

Important point to note for the group, and especially anyone with
connections to these organisations, that we should be trying to get all of
the major card associations (and wallet vendors - lots of overlap here)
involved in this work.


>
> 5.1 W3C Groups
> ----------------------
> * Suggest adding at least one WAI group to this list.
>
> 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.
>
> * 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."
>
>
>
>
> ________________________________
> 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.
>
>
>

Received on Monday, 13 July 2015 21:06:06 UTC