You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
The text was updated successfully, but these errors were encountered:
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.
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.
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 totime.Now()
. As best I can tell, this isn't really persisted anywhere "permanent" on the lsat itself. Then there is this code that sets anIsValid
method on theToken
. It's only a placeholder now that always returns true. It's not clear to me how theTimeCreated
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?
The text was updated successfully, but these errors were encountered: