Re: Who writes the ACLs on your pod?

I agree with Harsh, an ISO standard follows an architecture along these lines:

 

 
Everyone is connected, networks will get faster and lower latency
Follows the principles of triples (actor, action, asset) and coexists with emerging standards
With enough decorations, you can also implement temporary caching (e.g. “access for one-day” type) to reduce network/latency/trips
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
External PDP allow for changes and enforcement at scale - one place that affects large amounts of components
External policy registries allow for consistency and reduction of cost of implementation, training, maintenance
Lowers barrier of entry (a PEP component is built once – used anywhere) to create more complex behaviours using public policies
 

Regards,

 

___________________________________

Joshua Cornejo

marketdata

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 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.

 

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