Web Payments Charter Development CG Wiki Page

This page is keeping track of the different comments received on the different drafts of the charter.

Don't hesitate to send your comments to:

• The group: public-webpaymentsigcharter@w3.org (archived)
• The chairs:
  • Stephane (boyera@w3.org)
  • Wendy (wseltzer@w3.org)

Comments received on v0.3 (published 4 July 2014)

Charter on which those comments apply: V0.3

Comments received on v0.2 (published 4 June 2014)

Charter on which those comments apply: V0.2

Comment

a point on Web payments terminology -- building off of ISO20022 and ISO29115 should be added

Proposed Change

ok added a point in the deliverable section about terminology

Comment

In the one of the IG’s tasks, It would be good to clarify whether there is any specific categories of "use cases" that could be in more focus.

Proposed Change

agreed and this is now mentioned in the description of the corresponding work item

Comment

we also think using the term non-traditional currencies could be better because it could apply to non-fiat money, digital, virtual and crypto currencies and etc.

Proposed Change

ok will clarify the term

Comment

The case of utility payments should be considered. In most countries, there are specific forms used for utility payments. while these forms diverge from country to country, the information carried is the same and could be standrdized for greater interoperability for utility payments

Proposed Change

added a section in hte web payments roadmap

Comment

It might be interesting to consider extra services around transaction such as invoice storing, warranty storing, recurring payments, utility payments etc.

Proposed Change

added a section in the web payments roadmap

Comment

The part on user data should be expanded. User data is a very important topic that covers 3 major aspects

• personnal data that have value for merchants/payment providers: knowing what your customer buys, etc to have a better profile that could lead to personalized service. the balance here is user privacy vs data monetization
• legal data: some data must be provided to the merchants or the transaction cannot be made for regulatory reasons: e.g. age when buying alcohol
• anti-fraud data: some data are essential for fraud detection (e.g. geolocation), and the payment provider may refuse to proceed with the transaction if they are not provided

this topic is essential to consider as part of this activity

Proposed Change

added a section in the web payments roadmap & delvireable

Comment

wallet concept is applicable to both merchants and users. From merchants perspective, being able to support multiple payments transparently is essential. In the same way, being able to mange transparently things like coupons, loyalty points (in both ways for payments and for reward) is essential. Standardization in protocols & format for such elements (coupons, loyalty) might be interesting to consider. In the same way, connection between banks and merchants (or more generally merchants with service porviders including e.g. accountancy services) is potentially interesting topic.

Proposed Change

added mention of wallet for merchant in the wallet seciton of delivreables

Comment

• Section 2, under “1 Web Payments Roadmap” – suggest a new bullet under “Increase user protection…”: “Reduce payee exposure to risk from fraud.”
• Section 3.2 – suggest we add “Merchant Customer Exchange (MCX)” for outreach. http://www.mcx.com/

Proposed Change

ok to both

Comment

I think it would be useful for the IG to explicitly state whether "offline" payments are in scope and if so what work will be undertaken in this area. It is common for most payments systems to support the concept of floor-limits and stand-in for specific transaction scenarios which means the transaction is concluded without the full authorisation request/response loop being completed. How this will be dealt with by Web Payments should probably be in the group's agenda.

Proposed Change

ok to add mention of off-line payments. This is now explicitly stated in the description as well as roadmap deliverable. mentinoed also the speicfic floor-limits and stand-in in the scenario to consider

Comments received on v0.1 (published 15 May 2014)

Charter on which those comments apply: V0.1

Comment

Change the scope section to mention credit transfer and direct debit in payment instrument, and B2B and B2B2C in scenario/

Proposed change

First sentence of the scope to become: "The Web Payments Interest Group's scope covers payment transactions on the Web over a variety of devices (computer, mobile, tablet, etc.) and channels using a variety of payment instruments (credit cards, credit transfer, direct debit, loyalty cards, coupon, new payment systems such as e.g. Paypal, Google wallet, etc., new cryptocurrencies such as e.g. Bitcoin, Ven, etc.). It also covers business-to-person (B2C), business-to-business (B2B), Business-to-Business to consumer (B2B2C), and person-to-person (P2P) transactions, as well as physical (payment at physical shops) and online payments for physical or digital goods, including in-app payments."

Comment

