A (controversial) proposal for what should be in/out of scope

Many of the topics discussed in the Web Payments Interest Group fall into
the category of "best practices" we might like various parties in the
payment ecosystem to implement.

Arguably, the W3C should only focus on standards that increase
interoperability between systems that need to communicate.

Some of the topics we talk about wanting to improve are features (e.g.
authentication and fraud prevention mechanisms, subscriptions, etc) or
limitations (e.g. using card numbers alone to authorize payments is
insecure) of the payment instrument, so that's not the purview of the W3C.
If users or governments want more secure, faster, better, cheaper payments
they need to switch or upgrade their payment instruments.

Problems that are in scope for the W3C Web Payments Group:


   -

   Filling out credit card and other payment details in forms is annoying.
   It would be better if the website could request a payment in a standard
   way, using one of a given list of payment instruments. The user agent can
   pass that request to a 3rd party service, or a built in one, that knows how
   to initiate payments with various instruments (push, pull, credit, debit,
   etc, all of which have different properties).
   -

   Too many parties to the transaction need to request, validate, and store
   a lot of information about the payer. They should be able to rely on signed
   attestations about the payer from trusted parties alone so that the data
   can be validated and stored by fewer parties who can focus on making that
   service better and more secure.
   -

   User agents may have security-related information or capabilities (e.g.
   smart cards, biometrics, etc) that websites may want to access. That said,
   allowing them to request access to this data might be a terrible idea.
   -

   (anything else?)


Note that the above should probably be different standards, developed by
different W3C working groups.



Topics that are arguably out of scope for the W3C Web Payments initiative
include:


   -

   Authentication, including multifactor. This is up to the payment
   instrument. If instruments want to upgrade their security they can. If
   users or governments want them to improve their security they need to take
   that up with the instruments, but it’s not for the W3C to do.
   -

   Tokenization. This is another feature of the payment instrument. Some
   instruments will support this, some will not. Users and governments will
   choose what instruments they want to use or support based on the features
   they offer.
   -

   Active fraud prevention. Once again this is up to the payment instrument
   or processor.
   -

   Proof / description of purchase. This format is up to the merchant.



This is a personal proposal based on what I've heard from the discussions
during this face to face meeting. This comes from me personally, not from
Ripple Labs.

The proposal will continue to be edited here:
https://docs.google.com/document/d/10T3z25zzBoorOaOUuQiJCu7gZXQeSvUSqYpJmsqrE6Y

-- 
Evan Schwartz | Software Architect | Ripple Labs
[image: ripple.com] <http://ripple.com>