Question about access modes

[michielbdejong]

https://solid.github.io/data-interoperability-panel/specification/snippets/projectron.example/needs.ttl mentions acl:Create but I think https://www.w3.org/ns/auth/acl only defines acl:Write.

See also https://solidproject.org/TR/wac#access-modes

[michielbdejong]

Are access modes out of scope for this spec and should we in practice just use the ones that WAC defines?

[elf-pavlik]

We rely on allowing an agent to create new contained resources without allowing them to change the description of the containing container itself (the server manages ldp:contains statements, not the client).

There are relevant issues which still stay unresolved:

• Universal Access Modes API authorization-panel#194
• Ideas for access modes and corresponding operations in the Protocol authorization-panel#253

[michielbdejong]

OK, so it's complicated :)
I'm looking for a version of the interoperability spec that I can use now, in combination with a pod server that adheres to the Solid 0.10 spec. Ideally I think I want to have a sort of "admin app" or "launch panel" that implements the authorization server and that edits ACLs on the pod to add/remove access for specific apps to specific folders. Do you think that's possible?

[elf-pavlik]

I'm open to collaborate on TS packages that can set ACL and ACP policies based on SAI Access Grants. Once available we can hook it up to sai-impl-service.
This will still leave some undesired access open until we can resolve the two issues linked above.

[elf-pavlik]

Meeting minutes:

@justinwb: Spec currently explains how to use current WAC access modes while more granular ones are missing.

@michielbdejong: I plan to implement WAC+ (which will add acl:Create and acl:Update) in Solid Next Cloud and see how that will work

@elf-pavlik: in SAI, WAC acl:Control would be reserved only for the Authorization Agent so it can maintain the single source of truth for access policies. Any regular (domain-specific) app would use flow from #138 to share access.