RE: New Web Payments Architecture document proposal

Hi,

No doubt many if not all of you already know which documents to look at and comment, and which ones to - in fact - ignore.
I must say I am still tapping in the dark largely. 
I have been reading about a dozen documents so far, both from the references given below as well as surfacing from 'Google searches'.

I personally observe a discrepancy between - on the one hand - the many persons and entities involved in the work and on the other hand the 'age' of the documents I encounter, seen the number of flaws, omissions, 'white spots', etc. that I perceive.
 
Surely, these matters must have been covered by now (given the amount of people involved combined with the age of the documents) .... which can only lead me to one conclusion: so far I obviously have not been able to find the most recent working versions ;-)

I'm sure you agree that commenting on the basement is a bit a waste of effort, if everyone is already working on the second floor. I've been offered help to find my way in the documents by individuals reading about my quest. I surely appreciate that, but this individual support won't help 'the newbies coming after me'.

This is W3C right ? Following up on e.g. (from 'Web Principles'):
"Any architecture grounded in the Web should respect well-known Web principles such as:
• Adhering to Web architecture fundamentals
• Being open and usable by anyone, including those who are not yet connected to the Web"
I take the liberty to translate that into the expectation that there will be somewhere a single well-maintained (web-)page containing all the links (URL's) to the most recent versions of the documents necessary to be able to participate and contribute .... Can someone help me find that page if it is indeed there ? Should I join forces somewhere to help building the one ? I feel a bit stuck at the moment.

Please advise,



Greetz
Peter



Peter Potgieser

Business Innovation
Senior Consultant Industry Standards
e-mail: p.g.l.potgieser@planet.nl
GSM: + 31 6 301 803 99

-----Original Message-----
From: Manu Sporny [mailto:msporny@digitalbazaar.com] 
Sent: Saturday, June 25, 2016 6:19 PM
To: Peter Potgieser; 'Web Payments WG'; 'Web Payments IG'
Subject: 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/


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Received on Sunday, 3 July 2016 11:26:20 UTC