W3C home > Mailing lists > Public > public-webpayments@w3.org > March 2018

Re: HTTP 402 in use

From: Andrew Bransford Brown <andrewbb@gmail.com>
Date: Tue, 27 Mar 2018 00:16:08 +0700
Message-ID: <CAPS+YFJeJuVsX-d84mw+1QVRBr7YzezRubbmFZL+jxyBW6P6Hw@mail.gmail.com>
To: Melvin Carvalho <melvincarvalho@gmail.com>
Cc: Adrian Hope-Bailie <adrian@hopebailie.com>, Web Payments <public-webpayments@w3.org>
Yes, I agree with most of that.

A payment is one of the "Deliver" messages in the 6 events of a contract.

On Tue, Mar 27, 2018 at 12:04 AM, Melvin Carvalho
<melvincarvalho@gmail.com> wrote:
>
>
> On 26 March 2018 at 18:47, Andrew Bransford Brown <andrewbb@gmail.com>
> wrote:
>>
>> HTTP message composition must be sufficiently granular to handle all
>> use cases.
>>
>> Here are 6 events in a contract, from initial offer to delivery:
>> [1] John Offer $1
>> [2] John Terms Water
>> [3] Mary Agree (becomes a contract)
>> [4] Mary Deliver Water
>> [5] John Deliver $1
>> [6] End transaction
>>
>> Headers to describe [1] John's Offer:
>> Transaction-ID:  123
>> Commerce-ID:  John
>> Event-Type:  Offer
>> Description:  $1
>> Time-Stamp:  2018-03-26T23:40:30
>>
>> Headers to describe [2] John's Terms:
>> Transaction-ID:  123
>> Commerce-ID:  John
>> Event-Type:  Terms
>> Description:  Water
>> Time-Stamp:  2018-03-26T23:40:31
>>
>> etc.
>>
>> Each is its own HTTP message?
>
>
> Given the complexity that arises, it seems a little unwieldy to stuff all of
> this information in headers.
>
> Similarly to put this information in the body also can be problematic
> because how do clients then cache the content, when it is changing and has
> its own state diagram, for any given resource.
>
> And putting things like a payment request in the body (although bonus marks
> for having the right content type) might not allow a human readable message
>
> Some quite tricky design trade offs
>
> A possible solution here might be for the resource yielding a 402 to
> redirect the client to a URI from which it can learn more and negotiate a
> payment.
>
> Then have a set of standard messages that can be used to pay e.g. what is
> the cost, where do I send the money, how do I send it etc.
>
>>
>>
>>
>> On Mon, Mar 26, 2018 at 10:10 PM, Melvin Carvalho
>> <melvincarvalho@gmail.com> wrote:
>> >
>> >
>> > On 26 March 2018 at 16:31, Adrian Hope-Bailie <adrian@hopebailie.com>
>> > wrote:
>> >>
>> >> Pity it only works on Lightning though... Would be nice to get some
>> >> collaboration on something that works across any payment network
>> >>
>> >> https://tools.ietf.org/html/draft-hope-bailie-http-payments-00
>> >> https://interledger.org/rfcs/0014-http-ilp/
>> >>
>> >>
>> >> https://medium.com/interledger-blog/http-ilp-paid-api-calls-with-interledger-fda53643a2eb
>> >
>> >
>> > Thanks for the pointers.
>> >
>> > I'm a fan of the work on lightning, however the 402 response itself
>> > doesnt
>> > seem to be lightning specific
>> >
>> > So it seems that the main difference is that this work uses
>> >
>> > X-Token
>> >
>> > vs the draft using
>> >
>> > Pay-Token
>> >
>> > And the body contains bolt11 payment request
>> >
>> > Both approaches seem reasonable?
>> >
>> > Perhaps the draft could look at a variety of implementations and use
>> > cases.
>> >
>> >>
>> >>
>> >> On 26 March 2018 at 13:15, Melvin Carvalho <melvincarvalho@gmail.com>
>> >> wrote:
>> >>>
>> >>> Very cool use of HTTP 402 -- Payment Required -- in the paypercall
>> >>> lightning network app
>> >>>
>> >>> https://github.com/ElementsProject/paypercall#paying-for-api-calls
>> >>
>> >>
>> >
>
>
Received on Monday, 26 March 2018 17:16:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:07:48 UTC