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: Melvin Carvalho <melvincarvalho@gmail.com>
Date: Tue, 5 Apr 2016 02:45:49 +0200
Message-ID: <CAKaEYhJv0hEQ7gt=WJtNDueQ6PMPS5HncJ1gPkCPZWzu10gStA@mail.gmail.com>
To: Joseph Potvin <jpotvin@opman.ca>
Cc: Web Payments CG <public-webpayments@w3.org>
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
>>>>>
>>>>>
>>>>
>>>
>>
>
Received on Tuesday, 5 April 2016 00:46:19 UTC

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