Fundamental Principle: Client-Server symmetry

[bblfish]

I propose the following fundamental principle: Clients authentication agents and Server Guards should reason from the same wACL to establish access.

A Solid Client has to follow links from one domain to another, which could lead anywhere on the web. It has no way other than the published wACLs to know how to authenticate to a given resource. It needs to know prior to authenticating which credentials it needs to show, or which it should acquire.

For this the reasoning from the client should be dual to that of the server from the same information. Where the client constructs a proof that it fulfills the criteria in the wACL, the server is tasked with verifying that the proof satisfies those same criteria.

If the criteria differ then the client would be left with only being able to guess how to authenticate. It also makes it debugging an Authorization server by a generic client impossible, since it would not know what to rule to invoke to understand an authentication failure.

Some example from real life:

• Mr X wants to rent a car. As expressed on the form he needs to present a credit card and a drivers license. If refused he is in the right to ask what was wrong: Was the drivers license or credit card invalid? Or was the credit or legal history problematic? If neither, then he has a claim as to the access control rule being broken.
• (fill in others)

This symmetry between the guard and the client, one who constructs a proof and the other who verifies it, is in logic thematised under dialogical reconstructions of logic. These are mathematical duals: one uses constructive logic, the other co-constructive logic. One is a logic of proof, the other of refutation. Some interesting recent books on the topic

• Immanent Reasoning or Equality in Action
• Meaning in Dialogue: An interactive approach to logic and reasoning.

