elf-pavlik
commented
5 years ago The server may propose different ways to allow authentication: using a WebID, using OpenID, HTTP Basic Auth,...
As we touch during last Authentication Panel call, we may aim at having limited authentication methods for Resource Servers (possibly just one). OIDC Providers on the other hand can offer whatever. I've created issue to track authenticating users with different parties https://github.com/solid/authentication-panel/issues/27
@bblfish I don't see clear way forward to resolve this issue. If you would like to propose adding independent access control for acl resources themselves, I suggest making PR with proposal which should include or reference Use Cases it tries to address.
This issue is to highlight aspects where interaction between issues from the Authorization Panel and Authentication Panel come together, and where looking at them together makes issues visible that would not be apparent separately.
A solid client differs from normal web2.0 app in that it is likely to be fetching data from all over the web by following links, in order to build a display for the user. To build a single display the client may therefore need to authenticate to a number of different resources located potentially on many different servers.
If we look at just one authentication event:
Because of privacy and efficiency concerns it would not do to have the client try out every single credential/identity it can. What it should be able to do is on a 401, look at the access control rules and the HTTP header telling it which methods of authentication are allowed, and work out what credentials it may need before authenticating, ordering them according some metric such as privacy. Even if the client has none of the needed credentials it could at least work out from the wACL what it would need to do to be able to interact with the resource -- perhaps become member of a club, or a friend of someone, ... It may even want to ask for a wACL change, say if the client knows it should have access.
This interaction between client and server indicates that there are very good reasons and use cases for many wACLs to be public. (note: it is not an argument to require them all to be public). Since there are also reasons for some ACLs to be protected, there must be a way to separate wACLs into public and protected parts, by say including one ACLs (through a link) into another.
It should be possible for the user of the app then to set policies about when to automatically authenticate, when to warn the user, or even to ask the user for information.