Re: Thanks to all and next steps

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.


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.
>
>
>
> --
> [image: Oracle] <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
>
> [image: Green Oracle] <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.
>
>
>
> --
> [image: Oracle] <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
>
> [image: Green Oracle] <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
>
>
>
> --
> [image: Oracle] <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
>
> [image: Green Oracle] <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.
>
>
>
> --
> [image: Oracle] <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
>
> [image: Green Oracle] <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.
>
>
>
> --
> [image: Oracle] <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
>
> [image: Green Oracle] <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.
>
>
>
> --
> [image: Oracle] <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
>
> [image: Green Oracle] <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/
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>