Use Cases - editorial observations.

Dear Use Cases TF members:

Thanks to everyone who has given the use cases review.  There is quite a bit here, and I think it is taking shape nicely.  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.

Best regards,
David


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

Section 3
"person, organization, or software agent)" - no need for the closing parenthesis.

"ACH and SEPA" - would add "For instance," before the sentence.

"regulatory block" - sounds like a useful term for "runtime exception caused by a regulatory infraction"

I'm not really comfortable with the implied ordinality of "first, second, third..." with regard to phases.

Section 3.1
"payer<https://dvcs.w3.org/hg/webpayments/raw-file/default/latest/use-cases/index.html#dfn-payer> will be authenticated by the payee<https://dvcs.w3.org/hg/webpayments/raw-file/default/latest/use-cases/index.html#dfn-payee>" - I'm not sure the payee need directly to authenticate.

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.

String "The payee<https://dvcs.w3.org/hg/webpayments/raw-file/default/latest/use-cases/index.html#dfn-payee> selects one or more payment instruments)/tref><https://dvcs.w3.org/hg/webpayments/raw-file/default/latest/use-cases/index.html#dfn-payment_instrument>" appears in FireFox.

"The issuer of the payment instrument<https://dvcs.w3.org/hg/webpayments/raw-file/default/latest/use-cases/index.html#dfn-payment_instrument> authenticates the payer<https://dvcs.w3.org/hg/webpayments/raw-file/default/latest/use-cases/index.html#dfn-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".

"This authentication with the payment processor<https://dvcs.w3.org/hg/webpayments/raw-file/default/latest/use-cases/index.html#dfn-payment_processor> is distinct from any authentication required by the payee<https://dvcs.w3.org/hg/webpayments/raw-file/default/latest/use-cases/index.html#dfn-payee> (e.g., a merchant verifying a password on a payer's<https://dvcs.w3.org/hg/webpayments/raw-file/default/latest/use-cases/index.html#dfn-payer> 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.

Section 3.3
Authorization of Transfer - it seems that the payee is the one that needs to be notified.

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.

Section 3.4
"Fouth phase" should be "fourth phase"

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.

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.

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

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.

"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.

________________________________
This electronic message, including attachments, is intended only for the use of the individual or company named above or to which it is addressed. The information contained in this message shall be considered confidential and proprietary, and may include confidential work product. If you are not the intended recipient, please be aware that any unauthorized use, dissemination, distribution or copying of this message is strictly prohibited. If you have received this email in error, please notify the sender by replying to this message and deleting this email immediately.