Re: A B2B application layer protocol for Interledger?

Adrian,

I imagine there will be various use case discussions going forward. To the
extent some people here are primarily focused on the lower protocol layers,
having a new list focused on use cases seems a fine idea (provided
subscribing - and unsubscribing - is straightforward). It's unclear to me
how much momentum or interest we have at this point in the B2B use case,
specifically for something that's actually actionable now. I do have some
thoughts on how initial scope for that might be narrowed, which I hope to
share on this list shortly. If and when a new list is created, we can move
such discussions over to that.

Whether it's here or on a new list, your suggestion re adding [b2b] or
similar tags to subject lines could be helpful anyhow. I guess we should
have some kind of threshold that new topics or use cases should meet before
proliferating them into a new email list. If it's unclear whether a topic
meets that threshold, then maybe discussions could start via a tag, and
migrate to a list as email volumes over some period of time demonstrate the
need?

Best,
Roger








On Tue, Mar 29, 2016 at 2:57 AM, Adrian Hope-Bailie <adrian@hopebailie.com>
wrote:

> Roger, Joseph,
>
> I think it would be a shame to take this discussion off the public list as
> the B2B use cases are most certainly relevant to the group. SkuChain have
> been active group participants and as Zaki says are pretty committed to
> bringing ILP to the B2B use cases.
>
> I think we will find the discussions here begin to become either focused
> on the core ILP technology or the more use case specific application layer
> technologies.
>
> There are two ways we can segment these discussions to a) ensure there is
> a forum for everyone to discuss what is important to them and b) not create
> so much noise that contributors find it a distraction:
>
> 1. We can create a separate list for use case specific discussion,
> something like public-interledger-usecases@w3.org
> 2. We can try to use subject line filters to assist folk to filter out
> threads they aren't interested in example, start subject s with "[use
> cases]" or "[b2b]" or similar.
>
> I'd favour option 1 as it's a pretty trivial thing to setup and then
> allows that list to even frther segment their threads based on specific use
> cases using subject line filters.
>
> What would be everyone's preference?
>
>
>
> On 28 March 2016 at 22:08, Joseph Potvin <jpotvin@opman.ca> wrote:
>
>> RE: "not comparing apples and apples in talking about..." & "this
>> discussion is perhaps getting increasingly arcane, and even off-topic"
>>
>> Agreed. :-)  I was just providing some background to the breadth of
>> applied-UBL activity, since it takes some poking around to sift out and
>> make sense of it. I almost changed the subject line to "UBL [WAS: A B2B
>> application layer...]"
>>
>> Happy to discuss details off-list jpotvin@xalgorithms.org
>>
>> Joseph Potvin
>> Executive Director, Xalgorithms Foundation
>> Mobile: 819-593-5983
>> jpotvin@xalgorithms.org
>> https://www.xalgorithms.org
>> <http://t.sidekickopen06.com/e1t/c/5/f18dQhb0S7lC8dDMPbW2n0x6l2B9nMJN7t5XYgdDM1sVRYyfn4XXSbTVd0r_-56dVbMd4C5Ts02?t=https%3A%2F%2Fwww.xalgorithms.org%2F&si=6060383291310080&pi=5f61f02f-9a2c-4b9a-c45f-c6fbd72f85bf>
>>
>> On Mon, Mar 28, 2016 at 4:56 PM, Roger Bass <roger@traxiant.com> wrote:
>>
>>> Joseph et al,
>>>
>>> Lichen and Xalgorithms sound like interesting efforts. UBL is a
>>> perfectly reasonable choice as a canonical data format, or wire format, I'd
>>> agree. But you're simply not comparing apples and apples in talking about
>>> other layers of the protocol stack, about proprietary solutions like
>>> Tradeshift (who I know well), or about semi-proprietary implementations
>>> like PEPPOL (which btw, invented its own much more proprietary protocols
>>> for various layers of the stack addressed by ebXML: I bet you've never even
>>> heard of START/LIME). Not to get into it here, but there's also less than
>>> meets the eye to the OpenPEPPOL effort in my view (see OASIS BDX/BDXR, in
>>> which I was also quite involved).
>>>
>>> I think there are some more fundamental business network dynamics at
>>> work as regards how interoperability standards evolve and get adopted at
>>> different layers of the stack, i.e. data vs others. Secure, reliable
>>> messaging in particular, for example, is one that's a general need and
>>> where convergence has happened slowly, but is more or less now there.
>>>
>>> Anyhow, this discussion is perhaps getting increasingly arcane, and even
>>> off-topic from the perspective of the Interledger group, I rather suspect.
>>>
>>> Per the IETF credo, "rough consensus and running code" seems to be the
>>> way to go - with a continuing focus on the simpler, consumer payment OWPS
>>> use case to start with. Religious debates on B2B, or anything else, seem
>>> less than constructive. If any of us have specific proposals around focused
>>> B2B use cases, maybe this discussion gets interesting again.
>>>
>>> Roger
>>>
>>>
>>> On Mon, Mar 28, 2016 at 1:35 PM, Joseph Potvin <jpotvin@opman.ca> wrote:
>>>
>>>> RE: "ebXML looks like it would add a ton of complexity"
>>>>
>>>> Agreed. It's not the way to go. And there's been almost no activity in
>>>> ebXML itself since around 2008.
>>>>
>>>> On the other hand, it's more elegant offspring UBL has flourished.
>>>>
>>>> UBL in N. America is Industry-led (in B2B frieght, mainly)
>>>> — US: e-Invoice-based Freight Payment
>>>> http://eeiplatform.com/14904/us-bank-launches-e-invoice-based-freight-payment-trade-finance-service/
>>>> — Electronic Freight Management Overview
>>>> http://ops.fhwa.dot.gov/Freight/intermodal/efmi/electronic.pdf
>>>> — e-Invoicing is at the center of the treasury & trade convergence
>>>> http://www.swift.com/resources/documents/SOFA_2012_eInvoicing_Fast_Evolving_Landscape_02_Mar_2012.pdf
>>>>
>>>> There are several UBL implentations based in Europe -- mostly oriented
>>>> to govermentment procurment use cases. This is because UBL is now (or is
>>>> soon becoming) mandatory for public sector procurement invoicing in most
>>>> European countries.
>>>>
>>>> There was a government-sponsored pilot (now ended) called PEPPOL. It
>>>> lives on as OpenPEPPOL, an "open" government+commercial platform (i.e. the
>>>> continuation of PEPPOL) ... though it's not clear to me yet how genuinely
>>>> free/libre/open source it really is.
>>>> http://www.peppol.eu/about_peppol/about-openpeppol-1
>>>>
>>>> http://www.peppol.eu/news/new-open-source-implementations-for-the-peppol-network
>>>>
>>>> One of the European implementations of UBL, "NemHandel" (Denmark) is a
>>>> government-run project. Buy several of NemHandel's core developers left
>>>> home and set up the company "Tradeshift" in California
>>>> http://www.forbes.com/sites/tomgroenfeldt/2014/12/23/tradeshift-a-supply-chain-model-that-takes-after-linkedin/
>>>>
>>>> Tradeshift is restricted software on a SaaS model, with an open API)
>>>> http://tradeshift.com/ http://integrate.tradeshift.com/
>>>> Onboarding Users to Tradeshift
>>>> http://eeiplatform.com/15769/tradeshift-and-the-art-of-supplier-on-boarding/
>>>>
>>>> "Interview with Tradeshift’s CEO Christian Lanng":
>>>> http://www.computerworlduk.com/news/public-sector/3436545/tradeshift-ceo-uk-government-could-save-852m-moving-to-open-e-invoicing/
>>>>
>>>>    -         http://www.programmableweb.com/api/tradeshift
>>>>    -         https://github.com/Tradeshift/tradeshift-api-client
>>>>    -         Python-based API to Tradeshift
>>>>    http://www.cranesoftwrights.com/resources/ubl/index.htm#tspython
>>>>    -         https://github.com/Tradeshift/Tradeshift-Apps
>>>>    -         https://github.com/Tradeshift/Tradeshift-AppDeveloper
>>>>    -         https://github.com/Tradeshift/Tradeshift-Java-Client
>>>>    -         https://github.com/Tradeshift/tradeshift-ubl-xsd
>>>>
>>>> The particular niche that Xalgorithms Foundation is pursuing with
>>>> Lichen & with the Xalgorithms Federated Registry is to simplify and make
>>>> much more efficient the availability of computational algorithms that are
>>>> needed to accomplish a complete transaction. It is our view the scope of
>>>> improved "payment" includes all essential elements including taxes,
>>>> exemptions, credits, cross-border duties, point system adjustments, just as
>>>> the scope of "a complete trip" by aircraft includes the passenger's
>>>> baggage.
>>>>
>>>> Lichen uses UBL an e-commere data 'Rosetta Stone'.
>>>>
>>>> Joseph Potvin
>>>> Executive Director, Xalgorithms Foundation
>>>> Mobile: 819-593-5983
>>>> jpotvin@xalgorithms.org
>>>> https://www.xalgorithms.org
>>>> <http://t.sidekickopen06.com/e1t/c/5/f18dQhb0S7lC8dDMPbW2n0x6l2B9nMJN7t5XYgdDM1sVRYyfn4XXSbTVd0r_-56dVbMd4C5Ts02?t=https%3A%2F%2Fwww.xalgorithms.org%2F&si=6060383291310080&pi=5f61f02f-9a2c-4b9a-c45f-c6fbd72f85bf>
>>>>
>>>> On Mon, Mar 28, 2016 at 3:58 PM, Jehan Tremback <
>>>> jehan.tremback@gmail.com> wrote:
>>>>
>>>>> ebXML looks like it would add a ton of complexity.
>>>>>
>>>>> On Mon, Mar 28, 2016 at 12:39 PM, Joseph Potvin <jpotvin@opman.ca>
>>>>> wrote:
>>>>>
>>>>>> Lichen is being structured as a full reference implementation of UBL.
>>>>>> Most UBL implememtations cherry-pick according to context. Cherry-picking
>>>>>> can be done in a UBL standard conformant way. With Lichen Xalgorithms, we
>>>>>> don't assume a context any more specific than "commerce".
>>>>>>
>>>>>> UBL is derived from ebXML / EDI, but is much reduced in complexity.
>>>>>> But it accommodates a great divesity of use cases and specialize
>>>>>> requirements. And it has some fields that accommodate semantic flexibility,
>>>>>> with the result that to some degree extensions can be in the sematics
>>>>>> rather than in the data structure per se.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Joseph Potvin
>>>>>> Operations Manager | Gestionnaire des opérations
>>>>>> The Opman Company | La compagnie Opman
>>>>>> jpotvin@opman.ca
>>>>>> Mobile: 819-593-5983
>>>>>> LinkedIn
>>>>>> <http://t.sidekickopen06.com/e1t/c/5/f18dQhb0S7lC8dDMPbW2n0x6l2B9nMJN7t5XYgdDM1sVRYyfn4XXSbTVd0r_-56dVbMd4C5Ts02?t=https%3A%2F%2Fwww.linkedin.com%2Fpub%2Fjoseph-potvin%2F2%2F148%2F423&si=6060383291310080&pi=5f61f02f-9a2c-4b9a-c45f-c6fbd72f85bf>
>>>>>>
>>>>>> On Mon, Mar 28, 2016 at 3:15 PM, Roger Bass <roger@traxiant.com>
>>>>>> wrote:
>>>>>>
>>>>>>> You were suggesting, Adrian, that the scope of any such B2B effort
>>>>>>> might be quite large. That may be so - in which case, it probably would be
>>>>>>> premature to work on it (as you also suspect: Adrian, Zaki).
>>>>>>>
>>>>>>> That said, to the extent that the ebXML stack as well is written in
>>>>>>> a layered way, and is reasonably mature, it may be that the relevant scope
>>>>>>> could be limited to the definition of bindings between the relevant
>>>>>>> protocol layers. I'm looping in some of the folks more expert on this than
>>>>>>> I am to discuss this. Such an effort might also seem more worthwhile if the
>>>>>>> scope were narrowed to focus on a more specific use case. One possible
>>>>>>> scenario relates to a (B2B-oriented) payer-to-payee message that could be
>>>>>>> "settled" via multiple alternate networks (card, ACH... and perhaps ILP) -
>>>>>>> a check alternative, if you will. (The message itself would be an ISO 20022
>>>>>>> message, though there would likely some other protocol pieces involved).
>>>>>>> From my perspective at least, it may be that interest in the non-ILP
>>>>>>> scenarios are more critical to determining if this moves forward. But if it
>>>>>>> does, defining ILP bindings for this could become quite interesting.
>>>>>>>
>>>>>>> Roger
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Mar 28, 2016 at 12:00 PM, Adrian Hope-Bailie <
>>>>>>> adrian@hopebailie.com> wrote:
>>>>>>>
>>>>>>>> > My sense is that is premature to try to standardize now but I
>>>>>>>> think experience reports will be very valuable from those who can share
>>>>>>>> them.
>>>>>>>>
>>>>>>>> +1 - that's why we're working on a very simple application layer
>>>>>>>> protocol to start with and not trying to incorporate any baggage from other
>>>>>>>> standards or frameworks yet.
>>>>>>>>
>>>>>>>> As the core ILP foundation solidifies the direction to take with
>>>>>>>> higher level functions will become clearer. It's quite possible that some
>>>>>>>> of the early application layer protocols may even disappear as the stack
>>>>>>>> matures. Anyone remember Gopher :)
>>>>>>>>
>>>>>>>> On 28 March 2016 at 16:38, zaki@manian.org <zaki@manian.org> wrote:
>>>>>>>>
>>>>>>>>> Skuchain is pretty committed to bring Interledger to B2B use cases
>>>>>>>>> and preliminary indications are that  ISO20022 might be the way
>>>>>>>>> to go.
>>>>>>>>>
>>>>>>>>> My sense is that is premature to try to standardize now but I
>>>>>>>>> think experience reports will be very valuable from those who can share
>>>>>>>>> them.
>>>>>>>>>
>>>>>>>>> On Mon, Mar 28, 2016 at 8:04 AM, Joseph Potvin <jpotvin@opman.ca>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> RE: "the Interledger architecture is layered... there is scope
>>>>>>>>>> for a more complex and rich application layer protocol that is more
>>>>>>>>>> targeted at "enterprise" use cases"
>>>>>>>>>>
>>>>>>>>>> +1
>>>>>>>>>>
>>>>>>>>>> RE; "to begin developing another application layer protocol that
>>>>>>>>>> is focused on B2B and leverages existing standards like ebXML. ISO20022 or
>>>>>>>>>> UBL then that would be great:
>>>>>>>>>>
>>>>>>>>>> In part, like this?
>>>>>>>>>> https://github.com/Xalgorithms/xa-arch/blob/master/README.md
>>>>>>>>>> https://www.xalgorithms.org/
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> RE: It is a far larger task than the current group could take on
>>>>>>>>>> but I'd certainly support it and try to get involved as time allows.
>>>>>>>>>>
>>>>>>>>>> Xalgorithms Foundation (XF) has not yet been reaching out much.
>>>>>>>>>> An initial group is doing some grunt work to determine which specific
>>>>>>>>>> functions we'll target and how, and which parts are for others to do. i.e.
>>>>>>>>>> Which the internal functions of OSI Layer 7 can we enhance with the our two
>>>>>>>>>> contributions?)  Our scope is much narrower than you described for Layer 7
>>>>>>>>>> work, only some component parts. Some structure for our work is now getting
>>>>>>>>>> posted to Github. We haven't yet got much of any use for anyone to
>>>>>>>>>> download. At present we're creating a limited working proof-of-concept.
>>>>>>>>>> There's also a fully-scalable free/libre/open pathway in planning.
>>>>>>>>>>
>>>>>>>>>> Starting on 6 April at 2:30 EST, XF will be hosting an
>>>>>>>>>> open-to-anyone 30 min "Xalgorithms Tech Weekly Forum" on Google Hangout.
>>>>>>>>>> I'll share details shortly.
>>>>>>>>>>
>>>>>>>>>> Anyone with specific enquiries (which may be out-of-scope for
>>>>>>>>>> this email list) can contact me directly via
>>>>>>>>>> jpotvin@xalgorithms.org
>>>>>>>>>>
>>>>>>>>>> Joseph Potvin
>>>>>>>>>> Executive Director, Xalgorithms Foundation
>>>>>>>>>> Mobile: 819-593-5983
>>>>>>>>>> jpotvin@xalgorithms.org
>>>>>>>>>> https://www.xalgorithms.org
>>>>>>>>>> <http://t.sidekickopen06.com/e1t/c/5/f18dQhb0S7lC8dDMPbW2n0x6l2B9nMJN7t5XYgdDM1sVRYyfn4XXSbTVd0r_-56dVbMd4C5Ts02?t=https%3A%2F%2Fwww.xalgorithms.org%2F&si=6060383291310080&pi=e92aa223-ebe7-4a9d-e849-f83c11b9920b>
>>>>>>>>>>
>>>>>>>>>> On Mon, Mar 28, 2016 at 6:13 AM, Adrian Hope-Bailie <
>>>>>>>>>> adrian@hopebailie.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> From the discussion around payment to invoices there appears to
>>>>>>>>>>> be a number of views that the current application layer protocol is not
>>>>>>>>>>> meeting the needs of all B2B use cases.
>>>>>>>>>>>
>>>>>>>>>>> Further, there is a suggestion that there are a number of
>>>>>>>>>>> existing protocols and standards that we should be leveraging.
>>>>>>>>>>>
>>>>>>>>>>> It's important to note that the Interledger architecture is
>>>>>>>>>>> layered, intentionally, to resemble something like the OSI model for
>>>>>>>>>>> communications protocols. At the lowest layers are very simple protocols
>>>>>>>>>>> that have a specific purpose but these build up to an application layer
>>>>>>>>>>> where it is possible to construct a number of application layer protocols
>>>>>>>>>>> that are built on the lower layer primitives and fit for a particular
>>>>>>>>>>> purpose.
>>>>>>>>>>>
>>>>>>>>>>> I'd compare these to communications stack protocols like HTTP
>>>>>>>>>>> and FTP. These two protocols are built on the same underlying IP-based
>>>>>>>>>>> stacks but were designed for very different purposes.
>>>>>>>>>>>
>>>>>>>>>>> Right now OWPS is intended to be a very simple application layer
>>>>>>>>>>> protocol primarily designed to handle P2P payments or very simple C2B
>>>>>>>>>>> payments (i.e. 1:1 payment to invoice). It has very specific design
>>>>>>>>>>> principles which may not be appropriate for a lot of use cases (such as
>>>>>>>>>>> being operatorless). This protocol may evolve but it's unlikely to ever be
>>>>>>>>>>> a rich protocol that incorporates comprehensive stacks like ISO20022 or
>>>>>>>>>>> ebXML.
>>>>>>>>>>>
>>>>>>>>>>> Rather than trying to turn OWPS into a protocol that can handle
>>>>>>>>>>> all use cases I'd suggest there is scope for a more complex and rich
>>>>>>>>>>> application layer protocol that is more targeted at "enterprise" use cases.
>>>>>>>>>>>
>>>>>>>>>>> If there is a willingness within this group to begin developing
>>>>>>>>>>> another application layer protocol that is focused on B2B and leverages
>>>>>>>>>>> existing standards like ebXML. ISO20022 or UBL then that would be great.
>>>>>>>>>>>
>>>>>>>>>>> It is a far larger task than the current group could take on but
>>>>>>>>>>> I'd certainly support it and try to get involved as time allows.
>>>>>>>>>>>
>>>>>>>>>>> Adrian
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>