Re: Thanks to all and next steps

RE: "Some participants strongly object to a W3C standard that is dependent
upon an ISO standard."

Is/are the reason(s) documented somewhere?  I'd guess it's the issues of
the W3C's royalty-free licensing commitments versus ISO's RAND policy. Plus
I imagine there's objection to the relatively expensive fees that ISO
charges for access to its docs.

RE:  "This is not to say any standard couldn’t optionally allow for ISO
20022 compliant messages, but there are many concerns around mandating
compliance."

In light of:
http://www.w3.org/2010/04/pasfaq
and
http://www.w3.org/2001/11/StdLiaison#I
...and considering that ISO 20022 is really just
SWIFT-messaging-made-generic, in this case it seems it's the prior reality
of SWIFT itself that makes those messaging specs effectively mandatory
anyways. Besides they are useful towards saving everyone time.

A simple clear statement would do -- there's surely some appropriate
wording to borrow from some other conditional reference in a W3C spec to a
useful ISO standard.

Joseph Potvin
On behalf of DataKinetics http://www.dkl.com/
Operations Manager | Gestionnaire des opérations
The Opman Company | La compagnie Opman
jpotvin@opman.ca
Mobile: 819-593-5983

On Wed, Jun 24, 2015 at 9:53 PM, Nick Shearer <nshearer@apple.com> wrote:

