Web Payments IG - Use Cases Task Force -- 09 Jul 2015

<ShaneM> ScribeNick: ShaneM

<manu> scribenick: ShaneM

Introduction to Matt Collier

Matt: Hi, my name is Matt Collier and I work for Digital Bazaar. I'm joining the calls to come up to speed on the Web Payments work and hopefully help with the work once it goes into the Web Payments Working Group.

AdrianHB: some discussion on the mailing list between a few people. collecting input. will discuss a few things today then revise based upon the input so far.
... there was a committment on Monday to have comments in by the end of the week.
... I wont have time over the weekend but will review early Monday and discuss on Monday and try to get to a final editors draft in the early part of next week.
... Two things worth discussing... wallets (might be bike shedding)
... I have no problem with Manu's proposal on the mailing list.
... maybe we should call it Wallet Service before we get into the API flow

<Zakim> manu, you wanted to explain wallet position being okay toward the middle

AdrianHB: happy to standardize other services but not sure what they are might be

manu: the word wallet was used... wallet is in the goals section way at the top. If we link to the section on wallets throughout the document that will just work.

<AdrianHB> +1 to linking to wallets section and not having it IN the goals section

manu: the charter is short enough that referencing things and being able to look at definitions should be okay.
... I tried to rework and not use the word. Mentioning it at the beginning was only a way to get the definition up front.

AdrianHB: sounds good. I will move the defintiion down a bit and reference that definition when the term is used.

<AdrianHB> http://manu.sporny.org/tmp/wpig/payments-wg-charter-manu-2.diff.html

manu: we agree that there is at least one REST API. So there should be a mention in the charter.

<AdrianHB> Moving wallet section:

<AdrianHB> http://manu.sporny.org/tmp/wpig/payments-wg-charter-manu-1.diff.html

manu: it is important to point out so people can comment and so that it is in scope.
... we know we need one from the user agent to the wallet service
... the comment that there could be a 'promise' that resolves into the browser context... that is possible, but it puts the entiretyu of the implementation in the browser
... we don't want to rely upon that because there are lots of browsers that dont have a WebIDL underpinning in the browser.
... we have to PolyFill this. We need to support old browsers. If we need to polyfill we can't rely upon a priomise to make a callback
... if the transaction goes into another site (merchant to service) the transaction can't come back.
... when the processor says "I have made the payment" there is no context as to where to go. The browser "promise-like" context doesn't exist in older browsers. So a callback URL to the merchant site is the most reliable portable backward compatible way to complete the transaction.

AdrianHB: in the scenario of the simplest use case... if there is a cloud based wallet is the UI is a popup window, or is it a redirect? There may need to be some UI.
... it is critical for us to standardize the message. It is useful to define different delivery mechanisms for the message.
... for example, in cloud based, there is a HTTP POST to the service with a callback. in browser based, there is an API call. Whatever.
... the charter should say that we are going to define the standarize the messages and deliver mechanisms between the entities.

<Zakim> manu, you wanted to agree w/ design flexibility.

manu: the primary thing is that the WG should have the design flexibility. the group should be able to pick WebIDL or REST API or both.

AdrianHB: let me rework to say that we are going to standardize the flow and the message format.
... for example, on a mobile there might be a way to communicate between apps so an installed wallet on the mobile can be talked to from another app on the same mobile.

<Zakim> manu, you wanted to mention that WGs should have an idea of the specs they'll create.

AdrianHB: through custom URI schemes, for example.

manu: Another thing about deliverables section. The W3C really wants to see what the group is going to deliver.
... if that section is empty or has handwaving, the members get nervous
... so we can say "we know we are going to need a vocab." We can also have optional deliverables "WebIDL is optiojnal. Rest API is optional."
... optional gives the AC an idea of what might be generated, and allows flexibility to the working groupo.

<manu> +1 to standardizing messaging/flow, and then separating WebIDL interface, and a REST API interface.

<Ryladog> +1

AdrianHB: Are people comfortable with standardizing messaging and a flow, and then also possibly providing interfaces as deliverables.

Sounds like everyone agrees.

manu: where will you be editing the charter?

AdrianHB: I will do it on github.

Use Case Updates

<manu> https://dvcs.w3.org/hg/webpayments/raw-file/default/latest/use-cases/index.html

manu: I have integrated some input. There is more to do.

<manu> https://www.w3.org/Payments/IG/wiki/Use_Cases_Task_Force

<manu> Moved actual use cases to here: https://www.w3.org/Payments/IG/wiki/Use_Cases_Task_Force/Use_Cases

<manu> This is now a high-level summary: https://www.w3.org/Payments/IG/wiki/Use_Cases_Task_Force

manu: still need to add KYC and alibaba use cases
... hope to have the changes done by next wednesday

Capabilities document

<inserted> scribenick: manu

Shane: Converted Google Doc for Capabilities into ReSpec
... unfortunately, due to some artificial restrictions, there are issues w/ the sections of the document.
... It's looks better than before, but we need agreement on how to make the sections look better.

Capabilities in ReSpec: https://dvcs.w3.org/hg/webpayments/raw-file/default/latest/capabilities/index.html

Shane: If you look at the Table of contents, under each capabilities - there are subsections - shouldnt' be in table of contents, sections end up in there - if you tell them not to, they format in some weird way.
... This doesn't look quite synchronized, if you go into core/security section.

<ShaneM> https://dvcs.w3.org/hg/webpayments/raw-file/default/latest/capabilities/index.html#core-and-security

Shane: you'd notice the items in 1 and subitems of 1 and 2, and so forth - those should be automatically through the stylesheet.
... I created a section in github - common - glossary, stylesheets, etc. That styling is in there.
... The other thing is the glossary.

Unified Glossary

Shane: If you look at the bottom, there is a glossary section - any time you reference those sections, you put them in an HTML <A> tag

<ShaneM> <a>payee</a>

Shane: When you do that in the document, it'll auto-link to that - any terms get removed automatically.
... There are limitations to this feature - real limitation is that "terms" have /a/ name, but we refer to them in multiple ways.

<ShaneM> <a>payees</a>

Shane: If I said "payees" - it wouldn't work

<ShaneM> <a title="payee">payee</a>

<ShaneM> <a title="payee">payees</a>

Shane: you can do that, and it'll link to the right term.
... An extension to ReSpec is to specify aliases for a term, and it just magically works.
... Comment about Capabilities document - we have a "payment services provider" term, and we are very inconsistent in the way we use that term.
... Sometimes it's payment services provider, or payment services provider, etc. I harmonized all of them to the way they're in the glossary.

<AdrianHB> +1 for glossary definition

Manu: We need to figure out what that thing is.

<AdrianHB> "payment services provider"

<AdrianHB> Thanks Shane!

<inserted> scribenick: ShaneM

manu: We are going to have two glossary documents.
... one is the terms
... the other is a document that will take the terms and then relate them to other terms in the industry.
... SWIFT has definitjons. IBS has definitions. we should link to all of them.

Roadmap

manu: I have not touched it much.
... thought about what people have said. I know what needs to be updated. Will try to make the updates for the call tomorrow.

- DRAFT -

Web Payments IG - Use Cases Task Force

09 Jul 2015

Attendees

Contents

Introduction to Matt Collier

Use Case Updates

Capabilities document

Unified Glossary

Roadmap

Summary of Action Items

Scribe.perl diagnostic output