Re: Payment Protected Resources -- Using HTTP 402

On 2014-07-31 01:04, Melvin Carvalho wrote:
>
>
>
> On 30 July 2014 18:15, Anders Rundgren <anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>> wrote:
>
>     On 2014-07-30 18:09, Melvin Carvalho wrote:
>
>
>
>
>         On 30 July 2014 17:24, Anders Rundgren <anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com> <mailto:anders.rundgren.net@__gmail.com <mailto:anders.rundgren.net@gmail.com>>> wrote:
>
>              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> <mailto:anders.rundgren.net@__gmail.com <mailto:anders.rundgren.net@gmail.com>> <mailto:anders.rundgren.net@ <mailto:anders.rundgren.net@>____gmail.com <http://gmail.com> <mailto: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.
>
>
>         There's no requirement for the browser to change.  Every browser that I know of, can accept a 402 code today, and can render HTML.  That's because, it's already standarized as part of HTTP.  So from the perspective of the browser and the user, it's a non disruptive change.
>
>
>     Right, but what does the 402 add to this particular scenario today?
>
>
> There's no change to the standard browser experience.

It was easier for me understanding the following:
https://bitcointalk.org/index.php?topic=3895.0
which indeed suggests a changed browser experience.

> The only change is for spiders, robots and AJAX agents than can pass the code on to a handler.

Would those interpret localized HTML?  I hope not.

Anders

>
>
>     Anders
>
>
>
>
>              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 Thursday, 31 July 2014 00:59:37 UTC