Web Payments Working Group Teleconference -- 21 Apr 2016

FPWDs

<scribe> scribe: Ian

nicktr: Congrats to the group and thanks to everyone who has contributed and who continues to contribute via github

https://lists.w3.org/Archives/Public/public-payments-wg/2016Apr/0150.html

pub notice -. https://lists.w3.org/Archives/Public/public-payments-wg/2016Apr/0179.html

https://www.w3.org/Payments/WG/charter-201510.html#coordination

https://www.w3.org/blog/wpwg/2016/04/21/first-public-working-drafts-of-payment-request-api/

https://github.com/w3c/webpayments/wiki/PaymentRequestFAQ

<shepazu> https://github.com/w3c/webpayments/wiki/Agenda-20160421

<manu> Ian: I've prepared a number of documents (linked above) that goes with the FPWD publication.

IJ: I will be reaching out to groups listed in our charter

<ChristopherA> Thanks you for interruption for IRC details. Officially joined group today.

<ChristopherA> For Blockstream.

nicktr: I will be contacting three main groups at EMVCo about the publications
... I will ask the groups to review the specs

Welcome Christopher Allen

nicktr: Welcome!

(ij seconds the welcome)

<ChristopherA> (minor note, always spelled Christopher Allen ;-)

Proposal that the group take on the SEPA payment method spec

MattS: Here's the draft proposal:

https://w3c.github.io/webpayments/proposals/basic-ct-dd-payment/basic-ct-dd-payment.html

scribe: one goal is to validate the API approach by having multiple payment method specs
... it paves the way for others to do similarly
... and can help us avoid different orgs creating competing specs for the same payment method
... today's discussion is about taking it on into the WG...not focused on content today

<ChristopherA> It is useful to me, as I'm hoping to see how to, in theory, publish how bitcoin does BIP70 https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki

Manu: +1 to bringing the proposal into the group
... there are issues with the content we can address once brought in

<dezell> +1 to bringing in the SEPA prop

Manu: this can help us learn to write payment method specs

<Zakim> manu, you wanted to provide feedback on SEPA Payment Method spec. and to +1 for another ubiquitous payment method example.

+1 to taking Cyril's spec into the group

<AdrianHB> +1

<dlongley> +1

<ShaneM> +1

MattS: A point I want to make in general - I have a number of pull requests on the basic card spec...some of those are general comments....
... I would like to get at least one "great examplar"

<adrianba> +1 to the idea of bringing it in without necessarily supporting the content so far

MattS: so suggest we hold off on getting further ones until we have a great exemplar

<AdrianHB> +1 to Matt (volunteers to concentrate on the Basic Card Spec)

Matt: I volunteer to edit; Cyril supports this

+1 to MattS being an editor

(with Cyril)

<dlongley> +1 to MattS + Cyril

Manu: At some point we may have a payment method spec that explains how to write them

(IJ thinks this is NOT a spec but rather a good practice doc)

<Zakim> manu, you wanted to mention exemplar work

IJ: -1 to a "spec" for payment method specs...rather just a live page that we can work on more easily

POINT OF ORDER: Let's move "payment specs" to another topic

MattS: I propose also to be co-editor of the card spec

<manu> +1 to Matt becoming co-editor of card spec

<adrianba> i believe we chose not to merge those proposals because we didn't deem there to be consensus

<dlongley> +1 to MattS

+1 to Matt as co-editor to card spec to help with harmonization

nick_tr: Zack and Adrian, you ok with that?

zach: I'm fine with it

<ShaneM> +1 to MattS

<adrianba> i have no objections to adding matt but i don't believe that this is due to lack of resources

MattS: I'll work with the editors to get to consensus

<manu> pull it in

<AdrianHB> +1

<manu> pull the SEPA spec in

<dlongley> +1

RESOLUTION: (1) Add MattS as co-editor to basic card spec (2) Take up the SEPA transfer spec with Cyril + MattS as editors

New architecture spec

AdrianHB: In issue 138 I restructured the content a bit
... I submitted a proposal for a new arch doc and I don't think we should spend time on the call today

<zkoch> Link to new arch. doc proposal?

<manu> http://w3c.github.io/webpayments/proposals/architecture/

<zkoch> thanks!

adrianhb: I would like to discuss organization of specs

