Re: Draft requirements for discussion at the WPWG FTF meeting

On 02/18/2016 10:22 PM, Ian Jacobs wrote:
> Here is the resulting draft, which I hope can help us structure some
>  of our conversations: 
> https://github.com/w3c/webpayments/wiki/WPWG-FTF-Feb-2016-Requirements
>
> It is important to note that this is NOT a proposal for a set of
> requirements. Rather, it is a list of requirements that I want the 
> group to discuss to see whether there is consensus. I say more about
>  this in the document.

Thanks for putting this list together, Ian. In time, I think we'll get
to every bullet item you placed into that list.

That said, I don't see how a discussion about the following requirements
at the face-to-face helps us get to a FPWD by March 2016 (we should
de-prioritize these particular questions because the spec proposals are
already in agreement on them, or the spec proposals don't suggest how to
address the issue and don't need to by the FPWD publication):

General design goals
* Limit API capabilities to those that are useful independnet of which
  payment application the user selects.

General requirements
* The API must not expose user data without user consent.

Payment Scenarios
Requirements
* It must be possible to initiate payment without specification of the
  final amount.

Shipping Information
Assumptions

Purchase cost for physical goods often depends on shipping information.
Requirements

* For transactions where a shipping address is required before
  authorizing payment, it must be possible to satisfy that constraint.
* It must be possible to update the final price based on shipping
  information.
* It must be possible to change the shipping information any number of
  times as part of a single user experience for a given transaction.
* It must be possible to update the shipping information without
  updating the price.
* It must be possible to update payment request data asynchronously
  (e.g., price based on shipping information). (The corollary is the UI
  should not be blocking.)

Questions

* Does sharing shipping information with the merchant to enable
  calculation of the final price constitute explicit user consent?

Additional Payment Request Information
Requirements

* The API must include a standard field for an email address (for
  communication with the customer).
* The API must include a standard field for a telephone number
  associated with shipping.
* The API must include a standard field for a transaction identifier.
  Because only some payment applications require a billing address,
  that should not be a mandatory feature of the API.

Payment Application Identifiers
Requirements

* It must be possible for anyone to mint a payment instrument
  identifier for any payment instrument.
* It must be possible for the Working Group to mint a payment
  instrument identifier for any payment instrument.
* It must be possible for the anyone to mint a payment instrument
  identifier for an instrument under their control.
* It must be possible to use a standard short string (e.g., "visa") to
  identify a payment instrument.
* It must be possible for someone minting a non-standard identifier to
  make it globally unique in a cost-effective manner.

Version information
Requirements

* The API design must enable the addition of features in future
  versions. (Forward-compatibility.)
* It must be possible for merchants to query a browser to determine
  which features the browser implements.
* The API must therefore specify clearly which features may be queried
  by merchants.

Payment Application Registration

Questions

* Do we need to specify anything around storage of payment app info?
* How are payment apps validated at registration (to avoid spoofing,
  for example)?

-- 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, 19 February 2016 04:45:23 UTC