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

ACL Expiry #10

Open
ghanemabdo opened this issue Apr 17, 2016 · 6 comments
Open

ACL Expiry #10

ghanemabdo opened this issue Apr 17, 2016 · 6 comments
Assignees

Comments

@ghanemabdo
Copy link

Adding a new triple to an authorization with predicate acl:validTill is probably a needed use case. It says an authorization rule is valid till a particular time. The ACL resource should be cleaned removing expired aurthorizations.

@nicola
Copy link

nicola commented Apr 17, 2016

i would let the apps clean the acl (so acl can be more transparent and policies would be easy to renew)

@timbl
Copy link

timbl commented Apr 18, 2016

Note that RDF is monotonic, so if a graph is true, deleting statements leaves it true. Having an optional constraint like acl:validTill 2016-06-30 doesn't work like this. Ways to get around it are many -- have a separate class TimedAuthenticaion for example where the validTill is required. This also means old systems will fail safe.

@dmitrizagidulin
Copy link
Member

@timbl Can you explain a bit more, about monotonic? What do you mean about deleting statements? Does that mean our PATCH verb is useless?

@ghanemabdo
Copy link
Author

@nicola I agree the cleaning process shouldn't be part of the specs, but I believe the server is more in charge of cleaning. It can happen with every write to the resource or it can rely on server implementation. Poor applications shouldn't cause a lot of dummy triples on the pod.

@timbl does this mean in an authorization rule containing acl:validTill, removal of acl:validTill triple should leave the rest of the triples in the same authorization valid which is not the case here. Removal of acl:validTill triple invalidates the whole authorization rule. I hope I got it right.

In this case, why don't we consider Authorization is actually a TimedAuthorization which has acl:validTill mandatory and for unlimited authorizations, the object could be blank or a very far time in the future? does this make sense?

@ghanemabdo
Copy link
Author

ghanemabdo commented Apr 19, 2016

@dmitrizagidulin do you think @timbl 's point also applies for acl:defaultForNew as it is also optional?

@dmitrizagidulin
Copy link
Member

@ghanemabdo not sure.. I need to understand this subject better; I'll see if I can ask him about it today.

@nicola - don't forget that many (most?) apps won't have read/write access to the .acl resource, and so won't be able to perform cleaning.

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

5 participants