[use cases] Meeting minutes for 2015-02-19 telecon

The minutes for today's Web Payments IG use Cases Task Force telecon can
be found here:

http://www.w3.org/2015/02/19-wpay-minutes.html

Full text of the meeting follows:

--------------------------------------------------------------------
Attendees

Present: Manu, David_Ezell, Ian, Jean-Yves, David_Longley, Pat_Adler,
         Katie, Laurent, Cyril
Scribe: Katie Haritos-Shea

Topics
1. Agenda Bashing
2. Updated Use Case Template
3. Brief discussion on Terminology
4. Push vs. Pull Payment Flows

Summary of Action Items

[NEW] ACTION: Ian to review Initiating a Payment use case and propose
              changes.
[NEW] ACTION: Laurent to write a pull-payment use case.
[NEW] ACTION: Manu to figure out how to have one glossary document that
              can be #included into each spec.

Agenda Bashing

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 Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: High-Stakes Credentials and Web Login
http://manu.sporny.org/2014/identity-credentials/

Received on Thursday, 19 February 2015 18:40:56 UTC