Re: Web Payments Working Group Draft Charter Review

On 11 July 2015 at 11:18, Adler, Patrick <patrick.adler@chi.frb.org> wrote:

>  Hi All,
>
>  I’ve reviewed the charter and have attached my thoughts for your
> consideration.  I’ve tried where possible also not to repeat feedback
> already submitted by others unless there was some additional context.
> Please let me know if there is anything I can clarify or questions that may
> arise.
>
>  *General Comments*
>
>    - Remove the term architecture from the title of the WG.  In line with
>    others comments here, I believe that framing the WG as a “Web Payments
>    Working Group” would allow the WG to focus on a more holistic view of
>    web-payments as opposed to just those dealing with Architecture
>
> Done


> *Section 1 – Goals*
>
>    - In the opening sentence the phrase “from a Web site or Web
>    application. Where practical the standards will be usable by native
>    applications/apps.” feels like it couples/centers the WG’s work too closely
>    to a particular type of user agent.  Trying to distinguish between web
>    applications or native applications may draw attention away from WG outputs
>    which should be application/user-agent agnostic.  Ideally, the work of the
>    WG would result in a generic approach to standard messages and interfaces
>    which could then be implemented by different stakeholders as part of the
>    work to show that they work across different user agents/client (ex. web
>    app, web service, native app, backend server process etc).  As a suggestion
>    for replacement, something like "Under this initial charter, the Working
>    Group defines standards that ease integration of the payments ecosystem
>    into the Web and allows for payers to initiate payments in a consistent way
>    across user-agents and applications that they interact with.”
>
> Have already tweaked this sentence based on previous comments. I do think
our focus is on the Web so Web applications are the primary domain. I think
the native app interoperability is a nice to have.

Also, we must distinguish between the possibility of wallets being "native"
and the application that the consumer is using being "native".

Example:
In scope: A user browsing a website and initiating a payment which results
in a WebIDL API call by the website. This causes the browser to pass the
payment initiation request to a native wallet configured by the user as
their wallet of choice.

Out of scope (nice to have): A user is browsing products on their favorite
store's mobile app and initiates a payment. How this app and the user's
wallet app communicate is out of our scope BUT it would be great if we
standardized our messages and flow so they were usable in this scenario.

>
>    - For the sentence The W3C is also planning other Working Groups to
>    develop standards that will facilitate payments on the Web, on topics such
>    as security.”, recommend also adding identity and credentials, commerce
>    (ex. loyalty, coupons, discounts, offers, etc). Also, it would be good to
>    add a statement here that it is expected that the WG will be expected to
>    interact with these other WG’s and that work will be coordinated on an
>    ongoing basis via the Web Payments IG.  A draft of this might read: “Due to
>    the nature of payments on the Web, the Web Payments WG is one of several
>    WG’s that will be be coordinated by the Web Payments IG on an ongoing,
>    regular basis to ensure that standards developed as part of the Web
>    Payments WG are interoperable with those developed in other related WG’s
>    (ex. Web Commerce) that may be working in parallel.
>
>
I don't want to presuppose what other WGs will be formed but I agree 100%
with your thinking. I have added a more generic form of your suggestion and
re-jigged that last bit of the goals section.



> *Section 2 – Scope*
>
>    - For the Note: "*Note:* W3C expects to a wider variety of of
>    eCommerce scenarios over time, including digital receipts; loyalty programs
>    and coupons; peer-to-peer payments; and harmonization of user experience
>    in-browser, in-app, and in-store. For more information, see the Payments
>    Use Cases <http://www.w3.org/TR/web-payments-use-cases/> published by
>    the W3C Web Payments Interest Group.” This appears as if it is suggesting
>    that this work may eventually fall into scope of the Web Payments WG. We
>    should be more explicit here as to where the “Commerce” work is to be
>    handled.  In IG discussions, having a parallel “Web Commerce WG” working
>    along side the “Web Payments WG” would help to decouple the work efforts to
>    allow for both to progress independently, but in a coordinated fashion.
>
> I'm not sure that is the current consensus of the IG. My understanding was
that it will be easier to recharter the WG down the line to deal with this
expanded scope rather than trying to charter a new WG.

