Can Alice restrict Bob? was: Who writes the ACLs on your pod?

Hi Joshua and Auke,

I'm forking off this thread because I think it deserves a dedicated
discussion.
Of course we want to (one day) enable Alice as a pod owner to share a
resource with "any Bob", be they a person, an organisation, an application,
or server-side process, an AI agent, etc.

> Bob should be able to access that information using any Solid application
Bob wants to use.

That is the simple case, which we have working now. But:
1) wouldn't it be nice if Alice could set some ODRL-like restrictions on
what Bob does with the access?
2) this does require the app to edit the ACLs, so if Alice is initiating
this from an app that has no Control access, then there should be some
back-and-forth between that app and some other system - I don't think
anybody has built a working demo of this yet?
3) what if Bob wants to use an app to access the data Alice shared, but he
does not want to give that app root access to all his other data? Would he
be allowed to edit the ACL for the resource on Alice's pod to restrict
that? That would require Alice to give Bob control access.

I think the current Solid spec <https://solidproject.org/TR/protocol>can
support 2) but not 1) and 3).

On Tue, 4 Feb 2025 at 09:29, Auke van Slooten <auke@muze.nl> wrote:

> Hi Michiel, and everyone else,
>
> I've been lurking on this list for some time now, but this is hitting
> close to stuff I'm working on, and which I hope other smart people will
> make just work :)
>
> From an application builders perspective, I want a user (say Alice) to be
> able to share data with someone else (the more difficult use case Michiel
> sketched). The intent is that I can grant access to someone I know,
> regardless of the application that someone else uses. It seems obvious to
> me, that the choice of application is not relevant in this case. So I
> should be able to give a specific set of access grants (read/write/...) to
> Bob. Bob should be able to access that information using any Solid
> application Bob wants to use.
>
> Bob is probably going to get a notification from Alice in some form, but
> that should not be tied to Alice setting or removing access grants. A
> simple solution, Alice just emails Bob with the URL of the data she has
> just granted Bob access to. I'm planning to write a solid address book
> application, specifically to handle notices in that application (as well as
> setting the ACL's probably), if the user (Alice) chooses to do so. I
> haven't yet worked with the Solid inbox or pub/sub protocol, so have no
> exact solution, but I'm planning to use e-mail as a backup for people
> without a WebID / Solid Identity.
>
> So what I'm getting at is that you should be able to grant access to
> someone, without specifying an application. The use case where an
> application asks access to your data for some purpose, where it is working
> for/as you, and you want to limit access to the application more than the
> access you yourself have, is clear. And also needed. But we need both
> options.
>
> I haven't read all of this thread, but could we regard an application as a
> special kind of user? So either you grant access to an application (without
> specifying a specific user), or you can grant access to another user
> (without specifying an application). As long as a web application has a
> WebID, this should just work, right? The only caveat is that when you use a
> specific application to access some resournce, the access request should
> specify both WebID's.
>
> I've just finished a first version of a OIDC client, and the client_id
> already supports using a URL, which is supposed to resolve to more
> information about that client. This looks quite close to a users WebID
> already. Can't we just co-opt that? We'd only need to consider dynamically
> registered clients separately, I think.
>
Yes, this is (unfortunately) not possible with WAC, but it is indeed how it
works in ACP. See https://solidproject.org/TR/oidc#clientids-document and
create something like http://poddit.app/clientid.jsonld (link will trigger
a download).
See also the screencast I recorded last week:
https://www.youtube.com/watch?v=5Q1nUmGdaXE


Cheers,
Michiel.


