Re: FYI: First Public Working Draft of Web Payments Use Cases

Hi Josh,

This is an official response to your comments on the Web Payments Use
Cases document from one of the document editors.

Thank you for your very thorough review of the Web Payments Use Cases
document. Many of the changes you requested have now been made. The
latest Editor's Draft can be found here:

https://dvcs.w3.org/hg/webpayments/raw-file/default/latest/use-cases/index.html

Responses to your comments below:

On 06/26/2015 04:50 PM, timeless wrote:
>> Carson (in New York City) sends money to Vladamir [sic] (in
>> Moscow) using his Ripple client, which converts the currency from
>> US Dollars to Rubels [sic] in transit.
> 
> Typically `Vladimir` Google says: Showing results for Vladimir 
> [191,000,000 results] Search instead for Vladamir [355,000 results]

Changed to Vladimir.

https://github.com/w3c/webpayments-ig/commit/c3db0feaa20d1ef03202255193b4b53003d7bd56

> `The ruble or rouble (Russian: рубль, rublʹ, plural рубли́, rubli; 
> see note on English spelling)`
> 
> plural: rubles

Changed to Rubles.

https://github.com/w3c/webpayments-ig/commit/9587345fd7c82effdf89d25ac4269b88b6ce5eb6

>> The roadmap will include payment schemes in use today (such as 
>> electronic cheques [sic], credit cards, direct debit, and 
>> cryptocurrencies) and those of the future.
> 
> w3c is en-us, and the web follows en-us: Google says "electronic 
> cheques" [6,160 results] "electronic checks" [233,000 results]
> 
> pattern: "checks"

Changed to checks throughout document.

https://github.com/w3c/webpayments-ig/commit/c3db0feaa20d1ef03202255193b4b53003d7bd56

>> The unbanked often live pay cheque [sic] to pay cheque [sic],
> 
> en-us/Google says: "pay cheque" [409,000 results] paycheck 
> [22,300,000 results]
> 
> pattern: "paycheck"

Changed to paycheck.

https://github.com/w3c/webpayments-ig/commit/c3db0feaa20d1ef03202255193b4b53003d7bd56

>> Section 2 defines basic payment terms.
> 
> Please make these things links.

Done.

https://github.com/w3c/webpayments-ig/commit/c3db0feaa20d1ef03202255193b4b53003d7bd56

>> A mechanism used to transfer value from a payer to a payee. 
>> Examples: Corporate Visa card, personal Visa card, a bitcoin 
>> account, a PayPal account, an Alipay account, etc.
> 
> you don't always use `etc.` at the end of examples, as below, I'd 
> suggest not including it above...

Removed 'etc.'

https://github.com/w3c/webpayments-ig/commit/c3db0feaa20d1ef03202255193b4b53003d7bd56

>> payment scheme
> 
> en-us warning: `scheme` is a Britishism, if you google "payment 
> scheme", the hits are all European. I have no idea what you mean and
>  respectfully request you find an appropriate en-us term for this. 
> Note: w3c is officially en-us and since this is designed as a w3c 
> document, it should adhere to this.

This is a term of art in the banking / payments industry:

https://en.wikipedia.org/wiki/Card_scheme

Would you prefer something like 'payment network rules'?

>> Activities surrounding and including a transaction (e.g.,
>> discovery of an offer, negotiation of terms, selection of payment
>> instrument, delivery, etc.).
> 
> pattern: e.g. ... etc.
> 
> Don't include both (see earlier flag for `Example:...etc.`)

Fixed.

https://github.com/w3c/webpayments-ig/commit/c3db0feaa20d1ef03202255193b4b53003d7bd56

>> The descriptions below only discuss the interactions between the 
>> payer and the payee.
> 
> payee is linked here, but not payer....

Fixed.

https://github.com/w3c/webpayments-ig/commit/c3db0feaa20d1ef03202255193b4b53003d7bd56

>> 3. An Overview of the Payment Phases
> 
> Doesn't cover pay-later cases such as Boleto [1] or really any house
>  billing system -- where goods / services are provided up front and 
> people settle debts ... somehow...

There is now a Boleto use case here:

https://dvcs.w3.org/hg/webpayments/raw-file/default/latest/use-cases/index.html#uc-invoices

Pay-later use cases are covered via the "Invoices" use case, IMHO. There
is nothing in the flow that prevents a merchant from providing
goods/services at any point in the process. We do say this in Section 3:

