Re: Payment Protected Resources -- Using HTTP 402

On 30 July 2014 18:15, Anders Rundgren <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>> 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>>> 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.

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


>
> 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 Wednesday, 30 July 2014 23:04:47 UTC