Re: Interledger Architecture: OWPS architecture

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