>
> On Jun 24, 2015, at 2:39 PM, Joseph Potvin <jpotvin@opman.ca> wrote:
>
> David,
>
> Thanks for the thoughtful analysis.
>
> Key item:
>
> RE: there is no concept (that I have seen) of an “initiating depository”
> which is the arbiter of what accounts exist, who owns them, and the
> payments instruments available to the parties
>
> Possibly what I meant to say got confused due to my attempt to avoid use
> of the word wallet. A web payment is necessarily (I think) initiated from
> "an e-commerce system" of some sort. Then it has two ways to enter the
> domain of financial services:
> Token-Oriented: It could enter "a payments system" first via a
> wallet/account/depository; or
> Ledger-Oriented: It could enter "a payments system" first via a financial
> services entity which is authorized to interact with both the Payer's and
> Payee's wallets/accounts/depositories to settle.
>
> Other items:
>
> RE: these flaws are requirements which will render the adoption of a
> standard to very low unless by use of regulatory/political force
>
> If useful the W3C Specification on Web Payments could have optional parts,
> as ISO 9001 does. Furthermore, standards in some fields come with "guidance
> on transition periods" (e.g.
> http://www.iso.org/iso/catalogue_detail.htm?csnumber=64129 )
>
>
> RE: assumes that the eCommerce application choses the payment message and
> that discovery of payments supported falls outside the web payments
> standard. For that to be true – we would have to assume that either 1)
> eCommerce is IN the payments standard flow or 2) payment initiation,
> discovery, negotiation of terms is in the eCommerce flow. In the latter
> case, web payments has very little work to accomplish
>
> I recommend #2: Payment initiation, discovery, negotiation of terms is in
> the eCommerce flow, thus web payments has very little work to accomplish.
> Proposed is that: "ISO 20022 messages originate from UBL invoices. Some of
> the components within UBL are: Currency, Payment and Tax, but inside UBL
> these can be thought of in future tense, as Currency "to be used", Payment
> "to be dispatched", and Tax "to be dispatched".
>
> https://www.w3.org/community/webpayments/wiki/A_Quick_Introduction_to_UBL_Oriented_to_Payment_Solutions_Designers#Relationship_with_ISO_20022
>
>
> RE: I was agreeing with Adrian and others that eCommerce is too large a
> concept to pull into a payments flow, lest we rearchitect the entirety of
> the eCommerce flow concurrent with the web payments standard
>
> Agreed.
>
>
> Re: In eCommerce as I see it, the seller has a pre-determined selection of
> payment schemes/instruments that it can support.
>
> Every seller is also a buyer. Organizational buyers often have the market
> presence to pre-determine the set of acceptble schemes/instruments, or else
> the supplier should not bother trying to sell to them.
>
>
> RE: "the assumption here is that the format of a message is chosen BEFORE
> the method of payment is chosen. To me this is a fundamental flaw"
>
> Are you sure? ISO 20022 does not standardize to that degree. "ISO 20022
> standardizes only a message "scheme" without specifying the various message
> types, because messages are transitory and they evolve with the diversity
> of payment systems in operation. For convenience the ISO 20022 community
> maintains a catalogue of message types structured according to the ISO
> 20022 standard. However that catalogue is not intrinsic to the standard."
>
>
> RE: I think you have a scenario linked more firmly to a more forced
> standardization then can work
>
> Possibly, but it seems to me that both of these standards provide much
> more flexibilty than you suggest.
>
>
> RE: "a message would go in ISO20022 to a third party, connect buyer
> preference to seller capability, create another message in the format
> required for the scheme selected, send out and return status in that
> standard to be converted to a return message in ISO20022 format. This flow
> causes two or more data formatting transformations"
>
> What's the alternative if a payment network-of-networks is supposed to
> emerge?
>
>
> RE: the embedded association with the 20022 standard will diminish the
> ability to...
>
> I thought alignment with 20022 was agreed.
>
>
> Some participants strongly object to a W3C standard that is dependent upon
> an ISO standard. This is not to say any standard couldn’t optionally allow
> for ISO 20022 compliant messages, but there are many concerns around
> mandating compliance.
>
>
>
> RE: the dissonance of a specific settlement message which may not have
> used the settlement mechanism assumed at the time of sale
>
> If it didn't get settled by the expected path, wouldn't that signal a
> potential problem?
>
>
> RE: cautious about too deeply specifying exactly how the transaction
> occurred
>
> Agreed.
>
>
> RE: it appears (I may be reading this in error) – that you are assuming
> the contract process is part of the payment
>
> I'm saying it the other way around: the payment process is part of the
> contract.
>
>
> Joseph Potvin
> On behalf of DataKinetics http://www.dkl.com/
> Operations Manager | Gestionnaire des opérations
> The Opman Company | La compagnie Opman
> jpotvin@opman.ca
> Mobile: 819-593-5983
>
> On Wed, Jun 24, 2015 at 12:06 PM, David Jackson <
> david.dj.jackson@oracle.com> wrote:
>
>> Joseph,
>>
>> This might require a bit of interactive discussion. There are flaws I see
>> with your flow – not in that they would not work, but in that these flaws
>> are requirements which will render the adoption of a standard to very low
>> unless by use of regulatory/political force – and not solving the specific
>> issues.
>>
>>
>>
>> The flow you use here is:  “e-Commerce application (IS0 19845 conformant)
>> dispatches the contracting parties' mutually authorized payment message
>> (ISO 20022-conformant) ... “ à this assumes that the eCommerce
>> application choses the payment message and that discovery of payments
>> supported falls outside the web payments standard. For that to be true – we
>> would have to assume that either 1) eCommerce is IN the payments standard
>> flow or 2) payment initiation, discovery, negotiation of terms is in the
>> eCommerce flow. In the latter case, web payments has very little work to
>> accomplish, in the former, we face years (or longer) debates on the
>> enforcement of a standard instead of solving an issue of standardizing
>> payment process alone. Herein, is where I was agreeing with Adrian and
>> others that eCommerce is too large a concept to pull into a payments flow,
>> lest we rearchitect the entirety of the eCommerce flow concurrent with the
>> web payments standard.
>>
>>
>>
>> Moving forward:
>>
>> “ … to the initiating Depository (Payer's for "push"; Payee's for
>> "pull"…. à there is no concept (that I have seen) of an “initiating
>> depository” which is the arbiter of what accounts exist, who owns them, and
>> the payments instruments available to the parties. In eCommerce as I see
>> it, the seller has a pre-determined selection of payment
>> schemes/instruments that it can support. Delivery of this information to a
>> third party for matching to the buyer’s preference on usage seems like the
>> creation of an entity which need not exist.
>>
>>
>>
>> In segment #1 – the assumption here is that the format of a message is
>> chosen BEFORE the method of payment is chosen. To me this is a fundamental
>> flaw in that only few countries completely standardize on ISO20022 for
>> intra-country payments. Also, the payment scheme chosen may invoke a
>> standard that is different from ISO20022. I am reacting to the statement
>> that choice of payment method is part of the ISO20022 message sent to a
>> “depository” which is a concept that I have not yet seen in the use case
>> work.
>>
>>
>>
>> For this as I read it -- I think you have a scenario linked more firmly
>> to a more forced standardization then can work. Minus the EU, the largest
>> economies of the world use intra-country systems which do not standardize
>> on these concepts, nor on ISO20022. Even the EU does not have a complete
>> ISO20022 card implementation that could satisfy the requirement of a
>> message to a third party arbiter of payments mechanisms. China, USA,
>> Brazil, Japan, India – and others use variations of several systems. This
>> would then result in a message would go in ISO20022 to a third party,
>> connect buyer preference to seller capability, create another message in
>> the format required for the scheme selected, send out and return status in
>> that standard to be converted to a return message in ISO20022 format. This
>> flow causes two or more data formatting transformations.
>>
>>
>>
>> While it is possible to force compliance with ISO20022 -- and that could
>> work – the embedded association with the 20022 standard will diminish the
>> ability to aid the standardization of web payments which use a myriad of
>> communications and force the web payments standard to be subsumed into the
>> broader ISO20022 functionality. And – as discussed – the multiple
>> transformations will slow the payments process only to support a third
>> party matching system of buyer preference to seller ability to accept.
>>
>>
>>
>> It seems possible that the <end> is as you indicate: "Payment confirmed
>> to digital account belonging to XYZ, settled via PQR Payment System,
>> originating with digital account belonging to ABC." Could occur – we have
>> to caution that least-cost routing or other means of movement from a
>> requested settlement mechanism to another could, in fact, happen. With
>> that, you would have the dissonance of a specific settlement message which
>> may not have used the settlement mechanism assumed at the time of sale. On
>> this we need to be cautious about too deeply specifying exactly how the
>> transaction occurred.
>>
>>
>>
>> The last concept that I think you have here which is outside the scope is
>> that of contract to purchase where you mention “contracting parties”.
>> While, in most (not all) common law, we have a contract when we have an
>> offer and consideration – it appears (I may be reading this in error) –
>> that you are assuming the contract process is part of the payment. If that
>> is true, on that I would disagree. Contracting is a negotiation among
>> parties that a payment MAY occur under conditions in the future. But that
>> is not a payment.
>>
>>
>>
>> Summary: I am confused to the beginning and end of payments versus
>> eCommerce in your flow and see the creation of additional entities that I
>> have not seen previously in the use case work. Maybe this summary was the
>> answer to the question you posed and not all the previous discussion. Hope
>> this was useful.
>>
>>
>>
>> --
>> <image001.gif> <http://www.oracle.com/>
>> David Jackson | Senior Director Financial Services
>> Mobile: +1.614.560.1237 <+16145601237> | VOIP: +1.614.465.6654
>> <+16144656654>
>> Oracle Industry Solutions Group
>> New York City | Columbus
>>
>> <image002.gif> <http://www.oracle.com/commitment>
>>
>> Oracle is committed to developing practices and products that help
>> protect the environment
>>
>>
>>
>>
>>
>> *From:* Joseph Potvin [mailto:jpotvin@opman.ca]
>> *Sent:* Wednesday, June 24, 2015 11:09 AM
>> *To:* Web Payments IG
>> *Subject:* Re: Thanks to all and next steps
>>
>>
>>
>> Is the following coherent or confused?
>>
>> 1. e-Commerce application (IS0 19845 conformant) dispatches the
>> contracting parties' mutually authorized payment message (ISO
>> 20022-conformant) to the initiating Depository (Payer's for "push"; Payee's
>> for "pull".) Choice of payment system is part of the message, since this
>> matter must be established between the contracting parties before payment
>> initiation. The signal issued upon this event contains this info: "Payment
>> message with such and such attributes sent to digital account belonging to
>> ABC, for settlement via PQR Payment System, with digital account belonging
>> to XYZ.")
>>
>> 2. The initiating Depository receives the payment message, validates it
>> against some rules, and dispatches a payment message to the identified
>> Payment System. The signal issued upon this event contains this info:
>> "Payment message received by account belonging to ABC, and dispatched to
>> PQR Payment System. (Or: Payment message rejected by account belonging to
>> ABC. Error code 12345)
>>
>> 3. PQR Payment System receives the payment message, validates it against
>> some rules, and dispatches a payment message to the identified Depository.
>> (Several steps occur within any Payment System's settlement process, but
>> their internal details need not be tracked by Payees and Payers.) The
>> signal issued upon this event contains this info: Payment message received
>> by PQR Payment System, and settled with account belonging to XYZ. (Or:
>> Payment message rejected by PQR Payment System. Error code 67890)
>>
>> 4. The transaction terminating Depository (Payee's for "push"; Payer's
>> for "pull") dispatches a message to the e-Commerce application to confirm
>> that the payment is completed. The signal issued upon this event contains
>> this info: "Payment confirmed to digital account belonging to XYZ, settled
>> via PQR Payment System, originating with digital account belonging to ABC.")
>>
>>
>>
>> Such a cycle would run twice when payment is held in escrow.
>>
>>
>> Joseph Potvin
>> On behalf of DataKinetics http://www.dkl.com
>> Operations Manager | Gestionnaire des opérations
>> The Opman Company | La compagnie Opman
>> jpotvin@opman.ca
>> Mobile: 819-593-5983
>>
>>
>>
>> On Wed, Jun 24, 2015 at 10:11 AM, David Jackson <
>> david.dj.jackson@oracle.com> wrote:
>>
>> We only run off the rails because you are thinking that the “end” has to
>> be success – that is not the point here. The “end” is the end of the
>> payment. If that simply means – payment sent without error code – fine.
>> Just a definitive “end” is what I’m seeking. What is amiss with several
>> payments schemes is that the “payment sent” occurs and then logic is
>> transferred to the eCommerce function and the payer thinks it closed and
>> then has an argument with the merchant when they come back because there
>> was ANY error code. So the thing I’m trying to get to is the normal
>> condition of “sent without error code”. We don’t have to interpret the
>> error, just no error occurred = end. Error occurred – return to eCommerce
>> site for processing.
>>
>>
>>
>> Make sense? Just don’t like orphaned processes without a defined end.
>>
>>
>>
>> --
>> <image001.gif> <http://www.oracle.com/>
>> David Jackson | Senior Director Financial Services
>> Mobile: +1.614.560.1237 <+16145601237> | VOIP: +1.614.465.6654
>> <+16144656654>
>> Oracle Industry Solutions Group
>> New York City | Columbus
>>
>> <image002.gif> <http://www.oracle.com/commitment>
>>
>> Oracle is committed to developing practices and products that help
>> protect the environment
>>
>>
>>
>>
>>
>> *From:* Adrian Hope-Bailie [mailto:adrian@hopebailie.com]
>> *Sent:* Wednesday, June 24, 2015 9:53 AM
>> *To:* David Jackson
>> *Cc:* Joseph Potvin; Web Payments IG
>> *Subject:* Re: Thanks to all and next steps
>>
>>
>>
>> The challenge with defining the end is that I think there are more than
>> one ways to end :)
>> We will need to define what those are but they could be different for
>> push and pull payments and whether or not the scheme in use performs some
>> kind of out-of-band confirmation of payment.
>>
>> To handle all of these I think we'll end up with two different API
>> methods, something like "requestPayment" and another for "completePayment".
>>
>> The payee will call both and the response to complete payment should be
>> the final signal that the payment is complete.
>>
>> I don't want to get into too much design detail here as this is the job
>> of the WG but suffice it to say I expect they will define an interface and
>> flow that makes sense and caters for all of the use cases in scope (i.e.
>> both push and pull)
>>
>>
>>
>> On 24 June 2015 at 14:47, David Jackson <david.dj.jackson@oracle.com>
>> wrote:
>>
>> Yes – agreed. With the only caveat that there is a clear “end” of the
>> payments standard – that was why I keep focusing on whatever we call that
>> end <signal of some kind> that is the clear end of the payments process –
>> whether or not it is satisfactory! Even if we say that <payment sent> is
>> the end – fine, as long as the feedback is available. Then we can pick up
>> the process for the eCommerce process either to create standards or allow
>> the implementations.
>>
>>
>>
>> I knew we really did agree Adrian – just a matter of getting to
>> definitions!  J
>>
>>
>>
>> --
>> <image001.gif> <http://www.oracle.com/>
>> David Jackson | Senior Director Financial Services
>> Mobile: +1.614.560.1237 <+16145601237> | VOIP: +1.614.465.6654
>> <+16144656654>
>> Oracle Industry Solutions Group
>> New York City | Columbus
>>
>> <image002.gif> <http://www.oracle.com/commitment>
>>
>> Oracle is committed to developing practices and products that help
>> protect the environment
>>
>>
>>
>>
>>
>> *From:* Adrian Hope-Bailie [mailto:adrian@hopebailie.com]
>> *Sent:* Wednesday, June 24, 2015 7:44 AM
>> *To:* David Jackson
>> *Cc:* Joseph Potvin; Web Payments IG
>>
>>
>> *Subject:* Re: Thanks to all and next steps
>>
>>
>>
>> +1 That was the consensus at the F2F and that is what I have been trying
>> to say. Thanks for putting it so succinctly.
>>
>> The payment provides a flow that can be piggy-backed or built upon in
>> future for the "commerce" requirements of e-commerce and the intention will
>> be to define a payments flow that is open to this but to explicitly exclude
>> "commerce" requirements from the v1 scope.
>>
>>
>>
>> On 24 June 2015 at 00:42, David Jackson <david.dj.jackson@oracle.com>
>> wrote:
>>
>> Yes – agreed for eCommerce. In this case, we are doing the Web Payments
>> so we just need to have a defined end for the payments function. Invoice /
>> receipt can be the subject of other flows that are not the payment itself.
>> In the invoice / receipt discussion there are several decades of discussion
>> and standards work. So I agree that this subject (receipt / invoice) should
>> be outside the scope of a web payment standard.
>>
>>
>>
>> --
>> <image001.gif> <http://www.oracle.com/>
>> David Jackson | Senior Director Financial Services
>> Mobile: +1.614.560.1237 <+16145601237> | VOIP: +1.614.465.6654
>> <+16144656654>
>> Oracle Industry Solutions Group
>> New York City | Columbus
>>
>> <image002.gif> <http://www.oracle.com/commitment>
>>
>> Oracle is committed to developing practices and products that help
>> protect the environment
>>
>>
>>
>>
>>
>> *From:* Joseph Potvin [mailto:jpotvin@opman.ca]
>> *Sent:* Tuesday, June 23, 2015 4:46 PM
>>
>>
>> *To:* Web Payments IG
>> *Subject:* Re: Thanks to all and next steps
>>
>>
>>
>> Doesn't the ISO 20022 catalogue supply the necessary <signal of some
>> type> specs for each of the significant points along the payment sequence?
>> http://www.iso20022.org/full_catalogue.page
>>
>> David, while "there is no need of a “receipt” or “invoice” to mark it’s
>> end" within the payment system itself, there certainly is such a
>> requirement in the broader e-commerce system. An attempt to explain the
>> boundary between the two domains is here:
>>
>>
>> https://www.w3.org/community/webpayments/wiki/A_Quick_Introduction_to_UBL_Oriented_to_Payment_Solutions_Designers#Relationship_with_ISO_20022
>> This explanation is currently being reviewed by a couple of people at
>> SWIFT, and if necessary I'll tweak it when I hear back from them.
>>
>>
>> Joseph Potvin
>> On behalf of DataKinetics http://www.dkl.com
>> Operations Manager | Gestionnaire des opérations
>> The Opman Company | La compagnie Opman
>> jpotvin@opman.ca
>> Mobile: 819-593-5983
>>
>>
>>
>> On Tue, Jun 23, 2015 at 4:09 PM, David Jackson <
>> david.dj.jackson@oracle.com> wrote:
>>
>> The issue of a finite <end> of the payments process is not contentious at
>> all, it was the invoice / receipt that caused the issue. I still remain
>> deeply committed that an end state of the payments process needs to be
>> defined. This is why I represented it as a signal of some kind in which the
>> process is known to be over. Otherwise, there is a transaction which goes
>> without feedback and the user has no known end point while the seller has
>> no definition of end state. So, no, this does not seem to be contentious at
>> all, it is only the defining of the end state of the transaction.
>>
>>
>>
>> --
>> <image001.gif> <http://www.oracle.com/>
>> David Jackson | Senior Director Financial Services
>> Mobile: +1.614.560.1237 <+16145601237> | VOIP: +1.614.465.6654
>> <+16144656654>
>> Oracle Industry Solutions Group
>> New York City | Columbus
>>
>> <image002.gif> <http://www.oracle.com/commitment>
>>
>> Oracle is committed to developing practices and products that help
>> protect the environment
>>
>>
>>
>>
>>
>> *From:* Adrian Hope-Bailie [mailto:adrian@hopebailie.com]
>> *Sent:* Tuesday, June 23, 2015 2:33 PM
>> *To:* Joseph Potvin
>> *Cc:* Web Payments IG
>> *Subject:* Re: Thanks to all and next steps
>>
>>
>>
>> Hi Joseph, Dave,
>>
>> My interpretation of the consensus at the F2F was that we will leave all
>> of this contentious stuff to the payment scheme to define and will, in v1,
>> simply define a high level flow and a message format that can be used as a
>> container for scheme specific messaging.
>>
>> Adrian
>>
>>
>>
>>
>>
>> On 22 June 2015 at 16:40, Joseph Potvin <jpotvin@opman.ca> wrote:
>>
>> Thanks David,
>>
>> RE: "<signal of some type> to the payer that the transaction did, in
>> fact, get submitted – better yet that it was “completed” to end the
>> payments transaction"
>>
>>
>>
>> There was some interesting discussion amongst participants at a table
>> during the US Fed's Faster Payments Task Force meeting last week about
>> standardizing the various points along all payment systems sequences that
>> should generate signals that are accessible to both payers and payees. (The
>> analogy discussed had to do with how shipping and destination parties of a
>> courier service can track any package online.)
>>
>> Discussants agreed that many of the points along the way of a financial
>> transactioni would surely be unintelligible to most people. Also the table
>> agreed that there are very many points that could potentially generate such
>> signals. But these considerations support the idea that some generally
>> understandable notional "status" commonalities across all payment systems
>> might be usefully identified, which all payment system operators may be
>> willing to accommodate.
>>
>> Does any existing standard describe a payment status request as
>> minimalist as a ping echo?
>>
>>
>> Joseph Potvin
>> On behalf of DataKinetics http://www.dkl.com
>> Operations Manager | Gestionnaire des opérations
>> The Opman Company | La compagnie Opman
>> jpotvin@opman.ca
>> Mobile: 819-593-5983
>>
>>
>>
>> On Mon, Jun 22, 2015 at 10:05 AM, David Jackson <
>> david.dj.jackson@oracle.com> wrote:
>>
>> Joseph and all,
>>
>> I think we are getting hung-up on this topic of “invoice” again … may I
>> offer:
>>
>>
>>
>> V1 = we are NOT seeking to include a standard for invoice nor contents
>> related to such. We COULD offer an optional call to include an invoice of a
>> format used by both payee and payer should that be of interest in the
>> implementation (highly likely to loyalty processing). However, we WOULD
>> like to include a <signal of some kind> that the payment has been sent for
>> processing as feedback to the payer/customer. The payee/merchant uses that
>> (or other means NOT in this process flow) to effect fulfillment and other
>> activities which occur around the timing of the payment. Please note from
>> the F2F – the payment may be held from settlement until fulfillment is
>> accomplished (in the case of physical goods) to accommodate standards (and
>> some regulation) about when the payment may be accepted by the merchant.
>>
>>
>>
>> While I am a very big proponent of the use of “invoice” and “itemized
>> receipts” – there are far too many standards and de facto standards to
>> enable through a single payment flow. It would restrict the communications
>> between buyer/seller and force too much compliance. The idea is that the
>> feedback to the payer makes sense that the payment transaction has been
>> “accepted” or is “in progress” – whatever term might be useful and
>> productive here. It is not useful to “invoice” unless that is truly part of
>> the process flow between buyer/seller.
>>
>>
>>
>> I would like to reiterate my support for a  <signal of some type> to the
>> payer that the transaction did, in fact, get submitted – better yet that it
>> was “completed” to end the payments transaction. I agree with the strong
>> opinions that the “invoice” or “receipt” are not the intention of the
>> payments process.
>>
>>
>>
>> --
>> <image001.gif> <http://www.oracle.com/>
>> David Jackson | Senior Director Financial Services
>> Mobile: +1.614.560.1237 <+16145601237> | VOIP: +1.614.465.6654
>> <+16144656654>
>> Oracle Industry Solutions Group
>> New York City | Columbus
>>
>> <image002.gif> <http://www.oracle.com/commitment>
>>
>> Oracle is committed to developing practices and products that help
>> protect the environment
>>
>>
>>
>>
>>
>> *From:* Joseph Potvin [mailto:jpotvin@opman.ca]
>> *Sent:* Monday, June 22, 2015 9:48 AM
>> *To:* Web Payments IG
>> *Subject:* Re: Thanks to all and next steps
>>
>>
>>
>> Thanks Adrian,
>>
>> RE: "no longer intend on defining either an electronic invoice or receipt
>> but simply a payment request/response and confirmation"
>>
>> Based upon what Manu referred to as "the final list of use cases for
>> version 1" (dated 20 June):
>>
>> https://www.w3.org/Payments/IG/wiki/Main_Page/FTF_June2015/UseCasesForVersion1
>> ...three of the use cases in the current selection, from the "Agreement
>> on Terms" part, are each pre-payment functions involved in e-invoice
>> development:
>>
>>    - Registration-less (Agreement on Terms)
>>    <http://www.w3.org/TR/2015/WD-web-payments-use-cases-20150416/#agreement-on-terms>
>>    - One Time Payment (Agreement on Terms)
>>    <http://www.w3.org/TR/2015/WD-web-payments-use-cases-20150416/#agreement-on-terms>
>>    - Subscription (Agreement on Terms)
>>    <http://www.w3.org/TR/2015/WD-web-payments-use-cases-20150416/#agreement-on-terms>
>>
>> It seems to me that in the sequence: *Payer/Payee >> Invoice >>
>> Wallet/Account >> Payment System*
>>
>> 1. Buyers & Sellers: W3C has a mandate to specify essential commonalities
>> in how all browsers should handle any [*Payer/Payee >> Invoice*]
>> sequence. This work should *take-as-given* any e-invoice documents and
>> components established and maintained by the authoritative e-Commerce
>> semantic and technical specifications. The most prominent of these is UBL,
>> which can be expressed in XML or JSON;
>>
>> General Architectural Requirements:
>> • United Nations Commission on International Trade Law (UNCITRAL): “Model
>> Law on Electronic Commerce”; “Model Law on Electronic Signatures” and
>> related UNCITRAL guidance
>> http://www.uncitral.org/uncitral/en/uncitral_texts/electronic_commerce.html
>> • International Institute for the Unification of Private Law (UNIDROIT):
>> “Principles of International Commercial Contracts”.
>> http://www.unidroit.org/publications/513-unidroit-principles-of-international-commercial-contracts
>>
>>
>> 2. Financial Services:  W3C has a mandate to specify how any
>> Wallet/Account and how any Payment System should accommodate any
>> Web-originating/terminating [*Invoice >> Wallet/Account >> Payment
>> System*] sequence. This work should *take-as-given* any financial
>> messaging requirements and types established and maintainted by financial
>> messaging specifications. The most prominent of these is UNIFI (better
>> known as ISO 20022) which can be expressed in XML or JSON.
>>
>> General Architectural Requirements:
>> • Bank for International Settlements: “Principles for Financial Market
>> Infrastructures”
>> https://www.bis.org/cpmi/publ/d101.htm?
>> • International Organization of Securities Commissions (IOSCO):
>> “Objectives and Principles of Securities Regulation”
>> https://www.iosco.org/about/?subsection=key_regulatory_standards
>>
>> In the above, I use the word "Requirements" deliberately because even
>> though their respective elements are only guidelines, neglect of any  of
>> their elements is sure to cause lasting headaches.  (I accept that the
>> challenge of trying to accommodating all those elements up front is itself
>> quite a headache, but it's the short-term-pain-for-long-term-gain variety.)
>>
>>
>> Joseph Potvin
>> On behalf of DataKinetics http://www.dkl.com
>> Operations Manager | Gestionnaire des opérations
>> The Opman Company | La compagnie Opman
>> jpotvin@opman.ca
>> Mobile: 819-593-5983
>>
>>
>>
>> On Mon, Jun 22, 2015 at 6:35 AM, Adrian Hope-Bailie <
>> adrian@hopebailie.com> wrote:
>>
>> Hi Joseph,
>>
>> To add some clarity. The work we did at the face to face was mostly to
>> narrow the scope of v1 to explicitly exclude anything not required to
>> execute a payment. You'll notice that we no longer intend on defining
>> either an electronic invoice or receipt but simply a payment
>> request/response and confirmation.
>>
>> My feeling was that this was due to the acceptance by all that a lot of
>> this is outside the scope of "payments" and more in the scope of "commerce"
>> and therefor necessarily introduces the need to incorporate work from a far
>> wider scope of liaison bodies.
>>
>> My perception of the v1 scope is to define standard messaging and a
>> protocol to initiate and complete payments from the browser while leaving
>> the bulk of the specifics to the payment scheme that is used. v2 of the
>> group's work will be wider in scope and will be based around the liaison
>> work done by the external reviews task force.
>>
>> Adrian
>>
>>
>>
>> On 21 June 2015 at 01:22, Joseph Potvin <jpotvin@opman.ca> wrote:
>>
>> Great to hear, except of the following...
>>
>> RE: I don't think we really spent too much time discussing ... external
>> liaisons, ... Next steps may be to back burner this until..."
>>
>> It seems to me critically time-sensitive that the IG's specifications
>> boundary (in scope / out of scope) be rendered operational in terms of
>> defining and engaging working relationships with other primary entities
>> that hold the official mandate for (a) Payment Systems Principles (eg BIS,
>> UNIDROIT); (b) e-Commerce Model Laws (eg UNCITRAL); and (c) Payment
>> Information Specifications (eg ISO-TCs; OASIS-TCs).
>>
>> The IG's official reply to the X9 review states: "As you rightly observe,
>> several aspects of what we are working on (e.g., trust, credentials,
>> digital signatures, loyalty programs, etc.) extend beyond a payment
>> transaction and are applicable to other standards efforts that may not even
>> involve payments."
>>
>> Several matters being worked on by this IG also extend beyond the W3C's
>> specifications domain.
>>
>> It is not clear why a "hot front-burner" process is not established for
>> this.
>>
>>
>> Joseph Potvin
>> On behalf of DataKinetics http://www.dkl.com
>> Operations Manager | Gestionnaire des opérations
>> The Opman Company | La compagnie Opman
>> jpotvin@opman.ca
>> Mobile: 819-593-5983
>>
>>
>>
>> On Sat, Jun 20, 2015 at 6:19 PM, Manu Sporny <msporny@digitalbazaar.com>
>> wrote:
>>
>> Thanks to everyone that attended and participated in the 2015 W3C Web
>> Payments face-to-face in NYC. I was particularly thrilled during the
>> roundtable as the message the group members were delivering demonstrated
>> an aligned vision. What's more impressive is the people that are
>> participating and the short time that it took to put this new effort
>> together and align our direction.
>>
>> There's still much more work to do, but my confidence that we can pull
>> this Web Payments stuff off is the highest it has ever been.
>>
>> I was just reviewing the goals of the meeting and had a few thoughts for
>> the coming weeks:
>>
>> > Prioritize payments use cases and the capabilities necessary to
>> > fulfill them.
>>
>> We came out of the face-to-face with a solid list of use cases:
>>
>>
>> https://www.w3.org/Payments/IG/wiki/Main_Page/FTF_June2015/UseCasesForVersion1
>>
>> I don't think we identified all the capabilities needed for V1, but with
>> a well-defined list of use cases, I think we'll be able to do a good job
>> with the capabilities over the next several weeks.
>>
>> I'm going to go through the use cases and update all the V1 use cases
>> with the clarifications made throughout the face-to-face meetings. I'll
>> also list the use cases in the Roadmap document.
>>
>> > Review draft charter(s) and plan for first round of standardization
>>
>> Quite a bit of work went into the Payment Architecture WG charter and I
>> think we have enough feedback to draw up a draft charter that can get
>> consensus from the group via the mailing list.
>>
>> I don't think we can say the same for the Authentication WG charters or
>> the Credentials WG charter.
>>
>> Next steps for the PAWG charter seem to be for Ian to revise it and pass
>> it by the group.
>>
>> Next steps for the Authentication WG charters seem to be for us to
>> identify capabilities that we can put into those charters.
>>
>> Next steps for the Credentials WG charter seems to be to coordinate w/
>> the Credentials CG and try to get more support from outside of this group.
>>
>> > Initiate discussion on other IG activities (to follow push towards
>> > launch of standard(s) groups).
>>
>> I don't think we really spent too much time discussing this, other than
>> "focus on V2, external liaisons, and supporting the WGs".
>>
>> Next steps may be to back burner this until after the PAWG is launched.
>>
>> > Solicit feedback from broader community on group's direction (via
>> > the roundtable)
>>
>> The feedback that we heard during the roundtable was probably best
>> summarized by what was not said; there didn't seem to be an objection
>> for the current direction. There were concerns over privacy and level
>> playing field. The cocktail reception discussions didn't reveal (to me)
>> any concerns about the current scope of work around payments.
>>
>> The biggest criticism seemed to be a lack of near-term focus on identity
>> and credentials, but that may be my bias kicking in.
>>
>> Next steps would probably be to establish deeper connections with the
>> Roundtable attendees and ensure that they're involved in future reviews.
>>
>> All in all, I think we made excellent progress. Thank you for all the
>> great comments, input, and discussion.
>>
>> -- manu
>>
>> --
>> Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
>> Founder/CEO - Digital Bazaar, Inc.
>> blog: Web Payments: The Architect, the Sage, and the Moral Voice
>> https://manu.sporny.org/2015/payments-collaboration/
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>
>