Re: sketching out HTTP 402 workflow

On 26 July 2015 at 16:22, Anders Rundgren <anders.rundgren.net@gmail.com>
wrote:

> On 2015-07-26 16:04, Melvin Carvalho wrote:
>
>>
>>
>> On 26 July 2015 at 08:04, Anders Rundgren <anders.rundgren.net@gmail.com
>> <mailto:anders.rundgren.net@gmail.com>> wrote:
>>
>>     On 2015-07-26 01:22, Melvin Carvalho wrote:
>>
>>         I'd like to sketch out a design and workflow for HTTP 402 that I
>> think would be possible to implement as a proof of concept
>>
>>         im trying to design a payment system using SoLiD and HTTP 402 ...
>> I wonder how it would go?
>>
>>         1    Alice wishes to view resource X costing 1 bit from wallet W
>>         2    resource X is ACL protected
>>         3    Alice visits controller website and indicates wish to view
>> protected resource
>>         3    Controller website sends back HTTP 402 saying payment
>> required and gives a protected location Y for Alice to send a payment
>>         4    Controller website subscribes to location Y
>>         5    If Alice is verified as sending a payment she is added to
>> ACL of X
>>         6    Payment is subtracted from wallet W
>>         7    Alice can view resource X
>>
>>         I'll be using the SoLiD framework for this.
>>
>>         Anyone see any obvious flaws in the workflow?
>>
>>
>>     Yes, web browsers don't support HTTP 402 in a way that make this
>> scheme feasible.
>>
>>     So you obviously rely on some mechanism like Chrome extensions or
>> AJAX.
>>
>>
>> Yes, I'm going to use AJAX.
>>
>
> That's a rather important piece of information in order to understand what
> you are looking for feedback on.
>

OK, thanks for asking.  Hopefully a demo will make this more apparent.


>
>
> > I think it's very common these days for
> > websites to use AJAX.  All browsers support it, I believe.
>
>>
>>
>>     The latter would run on any browser but would still be hit by the #1
>> problem
>>     with web payments (and federation), i.e. finding your
>> wallet/bank/IdP/etc.
>>
>>
>> Why is this a problem?  Linked data and follow your nose to the rescue!
>>
>
> Well, I'm just talking about this smallish issue which is providing the
> initial link, something none of giants in the industry have manged come
> up with a solution to.  Microsoft once tried but that's about the only
> serious attempt I have heard about.
>

The initial link can be clicked on.  Or put in the query string.  Or in
local storage.  Or in indexed db.  Or found in a certificate.  Or typed
into a form.  Hopefully the credentials API will give another solution.  I
think we have enough options to work tho.


>
> VISA/MasterCard also "solved" this issue in 3D Secure.  However, this
> solution is
> extremely cumbersome and have fortunately been rejected by most
> e-merchants.
>
> I guess that the FIDO folks have upgraded their spec to deal with links; if
> not, they won't make much of a dent in the payment space.
>
>
>
>>     AFAICT, the Web Payment IG haven't yet addressed this topic either...
>>
>>
>> Unsure the IG has interest in this topic, it's meant for the CG.
>> Hopefully I can write up an RFC if I get time, but at the moment I'm trying
>> to create a workflow and working demo.
>>
>>
>>     Or are you rather betting on WebID-TLS here?  Ok, then it might work
>> "as is"
>>     but that's a solution WPIG will not consider.
>>
>>
>> Yes, currently my implementation is going to use WebID-TLS which I
>> actually like a lot.
>>
> > What the IG considers, is not my problem, my goal is to create running
> code and use it,
> > and to leverage the expertise here to make it standards quality.
>
> That's not feasible using the approaches mentioned.
>

Not sure I follow this.

>
>
>
>  Im not trying to win a popularity contest, just show what technology can
>> do ... :)
>>
>
> That's doable.


Agree!


>
>
> Anders
>
>
>
>>
>>
>>     Anders
>>
>>
>>         [1] https://linkeddata.github.io/SoLiD/
>>
>>
>>
>>
>