Consider the advantages of wACLs being readable by apps

[bblfish]

In order for an App to be able to decide what form of credential it needs to present in order to authenticate to a resource it needs to be able to read the wACL rules. Currently a user may have a number of WebIDs or OpenIds to authenticate with. In the future this may extend to any number of Verifiable Credentials as developed by the Verifiable Claims WG at W3C. Choosing which credential to present is only possible in a distributed environment if the client can see which claims would succeed.

The client may want to know

• if any of the identifiers it has is listed as member of a group
• if any of the credentials it has, allow it to prove that it fits the description a class of users that are allowed access
• or it may want to do something to become a member of the group that has access - such as signing up to a group (which may be on a different server)
• if it just is not worth bothering to access the resource

Otherwise the only strategy is that the client try out each of its Credentials randomly, thereby giving away all information it has and potentially linking all those credentials together.

For those concerned about leakage of information of wACLs:

• There are many cases where publicity of ACLs is not a problem:
  • Stores will quite readily and publicly say that certain items can only be purchased on proof of belonging to a certain age group.
  • Airlines, credit cards, ans others like to provide gold, titanium and other memberships and are happy to advertise the advantages as loudly as possible to all that they think may be moved to subscribe to the offer
  • Cinemas make clear that one can only enter after payment, a feature that would be very useful for a Hyper Music Browser
• There are cases where ACLs may be sensitive, in which case they can further be protected by another ACL. The first ACL would for example only be visible according to the second for anyone able to prove they are a US citizen. Proving one's US citizenship would allow a US citizen to see that the resource is protected only for people able to prove they have a certain rank in the army. One can imagine more complex schemes.
• It is possible to continue not show anything as now, but that makes it difficult to provide a fluid experience for the user.

[TallTed]

quibble -- the WG's name notwithstanding, "Verifiable Claims" (and "claims") should be changed to "Verifiable Credentials" (and "credentials") in most cases.

[bblfish]

Thanks @TallTed for the clarification. I made the changes and added some extra examples.

[jaxoncreed]

I would be fine with allowing access to .acls as long as you are able to set who has access to them.

[elf-pavlik]

I would be fine with allowing access to .acls as long as you are able to set who has access to them.

:+1: I think we could just add option to set explicit rule for the acl resource itself ('inside' of that acl) and keep current 'controller only' access as default behavior. Which would mean that applications should gracefully handle cases where they can't access ACL (eg. prompt user to select credential if they don't have existing active user session) and if they detect public ACL can use progressive enhancement strategy to offer some kind of dynamic credential detection. Applications which require explicit 'log in' up front and establish single active user session this way, should not be affected in any way by this added functionality and can choose to safely ignore it.

[bblfish]

I would be fine with allowing access to .acls as long as you are able to set who has access to them.

Ok so if wACLs can themselves have Link: rel=acl ... headers, then one needs to think this through.

For the client this is quite easy. On receiving an wACL document it will receive a header showing if it too has an acl, so that it can work out if it is allowed to edit it.

For the Guard the reasoning should be the same as for the client.

The open question is how someone with the correct rights would set the acl of an acl. This is a similar question as to how one sets headers for resources, and who is allowed to do so.

If we have wACL docs pointing to acls, is it that the current situation is that we implicitly have all wACLs pointing to themselves?

Answering these problems looks like a simple research project to me.

[elf-pavlik]

The open question is how someone with the correct rights would set the acl of an acl. This is a similar question as to how one sets headers for resources, and who is allowed to do so.

I think acl document should contain rules to access itself. For consistency we might still require for them to have rel="acl" which MUST point to itself. In that case we don't have need for clients to manipulate relations exposed in HTTP Link header, we might still need to address it for some other requirement.

We could create PR proposing it after https://github.com/solid/data-interoperability-panel/pull/32/ gets merged. @justinwb how do you see discussion here turning into followup PR to your original metadata PR?

[justinwb]

@elf-pavlik @bblfish Apologies i didn't catch this notification the first time around! I'm combing through the resource metadata pull request to make sure i haven't missed anything and just came across this.

I think @bblfish makes a good argument for cases where it might be beneficial to see an .acl without proof of control access first. Still, I do not think it would be appropriate to change the default behavior or expectation of the same from what it is today.

I think @elf-pavlik's proposal would be the right way to go about it, because that's something we could add that would be backwards compatible and not change assumed default behavior. That said, I think it would need to accompany verifiable credential support - otherwise it would seem like we're making a change without a use case to justify it.

[ericprud]

I think the acl should control itself as @elf-pavlik describes and that there should be an ACL control between stealth and detectable. Unauthorized access to the resources would yield:

mode	resource	acl
detectable	401	200
stealth	404	404

As architects, we've been unable to decide between stealth and detectable because there is no single answer. Users may want finer-grained control than that but I think this covers most use cases.

[csarven]

If the rough rough rough consensus here is that an ACL need not have its ACL, then the proposal at https://github.com/solid/specification/issues/184 would prevent servers from advertising a link relation.

[bblfish]

@justinwb wrote

I think @bblfish makes a good argument for cases where it might be beneficial to see an .acl without proof of control access first. Still, I do not think it would be appropriate to change the default behavior or expectation of the same from what it is today.

What is the expectation meant to be for a client? Is it that it won't be able to read the wACLs that is linked to in the header unless it already knows what the acl contains because it (or the user who owns the app) wrote it?

Apart from this being a very odd expecation to have, it creates the following problems:

1. It goes against the fundamental principle #73 on client server symmetry
2. as a result it pushes the problem elsewhere: for example requiring complex protocols to be developed to allow a client to work out if it has access rights to a resource (how can it do that without just guessing?)

[bblfish]

I think the problem is the following. If wACL documents have their own acl link relation how do you not end up with an infinite regress? Also how does this work with the current installed base?

The answer is quite simple and is what I implemented in rww-play.

A wACL document can have a link relation to itself by placing a Link: <>, rel="acl", indicating that it is the source of truth for itself.

One can see this to be the current behavior implicitly. It just happens that the current solid apps don't publish that link.

[elf-pavlik]

ACP Proposal allows for setting access on Access Control Resource itself.