[ISSUE-9] Re: Web Payments Use Cases 1.0, W3C First Public Working Draft 16 April 2015

On 04/16/2015 08:04 PM, Steven Rowat wrote:
> This is my first posting to this 'comments' list (I saw the
> announcement on the public-webpayments list).

Hi Steven, thank you for your comments. This is an official response
from one of the editor's of the document. I'll try to process your
comments by channelling what I believe to be the consensus of the group
to date. If you disagree with any of my responses, you may request that
the issue is raised to the group for an official group position on your
concern.

> A. Viewed in my standard Browser (Firefox, Mac OS) the draft is
> peculiar in having not enough vertical spacing between the lines. I
> know some W3C documents do this, but it is annoying. HTML/CSS allows
> you to control line leading (vertical spacing) and I suggest you
> increase it to 1.3 or 1.4. It looks like it's at 1.0. This causes
> some of the link underlining to run through the tops of the
> characters in the line below, making them hard to read.

The line-height has been changed to 1.4.

https://github.com/w3c/webpayments-ig/commit/2cacf81e3c8c078cdf55d2f54c2bd225f3face39

> B. The choice of the words 'payer' and 'payee' is unfortunate; they
> are too similar and my mind reels in trying to separate them if
> there is a problem in interpretation. See for instance my concern
> with section 3.2 below; I think if the words had been easily
> separable -- like perhaps 'merchant' and 'customer', though I suspect
> there are objections for those as well -- then that section would
> have been easier to understand.

Yes, we'd love it if there were a better set of terms. We had tried
merchant and customer, but the problems with those words is that
transactions (such as peer-to-peer transactions) don't always have a
merchant and customer. We tried to keep the use cases as generic as
possible, thus the 'payer' and 'payee' usage.

> On first reading, it looks like there's an error in the second
> bullet point... Should it begin 'The payer selects...' instead of
> 'the payee selects...'?

Yes, there is an error. Thanks. Fixed.

https://github.com/w3c/webpayments-ig/commit/2cacf81e3c8c078cdf55d2f54c2bd225f3face39

> As it stands: "Verification of Available Funds. The payee may need
> to provide a proof of funds or a proof of hold to the payer before
> finalizing payment and delivery of the product."

This was another payer/payee swap error. Fixed.

https://github.com/w3c/webpayments-ig/commit/2cacf81e3c8c078cdf55d2f54c2bd225f3face39

> Typo error I believe: "Refunds. At time exceptions..." should be
> "Refunds. At time[s] exceptions..."

Fixed.

https://github.com/w3c/webpayments-ig/commit/2cacf81e3c8c078cdf55d2f54c2bd225f3face39

> This sentence is nonsensical -- try making sense of the three 'is'
> verbs: "General feedback is requested as to whether or not this
> section is helpful in grounding the payment phases and steps in a
> real world use case is helpful this early in the document."

You're right, attempted to fix the language. See if you're happy with
the new language.

https://github.com/w3c/webpayments-ig/commit/2cacf81e3c8c078cdf55d2f54c2bd225f3face39

> But, hold on, another problem has cropped up as well -- in 4.2, when
> does PayToParty 'offer' her payment? Before or after she presses the
> button? Isn't the 'offer' actually after she presses the button? If
> so, then "Discovery..." in 4.2 is wrong -- it hasn't been offered
> yet. Or, again, are there steps missing that aren't listed?

The word "offer" in that context is problematic. I changed the phrasing
from "PayToParty offers her" to "PayToParty accepts" to attempt and
avoid the type of confusion the phrasing caused you. Let me know if that
helps.

https://github.com/w3c/webpayments-ig/commit/2cacf81e3c8c078cdf55d2f54c2bd225f3face39

> On this basis, the first 'utilize' under 'Connectivity' is not
> correct and should be reverted to the simpler 'use'.

Fixed.

