Re: sketching out HTTP 402 workflow

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
>