adrianba: The original architecture spec I wrote up was intended to allow the browser api spec to proceed at a rate independent of other specs
... such as payment app registration or payment method specs
... the cornerstone is the payment method identifier spec
... most other docs would depend on it
... then there's a browser API that describes how to get from javascript in a web page to getting a response from an app and incorporates the mediation role.
... separately we talked about a registration spec that explains how you find applications that produce those responses.
... those can definitely proceed independently
... we put mediation role in that document as well

adrianhb: that's a fair reflection of where we are today.
... we heard reservations ... Ian pulled in more architectural description in (in addition to spec relationships)
... my motivation behind my proposal is that there's a lot of confusion about mediator (and relation to user agent)
... and I wanted to emphasize that mediator and payment app are "roles"
... the new proposed architecture is renamed slightly to call this out
... it's also explicit that it's not an architecture for web payments, it's an architecture for processing payment requests.
... we don't make assertions about "what processing means"
... so the proposal is a description of roles and roughly how they work
... it also defines extension points

[AdrianHB continues to explain vision of organization of specs and roles]

adrianhb: Arch doc explains what a payment method is...defers to the identifier spec for how to identify them.

<Zakim> manu, you wanted to speak in favor of this new architecture document (and support it in lieu of the Payment Apps spec)

manu: +1 to the new architecture document
... I like it a lot..it was what I was expecting in an architecture document.
... it's the right direction even if I don't agree with all the content.
... there's also a payment registration spec.
... would this document replace that one?

adrianhb: The payment app spec will able about what they do and how you register them (things not yet addressed)
... I don't believe that structure (of that doc) is currently correct.
... I think the content may be split out into 3 places:

- A "manifest" specification

- For parts of payment app, yes pull into the architecture spec

- Then registration is a third topic and there's not yet agreement in the group where that should sit

scribe: I think that registration is a function of mediator

<dlongley> +1 to new architecture doc and idea of core abstract specs that API specs depend on ... also need a core messages spec that describes data model for payment requests and responses, how to extend, + some syntaxes (JSON) ... manu has submitted this doc as a proposal.

adrianhb: Too early to get consensus on the arch doc
... let's defer decision on that
... what we need to discuss is whether to mention registration in the browser API spec

IJ: I am hearing proponent withdraw 2 proposals today ...for discussion at a future call

manu: +1 to splitting out payment app specs

<Zakim> manu, you wanted to agree w/ splitting out Payment Apps spec into different places - assumption is request for payment apps proposal is withdrawn and should be removed from

HTTP API proposal

https://w3c.github.io/webpayments/proposals/web-payments-http-api/

Manu: Ian has reviewed the spec

<manu> http://w3c.github.io/webpayments/proposals/web-payments-http-api/

Manu: I've incorporated his comments
... HTTP API is a way of registering a payment app through an HTTP client
... and of initiating a payment
... sending the payment request to a payment app and getting a response
... and returning a response
... the spec is incomplete ... wanted to get a straw man on the table

IJ: Have others read the spec?

<manu> Ian: My first question to the group - have other people read the spec?

<ShaneM> I have read the spec

AdrianHB: Yes

nick_tr: read an earlier iteration; haven't read most recent version

<zkoch> Yes, but not updated version

<adrianba> yes

<ShaneM> publishing?

<manu> Ian: I have read it and have a bunch of questions - there are things it's doing today that we're working on in other places. It strikes me both that publishing it with that content would create confusion and possibly dilute the effort to resolve some of these things that we want to be common across all of these things?

<manu> Ian: I mean, taking on this work

<manu> Ian: Secondly, I think for the things that an HTTP API spec should do, it doesn't do enough of those things. I also have an outstanding email regarding use cases asking to clarify the situation in which it would be employed. Even though it's only a question of taking it up - taking it up in it's current form overlaps with other stuff we're taking on. We should reduce it to a web services specification and drop the bits we're working on in other specs in the group.

<Zakim> manu, you wanted to respond

IJ: I gave detailed suggestions in my email

Manu: the spec as written now tries to give someone a clear idea of request and response
... I don't think that classifying as a "web service" specification is the right direction
... let me get back to your email

MY concern is that this content, unlike the SEPA spec, overlaps with other specs and that's the concern

Manu: There is content in there that would help someone build an HTTP client

adrianHB: I think I see where IJ is coming from but maybe a separate call would be useful
... on the back of the fact that there's a new arch proposal
... perhaps there's an opportunity for AHB and Manu to spend this week on looking at how to get these two docs to work together

<Zakim> AdrianHB, you wanted to suggest working with Manu on this

<nick_tr> ?

adrianHB: and the HTTP spec would define how to build clients that fulfill the role

roles

