Re: Interledger Architecture: OWPS architecture

On 25 March 2016 at 02:49, Stefan Thomas <stefan@ripple.com> wrote:

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

Will try and put together a demo as time allows.


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

Simplicity is subjective.  And we have no real data to back up those
opinions, normally just anecdotes.  So in essence development is being
based on subjective opinion, rather than, technical merit.  That's
certainly one way to do things, but to become a standard you generally want
: interoperability, scalability, resilience and stability.  These are the
principles on which W3C standards are designed.

For me the network effect is the primary goal in a financial system as it
offers a competitive advantage.  Simplicity is one way to increase the
network effect, but the problem is that it's essentially a meaningless
term.  Id rather stick to technical arguments such as the implementation
problems that people that have created webfinger based systems have
reported.  I guess this is going to be a learning experience and more will
be found out over time.

red.ilpdemo.org doesnt load for me.  I am hoping to put together my own
demo, and I suppose a good test will be what is capable of interoperating
with what.  I seriously doubt webfinger is capable of interop with anything
other that itself, and that JSON LD can interop with heterogeneous systems,
but we will find out more over time.


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