Re: comments on the charter

On 13 July 2015 at 14:23, Joseph Potvin <jpotvin@opman.ca> wrote:

> RE: "Even in a system that requires a payment to be executed from the
> payment processor there needs to be an initial exchange between payer and
> payee to select instrument and confirm terms."
>
> Yes, that's done in the Invoice's specification of the terms of payment.
>

Yes, in our proposed flow the payment initiation request lists the terms
and supported instruments. In the response to this the payee has selected a
payment instrument to use and is confirming the terms.


>
> The Invoice then emits a message:
>

How does an invoice emit a message?
Firstly, we are not defining an invoice in our standard at all, simply two
request response message pairs for initiation and completion.
Second, an invoice is a document not a system so I'm not sure I understand
how it can "emit a message".


> * to the payer's depository (aka "wallet") in the case of a token-based
> architecture, which sends info to the payment system; or,
>

In the case of a token based system the payment initiation response from
the wallet includes the necessary info (token) for the payment system to
execute the payment.


> * to the payment system in the case of registry-based architecture, which
> settles amongst depositories.
>

In the case of a scheme where the payment is executed by the payer
(credit-push) this will be done by the wallet system upon receipt of the
payment completion request. Either the wallet system will be capable of
doing this directly (like a Bitcoin wallet) or it may call out to a 3rd
party service it uses for execution of payments in the specific scheme that
has been selected.


>
> Joseph Potvin
> Operations Manager | Gestionnaire des opérations
> The Opman Company | La compagnie Opman
> jpotvin@opman.ca
> Mobile: 819-593-5983
>
> On Mon, Jul 13, 2015 at 5:11 PM, Adrian Hope-Bailie <adrian@hopebailie.com
> > wrote:
>
>> Hi Joseph,
>>
>> We are defining a flow of messages that will hold scheme specific data in
>> them as required irrespective of the type of system.
>>
>> In this flow the differentiation lies in who "executes" the payment and
>> this sits either with the wallet (triggered by receipt of the completion
>> request) or payment processor (triggered by receipt of the initiation
>> response).
>>
>> i.e. The same high-level flow could be used to handle both types of
>> system because it consists of two request/response pairs.
>>
>> Even in a system that requires a payment to be executed from the payment
>> processor there needs to be an initial exchange between payer and payee to
>> select instrument and confirm terms.
>>
>> Adrian
>>
>> On 13 July 2015 at 13:47, Joseph Potvin <jpotvin@opman.ca> wrote:
>>
>>> RE: I have attached a swim-lane flow diagram to try and illustrate the
>>> payment flow, does this work?
>>>
>>> Adrian, Your attached diagram has the flow going to the depository (aka
>>> "wallet") first. That's suited to token-based systems. In registry-based
>>> systems, the flow goes to the payments processor first, which then
>>> validates and settles amongst the relevant depositories.
>>>
>>> The token-based and registry-based instantiations are distinguished at
>>> the level of UNCITRAL's WG IV (e-Commerce).
>>>
>>> Joseph Potvin
>>> Operations Manager | Gestionnaire des opérations
>>> The Opman Company | La compagnie Opman
>>> jpotvin@opman.ca
>>> Mobile: 819-593-5983
>>>
>>> On Mon, Jul 13, 2015 at 4:30 PM, Adrian Hope-Bailie <
>>> adrian@hopebailie.com> wrote:
>>>
>>>>
>>>>
>>>> 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.
>>>>>
>>>>>
>>>>
>>>
>>
>