Re: [apps-discuss] Proposal for a Finance Area Mailing List

[Walter <[e-mail]>]

> A separate but related question is whether "financial-protocol" folk need
> different underlying  protocols, for transport/transfer of this particular
> type of data and notifications, than what is extant (and implemented &
> shipping) today (e.g., HTTP, TLS/SSL, SCTP, XMPP, etc.).
>
> If not, then perhaps they might concentrate on the stuff at their
> "financial" layer and concoct "bindings" to the existing underlying stuff
> (eg, as we did in SAML & Liberty (to HTTP)) as appropriate, and they then
> could perhps more easily work on their "financial" layer whereever (eg, W3C,
> OASIS, SomeNew.org, etc).

I agree wholeheartedly with the suggestion of transport neutrality,
which I believe I raised earlier on this thread (possibly indirectly
through allusion to arbitrary topology support).  Each of the
transports mentioned above offers different properties in terms of at
least security, topology, wire-level efficiency and latency and for
this reason alone it would appear to be unwise to mandate one or more
possible transports for all deployment environments (whose
requirements will vary).

However, I am not certain that I can agree with the apparent(?) notion
presented that perhaps it then follows that the IETF is not an
appropriate venue for this development.

The rest of this email will address each of the previous efforts
raised by Dave and Jeff (thanks for taking the time to point these
out!) and summarize briefly why from my perspective they appear to
differ significantly from the proposed scope.

> The early EDI work produced a working group and a successor working group,
> participation and specifications:
>
> RFC6362, Multiple Attachments for Electronic Data Interchange - Internet
> Integration (EDIINT) K. Meadors, Ed.  August 2011  ASCII  INFORMATIONAL
>
> RFC6359, Datatracker Extensions to Include IANA and RFC Editor Processing
> Information S. Ginoza, M. Cotton, A. Morris  September 2011  ASCII
>  INFORMATIONAL
>
> RFC6017, Electronic Data Interchange - Internet Integration (EDIINT)
> Features Header Field
>
> RFC5402, Compressed Data within an Internet Electronic Data Interchange
> (EDI) Message T. Harding, E
>
> RFC1865, EDI Meets the Internet Frequently Asked Questions about Electronic
> Data Interchange (EDI) on the Internet W. Houser, J. Griffin, C. Hage
>  January 1996 ASCII  INFORMATIONAL
>
> RFC1767, MIME Encapsulation of EDI Objects D. Crocker

Scope is EDI.

Without passing judgement on any one of the various EDI standards that
are apparently floating about these days, my own perspective is that
at its core EDI tends to differ significantly in scope from the
proposed scope of financial transactions, largely because EDI's focus
appears to be on "big corporate" and government business level
metadata and processes (invoicing, purchase orders, etc...) that do
not necessarily apply to all or even most financial transactions on
the internet today, such as those involving individual consumers.

As a result of this key difference, EDI systems tend to prevent or
constrict the expression of possible financial settlement level
concerns, and have little motivation to accomodate or consider
alternative systems that may be based upon either non-currency value
exchange or non ISO4217 currency exchange such as Ripple, CES, LETS,
Bitcoin, etc. In short, from an EDI perspective, it would seem that
(in *most* cases?) the settlement of financial transactions is
essentially an external process.

In addition, documents like http://tools.ietf.org/html/rfc5402 delve
in to concerns such as security (authentication, integrity and
encryption) that an alternative protocol designed now (from a
message-oriented perspective) might well be able to delegate in whole
or in part to the transport layer.

The proposed scope could be seen to support EDI in that it could
potentially provide higher reliability, lower cost, transparently
redundant (supporting business continuity / disaster recovery goals),
or otherwise more attractive settlement functionality to complement
existing EDI systems.  In addition, EDI information could potentially
be bundled within financial transaction related messages in order to
provide both information relevant to settlements and higher level
metadata where appropriate.

> In addition to the previously mentioned EDI and IOTP work, there was also
> this back in the late 1990s..
>
> CyberCash Credit Card Protocol Version 0.8
> http://tools.ietf.org/html/rfc1898

Scope is basically credit cards. It is also interesting to note that,
apparently at the time of writing, their centralized registry of
message types exceeded 100 (getting rather messy... maybe the approach
was not high level enough to be portable to an internet sized
community, re: most of these were probably necessitated by legacy
system integrations and there was no mechanism for abstracting them
away at the higher conceptual level of a 'financial transaction'...).

