Re: Interledger Architecture: OWPS architecture

The $700 trillion B2B number is from McKinsey (in PDF here, page 24
<http://www.mckinsey.com/industries/financial-services/our-insights/global-payments-2015-a-healthy-industry-confronts-disruption>):
$550tn domestic, $155tn cross-border. Their corresponding C2C
(consumer-to-consumer) numbers are $110tn and $1tn. See the report for
industry revenues on those figures. It's unclear, btw, if / how they're
counting C2B and B2C.

In other words, if the focus is on cross-border payments as the key initial
use case for ILP / crypto-currency payments, then it is, in volume terms at
least, 99.7% about B2B payments versus C2C (again - I'm unclear on
B2C/C2B). In revenue terms, it's less overwhelming: "just" 79% of industry
revenue is from B2B.

I don't want to get into a debate on JSON LD - I don't think the things
we're talking about are apples-to-apples comparable... and I risk making a
fool of myself, if I haven't already :-)  Useful as that standard seems to
be, I think a global, federated payee discovery model will require rather
more than this. My broader question about extensibility is: to what? What
use cases are to be supported, and what other frameworks or protocols have
what traction in addressing those use cases, at which layers of the stack?

Nor do I want to dismiss the value of lighter weight protocols - the whole
REST vs WS-* battle is evidence enough of that. But given the
overwhelmingly B2B driven context of cross-border payments, it seems to me
there may be reason to consider other frameworks, notably ebXML, that
encapsulate over a decade of thinking about the full stack of standards
needed to solve this type of problem.

But it may also be that this is just something to revisit at some point in
future, with the focus for now staying on the more narrowly defined scope.



On Thu, Mar 24, 2016 at 3:28 PM, Melvin Carvalho <melvincarvalho@gmail.com>
wrote:

>
>
> On 24 March 2016 at 22:02, Roger Bass <roger@traxiant.com> wrote:
>
>> The short answer: extensibility.
>>
>
> Which W3C standards have baked in.  JSON LD was designed to be
> extensible.  It's really hard to extend webfinger in the same way.
>
>
>>
>> Notably in a B2B relationship context (which are $700trillion globally,
>>
>
> $700 trillion?  That number seems too high an estimate.
>
>
>> so not small - indeed, much larger than consumer payments), payments are
>> one transaction among many others. Payments are tightly coupled to
>> invoices, of course... but invoices link to orders, which link to catalogs
>> etc etc. So either the payment interaction is a completely special case,
>> with its own protocol stack. Or, it aligns with - and potentially even
>> helps to bootstrap the setup of - a communications channel which can handle
>> those other transactional interactions as well. Needless to say, I'm
>> personally quite bullish about the latter scenario.
>>
>> More specifically, there's a fairly mature stack of standards for this,
>> based on work dating back over 15 years, under the ebXML
>> <http://t.signauxdeux.com/e1t/c/5/f18dQhb0SmZ58dDMPbW2n0x6l2B9nMJW7sM9dn7dK_MMdBzM2-04?t=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FEbXML&si=6060383291310080&pi=59556d3e-b6fe-4a42-a10f-fb403220779a>
>> banner, maintained at OASIS (although the "XML" part is something of a
>> misnomer for some layers). Some layers are more mature and widely used than
>> others (and some fairly new), but they include: Messaging (secure,
>> reliable, multi-hop - ebMS 3.0 and its profile AS4), Collaboration Profile
>> Protocol and Agreement (CPPA
>> <http://t.signauxdeux.com/e1t/c/5/f18dQhb0SmZ58dDMPbW2n0x6l2B9nMJW7sM9dn7dK_MMdBzM2-04?t=https%3A%2F%2Fwww.oasis-open.org%2Fcommittees%2Ftc_home.php%3Fwg_abbrev%3Debxml-cppa&si=6060383291310080&pi=59556d3e-b6fe-4a42-a10f-fb403220779a>),
>> including some newer work on negotiation / handshakes - and Discovery, as I
>> mentioned.
>>
>
> Yes, but the W3C stack also has significant maturity in terms of
> discovery.  And a lot of pain points have been worked through over the past
> 15 years.  Webfinger was a poor man's attempt to reinvent JSON LD and web
> discovery via follow your nose.  By all accounts people have struggled with
> it and adoption is falling.  It also misses several vital points, such as
> it doesnt allow numbers in its bespoke JSON serialization, which the W3C
> stack does, and this may be relevant to payments.
>
>
>>
>> Even within the payments context, this could have significant
>> implications. For example, one path to faster adoption of ILP-based
>> payments might be if, rather than requiring a bilateral agreement upfront,
>> ILP settlement was offered as one among several options for "depositing" or
>> settling a payment (less familiar, but obviously faster and lower cost). A
>> next gen check, if you will.
>>
>> Of course, I realize I'm potentially opening something of a Pandora's Box
>> here, and adding complexity. There's lots to be said for simple, focused
>> specifications that achieve a narrow goal efficiently. That said, talking
>> about an "Internet of Value" (or of Payments) does imply a certain ambition
>> to be universal. And in the broader context of global business as well as
>> consumer payments, if that is indeed the goal, it has certain implications.
>>
>> Roger
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Thu, Mar 24, 2016 at 12:57 PM, Melvin Carvalho <
>> melvincarvalho@gmail.com> wrote:
>>
>>>
>>>
>>> On 24 March 2016 at 20:42, Roger Bass <roger@traxiant.com> wrote:
>>>
>>>> Melvin et al,
>>>>
>>>> I know we're operating as a W3C Community Group, but the implications
>>>> and applications of ILP clearly go beyond W3C's "web platform" scope (viz:
>>>> proposed IETF submission of ILP, crypto conditions etc).
>>>>
>>>> That being so, I don't see why we would want to restrict ourselves to
>>>> consideration of W3C standards. I linked below to one OASIS work product,
>>>> which may or may not be a good option. Doubtless there are other candidates
>>>> - you might care to name some. Again, I suspect there may be simplicity vs
>>>> extensibility trade-offs here. I'm not sure if it's easier to discuss those
>>>> in the context of specific proposed alternatives - or to have a
>>>> conversation upfront about scope and goals (see also Evan's email on
>>>> another thread re naming).
>>>>
>>>
>>> I agree with this comment, there's no necessity to restrict scope.
>>>
>>> But why would you *not* want to use a w3c standard here, which solves
>>> the same problem, in a standards compliant way?
>>>
>>>
>>>>
>>>> Roger
>>>>
>>>>
>>>>
>>>>
>>>> On Thu, Mar 24, 2016 at 11:18 AM, Melvin Carvalho <
>>>> melvincarvalho@gmail.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> On 24 March 2016 at 18:06, Roger Bass <roger@traxiant.com> wrote:
>>>>>
>>>>>> Stefan,
>>>>>>
>>>>>> Kudos again to you, Evan and the team on the architecture doc - a
>>>>>> great start.
>>>>>>
>>>>>> The payments layer piece is a really interesting addition, even
>>>>>> though it's obviously quite early. I had a couple of comments on the
>>>>>> architectural content, as a prelude to some thoughts on perhaps renaming
>>>>>> it, as you were suggesting. I'll put those in a separate email, for easier
>>>>>> readability.
>>>>>>
>>>>>> Firstly, it seems to me there may be a trade-off here between
>>>>>> maintaining simplicity, focusing on a narrow payment use case, and
>>>>>> extensibility - both to a wider variety of payments use cases, and perhaps
>>>>>> even to other transactional interactions between payer and payee (e.g. in a
>>>>>> B2B context). The more important that extensibility seems to be, the
>>>>>> stronger the case for leveraging standards frameworks that have already
>>>>>> been built (and deployed) elsewhere. Perhaps we should clarify what the
>>>>>> goal is with this Architecture document? More specifically...
>>>>>>
>>>>>> 1. Discovery. Webfinger, although it uses a URI, seems more focused
>>>>>> on converting a (payee) email address. (And despite the name, doesn't
>>>>>> really seem like a Web protocol). That seems potentially problematic for
>>>>>> payments to organizations in particular. There's an IETF RFC specified
>>>>>> framework for federated directory / discovery applications on top of DNS:
>>>>>> DDDS
>>>>>> <https://en.wikipedia.org/wiki/Dynamic_Delegation_Discovery_System>.
>>>>>> There's also been some work on using this for discovery of organizations /
>>>>>> entities, and Metadata Services that describe transaction endpoints for
>>>>>> them (OASIS doc linked here
>>>>>> <http://docs.oasis-open.org/bdxr/BDX-Location/v1.0/cs01/BDX-Location-v1.0-cs01.html>),
>>>>>> a generalization of a model that's live in a pan-European government
>>>>>> procurement system, PEPPOL. It seems to me that an Interledger / Payments
>>>>>> Discovery model needs to explicitly address the federation of existing
>>>>>> payee directories, based on a range of potential identifiers (email,
>>>>>> cellphone, domain, organizational ids etc).
>>>>>>
>>>>>
>>>>> Good spot.
>>>>>
>>>>> I cant think why webfinger would be used for discovery, rather than,
>>>>> linked data + JSON LD.
>>>>>
>>>>> Certainly I would want to replace that portion of the arch with a
>>>>> version that uses w3c standards.
>>>>>
>>>>>
>>>>>>
>>>>>> 2. Query. The notion of routing payments to a *receiver* which may be
>>>>>> an invoice rather than a payee is interesting. However, it's unclear how
>>>>>> well this lines up with real world processes, especially B2B, where a
>>>>>> single payment is associated with remittance detail for applying that
>>>>>> payment to multiple invoices, sometimes with deductions or other
>>>>>> adjustments.
>>>>>>
>>>>>> Roger
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>