Re: Presentation to Web Payments IG

On 10/18/2014 05:48 PM, Jorge Zaccaro wrote:
> *- Use cases:* +1           (though I would also include 
> microtransactions (e.g. 1 cent payments))

It does include microtransactions, but it seems as if we've lost the use
case along the way:

https://web-payments.org/specs/ED/use-cases/2011-10-25/#micropayments-to-thousands-of-individuals

We should probably merge the old use cases document w/ the new one at
some point.

> *- Tech Stack:/               /*_*Digital Wallets +10*_

For some definition of "digital wallet". See the previous email wrt. why
the term is problematic:

http://lists.w3.org/Archives/Public/public-webpayments/2014Oct/0095.html

> - WPCG-WPIG: +1       (though I'd love to see them merge)

They're probably never going to merge due to W3C process, membership
requirements, and intellectual property concerns. This is by design. A
merge would mean that most everyone in the Web Payments CG (that is not
also a W3C member) would not be able to directly participate in the
discussion. No audio recorded telecons, no ability to dial in at will, etc.

The Web Payments CG is where much of the pre-standardization work and
discussion happens. The Web Payments IG (and later) is where much of the
"specifically, what are we going to standardize and how are we going to
do it" discussion happens. The former is accessible to all, the latter
is only accessible to W3C members and a handful of invited experts.

There will be a number of people in the Web Payments CG that will also
participate in the Web Payments IG (and successive technical groups).

> Before I jump into my answer to the question 'What do you need for a 
> digital wallet?', I must point that it will be strongly influenced by
> the API specification I'm working on: 
> https://github.com/playbanq/WebWalletAPI/.

+1 - the general approach that you're taking closely matches the set of
Web Payments specs that we currently have.

> In my opinion, what we need for _digital wallets to become part of 
> the core architecture of the Web_ is basically to seize the existing
>  Web infrastructure and follow the architectural principles of the 
> Web, meaning:

+1

> *- URL identification: *Just like blog posts/photos/videos, digital 
> wallets on the Web should be resources that can be referenced by a 
> URL, so that if you want to engage in a particular transaction with 
> another party, you just need to share a link to your wallet as if you
> were sharing a link to your homepage, your social network profile or
> your email address (e.g. "did you like this article/song/video? 
> Tip/donate 1 cent to _https://wallet.example.com/mywalletid_ by 
> clicking the link or the tip button...[plus some authorization flow 
> undoubtedly]).

+1

> *- HTTP-based interactions:* Assuming that each digital wallet is 
> identified by a URL, then we should be able to interact with them
> via _HTTP methods_: GET balance, POST funds, PUT debit card, DELETE 
> credit card, LOCK wallet, UNLOCK account, and so on. Having HTTP as a
> means of interfacing with wallets and carrying out transactions would
> certainly increase the likelihood of achieving interoperability
> between different stakeholders and the different payment methods.

+1

> *- RESTful architecture:* If the objective of the WPIG is to 
> 'establish a common ground for payment service providers on the Web 
> Platform', and other W3C Working Groups have achieved similar 
> objectives in other areas by agreeing on a set of APIs for vendors to
> implement (e.g. HTML5), maybe it would make sense for the Web 
> Payments initiatives to agree on a set of _RESTful APIs_ designed to
>  expose and enable interactions with digital wallets in a _uniform 
> and standardized way_. It would certainly take some time to agree on
>  things such as the API endpoints and response bodies, but there are
>  several basic interactions that we would immediately agree on such 
> as a /balance endpoint.

+1

> Furthermore, if we would take the REST API approach for digital 
> wallets on the Web, there would already be a handful of proven 
> authorization/security technologies such as the OAuth 2.0 protocol 
> that would be extremely useful both for _payment initiation_ using 
> the OAuth 2.0 authorization flows and _transaction tokenization_ 
> using nonce/revokable/expirable tokens (e.g. JWTs).

-1 - Digital Bazaar started off with using OAuth and it turns out that
it's non-optimal when you take the larger picture into account. The same
is true for JWT. The JWT bits of our concerns can be found here:

http://manu.sporny.org/2013/sm-vs-jose/

Unfortunately, we haven't had the chance to outline why OAuth isn't
great when it comes to access control (when you factor in everything
else that the payment technology has to do).

> Although the 'development of technical standards is not in scope for
>  the Interest Group', my believe is that if we agree on some kind of
>  Web API for exposing and interacting with resources that represent a
>  medium of exchange + a store of value + a unit of account, it will 
> not matter which device/technology or physical/digital context you 
> are carrying on transactions from, since in the background all 
> vendors and environments would be using _the same mechanisms to 
> exchange value on the Web_, regardless of how fancy or tangible their
> user interfaces might be.

I don't know if you've been tracking the technical work in the Web
Payments CG, but that's exactly the approach that the current set of
specifications take.

-- 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/

Received on Sunday, 19 October 2014 19:47:57 UTC