W3C home > Mailing lists > Public > public-webpayments@w3.org > April 2016

Re: Update on Web Payments Working Group [The Web Browser API Incubation Anti-Pattern]

From: Roger Bass <roger@traxiant.com>
Date: Tue, 5 Apr 2016 10:33:47 -0700
Message-ID: <CA+nC-Xtt+joZzgO1hmdC8ooDc-dzCXwnT+0AxNaWUNUppzOkBw@mail.gmail.com>
To: Anders Rundgren <anders.rundgren.net@gmail.com>
Cc: Joseph Potvin <jpotvin@opman.ca>, Web Payments CG <public-webpayments@w3.org>
This seems to be a time for big picture reflections. How to incubate a new
standards effort and platform, and avoid its "corruption" by commercial
vested interests has been a core concern on this thread. Some of you have
commented on perhaps finding other standards venues that are less
"corporate" than the W3C.

I broadly agree. But I have two further observations: first, that thinking
about standards venues is just one part (and not the most important) in
thinking more broadly about the adoption trajectory; and second, that
thinking about use cases is absolutely central. My conclusion, to state it
upfront: an Internet of Payments, focused first on interoperability of
existing systems, behaviors and processes, and initially perhaps B2B
Payments, is a better candidate to focus on first. The Interledger effort
has some important and helpful characteristics in thinking about a
trajectory to mass adoption.

With hindsight, it was perhaps always quixotic to expect early progress -
and from a pure, community-led process at that - from a re-engineering of
the mass-scale user experience that is web checkout. Obviously enough,
these experiences depend on major browser platforms, as well as tens if not
hundreds of thousands of checkout solution implementations.

The examples of the Internet and the Web, and their adoption trajectories,
are perhaps instructive. Mass adoption of the Internet came first, led by
email - after a decade or so of incubation and global adoption in academia.
The use case that drove that mass adoption was email, with the trigger of
large commercial providers deciding to make their email interoperable using
the Internet email stack (TCP/IP, DNS, SMTP, S/MIME). This involved no
client software change (or minimal?) and a tiny end-user behavior change:
just adding "@" to email addresses. The Web, which was a significant change
for end-users and publishers alike, albeit one with compelling value, came
later, and piggy-backed on that earlier mass adoption of the Internet.

What, then, should we look for as regards use cases with the potential
become the email-like "killer app" for an emerging Internet of Payments?
The "minimal behavior/process change" aspect is crucial. That goes for
end-users: enabling them to continue doing what they're doing, with what
they already have. It goes for providers too: enabling them to just "plug
in" a router, rather than change internals of their systems. B2B Payments
present such a use case. Both payers and payees already broadly support a
variety of processes - some more efficient than others. New models for
interoperability can simply shift volume from less efficient to more
efficient channels, with minimal process change. Such scenarios certainly
touch very much on the large-scale incumbent payment networks, domestically
and globally. Commercial interests will be very much involved in deploying
there. The Interledger effort, however, sits in an interesting place from
an adoption trajectory perspective. It seems to me it could play the role
that academia played for the Internet and email: led by technologists, and
with some early users that could help reach some level of global scale,
albeit still small enough to steer somewhat clear of the larger commercial
interests in building early adoption.

As others here have noted, the Identity / Credentials aspect of all this is
absolutely foundational to any payments effort. There's some early
discussion on the Interledger CG email list about B2B and other payments
use cases (sitting on top of the lower, Interledger Protocol layers). The
initial set up of a new payment channel - and verification of payee
identity - is a core, challenging aspect of all this. It's unclear to me
how the Credentials aspects of the WPIG work may fit with that. But if
you're involved / interested - and if you buy in to some of the broader
arguments I've made here - I'd welcome your involvement in thinking about
how these pieces might fit together.

Best,
Roger


On Tue, Apr 5, 2016 at 4:54 AM, Anders Rundgren <
anders.rundgren.net@gmail.com> wrote:

