Re: comments on draft Payment Architecture WG charter

Hi David,

I'll take a stab at updating this. Some comments inline to clarify.

On 19 June 2015 at 08:03, L. David Baron <dbaron@dbaron.org> wrote:

> Here are two comments on the draft charter at:
> https://www.w3.org/Payments/IG/wiki/Roadmap/PaymentArchitectureWG
> in particular, on the revision:
>
> https://www.w3.org/Payments/IG/wiki/index.php?title=Roadmap/PaymentArchitectureWG&oldid=1995
>
> (1) In the Scope section, it currently says:
>       #  Discovery of available payment instruments that can be used
>       #  by matching those registered by the payer with those
>       #  supported by the payee (as defined in the Payment Request).
>
>     I think there was agreement in the discussions at the
>     face-to-face that the selection of payment instrument is done by
>     the payer, since we don't (for privacy reasons) want to expose
>     all available payment instruments to the Web site.  This is even
>     explicitly stated in the following bullet.  Despite that, I
>     think the term "Discovery" is still a little bit jarring (since
>     it suggests a discovery API).
>
>
+1 that discovery is possibly the wrong word. You'll recall that this did
cause some confusion during the use case discussion.

My understanding from the discussion at the face to face was that we wanted
the recommendation to support openness in support of payment schemes and
instruments (i.e. The browser shouldn't prevent the user from registering
any scheme or instrument) but that we didn't want to prescribe the
algorithm that was used to match registered schemes and instruments against
those supported by the payee.

At this point I imagine the browser API spec defining that the browser MUST
allow the user to define which "wallet" they want to use and for this
"discovery" algorithm to be provided by the wallet. Browser's may ship with
a default wallet from the day that they support the payment API but if the
user replaces this with another then the payment request (list of supported
payment schemes and instruments) must be passed, unaltered, from the
browser to the "wallet" whenever the payment API is invoked.


>     While I don't have a better term to offer, I think at least it
>     could be clarified more locally by adding a clarifying
>     statement, such as "so that an instrument can be selected by the
>     payer" at the end or something like "local to the payer" or
>     "while keeping information local to the payer".
>

I am starting to think we will need to use the term "wallet" and also
define what this means.


>
> (2) Some parts of the "Web Payment Vocabularies 1.0"
>     deliverable's description seem too specific.  In particular, I'd
>     like to remove the entire (fourth) bullet point:
>
>       #  *  For each vocabulary, the Working Group will create at
>       #     least a JSON-LD serialization and may create additional
>       #     serializations (e.g., XML).
>
>     I'd prefer that the group not be constrained to those particular
>     technical solutions.
>

+1 to a more open charter and leaving the specifics to the WG


>     I also wonder whether some of the first three notes in that
>     section might also be too specific; it's hard for me to tell as
>     they're far from my areas of expertise.
>
> -David
>   (at flight level 36,000 feet, above Nevada)
>
> --
> 𝄞   L. David Baron                         http://dbaron.org/   𝄂
> 𝄢   Mozilla                          https://www.mozilla.org/   𝄂
>              Before I built a wall I'd ask to know
>              What I was walling in or walling out,
>              And to whom I was like to give offense.
>                - Robert Frost, Mending Wall (1914)
>