One topic you may want to consider (and perhaps you already did) is the aspect of payment privacy. I believe it may be worth highlighting how (if?) your work plans to address the inherent loss in privacy into account as payments move away from cash to any kind of logged transaction.

Proposed change

Privacy aspect is very important. This should be highlighted in a better way in the deliverables (where it is just mentioned so far in the identity, authentication, security section) and in the scope section

Comment

Section 2  : the label ‘Web Payments Architecture’ does not really reflect the scope of that item. Something like ‘Web Payments use cases and requirements’. Or do we really want to design an architecture ? in that case it should be added in the list of items delivered.

Related Comment:the overall role of the IG shuold be clarified to state whether W3C is going to standardize payment process and transactions, or only interfaces between web applications and payment processes Related Comment: are cryptocurrencies (validation etc.) part fo the targeted work?

Proposed change

this section (architecture) needs to be reworked to describe in a better way the role of the IG. The aim is not to describe a new architecture, but to identify the place of actions of W3C Web Payments activities, and the relation with the different stakeholders. In particular the proposed role of the future W3C Web Payments activity is to explore interoperable interfaces between web applications and payment transactions/payment systems. It is not to work on a new payment transaction scheme, or work on existing payment solutoins such as cryptocurrencies. This will be clarified in the scope and deliverable section.

Comment

Section 3.1 : you may add the Web Security IG as a possible group to interfere with.

Proposed change

yes will add "Web Security IG Review on security considerations for Web payments"

Comment

Section 5 Communication : mails are going to the web payment community group public-webpayments@w3.org (archive).. Is that a consensus that the IG will actually re-use that CG structure or a copy and paste error ? Other links such a web page and wiki are not pointing on the CG.

Proposed change

This was a mistake. The public mailing-list of the web payments ig will be public-webpayments-ig (same for member, member-webpayments-ig)

Comment

The charter should mention the place of regulations in the targeted work related comment: - [scope] Is it too broad to say all devices and all legal payment options?

Proposed change

The objective is to define technologies and overall architecture that while not dedicated to work under specific regulatinos, is flexible enough to be adapted to all regulations. It will be therefore essential to take into account existing regulationr equirements in use-cases to ensure that the proposed technical standards can cope with existing requirements. This will be clarified in the scope section.

Comment

- Identity: I would be mildly cautious about this area; it's such a huge topic and I reckon this group could be in danger of focusing on it too much if conversations start in a particular way. I am sure you are well aware of all the foundations working on this topic, including IETF and Open ID, so as long as these guys are included (and targeted) and much of the work in this area is placed on their shoulders (or on W3C Crpyto group?) then I think it should be ok.

Proposed change

I agree that managing identity on the web is a topic that is far bigger than its application on web payments. The aim of this group is not to tackle this aspect, but to identify requirements and needs for web payments. This group will ensure that work developed in this area by others (notable the one you are citing) are compatible and take into accounts web payments use-case. This is slightly clarified in the bullet point of deliverables 4 "Review existing Identification mechanism and identity providers on the Web and whether they fit with payments requirements in terms of privacy and security. Develop requirements and use-cases otherwise to seed new work in the area." I will clarify this further.

Comment

I think missing groups here are: Open ID Foundation, FIDO (maybe), groups within the W3C (crypto, security etc.), and maybe the EU?

Proposed change

we will add open id, fido. W3C groups are already listed (except seucirty ig that will be added). For the eu or other regulatory bodies, we expect to have them aprticipating in the work.

Comment

summarizing the proposed change in Joseph Potvin's proposed edits

• scope section:
  • mention of specific payment instruments should be removed, and
  • more emphasis should be put on web payments and web-connected devices.

• more details should be put on the liaison statement to describe better the type of organizations targeted

• success criteria section: greater emphasis should be put on aligning and linking with non-w3c groups and communities

• deliverable section: more details should be put in the architecture point on the respective roles of the different parties with regards to the different attributes of price.

• liaison: more details on unicitral group targeted should be provided

Proposed change

one by one:

