Hi all,
I’m currently developing a research proposal and would really appreciate feedback from the Solid community before I finalise the direction.
The broader research area is Human-Centred AI and personal control over the data context available to AI systems. My particular interest is health, social care and social protection, where relevant personal information may already be distributed across multiple authoritative systems.
Rather than moving or copying all of that sensitive data into a Solid Pod, I’m exploring a different role for the Pod:
a persistent, user-controlled authorisation layer for AI access, while the underlying authoritative data remains within the organisations that hold it.
For example, a person might interact over time with several AI-enabled services:
- an income-support navigator;
- a health-support assistant;
- a social-care navigator.
Each agent might request access to different information, for a specific purpose and duration.
The Pod would maintain a personal record of those authorisations, for example:
Income Support Assistant
Household information ACTIVE
Income ACTIVE
Purpose: income support
Expires: 14 days
Health Support Assistant
Functional assessment ACTIVE
Purpose: support navigation
Expires: 30 days
Social Care Assistant
Functional assessment EXPIRED
Conceptually:
User
↓
Solid Pod
(agent / data / purpose / expiry / revocation / access history)
↓
Access gateway
↓
AI services
↓
Health / Social Protection / Social Care systems
The external systems would remain the authoritative sources of data.
The access gateway would authenticate the requesting agent, check the current authorisation represented in the user’s Pod, and then permit or reject the request to the relevant external system.
I’m not assuming that Solid currently enforces access control over arbitrary external databases. The gateway connecting the personal authorisation state to external APIs would be an explicit part of the research prototype.
I’m also not claiming that Solid is uniquely capable of this pattern. UMA, OAuth-based approaches and centralised consent/permission registries can address related problems.
What I’m interested in is whether Solid provides a good foundation for a personal, portable and persistent locus of control across multiple services, rather than each service maintaining its own isolated permission state.
The Human-Centred AI study would then compare:
service-scoped permission management
with
a consolidated personal authorisation view
while keeping the information and controls available in both conditions equivalent.
The study would focus on whether people can understand and manage cumulative access over time, for example:
Which AI currently has access to this information?
Why was access granted?
Has it expired?
What has actually been accessed?
Can I revoke one agent without affecting another?
The broader idea I’m exploring is:
decentralising control over AI context without necessarily decentralising the authoritative data itself.
I’d particularly value feedback on:
- Does using a Solid Pod as a persistent personal authorisation registry/control layer fit reasonably with Solid’s architecture and philosophy?
- Are Access Needs, Access Authorizations, Access Grants and the Authorization Registry in the Solid Application Interoperability work appropriate building blocks for this kind of design?
- Is there existing Solid work addressing authorisation of access to data that remains outside the Solid ecosystem?
- If the external gateway described above is needed, where would you see the trust boundary and agent-authentication responsibility sitting?
- Would representing purpose, expiry, revocation and access history in the Pod be a reasonable pattern, perhaps using something such as DPV for purpose metadata?
- If current interoperability implementations are not mature enough for this, would a simpler RDF-based authorisation registry stored in a Pod be a sensible research prototype?
- What is the biggest technical or conceptual weakness you see in this architecture?
This is still at proposal stage, so critical feedback is very welcome. I’m particularly interested in identifying where I may be stretching Solid beyond its intended role before committing to the implementation.
Thanks in advance