RE: [Action-54] Glossary revision

Hello Ian,

Thanks for your feedback.
I agree that the Four Phases can be matched well to the Transaction Steps I described in the Utrecht F2F meeting.

Privacy aspects which are of concern to me, relate to "use of data according to specific and agreed goals"
This is strong in payment processing, where the privacy for data from retail payments (such as POS transactions) is a very sensitive subject.
Also, in the first F2F in Santa Clara, WalMart underlined that a retail organization shall have control over what data is processed where (especially for sales related data such as order lines).

So, a specific "processor" can offer payment services and / or value added services - but the architecture shall be designed such that these processes are decoupled. That was the main intention of the diagram I suggested.

With kind regards,

Evert

-----Oorspronkelijk bericht-----
Van: Ian Jacobs [mailto:ij@w3.org] 
Verzonden: maandag 9 maart 2015 3:42
Aan: Fekkes, ER (Evert)
CC: public-webpayments-ig@w3.org
Onderwerp: Re: [Action-54] Glossary revision


> On Mar 4, 2015, at 9:13 AM, E.R.Fekkes@rn.rabobank.nl wrote:
> 
> Dear all,
>  
> As you may have noticed, re-drafting of the [Glossary] has been limited to the posting of the two diagrams we discussed in Utrecht:
> https://www.w3.org/Payments/IG/wiki/Context

>  
> Action-54 states to "Revise the glossary per the discussion at the f2f, and let us know when season opens on comments”.
> We discussed the Glossary on Feb 2, 2015 (see Glossary) in the minutes.
>  
> The F2F minutes state my intentions at that point in time:
>  • A couple of slides - putting the roles into context - three and four corner models
>  • I wanted to organize use cases w/ examples on major steps. The 
> phases of the payment transaction This was geared towards a more compact Glossary, identifying the “key terminology” to understand the “basic payment flow”  on which the "use cases" elaborate further and the "payment agent" architecture implements.
>  
> During the last weeks, I did not deliver the texts I hoped to do - but 
> Ian filled this gap with the description of flow in a 
> customer/merchant transaction and the Single Narrative for Web 
> Payments Use Cases on http://www.w3.org/2015/02/wpay-sample.html

>  
> In the Flow descriptions, slide 5 (http://www.w3.org/2015/Talks/ij-usecases/?full#5) and further give a nice listing of basic terminology.
> The terminology stated there is used in the Use Cases Editor’s Draft and should be the right selection.
>  
> Now, for the Glossary, we could come to a cross reference of these basic terms and relate these to “technological”  definitions referring to existing definitions as these exist in payment scheme documentation etcetera. This is a mapping and validation exercise for the “working terms” we use in the Use Cases and Payment Agent documents (and further TF documents, such as the settlement work).
>  
> My questions at this point in time:
>  • Should we transform the Glossary in the "cross-reference" approach between the “working terms” and “industry terms”?
>  • Can we reduce the Glossary to only terms referenced via the “working terms”  for Use Cases, Payment Agent, etc? 
>  • What shall we do with the diagram on the extended four corner 
> model? 
> (https://www.w3.org/Payments/IG/wiki/File:Extended_four_corner_model.p

> ng)
>  
> Transaction Steps
> As for the other diagram, the “Economic Transaction Steps” 
> (https://www.w3.org/Payments/IG/wiki/File:Economic_Transaction_Steps.p

> ng) This subject seems to be superseded by the four steps of the 
> payment flow as now described in http://www.w3.org/2015/Talks/ij-usecases/?full#7:

> Negotiation of Purchase Terms; Negotiation of Payment Instruments; 
> Payment Processing; Delivery of Product/Receipt
>  
> The diagram which was presented in Utrecht now seems superfluous. 
> The different elements of this diagram should be addressed in chapter 2 (The Phases of a Payment) of the Use Cases document.

Hi Evert,

I wanted to review this email before our call tomorrow on these topics. I’d like to see if we can reconcile your diagram:
 https://www.w3.org/Payments/IG/wiki/File:Economic_Transaction_Steps.png


With the four phases:
 http://www.w3.org/2015/Talks/ij-usecases/?full#7


I’ll attempt to formulate your diagram in terms of the phases. I think you are (roughly) saying this:

 1) Negotiation of purchase terms and payment instruments
 2) Application of Marketing Elements (part of Phase 1 in the slide deck)
 3) Payment Processing

Your diagram does not explicitly cover delivery of product/receipt. The slide deck (by design) does not discuss clearing, reporting and reconciliation.

It seems to me that the phases and diagram are not terribly far apart.
 
> As I distinguished between “Purchase”, “Value Added Services”  and “Payment”, I suggested a separation in what type of information is required for the different steps.
> At “Purchase” (Negotiation of Purchase Terms; Negotiation of Payment Instruments), two sets of data orginate: the “order lines” (what have been bought) and a “smart contract”  which may just be the price, but can be much more elaborate. Now, the “order lines”  were only used for “value added service”  processing (where negotiation of marketing terms happens) - but would NOT be required for the actual “payment processing”.

If I understand correctly, you are here characterizing what information will need to be exchanged among different parties, and you offer that there are going to be two kinds of chunks:

  - The payer and payee will exchange certain information (via the payee’s site, the user’s browser, and the user’s payment agent). This is the “order lines” data.
  - The payer, payee, and payment processors will exchange some other data (and that data might overlap for things like price). This is the “smart contract”
    that enables payment processing to take place.

If what I’ve said is at all relevant, then my sense is that this level of discussion will belong in the “architecture” and “requirements” deliverables. It may be that the people working on the architecture description begin to enumerate data requirements, and might find your modeling useful for doing so.
>  
> This “separation of concerns”  is, in my opinion not (yet) addressed in the Use Cases - but is relevant for privacy matters.
>  • Is this something to be addressed further? Where would be the best place?

If we want the architecture to demand a particular data organization in the name of privacy, I agree with you we should have some use cases to ground it. Can you say more about the privacy matters you have in mind? That might help surface the relevant use cases.

Thanks!

Ian

>  
> Regards,
>  
> Evert
>  
> PS – this message was sent a bit earlier from my gmail account, but that was not yet known to w3c, it occurs.
> So we may end up with twice the message in the mail archive – sorry for that!
>  
>  
> ======================================================
> Rabobank disclaimer: http://www.rabobank.nl/disclaimer

> 

--
Ian Jacobs <ij@w3.org>      http://www.w3.org/People/Jacobs
Tel:                       +1 718 260 9447



======================================================
Rabobank disclaimer: http://www.rabobank.nl/disclaimer

Received on Monday, 9 March 2015 10:47:32 UTC