[use cases] Re: Use Cases - editorial observations.

On 03/29/2015 06:13 PM, David Ezell wrote:
> One overall comment (see a specific instance below) is that we should
> indicate where we think we need further review from external parties.
> This kind of tagging gives the clearest indication that we don’t
> think we’re finished yet.

I tried to sprinkle a couple of issues in the document to indicate some
areas where we'd like further external review and comments:

https://github.com/w3c/webpayments-ig/commit/62eecafe430ca1a77f02d9885a65445938dd8b77

> _Section 3_
> 
> “person, organization, or software agent)” – no need for the closing 
> parenthesis.

Fixed through another review comment.

> “ACH and SEPA” – would add “For instance,” before the sentence.

Used "In addition", as "For instance" sounds strange due to the use of
"For example" in the previous sentence. The language is still a bit awkward.

https://github.com/w3c/webpayments-ig/commit/7a94bdafdc538875cbb659f5c7e84422e1ee4b1e

> “regulatory block” – sounds like a useful term for “runtime
> exception caused by a regulatory infraction”

Are you requesting that we add this to the glossary?

> I’m not really comfortable with the implied ordinality of “first, 
> second, third…” with regard to phases.

While I agree with the notion that we don't necessarily want to require
that one phase must be performed before another phase, there aren't any
flows that we have currently that don't fit into the "first, second
third..." layout we have right now. We should discuss this on the use
cases TF call.

In order to get rid of the "first, second, third..." ordinality, a
payment flow that doesn't fit into that model should be presented. If we
can't find one, that would be a pretty powerful statement in support of
the current simplified model.

> _Section 3.1_
> 
> “payer will be authenticated by the payee” I’m not sure the payee 
> need directly to authenticate.

You're right, that bit has been reworded to:

"The payee may require the payer to authenticate themselves."

https://github.com/w3c/webpayments-ig/commit/7a94bdafdc538875cbb659f5c7e84422e1ee4b1e

> _Section 3.2_
> 
> “*Discovery of Accepted Schemes” -**I believe there is also a 
> dependency on the “marketing elements” from 3.1: coupons or loyalty 
> may or may not partially define the accepted schemes.*

Added something to the effect of "...which loyalty programs are acceptable".

https://github.com/w3c/webpayments-ig/commit/7a94bdafdc538875cbb659f5c7e84422e1ee4b1e

> *String “*The payee selects one or more payment instruments)/tref>” 
> appears in FireFox.

Fixed in a previous review edit cycle.

> “The issuer of the payment instrument authenticates the payer” –
> this statement shows more or less what I was talking about in Section
> 3.1. I think someone else pointed out that “issuer” doesn’t appear in
> the list under “Terminology”.

We only mention "issuer" in the document once. Rather than add a term to
the glossary for issuer, in the name of simplifying the document, I
removed the instance where we used "issuer" in the document.

https://github.com/w3c/webpayments-ig/commit/7a94bdafdc538875cbb659f5c7e84422e1ee4b1e

> “This authentication with the payment processor is distinct from any
>  authentication required by the payee (e.g., a merchant verifying a 
> password on a payer's user account).” – when do merchants do this? 
> I’m not familiar with any public (as opposed to bespoke) payment 
> systems that do this kind of thing.

I updated the text to remove the potential for misunderstanding what
this statement was trying to say:

"a merchant verifying a password on a payer's user account when they
login to the merchant website."

https://github.com/w3c/webpayments-ig/commit/7a94bdafdc538875cbb659f5c7e84422e1ee4b1e

> _Section 3.3_
> 
> Authorization of Transfer – it seems that the payee is the one that 
> needs to be notified.

Fixed.

https://github.com/w3c/webpayments-ig/commit/7a94bdafdc538875cbb659f5c7e84422e1ee4b1e

> Completion of Transfer – doesn’t mention who gets notified.  I think 
> it’s payer and payee.  It seems that Completion of Transfer may be 
> underspecified with regard to the mechanics.

Added some text to say who gets notified. I tried to specify the
mechanics a bit more.

https://github.com/w3c/webpayments-ig/commit/7a94bdafdc538875cbb659f5c7e84422e1ee4b1e

> _Section 3.4_
> 
> “Fouth phase” should be “fourth phase”

Fixed in a previous set of review comment edits.

> Delivery of Product – for some reason this doesn’t seem as though it 
> belongs.  Once processing has completed, the payee has an obligation
> to deliver goods, but it’s not a process that we care about.

We care when a digital proof of payment may be required to access a
digital good. Added this sentence to make it more clear why we're
including this particular item:

"A digital proof of payment may be required to access the product."

https://github.com/w3c/webpayments-ig/commit/7a94bdafdc538875cbb659f5c7e84422e1ee4b1e

> *_Section 4.3_*
> 
> I’m sure the team must have discussed the fact that there is no 
> indication of “regulated agencies” in this example.  For instance, 
> completion of transfer with such an addition would read:
> 
> *Completion of Transfer*. Since Jill's PayToParty loyalty card 
> operates as a credit card, the PayToParty */acquirer/* immediately 
> credits PayToParty with the purchase amount and the funds will be 
> moved from */the issuer bank/* into PayToParty’s bank account at the
>  end of the week. Jill will pay off the credit line */at her issuer 
> bank/* at the end of the month.
> 
> I’m not insisting that we use these terms, simply that without the 
> entities clarified it seems very, very vague.

I'd argue that it's vague from a payment professional perspective in the
same way that "If you want to stop the car, slam on the brakes" is vague
to a mechanical engineer.

Most readers of the use case won't necessarily care about those details
yet. To come at it another way - adding terms like 'acquirer' and
'issuer' will add heft to the document and will be difficult for
non-payment professionals to grasp.

> (Note: it might be helpful in FPWD to have a way to say (like 
> Wikipedia) “needs clarification”, etc.)

Review comments usually say stuff like this when something needs
clarification?

> _Section 6.2.2_
> 
> Q: Is a loyalty card a payment instrument or a credential?
> 
> A: Neither – it is an account identifier, closely related to a 
> credential, but much more specific.  Payment instruments (normally) 
> refer to more general things backed by regulation.

An account identifier can be a credential (per the Credential CG's
definition of "credential"). Agreed that a payment instrument is
probably a different beast than a loyalty card.

What about an "Amazon Visa Card"? Is that a loyalty card? You get
discounts on Amazon when you use it, right? It's also a payment instrument.

> “David wants to be able to manually order available payment 
> instruments when they are presented to him.”  I agree this is part of
> the wallet UI, but I think we need to make statements about the UI
> with regard to Accessibility.

+1 - do you think we need to remove the question from the document?

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: The Marathonic Dawn of Web Payments
http://manu.sporny.org/2014/dawn-of-web-payments/

Received on Tuesday, 31 March 2015 04:10:37 UTC