- From: UniDyne <unidyne@gmail.com>
- Date: Wed, 17 Jun 2015 12:12:52 -0400
- To: Anders Rundgren <anders.rundgren.net@gmail.com>
- Cc: Melvin Carvalho <melvincarvalho@gmail.com>, "David I. Lehn" <dil@lehn.org>, Web Payments <public-webpayments@w3.org>
- Message-ID: <CAE3_Mcjy-b=AWf_BJj3yREKtyzD3DQmVCWXjnpo6cYCa2KWBFQ@mail.gmail.com>
@Anders - Others have ignored the browser in their payment solutions mostly for their own advantage, producing walled gardens that lock users and merchants into their own proprietary platforms to ensure they get their cut of the action. There's nothing fundamentally wrong about HTTP that would prevent a secure and pluggable payment solution from being built. In my head, a solution to 402 would look something like a WebSocket handshake in reverse, passing an endpoint and a secure token to start the payment process, should the client accept. On Wed, Jun 17, 2015 at 1:58 AM, Anders Rundgren < anders.rundgren.net@gmail.com> wrote: > On 2015-06-17 07:38, Melvin Carvalho wrote: > >> >> >> On 17 June 2015 at 07:34, Anders Rundgren <anders.rundgren.net@gmail.com >> <mailto:anders.rundgren.net@gmail.com>> wrote: >> >> On 2015-06-17 07:22, Melvin Carvalho wrote: >> >> >> >> On 17 June 2015 at 07:13, 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 2015-06-17 05:51, UniDyne wrote: >> >> Why limit yourself to a "Location" header? If you are >> expanding 402 into something useful, you might as well make use of >> additional headers to pass the payment requirements. The Location header >> might just be the endpoint payment must be submitted to. Other headers >> might include the payment parameters including amount, currency type, >> accepted methods. >> >> In lieu of a user-agent that actually provides these >> functions, it could easily be handled by a web app. >> >> It seems we've had this discussion before. >> >> >> Yes, and it still doesn't work :-) >> >> >> Disagree >> >> >> Why wouldn't the server know already at the time it provided >> the URL to the protected resource if it needs to be paid for or not? >> >> >> It does. >> >> >> Anyway, a payment system integrated in the user agent must >> provide "trusted chrome" otherwise such an integration would be pointless. >> >> >> Disagree. >> >> >> The universal Web Payment problem remains: linking 402 or >> anything like it to a payment process in a secure manner. >> >> >> Hopefully, not for long :) >> >> >> So far we have waited some 20 years so it all depends on what you >> consider "long"... >> >> >> Already started to implement. Just want to standardize to it scales. >> >> >> Apple, Google, Samsung and Facebook solved this problem by ignoring >> the browser. >> >> >> Good for them. >> >> Anders, this isnt advancing the topic, at all. >> > > Melvin, > > Anybody is free developing a Web Payment standard even if it will > unlikely reach the security bar set by the current "App"-based systems. > > For some people this is considered a problem for some other people it is > not. > > That's all. > > Anders > > >> >> Anders >> >> >> >> Anders >> >> >> On Tue, Jun 16, 2015 at 11:40 PM, UniDyne < >> unidyne@gmail.com <mailto:unidyne@gmail.com> <mailto:unidyne@gmail.com >> <mailto:unidyne@gmail.com>> <mailto:unidyne@gmail.com <mailto: >> unidyne@gmail.com> <mailto:unidyne@gmail.com <mailto:unidyne@gmail.com>>>> >> wrote: >> >> Yes, you can return headers including "Location" >> with a 402. The issue is that user-agents today won't do anything with it. >> For now, you would also need to include a page with a link as suggested by >> David. >> >> On Tue, Jun 16, 2015 at 8:34 PM, Melvin Carvalho < >> melvincarvalho@gmail.com <mailto:melvincarvalho@gmail.com> <mailto: >> melvincarvalho@gmail.com <mailto:melvincarvalho@gmail.com>> <mailto: >> melvincarvalho@gmail.com <mailto:melvincarvalho@gmail.com> <mailto: >> melvincarvalho@gmail.com <mailto:melvincarvalho@gmail.com>>>> wrote: >> >> >> >> On 17 June 2015 at 02:23, David I. Lehn < >> dil@lehn.org <mailto:dil@lehn.org> <mailto:dil@lehn.org <mailto: >> dil@lehn.org>> <mailto:dil@lehn.org <mailto:dil@lehn.org> <mailto: >> dil@lehn.org <mailto:dil@lehn.org>>>> wrote: >> >> On Tue, Jun 16, 2015 at 7:57 PM, Melvin >> Carvalho >> <melvincarvalho@gmail.com <mailto: >> melvincarvalho@gmail.com> <mailto:melvincarvalho@gmail.com <mailto: >> melvincarvalho@gmail.com>> <mailto:melvincarvalho@gmail.com <mailto: >> melvincarvalho@gmail.com> <mailto:melvincarvalho@gmail.com <mailto: >> melvincarvalho@gmail.com>>>> wrote: >> > I've implemented HTTP 402 a few times for >> payment protected resources. >> > ... >> > If payment is required, how does the >> client know what to do next? >> > ... >> > What about sending a Location: header >> telling the client where to go next? >> > >> > Then the client can find all the >> information about how to pay, their >> > balance, the cost etc. >> > ... >> >> Won't user agents only follow that Location >> for 3xx codes? How about >> just including human and/or machine >> readable info in the 402 response >> content? >> >> >> Seems possible. But are you allows to return >> data with a 4xx? Im not sure on this ... >> >> >> -dave >> >> >> >> >> >> >> >> >> >
Received on Wednesday, 17 June 2015 16:13:23 UTC