Re: The Payments Architecture within which a Web Payments Architecture occurs

 On 00:11, Fri, 15/05/2015 Joseph Potvin <jpotvin@opman.ca> wrote:

I would like to raise a general consideration to the CG list:

What aspects of a "Web Payments: Technical Architecture" are unique to
"Web" mediated payment, what what aspects are generic to payment via any
medium?

IMHO: we're tooling for knowledge economy.

That job includes defining solutions for Massive identity related issues;
which likely include,

Choice of law

Data rights; including Data storage, reuse, security and other requests
that can be defined via standards that incorporate linkrd data, in addition
to ontology works that refactor transactional life experience, with
structured data.

In-turn, this capacity building exercise becomes a hub for enormous
opportunities to innovate, enhance productivity, efficiency and fairness as
defined by law, in and between each jurisdiction.

Before the web, commerce related behaviours were very different.  A bit
like looking at trade before shippinh containers.

Existing web supports open data and organisationally secret data very well.

Yet,  In life, we pay to live, and whilst free services have provided
enormous accessibility to web; whether or not participants are reasonably
served economically remains to be seen. "We" dont have the data to
evaluate, most have had commercial experiences relating to the transmission
of IP resulting in circumstance they felt was unfair, yet the economic
impact is currently difficult to assess; as are the opportunities and
tooling for innovation that may evolve solutions overall.

New digitally native objects are being created every millisecond,
currently, most is either stored without payments notation, or transfered
via legally transparent mechanisms that are generally asymmetrical in
nature.

data for economic purpose is a particular form of data that is neither
truely secret nor the domain of solely particular entities, generally
service providers and advertisers are the known forms of economically
successful http agents; arguably due to tooling.

economic handshakes between all web agents is difficult / perhaps no "fit
for purpose" solution exists as yet...

Generic trade goes back to the days of eden.

I got a chicken, I'll trade you for those potatoes.

Not

Do you like my chicken?

I like potatoes and can sell them. I will take them, and sell them for half
the price it cost you to make them + my costs, down the street...

Magna carta is a notable example on history, where that form of shared
value was agreed.


It seems to me that a generic payments technical architecture provides the
functional system environment within and upon which a Web payments
technical architecture occurs.  Therefore it seems to me critical to
clearly separate these two in the document.


Isnt it simply http?


The thought I'm attempting to underline is that a Web Payments Technical
Architecture must point to an explicit external source that provides a
generic Payments Achitecture, preferably one provided and maintained by a
genuine global standards body, or something that in effect serves that
function. The generic Payment Architecture ought to be sufficiently refined
as to be consistent across all media

A Web Payments Technical Architecture must (I would have thought) restrict
its additive scope to that which is within the domain of the W3C, while
explicitly referencing (in its text and diagrams) the generic Payments
Achitecture that it is engaging.

-- 

Joseph Potvin
Operations Manager | Gestionnaire des opérations
The Opman Company | La compagnie Opman
jpotvin@opman.ca
Mobile: 819-593-5983