Re: Interledger Architecture: OWPS architecture

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