Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
bucko13 opened this issue Sep 21, 2022 · 2 comments
Open

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

bucko13 opened this issue Sep 21, 2022 · 2 comments

Comments

@bucko13
Copy link
Contributor

bucko13 commented Sep 21, 2022

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
Copy link
Member

guggero commented Sep 21, 2022

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
Copy link
Contributor Author

bucko13 commented Sep 22, 2022

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants