Precise definition of acl:default about web-access-control-spec HOT 16 CLOSED

@acoburn I believe it would use /docs/.acl in your case because this is the first acl file with acl:default specified, hence providing the first permissions which can be inherited.

From the ACL Inheritance Algorithm:

4. Failing that, move up the container hierarchy until you find a container with an existing ACL file, which has some permissions to inherit

from web-access-control-spec.

@Otto-AA yes, that is also my understanding (and that is how I have implemented the WAC algorithm myself), but it is worth noting that the definition in the algorithm conflicts in this regard with what is stated in the ACL namespace:

If a resource has no ACL file (it is 404), then access to the resource if given by the ACL of the immediately containing directory, or failing that (404) the ACL of the recursively next containing directory which has an ACL file. Within that ACL file, any Authentication which has that directory as its acl:default applies to the resource. (The highest directory must have an ACL file.)

That is, when looking up the containment hierarchy, does one stop at the first "container with an existing ACL file [with] permissions to inherit" (as per the algorithm described here) or at the first container resource "which has an ACL file" (as per the vocabulary).

from web-access-control-spec.

My reason for creating #70 is that it's how the current servers work in practice, so the 0.8 spec should be corrected to describe that.

This is not correct. There are implementations in the wild right now that follow the algorithm as described in the specification text. It does not follow that the specification text should be changed because one particular implementation does not follow those rules. (And I think it should be verified that, in fact, NSS does not conform, because these lines suggest that it does).

from web-access-control-spec.

No, that's not how acl:default works. There are two situations when looking for the applicable ACL doc: the resource has its own ACL doc (a Link response header points to a resource that exists), or it defaults to its nearest parent (the resource's Link response header leads to a 404).

In the first case, look for acl:accessTo, in the second case, look for acl:default instead.

acl:defaultForNew is treated as a deprecated synonym for acl:default.

from web-access-control-spec.

Thanks for coming back to this question. I think I am understanding what you are saying, but I'm not sure how it answers my question.

I'll try to explain my question with a simple example. Here is the example for acl:default from the wac-spec. Only the last line is changed:

# Contents of https://alice.databox.me/docs/.acl
@prefix  acl:  <http://www.w3.org/ns/auth/acl#>.

<#authorization1>
    a                  acl:Authorization;

    # These statements specify access rules for the /docs/ container itself:
    acl:agent          <https://alice.databox.me/profile/card#me>;
    acl:accessTo       <https://alice.databox.me/docs/>;
    acl:mode           acl:Read, 
                       acl:Write, 
                       acl:Control;

    # default says: this authorization (the statements above) 
    #   will also be inherited by any resource within that container 
    #   that doesn't have its own ACL.
    acl:default  <https://alice.databox.me/docs/first.ttl>.

I've changed the value of acl:default from ".../docs" to ".../docs/first.ttl". Does this change the behavior of it? Or is this value redundant?

from web-access-control-spec.

@Otto-AA asks an excellent question here. I have had that same question, myself.

I also have another question that touches on acl:default, building on the example above:

Assume there exist the following four resources:

• https://alice.databox.me/docs/
• https://alice.databox.me/docs/photos/
• https://alice.databox.me/docs/photos/spain/
• https://alice.databox.me/docs/photos/spain/1.jpg

The /docs/.acl ACL is similar to what is above except that acl:default points to https://alice.databox.me/docs/

There is also a /docs/photos/.acl resource without an acl:default value and which only grants acl:Read access:

# Contents of https://alice.databox.me/docs/photos/.acl
@prefix  acl:  <http://www.w3.org/ns/auth/acl#>.

<#authorization1>
    a                  acl:Authorization;
    acl:agent          <https://alice.databox.me/profile/card#me>;
    acl:accessTo       <https://alice.databox.me/docs/photos/>;
    acl:mode           acl:Read .

There is no ACL resource for https://alice.databox.me/docs/photos/spain/ or for https://alice.databox.me/docs/photos/spain/1.jpg.

If the user https://alice.databox.me/profile/card#me wishes to DELETE /docs/photos/spain/1.jpg, will that be allowed? (via inheriting from the ACL at /docs/.acl) or will that be rejected (via inheriting from the ACL at /docs/photos/.acl)?

from web-access-control-spec.

@Otto-AA

I've changed the value of acl:default from ".../docs" to ".../docs/first.ttl". Does this change the behavior of it? Or is this value redundant?

