Adding ACP to Authorization Mechanisms in Solid Protocol

[justinwb]

Given that Access Control Policies have been accepted into the specification ecosystem and there are multiple implementations available, the question now becomes whether and how ACP is cited in the protocol specification itself, likely under the Authorization section.

Assuming that it is included in the Protocol's Authorization section, the next question becomes what is required for a server implementation to be conformant?

• A server MUST implement both ACP and WAC?
• A server MUST implement at least one of ACP or WAC?

[elf-pavlik]

I think we should consider scenarios where both would be used. I don't think a single resource should have both ACP and WAC rules applied to it at the same time. Possibly even in a single Storage only one of the authorization systems should be used. I created some time ago #377 to consider diversifying storage types, one aspect could be which authorization system is being used for the storage.

[timbl]

Well, for interop we of the Solid Protocol, we need to answer not so much

• A server MUST implement both ACP and WAC?
• A server MUST implement at least one of ACP or WAC?

as

• A storage MUST implement both ACP and WAC?
• A storage MUST implement at least one of ACP or WAC?

as it depends not on not on what the server is capable of doing, but what it is configured to do for the storage in question. But also of course

• A client MUST implement both ACL and WAC?
• A client MUST implement at least one of ACL and WAC?

Because WAC and ACP are completely incompatible, I can't see how a strage can run both at once. It would have to run the intersection of the features in some way, but I don't see anyone thinking along those lines. We talk about WAC pods and ACP pods. SO this means that clients have to be prepared to work with either.

So the logical conclusion is then that clients and apps MUST to be able to handle BOTH WAC and ACP.

This quite a big ask from the ACP community.

This would of course all be much easier if ACP has been formed as a set of extensions to WAC. There has been a call for ACP to be re-cast as a set of extensions to WAC. That should be looked at seriously.

I's note that the idea of Universal API sounds good but is a bit bogus in that the effect doing something in WAC is going to be different from the effect of doing it in ACP. WAC can guarantee some invariants which fail in ACP.

In fact the difficulty of writing for both ACP and WAC may mean than in practice we end up with clients which only work on one, and the Solid ecosystem is split in two.

[scenaristeur]

As apps developer, I think the server should inform "hey I'm using ACP" or "hey I'm using WAC" and the client library should have one by default and fallback to the other

[elf-pavlik]

So the logical conclusion is then that clients and apps MUST to be able to handle BOTH WAC and ACP.

During AuthZ panel talks we seemed to agree that most domain specific clients (task manager, calendar etc.) would not set any access policies. A person would use some dedicated Authorization client to manage their access policies, this would not be an average solid app.

I think we should be careful not to mislead the community that to develop some domain specific app (99% of solid apps?) they would need to implement (or just bundle in) any of WAC or ACP. That 99% of apps ,that are not dedicated ones to set access policies, will not need to deal with any of that. Most apps just need to understand hints like WAC-Allow and/or be able just to parse the information from something like SAI Data Grants.

[ThisIsMissEm]

