Re: Payment Initiation - platform integration

On 2015-09-16 20:54, Adrian Hope-Bailie wrote:
> Two personal comments on UBL and XML vs JSON *specifically with regard to the proposed WG*.
>
> 1. Invoices, and therefore UBL, are out of scope for what is being dealt with in this WG.

Odd, BTW a payment request isn't really an invoice, it is more like a quote but that
doesn't mean that we should use UBL quote either.  For consumers, clear text receipts
or even PDFs would be more useful.



 > They form part of the larger scope of the IG and may be part of the scope of a future WG.
 > At most, I expect that accommodation may be made in the logical message designs to
 > reference the invoice triggered the payment.
>
> 2. The WG will likely use JSON as it's preferred message encoding as this is the
 > accepted practice today for W3C recommendations.

With one (for us) big exception, signatures.  W3C haven't [yet] decided to adopt
JOSE and if they did it would be a big mistake since JOSE doesn't support
"Signed JSON". The JOSE folks have created a CMS equivalent in JSON which
dress business messages in Base64.


> That is not to say that the logical messages we define could not be encoded
 > in other forms or that informative examples, test cases etc may not be produced
 > using other encodings.

I imagine that you only need to goto other formats when you hit the backend
but that this part is already dealt with by the backend software supplier.
What you DO need is to have the right information.


> *With regard to the work of the IG*, my hope is that, with Kris and Vincent's
 > help, we will vastly improve our understanding of ISO20022 and see where the
 > IG and the ISO20022 RA may work together to close the gap between what is
 > being done in the two groups. This MAY include such things as collaborating
 > to produce a recommendation for JSON encoding ISO20022 messages or some
 > standards for exposing Web APIs that exchange ISO20022 messages.

This would IMO make life even more complicated since suddenly systems must speak
two languages.

Some systems like 4-corner will require completely new messages to backends.
They should be in JSON.

> UBL is most likely to come into context when the group takes on the broader
 > scope we have called "commerce" at which time it will likely be an important
 > input to the work.

I personally doubt that but it is of little importance at this stage.

