Re: Interledger Architecture: OWPS architecture

> I cant think why webfinger would be used for discovery, rather than,
linked data + JSON LD.

I'm very interested in other/better discovery mechanisms. But I don't know
what would be different or what the benefits would be of a JSON-LD based
alternative. JSON-LD is a way to annotate JSON objects such that each
property has a globally unique meaning. If anyone puts forward a rough
sketch and a prototype, then we have something we can compare to the spec
we have for Webfinger and the implementation on red.ilpdemo.org.

Simplicity is an important design goal for Interledger, perhaps the most
important. Security, interoperability, utility all derive from the
simplicity. It is very easy to add complexity, very hard to contain it.
That said, if anyone proposes any change that has a good ratio between
benefit and added complexity, or one that reduces complexity, this group
should always be open to it.


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

I don't think we are (or should be) dogmatic about a technology stack.
We're at the W3C because a lot of web technologies make sense for us to
build on, not the other way around.

The reason we are taking so many ideas from Internet and web technologies
is because they are one of the very few things that have ever managed to
reach (and connect) the feature phone in Africa with the board room in
Chicago.

Everyone, from individuals to the largest companies use and rely on - even
for mission-critical tasks - the Internet.

I think a protocol based on ISO 20022 makes a lot of sense on the
Interledger application layer. Users like corporates and banks who are
familiar with ISO 20022 can use it without learning anything about the
internals of Interledger, and with making minimal changes to their
processes. For the lower layer protocols though, Interledger works very
differently and the large number of modifications to ISO 20022 just
wouldn't be worth it imho. Sometimes it's easier to start from a clean
slate.

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

>
>
> On 25 March 2016 at 00:11, Roger Bass <roger@traxiant.com> wrote:
>
>> 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.
>>
>
> Thanks for the data.  I just thought it was high as world assets are about
> 200T.  Interesting stuff.
>
>
>>
>> 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?
>>
>
> OK.  Well JSON LD was designed to be completely extensible to any data,
> and therefore, any use case (that can be handled on the web).  It's used on
> millions of sites (according to google), and so I have adopted it for my
> code, and I think it will provide an edge with interop, and a network
> effect.  My hope actually is that webfinger next version will adopt JSON LD.
>
>
>>
>> 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
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>