- From: Melvin Carvalho <melvincarvalho@gmail.com>
- Date: Wed, 17 Jun 2015 07:38:06 +0200
- To: Anders Rundgren <anders.rundgren.net@gmail.com>
- Cc: UniDyne <unidyne@gmail.com>, "David I. Lehn" <dil@lehn.org>, Web Payments <public-webpayments@w3.org>
- Message-ID: <CAKaEYh+w4qkhZf+mtipFeCwEig5HnKE3zWXz_m=K0PBqDv1dOA@mail.gmail.com>
On 17 June 2015 at 07:34, Anders Rundgren <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>> 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. > > 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>>> 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>>> 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>>> 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>>> 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 05:38:35 UTC