"In some cases, steps may happen in a slightly different order than
described below."

Is there specific language that you'd like to see in the spec?

>> Jill can't decide whether the dress displayed online is blue with 
>> black stripes or white with gold stripes,
> 
> this is cute, but I don't think future readers will get this Meme. 
> Unless you're willing to include a citation (which you could, but 
> please use web.archive.org to anchor it), then I'd suggest changing 
> it.

I added a link to Wikipedia to anchor it as I imagine that'll be
around as long as archive.org.

https://github.com/w3c/webpayments-ig/commit/8426cc75570bd628a9813a77780c2db3575ea1ed

>> That same evening at home, Jill logs into her account on the 
>> PayToParty Web site, adding her preferred items to her shopping 
>> cart.
> 
> `preferred` isn't the right word. She added the items she has chosen.
> I can prefer something out of my price range (and she's entitled to
> do the same).

Fixed.

https://github.com/w3c/webpayments-ig/commit/8426cc75570bd628a9813a77780c2db3575ea1ed

>> 3.1 Negotiation of Payment Terms Application of Marketing
>> Elements. The payer discovers and applies any loyalty programs,
>> coupons, and other special offers to the payment terms.
> 
>> 4.1 Negotiation of Purchase Terms Application of Marketing 
>> Elements: As Jill prepares to check out, PayToParty offers her a 
>> discount of 10% if she uses the store's loyalty card to pay.
> 
> There's a mismatch here. In 3.1 you used the word `applies`. Here, 
> you use the word `offers`.

The payee is offering a discount if a loyalty card is used.

The payer chooses to take advantage of the discount offer by applying
her loyalty card to the payment terms, thus lowering the final price.

I think it's right, does the above make sense to you?

>> Authentication to Access Instruments: Jill selects the PayToParty 
>> loyalty card, which she enabled with theft-protection [awk], and
>> is asked to input a code that is sent to her phone before the
>> purchase can be completed.
> 
> Google: "theft protection" -identity -car -auto -bicycle doesn't 
> yield `theft-protection` used the way you're using it.
> 
> You could (and should) mention Two Factor Authentication (2FA).
> Also, the code is really an anti-skimming feature, not an anti-theft
>  feature.
> 
> But the main problem ([awk]) is that Jill didn't enable the card, she
> got the card and enabled a feature for the card.

The text has been updated to be less awkward.

https://github.com/w3c/webpayments-ig/commit/8426cc75570bd628a9813a77780c2db3575ea1ed

>> Identity. There will be a consistent, interoperable identifier
>> used to identify the participants and accounts in a Web Payments 
>> transaction.
> 
> I somewhat object to `consistent`. The credit industry is slowly 
> moving to tokenized transactions. There are a number of variations of
> this, an old one is Secure Online Account Numbers....

Struck the word 'consistent'.

https://github.com/w3c/webpayments-ig/commit/8426cc75570bd628a9813a77780c2db3575ea1ed

>>> Secure Online Account Number service allows you to generate a 
>>> temporary card number for safer checkout—anytime you shop
>>> online. With Secure Online Account Numbers you can. Generate a
>>> temporary card number so your real account number is not
>>> revealed. Create and save a number for every online purchase you
>>> make.
> 
>> Website Penny uses the HobbyCo website to select a $15 model train 
>> for purchase. Goals rapid, widespread adoption.
> 
> I don't understand `Goals`, whose goals? How is this a goal? Why is 
> `rapid` not Capitalized?

The Goals were problematic and were removed in a set of edits that were
made last week.

https://github.com/w3c/webpayments-ig/commit/afa4b4959b92f38fdded727c39729342e587380c

>> Goals Improved user experience, Greater security, Innovation, 
>> Automatability, and rapid, widespread adoption.
> 
> why are words here randomly capitalized?

Removed.

https://github.com/w3c/webpayments-ig/commit/8426cc75570bd628a9813a77780c2db3575ea1ed

>> Exceptions No mobile phone connectivity (visiting a different 
>> country, trip occurs outside the range of a mobile network, etc.)
> 
> missing trailing period

Fixed.

https://github.com/w3c/webpayments-ig/commit/8426cc75570bd628a9813a77780c2db3575ea1ed

>> Freemium Ricki plays his favorite native app game and wants to 
>> upgrade his avatar with a few extra "power-ups." Clicking on a 
>> power-up displays the price.
> 
> I know you were taught to put punctuation inside quotation marks. 
> Please don't, it makes parsing sentences much harder (especially when
> silly spec writers actually have section headings w/ punctuation that
> they're really quoting... *sigh*).

