Re: comments on the charter

You'll have to explain the difference then because we are clearly missing
each other.

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

> I think you've not accommodated the functional differences between digital
> token-based and digital registry-based systems.  Rather you seem to be
> reframing digital registry systems from a digital token perspective.
>
>
> 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 7:03 PM, Adrian Hope-Bailie <adrian@hopebailie.com
> > wrote:
>
>>
>>
>> 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.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>