RE: [payment_agent] Alternative TechStack and Black Box architecure

Hello folks:
+1 - many thanks to Joerg for the hard work and for "putting it out there," making our jobs as pundits much, much easier.

Also, I think the "6 payment steps" Manu outlined are very interesting:
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
(Note: nobody - including Manu (we talked) - thinks this list is final.)

What I mean by that - by the time we're done:
1) use cases should probably include one or more step above
2) it should be easy to figure out from the UPA interfaces provided (plus the proposed NFC and Web Crypto interfaces) exactly how a given use case will be implemented.

This approach gives a very "Agile" feel not just to our progress in definition (or adoption of definition) but also in how various entities might implement use cases.  It provides a good starting granularity for thinking about use cases in terms of the UPA and visa versa.

More later.  But thanks for all this.

Best regards,
David

-----Original Message-----
From: Manu Sporny [mailto:msporny@digitalbazaar.com]
Sent: Wednesday, December 03, 2014 10:00 PM
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/

________________________________
This electronic message, including attachments, is intended only for the use of the individual or company named above or to which it is addressed. The information contained in this message shall be considered confidential and proprietary, and may include confidential work product. If you are not the intended recipient, please be aware that any unauthorized use, dissemination, distribution or copying of this message is strictly prohibited. If you have received this email in error, please notify the sender by replying to this message and deleting this email immediately.

Received on Thursday, 4 December 2014 21:14:48 UTC