• I believe it makes sense to illustrate with some examples the type of payment instruments we are considering. But it should be clearly mentionned that those are juste example. All mention of trademark should be removed. The use of the word cryptocurrencies is still underdebate. Letting it in for now
• I agree that a greater emphasis on web payments makes sense
• I'm happy to develop the description of liaisons
• In the success criteria, the importance is on coordinating activities within W3C. Liaisons are in place to coordinate at the group levels activities with non-W3C groups. The proposed change mix the two and requires that members are active in non-W3C groups. I propose to keep the separation clear (ie reject this proposal)
• concerning the role of the different parties, the proposed change seems very specific with a very specific definition of attributes of prices. Given the scope of the charter, i believe this is too specific.

I'm waiting for more input from other members whether we should explicitly put this item in the charter

• concerning the liaison, i believe it is a good idea to be more specific in the group targeted, so i will implement the proposed change.

Comment

First, in "1.1 Success Criteria" (or maybe in an introduction or somewhere else) I would think that one measurement of the success of the Interest Group would be that Web Payments are used more and more widely on the basis of the output of the Interest Group (ie not just more and more card payments over the internet). But maybe you see this as a consequence of the work of the Interest Group and not something that is directly in your hands, which I would understand.

Proposed change

I think that we should put some sentences in the scope to mention this objective. However, putting this in the success criteria is largely outside the power of the group. Success criteria is more the results of the group, while better web payments is more an outcome that will result if there is a general adoptin of the results of the group.

Comment

Secondly, in "2 Deliverables" it might be helpful to prepare a summary of the problems with web payments in the past and the barriers that you can identify for the future. In some cases this will be technical (eg security, communications protocols, authentication etc), but I would think that in some cases it would be about diverging incentives such as the risk to the income of banks, who control much of the payments chain. Again, maybe you will feel that this is outside the mandate of the Interest Group, so I leave it to you.

Proposed change

I think this is a great idea: developing a state of the art of web payments summarizing technical and incentives challenges. Before adding a specific point, i will wait for the input of the community

Comment

Finally, I wonder if it would not also be interesting in section 2 to identify the provision of information in the list of topics. For example, a number of companies (I think one is called Star Money) now offer services to allow consumers to see a summary of the balance on their different bank accounts (even in different banks), the latest payment transactions that have been made and some sort of classification of payments etc. This requires interaction with the different banks concerned and gives value-added to the consumers. However, this is not strictly speaking a payment process (more an information process) and so you might prefer not to address it.

Proposed change

If i understand correctly, it is about standards for banking information access and representation ? I don't know to be honest how important is this topic for the actors, as it is the first time i see it mentioned. But i understand the value, particularly, if you think of a wallet approach where the wallet needs to interact with different payment provider. LEt's see what the community feels about this

Comment

we think it would be nice if the P2P would include Diaspora payments, meaning, low value, potentially high volume transactions, being conducted by a sender in one country back to their home country to support their family.

Proposed change

I believe this is more a use-case than a specific work focus. My feeling is that the work items are related to micro-payments and cross-boundaries/international payments. I'm happy to mention these topics.

Comment

include B2B use cases the scope

Proposed change

ok makes sense

Comment

clarify somewhere that "browser" is used to refer generically to web user-agent functionality that may be used in an actual web browser, a hybrid app, or an installed web app related comments:

• In addition we need to pay attention to the term "web payment" which is commonly associated with payment made on Internet only while web technologies are more and more used in face to face payments. It's important that we include those use cases in our work.
• The use of 'the Web platform' continues on through the text. Is it wrong to assume that most people will associate 'Web platform' with a network abstraction? Again 'Web technologies' would allow the scope be widened to what already gets used (in places).
• in the Scope, 'payment transaction s on the web' doesn't suffice as a scope anymore, IMO. We are using web technologies for proximity payments which do not 'go over the web', but still are based on web technology to harmonize transactions across the physical and the virtual world.
• Web Payments are not just browser based I think. We need to think whether we consider webpayments on mobile for example as browser

based or not. But if we want to include things like NFC payments in scope, browser won't be used...

Proposed change

Proposed change: 'The Web Payments Interest Group's scope covers payment transactions using Web technologies on a variety of devices...' as well as in other seciton of the document

Comment

Deliverables: 1) 'Reduce the burden on merchants to support multiple payment providers' doesn't make clear whether the multiple service providers constitute the burden, or whether it should be made easier for merchants to support multiple payment services and providers for greater choice, both on the merchant's and the user's side. Also I would propose to add a bullet on transparency and user control, which might also resolve some of the controversies about fees, etc.

