-
Notifications
You must be signed in to change notification settings - Fork 20
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
Fundamental Principle: Client-Server symmetry #73
Comments
Related #58 |
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? |
i disagree with this proposal, because it
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. |
I very much agree with @zenomt in #73 (comment) for all of the reasons listed there. |
Thanks for your input @zenomt. To take your points one by one.
|
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. |
@zenomt wrote:
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. |
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:
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. |
I agree that the wording of the principle can be improved. @acoburn wrote
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...). All those examples are counterexamples to your claim @acoburn that
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 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. |
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 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. |
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). |
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:
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
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.
The text was updated successfully, but these errors were encountered: