Re: Payment Protected Resources -- Using HTTP 402

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


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