This last book is very good as it show that this difference is between both constructive and co-construtive logics (Popper's logic of refutation) is a real duality that is precise and visible through Category Theory.

The logical background I put forward is one that should be useful for more advanced authentication scenarios. The importance to us is that it shows that this duality goes very deep.

[elf-pavlik]

Related #58

[csarven]

It has no way other than the published wACLs to know how to authenticate to a given resource.

I'm not sure I understand how an ACL (which are only discoverable and accessible by agents with Control access privilege) or what information in an ACL resource (authorization policy?) helps a client with authentication. Can you clarify?

[elf-pavlik]

which are only discoverable and accessible by agents with Control access privilege

to my understanding @bblfish questions this design choice, see #58

[zenomt]

i disagree with this proposal, because it

• violates the Principle of Least Privilege, and Defense in Depth
• would necessarily disclose private information, like the actual identities of agents allowed to a resource
• wouldn't work in situations where (for example) a vcard group is at a non-publicly-accessible location, such as behind a firewall or on a server with a local IP address (localhost, RFC 1918, unique-local, etc)
• is not aligned with how ordinary users use ordinary applications
• would require only WAC to be used on a resource server

i have no problem with a security domain choosing to publish its access control rules (for example, as an origin-wide policy, or to anyone with access to the protected resource, or by choice of the resource controller by explicit grant in the ACL, or an ACL for the ACL, or ...), but the correct operation of an ordinary client shouldn't depend on access to the access control rules, and the assumption by a client should be that it will not have access to the access control rules for a resource.

[acoburn]

I very much agree with @zenomt in #73 (comment) for all of the reasons listed there.

[bblfish]

Thanks for your input @zenomt. To take your points one by one.

1. can you explain why it violates the Principle of Least Privilege giving your definition of it and of "Defense in depth".

2. To your very strong claim that "it would necessarily disclose private information, like the actual identities of agents allowed to a resource" I can give a very simple counterexample. Imagine a wACL that gives access to a resource to anyone over 18. Making that publicly available would not divulge any information about those being able to access it. I can find whole classes of further counterexamples to it. To name a few more:

   • a wACL that gives access to anyone in possession of a mode of payment
   • a wACL that gives access to members of a group by reference, but only members of the group can see who else is a member of the group.

3. I think you would need to demonstrate why your localhost usecase of non publicly accessible resources is both one that we need to take into account and why this principles excludes it.
   Here is a counterexample. Imagine we use an cert:key to identify a user via access to a public key. The wACL on localhost can have a rule stating that the agent with that cert:key has read access to a resource. This can work without needing internet access since it only requires the client to provide a cryptographic proof using its private key.

4. To your behavioral point that it is not aligned with how ordinary users use ordinary applications I think you'd need to explain on what you base that statement.
   It seems to me that in ordinary daily life restrictions on access to property have to be clearly marked and explained. Stores that sell items that are restricted (eg. liquor) among other openly accessible ones, have to post a sign that is clearly visible to all their customers stating that restriction. Private properties adjacent to public ones need to have a wall or a clearly marked sign stating that trespass is not allowed...

5. Can you explain why you think that this requirements is a restriction to wACLs only?
   Here is a simple counterexample: The Friend of a Friend ontology has an inverse functional property foaf:openid that allows one to describe someone indirectly via their openid. A resource can be protected by a publicly visible wACL that allows members of a group read access. The group description can be protected to be readable to only members of that group. And there is no reason why some people could not be identified there via their OpenId. A member of that group seeing she is identified there by her OpenID, could start an OpenId authentication process if she wishes to have access.

[zenomt]

@bblfish

1. this is what i mean by "Principle of Least Privilege" and this is what i mean by "Defense in Depth" (for computing). "how to access a restricted resource" is Generally Recognized as Privileged in computer security.
2. today's Solid access control model is entirely based on identity (specifically webid), not on verifiable attributes, claims, or non-webid credentials. the examples you give (such as "anyone over 18" or "someone who controls an anonymous public key" (paraphrased)) seem to imply an entirely different authentication, access control, and authorization system. with today's identity-based access control, where the variable is "which identity", and today's model for describing the identities allowed, the only way to allow the client to determine what identity to present is to provide an enumeration of allowed identities or vcard groups (with enumerable memberships). in addition to not being acceptable from a privacy perspective, this also does not scale.
3. the "localhost" or private/non-publicly-accessible back-end service is how modern, scalable, 12 factor services are usually built.
4. ordinary users log in to ordinary web applications with one identity. it's very unusual to log in to the same instance of an app (especially with an OIDC flow) with more than one identity. it's also very unusual for an OIDC Provider to support being simultaneously logged in with more than one identity at that provider in the same cookie-based session, so even if you had a web app that let you log in with different identities, each identity would probably need to be hosted at a different OIDC Provider. the user makes her choice as to what identity to use with a particular app that then accesses resources as her; she does not usually allow the app to determine which of her many identities to use for different resources.
5. the general point is that the client will need to understand the access control language, abstraction model, and semantics used by resource servers in order to decide what identities (or whatever) to present/prove to each one. to be practical, this would need to be standardized.

specifically to point 2, perhaps with a more fleshed-out (that is, less hypothetical and implied) access control and authorization system and user interaction stories, a stronger case could be made for the minimal set of access control information that would need to be made public (or less private) to facilitate the proposed system without compromising security and privacy principles.

[bblfish]

@zenomt wrote:

today's Solid access control model is entirely based on identity (specifically webid), not on verifiable attributes, claims, or non-webid credentials. the examples you give (such as "anyone over 18" or "someone who controls an anonymous public key" (paraphrased)) seem to imply an entirely different authentication, access control, and authorization system.

This is a fundamental misunderstanding about web Access Control. It is very helpful that you expressed it as it would otherwise be laying around in the background of unsaid things distorting all communication. So thanks for having the courage to voice it.

The limitations of wACL to identifiers and simple groups were put in place in the early days only to help the project gain adoption among hackers with limited resources and researchers to allow us to experiment with the fundamental concepts. This was also way before the existence of Verifiable Claims. The use cases that was the most fun to play with in such small communities was simple peer to peer social networks. But the option of using OpenId authentication in addition to WebID was one that was considered. (I showed 4 years ago how to combine HTTP-Signature with WebID a few years ago for example, and the current solid implementations allow OpenID authentication). The web being an open space, there cannot be One unique protocol for identifying users and so Solid wACLs are open to all: Verifiable claims, OIDC, eIDs, WebIds, ... Indeed here is a picture @timbl drew in Lyon around 2012 at a WebID Workshop, showing how we were thinking of getting all these to work together.

The Solid project started over 10 years ago (before it was named), and we are no longer in this early experimental phase where we limited outselves to a few identifiers. Also we now want to look forward to the future and make sure the system continues to remain well architected for all the important use cases Inrupt is encountering and those to come.

If you now look carefully at wACL you will see that it is just a Linked Data implementation of an Access Control System. I.e. an implementation for the World Wide Web. Given the tools we have available through 20 years of research worldwide through the W3C this goes much beyond usual operating systems acls. But fundamentally these all rest on a simple read/write access to users and groups which I believe have a mathematical basis. There is nothing there that stops us from adding groups determined by attribute (people over age 18, ...). Neither is there anything stopping us from adding friend of a friend type access control rules, or giving access to a resource on payment. We need to think of how we architect the system with all of these in mind.

So my counterexamples to all your points (2,3,5) still hold. In point 1 you linked to a few definitions, but you did not give the reasons. And in point 3 your argument is that this is not how it works in OIDC. But we are not here working to the same model as OIDC, and our use cases are very different. We are building a system where each person or company will have their own pod, sharing some resources with some people and others with others. Given the open nature of the web this will also mean different identifiers and protocols will have to be accommodated.

This means that we need creative people to come up with new answers to problems within the constraints of Solid. There is a lot of work to do and potential for creativity. Let not the past hold you back.

[acoburn]

This means that we need creative people to come up with new answers to problems within the constraints of Solid. There is a lot of work to do and potential for creativity. Let not the past hold you back.

I am all for coming up with new answers to these problems, but I would argue that the initial statement articulated in this issue is flawed. Namely:

I propose the following fundamental principle: Client authentication agents and Server Guards should reason from the same wACL to establish access.

The problem with that principle is that it assumes that the trust relationship between Client and Server is symmetrical. For all of the reasons outlined above, that is not a reasonable assumption to hold. To expose that information to an unauthorized actor is a fundamentally unsafe operation, c.f. CWE-200: Exposure of Sensitive Information to an Unauthorized Actor.

In a decentralized ecosystem, such as what underlies Solid, we cannot assume any symmetry in the trust boundaries between client and server.

[bblfish]

I agree that the wording of the principle can be improved.

@acoburn wrote

The problem with that principle is that it assumes that the trust relationship between Client and Server is symmetrical.

What I wrote down was a first version that emphasizes the symmetry of reasoning on both sides. (not in the trust relationship). The symmetry is the following: the server specifies what credentials give access, the client following that description can present the right credential if it has one (or procure itself one).

This is clear in cases where the server does not need to hide any information about who has access. There are many: open follower lists (a major feature of Twitter for example), access by credential (age, license, payment, etc...).
The above use cases make it clear how a world readable wACL allows clients to choose the right identity or credential, allowing them to disclose the minimal information. It even enables a form an implementation of the principle of least privilege. Say the user of an App only wants it to read resources, then she could choose the credential that gives the App only read access.
The ability of the client to select the right credential also helps avoid information leakage of client credentials, which is good for privacy.

All those examples are counterexamples to your claim @acoburn that

To expose that information to an unauthorized actor is a fundamentally unsafe operation.

In many very important and widely deployed use cases they are fundamentally safe and needed. Not perhaps in some paranoid high security use cases, but I believe we can get to those without compromising on the principle. Let's look at the first step towards that next:

As I mentioned it is possible to have the symmetry I am trying to get at whilst also allowing the server to hide information. Say resource /42/MoL can only be viewed by group </A23cF#>. That resource can be protected so as to be viewable to only members of that group. A client that sees that access to the /42/MoL resource is only allowed to members of </A23cF#>, will either know that it is a member or not. If it does not know, then it knows that it does not know how to access. If it does know that it is a member of the group, then the client will know how to access the resource.

So here we have an example of how one can have the required symmetry in reasoning, whilst keeping some information hidden. Indeed we can have symmetry in the game played to gain access and asymmetry of knowledge between the players.

Now there may be a better word than symmetry. Duality perhaps? I'll look to see if there is a specific word for this concept I am trying to get at.

[bblfish]

Perhaps we can think of the symmetry as follows.

If a user of an App is one who does have access to a resource R, then that user should be able to see (via her Authentication App) from the Link: <...>, rel=acl related document that one or more of her credentials satisfies one of the wACLs, enabling the App to authenticate. If the user of the App does not have access to the original resource R, this will be because its Authentication App cannot find a credential to fit the rules.

This allows parts of the wACLs to be hidden to those who do not have access. If they don't have access to all of the wACLs and supporting documents (eg. groups) then nothing is lost to them. If they do have access to R, they will know how to access the resource, because they can read the wACLs and related documents (eg. a document describing a foaf groups).

So we see that there is a type of symmetry that allows open and protected information without leaking of sensitive information if such there be.

[bblfish]

It seems that a logical consequence of the design proposed for giving access to a protected Group described above would be that when adding people to a protected group, one needs to notify them of that fact (since otherwise they can't know they are part of it) and so would not know to respond correctly to an wACL giving access to those members only. This would entail that clients keep a list of protected groups they are interested in being members of (and perhaps a trash list of ones they want people to know they never wanted to be part of).