Paying when payment is required

[michielbdejong]

Split out from #4.
When a 402 Payment Required response is received, how does the user(-agent) pay before trying again?

[michielbdejong]

This part is still tricky, I'm still brainstorming about this.

Now I just need to figure out a way to establish the payParams.

It would be easier here to use a payment pointer, but we want to create a specific invoice for this specific user making this specific http request (at this specific time). But what we have is the payment pointer of the pod owner.

So given:

• a unique identifier for this request (user webid, request URL, request method, maybe request headers, maybe request body)
• the payment pointer of the pod owner
• presumably, some way to set a price
• optionally, some expiry date

How do you create an ILP/STREAM invoice?

I'm going to use the word 'ticket' to mean the abstract thing the user buys by paying. It may be slightly confusing because the user doesn't present the ticket (so "guest list entry" would be a better word than "ticket" in that sense) but since that part of the flow doesn't affect the earlier parts of the flow, and "ticket" is an easier concept, I'll still stick to it for now.

What should be the realm to which the ticket gives access? The request that returned a 402 response already happened, so you can no longer get access there. But suppose the exact same 402 is repeated at a later point in time. Then obviously it should succeed. What if the method or one of the headers is different? How do you slice up the space of possible slightly-different http requests a user could try to do after paying? It seems reasonable to go back to the ACL document for that. We can say one ticket gives access to everything the specific acl:Authorization gives access to.

For simplicity, we don't support expiry, so once you have access to a given acl:Authorization, you will always have access until the server is taken offline, or until the ACL doc is changed and an acl:Authorization with that URI no longer exists. If we want to add expiry dates then I think that can go into the ACL doc as an additional triple on the authorization.

Also for simplicity, let's say the price is always "any non-zero amount" (pay what you like, as long as it's not zero). If we want to add price then I think that can go into the ACL doc as an additional triple on the authorization.

[michielbdejong]

See also the issue about this at the monetization-tests.
See also the issue about this at node-solid-server.

[michielbdejong]

So then "ticket space" has two dimensions for now: the URI of the acl:Authorization and the webid of the agent.

[michielbdejong]

For now, mainly due to sync vs async considerations and not wanting to change the code paths in NSS acl check code too much, I went with tickets per agent & resource URL, see https://github.com/solid/monetization-tests/blob/3cf0d87/test/surface/payment-required.test.ts#L117