W3C home > Mailing lists > Public > public-webpayments-ig@w3.org > March 2015

[use cases] Meeting minutes for 2015-03-12 telecon

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Fri, 13 Mar 2015 00:42:29 -0400
Message-ID: <55026AB5.3050407@digitalbazaar.com>
To: Web Payments IG <public-webpayments-ig@w3.org>
The minutes for today's Web Payments IG Use Cases Task Force telecon can
be found here:


Full text of the meeting follows:

Present: KePeng, Ian, Manu, Shane
Regrets: DavidE
Chair: Manu
Scribe: Manu, Ian

1. Use Cases Rework
   * Current status
   * Micro-use case layout
   * Alipay / Asia-Pacific specific examples
   * Things that still need to be done for FPWD

<Ian> [IJ notes for the call: DSR items, privacy considerations,
exception considerations]
Manu: Any changes to agenda today?

Ian: I'm most interested in the structure - have some structural points
/ questions.

Use Cases Rework

<scribe> scribe: manu
<Ian> +1 to short labels for (micro) use cases
Ian: There are a couple of things that are good... +1 to short labels
for micro use cases

ian: Industry folks tend to throw around short labels quite a bit -
especially in these cases, slightly higher level - short phrase that
speaks to industry doesn't get in way of easy understanding.
... I like that.
... I think the green and the red is distracting.
... Minor comment, but maybe we can find some other way to format some
... There were times when Dave mentioned exception situations - when a
payment fails and coupon needs to be re-instated. Thinking about those
and putting them in use cases at that high level seems like an
annotation about an exception situation.
... Other topic that's come up has been privacy considerations -
remember that you don't want to send your Social Security Number over to
a merchant, for example.
... Not sure what "Justification" is yet?

<Ian> Manu: Agree green/red is distracting. Red is editorial (to be
stripped out).
<Ian> ...the Justification bit is to explain why it's different than
another use cases

<Ian> IJ: Justification is why we have the use case at all
<Ian> ...but it's there for the editors.
Ian: Ok, we may want arbitrary notes - why this is important... which is
slightly different than editorial notes.
... If a lot of them have the same justification, we could have a
section that's assumptions - why did we include these use cases overall?
... For example, help ensure ubiquity, etc.

<Ian> IJ: Maybe they don't have common justifications (so does not make
sense to factor out)
Ian: Let's read through a few of them... (reads through Website-based offer)
... Themes - automation is important - need unifying architecture given
diversity of devices, applies to automotive, point of sale, etc.
... So, there might be able to pull out the justifications - we might be
able to figure out if it contributes anything to certain topics.
... Automation, legal obligations, security, etc. These are clearly
perceived needs...

<Ian> Manu: What you did in your doc....
manu: here - http://www.w3.org/2015/03/wpay-usecases.html

<Ian> ...you did break it into categories
Ian: The justification you have, I like the idea that we say 'how did
any use case get into this document to begin with?'?

<Ian> https://www.w3.org/Payments/IG/wiki/ExecSummary#Goals
<Ian> do they improve usability?
<Ian> security?
Ian: If the group could see the broad things we wanted to address -
tying them into the goals - do they improve usability?

<Ian> porttability?
Ian: We believe these are "in pursuit of these goals"... here's the goal
it helps us pursue.
... So now everyone in the group knows why it made it in here - it's in
pursuit of some goal, otherwise it shouldn't be in here.
... We should attempt to do that - that would simplify the document by
making it short labels... that's different from editorial notes, like
"is this a duplicate?"
... Categories that I had in my document were intended to group things
slightly differently - avoid duplication of use cases - putting them
next to each other, when they differ by a tiny amount, I had a common
label for them.

<Ian> Manu: One thing I found moving them into the use cases, I could
find a slightly different justification for each use case
<Ian> ...there was a use case where hold/pre-auth was so close that I
think we can put them into one use case
Ian: You have a number of things under "Discovery of Offer" - if we say
what goal it helps us pursue - that might be useful... having everything
flow from a small number of goals would be nice... so having an
annotation wrt. about what the group likes about this model. For
example, the purchase price of the train in the first example of $15
might be important because the price.

<Ian> - short label
<Ian> - the short story
<Ian> - annotations:
<Ian> - priority
<Ian> - motivation
<Ian> - security / privacy considerations
<Ian> - exceptions
Manu: So, if we add each one of those subtopics for each micro use case
- we don't have micro-use cases anymore.

<Ian> - which goals do they help use pursue
Ian: Without trying to be fancy - possible to have one view that's just
the simple statements w/o anything else - another one that's the fully
annotated one - push the button to do the annotation.

<ShaneM> sorry my mute button stopped working!
<Ian> IJ: Can we expand good bits?
<Ian> Manu: We can built that but we don't get it for free
Ian: I have the feeling that a designer could make this still readable...
... The sentence could be big - if it was airy to read - might not be
too painful.

<Zakim> manu, you wanted to mention Motivations.
<Ian> Manu: We could put security/privacy, and exceptions in their own
Ian: Yes and no - Dave's comment was - I want to pay with a voucher -
please note that if a payment fails, I get my voucher back.
... On another hand, there are probably general statements that can be
made. For example - transactions can stop at any time, so in those
cases, what do we need to keep in mind when that happens?
... It could be that exceptions merit it's own document section.
... For security/privacy - it's sort of the same - we want to make sure
that when we get to the architecture that we're able to send data to
only the parties that need it.
... For example, data sent to merchant is only to be shared w/ the
merchant - that seems like a useful/general statement. However, there
could be, in a specific use case, it could be that we want to call out

