Re: Interledger Architecture: OWPS architecture

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

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