Fixed.

https://github.com/w3c/webpayments-ig/commit/8426cc75570bd628a9813a77780c2db3575ea1ed

>> Goals Improved user experience, Innovation, and Transparency.
> 
> why are words here randomly capitalized?

The goals have been removed entirely.

https://github.com/w3c/webpayments-ig/commit/afa4b4959b92f38fdded727c39729342e587380c

>> E-mail [sic] A GroupBuyCo customer receives an offer by email to 
>> purchase the deal of the day.
> 
> Email (you aren't consistent within this one row...)

Fixed.

https://github.com/w3c/webpayments-ig/commit/8426cc75570bd628a9813a77780c2db3575ea1ed

>> Goals Improved user experience, Increased user choice, and rapid, 
>> widespread adoption.
> 
> why are words here randomly capitalized? (I'm not flagging all 
> instances, I'm randomly flagging...)

The text was semi auto-generated. The Goals entries have been removed
entirely.

https://github.com/w3c/webpayments-ig/commit/afa4b4959b92f38fdded727c39729342e587380c

>> Exceptions Software acting on the payer's behalf may keep track of 
>> exactly how much money the payer has and not allow them to process 
>> the offer.
> 
> `has` or `has available`?

Fixed to 'has available'.

https://github.com/w3c/webpayments-ig/commit/8426cc75570bd628a9813a77780c2db3575ea1ed

>> Security Automated purchases (e.g,. by a vehicle) should involve 
>> increased security (e.g., a second factor of authentication).
> 
> Why? It might be reasonable to say they should have more 
> Logging/Auditing. But I don't think that being asked to present my 
> Passport at every gas station is a good idea.

That wasn't the intent of the security note.

Changed 'should' to 'may'. Added 'logging'.

https://github.com/w3c/webpayments-ig/commit/8426cc75570bd628a9813a77780c2db3575ea1ed

>> Goals Increased user choice, Improved user experience, Innovation, 
>> Transparency, and Automatability
> 
> Missing period

Goals have been removed.

https://github.com/w3c/webpayments-ig/commit/afa4b4959b92f38fdded727c39729342e587380c

>> Trial-ware
> 
> Remove the dash [2]

Done.

https://github.com/w3c/webpayments-ig/commit/8426cc75570bd628a9813a77780c2db3575ea1ed

>> Accessibility For safety reasons, the interface used to interact 
>> with the digital offer must not distract the driver of the
>> vehicle. Voice controls and other techniques can be used to reduce
>> driver distraction.
> 
> Um. No [3]. Let's work on Vision Zero [4] instead of increasing 
> distracted driving fatalities [5].

Struck the last sentence. Changed the first sentence to "must not lead
to an increase in vehicle accidents."

https://github.com/w3c/webpayments-ig/commit/8426cc75570bd628a9813a77780c2db3575ea1ed

>> Privacy Protection Tibor orders assorted chocolates from CandyCo. 
>> CandyCo only needs Tibor's verified shipping address to send him 
>> the chocolates.
> 
> Why does CandyCo need a verified shipping address?

Changed to "tokenized shipping address" to ensure that his privacy is
protected.

https://github.com/w3c/webpayments-ig/commit/8426cc75570bd628a9813a77780c2db3575ea1ed

>> Need to Know PayCo is required to keep a certain amount of 
>> information on their customers for anti-money laundering / know 
>> your customer regulatory purposes.
> 
> It's unclear that PayCo is a payment processor and not a vendor.

Changed to: "PayCo, a payment processor, is required".

https://github.com/w3c/webpayments-ig/commit/8426cc75570bd628a9813a77780c2db3575ea1ed

>> Goals Improved user experience
> 
> missing period

Goals are now removed.

https://github.com/w3c/webpayments-ig/commit/afa4b4959b92f38fdded727c39729342e587380c

>> Seth participates in a loyalty program with his local grocery
>> store and can apply a variety of digital coupons when he visits
>> the store. Is a loyalty card a payment instrument, or a
>> credential?
> 
> A loyalty card is the wrong payment instrument. This is a store 
> Charge Card...

Some organizations bundle the store charge card with the loyalty
features (it's a two-in-one card). The question is more of a technical
ask: Do we want to model non-payment instrument cards as credentials? If
we do, how do we model cards that are both payment instruments and
things that contain other information (like stored coupons)?

I don't think the answer can be as simple as what you express above
because there are store charge cards that are also loyalty cards. The
problem may be with the terminology "loyalty card", as I expect most
everyone has slightly different definitions of what that is and isn't.

>> David wants to be able to manually arrange available payment 
>> instruments when they are presented to him. Why does this need to 
>> be standardized? Isn't this just a part of the wallet UI?
> 
> If I need to split a payment across three payment instruments...

That's not what this question is asking. The statement has to do with a
UI that allows the person to put their preferred card "on the top of the
stack" of cards that show up when they go to pay for something.

Splitting a payment across three payment instruments is something that
may require 3 round trips with the current architecture (as it's a
corner case based on the sheer number of transactions that clear using a
single payment instrument).

>> Lalana does not like to scroll. She wants the instruments she uses 
>> most often to appear at top of the displayed list of available 
>> payment instruments.
> 
> This should be done by the UA using frecency [7].

Agreed, but this document is about use cases, not solutions to use cases.

>> Wes has configured his debit card to require a fingerprint scan 
>> from his mobile device and a Universal Two Factor (U2F) device to 
>> be used when performing a purchase over $1,000.
> 
> I had a whole bunch of citations for why this stuff is awful 
> (MacGuyver [8], James Bond [9], Spaceballs, Demolition man [10]), but
> my computer ate the citations.
> 
> Note that banks discourage [11] certain "protections" because they 
> just put their customers at risk:
> 
> "There are ... concerns that customers under stress may be unlikely 
> to remember the reverse of their PIN, which may place them in greater
> danger should the perpetrator figure out what they are attempting to
> do and escalate the situation,"

Yes, and yet we have Apple Pay and an increasing number of fingerprint
scanners going into many of the new high-end mobile phones.

Biometric two-factor is a thing, so we have to mention it in the use
cases document, even if some of us don't think it's a good idea.

>> Nadia's bank asks her to use her two-factor authentication device 
>> and at least one of their in-branch retinal scanners or palm-vein 
>> readers before she is allowed to withdraw $25,000.
> 
> Defeating scanners is a fairly standard thing, which has been done 
> for decades. Roughly, any technology that encodes based on something 
> that is measurably you makes it fairly easy for someone to measure, 
> record, and reproduce for the purposes of claiming to be you.

True, but it cuts down on opportunistic fraud, which is primarily what
this sort of technology is intended to do.

>> In current online and offline payment transactions, biometric 
>> authentication can be used instead of password-based 
>> authentication: John registers his fingerprint with his payment 
>> provider so that he can just use a fingerprint to pay for
>> low-value items.
> 
> MacGuyver and gummy bear attacks against fingerprints

Yes, but the fingerprint for a low-value transaction is better at
protecting against opportunistic fraud than say, swiping a plastic card
that doesn't belong to you (credit cards in the USA).

>> Sarah registers her voiceprint and face with her payment provider 
>> for use in transactions greater than $1,000.
> 
> Sneakers [12] "Hi, my name is Werner Brandes. My voice is my 
> passport. Verify Me."

Counterpoint, randomly generated text that must be recited, analyzed by
a deep learning / neural feedback network:

http://www.ted.com/talks/jeremy_howard_the_wonderful_and_terrifying_implications_of_computers_that_can_learn?language=en

>> Rico buys a $5,000 car for his daughter through an online 
>> dealership. His payment processor requires a password plus two 
>> forms of biometric identification. Rico doesn't have hands, so he 
>> uses a face and iris scan to perform the authentication.
> 
> This is not two additional forms, it's only one, if someone captures
>  Rico, they have his face and iris. If they decapitate him, they have
>  his face and iris. If someone kidnaps a loved one, they can coerce 
> Rico.
> 
> Faces can be transplanted [13].

This use case is about accessibility. I don't expect there will be many
payment instruments with biometric two-factor that will be effective
against kidnapping, face transplants, or decapitation. Those aren't the
attacks biometric two-factor are intended to solve.

Is there a specific spec text change that you'd like to see here?

>> Biometrics can be utilized on Point of Sale terminals
> 
> Skimming point of sale terminals isn't new [14][15].
> 
>> 4 corner model "three-corner model payments" "four corner model 
>> payments"
> 
> please spell this consistently, and please introduce it before you 
> use it.

Consistency issue fixed. Three corner and four corner have been added to
the terminology section.

https://github.com/w3c/webpayments-ig/commit/8be538745b5891cfc3071491dd45f1a9220f7976

>> A payee may want to limit access to certain services to only those 
>> who they know can afford the good or service because the act of 
>> engaging the payer may be costly.
> 
> "engaging" is an odd word -- it's probably the wrong word too..

Changed to:

"...because the act of providing an acceptable level of service to the
payee during the pre-sale phase may be costly."

https://github.com/w3c/webpayments-ig/commit/8be538745b5891cfc3071491dd45f1a9220f7976

>> The bicycle is delivered a few days later with a QRCode attached
>> to the package that only Giralt can access.
> 
> I don't understand what this means. If you mean "included inside the
>  box", you should probably say this.

Removed the QRCode text as it was unnecessary. Initially, the QRCode was
encrypted to Giralt's device so that only he could tell what was inside
the box (without opening it). Clearly, that's overkill for just
expressing a physical good purchase.

https://github.com/w3c/webpayments-ig/commit/8be538745b5891cfc3071491dd45f1a9220f7976

>> Goals rapid, widespread adoption.
> 
> You probably wanted to capitalize the first word (Rapid) here...

Goals have been removed.

https://github.com/w3c/webpayments-ig/commit/afa4b4959b92f38fdded727c39729342e587380c

>> Electronic receipts will make it easier to track expenses, prove 
>> that certain purchases were made, file tax returns, and simplify 
>> management of unnecessary paper.
> 
> This is nonsense. People have been tracking expenses since the 80s, 
> filing taxes using electronic software since the 80s (1986) TurboTax
>  [16], importing receipts since 1994 (Quicken 3 [17]).

Changed the text to make it more clear that the important distinction is
"standard, machine-readable electronic receipts":

"Standardized, machine-readable electronic receipts could make it easier
to track expenses, prove that certain purchases were made, file tax
returns, and simplify management of unnecessary paper."

https://github.com/w3c/webpayments-ig/commit/8be538745b5891cfc3071491dd45f1a9220f7976

> The most important thing about a receipt is that it be meaningfully 
> signed and not trivially forgeable / maleable.

+1, I've added a note on security about non-repudiation and digital
signatures.

https://github.com/w3c/webpayments-ig/commit/8be538745b5891cfc3071491dd45f1a9220f7976

>> Bongani reserves a bus ticket online using his mobile phone. At
>> the bus terminal he taps his phone to a kiosk and receives a
>> printed physical receipt that he can use on the bus.
> 
> Electronic tickets [19] were common in the late 1990s. They have 
> already reached widespread adoption.

This is a use case from South Africa, where some buses still rely on
physical tickets, but you can buy them electronically.

>> Teo claims that a blender they purchased online was faulty and 
>> returns the product to the merchant.
> 
> Unless you're trying to honor Teo's gender preference (they) please 
> consider using a more traditional singular personal pronoun.

Changed to "he", although I still honor Teo's gender preference (just
not grammatically).

https://github.com/w3c/webpayments-ig/commit/8be538745b5891cfc3071491dd45f1a9220f7976

>> Janet selects her Discover points card
> 
> Discover is a Credit Card [20], not a points card -- often called a 
> Rewards Credit Card.

Changed "points" to "rewards" and added "credit card".

https://github.com/w3c/webpayments-ig/commit/8be538745b5891cfc3071491dd45f1a9220f7976

>> Terrific-Tools, Inc. ships the ax to Tom.
> 
> Suddenly Incorporated (quite late in the example).

Removed "Inc."

https://github.com/w3c/webpayments-ig/commit/8be538745b5891cfc3071491dd45f1a9220f7976

>> Anna is told that she will pay for the airline ticket with 600RMB 
>> and she confirms it.
> 
> This is less than 100 USD. That seems unlikely, TravelChinaGuide [21]
> shows 111 USD as the cheapest flight for Jul 21 from PEK to SHA. (It
> might be occasionally possible.)

Changed to 3,500 RMB.

https://github.com/w3c/webpayments-ig/commit/8be538745b5891cfc3071491dd45f1a9220f7976

Thanks again for the thorough review Josh, and apologies for the delay
in getting to your comments. It took a while to go through your
extensive set of suggestions and apply the ones that I could. Let me
know if you disagree with any of the changes of you see any more issues
that you'd like to have corrected.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Web Payments: The Architect, the Sage, and the Moral Voice
https://manu.sporny.org/2015/payments-collaboration/

Received on Friday, 3 July 2015 03:54:44 UTC