Proposed change

Proposed change: 'o Provide mare transparency to the user to understand the roles of involved parties, assess the effects of possible fees, and understand the data flow and its implications (e.g. for privacy, governance, etc.)'

Comment

4) Please add 'Secure Elements, SIM or UICC to the list in:

  'Including hardware tokens, smartcards, biometrics, mobile, 2nd factor authentication, etc.'

Proposed change

ok

Comment

Dependencies/ Liaisons: GSMA - an industry association of mobile network operators with almost global coverage. GSMA works on recommendations for NFC-based payments, but also on other handset- and SIM-based aspects for secure transactions which will likely have an effect on capabilities of wireless devices for payments.

Proposed change

ok

Comment

1.Scope Statement: a. Line 2 – Change “payment instrument” to “payment method.” Payment instrument is a more narrow term than the examples suggested in the parenthetical list that follows. b. Line 2 – Add the following to the list of payment methods in parentheses—i.e., ACH, debit cards, prepaid cards, e-checks. Also, delete the reference to “coupon” as this isn’t a payment method. Consider also deleting “Loyalty card” as this may or may not be a payment method, depending on whether it is tied directly to the payment itself. In some cases a loyalty card is tied only to customer information, rewards, or other items relevant to the customer/merchant relationship and not the payment method itself. c. Line 2 – Change “new” payment systems to “newer” payment systems. PayPal, as an example, has been around for 10+ years. d. Line 3 – Add business-to-business (B2B) to the list of transaction types covered by the scope. Many businesses, especially smaller businesses/merchants transact many of their B2B payments on the Web. e. First bullet under “Note” – Developing technical standards is generally out of scope but may be needed to support the work of the Web Payments Interest Group (WP-IG). Consequently, we suggest stating that the W3C will pursue and/or encourage the development of technical standards

Proposed change

a: ok b: happy to complete the list of examples, but i suggest we keep non-money-based method of payments (coupons, loyalty card) c: ok d: ok e: ok

Comment

3. Deliverables: a. We suggest being more explicit about the need for the Web Payments IG to review relevant external documents. For example, ISO has a work group in place developing mobile banking and mobile payments standards. This work is relevant and perhaps overlapping to some aspects of the Web Payments IG effort and so should be reviewed. b. Under topic #2, Wallets and Wallet APIs, bullet 5, change the “…integrating new payment schemes such as loyalty cards or coupons” to “enable integration of new payments schemes and ancillary services, such as loyalty cards or coupons….” c. Under topic #4, Identify, Authentication, and Security, bullet 1, what’s the definition of “high value” authentication? d. Under both topics #3, Payment Transaction Messaging, and #4, consider adding a new bullet that states, “Leverage and/or reference existing, relevant technical standards. In item #4, place this as a sub-bullet under existing bullet 4, “Minimize risk in identifying users.”

Proposed change

a: ok b: ok c: ok will clarify "high value" which means improved authentication using various technologies from multi-factor auth to secure-elements, smartcard-based auth. d: I suggest to mention it clearly both in the scope and at the very beginning of the deliverable section because it is a critical element to highlight

Comment

4. Dependencies and Liaisons: a. Under External Groups, we suggest removing ANSI, as it isn’t relevant here. However the ANSI accredited standards development organization X9 is. Thus, we suggest adding ASC (Accredited Standards Committee) X9, and describe this as “The ANSI accredited U.S. standards development organization for U.S. financial services. ASC X9 uses an open, consensus process to develop its standards.”

b. In addition to ISO broadly, we suggest adding the specific, relevant technical committee, ISO TC 68. This can be described as, “ISO Technical Committee 68 is the ISO entity that develops international financial services standards.”

Proposed change

ok to both

Comment

I would also like to see the question of trust, usability security and uptake brought out clearly in an early bullet point. 

Proposed change

• add B2B in the list of scenarion
• expand payment methods to add credit transfer and direct debit
• expand the tasks of the ig and add a bullet point:
  • Identifying ways to improve the trust in and usability, security and uptake of web payments.

Comment

we would also request inclusion of our group (Payment Systems Development Group, World Bank) also as an external group.

Proposed change

ok

Comment

