Web Payments IG Use Cases Task Force -- 19 Feb 2015

<manu> Agenda: https://lists.w3.org/Archives/Public/public-webpayments-ig/2015Feb/0031.html

<scribe> Scribe: Katie Haritos-Shea

Agenda Bashing

<scribe> ScribeNick: Ryladog

Manu: we do have e terminology section - we will add that

Pat: I noticed I would like to clarify Push vs Pull or Pyer vs payee
... We need to clarify this in the use cases

Manu: Will cover later OK?

Pat: yes

Updated Use Case Template

<Ian> diagrams++

Manu: we decided to add and remove some things from the UC, we decided to do diagrams and turn out to be really important

<manu> https://lists.w3.org/Archives/Public/public-webpayments-ig/2015Feb/0030.html

<manu> Look at this one specifically for an example of the new template: https://dvcs.w3.org/hg/webpayments/raw-file/default/latest/use-cases/index.html#initiating-a-payment

Manu: You will see the new description and the flow and the objects as I an reaised in the F2F. then example to add meat o the bones
... The next section are the motivations for the CS why they are important and why we decided to incluse them
... and at the bottom there are US preconditions and post conditions
... pre is wht should eb true for the UC to work
... the post is what should be true after the use case is implementsed
... so what aree we nising?

Ian: F2F talked about US should be - what the examples are . So each example is a UC
... I agree that factoring out pre and post. So have you thought about moving th examples to USs?
... why are there 4 examples - if they are diffetent then they should be there own US

David E: +1 to Ians questions. The basic flow looks great. It is nore than I was thinking. Maybe it needs to be simple steps.

scribe: the flow we need to have that spelled out just in text
... the way these are laid out....which is multiple ways of looking at the same thing. But there is the more common way without a POV.
... I am unsure if we shoul keep POV...that is the part that nakes it hard to map to sprocofc UC

Laurent: I cannot agree that for the examples that they should not have POV.

<Zakim> manu, you wanted to say that moving examples out to be their own use cases would lead to an explosion of use cases.

Manu: Background on the examples: started out in the CG, we kept going more and more generic with the text. But then the description wee tto generic and it was hard to map to a use case
... what we really need is a view of the UC from a variety of visual.
... -1 to spliting the example out into their own UC
... they are all supposed to be about a particluar use case

Ian: 3.1.2 is different perspective on the same US. That sound s different to me. So maybe we could identify that

Manu: the reason that we have that their is that folks want tto have something that each stakeholder could hold on to

<Ian> [Maybe we can recast 3.1.2 as "Different perspectives on the use case" rather than "Different examples"]

Manu: before it was all customer centrix. Can we reword?
... I dont have stronge feeling about that.....other did...

<Ian> +1 to single use case and multiple points of view

DaveL: I was going to say what Ian said. another approach is to have generic text for each use case then giveexample of wht they were trying to say

Pat: I think the image is helpful but I think it specialized too early. I would like to update to payer sellects something on payee
... vey generic concepts are easier to understand aand allow the terms to stay consistant.
... a person sometimes is not neecssarily a customer

Manu: In one we tired to use just payer and payee...so we can rework the diagrams to just have payer and payee

Pat: Simple online payment example
... If we are doing that conisistantly it will be more clear to folks

Jean-Yves: I think that helpful to have some definitions or visions of not only the POV but also the roles are very different from merchant to others
... if we solit it into different sections on what we all agree - otherwise (sorry Cyril idid not capture you comments well, please add them)
... pre and post conditions should be part of the requirments maybe. I want to understand what kind of conditions we have to use b/c that is noy clear to me so far

Manu: We have good input.
... clealy we have a problem with the exmple section

<Zakim> dezell, you wanted to talk (again) about "examples"

DavidE: We need to move quickly there may be other UC. I think I can supply a poinyter to traditional UC methodology/terminology. If you couple

<Zakim> manu, you wanted to say that we tried same use case across all examples - and people complained about it being too focused.

DavidE: them hthen you have a basic flow. It is common for the stories to not fit so that means that they need to be moved to a new UC

Manu: what David says is true it is like atunnel

<Zakim> Ian, you wanted to discuss diagram

<Ian> http://www.philadelphiafed.org/consumer-credit-and-payments/payment-cards-center/publications/discussion-papers/2013/D-2013-October-Clearing-Settlement.pdf

<dlongley> One approach would be to just drop spelling out the POV and keep the example text. That would give different perspectives (without explicitly saying so) within a set of examples.

Ian: Diagram. I read an artcile from th Payment card center on the last page they have some diagrams that are useful. We might not want all of the info.

<padler> +1 to type mismatch..

Ian: people talk to merchandt. The website happens to be the way the merchant happen to communicate with the bnank. The diagram should not respresent the website and rather the parties involved