Here you're mixing up the target URL of the request and the context URL of the ACL doc.
Remember we're consulting https://alice.databox.me/docs/.acl to learn ACL rules about https://alice.databox.me/docs/ and so any rule that's not about https://alice.databox.me/docs/ will be ignored.

So you should always keep track of three resources, and not confuse them:

• targetUrl, the resource being accessed (in this case https://alice.databox.me/docs/first.ttl)
• contextUrl, the closest parent resource for which an ACL doc exists (in this case https://alice.databox.me/docs/)
• aclDocUrl, that ACL doc (in this case https://alice.databox.me/docs/.acl)

All acl:default and acl:accessTo triples should have an authorization (aclDocUrl + #something) as their subject and the contextUrl as their object.

@acoburn

If the user https://alice.databox.me/profile/card#me wishes to DELETE /docs/photos/spain/1.jpg, will that be allowed? (via inheriting from the ACL at /docs/.acl) or will that be rejected (via inheriting from the ACL at /docs/photos/.acl)?

that will be rejected. Only one ACL doc, the closest one up the tree, is looked at - in this case /docs/photos/.acl and not /docs/.acl

from web-access-control-spec.

If the user https://alice.databox.me/profile/card#me wishes to DELETE /docs/photos/spain/1.jpg, will that be allowed? (via inheriting from the ACL at /docs/.acl) or will that be rejected (via inheriting from the ACL at /docs/photos/.acl)?

that will be rejected. Only one ACL doc, the closest one up the tree, is looked at - in this case /docs/photos/.acl and not /docs/.acl

In that case, what is the use of acl:default?

from web-access-control-spec.

@michielbdejong in the ACL Inheritance Algorithm Example, it appears clear that acl:Authorization statements are inherited only if they contain acl:default. See, in particular, step 2 and 3.

from web-access-control-spec.

I think acl:accessTo / acl:default is a misnomer and better names would have been
acl:accessToResourceItself / acl:accessToDescendantResources.

That's how you interpret the ACL doc once you've found it. The word inheritance is confusing there, and so is the word default.

And then to find the ACL doc that applies, you just walk up the tree and stop when you find one. So there inheritance is also confusing, because in biology you inherit things from all your ancestors up to the root, and in WAC you don't.

EDIT: Sorry, I wrote acl:accessToDirectlyContainedResources but that should be acl:accessToDescendantResources, so directly contained + sub-container contained, etc.

from web-access-control-spec.

I agree with @acoburn that the current form of the WAC-spec clearly states, that it looks for the next parent with an acl:default expression. I personally don't see how I could interpret it the way you do, @michielbdejong .

From the example in the spec:

3. If the document's container has no ACL resource of its own, the search continues upstream, in the parent container. The server would check if /documents/.acl exists, and then /.acl, until it finds some authorizations that contain acl:default.

from web-access-control-spec.

@michielbdejong

All acl:default and acl:accessTo triples should have an authorization (aclDocUrl + #something) as their subject and the contextUrl as their object.

Is this specified somewhere? As far as I've seen, the specification doesn't mention what the object of acl:default should be.

from web-access-control-spec.

@Otto-AA you're right, the only phrase that describes not looking at the presence of acl:default statements is "If the document's container has no ACL resource of its own, the search continues upstream". My reason for creating #70 is that it's how the current servers work in practice, so the 0.8 spec should be corrected to describe that. We can then have a discussion in solid/specification#55 about whether the current Solid server deployments should switch to the different behaviour that is described in the current spec text, or maybe even to yet other behaviour.

from web-access-control-spec.

All the code I have ever written follows the spec.
Does the value of acl:default matter? Yes.

Is "default" too short when it should be something lke "defaultForThingsWhich DoNotHaveACloserACLFileAndAreBelowThis" ? maybe a bit .. Make contentsDefault or something... but it is definitely a default, as it provides a fallback ACL for anything until that thing has something of its own or something closer.

from web-access-control-spec.

While @timbl's answer settles the question of whether it matters, I'd still like to see a precise definition of how it matters. It seemed meaningful to repurpose this issue in that sense.

Specifically, I'd like a definition of the set of resources affected by the default.

Also, @acoburn's question was specifically about the value (triple object) of the triple. How does it affect behavior? What kind of values are allowed in a given folder? Should they always be subfolders of the current folder? Etc.

from web-access-control-spec.

Ah wait, this is just a duplicate of solid/specification#55 then. Let's continue over there.

from web-access-control-spec.