RE: [payment_agent] developing a flow chart and mapping with standards and existing system

Hello all,

While I absolutely agree with the layering Pat is asking for, I'd say let us limit the number of layers a bit. Also, I would like to share our experience wrt/ existing technology we applied in our prototype.

- Our top layer is a usage pattern for users (and humans at the register - yes, they have their own 'protocol') and web sites alike
- Underneath we have technologies to integrate solutions - independent of actual protocols, but with intrinsically supported flows and interaction elements.
- To ease integration, a meta-data definition serves an Item concept (basically virtual cards and stuff) so that the patterns can get streamlined along this paradigm.
- On the implementation layer for individual services behind items, there is a little pre-defined yet.
Web-specific payment standards could be like building blocks, probably belonging to the next layer:
- The hardware abstraction and framework interfaces will allow implementations to use capabilities of the client (hardware and OS) as well as the wallet framework.
- Capability layer (hardware, OS, wallet framework)

Basically, the first three are to be described by the user payment agent concept. Number four is where millions of traditional implementations for proximity, web or remote-payments can be allowed to live. Ideally some coming from W3C which require mere parameterization in order to cover a wide range of services. I guess, this is where Layers 2 - 6 in Pat's layering would be needed. Perhaps also layer 1 - I am not too sure, perhaps we'd share layer 1.

I have nothing against the idea to specify a complete experience from layers 1 to N, I just want to make sure, we are not assuming to own super powers which will make everybody accept and implement the whole stack immediately. The multitude of services, functions and their implementations will be of utmost importance to acceptability in the industries - and the users, I guess.

If there are not too many objections I will try to come up with a sketch of these layers over the week...

Cheers,

	Jörg

-----Original Message-----
From: Adler, Patrick [mailto:patrick.adler@chi.frb.org] 
Sent: Dienstag, 25. November 2014 06:04
To: Stephane Boyera; public-webpayments-ig@w3.org
Cc: McDermitt, Dave; Swendseid, Claudia
Subject: Re: [payment_agent] developing a flow chart and mapping with standards and existing system

Hi Stephane,

In thinking about what you shared below, it seems that while the current picture does outline some key aspects of things that we should be considering in our work, the key challenge is that it mixes concepts from different layers/levels of thinking which may make it harder to understand.  One thing that I've seen work well in the past is if there are multiple more focused diagrams that only try to tackle one layer at a time, and then a single top level diagram which helps orient the reader to where to find the level of detail they want to know.  I think that both the OSI, TCP/IP, and to some extent the ISO 20022 spec do this well by
layering different levels of the standard.   This also has the benefit of
introducing a nice logical separation of pieces of the standard that may need to evolve orthogonally or independently of one another.

Some examples for our work might be (these need much broader discussion and are only provided as an example to help the discussion):
	Level 1 - General Top Level Payments Business Domain Concepts (refer to other payment standards)
	Level 2 - More specific payments vertical concepts (ex. P2P, P2B, B2P,
etc) (This may be important to call out because the underlying web technologies in each case to enable compliance with a global standard my be necessarily different but still could comply with an overarching
framework/standard)
	Level 3 - General Web/Technology Domain concepts used for payments (ex.
Payment Agent) that would be expected to be adhered to in all use cases
	Level 4 - More specific Web/Technology Domain Concepts used for payments in a particular context from Level 2 (ex. "USER" payment agent  - which as described here may only involve payments involving people as opposed to something like Automated Payment Agent or Merchant Payment Agent which may need to adhere to specialized rules)
	Level 5 - General Foundational Standards/Web Technologies that this work depends on (ex. HTTPS, SSL, NFC, BLE, etc, etc)
	Level 6 - Specific Web/Technology Standards that may be required to support specific level 2 concepts
	Level 7 - Not sure where this would go yet, but any localization/internationalization/interoperability standards that would be necessary to provide integration to existing payments systems (this would be a great topic for the group to discuss regardless of where it goes)

Again, the key benefit of this is that pieces of the standard can evolve on different time horizons (ex. today we are likely reliant on components of HTML5 or a particular encryption approach, but as those get better, the whole standard can benefit from underlying improvements)

Finally, I came across the following link while reading up on some of this that I thought would be worth sharing with this group if you haven't seen it.  The link contains all of the business model definitions for the ISO
20022 spec which should be helpful as we work to align terminology as well as providing a nice graphical picture of how domain concepts relate to one another in that spec.  http://www.iso20022.org/business_model.page

Hope this is helpful - as always, I'm very interested in what others thoughts are© 

Pat

On 11/24/14 8:38 AM, "Stephane Boyera" <boyera@w3.org> wrote:

>Hello,
>
>I've been trying to explain to various people, including my internal 
>colleagues, the diagram at 
>https://www.w3.org/Payments/IG/wiki/Payment_Agent_Task_Force#Draft_Fram
>ewo
>rk
>and I've to say that I was not very successful.
>
>Therefore, I'm trying to find out how we could do a better job.
>Collecting various inputs, it seems that one way to make this a bit 
>understandable is
>1- make a flow chart that will identify various steps till the 
>transaction is completed
>2- instantiated the flow chart on a couple of well-known systems like 
>Apple pay, paypal, currentC, google wallet to show how it works 
>3-highlight places where there are standards or groups working
>
>I feel the 3rd point is very difficult as it is a mix of apis, data 
>format, etc. that will varies. But at least we can make a try?
>
>What does people think?
>Do you htink it would make the diagram clearer? should we try to go 
>that way and start with step 1 ?
>I'm trying to find examples of such flow diagram from e.g. existing 
>payment system. Any links/referenes would be helpful
>
>cheers
>steph
>-- 
>Stephane Boyera        stephane@w3.org
>W3C                +33 (0) 6 73 84 87 27
>BP 93
>F-06902 Sophia Antipolis Cedex,
>France
>



This e-mail message, including attachments, is for the sole use of the intended recipient(s) and may contain confidential or proprietary information.  If you are not the intended recipient, immediately contact the sender by reply e-mail and destroy all copies of the original message.

Received on Monday, 1 December 2014 17:00:08 UTC