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

<dezell> Scribe: manu

<Laurent_> Closed some edits after the face to face meeting

Laurent: I tried to send a mail to the mailing list - a couple of proposals for spec... the mail didn't go out. Don't know if you have a way to add me to the mailing list.

David: I think you may not be a member?

Laurent: I might have sent it to the wrong mailing list.

David: Send it to public-webpayments-ig@w3.org

Laurent: Hmm, I think I sent it there.

David: I'll take a look.

Manu: We can talk about it next week?

Laurent: I have a bunch of comments coming in for review, I'll send comments in use case by use case

<scribe> scribenick: Laurent_

Agenda Bashing

<CyrilV> i sent also something on the pushed based

<manu> CyrilV, do you want to discuss on the call today?

CyrilV: It's not to discussed today

<manu> manu: I'd rather send as little as possible to member-webpayments-ig@w3.org

David: I'll resend the difference between member and public to CyrilV

CyrilV: I'll resend it to public-webpayments-ig@w3.org

Manu: We'll review it next week to give people time to review the mail

Updated Use Cases Document

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

Manu: this is the email that covers the changes

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

Manu: In this doc you'll see the latest changes, reflecting most of Chaals desired changes
... lots of title changes (Laurent: couldn't follow them all)

<dezell> +1 it's a big improvement

<CyrilV> ok for this types of changes

<manu> Laurent: I think this is moving in the right direction - some of the use cases are just pieces of the flow instead of the full flow.

<manu> Laurent: We should take a look at a full payment flow - if I take an example - initiating a payment one, and the ... these are part of the push flow as described for the merchant/customer. So maybe it'll be interesting to merge.

<manu> Laurent: Similar - we need something for pull payments - payee-initiated.

Katie: We should change blinding to something else (in 3.2)

Manu: Something like "Partially Anonymizing Payment Information"

dezell: First title doesn't refer to web browser but the text does, we should align things

Manu: statement 1 is an acknowledgment of the problem. We should not be specific to the browser.
... We need more comments(?) on the use cases, to make sure we're talking about the web not only the browser

<manu> Laurent: Could we use the term user agent instead of browser?

Manu: It's typical but might add complexity since we have a User Payment Agent that may or may not be the User Agent

<dezell> +1 to using "user agent" as a start toward abstraction.

Manu: User Payment Agent doesn't need to be a part of the browser
... In the F2F it wasn't clear what the motivations for each use cases was
... Detail section really were the motivations

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

<dlongley> +1

Manu: Now every single use case has a motivation section replacing detail one

<manu> Laurent: Yes, good change.

<CyrilV> +1

Manu: We had to explain push vs pull based
... People are going to continue being confused by that

<CyrilV> my view is to structure in / card Pyament

+1 on payee and payer-initiated

<dezell> +1 to payer-initiated/payee-initiated

Manu: Changes is push-based = "payer-initiated", pull-based = "payee-initiated"

<manu> Laurent: Good change - I suggest putting it as a glossary-item like thing... it's not quite a use case...

<manu> Laurent: It's worth having it in the glossary, and it may be important to call out why it's important to the work. Explain why payer-initiated and payee-initiated is important.

<CyrilV> payee initiated is divided into 2 different type of schemes : card system / direct debit. maybe we could make the difference ?

<dezell> +1 to adding the definitions.

dlongley: Still might be some confusion about payer-initiated vs payee-initiated
... use case 2.6 is a bit different than what we described
... We don't know if it refers to fund transfer or the payment itself

CyrilV: Payee initiated can refer to multiple schemes, I'm not sure we need to distinguish between payer/payee initiated

<manu> Laurent: What Manu and I are talking about is who initiated the payment. The financial transfer in the back-end isn't necessarily what we're talking about.

<manu> Laurent: It's whether or not the customer initiated the transfer. This is important wrt. message exchange between payer and payee. It has some effect on message itself.

<dlongley> "Who controls when the actual money moves, the payer (push) or the payee (pull)?"

Manu: This generalization is too great a generalization
... Front-end messaging, refering to payer/payee initiated, and a completely different set of messages in the back end (credit/debit/card/...) referring to the way funds are transferred

<dlongley> "clearance/settlement initiation"?

<manu> Laurent: In the mail I'm going to send to the list - I have a proposal, hopefully that'll solve part of the problem.

Manu: Last change was around Partially Blinding Payment Information. Still pose some issues for some in the group

<dlongley> "Omitting"

<dlongley> ^

Manu: We'll have a discussion by email

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

Manu: Any comments on this particular set of changes?
... Any missing changes from F2F?

Reviews and Additions to Use Cases

Manu: Next topic - reviews and additions

<manu> ACTION: Laurent to perform a full review for the Use Cases FPWD. [recorded in http://www.w3.org/2015/02/12-wpay-minutes.html#action01]

<trackbot> Created ACTION-63 - Perform a full review for the use cases fpwd. [on Laurent Castillo - due 2015-02-19].

Manu: Any volunteer for doing a full review of the document?

<manu> ACTION: Chaals to perform a full review for the Use Cases FPWD. [recorded in http://www.w3.org/2015/02/12-wpay-minutes.html#action02]

<trackbot> Created ACTION-64 - Perform a full review for the use cases fpwd. [on Charles McCathie Nevile - due 2015-02-19].

dezell: In the face 2 face we discussed having basic flows, or a set of steps as a basis for the discussion

+1 to wroking on flows

<CyrilV> my document try to provide basic flows

<manu> ACTION: Manu to add "basic flow" to each use case as well as nouns (actors) and verbs (actions). [recorded in http://www.w3.org/2015/02/12-wpay-minutes.html#action03]

<trackbot> Created ACTION-65 - Add "basic flow" to each use case as well as nouns (actors) and verbs (actions). [on Manu Sporny - due 2015-02-19].

dezell: We need to have steps and flows with common verbs/actions

Manu: There was a request for images for each basic flows

<dezell> +.5 to images - very nice, but also nice to have

Manu: It should probably be one of the last thing we do

<manu> Laurent: It would be nice to have a sequence diagram - if it helps, I can send a link.

<dlongley> +.5 to images, nice to have, but agree should be done last as they are harder to edit (takes time)

CyrilV: I've sent basic flows explaining SCT and Bill Payment flows
... Tell me if those are useful / the kind of things we want to include

<CyrilV> I volunteer

Manu: Looks like it's exactly the kind of flows we want to have

<CyrilV> +q

<manu> Here's an example of Requirements: https://dvcs.w3.org/hg/webpayments/raw-file/default/latest/use-cases/index.html#initiating-a-payment

Manu: Every single use cases have requirements, anybody against / for it?

dezell: Some requirements were kind of bizarre

Katie: maybe we should hide the requirement piece for now

<manu> ACTION: Manu to remove the "Requirements" sections and replace them with "Preconditions" and "Postconditions". [recorded in http://www.w3.org/2015/02/12-wpay-minutes.html#action04]

<trackbot> Created ACTION-66 - Remove the "requirements" sections and replace them with "preconditions" and "postconditions". [on Manu Sporny - due 2015-02-19].

<dlongley> +1 to keeping the requirements around, they are very useful for designing solutions; they've distilled out the important elements from the use cases and we don't want to do that work again

CyrilV: We have to define the use cases and only then define the requirements

<dlongley> but they can be hidden/moved elsewhere

CyrilV: otherwise we drive to a specific solution

dlongley: We can move them somewhere else as long as we keep them somewhere

<manu> Laurent: I'm fine with requirements being put somewhere else, but having it somewhere else is important. Design goals / requirements maybe.

dlongley: We might have some difficulties since some requirements looks like preconditions
... Goals are different from motivations

<manu> Manu: We may want to add a "Goals" section in the Introductory section?

dezell: Agree with Dave - we stick with motivations, Goals are in many documents and will be difficult to synchronize

CyrilV: I can understand "Design Goals" but not "Goal" standalone - it's too broad

<dlongley> +1

<manu> Manu: The group is saying that they don't think a "Goals" section in the "Introduction" section is appropriate at this point in time.

<dezell> +1

<manu> Manu: Goals should probably be in the Roadmap document, and only there.

<manu> Scribe: Laurent

- DRAFT -

Web Payments IG - Use Cases Task Force

12 Feb 2015

Attendees

Contents

Agenda Bashing

Updated Use Cases Document

Reviews and Additions to Use Cases

Summary of Action Items

Scribe.perl diagnostic output