Re: Who writes the ACLs on your pod?

> I’ve not found a diagram that showcases the solid architecture – I would
have used that as a baseline.

Forgive my drawing skills, but here is a quick diagram of how Solid works
when using ACLs and client IDs to implement the separation between
apps, identity, and storage. This is the best I could come up with without
diverging from the current* Solid spec.

Some apps can edit the data on the user's pod, some apps can edit the
ACL's. That is the architecture we are working with here. We might conclude
that this architecture is flawed and should be replaced, but it is what we
have:
[image: Screenshot 2025-02-04 at 16.09.03.png]

*) "current", except for the use of UMA in Solid-OIDC, which was specced a
few years ago, but not yet implemented very widely.

On Tue, 4 Feb 2025 at 15:53, Joshua Cornejo <josh@marketdata.md> wrote:

> I refer to “container” as in the software pattern, not the infrastructure
> concept.
>
>
>
> “Component” might clarify the intent, but it looks vague when expressing a
> “bucket with objects like person, organisation, car, house, etc”.
>
>
>
> Unfortunately, I’ve not found a diagram that showcases the solid
> architecture – I would have used that as a baseline.
>
>
>
> Cheers,
>
>
>
> ___________________________________
>
> *Joshua Cornejo*
>
> *marketdata <https://www.marketdata.md/>*
>
> smart authorisation management for the AI-era
>
>
>
> *From: *Frederick Gibson <frederick@graphmetrix.com>
> *Reply-To: *<frederick@graphmetrix.com>
> *Date: *Tuesday 4 February 2025 at 14:40
> *To: *Michiel de Jong <michiel@unhosted.org>
> *Cc: *Joshua Cornejo <josh@marketdata.md>, public-solid <
> public-solid@w3.org>
> *Subject: *Re: Who writes the ACLs on your pod?
> *Resent-From: *<public-solid@w3.org>
> *Resent-Date: *Tue, 04 Feb 2025 14:39:57 +0000
>
>
>
> For data interoperability, using containers seems fundamentally flawed for
> the same reason that trying to organize information in directory structures
> is fundamentally flawed.  Everyone has a different idea on which containers
> to use, how to name them, what hierarchy they should be in, etc.   Taking a
> more semantic systems approach to enable interoperability may have a far
> more successful outcome, for example, using the webid as the top level
> system object for a pod with a standard system hierarchy below that based
> on what that pod represents, whether it be a person, organization, car,
> house, etc.
>
>
>
> Fred Gibson
>
> *Founder & CEO*
>
> *mobile: 415.335.8232*
>
>
>
> 1255 Treat Blvd, Suite 300
> PMB#4611
>
> Walnut Creek, CA  94597
>
> *office: 925.940.0741*
>
> [image:
> cid:0.28869225360.8677785181422948554.194d1671138__inline__img__src]
>
>
>
>
>
>
>
>
>
>
>
> ---- On Mon, 03 Feb 2025 06:18:01 -0800 *Michiel de Jong
> <michiel@unhosted.org <michiel@unhosted.org>>* wrote ---
>
>
>
> Thanks for your replies! That gives a lot of context and vocabulary for
> this discussion.
>
>
>
> Nevertheless, I think the open questions that remain are:
>
> 1) For our ACP+OIDC-based Solid servers, will we restrict the root ACL to
> one or more specific app store(s) or app launcher(s) like I did here
> <https://github.com/SolidOS/css-mashlib/pull/12/files#diff-dc4616bca0f58db6ed4723826804587e7c8d9ff61d3132e057f9f9e872d5dce8R38>
> ?
>
> 2) For our WAC+OIDC-based Solid servers, what should we do? Have a really
> stern warning like I did here
> <https://github.com/solid-contrib/pivot/pull/38#issuecomment-2531296629>?
> Not ideal of course! We want to do better. But what is the way forward?
>
> 3) We have the SAI spec which may actually one day replace  ACLs
> altogether, or become an answer to the question of how we edit the ACLs on
> our pod, but none of our Solid servers have adopted it yet. Can we somehow
> work together to change that, so that we can try it out on at least one
> Solid server?
>
>
>
> If we apply one of these three options then we can begin to define a
> minimal version of interoperability between Solid apps. I have spent
> considerable effort on all three options over the past years, and have
> recently ended up picking the first one.
>
>
>
> I did some more demo building and my "app launcher" now has three
> bookmarking apps in its "app store":
> https://github.com/pdsinterop/launcher-exploration/blob/957a0dacd5baa8e4d9bef1681c363195767bd3e8/app-permissions.js#L1-L14
>
>
>
> It now demonstrates actual interop between real Solid apps! :)
> https://www.youtube.com/watch?v=I48DW0F4bX4&t=269s
>
>
>
> So, achievement unlocked, in that sense. :) But even with that, more
> questions remain:
>
>
>
> A) Should we try to form a consensus and gain traction on one of the three
> options? Or should we keep the options open to allow for more diversity and
> experimentation?
>
> B) Should access be edited along the lines of the private and public type
> index, or can we do better? More precisely, do we want to stick to the type
> indexes approach and try to build an ecosystem of interoperable apps with
> that, or do we want to develop something better than type index based, or
> do we want to do both of those things at the same time?
>
> C) Assuming we want there to be multiple independent implementations of
> Solid app launchers/stores apart from the rudimentary one I put together
> for this demo, and we don't want to enforce one centralised app registry on
> them, how can we nonetheless help them manage their app registries in a
> collaborative way, and can https://github.com/solid/catalog help there?
>
> D) Is scoped access for Solid applications actually a goal in itself we
> want to achieve, or should we not work on scoped access unless we also work
> on other dimensions of fine-grained consent (such as purpose, agreement to
> policies, audit, etc).
>
>
>
> Cheers,
>
> Michiel de Jong
>
>
>
> On Sat, 1 Feb 2025 at 10:33, Joshua Cornejo <josh@marketdata.md> wrote:
>
> I agree with Harsh, an ISO standard follows an architecture along these
> lines:
>
>
>
> [image: cid:ii_194cc0913714ce8e91]
>
>
>
>    1. Everyone is connected, networks will get faster and lower latency
>    2. Follows the principles of triples (actor, action, asset) and
>    coexists with emerging standards
>    3. With enough decorations, you can also implement temporary caching
>    (e.g. “access for one-day” type) to reduce network/latency/trips
>    4. The audit is not necessarily the responsibility of the owner of the
>    container and might not even be the responsibility of the PDP/registry
>    provider
>    5. External PDP allow for changes and enforcement at scale - one place
>    that affects large amounts of components
>    6. External policy registries allow for consistency and reduction of
>    cost of implementation, training, maintenance
>    7. Lowers barrier of entry (a PEP component is built once – used
>    anywhere) to create more complex behaviours using public policies
>
>
>
> Regards,
>
>
>
> ___________________________________
>
> *Joshua Cornejo*
>
> *marketdata <https://www.marketdata.md/>*
>
> smart authorisation management for the AI-era
>
>
>
> *From: *Harshvardhan Pandit <me@harshp.com>
> *Date: *Saturday 1 February 2025 at 00:38
> *To: *<public-solid@w3.org>
> *Subject: *Re: Who writes the ACLs on your pod?
> *Resent-From: *<public-solid@w3.org>
> *Resent-Date: *Sat, 01 Feb 2025 00:38:01 +0000
>
>
>
> Hi.
>
> A 'registry' (is this different from an 'app store' as in the Apple on or
> a 'package repository' as in the Linux ones?) is definitely the correct
> step forward IMHO for practical governance and management of apps. Two
> relevant papers that are helpful for governance of apps for things like
> policies, notice/consent/contracts, and also things to consider regarding
> lock-ins etc.
>
>
>
> 1) Making Sense of Solid for Data Governance and GDPR
> https://doi.org/10.3390/info14020114 (see Section 5.2 in particular)
>
> 2) Using Patterns to Manage Governance of Solid Apps
> https://ceur-ws.org/Vol-3636/paper5.pdf (See fig.1 on pg.5 to summarise)
>
>
>
> For "access scope" - it would be better to not reinvent terms where
> possible. If we're talking about a description of data used/processed by
> the app, then it goes beyond 'access' (see article 1 above). Currently,
> this information is contained within a document called a 'privacy notice'
> where it also includes information such as who is doing what, what controls
> are available to start/stop something, and how to exercise rights and
> requests. But we definitely shouldn't repeat that rubbish modus operandi of
> drowning people in large legalese documents. So instead, we can think
> something like the Privacy Labels in the Apple App store which, but much
> more detailed and useful - in machine-readable form. This way no one has to
> 'read' anything and 'agents' have the information to support decision
> making in context. This follows from the existing philosophy of what Solid
> aims towards IMO.
>
>
>
> In terms of having a 'language' to do all of these - DPV
> https://w3id.org/dpv <http://w3id.org/dpv> is fully capable of expressing
> all pertinent details, and can be extended to add granular/arbitrary things
> like specific data categories, 'purposes', technical measures, and
> actors/roles for Solid. ODRL is a standard to express
> agreements/permissions/prohibitions/etc. - so it provides the framework for
> stating something is a request, a user policy, an agreed use of app/data,
> etc on top of DPV. So the only thing remaining is creating a spec and
> getting folks to use/improve it.
>
>
>
> Regards, Harsh
>
>
>
> On Wed, 29 Jan 2025, at 09:30, Michiel de Jong wrote:
>
> Hi all,
>
>
>
> I wanted to share this 9-minute screencast about an experiment we
> originally did in 2019 and recently updated to the latest spec version:
> https://www.youtube.com/watch?v=5Q1nUmGdaXE
>
>
>
> In this example, the launcher app "knows" that Poddit is an app that
> requires access to instances of type 'bookmark', through a hard-coded
> registry
> <https://github.com/pdsinterop/launcher-exploration/blob/6328ad6f9d3e68f11bf2d77a3ae838a0d7909692/app-permissions.js#L1-L6>
> .
>
>
>
> Within the Solid project, and also maybe cross-fertilising with
> other related projects on this, we could do a lot of improvement on how
> such an app registry would work in the real world, and on developing a
> language to express access scopes such as "all your things of type
> Bookmark".
>
>
>
> Cheers,
>
> Michiel
>
>
>
>
>
>
>
>