It would be important to acknowledge that there are prevalent international standards for payment systems in terms of risk management and Governance; and, messaging; and make this explicit when referring to Topic 3 in the list of topics.

Proposed change

ok we will clarify in the topic 3 that the work should be based and take into account existing international standards. I'm happy to add a sentence along these lines. I think it is an important point. However, if i understand correctly, you are referring to messaging between different entities within a given payment system, while the topic 3 is mostly about messaging between a web application and a payment system. I think it is a general problem of the current charter and i need to clarify what we are talking about.

Comment

Identification of specific "use cases" is mentioned as one of the tasks of the group. It would be good to clarify whether there is any specific categories of "use cases" that would be in focus. At the World Bank we are in particular keen on small value international remittances, in addition to general purpose retail payments, corporate payments etc.

Proposed change

agreed that specific use-cases like low-value should be mentioned

Comment

We also noted the active exchange of emails on the definition for web payments. We would like to encourage the group to look at the prevailing definitions used by the organizations like the CPSS and in the publications of the World Bank. I am attaching links to these documents below. In the payment systems community there is an ongoing tussle on whether the define types of payments by type of underlying payment instruments or by the access channel and the considered opinion is to go by payment instruments and where the channel has on overwhelming impact try to reflect that in a new category. You would see this attempt to balance in the definitions in these documents.

http://siteresources.worldbank.org/FINANCIALSECTOR/Resources/Retail_Payments_Strategy_June2013.pdf [Refer Annex 8] http://www.bis.org/publ/cpss102.htm http://www.bis.org/publ/cpss00b.htm

Proposed Change

I believe it is a work item by itself. There are different terminologies used by different actors, and it is essential that we adopt a clear one for the work of the group. So instead of discussing it now, my suggestion would be to add it as one of the work item of the group

Comment

> Identity and authentication methods for the Web should meet criteria for additional spheres. Accreditrust needs a global solution for storing high stakes credential data and ability to associate them with identity on the Web. We think any solutions working for finance should also work for the education sector.

Proposed Change

The fact is that identity on the Web is something that is far bigger in scope than identity related to web payments. That's why this group will not be in charge of defining idenitty on the web or authentication, but will define the specific requirements related to payments and work with other groups (W3C or non-w3C ones) to ensure that the technologies they are developed can fit with web payments requirements.

I will try to clarify better this point

Comment

wallet could be used for both onsite and online payments

Proposed Change

good point to be clarified

Comment

wallet could be used for both onsite and online payments

Proposed Change

good point to be clarified

Comment

The Payment should also consider requirements around CI (Customer Intelligence) there by provisioning the “Shopping Attributes” as well (e.g. Location, Period, Basket items etc.) as a part of overall coverage.

Proposed Change

good point. This should be made explicit in both privacy aspect and messaging

Comment

Following Payment domains are missing (or not explicitly mentioned)

• Peer-to-Peer (P2P)
• Bill Payments (Utilities, Tax, Invoices etc.)

Proposed Change

ok for P2P. I will also mention specific points around recurring payments and alike

Comment

We suggest the charter could be made more compelling if it offered a stronger statement on the problem that this work effort is seeking to address. For example the problem statement could be expressed along the following lines: consumers and other end users when making payments on the Web encounter problems, notably a common user experience that is safe and secure, easy to use, efficient, and generally uniform from site to site. Others closer to this effort may have better language to offer.

Proposed Change

This is an interesting point. It is true that defining a strong, short and sharp problem statement would make the charter stronger. However, i believe that different actors have a different views of the issues. It is a work item by itself to identify the problem statements of each categories of actors and try to bring a coherent view on how to solve them. The proposed change is there adding a work item on the state of art and the identificatin of the problem statements for each category of actors

Comment

As mentioned in earlier Federal Reserve comments, the reference to B2C and P2P in the Scope may be unduly narrow as later descriptive references to commerce seem to suggest many more use cases. In addition, the Scope seems to encompass not only payments for purposes of commerce (which would be most “X2B” use cases), but payments to individuals, whether from a person or a business.

Proposed Change

agreed. We will expand to cover all cases.

Comment

Regarding earlier comments on loyalty, we revise these to suggest that rather than eliminating these references, they be narrowed in scope to the aspects of loyalty that involve payment for goods and services.

Proposed Change

ok we will refine the meaning of loyalty