search

lightninglabs / aperture

⚡️L402 (Lightning HTTP 402) Reverse Proxy ⚡️
http://l402.tech/
MIT License
233 stars 58 forks source link

Ability to deal in relative times with aperture created lsats #80

Open bucko13 opened 2 years ago

bucko13 commented 2 years ago

I noticed some breadcrumbs in the existing code that indicate there was the intention to build in some support for this but best I can tell they are mainly just placeholders for now.

token.go just sets a TimeCreated value when parsing from the challenge but that's just set to time.Now(). As best I can tell, this isn't really persisted anywhere "permanent" on the lsat itself. Then there is this code that sets an IsValid method on the Token. It's only a placeholder now that always returns true. It's not clear to me how the TimeCreated value on the token serves any use if it's not encoded directly in the macaroon. I might be missing where this is persisted though.

It seems to me like this would be pretty valuable functionality to have. Without the ability to use aperture as a library, the only way to add caveats via aperture as the author is hardcoded in the config file. As far as I can tell, this makes relative caveat restrictions like an expiration date impossible. The sample config shows how to add an absolute expiration with a valid_until constraint, but I can't see how given the current tooling you could do something like "valid_for=xx_days", which feels much more valuable and flexible to me.

Is there some way to achieve this that I'm missing? If not, what are the chances of getting this support in aperture?

guggero commented 2 years ago

I don't see how a relative valid_for would work. When would that start counting? At the moment you add that caveat? Then you could just as well create an absolute valid_until field, which is basically now+x days. lnd does understand and validate the valid_until field, we just never added support for it in Aperture. But would be quite trivial to add.

bucko13 commented 2 years ago

The problem with valid_until is the way that aperture configs work (again, as far as I'm aware). Since they're static, you'd have to constantly keep updating it to useful. If i set that config to 1 year from now, each new lsat that's issued becomes more and more restrictive.

What I think makes sense is to do something similar to what it looks like lnd does with macaroontimeout where in the config you set the timeout, and then the minter/bakery will add the caveat based on that number of seconds. I actually hacked together a version of this and it seems to work. I'll put a PR up in a bit for reference.