Re: Payment Protected Resources -- Using HTTP 402

On 30 Jul 2014, at 10:38 pm, Melvin Carvalho <melvincarvalho@gmail.com> wrote:

> 
> 
> 
> On 28 May 2014 15:51, Anders Rundgren <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.
> 
http://www.news.com.au/technology/online/federal-government-proposes-cracking-down-on-internet-piracy/story-fnjwneld-1227007716641 

Could provide alternatives..  

> 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.
>  
Honestly - i don’t like it - would far prefer to see implementations that support voluntary rewards systems, rather than mandated ones.  Yet, i both understand the requirement and the choice you’ve made to pursue this path, over others.

IMHO - a 402 for an invalid account (meaning perhaps, a WebID without WebCredits ID associated) might be a means to support environments where people are using ‘decentralised rewards’ concepts, in association to ‘liking’ posts, etc.  

perhaps find a way of demonstrating it, with something like a forked version of cimba (utilising the fav. icon for payments? A bit better than coming-up with a blunt instrument to solve the problems described in the link above.  yet. an ideological disappointment surely.) 

If it helps with personal identity / data rights related issues - i support it. Even though i think more focus needs to be made upon the rights of individuals with data and in-turn, rationalisation of data as a personal, civic, commercial, private, privileged or other form of property / economic asset (than seems to be prioritised atm) with natural legal entities being foremost in the minds, overall. 

Alternatively, perhaps encrypt a video’s keyframes with block-chain data, linked to a WebID.  or not… 

cheers.

Tim.h.

> 
> 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:48:11 UTC