Re: What single thing should we deliver?

Hi All,

In reading the thread below, and thinking about the discussions so far on
the group and the exchange below, I wanted to offer a perspective for the
groups consideration that might help the discussion.  Looking at the
charter of the work we were commissioned to do, there are many aspects and
goals to accomplish, but perhaps 2 key themes/patterns that are
complimentary and supportive of one another.  First, for a standard to
emerge that will be ubiquitous and allow for they type of global
interoperability and benefit we seek to achieve, there is a body of work
which must seek to abstract and harmonize what exists with what will come
next.  This body of work includes things like reviewing the existing as
well as emerging landscape to identity the common concepts and patterns
and creating a stable core upon which to build.  This will help provide a
bridge/on-ramp from where we are today, to the target state we hope to
achieve. This will be critical to gain momentum/buy-in and allow for the
graceful transition of existing investments and infrastructure that
underpins existing models and systems to occur.  Second, and equally
important, are the real life use cases and reference architectures/apis
which serve to validate specific uses of the standard in a way that
informs and contributes back to the improvement of the core standard.  In
a perfect world, these two bodies of work would co-evolve and build upon
one another such that they enable both a stable foundation which enables
broad improvement of the ecosystem and as well as practical
implementations that both benefit from and contribute back to the core.

That being said, reframing the question of "what single thing we should
deliver?" to something like "What's the best way to prioritize and align
the IG's activities so that we can achieve balanced progress on both the
foundational concepts that will enable longer term interoperability and
the specific frameworks and working examples that will serve to create
traction, industry engagement and critical feedback/input into the
concepts that contribute to building a solid interoperable core.   In
short, perhaps it is worth keeping a focus on the core abstractions and
interoperability as well as focusing on priority use cases, reference
models, and sample architectures use and in turn inform the roadmap and
interoperability work.  From past experience, the former tends to be more
abstract and higher level, while the latter tends to be more specific and
focused.  So for work efforts like the a) roadmap, b)identifying relevant
interfacing standards, and d) projections and e) Glossary efforts,
hopefully they would be sufficiently broad to allow for reference
architectures different web payment models to be developed for subsequent
use  cases as they are identified, while the work on c) Potential Sample
Architectures would be focused on whichever set of use cases and models
are best positioned to build momentum and practical real world feedback
into the roadmap work.

As always, I'm deeply interested in others thoughts on this - hope this is
helpful,

Pat

On 11/26/14 2:24 AM, "Joerg.Heuer@telekom.de" <Joerg.Heuer@telekom.de>
wrote:

>Hello all,
>
>Stephane's view is what made me join the activity. I think W3C will be
>able to define interfaces and APIs on generic payment transaction
>handling, thereby possibly making it easier for push-payments to
>integrate with our standards and recommendations, but better not
>declaring a specific way as 'the standard'.
>
>IMO we need to take the stance of the user and look at transactions from
>this side. Do they core - so they even know - whether its push or pull?
>Likely not. I say: great! This is what abstractions do - and this one is
>already established. Underneath, there might be a plethora of payment
>methods to implement it.
>
>Cheers,
>	Jörg
>
>-----Original Message-----
>From: Stephane Boyera [mailto:boyera@w3.org]
>Sent: Dienstag, 25. November 2014 14:44
>To: Erik Anderson; public-webpayments-ig@w3.org
>Subject: Re: What single thing should we deliver?
>
>Hi Erik, Manu
>
>first on manu's point, it think it is fine to work on a specific item,
>and I tend to agree that the push-based payment sounds like the less
>crowded area compared to e.g. token-based payments, so surely the easiest.
>However, I'm personnally more in favor for now to focus on the big
>picture and use-cases at least for the enxt couple of months.
>Identifying where the gaps are (either various proprietary solutions like
>in token-based payments) or absence of standards (like push-based
>payment) would allow to laucnh parrallel work on parrallel pieces,
>instead of telling the world that web payment ig==push-based payment. I
>tend ot think that we would loose visibility and credibility if we send
>the message globally that w3c web payment activity == standardization of
>push-based payment for next 12 months.
>In all cases, I agree with you that prioritization based on short-win
>will have to happen, but again i tend ot think that this should come
>after we have a clear roadmap.
>
>Now back to Erik's point, I'm not sure I agree with you. There is a big
>difference between interfacing web applications with push based payment
>solutions and implementing payments. E.g. paypal model based on e.g.
>http redirect is a model of push-based payment: this is all web-based:
>you ahve api, data format, authentication, then receipt sent to both
>parties. this is what we need to take care imho. How behind their walls
>paypal is moving money from one account to another is imho not more part
>of the web and out of the scope of this group.
>or did i misundertand your point?
>
>cheers
>steph
>
>Le 25/11/2014 13:37, Erik Anderson a écrit :
>> Agreed but push payments is more about back end IETF standards than
>> front end Web standards, correct? We would have to focus more across
>> various domains to achieve this, not just W3C?
>>
>> Erik Anderson
>>
>>
>> -------- Original message --------
>> From: Manu Sporny <msporny@digitalbazaar.com>
>> Date:11/24/2014 11:05 PM (GMT-05:00)
>> To: public-webpayments-ig@w3.org
>> Cc:
>> Subject: What single thing should we deliver?
>>
>> The discussion so far has given me hope that we're going to be able to
>> recommend doing something substantial with the Web Payments work. We
>> have some great people involved, which got me thinking - if we could
>> only deliver one thing, what would it be? What would be the most
>> impressive/simplest thing we could do? Some thoughts on that line of
>> questioning:
>>
>> It seemed like push-based payments was pretty high on everyone's list
>> at TPAC of important things to do from a safety perspective.
>>
>> The ideal use case for the buyer seemed to play a pivotal role as well
>> (more so than the ideal use case for the merchant or the payment
>> processor, even those were deemed very important).
>>
>> If I had to summarize the single most important thing that this group
>> should do, I think it would be something like this:
>>
>> Make it so that a buyer can:
>>
>> 1. Go to a website
>> 2. Click a Buy button
>> 3. Be provided an offer of sale / invoice 4. Choose their method of
>> payment from an array of payment instruments 5. Complete the purchase
>> and send the proof of purchase to the merchant
>>     to receive their goods/service
>>
>> All of this would be done w/o exchanging any theft-worthy data with
>> the merchant.
>>
>> If we do nothing else, wouldn't the above be a huge step forward in
>> worldwide payments? If so, shouldn't we craft the narrative and the
>> roadmap around achieving the above?
>>
>> -- manu
>>
>> --
>> Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
>> Founder/CEO - Digital Bazaar, Inc.
>> blog: The Marathonic Dawn of Web Payments
>> http://manu.sporny.org/2014/dawn-of-web-payments/
>>
>
>-- 
>Stephane Boyera        stephane@w3.org
>W3C                +33 (0) 6 73 84 87 27
>BP 93
>F-06902 Sophia Antipolis Cedex,
>France
>



This e-mail message, including attachments, is for the sole use of the intended recipient(s) and may contain confidential or proprietary information.  If you are not the intended recipient, immediately contact the sender by reply e-mail and destroy all copies of the original message.

Received on Wednesday, 26 November 2014 18:47:12 UTC