https://github.com/w3c/webpayments-ig/commit/2cacf81e3c8c078cdf55d2f54c2bd225f3face39

> A. Why is there a Privacy point under Kiosk, but not under Website?
> Are people going to Websites not entitled to privacy?

Further up in the document we state that some of these rows, like
privacy, are not specified for each use case. When it makes sense to
mention some aspect of privacy, we do so, at other times we don't. The
same goes for security, exceptions, etc.  In this particular use case,
Cory is using a loyalty card which enables the merchant to track him,
thus the privacy warning. The website use case doesn't use a loyalty
card, which is why we don't raise privacy implications there.

That said, there are many privacy implications in play. Did you have a
particular privacy implication in mind. Could you suggest some text to
put in the privacy portion of the website use case?

> First, I assume you mean 'some [hold funds] are merely there...";
> but even if so, I'm still confused by the rest of the sentence. Is it
> the payee who is protected (could this be another inversion of
> payer/payee error?). If not, if it's the payee being protected, what
>  sort of questionable judgment is possible in this circumstance?
> Perhaps you mean that the payer changes their mind? That they
> question their own judgment? But this is not the same thing as the
> payer having 'questionable judgment', which would be a decision by
> some third party that the payer's judgment was questionable. I
> suggest re-writing to clarify...

Reworded, let me know if the rewording works for you.

https://github.com/w3c/webpayments-ig/commit/2cacf81e3c8c078cdf55d2f54c2bd225f3face39

> Registration-less I don't agree that this case is non-essential. I
> would like it moved to essential. It seems core.

I agree, but the group decided that it was not essential at the
face-to-face meeting in Utrecht. You will have to make a case for why
you think it is essential. If you do that, and we haven't considered
your reason, I can re-open the issue with the group under the W3C
Process rule related to "reopening an issue due to new information that
the group hasn't considered".

> Coupons & Loyalty cards Especially given that Registration-less is
> non-essential, I object strongly to this one being essential. Taken
> together (6.1.2.1 and 6.1.3), it looks like a strong bias in favour
> of the merchant over the customer. I think this is a mistake.

I agree, but the group has decided that this is essential. Please
provide a more detailed analysis and I can open an issue based on the
reasoning in the previous paragraph.

> By this point I'm beginning to realize the level of detail is too
> much -- I can't read the same format over and over and still
> comprehend it. So, yes, I think there are too many examples...(I
> believe you asked about this earlier).

Do you have a suggestion on what we could change to make this better,
other than cutting down on examples? Each example is supposed to expose
something unique that the other examples do not. Do you see duplication
anywhere? We can cut out the duplicated bits, or perhaps do some merging.

> Overview thought: maybe the four main steps that are laid out at the
> start --  Maybe these should divide the entire document. Of course
> there would have to be an abstract or summary of them at the top,
> but after that, instead of iteratively going through all four steps
> -- what -- thirty-five times?

Hmm, there is clearly a problem here, but I'm trying to understand the
specifics. I think the document is already laid out in the way that
you're describing. We don't go through all four steps 35 times. There is
a section for each phase, and a subsection for each step in each phase.
Then there are use cases in each step. So, I believe we're doing what
you want, but you didn't get that impression from looking at the
document (and that's bad).

Could you take a look at the document again and let us know if there is
still a problem?

> Or maybe the layout is fine, and it's just that there are too many
> examples for one sitting. And maybe that's necessary; maybe it's a
> two-sitting document. Not sure.

Unfortunately, the number of examples are going to grow because each one
is different from the other and is designed to surface a new requirement
in the payment architecture we're going to have to describe.

Thank you for your review comments, Steven. Feedback on the questions I
have for you above would be appreciated. We are tracking your review
comments via this issue:

https://www.w3.org/Payments/IG/track/issues/9

... and will close the issue once we're certain that you're happy with
this round of changes.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.

Received on Sunday, 19 April 2015 17:09:16 UTC