W3C home > Mailing lists > Public > public-webpayments@w3.org > July 2014

Re: Payment Protected Resources -- Using HTTP 402

From: Anders Rundgren <anders.rundgren.net@gmail.com>
Date: Wed, 30 Jul 2014 17:24:39 +0200
Message-ID: <53D90E37.2040208@gmail.com>
To: Melvin Carvalho <melvincarvalho@gmail.com>
CC: Web Payments <public-webpayments@w3.org>
On 2014-07-30 14:38, Melvin Carvalho wrote:
>
>
>
> On 28 May 2014 15:51, Anders Rundgren <anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>> wrote:
>
>     With this complete lack of clarity, the WebPayments and WebID groups
>     won't ever leave their Incubation, IG or CG levels.
>
>     HTTP 402 to a browser user?  Hardly.
>
>     So obviously there must be at least two server-actors involved, right?
>
>     If not, the whole idea is bogus since *internal* operations can be built
>     as you like and do not need a standards committee for guidance.
>
>
> Been thinking this through a bit more, with almost an implementation ready.
>
> In the browser scenario the 402 is delivered, but so is human readable text.  The primary means to continue will be the user taking action, by clicking through a wizard that takes them through next steps.
>
> In the scenario of a robot or spider, if they have run out of credit they need to obtain a new token, and should be smart enough to know how to do this.  They keep using this token until that expires, then either get a new token, top it up, or send funds via a digital signature.
>
> The workflow for the user is initially non disruptive and does not change.  But as browsers get smarter either natively, or through polyfils etc.  The user experience has an upgrade path to make payments seamless.
>
> The 402 code is already baked into HTTP, so I'm just working out ways to use it.  I'm aiming to implement a simple pay wall as a first app., but the same technology could be used for pay per view, throttling, shared content, protecting sparql endpoints, streaming bandwidth or disk and so on.

Hi Melvin,

I understand the motives but would personally not take this route for browsers
which I regards as entirely different to "agents" even if use run HTTP.  For
the same reason I don't see HTTP Signatures as a useful browser extension either.

Requiring browsers to be smarter is OK, but only if they can perform some action
that the user cannot.  If there is some local service that the browser can call,
the server should be able to return the necessary webcode equally well.  If such
a service is available or not should be dynamically discoverable.

IMO, browsers remain the #1 pain-point for the WebPayment and WebID communities.

Anders

>
>
>     Anders
>
>
>     On 2014-05-28 14:47, Kingsley Idehen wrote:
>
>         On 5/28/14 1:27 AM, Anders Rundgren wrote:
>
>             The most important thing in a payment scenario are the actors and
>             their roles.  Linked Data in not a panacea.  If there are only two
>             actors, HTML is all you need.
>
>         Again, nobody is indicating that Linked Data is a panacea.
>
>         You need to be able to access, manipulate, and exchange data for
>         anything to function in our realm of existing. Linked Data simply makes
>         Data webby or web-like.
>         RDF based Linked Data simply ensures the relations that constitute the
>         Data are human and machine comprehensible.
>
>         RDF based Linked Data is a vehicle for encoding and decoding
>         information, via statements, in the medium provided by the Web (an HTTP
>         network).
>
>         RDF based Linked Data is a kind of Controlled Natural Language.
>
>         Without Language, we are unable to function.
>
>         Links:
>
>         [1] http://slidesha.re/QEqLZN -- Natural Language & RDF based Linked Data .
>
>         [2] http://bit.ly/1c3QeEc -- Language .
>
>
>
>
Received on Wednesday, 30 July 2014 15:25:26 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:07:32 UTC