<manu> ACTION: Ian to review Initiating a Payment use case and propose changes. [recorded in http://www.w3.org/2015/02/19-wpay-minutes.html#action01]

<trackbot> Created ACTION-69 - Review initiating a payment use case and propose changes. [on Ian Jacobs - due 2015-02-26].

<padler> if the goal is to create standard web payments, keeping it generic would help to allow for many different types of clients on either end of the transaction (ex. POS terminal, refrigerator, watch, etc)..

Brief discussion on Terminology

<manu> https://dvcs.w3.org/hg/webpayments/raw-file/default/latest/use-cases/index.html#terminology

JY: We need to be consistant in out terminology and I dont think we are.

<Ian> https://www.w3.org/Payments/IG/wiki/Glossary#Roles

JY: I think we should stick to known elements and inputs - maybe when we will try to get the new components in the glossary with descriptions

<Zakim> manu, you wanted to say that Terminology in use cases is being used actively - can we focus there?

<manu> https://dvcs.w3.org/hg/webpayments/raw-file/default/latest/use-cases/index.html#terminology

<Ian> (All problems can be solved by an indirection. :)

Manu: I completely agree with JY. The terminoly in the UC spec I am trying to make it line up with the gloassry. Please send very cpcific changes to the list

DavidE: I also agree with JY, that is non-contiversial. But it is hard for us to ensure that. What is the best way to help?

Ian: The expectation that there will be a glossary and that this document will rely on that. The glossary is not being upadted on a regular basis. What are the obsticles.

<manu> Here's the current glossary: https://www.w3.org/Payments/IG/wiki/Glossary#Roles

Ian: you could move the terminology section out of the document into the Wiki
... there would be one place instead of 2

<dezell> +1 to using the glossary for the definitions.

Ian: I am unsure if there is agreement

<Zakim> manu, you wanted to close discussion on glossary and move on.

<Ian> (Ok to know that respec mechanics are part of this story)

<manu> https://dvcs.w3.org/hg/webpayments/raw-file/default/latest/use-cases/index.html#terminology

Manu: Absolutely agree, becasue of the ReSpec tool it required you to define terms
... -1 to moving it out to the Wiki, becasue we will no longer be able to do that in the FPWD
... we should hav only 1 glossary thing that we end up editing
... stop the glossary in the Wiki nd figure out a way to import it into the FPWD doc
... respec does not support @import

Ian: we probably dont want this to be a dynamic thing - we need a static include for stability. Maybe emporarrily dunamic

<manu> ACTION: Manu to figure out how to have one glossary document that can be #included into each spec. [recorded in http://www.w3.org/2015/02/19-wpay-minutes.html#action02]

<trackbot> Created ACTION-70 - Figure out how to have one glossary document that can be #included into each spec. [on Manu Sporny - due 2015-02-26].

<Ian> (I suggest also talking with Evert about moving from Wiki to github)

Manu: we need to talk to Evert about this

Push vs. Pull Payment Flows

<manu> http://www.w3.org/Payments/IG/track/issues/1

Pat: Just want to point out that payments people the payer is actually pushing the payment out of therie account into ssoemone else account
... pull based is when someone pulls the money out. WE can very clearly delineate those two things
... the actual mechanics behind the scenes......

<Zakim> manu, you wanted to raise the point of confusion around push vs. pull.

Manu: The reason it was chnaged in the spec - there seemed to be confusion in the industry about this
... we had discussion that seemed it as not clear. The original intent was what you just said

DavidE: The push and pull acutally referes to the issuer and the acquirer
... the part of the language that - the reason that push payment is different is that this is a role reversal. I think Manu is saying that the user counts

Pat: the title of it suggestes that as a user that I could acy=taully iitiate a pull payment form my account
... that is a payer initaited pull payment

<manu> http://www.w3.org/Payments/IG/track/issues/1

<Zakim> Ian, you wanted to ask a clarifying question

Pat: payer initiated pull/push and payee has initiated pull/push

<manu> Ian, look at this wrt. Push-based payment: https://dvcs.w3.org/hg/webpayments/raw-file/default/latest/use-cases/index.html#payer-initiated-funds-transfer

Ian: I hear that 3.1 as stated may not be presice, maybe we need multiple. That could be a whole useful thing inside this use case it really is the same it is just where the paymnt is initaited

Manu: Please look at what i put into IRC, it is a specuficf different ise case

<Ian> will do

<padler> +1 to what Laurent is describing..

Manu: there was supposed to be no difference, but as Pat has outlined there is clealy a different

DavidL: It is unclear what is being initiated. It is all about who is authorized to access your funds
... with pull you gviethen access to pull when they want to
... use aterm authorization\Manu: maybe yu could send something to the mailing list

<CyrilV> -1 for authorization : it is already use for another process in card payment

Pat: the differecne is really around who starts the process, who initaiates the collection of thinsg that start the payment
... the other is saying here is th list that they will accept in both cases the push id she=where the authoization actaully astrat te transaction

<Laurent> Laurent (capturing his own comments): In the F2F, we used push / pull to refer to processor location. Push was on the customer side, Pull on the merchant side. But Pat's point is that push / pull is referring to who initiaites funds transfer between accounts, so we should find other terms for processor location.

Pat: payer initailed pull payment

Manu: Cyril says he is -1 on any use of the word authorization

DavidL: Maybe we can use the word deligation

Cyril: No

Manu: Do we want to add a UC that has to do with this vague Pull Based Payment?

<padler> in general pull based payments have a lot of risks... so it may be a lower priority..

<manu> ACTION: Laurent to write a pull-payment use case. [recorded in http://www.w3.org/2015/02/19-wpay-minutes.html#action03]

<trackbot> Created ACTION-71 - Write a pull-payment use case. [on Laurent Castillo - due 2015-02-26].

Manu: What exactly is the terminology that we are going to use to write tha tUC

<padler> +1 to the term validation...

Cyril: We could describe the .....payment subscription.....(scribe is having trouble hearing comment).....

Manu: we are out of time, thanks everyone, a great discussion - the call we be at the same time next week

Manu

<manu> s/Topic: Push vs Pull Payment Flows//

- DRAFT -

Web Payments IG Use Cases Task Force

19 Feb 2015

Attendees

Contents

Agenda Bashing

Updated Use Case Template

Brief discussion on Terminology

Push vs. Pull Payment Flows

Summary of Action Items

Scribe.perl diagnostic output