Re: [payment_agent] Alternative TechStack and Black Box architecure

On 12/03/2014 05:23 PM, Joerg.Heuer@telekom.de wrote:
> 
> https://www.w3.org/Payments/IG/wiki/Payment_Agent_Task_Force#Draft_Framework
>
> https://www.w3.org/Payments/IG/wiki/Payment_Agent_Task_Force#User_Payment_Agent
> 
> Send your opinions on the mailing list too - especially those of you 
> who can't make it to the call.

Thanks for that hard work, Jörg, I know it's not easy to try and distill
all this complexity into a diagram or two. Your diagrams helped me sort
of understand why I still feel uneasy about the way we're trying to
communicate the payment agent concept. I'm going to try and convey those
rough thoughts without having them fully formed. So, apologies in
advance for the rough edges.

I don't think we should present a single UPA stack, nor do I think we
should say we have this pluggable black box. The technology stack that
is used is context dependent. The Payment Agent looks different
depending on what part of the transaction process it's participating in.

To suggest an alternative, we may want to break this stuff down into the
"phases of a transaction" we'd like to see standardized on the Web. For
example:

Phase 1: Merchant Expresses an Offer of Sale
Phase 2: Payment Initiation / Identity Credential Transmission
Phase 3: Payment Instrument Negotiation
Phase 4: Submission of Payment to Payment Processor
Phase 5: Delivery of Proof of Payment to Merchant
Phase 6: Payment Clearing/Settlement

I'm not saying these are the only phases or that the order above is the
only order that makes sense, there may be many more/others... but the
bit above are the phases that are most clear in my mind as being
something useful to work on.

We have a grab bag of technologies at our disposal, some of them already
exist (like HTML5, Javascript, TLS, JSON-LD, etc.), others are just now
forming (like an Offer metadata format, WebIDL for payment initiation,
etc.). Only some of these technologies are applicable to the phases
above. For example, in Phase 1 above, we can say that the Payment Agent
stack might look like this:

Presentation: HTML5 / Native UI / Screen Reader
Metadata: Offer Metadata Vocabulary/format (missing technology)
Message Format: JSON/JSON-LD + digital signatures
Transport: NFC, HTTPS

We don't need to talk about many of the other technologies because they
don't apply to this particular phase. This approach has a number of
benefits:

* It makes the problem more accessible to the general public by not
  hitting them with a firehose of information and financial jargon.
* The point above then plays into Pat's point that we want to
  make it easy for people in the financial industry to identify
  areas where they can help. A company may latch on to phase 3
  for example, while another latches on to phase 6.
* It breaks the problem down into modular components where you don't
  need to have the whole picture in your head in order to contribute.
  Modularity also means that we can hopefully add/remove new
  technologies to each phase w/o having to rethink the entire Payment
  Agent diagram.

So, I think my suggestion is that we work bottom-up. We don't worry
about the "big picture diagram" right now, and instead approach the
problem from the other direction; we think about the phases of the
transaction process we want to try and standardize for the Web. Once we
have enough phases/buy flows worked out, we may be able to construct a
"bit picture diagram".

I'll have to think about whether or not I really like this approach over
the next day or two, I may hate the idea by Friday, we'll see. :)

Thoughts?

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: The Marathonic Dawn of Web Payments
http://manu.sporny.org/2014/dawn-of-web-payments/

Received on Thursday, 4 December 2014 03:00:00 UTC