Re: comments on the charter

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.
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>