> ECML v1: Field Names for E-Commerce
> http://tools.ietf.org/html/rfc2706.txt
>
> ECML v1.1: Field Specifications for E-Commerce
> http://tools.ietf.org/html/rfc3106.txt

Scope is HTML (user interface) oriented; a totally different problem
domain. Also limits scope further to credit cards.

> ..and then fwiw, it's not clear what happened to these expired I-Ds..
>
> http://tools.ietf.org/html/draft-eastlake-internet-payment-01
> http://tools.ietf.org/html/draft-eastlake-universal-payment-02
> http://tools.ietf.org/html/draft-hallam-micropayment-00

'draft-eastlake-internet-payment-01' is one of the most relevant
historic efforts under review to the proposed scope. It specifies a
character string syntax to (1) indicate prices and acceptable methods
of payment, (2) tender payment, and (3) issue a receipt acknowledging
payment or notification if payment fails.  It could be considered an
early attempt at the same problem space. Some issues: ISO4217 limited.
Includes settlement path specification with boolean 'or' logic (no
other). Encourages payment information to be sent over insecure
transports. Vague (re: partial payment, what is a 'payment system',
estimates, ceilings, receipt delivery mechanisms, etc.). HTML
integration concept predates the tendency towards pixel-perfection in
the modern 'browser as a platform'-world and would be harder to
propose today. Receipt implementation appears to have skipped
consideration of non-realtime settlement (ie: ACH, SWIFT, etc.).

'draft-eastlake-universal-payment-02' attempts to provide header-based
negotiation of common 'payment systems' between clients and servers
(merchants) to facilitate simple payments, mostly in the language of
online shopping from a browser. This is potentially interesting but
has issues: Confuses actual financial connectivity and payment systems
(which often act as gateways to others), strong B2C + centralized
settlement system (legacy) focus, examples appear to request that
consumers might provide personally identifiable information prior to
purchase, lack of metadata.

'draft-hallam-micropayment-00' is one of the most relevant historic
efforts under review to the proposed scope.  It is an unfinished
proposal for a payments system based upon a
customer-(single)broker-vendor model, primarily concerned with
micropayments. It is relatively holistic and well considered, but
appears to fail to delineate clearly between aspects of financial
instruments (eg: currencies) and those of financial settlement
networks (eg: party authentication, message non-repudiation) in its
incomplete risk model. Its forward looking proposal to formally
describe multiple settlement paths with different temporal, risk, or
other characteristics is very much similar to the approach that we
have had under consideration and have been developing at Payward Inc.
since late 2011.  However, the proposal also descends in to specific
cryptographic algorithms instead of maintaining a pluggable
architecture which is apparently often considered 'bad practice' in
higher level protocol design today. It is also rather centralized and
insecure: "requires perfect trust between servers acting as brokers.
Compromise of one server compromises all others."

Considering all of the above proposals, at one end we have EDI focused
on business level metadata surrounding actual financial transactions,
and at the other we have draft-eastlake-internet-payment-01 that
attempts to strip out all metadata and simply negotiate prices and
paths for external execution of settlements through a finite
vocabulary of intermediary 'payment systems', conveniently ignoring
the potentially complex realities of said systems.

In summary - whilst interesting at points - none of the historic
financial related proposals target the same problem domain. Most
importantly, none can adequately describe the breadth of financial
transactions occurring over the internet today.

>From my perspective, what is sorely needed is instead an adequately
descriptive (yet extensible/flexible) protocol based not upon a
specific integration point within the existing standards
infrastructure (examples in the historic documents above included HTTP
headers, SMTP, etc.) but rather a transport neutral message-oriented
protocol that is concise and minimalist enough to be deployed readily
yet robust enough to be deployed for any conventional (interbank
payments, credit card payments), specialist (high frequency trading,
non-currency value exchange such as the Energy Working Group member's
idea regarding possible use for energy costs and trading, 'exotic'
(ie. non US / credit card centric)) or emerging (mobile, digital
currencies such as bitcoin, ripple) use case.

There has clearly been thought in this direction previously but
nothing adequately broadly based and flexible with the potential to
tie things together without excluding significant, interesting,
valuable and emerging parts of the community.  Perhaps it is now the
right time to solve this problem?

Regards,
Walter Stanish
Payward, Inc.