- From: Melvin Carvalho <melvincarvalho@gmail.com>
- Date: Sat, 27 Dec 2014 17:45:26 +0100
- To: Anders Rundgren <anders.rundgren.net@gmail.com>
- Cc: Mark Leck <markpleck@gmail.com>, Steven rowat <sn0281@uniserve.com>, Web Payments CG <public-webpayments@w3.org>, Eric Martindale <eric@bitpay.com>
- Message-ID: <CAKaEYh+beJKjaA1T6rV+zAOq76LNU4fAE=_xirm=X5R_0Atpfg@mail.gmail.com>
On 27 December 2014 at 15:16, Anders Rundgren <anders.rundgren.net@gmail.com > wrote: > On 2014-12-27 14:43, Melvin Carvalho wrote: > > >> On 27 December 2014 at 13:07, Anders Rundgren < >> anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>> >> wrote: >> >> On 2014-12-27 10:59, Melvin Carvalho wrote: >> <snip> >> >> >> I think we are either agreeing or going round in circles. >> >> >> I think you owe us a flowchart and UI description otherwise we won't >> get forward. >> >> >> I like the chrome extension and it could save a server URL. >> >> >> OK, I'm less enthusiastic since it is undocumented and >> chrome-specific. >> >> >> This is not the only way to implement it, I'm personally using >> X.509. >> >> >> Which is something entirely different which I have absolutely no clue >> about >> (in this context) unless you are talking about WebID-TLS where the >> URL is >> a part of certificate. >> >> >> Yes it is different. As I keep saying there's many ways to implement the >> 402 pattern. I'm not currently using webid+TLS but I will implement that >> soon. Right now, I simply use the fingerprint of the certificate as the >> wallet URL. So every certificate can have a balance and make authenticated >> secure transfers. >> >> This works fantastically well for me, but please note my stress that it's >> only one way to implement 402's. >> >> I'm sure you'll want to shoot his down, but if such a system doesnt suit >> your needs implement it another way or implement something else. This is >> just a way of doing payments on the client and server that some people like. >> > > Melvin, I don't feel an urge to shoot down anything, I just want to > understand how things work. > Since this list is intended for creating input to payment standards it is > a reasonable ambition. > I guess the other folks here then understand what you are doing, I must > confess I still don't :-( > I'm just associating balances with browser certificates, then allowing access to premium content to those with a positive balance, and giving a 402 to those that do not. > > To me the eternal question (in this context NB), is simply "who is doing > what and with whom and why" > > The Zero Click guys certainly didn't bother much about explaining that, > maybe it's a trade secret? > Just a proof of concept I think. > > Cheers, > Anders > > > >> Anders >> >> >> >
Received on Saturday, 27 December 2014 16:45:54 UTC