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

Re: HTTP 402 in use

From: Andrew Bransford Brown <andrewbb@gmail.com>
Date: Wed, 28 Mar 2018 09:02:22 +0700
Message-ID: <CAPS+YFJzuTrPBE58WbwbdkhMBqLicV0Wab+06HcNgMe36ewoyA@mail.gmail.com>
To: Melvin Carvalho <melvincarvalho@gmail.com>
Cc: Adrian Hope-Bailie <adrian@hopebailie.com>, Web Payments <public-webpayments@w3.org>
A contract is a document.  It is composed over time as participants
add elements/events (Offer, Terms, Agreement, Deliver, Notice, etc.)

So HTTP PUT can construct the contract.




On Wed, Mar 28, 2018 at 3:39 AM, Melvin Carvalho
<melvincarvalho@gmail.com> wrote:
>
>
> On 27 March 2018 at 22:28, Andrew Brown <andrewbb@gmail.com> wrote:
>>
>> Melvin and Adrian:
>>
>> We could put an xml document in the message body, and put the next event
>> in the message header.
>>
>> Xml document - describes the contract and current status.
>> Message header - next event to be added to the xml document.
>
>
> IMHO, the web scales really well when one document does one thing.
>
> For example a document that contains content, but has a challenge
>
> Or a document that has payment information, then leads you to a content link
>
> When mixing these two workflows, it's more difficult for clients to track
> and cache previous bodies
>
> To my mind when getting a 402, it's saying -- there's content here (e.g. a
> movie) -- but you need a payment
>
> It would be a nice separation of concerns if the negotiation of a payment,
> especially if XML or JSON or RDF type documents are going to be parsed,
> happened on another page.  Perhaps an exception would be very trivial work
> flows, but even in that case there is danger of a slippery slope.
>
> Nothing is really prohibited on the web, but in my head a clean design would
> be.
>
> - Content on a page
> - 402 if you need to pay
> - If you need to pay, direct the user agent to some kind of payment API or
> service
>
> I could be wrong on a number of points above, and appreciate there are
> numerous ways to model this
>
>>
>>
>>
>>
>> > On 27 Mar BE 2561, at 12:16 AM, Andrew Bransford Brown
>> > <andrewbb@gmail.com> wrote:
>> >
>> > 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 Wednesday, 28 March 2018 02:03:04 UTC

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