Anyway, sorry if all this has already been hashed out and I missed it,
> these are my 2 cents :)
>
> regards,
>
> Auke van Slooten
>
> Muze.nl
> On 03-02-2025 16:36, Michiel de Jong wrote:
>
> To put it another way, I'm looking at the scenario where there is just one
> user, but there are multiple apps. For instance, the user is switching from
> one app to another, the 'plausible exit' scenario.
>
> We should of course also try to implement the scenario where one user
> ('Alice') shares something with another user ('Bob') but for that use case
> it's even harder than just the question of the title of this thread.
>
> Additional questions that arise there would be who should decide which app
> Bob should use for this (Alice? Bob? Alice's pod provider?) and we also
> don't have a good way for Bob to get notified that something was shared
> with him. The obvious way would be to send a Linked Data Notification to
> Bob's inbox, but I'm not aware of any Solid server implementation that
> actually pings its users when something hits their inbox. And of course
> also the additional question - if Alice gives Bob access to a resource on
> her pod, how can she express the purpose and the use restrictions in a way
> that she can trust Bob will adhere to. So the question I'm asking in this
> thread is far from the only question ahead of us. :)
>
> Cheers,
> Michiel
>
> On Mon, 3 Feb 2025 at 15:46, Michiel de Jong <michiel@unhosted.org> wrote:
>
>> Hi Joshua,
>>
>> Yes, that is indeed important to get clear. I'm not talking about GDPR or
>> ODRL or DPV here, although they can obviously help. I'm purely talking
>> about the Solid protocol and the Client-Client specs of the Solid project
>> here - in particular type indexes <https://github.com/solid/type-indexes> as
>> a way to know what type of data is in each document and/or container on the
>> pod, as a basis for access decisions.
>>
>> > authorisation by third parties
>>
>> Who are the first, second and third parties in this case?
>>
>> The way I'm modeling it here, there are four parties involved:
>> * the pod (storage+idp) owner/user
>> * the pod (and with that, its provider)
>> * the app launcher (and with that, its provider)
>> * the app (and with that, its provider)
>>
>> The app launcher edits the ACLs in response to instructions from the pod
>> owner.
>> In SAI, this is the authorization agent editing the registries the
>> achieve the same.
>>
>> The pod owner makes the decision
>> The app launcher translates the decision into edits in ACL documents
>> The pod (provider) hosts the ACL documents alongside the data in the pod,
>> and also enforces the policy described by them
>> The app gets access to the data, or not. :)
>>
>> HTH!
>> Michiel
>>
>> On Mon, 3 Feb 2025 at 15:29, Joshua Cornejo <josh@marketdata.md> wrote:
>>
>>> Michiel,
>>>
>>>
>>>
>>> Just to make things clearer and create the right context, OIDC
>>> definition of “Authorize” is not the same as the one Harsh/me are talking
>>> about.
>>>
>>>
>>>
>>> OIDC uses authorisation for coarse grain elements of the identity
>>> (claims connected to an account, things like “email” or “uuid”) during the
>>> process of authentication.
>>>
>>>
>>>
>>>
>>>
>>> (Harsh correct me if wrong) DPV refers to the language used to describe
>>> authorisation by third parties to access **ANY** data (parts of
>>> authentication or parts of the data inside app) according to specific
>>> controls (processes, legal or otherwise).
>>>
>>>
>>>
>>> ODRL is a language to describe rights management – from CRUD to
>>> sophisticated permissions/prohibitions/obligations (and any extended
>>> taxonomy of rules).
>>>
>>>
>>>
>>> Regards,
>>>
>>> ___________________________________
>>>
>>> *Joshua Cornejo*
>>>
>>> *marketdata <https://www.marketdata.md/>*
>>>
>>> smart authorisation management for the AI-era
>>>
>>>
>>>
>>> *From: *Michiel de Jong <michiel@unhosted.org>
>>> *Date: *Monday 3 February 2025 at 14:19
>>> *To: *Joshua Cornejo <josh@marketdata.md>
>>> *Cc: *<public-solid@w3.org>
>>> *Subject: *Re: Who writes the ACLs on your pod?
>>> *Resent-From: *<public-solid@w3.org>
>>> *Resent-Date: *Mon, 03 Feb 2025 14:18:26 +0000
>>>
>>>
>>>
>>> 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
>>>
>>>
>>>
>>>