RE: [payment_agent] Alternative TechStack and Black Box architecure

Hello Manu,

Many thanks for your comments. This is the kind of exchange I was hoping for. 

I will see to adding text to the graphics, to make a few things clear, which you have correctly pointed out:
- The black-box model is not meant to be published as a result. It is only there to act as a 'straw man', as an interims-contribution to be replaced by something generic originating  from this task force. And I hope we get there fast.
- The 'stack' is not complete and already too complex. Yep.

Indeed, I will add a bit of text to explain how I'd like to use it. Basically it is meant to be used as a pattern with a certain degree of 'self-likeness': every solution for any of the sub-functionalities of payment, which also have a life outside of payment in most cases, would be modelled as either a long box with lots of legacy or proprietary technologies stacked up.
Example: NFC-based EMVCo-compliant payment could be detailed in the left hand box by experts easily.
My hopes for the right hand side would be, that with web-standards we can re-use as much elements as possible. So, EMVCo payment from a smartphone doesn't use any tokens or credentials from the web world, and we better accept that for some more years. However, the POS protocol for coupons/ loyalty cards we have been 'attaching' to the EMVCo transaction already uses JSON objects we might easily re-use in Web-specs.
In order to have all these things work together even for the moment, the larger blocks for UI and meta-data were introduced. The can make of a user payment agent that adapts many legacy technologies despite their possibly non-webbish nature. The lower blue box will hopefully introduce abstractions and utility functions usable for everyone - although currently not yet used by legacy implementations (but might be adopted in the future simply because it eases portability).

The break-down of complexity, in my eyes should, thus, perhaps not be done per phase (which, I fear wouldn't help us a lot in the first place, as transactions starting with a certain tech stack, usually stick to the technology for the whole time) but per function.

Thus, the 'payment transaction protocol' should serve as a bracket around everything we need for a full-fledged payment transaction, but the components within could be detailed exactly the same way as the boxes between the blue layers: identity could be established using OAuth/ OpenIDConnect (right hand side) or any proprietary protocol (left-hand side), but still use a receipting function we defined as part of the payment transaction protocol stack.

I will try to outline this in the wiki too. My message would be: it's not about _the_one_payment_standard_, it's about a set of standards that help us to accommodate existing solutions with an edge towards unification of user interactions, existing ecosystems and a clear advantage for upcoming solutions supporting the new standards.

Looking forwards to more fruitful discussions tomorrow,

	Jörg

-----Original Message-----
From: Manu Sporny [mailto:msporny@digitalbazaar.com] 
Sent: Donnerstag, 4. Dezember 2014 04:00
To: public-webpayments-ig@w3.org
Subject: 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_Fra
> mework
>
> https://www.w3.org/Payments/IG/wiki/Payment_Agent_Task_Force#User_Paym
> ent_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 17:13:22 UTC