- From: Ian Jacobs <ij@w3.org>
- Date: Sat, 25 Jul 2015 13:22:04 -0500
- To: Joseph Potvin <jpotvin@opman.ca>
- Cc: Web Payments IG <public-webpayments-ig@w3.org>
- Message-Id: <6E9B72D8-37C2-4A11-B230-9AA992C4E29E@w3.org>
> On Jul 25, 2015, at 11:28 AM, Joseph Potvin <jpotvin@opman.ca> wrote: > > My following comments/suggestions on the current charter may be a little late, and may miss some insights already addressed in discussions. Hi Joseph, Thank you for the thoughtful comments. At this point in our discussions (following an IG consensus decision and subsequent consensus building with the management team) I am reluctant to make additional substantive changes prior to the Membership review. During the course of Member review it may be that proposals align with your own suggestions and we can perhaps then take your suggestions more deeply into account. Some comments inline on changes that I think are not controversial at this particular point in time. Ian > I trust this input will nevertheless be useful: > > 1. On the topic of wallets: > > SUGGESTION: There was considerable discussion on this list about whether or not the term "wallet" was helpful or confusing. It appears there's a preference to keep it. Let me therefore suggest the following concise functional definition summarizing our approach at DataKinetics: I am reluctant to change the definition of wallet at this time as it has been scrutinized through previous reviews. > > An e-wallet has two general functions: > * It is a "depository" for the temporary storage of information in the form of authorized scalar units of money (as either tokens and/or scalar values in a registry) > * It is a "repository" for persistent storage of enduring integral artifacts (e.g. payment method algorithms, receipts, coupons, credentials, etc.) > > Therefore some potential adjustments to the charter text: > > FROM: It holds and allows access to payment instruments registered by the payer. > TO: It contains or references payment tokens, registries and algorithms registered by payees and payers, and it enables their use. > > FROM: "It may hold digital assets, in the form of one or more account balances, that can be used to make payments." > TO: It contains or references authorized digital tokens or authorized scalar values in a registry for making monetary payments. > > FROM: This group is not developing standards for loyalty schemes and coupons, digital receipts, digital credentials, tickets, and location services. Future W3C activities may seek to increase interoperability of these additional digital wallet capabilities. > TO: This group is not developing standards for the artifacts contained in a wallet repository (e.g. loyalty schemes and coupons, digital receipts, digital credentials, tickets, and location services). Future W3C activities may seek to increase interoperability of such wallet contents. > > QUESTION: In all the references to "wallets" it appears in the charter text that only payers have wallets. Surely payees also have wallets. > Other single-sided assumptions also show up elsewhere, so here are some suggested tweaks to balance this… I don’t know whether moving from a focus on the payer’s wallet (as we do) to a bidirectional framing is an innocuous change to the charter (in the sense that it is not a stretch to say that payments go from wallets to wallets) or a more significant one. Comments from others welcome. > > FROM: This Working Group intends to create a standard programming interface from the Web to a payer's digital wallet so that someone with a conforming digital wallet can seamlessly make payments with a conforming application running in a conforming user agent. > TO: This Working Group intends to create a standard programming interface from the Web to conforming digital wallets so that parties using them can seamlessly issue and recieve payments structured by digital invoices in conforming applications, running in conforming user agents. Based on June discussions we do not use the word “invoice” in this charter (intentionally). > FROM: Improved transparency and confidence in digital payments for consumers as a result of increased choice and standardized flows and experiences. > TO: Improved transparency and confidence in digital payments for consumers and merchants as a result of increased choice and standardized flows and experiences. That seems like a minor change and (if it’s true) I don’t object to making it. > > FROM: Easier integration of new payment schemes by payment service providers, increasing the variety of payment instruments accepted by payees. > TO: Easier integration of new payment schemes by payment service providers, increasing the variety of payment instruments accepted by payees and payers. I think “accepted by payees” is preferable here (because we are referring to the receipt of the payment.) > > FROM: Registration by the payer with their digital wallets, of any conforming payment instrument they wish to use on the Web (a credit or > debit card, electronic cash, cryptocurrency, etc). > TO: Registration by the payer and the payee with their digital wallets, of any conforming payment instrument they wish to use on the Web > ...Note: I suggest to remove the part in parentheses containing examples. It's better to leave this wide open to the evolution of options and terminology. In the age of HCE, do we really still refer to credit "cards”? Many people may still be looking for (and understand) the word “card" > > RE: "Jeff Jaffe observed that the flow in the current charter does not handle the case where there is no digital wallet." > > The definition of "wallet" proposed above based on our work at DataKinetics eliminates Jeff's scenario conceptually, since the the token and/or the scalar values in a registry need to be "somewhere". Where ever that happens to be, comprises "the wallet”. > By analogy to the physical form, if I just carry a wad of paper money in my pants pocket, that's my de facto wallet. If the digital money (token or scalar value in a registry) is somewhere, then that's the wallet. Our definition says that a digital wallet is “a software service that provides similar functions in the digital world to those provided by a physical wallet.” The failure mode described in the charter is that the user agent does not find such a thing. What you describe is that they need to be “somewhere” but in the scenario I have in mind, the are not known to the user agent. I would have to enter them (e.g., via a form) for them to be known to the user agent. The question is whether that can happen and the the protocol should be designed to start from that (manual entry) point and “take it from there." > > > 2. On the Topic of Other Standards Bodies > > The charter previously referred to "engaging in liaisons with other payments standards bodies" This is now removed. I was going to suggest that this line be adjusted to "engaging in liaisons with other standards bodies". I understand why this would have been pulled, but there are several other standards that provide useful working "boundary conditions" for the role and particulars of this WG. > > Related to the previous point, I see that the section "Groups Outside W3C" has been removed. There is a section 4.3 Groups Outside W3C. Ian > Okay -- on the earlier version I was going to point to some major gaps, but it might be best to leave this list off the charter itself. Assuming this list would be maintained elsewhere however, I'll recommend as mentioned earlier on this list that "Coordination with ISO JTC 1 will help achieve broad interoperability between e-invoices and web payment systems (e.g., through alignment between Web protocols and ISO/IEC FDIS 19845)." > > > Joseph Potvin > On behalf of DataKinetics > Operations Manager | Gestionnaire des opérations > The Opman Company | La compagnie Opman > jpotvin@opman.ca > Mobile: 819-593-5983 > > On Fri, Jul 24, 2015 at 9:34 PM, Ian Jacobs <ij@w3.org> wrote: > Dear Interest Group, > > On 20 July I sent a request to the W3C management team to approve the draft > Web Payments Working Group charter [1] and to start W3C Member review in August. > Two people from the management team reviewed the charter and sent detailed > comments. I have updated the charter based on their comments. (I also made a few > subsequent editorial changes such as alphabetizing the list of liaisons.) > > Here are the detailed changes based on the review: > https://github.com/w3c/webpayments-ig/commit/cb764d239afa16fe6e5751177a1776044800957b > > I believe all changes were improvements, either clarifying the scope or the nature of the deliverables. > I have requested time during Monday’s teleconference to review the changes and answer any questions > you may have. If you have serious concerns about any of the changes, please let me know and we’ll > try to discuss them at Monday’s call. > > I also have one question for the group: Jeff Jaffe observed that the flow in the current > charter does not handle the case where there is no digital wallet. Jeff pointed out manual > entry of card data will continue for some time, and that it might be possible to increase interoperability > even when there is no wallet present. He asked me to check on the Interest Group’s consensus view: > was the charter intended to increase interoperability even in the case of manual card data entry > and no wallet, or was that considered out of scope for this charter. > > I expect the management team to review the revised charter on 29 July. I plan to summarize any > feedback from the IG on the charter changes in time for that call. > > Talk to you Monday, > > Ian > > [1] http://www.w3.org/2015/06/payments-wg-charter.html > -- > Ian Jacobs <ij@w3.org> http://www.w3.org/People/Jacobs > Tel: +1 718 260 9447 > > > > -- Ian Jacobs <ij@w3.org> http://www.w3.org/People/Jacobs Tel: +1 718 260 9447
Received on Saturday, 25 July 2015 18:22:08 UTC