-
Notifications
You must be signed in to change notification settings - Fork 25
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
Clarify: 'acl' rel link is a naming hint, not always points to existing file #8
Comments
From my interpretation "a client can discover the location of its corresponding ACL" indicates that the ACL file actually has to exist if the link value is present. Therefore I would also welcome clarification on that. |
@Otto-AA Yeah, exactly, the spec wording sort of implies that the file exists. |
https://datatracker.ietf.org/doc/html/rfc8288#section-2.1 :
Closing this issue as consensus is deemed to be captured in WAC Editor's Draft: https://solid.github.io/web-access-control-spec/ . https://solid.github.io/web-access-control-spec/#acl-resources details ACL resource discovery and representation, and there is no requirement that an ACL resource needs to have a representation. https://solid.github.io/web-access-control-spec/#effective-acl-resource-algorithm includes the case where an ACL resource may not have a representation. |
Add an explanation to the ACL Resource Discovery section that the
rel="acl"
link will be returned even if no actual individual.acl
file is present. That is, it's a naming hint, and not necessarily a link to an existing ACL resource.The text was updated successfully, but these errors were encountered: