Add TTL support to relation tuple

[robinbraemer]

Is your feature request related to a problem? Please describe.

Allow automatic expiring for ACL tuples. It's a great feature to e.g. allow temporal access to something.

• grant a user a time limited role / object / ...

After TTL timestamp expiration the tuple has no longer effects and gets garbage collected.

[zepatrik]

I'm wondering if that is something you would be better off by using the ABAC functionality. It could also use the system time as an input.

[robinbraemer]

I think it can only be integrated to be scalable. Imagine a more deep expand check that may involve more complex tuples herarchies.

If we have said, that ABAC is too much to implement into Keto and one should use e.g. OPA on client side: How would you have ACL tuples to expire in a big system? Keto would only use living tuples. I think passing an optional TTL on tuple insertion would be very simple for users.

Perhaps TTL would be the only attribute we should support for tuples? 🤔

Otherwise we would need to allow attributes on tuples and allow users to define policy and append context to check/read requests to filter out tuples that not pass at request time (which comes with scalability issues, instead of efficiently query the db just tuples that have sufficient TTL at request time.)

[zepatrik]

If we start adding single features like TTL into the core, we will eventually add more and some day end up with OPA (exaggerated).
The top priority is low latency and we can only reach that if the language is simple enough. In general, tuple cleanup has to be done by the client application anyway, and for most of the tuples it makes no sense to make them expire. This is really just a single feature used by some applications, and not critically required by everyone.

In general we have the following sources of relation tuples:

1. database
2. subject set rewrites

We can simply add a third one that enables ABAC and all kinds of integration, just by allowing the client to attach tuples to a single request that are only valid and considered for that single request.

So in essence TTL could then be implemented similar to:

object#access@(<timestamp>#system-time-before) <-- stored in the database when enabling "allow access until <timestamp>"
<timestamp>#system-time-before@user-id <-- added dynamically by the client if the system time is before the <timestamp>

This changes 0% of the core language but still allows all kinds of fancy rules, ensuring that we can keep the latency low.
For me the most important goal is to stick to this simple language.

[emayssat]

Another approach is to keep the language as simple as possible and have an external service that deleted the ACL at a given time. In other words, the timestamp is not in the ACL. You could for example have scenarios such as: this access on this object is only possible every weekday between 9am and 5pm PST.

[g13013]

@zepatrik

The top priority is low latency and we can only reach that if the language is simple enough. In general, tuple cleanup has to be done by the client application anyway, and for most of the tuples it makes no sense to make them expire. This is really just a single feature used by some applications, and not critically required by everyone.

In a microservices approach and especially when using OAuth to simply grant application to act on behalf of a user this scenario is very common

It's critical that Keto manages the TTL, as it would be the single source of truth for permissions. also, it would make applications save a state of permissions to check against which makes the need to keto not relevant.

[istarkov]

Just curious can it be done now using https://www.ory.sh/docs/keto/reference/ory-permission-language ?

[ryukinix]

That would be really appreciated. It would be useful at @NeowayLabs Feature Store Ecossystem

[github-actions]

Hello contributors!

I am marking this issue as stale as it has not received any engagement from the community or maintainers for a year. That does not imply that the issue has no merit! If you feel strongly about this issue

• open a PR referencing and resolving the issue;
• leave a comment on it and discuss ideas on how you could contribute towards resolving it;
• leave a comment and describe in detail why this issue is critical for your use case;
• open a new issue with updated details and a plan for resolving the issue.

Throughout its lifetime, Ory has received over 10.000 issues and PRs. To sustain that growth, we need to prioritize and focus on issues that are important to the community. A good indication of importance, and thus priority, is activity on a topic.

Unfortunately, burnout has become a topic of concern amongst open-source projects.

It can lead to severe personal and health issues as well as opening catastrophic attack vectors.

The motivation for this automation is to help prioritize issues in the backlog and not ignore, reject, or belittle anyone.

If this issue was marked as stale erroneously you can exempt it by adding the backlog label, assigning someone, or setting a milestone for it.

Thank you for your understanding and to anyone who participated in the conversation! And as written above, please do participate in the conversation if this topic is important to you!

Thank you 🙏✌️