Re: Thanks to all and next steps

> 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 <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 <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/ <http://www.dkl.com/>
> Operations Manager | Gestionnaire des opérations
> The Opman Company | La compagnie Opman
> jpotvin@opman.ca <mailto:jpotvin@opman.ca>
> Mobile: 819-593-5983
> 
> On Wed, Jun 24, 2015 at 12:06 PM, David Jackson <david.dj.jackson@oracle.com <mailto: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 <tel:+16145601237> | VOIP: +1.614.465.6654 <tel:+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 <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 <http://www.dkl.com/>
> Operations Manager | Gestionnaire des opérations
> The Opman Company | La compagnie Opman
> jpotvin@opman.ca <mailto:jpotvin@opman.ca>
> Mobile: 819-593-5983 <tel:819-593-5983>
>  
> 
> On Wed, Jun 24, 2015 at 10:11 AM, David Jackson <david.dj.jackson@oracle.com <mailto: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 <tel:+16145601237> | VOIP: +1.614.465.6654 <tel:+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 <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 <mailto: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 <tel:+16145601237> | VOIP: +1.614.465.6654 <tel:+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 <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 <mailto: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 <tel:+16145601237> | VOIP: +1.614.465.6654 <tel:+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 <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 <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 <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 <http://www.dkl.com/>
> Operations Manager | Gestionnaire des opérations
> The Opman Company | La compagnie Opman
> jpotvin@opman.ca <mailto:jpotvin@opman.ca>
> Mobile: 819-593-5983 <tel:819-593-5983>
>  
> 
> On Tue, Jun 23, 2015 at 4:09 PM, David Jackson <david.dj.jackson@oracle.com <mailto: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 <tel:+16145601237> | VOIP: +1.614.465.6654 <tel:+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 <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 <mailto: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 <http://www.dkl.com/>
> Operations Manager | Gestionnaire des opérations
> The Opman Company | La compagnie Opman
> jpotvin@opman.ca <mailto:jpotvin@opman.ca>
> Mobile: 819-593-5983 <tel:819-593-5983>
>  
> 
> On Mon, Jun 22, 2015 at 10:05 AM, David Jackson <david.dj.jackson@oracle.com <mailto: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 <tel:+16145601237> | VOIP: +1.614.465.6654 <tel:+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 <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 <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 <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 <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 <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 <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 <http://www.dkl.com/>
> Operations Manager | Gestionnaire des opérations
> The Opman Company | La compagnie Opman
> jpotvin@opman.ca <mailto:jpotvin@opman.ca>
> Mobile: 819-593-5983 <tel:819-593-5983>
>  
> 
> On Mon, Jun 22, 2015 at 6:35 AM, Adrian Hope-Bailie <adrian@hopebailie.com <mailto: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 <mailto: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 <http://www.dkl.com/>
> Operations Manager | Gestionnaire des opérations
> The Opman Company | La compagnie Opman
> jpotvin@opman.ca <mailto:jpotvin@opman.ca>
> Mobile: 819-593-5983 <tel:819-593-5983>
>  
> 
> On Sat, Jun 20, 2015 at 6:19 PM, Manu Sporny <msporny@digitalbazaar.com <mailto: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 <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/ <https://manu.sporny.org/2015/payments-collaboration/>
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>