Re: Interledger Architecture: OWPS architecture

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