Re: sketching out HTTP 402 workflow

On 27 July 2015 at 15:06, Adrian Hope-Bailie <adrian@hopebailie.com> wrote:

> Yes, there was a diagram included in a previous version of the charter
> which has been moved to an FAQ (under development) which will be referenced
> by the charter (to keep it from being too verbose).
>
> It's still in GitHub though here:
> https://raw.githubusercontent.com/w3c/webpayments-ig/master/latest/charters/images/WebPaymentsBasicPaymentFlow.png
>

This is excellent!


>
>
> I think there are a number of ways to deal with the 402 use case under
> this flow, I'd be interested to hear from others how they'd approach the
> problem.
>
> Example (feels wrong because requests are being sent in responses but I
> think it works well nonetheless):
>
> GET - https://example.com/someresource
>
> 402 - Payment Required
> Location: https://example.com/payment/processing/endpoint
> <response body contains payment initiation request document per standard>
>

So this was my first great question on the 402 response.

1. Should it return the location header
2. Should it return a body
3. Both of the above are permissible

see also 403 returning a message body: https://tools.ietf.org/html/draft-
ietf-appsawg-http-problem-00

I still dont have a good answer to this question.  My current proof of
concept is going to go with (2) but I'm open to idea.


>
> POST - https://example.com/payment/processing/endpoint
> <request body contains payment initiation response document per standard>
>
> 200 - Success
> <response body contains payment completion request document per standard>
>
> POST - https://example.com/payment/processing/endpoint
> <request body contains payment completion response document per standard>
>
> 302 - Found
> Location: https://example.com/someresource
>
> GET - https://example.com/someresource
>
> 200 - Success
>
> On 27 July 2015 at 13:30, Melvin Carvalho <melvincarvalho@gmail.com>
> wrote:
>
>>
>>
>> On 27 July 2015 at 13:15, Adrian Hope-Bailie <adrian@hopebailie.com>
>> wrote:
>>
>>> Melvin,
>>>
>>> Have a look at the flow that's been proposed in the Web Payments WG
>>> draft charter[1]. It consists of two request response pairs to establish
>>> the terms of the payment and complete it's execution. The primary use case
>>> (motivated by the browser vendors who are all participating) is to exchange
>>> these messages via a browser API but the 402 use case for web services is
>>> not out of scope.
>>>
>>> The intention is for the standard to be sufficiently general that both
>>> push and pull payments will be supported. The whole flow is initiated by
>>> the payee sending a payment initiation request document to the payer which
>>> contains the terms of payment and a list of supported payment methods. This
>>> could be passed as the body of the 402 response from the API as well as a
>>> location (or other) header indicating where to POST the initiation response?
>>>
>>
>> Looks good!
>>
>> So Alice wants to view an article, but it requires payment.
>>
>> Pre Payment / Registration -- she will require a balance in a wallet to
>> pay (this is done out of band)
>>
>> Negotiation of terms / Payment Initiation Request -- the 402 will tell
>> alice she needs to pay, and give her the terms that are acceptable to
>> unlock the article, and how
>>
>> Negotiation of payment instruments / Discovery -- this is quite easy in
>> my system at the moment because wallets only use one currency (later
>> versions may have more).  Alice will discover how to securely initiate a
>> payment.  Normally this will be to send the correct data structure to an
>> access controlled inbox that only she can access.
>>
>> Payment processing and completion -- after sending the payment, it is
>> verified, and either accepted or rejected.  A notification is sent back to
>> alice of the status and where to find more details.  The browser can then
>> proceed to view the article, which will have been unlocked to Alice.
>>
>>
>>>
>>> I'd be interested to see how the 402 use case could be solved using the
>>> same set of messages and flow as the WG is planning to standardise. This
>>> would be valuable input into the WGs work.
>>>
>>> Adrian
>>>
>>> [1] http://www.w3.org/2015/06/payments-wg-charter
>>>
>>> On 27 July 2015 at 10:11, Melvin Carvalho <melvincarvalho@gmail.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On 27 July 2015 at 04:31, Steven Rowat <steven_rowat@sunshine.net>
>>>> wrote:
>>>>
>>>>> On 7/26/15 2:56 PM, Melvin Carvalho wrote:
>>>>>
>>>>>> You can see a demo partly completed at:
>>>>>>
>>>>>>
>>>>>> http://inartes.com/?contentURI=https:%2F%2Finartes.databox.me%2FPublic%2Fdante%2Finferno-02%23139
>>>>>>
>>>>>> Click on "Next Verse"
>>>>>>
>>>>>
>>>>> Awesome!
>>>>>
>>>>> Just the kind of demo I've been hoping could happen for the last, oh,
>>>>> ten years?
>>>>>
>>>>> I'm not Dante, but I certainly have lots of material I could set up
>>>>> with something like this if/when it's operational (and/or beta).
>>>>>
>>>>
>>>> Sure, actually it can already point to any text so long as it's split
>>>> into chapters and verses.
>>>>
>>>> I'd like to add some more texts e.g. from
>>>>
>>>> http://www.poetryintranslation.com/
>>>>
>>>> And maybe finnegans wake (my favourite!) :)
>>>>
>>>>
>>>>>
>>>>> Is pseudo-anonymity possible (for the payee)?
>>>>>
>>>>
>>>> Great question.  I havent really thought this through.  But possibly
>>>> yes.  How would you imagine pseudo-anonymity to work?
>>>>
>>>>
>>>>> Will accepting Bitcoin be possible? Paypal?
>>>>>
>>>>
>>>> As it's decentralized, I dont decide.  Merchants and users will decide
>>>> on the currency.  But bitcoin is the default, so far :)
>>>>
>>>>
>>>>>
>>>>> O what fun. :-)
>>>>>
>>>>> SR
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>     I'll be using the SoLiD framework for this.
>>>>>>
>>>>>>     Anyone see any obvious flaws in the workflow?
>>>>>>
>>>>>>     [1] https://linkeddata.github.io/SoLiD/
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>> Sent from a mobile device, please excuse any typos
>>>
>>
>>
>