Interledger Architecture: OWPS architecture

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

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