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

RE: "you can have an internet without the web, but it wouldnt be much of an
internet"

Great topic for a pub discussion ;-)    The pre-Web Internet was pretty
cool, actually. Bulletin boards. The early "network of networks" to trade
data amongst distributed Dbs.

Anyone who is blind today works online by de-Webifying the info they get
and produce. If a full-featured digital payments system can be created for
blind end-users today, then it can also be created independently of the
Web. Placing some elements into the Web layer may be desireable, but this
is not essential for those of us who are "payments-centric". Of course, if
your perspective is "Web-centric", then I would agree that getting it all
into Web specs is essential.

Joseph Potvin

On Tue, Apr 5, 2016 at 3:53 AM, Melvin Carvalho <melvincarvalho@gmail.com>
wrote:

>
>
> On 5 April 2016 at 03:34, Joseph Potvin <jpotvin@opman.ca> wrote:
>
>> RE: "So which of these four can't be modeled using web standards?  Or are
>> you saying we can use the web as a core and then bootstrap existing
>> methodologies?
>>
>> One set of things I am saying is:
>> (a) It is possible to have the Internet without the Web, but not the Web
>> without the Internet.
>>
>
> This is a source of confusion.  Firstly, you can have an internet without
> the web, but it wouldnt be much of an internet.  What is referred to as "on
> the web" in design issues is actually beyond HTTP.  It is anything with a
> URI.  So it could be http: xmpp: mailto: tel: bitcoin: -- anything that
> can be named.  This is really a first class definition for standards folks,
> but it's not universally appreciated, so sometimes there's communication
> issues.
>
>
>> (b) It is possible to have fully-functional and reasonably secure global
>> digital payments without the Web, but not without the Internet.
>>
>
> Nominally yes.  Let me try and unpack this.  Firstly, I dont really like
> the use of the word 'secure' getting shoehorned into tag lines.  Nothing is
> truly 100% secure.  It's a continuum.  Security has a dual purpose acting
> on the one hand to protect users in certain scenarios, and on the other by
> dogmatists at a barrier to entry to prevent the long tail from creating
> diverse solutions.
>
> Secondly, payments efficacy and the network effect are strongly
> correlated.  Related to above security and the network effect are inversely
> correlated.  The greatest network effect that we know is the web, and when
> you extend the web to be any URI it becomes unassailable.  Therefore, to
> have a meaningful global (I like this word!) payments network I would say
> that you need the web.
>
> Once again the premise here is to use URIs to name things.
>
>
>> (c) The Web makes many aspects of digital payments far more user-friendly.
>>
>
> Perhaps.  But we're interested in delivery to a wide audience and the
> network effect.  Delivery to a browser is arguably convenient, but well, we
> are really at a point where the web would benefit from more browser
> diversity, so it's a double edged sword.
>
>
>>
>> If some of what community members have wanted to include in Web standards
>> are to be excluded (for the time being), then to the extent feasible and
>> coherent, pursue those elements via some other standards-building pathway.
>>
>
> Part of the reason the web is a great platform for the network effect is
> because when you use URIs to name things, you can integrate anything.  Much
> in the same way that linux can write drivers for most meaningful hardware.
> Some stuff is plug and play, some things drivers are needed for.  We've not
> yet done the work for all of those drivers, and that will need to be
> prioritized on how useful those things are, as we have limited resources.
>
> To summarize.  Web standards are about growing the a large network via
> integration and naming things with URIs.  This aligns really well with
> payments use cases.  We've not built out all the use cases or done all the
> integrations yet, but largely the base line tools needed are there.  We
> just need to work out which bits we focus on first.
>
>
>>
>> Joseph Potvin
>> Operations Manager | Gestionnaire des opérations
>> The Opman Company | La compagnie Opman
>> jpotvin@opman.ca
>> Mobile: 819-593-5983
>> LinkedIn <https://www.linkedin.com/pub/joseph-potvin/2/148/423>
>>
>> On Mon, Apr 4, 2016 at 8:45 PM, Melvin Carvalho <melvincarvalho@gmail.com
>> > wrote:
>>
>>>
>>>
>>> On 5 April 2016 at 00:35, Joseph Potvin <jpotvin@opman.ca> wrote:
>>>
>>>> RE: "What do you by mean "some but not all"? My take is that the web is
>>>> ideal for all, we just need to write the code."
>>>>
>>>> Here are four examples prominent in my own primary work (which is
>>>> https://www.xalgorithms.org/ ). Other linkages will be key, for other
>>>> initiatives and contexts.
>>>>
>>>> 1. Many pre-payment and post-payment data req's are effectively
>>>> addressed by OASIS UBL http://ubl.xml.org/
>>>>
>>>> 2. The protocols required for moving around core messages and much of
>>>> the info 'baggage' attached to payments are defined by the IETF. (For
>>>> example, SWIFT's "value added" service functionality is at the Internet
>>>> layer, not the Web layer.)
>>>>
>>>> 3. To some extent US Federal Reserve System functions as a
>>>> quasi-standards body. The criteria that have been negotiated in the Faster
>>>> Payments Task Force (though an astonishingly open and collaborative
>>>> process) provides a good example for how this can work when it works well.
>>>> https://fedpaymentsimprovement.org/faster-payments/task-force/criteria/
>>>>
>>>> 4. UNCITRAL WG IV on e-Commerce is working on advancing the legal
>>>> foundations of "electronic transferable records"
>>>>
>>>> http://www.uncitral.org/uncitral/en/commission/working_groups/4Electronic_Commerce.html
>>>> If you look below the legalese (i.e. reflect upon Lessig's "code is
>>>> law"), and find a way to embrace the "weight" that comes with having a more
>>>> truly global representation than most IT standards bodies ever muster,
>>>> there's some extremely useful and timely work going on there.
>>>>
>>>
>>> So which of these four cant be modeled using web standards?  Or are you
>>> saying we can use the web as a core and then bootstrap existing
>>> methodologies?  The second way is very much part of the web paradigm, where
>>> the web works best as an integration platform.  Reuse is normally a good
>>> thing, but web standards encourage reuse already.
>>>
>>>
>>>>
>>>> Joseph Potvin
>>>> Operations Manager | Gestionnaire des opérations
>>>> The Opman Company | La compagnie Opman
>>>> jpotvin@opman.ca
>>>> Mobile: 819-593-5983
>>>> LinkedIn <https://www.linkedin.com/pub/joseph-potvin/2/148/423>
>>>>
>>>> On Mon, Apr 4, 2016 at 5:53 PM, Melvin Carvalho <
>>>> melvincarvalho@gmail.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> On 4 April 2016 at 23:26, 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.
>>>>>>
>>>>>
>>>>> What do you by mean "some but not all"?
>>>>>
>>>>> My take is that the web is ideal for all, we just need to write the
>>>>> code.
>>>>>
>>>>> Other specs in this space are nowhere close, especially when it comes
>>>>> to decentralized identity, imho.
>>>>>
>>>>>
>>>>>> 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 <E.R.Fekkes@rn.rabobank.nl>, Web
>>>>>> Payments CG <public-webpayments@w3.org <public-webpayments@w3.org>>, Web
>>>>>> Payments IG <public-webpayments-ig@w3.org <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
>>>>>> <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
>>>>>> <http://www.w3.org/2004/05/W3C-OMA-Agreement-FINAL.html>W3C & VoiceXML
>>>>>> Forum http://www.w3.org/2001/10/MOU.txt
>>>>>> <http://www.w3.org/2001/10/MOU.txt>Here also are some non-W3C examples:*
>>>>>> IEC, ISO, ITU &
>>>>>> UN/ECEhttp://www.itu.int/en/ITU-T/ebusiness/Pages/mou/MoUMG-members.aspx
>>>>>> <http://www.itu.int/en/ITU-T/ebusiness/Pages/mou/MoUMG-members.aspx>* ISO &
>>>>>> IEChttp://www.iso.org/iso/jtc1_home.html
>>>>>> <http://www.iso.org/iso/jtc1_home.html>* IETF &
>>>>>> ITUhttp://tools.ietf.org/html/rfc6756 <http://tools.ietf.org/html/rfc6756>*
>>>>>> IETF & IEEE 802 http://tools.ietf.org/html/draft-iab-rfc4441rev-08
>>>>>> <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
>>>>>> <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/
>>>>>> <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
>>>>>> <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 PotvinOperations Manager | Gestionnaire des opérationsThe
>>>>>> Opman Company | La compagnie Opmanjpotvin@opman.ca
>>>>>> <jpotvin@opman.ca>Mobile: 819-593-5983 <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
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>