Either way, do we need to be explicit about something that is not going to
change the scope of this WG?



> *Section 2.1*  - *Wallets*
>
>    - It would be useful in this section to illustrate how the term
>    “Wallet” (or any user agent for that matter) may use a set of standardized
>    Web Payment API’s to accomplish it’s work and focus more attention on the
>    API’s/Interfaces than the “Wallet".  In thinking back on the many
>    discussions that the group has had around the term “Payment Agent” and
>    “Wallet”, I believe that a focus on the API/Interface vs. the name/concept
>    of the type of user-agent (ex. Wallet, Payment Agent, POS terminal, etc)
>    would be helpful in keeping the focus on a standard set of messages that
>    can be used regardless of whether they start on a particular “kind” of
>    endpoint.  This would allow for the same Web Payment standard to do things
>    like “issue a refund” to a “wallet”, or send money from a “wallet” to
>    “wallet”.  This would also make it easier for organizations to use the
>    standard to do things like paying their employees or suppliers from a
>    “payroll system” to an “account” which would in turn increase adoption.
>
> First, and very important, is that the wallet is not the user agent.

I think the payment agent concept has mixed this message up and your
interpretation of this section is coloured by that preconception

The wallet is a service and it offers the same capabilities as most
services that are called wallets today. It is possible that the wallet
service may be built into a user agent but that's not required.

We are looking to standardise the messages that wallets must be able to
process and the responses they must return and we are also trying to
standardise the delivery mechanisms that will be used to pass these
messages to the wallet service and back to the payee application.

One of those delivery mechanisms will be via a user agent WebIDL API but if
the wallet is a Web service then the delivery mechanism may be REST APIs.

If the payee application is a a website then the message may be sent via
the WebIDL API to the browser which in turn proxies it to the cloud-based
wallet via a REST API.

The point is there will be many deployment scenarios and we will try to
standardise the most important ones (and all of the ones that are in scope
for the W3C)



> *Section 3.1 – Web Transactions 1.0*
>
>    - For “Web Payment Initiation” there appears to be some missing
>    context.
>       - Are payer’s user-agents expected to be able to “receive” a
>       request for payment as part of response received back from Payee’s web
>       application with payment context?
>
> The payment initiation request comes from the payee and contains all of
the terms and supported payment instruments. This will be sent via an
appropriate delivery mechanism for the context. In the common website
context where a payer clicks "Pay" on the payee's website the request
message is sent via the WebIDL API in the browser.


>
>    -
>       - Also, the second statement here around "to pass back to the
>       payee” may not align with the security/privacy goals for the payers payment
>       information as stated in the IG’s goals/benefits.  Is the statement here to
>       suggest that the user agent will send payment confirmation (or notification
>       that the payment has been initiated” to the payees application?
>
>
The initiation response will contain the payer's selection of payment
instrument and confirmation of the terms. Bare in mind that the wallet only
returns this response after some user mediation so unless the user has
configured the wallet to auto-select a payment instrument and auto-confirm
payments under a certain value the user will always be prompted by their
wallet before the response goes back to the payee.



>  *Section 4.1 – W3C Groups*
>
>    - Should we add CG’s or Notes related to other charters that are
>    likely in flight here (ex. Identity and Credentials WG)? It would be
>    helpful to illustrate how these may interact with the Web Payments WG as
>    defined
>
> I have added the Credentials CG, not sure about adding groups that don't
exist yet like Credentials WG. Will need some guidance from Ian on that.



>  *Section 7 – Decision Policy*
>
>    - Open question: How is the ongoing work of the WG influenced by the
>    IG? Given the coordination of work that may likely be required across other
>    related areas (ex. Identity/Credentials, Commerce, Security Etc.), is there
>    expected to be longer term engagement of the IG with the WG? If so, how is
>    that reflected here?
>
> Tried to reflect that in the changes I made to the first section. Not sure
if there is more we need to add?


>
>  Hope this helps.
>
>  Pat
>
>
>
>
>
>
> This e-mail message, including attachments, is for the sole use of the
> intended recipient(s) and may contain confidential or proprietary
> information. If you are not the intended recipient, immediately contact the
> sender by reply e-mail and destroy all copies of the original message.
>