>
> On Apr 5, 2016 12:08 PM, "Joseph Potvin" <jpotvin@opman.ca> wrote:
> >
> > RE: "fundamental limitations of the Web (browser) platform which still
> haven't been adequately addressed"
> >
> > This could be stated as a frustration or as a neutral fact.
>
> That Apple Pay is not working on the Web is probsbly not because Apple
> deliberately wanted to cripple their product.
>
> I'm pretty sure that they will launch a Web interface fairly soon which is
> less fuzzy integrating in existing Web sites than the W3C solution which
> more or less presumes a total rewrite of the checkout system (the downside
> of "revolutionary" approaches).
>
> anders
>
> >
> > The W3C staff have constraints they must work within, being employees of
> a sort of 'secretariat' that has a sort of 'security council' of members
> whose role is similar to the role played by exceptionalist countries of the
> UN (some permanent, some invited in on 'good' behaviour'.  They are what
> they are.
> >
> > Both the W3C and the UN organizations are representative of their
> corporation and country members respectively, within structures that are
> indeed 'inclusive' of everybody else to some extent, but whose most
> significant decision-making processes are shaped by and generally favor
> incumbents.
> >
> > If one's mission is to optimize digital payments, and certain aspects
> that would be optimally addressed in W3C specs don't make it through the
> W3C's processes, then go for a work-around. One could explore whether
> certain of those functional objectives might instead be pursued through the
> ITU or the IETF. And one can explore whether something like a parallel spec
> can be put forward (as in the tradition of "dissenting opinions" in law
> https://en.wikipedia.org/wiki/Dissenting_opinion ). These need not be
> done in an antagonistic way.
> >
> > Joseph Potvin
> >
> > On Tue, Apr 5, 2016 at 1:24 AM, Anders Rundgren <
> anders.rundgren.net@gmail.com> wrote:
> >>
> >> Joseph,
> >>
> >> The Web Payment WG is NOT trying to create a "Payment Standard" but
> something that they claim can build on existing and new payment standards.
> >>
> >> Will this succeed?  I doubt that because there are very few signs of
> any genuine interest from for example VISA (they have recently launched
> their own API).
> >>
> >> The core problem with Web Payments is (IMO) not related to formats or
> processes, but to fundamental limitations of the Web (browser) platform
> which still haven't been adequately addressed.
> >>
> >> Anders
> >>
> >> On Apr 4, 2016 11:29 PM, "Joseph Potvin" <jpotvin@opman.ca> wrote:
> >>>
> >>> RE: "if W3C is not the answer for this"
> >>>
> >>> The Web is the optimal layer for standardization of some but not all
> aspects of Web-mediated payment. Therefore this current schism may be a
> blessing in disguise, if this turns out to be a useful bifucation point at
> which the excellent integrated work that's been done to date is critically
> assessed to determine which open standards and open quasi-standards bodies
> may be the optimal ones to migrate certain elements to. The the community
> can build upon many existing partnerships amongst open standards bodies.
> >>>
> >>> I've forwarded below a message I originally sent a year ago relating
> to working relationships between W3C and other standards bodies, and
> amongst varous other standards bodies.  Maybe this, just in terms of the
> way of thinking suggested here, might lead to some ideas in response to:
> "Now what?"
> >>>
> >>> ---------- Forwarded message ----------
> >>> From: Joseph Potvin <jpotvin@opman.ca>
> >>> Date: Fri, May 22, 2015 at 7:55 AM
> >>> Subject: Re: [glossary] External data dictionary reference requirements
> >>> To: E.R.Fekkes@rn.rabobank.nl, Web Payments CG <
> public-webpayments@w3.org>, Web Payments IG <public-webpayments-ig@w3.org>
> >>>
> >>> RE: Are there specific standards bodies FORMALLY recognized by the W3C?
> >>>
> >>> Hmm, in fact I was hoping there were but I don't know.
> >>>
> >>> In domains like payments and e-commerce, any Venn diagram of the
> relevant deep-rooted standards bodies will look like the overlapping
> circles of the Olympic logo. So formal liaisons seem to me indispensible to
> facilitate dedicated efforts to map the structure, semantics & syntax.
> Ideally the sort of formal recognition I had in mind for this IG would be
> like these examples:
> >>> W3C & OASIS
> http://www.w3.org/Submission/2006/01/w3c-oasis-cgm-final-051215.pdf
> >>> W3C & OMA http://www.w3.org/2004/05/W3C-OMA-Agreement-FINAL.html
> >>> W3C & VoiceXML Forum http://www.w3.org/2001/10/MOU.txt
> >>>
> >>> Here also are some non-W3C examples:
> >>> * IEC, ISO, ITU & UN/ECE
> >>> http://www.itu.int/en/ITU-T/ebusiness/Pages/mou/MoUMG-members.aspx
> >>> * ISO & IEC
> >>> http://www.iso.org/iso/jtc1_home.html
> >>> * IETF & ITU
> >>> http://tools.ietf.org/html/rfc6756
> >>> * IETF & IEEE 802
> >>> http://tools.ietf.org/html/draft-iab-rfc4441rev-08
> >>>
> >>>
> >>> RE: I am not sure if it is right to label this as the PRIMARY default
> external source.
> >>>
> >>> This IG has correctly identified ISO 20022 as the primary default
> external standard for the exchange of financial information. In a nutshell,
> my recommendation is for this W3C initiative to equivalently reference both
> ISO 20022 and ISO 19845 (i.e. UBL
> http://www.iso.org/iso/catalogue_detail.htm?csnumber=66370  due for final
> vote next month).
> >>>
> >>> SWIFT brought uniformity to the financial info for 20022, but things
> aren't quite as elegant in the realm of e-commerce standards. Rather than a
> nice orderly Olympic logo sort of Venn Diagram, it's more like scribbled
> circles, with the result that there's been considerable confusion about
> which standards bodies cover what aspects. Here's a (2011) effort by
> OASIS/UBL Co-Chair Ken Holman to situate these various circles:
> >>>
> http://eeiplatform.com/4701/why-consider-cii-or-sepa-with-the-advent-of-ubl-2-1/
> >>> Original source: http://ubl.xml.org/book/export/html/234
> >>>
> >>> Things have advanced in the subsequent 4 years, and based on what I
> see, I recommend that UBL be given the same status as 20022 in this IG's
> work, acknowledging that there are likely a few aspects where they overlap
> an must be reconciled.
> >>>
> >>> This also means that anything which shows up in this W3C IG/GC work as
> "in scope", and which is already addressed in those other standards (ditto
> for others that I've not mentioned here), should be pointed at, not
> re-created or re-stated.
> >>>
> >>> Joseph Potvin
> >>> Operations Manager | Gestionnaire des opérations
> >>> The Opman Company | La compagnie Opman
> >>> jpotvin@opman.ca
> >>> Mobile: 819-593-5983
> >>>
> >>>
> >>>
> >>>
> >>> On Mon, Apr 4, 2016 at 4:23 PM, Melvin Carvalho <
> melvincarvalho@gmail.com> wrote:
> >>>>
> >>>>
> >>>>
> >>>> On 4 April 2016 at 22:02, Christopher Allen <
> ChristopherA@blockstream.com> wrote:
> >>>>>
> >>>>> On Mon, Apr 4, 2016 at 10:54 AM, Steven Rowat <
> steven_rowat@sunshine.net> wrote:
> >>>>>>
> >>>>>>   C. The real question is: can Credentials be solved in an
> open-standard way, thereby creating a playing field on which an open Web
> Payments standard can flourish?
> >>>>>
> >>>>>
> >>>>> I have not introduced myself yet, as my firm's membership
> (Blockstream) has been approved for W3C but has not been activated pending
> paperwork.
> >>>>
> >>>>
> >>>> Welcome!  Anyone is welcome to participate in community groups.
> Being a paid member will also give you access to working groups.  Ive been
> excited by blockstream work for some time, and am working on payment
> channels too.
> >>>>
> >>>>>
> >>>>>
> >>>>> However, I want to be clear that the interest from my firm, and in
> general from the blockchain and bitcoin community that we represent, is
> around verified credentials that supports decentralized identity, private
> channels, and selective disclosure/blinding/non-correlation of identifiers
> and attributes. This is the main reason why we are joining W3C.
> >>>>
> >>>>
> >>>> This is a great use case, and one that is well aligned with web
> standard IMHO.  I am also personally working on these use cases, and feel
> that W3C standards represent an unparalleled solution.
> >>>>
> >>>>>
> >>>>>
> >>>>> We are planning to make substantial contributions of open source
> code and cryptographic develop effort in these areas over the next year
> (which is part of why I'm involved with http://ID2020Summit.org at the
> UN) and desire this to be part of an open process.
> >>>>
> >>>>
> >>>> Awesome!
> >>>>
> >>>>>
> >>>>> But if W3C is not the answer for this, we'll move our efforts
> elsewhere.
> >>>>
> >>>>
> >>>> The W3C isnt a magic bullet.  It produces web based specifications,
> normally or a high quality in terms of extensibility and interop.  The
> specs can sometimes be hard to read and over a number of documents.  And
> some use cases require putting pieces together like lego, but I think the
> foundation is largely sound.  Teasing out the right answers from various
> specs and putting them together into a technical solution takes a bit of
> skill, I think, but also is a lot of fun.
> >>>>
> >>>> Every company has to make their bets, but Im not sure what
> alternatives you'd look at.  There's many opportunities to make bad bets in
> this area.  Do you have any particular concerns?
> >>>>
> >>>> Great to have you participating, I'd love over time to try and test
> interoperability (especially if you've selected javascript for a language).
> >>>>
> >>>>>
> >>>>>
> >>>>> -- Christopher Allen
> >>>>>
> >>>>
> >>>
> >
>
Received on Tuesday, 5 April 2016 17:34:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:07:46 UTC