Re: Interledger Architecture: OWPS architecture

The short answer: extensibility.

Notably in a B2B relationship context (which are $700trillion globally, 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.

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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>