and fill in the gaps

nick_tr: I hear that there's a proposal from Manu to take up the work, concern from Ian, and offer from AHB to work with Manu to align the emerging specs

<manu> Ian: I think, while the content, not the timing is the concern at this point.

Manu: I disagree the group agreed to take up the work in June. The idea was to aim for a FPWD in June.
... even if we said that, there's a member who wants to work on it
... +1 to working with AHB to alignment
... I can see how HTTP fits in

nicktr: Are you ok to take proposal off the table Manu?

<zkoch> OK, back

Manu: I'd like to hear more opinions.

<ChristopherA> Finally back in. took a long time.

IJ: My summary is that (1) content risks confusion (2) not urgent given previous decision re: June FPWD (3) want more people to weigh in
... I suggest 5 May for considering proposal (so that we have time to review)

<AdrianHB> ack -1

<Zakim> -1, you wanted to postponing

<dlongley> is Ian the only one who finds it controversial?

<zkoch> I’d like more time to review and write down some comments/concerns on the HTTP API. I like the 5 May deadline to do that.

nicktr: I would like to revisit this next week
... it will only work if people on the call commit to review both specs ahead of next week.

(When will they be available? )

<ShaneM> I am happy to re-review the documents in time for next week.

<zkoch> I’d rather we spend more time on next week’s call resolving issue around PaymentRequest

(IJ: +1 to doing issues next week)

<dlongley> if we're going to delay another week for people to read, then those people should take actions to review

Payment app registration

AdrianHB: Propose to take off the table today...but the question is whether there should be content in the browser API spec about how to register payment apps.
... Any views on whether content on registration in the browser API spec?

zkoch: I think there should be a reference to it...we need to talk about registration "a bit" in the API spec,

but all the details of payment app registration should be written in a separate spec

adrianhb: Why is that?

zkoch: I see the browser Api spec as focused purely on how to request payment in the browser
... how do I request payment and get a response
... how you register payment app is separate from that
... payment app registration is an orthogonal topic

<adrianba> +1 to zkoch

<manu> Ian: One of the thoughts that occurred to me reading the HTTP API spec, if I understood the flow correctly, some entity would kick off a payment if someone sends off a payment request somewhere.

<manu> Ian: The same user selection of the payment app would happen - therefore, we were talking about similar topics - how does a payment app declares what it supports?

<manu> Ian: How does it tell that entity what it can do - if we have those two APIs... the registration is a binding - don't know if registration is very close and should be in the browser.

<manu> Ian: The fact that a payment app can declare it's capabilities suggest that it does belong outside either one of those APIs, that's the inclination that it has, don't know enough about registration yet.

adrianhb: there will be lots of ways that registration can occur
... e.g., with a browser as extensions
... or through the underlying platform
... and I don't think it's our place to define how these various platform independent things happen
... however I think that we are the custodians of what happens on the web platform
... and so we should at a minimum provide guidance for how it happens on the web

<dlongley> +1 to AdrianHB

adrianhb: so that includes registration of payment apps with browsers and also how payment request gets to web based payment app
... I still am not sure why you would want to put that in a separate document
... if you don't talk about how to register payment apps, it's an incomplete picture
... it doesn't make sense to me to split it out

<Zakim> ShaneM, you wanted to note that having it in a separate spec has the advantage of clear conformance requirements for a payment app.

ShaneM: I don't mind having it in a separate spec...I think it helps with conformance and testing
... but I would object if the paymentRequest API spec before the payment app spec went to rec

<Andrew> +1 to a consolidated spec

ShaneM: they need to be done together.

Face-to-face meeting

nicktr: Blockchain workshop is going to be announced in June
... given interest from this WG, we are looking to move our FTF meeting into July

<ChristopherA> Please not too near IETF

nicktr: I am looking into logistics

https://www.ietf.org/meeting/upcoming.html

July 17-22, 2016

Host: Juniper Networks

Location: Berlin, Germany

<shepazu> (sorry about the workshop timing, folks :( )

nicktr: I will proposed dates to the WG

<shepazu> https://www.w3.org/2016/04/blockchain-workshop/

<ChristopherA> If it was end of week before that might work, do both trips together.

<AdrianHB> +1 ChristopherA

<AdrianHB> you did

next meeting

28 April

adrianHB: Will include proposals and also issues

(IJ: I would like to focus on issues and move proposals to 5 may so that we have time to review them)

- DRAFT -

Web Payments Working Group Teleconference

21 Apr 2016

Attendees

Contents