Would it make sense to use the storage metadata/description document to document whether a storage server uses WAC or ACP? (I don't think this is per-pod, but per-storage server)

Currently this is done on a per-resource basis, but could likely be optimised across the entire storage server in clients.

[barath]

It appears it would be good to have further discussion on the universal API in the coming weeks to see how we can reconcile authorization use for apps that want universality. I'll try to coordinate the discussion when folks are available in a few weeks.

[melvincarvalho]

The famous cartoon applies:

Situation: there are 2 competing standards for access control in Solid Solution: We need to develop a universal standard library to cover everyone's use cases Situation: there are 3 competing standards for access control in Solid

ACP and WAC seem slightly incompatible:

• Agent/Group granted access to resource R in WAC
• Agent/Group denied access to resource R in ACP

Which seems to be a potential source of inconsistency. This may be made worse when the next Access Control system is proposed.

So I think there's going to be advantage for those that choose one, and only one, access control strategy, possibly leading to a degree of fragmentation.

FWIW: as a data point, I'd personally prefer the WAC only strategy (ie the status quo), at this point in time.

[TallTed]

The differences between WAC and ACP seem to come down to the two basic schools of security —

1. That which is not expressly permitted, is forbidden. (a/k/a WAC)
2. That which is not expressly forbidden, is permitted. (a/k/a ACP)

As in every other arena where these might be applied, I think that neither school is best for every use (or deployment) case -- so either both schools must be available (which may mean changing the base assumption of either or both WAC & ACP), or we must decide which deployments we most want to support (and which least).

[elf-pavlik]

2. That which is not expressly forbidden, is permitted. (a/k/a ACP)

I don't want to sidetrack into that but to my understanding, ACP does not take such an approach.

https://solid.github.io/authorization-panel/acp-specification/#granted-access-modes

6.3. Granted Access Modes

An Access Mode MUST be granted if and only if in the set of Effective Policies:

• a satisfied policy allows the Access Mode; and,
• no satisfied policy denies it.

Again, just for the record.

[timbl]

@elf-pavlik You say, "During AuthZ panel talks we seemed to agree that most domain specific clients (task manager, calendar etc.) would not set any access policies. A person would use some dedicated Authorization client to manage their access policies, this would not be an average solid app." That finding surprised me very much. It sounds like a very strange way to go.

I think somain-level apps will need to change access control, both when setting up a new instance (like a new meeting) but also during the UX of day-day life.

• To ask users to do it directly using a generic UI is asking them to have too much knowledge of how the app works. Do we have to teach users that their chat files should have append access but notepad file write access? That when setting up a poll, the config file should be read-only to their participants, the data files append access?, and so on?

• An app typically maps between higher-level concepts such the Roles around instance, like (say,) Owners, Members, Invitees, Participants. Or Patient, FamilyAndFRiends, Doctor, Admin. The app then breaks the data into different resources or containers, and then gives different roles different acecs to different resources. This means the app has to control the access as it needs to do the mapping between Roles and Groups and Agents. A generic authz UI would not be aware of these mappings.

• In the flow of daily work, I may want inside an app just to give someone else access to a specfic task, only one task of many in a tracker. Say. But in general any solid app which deals with collections of things may want to chose whtehr it manages access t all resources in the collection as the same, or allows individual sharing.

• Sometimes there is logic to be done, like: Access to a contacts Card is the unions of access to groups which contain that card.

Here are the first few reasons which occur to me off the top of my head. Apps need to be able help the users manage their access control.

[bblfish]

@timbl wrote:

This would of course all be much easier if ACP has been formed as a set of extensions to WAC. There has been a call for ACP to be re-cast as a set of extensions to WAC. That should be looked at seriously.

This was my proposal. Starting from the observation that WAC seems to be an implementation of RelBac, which covers all of the ground we need in our use cases, I did not find the arguments that WAC needed to be restarted from scratch convincing. We started a project of evaluating both proposals, where I always proposed an evolutionary move from WAC to do the same thing as the feature under consideration. This I called WAC+ in those evaluations.

@timbl wrote

@elf-pavlik You say, "During AuthZ panel talks we seemed to agree that most domain specific clients (task manager, calendar etc.) would not set any access policies. A person would use some dedicated Authorization client to manage their access policies, this would not be an average solid app." That finding surprised me very much. It sounds like a very strange way to go.

I initially proposed such a specialised app a few years ago called the Launcher App though I was thinking of it more in terms of

1. reading WAC rules and
2. finding the right ID to authentication and
3. authenticate the app. In the case of http signature using IETF HTTP-bis WG's proposal to Sign http headers to allow the app to authenticate.

The Launcher App could thus sign headers allowing an app to edit acl rules, which would allow the scenarios you propose above.

But at the same time I have been wondering if it would not be better if access control settings editing were not filtered by an app such as the launcher app that is trusted by the user. But then your points above will need to be taken into account. If one wanted both it would indicate then that the client would need to communicate its desires to the Launcher App or the Wallet component of it, which would need to execute on it.... I'll need to think about that.

[elf-pavlik]

I'm afraid that we might be diving into a broader topic that goes beyond this issue's original intent. We probably should move this conversation to https://github.com/solid/authorization-panel/discussions and mark the moved comments as out of topic.

I think we should reinstate AuthZ panel meeting and make this discussion a main topic for one of the next meetings.

To quickly respond to @timbl

To ask users to do it directly using a generic UI is asking them to have too much knowledge of how the app works. Do we have to teach users that their chat files should have append access but notepad file write access? That when setting up a poll, the config file should be read-only to their participants, the data files append access?, and so on?

If those decisions are per app, then multiple apps will not be able to interoperate. In interop, we work with Shape Trees and Data Registrations to have app-independent ways of defining such details.

Across AuthZ and Interop panels we also discussed a simple common flow, which app would use to initiate sharing access to a specific resource or set of resources, with the dedicated AuthZ management client of the current user.

For most of the remaining points raised, I think we should consider how we expect to deliver on the promise that each user can choose an app of their choice and still collaborate on various domain-specific datasets with users who have chosen other different applications. IMO we can't leave most if not all of the mentioned details up to each of those apps.

Probably for each use case we should consider a scenario in lines of:

1. Pavlik (@elf-pavlik) and Justin (@justinwb) collaborate on common projects and tasks stored in @solid
2. Each one of them uses a different application to interact with those shared projects and tasks
3. Justin uses his application of choice (eg. Projectron) to also interact with projects and tasks stored elsewhere @janeirodigital etc.
4. Pavlik uses his application of choice (eg. SolidTasks) to also interact with projects and tasks stored elsewhere @hackers4peace etc.

Given all the above, we should have a good start in defining which parts of the interop belong where. As I currently see it, apps need an external 'common understanding' to be able to interoperate this way. We probably can't leave to those apps more than the domain-specific UX choices.

[timbl]

I want here to summarize my comment ,getting back to the original issue https://github.com/solid/specification/issues/447#issuecomment-1202434027 back at the start of this issue:

I believe all spec compliant servers must support either WAC or ACP. However, all compliant client libraries must support both WAC and ACP and detect when a pod is using one or the other and act accordingly.

Let's close this issue when we have that wording in the spec.

[woutermont]

It perplexes me that in some discussions we make a big deal of keeping complexity at a minimum for users and app developers, while in others (like here) we neglect it as if it were only a small bonus. I think @elf-pavlik has twice pointed out the value of an interoperability layer, with good reasons and examples. As this bears significant impact on the clientside requirements, I cannot understand why this issue should be closed by a short repitition of @timbl's opinion, and without addressing the points raised.

[bblfish]

Simplicity is an essential value for pragmatic reasons: to get going Solid needs implementations which can only be built with finite resources. The more complex things become the more costly. And unnecessary complexity is a waste. So the simplicity criterion is important.

But for weird political reasons we ended up with two access control systems, and Tim's proposal is a recognition of this reality. ACPs defenders have a lot of resources it seems so this may not be a problem for them.

I argued for WAC+ , i.e. extensions to WAC that would give us the features that ACP defenders wanted. So I worked carefully to compare WAC and ACP and always proposed an extension compatible with WAC that could get us the same. Those evaluations are in the evaluation directory. We started writing overview documents but that was then improved to show no information at all.

In the end ACP just continued irrespective of the process we had started.

For resource reasons I won't be able to implement both, so unless convinced otherwise (by eg. seeing that ACP is really brining something new to the table) I will implement only WAC on the server and client, with some WAC+ extensions. If I were to get more resources, I could also implement the other. But even then I would want to first evaluate both before investing in the work to support one more.

[woutermont]

Well, then you are a perfect example of why we should NOT mandate both authz mechanisms to be supported by each client. I believe the only way forward is to somehow converge on a single interface. And since I believe that applications should never be allowed to change access control rules themselves (but rather by asking the user's auhtz agent), I am convinced that incorporating the Interoperability spec as a core part of Solid is the way to go.

[elf-pavlik]

And since I believe that applications should never be allowed to change access control rules themselves (but rather by asking the user's auhtz agent)

If the project I proposed to NLnet will go through, I'll be working on implementing exactly that flow starting around January 2023.

IMO if we make a clear distinction between clients which do NOT touch access control at all and clients which specialize in managing access (eg. SAI Authorization Agent). Putting some extra burden on supporting currently two, and possibly more as the ecosystem evolves, authorization systems seem more justifiable.

I touched on client conformance on test-suite chatroom. While it still needs some clarification I think each client can cherry-pick features that are needed for it to operate. If some domain-specific client works with the assumption that the user has a separate and dedicated access control management client, the domain-specific client will only implement the required flow of handing off the user's interaction to the authz specialized client and skip any direct access control management itself.

[woutermont]

@elf-pavlik

[I]f we make a clear distinction between clients which do NOT touch access control at all and clients which specialize in managing access (eg. SAI Authorization Agent) [...] supporting currently two, and possibly more [...] authorization systems seem more justifiable.

While I agree that having specialized authz applications makes it more feasible for servers to freedly pick their authz framework, I don't believe that "[E]ach client can cherry-pick features that are needed for it to operate." I.m.o. when users (wisely) decide to use an authz agent to manage access to their data, their ACRs should no longer be accessible by other applications. Thus, in order to access those users' data, applications will have to support interaction with the authz agent, and won't be able to interact directly with WAC/ACP themselves.

Maybe I'm not seeing how enabling so would work without breaking stuff (e.g. source of truth problems). Do you?

[elf-pavlik]

Any application conforming to Solid Application Interoperability will be able to interoperate over any data in Data Registries. Other applications, which for example only conform to plain Solid Protocol, will not interoperate with SAI apps, they will also not be able to access any data in Data Registries.

On the other hand, any domain-specific application conforming to SAI, will not care if WAC/ACP/next-gen authz is being used. They pretty much only are concerned with SAI Access Grants plus basic access modes (excluding any Control related ones) https://github.com/solid/authorization-panel/issues/194

[woutermont]

Yes, I know, and that is precisely what I find problematic: in order to guarantee usability with pods of different users on different servers, applications will thus have to support WAC (for some pods without SAI), ACP (for other pods without SAI), and SAI (for pods with SAI). That is not developer-friendly at all.

On the other hand, if SAI were to become part of the Solid core, as a minimal interface, then [A] clients would only have to worry about SAI interactions, and [B] the authz framework would become an orthogonal concern.

[bblfish]

I don't think I have seen any work to show that SAI would be able to act as a minimal interface between ACP and WAC. We started work to show the mapping between ACP and WAC, and just that is a lot of work. I never heard of any work bringing SAI in seriously, nor any convincing argument for why it would be better.

So I would say that is for the moment just wishful thinking.

[elf-pavlik]

@woutermont I don't think SAI-conforming apps should try to interoperate with apps not conforming to SAI. I the app doesn't conform to SAI it means to mean to me that this app doesn't intend to interoperate with other apps. Unless one day someone will propose an interop layer providing an alternative to SAI, based on which apps could also interoperate.

EDIT: I think we should have a dedicated discussion about application interoperability, including SAI, and possible future alternatives including yet-to-be-drafted type indexes based interop.

[woutermont]

@elf-pavlik

I don't think SAI-conforming apps should try to interoperate with apps not conforming to SAI. I the app doesn't conform to SAI it means to mean to me that this app doesn't intend to interoperate with other apps.

To me, that feels like a dangerous starting point, capable of throwing out half of Solid's importance. I simply cannot see how Solid can deliver on its promise to separate apps from data, when each app can still choose to ignore SAI, and use WAC or ACL directly in order to lock it's own special formatted data somewhere in each user's pod.

I think we should have a dedicated discussion about application interoperability, including SAI, and possible future alternatives including yet-to-be-drafted type indexes based interop.

Very much aggreed! I think SAI and WebID-Profile contributors should sit around the table to talk this through.

[woutermont]

@timbl @bblfish @elf-pavlik Should it be relevant, I implemented an extention of WAC in the CSS, enabling client- and issuer-based ACL constraints: https://github.com/CommunitySolidServer/CommunitySolidServer/pull/1537