Re: New Web Payments Architecture document proposal

On 06/24/2016 10:20 AM, Peter Potgieser wrote:
> I recently started my participation in the WPIG and I am trying to 
> get up to date with the matter at hand.

Welcome to the group, Peter!

> One of the first documents I dove into is 
> UNOFFICIAL-web-payments-architecture-20160618/

I assume you're talking about this document (the link above is listed in
the document, but broken due to the unofficial status of the web
payments architecture summary doc):

https://w3c.github.io/webpayments/proposals/wparch/

Other suggested reading for Web Payments IG:

https://www.w3.org/Payments/IG/Vision

https://www.w3.org/TR/web-payments-use-cases/

> I have a number of questions - of course. I have been trying to find
>  the answers by going through the information available, but I got a
>  bit lost.

It's a bit of a maze at the moment, apologies for that. :)

> And seeing that (for instance) 'last update' of 
> https://www.w3.org/Payments/IG/wiki/Glossary is more than a year ago
>  and some action points have a similar age (see for instance 
> https://www.w3.org/Payments/IG/track/actions/open, the action on ISO
>  and X9 ) I started fearing being on the wrong tracks.

The latest version of the Web Payments IG Glossary can be found here:

http://w3c.github.io/webpayments-ig/latest/glossary/

Note that it is a mess. Due to the quick pace in the Web Payments WG, we
have multiple editors adding/modifying that glossary simultaneously thus
resulting in less cohesion than we'd like.

> I did not want to annoy everybody with my ‘learning in’

Don't worry about doing that. We have 170+ participants between both
groups. I expect that a non-trivial number of us have the same questions
that you do.

> If I have comments on a document, how am I supposed to do that?

If in doubt, send your comments/questions to the mailing list. It's
ultimately the job of the editors of the document to track these
comments and respond to them.

If you want to make life easy on the editors, file issues for things
that you know are bugs. Issues for the Web Payments IG documents can be
filed here:

https://github.com/w3c/webpayments-ig/issues

Issues for the Web Payments WG can be filed on each documents issue
tracker (which you should be able to find at the top of the document
somewhere). For example, to log bugs against the Web Payments Browser
API specification, you can do so here:

https://github.com/w3c/browser-payment-api/issues

> It would be nice if the document had line-numbers for reference but 
> it doesn’t;

I doubt that will ever happen at W3C. It's extra visual clutter that
most don't care about. If you want to make a comment on a section, note
the title of the section and include around a sentence or two of text.
That's enough for most people to know exactly which section of the
document you're talking about.

> - What is the (background) information this document is based on ? 
> For example, a sentence like ‘Improve the interface experience for 
> all stakeholders’ could refer to experience of a human user while 
> interacting via the screen of a mobile phone, but it could equally 
> mean the interface used ‘down there’ at the TCP/IP level ….

I was trying to be succinct, simplify the text, and be general. It means
both the human interface (UI) and machine interface (API). That said,
perhaps it's too vague. Thoughts?

> Is there a layered structure – like the European EIF, or perhaps
> even the good old OSI 7 layer model – in which the statements can be
>  positioned ?

Most of what we're discussing happens at OSI layers 5, 6, and 7.

> - Is there a ‘Definition of Terms’ ? For example, the sentence ‘The 
> requested mechanism to be used for processing the payment. Examples 
> include: credit card, ACH, SEPA, and Bitcoin.’

Yes, the terms are imported from the glossary, which is a bit of a mess
right now:

http://w3c.github.io/webpayments-ig/latest/glossary/

> seems to mix up legal framework (SEPA 
> http://ec.europa.eu/finance/payments/sepa/index_en.htm ) with 
> instrument (credit card) with concept / infrastructure (ACH), etc.

Any suggestions to use the right terms or examples are very welcome.

> By the way, ACH in US 
> (https://en.wikipedia.org/wiki/Automated_Clearing_House ) is 
> something rather different from an ACH like Equens 
> (http://www.equens.com/aboutus/index.jsp ); in order to be able to 
> formulate effective statements it is necessary to identify what terms
> exactly mean. And the Glossary I found does not help here ... -

Agreed... what do you think would help us do this more effectively?

> is there a collection of ‘scenarios’ depicting payments (and their 
> causes) in which the payments you are focusing on can be positioned ?
> I do not mean 'use cases' but instead a focus more concentrated on 
> 'infrastructure'. I mean, there are many well established practices 
> in the marketplace and it would help uptake and understanding if the
> mechanisms you depict could be easily positioned in them.

We have a Web Payments Flows task force that may be working on what
you're alluding to above:

https://github.com/w3c/webpayments-flows/wiki

> If I see a sentence like ‘Specific information pertaining to the 
> transaction. Examples include: price, transaction reference number, 
> and items being purchased.’ then it makes me think more about an 
> invoice than a payment actually and usually the invoice information 
> is not repeated in the payment but a reference to the invoice itself
>  is given instead.

Yes, this is a by-product of the direction the Browser API has taken:

https://w3c.github.io/browser-payment-api/

There was an attempt early on to separate the ecommerce/shopping
cart/invoicing portion from the payment portion. That attempt failed and
the API currently includes both the request for payment and information
traditionally considered a part of an invoice.

> - I strongly suggest you take a look at for instance 'ISO20022 for 
> Dummies' (copy obtainable via http://www.iso20022.org ) to help 
> understand the positioning of electronic messages for this purpose.

There are many in the group that are fully aware of ISO20022 and its
purpose. We also have participants from the ISO20022 Registration
Authority in the group.

The Web Payments Core Messages specification:

https://w3c.github.io/webpayments-core-messages/

and Web Payments HTTP API specification:

https://w3c.github.io/webpayments-http-api/

are attempting to align as much as possible with ISO20022 while not
completely de-coupling from the Browser API.

Underlying all of this is a mis-alignment in philosophy and the groups
are currently trying to work their way through this. To be clear, I
think the mis-alignment has more to do with different participants
having different priorities.

> I do not understand the use case given in 5. How does this relate to 
> the current ‘common practice’ ?

That section attempts to demonstrate how a tokenized credit card
transaction would occur under the Web Payments architecture.

> What is new and where are the overlaps ?

There are at least the following "new" concepts:

1. The concept of a payment application.
2. The concept of routing a payment request to a payment application.
3. The concept of routing a payment response to the payee.

> No doubt some of my questions are already answered somewhere – but 
> forgive me in that case where I could not find the answers (yet). I 
> really hope you can help me out.

I hope this helps, Peter. Great questions, and let us know if you have
any other follow-up questions.

Again, welcome to the group! :)

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
JSON-LD Best Practice: Context Caching
https://manu.sporny.org/2016/json-ld-context-caching/

Received on Saturday, 25 June 2016 16:19:31 UTC