LSAT for subscription payments?

[eddiepease]

Hello - I had an idea for building a service which uses LSATs to provide lightning subscription payments (something like paying a service 100 sats per month until cancelled, for example) which would work something like this:

User acquires an initial LSAT with a small payment of sats. The user could then delegate authority for sending the payment (with details like the amount per month, perhaps the time in the month etc) to this service whilst the user would retain complete control of cancelling or changing the terms of the subscription.

What I'm not sure is whether the above setup is possible using LSATs? Or is there another method which would work better seeing as, to the best of my knowledge, LSATs aren't supported by CLN/eclair?

[guggero]

LSATs should work well for subscriptions in general. You pay for the subscription once and get a macaroon that has an expiration date encoded as a caveat. Once the expiration date/time is reached, the macaroon part of the LSAT becomes invalid and the server would instruct the user to pay for a new LSAT.

The part in your use case I'm not sure about is the "delegated authority for sending the payment". How would that fit in with the client/server model? How would the server know what payments to pay for you? Perhaps there's a misunderstanding of how LSATs work. The macaroon part of LSATs is the same technology as lnd uses for its authentication mechanism. But the macaroons themselves are completely independent from lnd's macaroons. See https://lsat.tech/introduction#example-applications-and-use-cases.

LSATs aren't supported by CLN/eclair

They can very easily be supported by CLN/eclair. All you need to be able to do as a client is to pay for an invoice. Again, this is completely independent from the authentication mechanism in lnd. With LSATs you don't give someone access to your lnd node. You pay an invoice to use a HTTP API that serves paid responses.

[eddiepease]

Thanks very much for the detailed reply - in terms of the 'delegated authority for sending the payment', I was thinking of something akin to a direct debit in the fiat system. I understand that using LSATs as you describe, you can pay for subscription for a year, say, and then access is revoked upon expiration. However, you might not want to pay the whole amount up front and pay for the service/API every month without having the hassle of manually approving each new payment every month. So was thinking you could enter into an agreement (which either party could revoke at any time) that says something like 'here is permission to transfer [x] sats on 1st of every month for access to [x] service'. Understand that most people prefer to pay per use at the moment on Lightning but thought this could be useful for the future.

I thought that LSATs could be the answer here based the below section in this article but now see that this just corresponds to macaroon permission, rather than payment permission...

Due to the flexibility of the design, a macaroon holder is able to further attenuate a macaroon if they wish to share it with a third party under more restrictive permissions. Following the example above, the macaroon holder can restrict the macaroon’s capabilities to only allow access to Loop In (and not Loop Out) with a monthly volume of 1 BTC by adding the following caveats

Maybe a solution is for the merchant to have software to automatically generate an LSAT valid for one month every month, and the user to have software which approves automatic payment of the invoice if the invoice is valid (conditions to be agreed by user at the start of the subscription)

Quite new to lightning so there might well be an obvious solution to this which I'm missing!

[guggero]

What you are thinking about sounds like a "pull" model, where the an authorized party could pull funds from your node at a certain interval. That is currently not possible in a safe manner, because that would require you to give out the authentication token (macaroon) of your lnd node to a third party.

I think the "push" model where you need to refresh the subscription payment from time to time is probably easier to understand for most users. And the payment could still be automated by browser extensions (or other software) like Alby that can do the payment in the background.

Both models could be made more secure by the "macaroon account model" that I'm currently working on. That allows a user to give out the lnd authentication macaroon to a third party ("pull" model) or a browser extension ("push" model) and limit it to only be able to spend a certain balance (defined by the virtual account balance).

[eddiepease]

Thank you, very helpful!