Anders
>
> On 16 September 2015 at 18:29, Joseph Potvin <jpotvin@opman.ca <mailto:jpotvin@opman.ca>> wrote:
>
>     Hope the following is useful. I asked UBL TC Co-Chair Ken Holman for his comments...
>
>     At 2015-09-16 11:20 -0400, you wrote:
>
>         "Ken, Got a suggested reply?"
>
>
>     Well, I can make a few observations that you can do with as you like.
>
>          On 2015-09-16 16:49, Adrian Hope-Bailie wrote:
>          RE: "invoice" is described as *"a document used to request payment"*
>          [Anders Rundgren <anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>>]   I hope that UBL won't be used for payment requests. UBL was designed for B2B and payment operations usually only refer to invoice numbers.
>
>     The only seven mandatory items in the UBL Invoice are an identification string, an issue date, the party responsible to make payment, the party responsible to receive payment, a legal monetary total, and an item identification string and an item amount for each item.
>
>     Ref: http://docs.oasis-open.org/ubl/os-UBL-2.1/mod/summary/reports/UBL-AllDocuments-2.1.html#Table_Invoice
>
>     This satisfies a legal request for payment in any context, not just B2B or B2G, and so is not encumbered by any business semantic of "invoice".  All of the other semantics available in UBL are handy for business applications, but are not necessary to make UBL useful in any situation where a request for payment is being made.  Using the noun "invoice" is a convenient abbreviation.
>
>
>     RE: Aren't you BTW rather planning to use JSON rather than XML, ISO, ASN.1 etc?
>
>     JSON is used to convey an internal memory structure of information from one application to another application, obliging both applications to begin working from the same internal memory structure.
>
>     XML is used to convey information in an arbitrary document format so that applications can map their internal memory structures to and from the document format, with the added benefit of the document format being independently inspected, for example, for auditing purposes.
>
>     JSON is ideal between two applications that have identical memory and implementation representations, and a tight binding, and foreknowledge of the order and makeup of every information item.  Tight binding is not convenient for representing optionally-present information.
>
>     XML is ideal between two applications that have independent memory and implementation representations and a loose binding.  Loose binding is convenient for representing optionally-present information.  It is focused on conveying intent in a way that allows the information to be used in multiple ways.  XML is also self-documenting in the judicious use of labels for the information items, providing for independent inspection.
>
>     Loose application bindings and self-documenting labels are the better choices for open standards where participants have varied implementations, varied platforms and varied contexts of use of the information.
>
>     RE:   <https://yourlogicalfallacyis.com/false-cause>https://yourlogicalfallacyis.com/false-cause
>     An invoice may be defined as a means to request a payment but that does not mean that a payment must always be requested by an invoice.
>
>
>     True, but if a request for payment is needed and the invoice is an available and satisfactory document for legal and practical purposes, then there is nothing that prevents the invoice from being used for this purpose:
>     https://yourlogicalfallacyis.com/the-fallacy-fallacy
>
>     . . . . . . . Ken
>
>
>     Joseph Potvin
>     Project Coordinator, DataKinetics
>     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>
>     LinkedIn <https://www.linkedin.com/pub/joseph-potvin/2/148/423>
>
>     On Wed, Sep 16, 2015 at 10:57 AM, Anders Rundgren <anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>> wrote:
>
>         On 2015-09-16 16:49, Adrian Hope-Bailie wrote:
>
>             RE: "invoice" is described as *"a document used to request payment"*
>
>
>         I hope that UBL won't be used for payment requests.
>
>         UBL was designed for B2B and payment operations usually only refer to invoice numbers.
>         Aren't you BTW rather planning to use JSON rather than XML, ISO, ASN.1 etc?
>
>         Anders
>
>
>             https://yourlogicalfallacyis.com/false-cause
>
>             An invoice may be defined as a means to request a payment but that does not mean that a payment must always be requested by an invoice.
>
>             On 16 September 2015 at 16:08, Joseph Potvin <jpotvin@opman.ca <mailto:jpotvin@opman.ca> <mailto:jpotvin@opman.ca <mailto:jpotvin@opman.ca>>> wrote:
>
>                  RE: "Is “invoice” synonymous with “authorization request” or is it something different?"
>
>
>                  This is from the site of UBL Technical Cttee Co-Chair Ken Holman's site, where "invoice" is described as *"a document used to request payment"*
>             http://www.cranesoftwrights.com/resources/Crane-UBL-Skeleton/Crane-UBL-Invoice-2.1.html
>
>                  The specs: http://ubl.xml.org/wiki/ubl-specifications
>
>                  Here are a couple of general views of what UBL contributes to electronic invoicing:
>             http://eeiplatform.com/about/
>             http://www.faces-online.nl/ubl-breakthrough-electronic-invoicing/
>
>                  RE: [Dan S.] "I could be splitting a bill and that is my share, I could be giving someone a gift or donation - there is not always an invoice. Furthermore if you want to handle payments pull then there is no invoice, such an authorization to allow a company to debit your account."
>
>                  Call it what you wish in whatever context you like. In UBL, that's all specified in a document called "invoice", across any context.  I'm not aware of any better generic document type for this purpose, in any other existing open standard.
>
>                  Joseph Potvin
>                  Project Coordinator, DataKinetics
>                  Operations Manager | Gestionnaire des opérations
>                  The Opman Company | La compagnie Opman
>             jpotvin@opman.ca <mailto:jpotvin@opman.ca> <mailto:jpotvin@opman.ca <mailto:jpotvin@opman.ca>>
>                  Mobile: 819-593-5983 <tel:819-593-5983> <tel:819-593-5983 <tel:819-593-5983>>
>                  LinkedIn <https://www.linkedin.com/pub/joseph-potvin/2/148/423>
>
>                  On Wed, Sep 16, 2015 at 8:49 AM, Matt Howarter <Matthew.Howarter@walmart.com <mailto:Matthew.Howarter@walmart.com> <mailto:Matthew.Howarter@walmart.com <mailto:Matthew.Howarter@walmart.com>>> wrote:
>
>                      Is “invoice” synonymous with “authorization request” or is it something different?____
>
>                      __ __
>
>                      *Matt Howarter****Director - Payment Services*
>                      Phone: 479.204.9922 <tel:479.204.9922> <tel:479.204.9922 <tel:479.204.9922>> Fax: 479.277.9796 <tel:479.277.9796> <tel:479.277.9796 <tel:479.277.9796>>
>             Matthew.Howarter@wal-mart.com <mailto:Matthew.Howarter@wal-mart.com> <mailto:Matthew.Howarter@wal-mart.com <mailto:Matthew.Howarter@wal-mart.com>>
>                      Walmart
>                      702 SW 8th St.
>                      Bentonville, AR 72716-0100
>                      *Saving people money so they can live better.*____
>
>                      __ __
>
>                      *From:*Joseph Potvin [mailto:jpotvin@opman.ca <mailto:jpotvin@opman.ca> <mailto:jpotvin@opman.ca <mailto:jpotvin@opman.ca>>]
>                      *Sent:* Wednesday, September 16, 2015 5:41 AM
>                      *To:* Web Payments IG; Web Payments CG
>                      *Subject:* Re: Payment Initiation - platform integration____
>
>                      __ __
>
>                      Is there agreement that:____
>
>
>                      1. Payment is always specified and initiated from an invoice?____
>
>                      2. UBL 2.1 provides the relevant global standard for an invoice? http://ubl.xml.org/ ____
>
>
>                      ____
>
>                      Joseph Potvin
>                      Project Coordinator, DataKinetics
>                      Operations Manager | Gestionnaire des opérations
>                      The Opman Company | La compagnie Opman
>             jpotvin@opman.ca <mailto:jpotvin@opman.ca> <mailto:jpotvin@opman.ca <mailto:jpotvin@opman.ca>>
>                      Mobile: 819-593-5983 <tel:819-593-5983> <tel:819-593-5983 <tel:819-593-5983>>____
>
>                      LinkedIn <https://www.linkedin.com/pub/joseph-potvin/2/148/423>____
>
>                      __ __
>
>                      On Wed, Sep 16, 2015 at 5:45 AM, Adrian Hope-Bailie <adrian@hopebailie.com <mailto:adrian@hopebailie.com> <mailto:adrian@hopebailie.com <mailto:adrian@hopebailie.com>>> wrote:____
>
>                      Looking at the draft spec from Digital Bazaar for the CG and considering both, our language in the charter, and also some of the comments from the charter AC review I wondered what precedent there may be in defining how a browser should process an API call that requires interaction with the platform (host OS).____
>
>                      The best example I could find is in the Web Notifications PR published earlier this month: http://www.w3.org/TR/2015/PR-notifications-20150910/#displaying-notifications____
>
>                      I would like to get the groups' (both IG and CG) views on the parallels here between the action "Displaying Notifications" from the Web Notifications recommendation and a potential "Initiating Payments" section we'd put in a recommendation from our WG.____
>
>                      The pertinent line from the Web Notifications rec is:
>                      "Display notification on the device (*e.g. by making the appropriate notification platform API call*)." - emphasis mine.____
>
>                      While I know not all platforms upon which browser's run today have mature "payment APIs" in the same way that they have relativley mature "notifications APIs" this open-ended approach seems appealing in that it avoids the browser needing to become complex payment processing applications.____
>
>                      Rather, the messages passed to the navigator.payments API in the browser should simply be passed directly to the platform's payment API (following any security or privacy scrutiny or permissions checks we define).
>
>                      The timing seems right for us to work with the platform vendors (many of whom are also browser vendors that have expressed interest in working on this problem) to define a common vocabulary and logical messages for this flow.____
>
>                      *Example:
>                      *
>                      On a mobile platform I see this working similarly to the way Android intents may function. The browser passes the payment initiatiation request to the platform and the user is prompted with the app selection dialogue they are accustomed to for selecting the app they want to use for that action (the same way you select which app to use when sharing a photo for example). ____
>
>                      __ __
>
>                      Thoughts?____
>
>                      __ __
>
>                      This email and any files transmitted with it are confidential and intended solely for the individual or entity to whom they are addressed. If you have received this email in error destroy it immediately. *** Walmart Confidential ***
>
>
>
>
>
>

Received on Wednesday, 16 September 2015 19:24:37 UTC