Manu: I'll try a few things and you can try a few things - maybe we can
come up with a workable template.

<Ian> - short label
<Ian> - micro statement
<Ian> - goals
<Ian> - motivation
<Ian> Manu: Let's make motivation mandatory.
<Ian> IJ: Ok
<Ian> - security/privacy considerations
<Ian> - exception considerations
Ian: Does this flow make sense to you?

Kepeng_Alibaba: Yes.

<Ian> http://www.w3.org/2015/03/wpay-usecases.html
Ian: I put in a bunch of use cases in this document if I could make them
fit - tried to draw on slide decks, use cases, dave's comments.
... On the one hand I don't feel strongly about which ones make it in -
curious about yoru plan to bring them in.

Kepeng_Alibaba: One question - as part of the payment method - because
we have Alipay, largest payment method in China, but it's not mentioned
in use cases document.

<Ian> Manu: Yes, we should mention it somewhere.
<Ian> Manu: We need to understand the Alipay flow to figure out how to
include it.

<Ian> Initiation of Processing. Depending on the payment instrument, the
payer (e.g., when using PayPal), the payee (e.g., when using a credit
card), or other party (e.g., bank) initiates processing.
Ian: Where we mention PayPal or Google Wallet - we could also mention

<Ian> Ian: Let's put PayPal, Google Wallet, Alipay, Apple Pay
<Ian> IJ: We should also list Ripple or other cryptocurrencies where we
mention Bitcoin...same idea
<Ian> Manu: Alipay does a lot more than PayPal.
<Ian> ..you can do a lot more like linking to bank accounts
<Ian> ...you can pay credit card bills, etc.
<Ian> ...there are many things that Alipay does...clearly we need to
mention it
<Ian> ...we also need to break out the components of ALipay since
there's not just one thing that it does
<Ian> ...it does 3-corner model, 4-corner model
<Ian> ...so we should mention Alipay but do so in a way that is specific
to the particular function one can achieve through Alipay
Ian: My little bit of guidance would be - where it's a useful example -
look for other examples in the document and we can add Alipay alongside
other instruments.
... Where we have payment instruments known to other large markets -
MPesa - we should mention the relevant ones - we need to help
international audience understand that this is a global standard.
... You may be thinking of other things in Asia that are important to

<Ian> Manu: We don't have anything about Chinese market escrow
payments...those are different from many payment scenarios in US or Europe
<Ian> ...so it would be great to have that covered in the document
Ian: We have these phases of payments and we're trying to come up with
some narratives that illustrate the different phases in practice.

Ian: In that example, she uses a credit card - we don't want readers to
understand that we're not using just one type of payment.
... We need additional narratives to show how phases of payment work in
those scenarios.
... For example - here's a common scenario in China - section 3
describes phases and steps... then you write a story on "how" - using
Alipay, using the steps.

<Ian> Manu: +1 to having material in the document to emphasize it is
international...with examples from different countries.
<Ian> ...including China, US, and Europe at least
Ian: Happy to read and send in review comments.

<Ian> IJ: I will read it
Ian: One other thing - sounds like we're converging.
... Labels for alternative use cases... - Freemium offer, email offer,
motiviation will help us explain why there are two use cases - but
what's gone is any categorization of things.
... What's useful about my subheadings - manual selection, assisted
selection, that broke them up into smaller groups - conceptually easier
to grasp.
... When I didn't have good subsections, I put "general" - variation in
delay - added a little bit of explanation.

<Ian> Manu: I thought the categorization of related points was useful,
but I have a concern
<Ian> ...we can only have so many headings :)
<Ian> ...maybe the time to make the decision is once we have them all in
the doc
<Ian> ...category headings with only one thing takes up space
Ian: Yes, understand all that.
... All problems can be solved with an additional layer of abstraction. :)
... Maybe we could do a bottom-up one instead? One-time vs. Recurring
... What I found useful in adding the headers was to help see that there
is a theme emerging. This was intended to touch on a variation of that
... That let me see that we covered all the variations on that theme.
... I found it useful to see if we're repeating ourselves. If there was
a bit that was a theme - "Frequency" could be used. Or in "Motivation"
add a bit that says "relates to use case XYZ"
... Could be part of motiviation, making that a little longer - it might
be fine to include there.

<Ian> +1 to trying some ideas
<Ian> Manu: So to get to FPWD:
<Ian> - We need use cases for section 5
<Ian> - We need to experiment with the template
<Ian> - We need some real-world stories in section 6
<Ian> ...bitcoin, and an alipay scenario would be great
Ian: That sounds good to me - a lot of work from from you has gone into
listening. I'm not hearing objections to the direction - so let's keep
going and get it in front of the group.

<Ian> Manu: Alibaba had a comment about not mentioning
biometrics/2-factor...we need to get it in there
<Ian> ...DSR has suggestions about exceptions to get in there
<Ian> ...next big challenge will be to get review in a timely fashion
Ian: I'll read it and focus on look and feel - happy if you are taking
the lead on the actual use cases.
... ... and watching people's emails go by suggesting use cases... that
division of labor works works well for me.

<Zakim> ShaneM, you wanted to talk about agenda
ShaneM: In the meeting announcement - it said this meeting is 90
minutes, you may want to fix that
Received on Friday, 13 March 2015 04:42:55 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:08:33 UTC