ACLs on ACLs for WAC

[bblfish]

Overview

Here is a proposal that extends WAC without changing its default behavior as deployed, which currently is that only users with acl:Control mode rights can view and edit the ACL document. It is also compatible with ACP and could be used there too.

This proposal allows organizations with the need to make ACLs more widely readable, to make those available as they wish -- at their own risk. This feature is needed for the Minimal Credential Disclosure use case, and for a use case on the principle of least privilege which is not yet part of the UCR document. (hoping @justinwb will add such a use case)

In this description I build on the wac:authorizes relation discussed in issue 184: Limitations: re-using policies , but that is not a requirement for this proposal. (If you don't like that proposal just remove the authorizes relations from the diagram and turn the dotted lines into solid ones.)

Description

I illustrate this with the following diagram of a public organization (the W3C) that must show transparency in its workings. Note, that in the first comment below I show how this can work with more complicated cases where parts of the contents of the Access Control statements are protected.

@timbl has a public foaf card with a link to the its acl resource in the HTTP Link: <card.acl>; rel="acl" header. This card.acl document states that anyone can view the card resource and that Tim Berners-Lee also has write privileges to, via his WebID Profile card. On existing deployed systems the <card.acl> would not be readable by anyone, apart from Tim.

To help read the diagram here is the content of card.acl:

<#> wac:authorizes <personal#A1>;
    wac:authorizes  [ acl:agentClass foaf:Agent;
                      acl:mode acl:Read ].

it links to the <personal#A1> authorization which gives access to Tim in read and write mode.

<#A1> acl:mode acl:Read, acl:Write,
      acl:agent <card#i> .

In both those cases as developed in issue 184 the client and server can deduce the acl:accessTo relation from the existence of the accessControl Link header followed by the wac:authorizes relation. That is an idea taken from ACP which adds a lot of flexibility to the system, but is not central to the argument here.

The Proposal here is that if the ACL document X itself has a HTTP Link header relation of type acl (or acl:accessControl) to Y, then the Y ACL sets the access control rules on X. So here the card.acl is readable by any authenticated agent because it has an accessControl Link header (show in double lines) to the </People/Default.acl> resource which says (after authorizes reasoning is applied) that all Authenticated Agents can read the card. This is a very lax restriction - any type of authentication is allowed here - which is used here for illustration purposes to show that one can have different access control restrictions.

[] acl:agentClass acl:AuthenticatedAgent;
   acl:mode acl:Read;
   acl:accessTo </BernersLee/card.acl> .

And indeed because the W3C wishes to be fully transparent, that resource also has an acl to itself, making itself readable by anyone who is authenticated too.

This extension should be completely compatible with the current WAC spec, in so far as it does not change the behavior of existing systems. But as it allows ACLs to be restricted in the same way other documents can be - using exactly the same ontology - we can be more flexible. It may affect how test systems are written though (cc @michielbdejong ).

I proposed something very similar for ACP in use 151 for which it work the same way too. This means that people really worried about readability of ACLs (as per Allow ACL doc discovery without acl:Control) can be as secure-by-default as is reasonable, but others that want to be more transparent can be so too.

[bblfish]

Let us look at a more complicated case next. We want to make information publicly visible on who can access a resource without revealing who has access, so that those who can access know what type of Credential they need to present to gain access.

We have two protected resources:

• <event> which contains the event information, where and when it is happening, what will be happening, what dress code to have, etc...
• <invitees> contains a group <#G> of members.

RFC 7235 requires a server to return a 401 to a client that has not presented a credential (or the provided credential was refused).
WAC enriches this 401 response with a Link: <event.acl>; rel="acl" header. But that linked-to resource can currently only be read by those who have acl:Control rights it, ie those who can edit it (but see PR 250).

This presents a problem in the case where Alice is a member of <invitees#G> and knows it, but is not an organizer of the party, so cannot see the linked-to acl and does not know that the <event> is in any way connected to that group. If her user agent reached <event> by following a link from somewhere else on the World Wide Web, it would not know what credential, if any, to show in order to see the contents.

This example would be clearer if both documents had UUID generated names such as <15263626-8352-11eb-8dcd-0242ac130003> or if the group were on a different server. But for the sake of making it easier to follow the exposition, I'll stick to easy to understand names here. Here is the view she would have:

What the ACLs on ACLs proposal enables is for both <event> and <invitees> to be protected resource visible only to members of the group <invitees#G>, but for Alice to be able to discover what Credential she needs to present to access them. This is illustrated in the picture below, which makes a lot more visible, without leaking any unnecessary information.

Both the grayed out resources are still only visible to members of <invitees#G>but the ACL for <event> and the acl for <invitees> which a client can discover on a 401 by following the accessControl Link header (shown in doubled blue lines), are public.

To help read the illustration I show the turtle here:

1. <event.acl> is the acl for <event> and contains

<#> :authorizes <invitees.acl#P1> .

The authorization links to a "policy" description #P1 in <invitees.acl>, since it can be re-used.

2. <invitees.acl> is the ACL for <invitees>. It contains

<#> :authorizes <#P1> .
<#P1>  acl:agentClass <invitees#G>;
      :mode :Read  .

This refers to the group of invitees <#G>.
Since the accessControl relation from <invitees> to the acl (shown in double stroke) followed by the :authorizes relation implies

<invitees.acl#P1> :accessTo <invitees> .

we have that <#P1> gives access to the resource <invitees> to the group <#G> in :Read mode. So the group <#G> can only be seen by members of the group.

Similarly because the accessControl Link header relation from <event> to <event.acl#> is followed by the authorizes relation from <event.acl#> to <invitees.acl#P1> the client or server guard can deduce the relation:

<invitees.acl#P1> :accessTo <event> .

As such the event is also only readable to members of the group <#G>.

3. We then have ACLs on both those ACLs pointing to <Default.acl#> which gives read access to anyone to those ACLs.

How would you then know you are a member of the group? You'd need to be invited using Linked Data Notification or something similar.

If you know you are a member of the group, then you will know what identity to use to authenticate, if you are not then you should probably not bother, though you may follow a ldn:inbox link to find a box to ask to be added to the list.