# Exploring Solid as a persistent personal authorisation layer for AI across health and social services **URL:** \ **Category:** General Discussion\ **Created:** [October 7, 2026, 4:00pm UTC](https://forum.solidproject.org/t/exploring-solid-as-a-persistent-personal-authorisation-layer-for-ai-across-health-and-social-services/10980 "2026-10-07T16:00:14Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![mark\_cc](https://avatars.discourse-cdn.com/v4/letter/m/4da419/32.png) [@mark\_cc](https://forum.solidproject.org/u/mark_cc)\ **Post date:** [October 7, 2026, 4:00pm UTC](https://forum.solidproject.org/t/exploring-solid-as-a-persistent-personal-authorisation-layer-for-ai-across-health-and-social-services/10980/1 "2026-10-07T16:00:14Z")
### 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: ```auto 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: ```auto 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: 1. Does using a Solid Pod as a persistent personal authorisation registry/control layer fit reasonably with Solid’s architecture and philosophy? 2. 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? 3. Is there existing Solid work addressing authorisation of access to data that remains outside the Solid ecosystem? 4. If the external gateway described above is needed, where would you see the trust boundary and agent-authentication responsibility sitting? 5. Would representing purpose, expiry, revocation and access history in the Pod be a reasonable pattern, perhaps using something such as DPV for purpose metadata? 6. 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? 7. 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 ---
**Author:** ![bourgeoa](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.solidproject.org/bourgeoa/32/291_2.png) [@bourgeoa](https://forum.solidproject.org/u/bourgeoa)\ **Post date:** [October 8, 2026, 9:01pm UTC](https://forum.solidproject.org/t/exploring-solid-as-a-persistent-personal-authorisation-layer-for-ai-across-health-and-social-services/10980/2 "2026-10-08T21:01:41Z")
You may be interested with [ODRL V2.2 Implementation Best Practices](https://w3c.github.io/odrl/bp/) This should be implemented in lws specification [https://www.w3.org/TR/lws10-core/](https://www.w3.org/TR/lws10-core/). This specification shall be in someway’s complementary to Solid. A CSS PR tries to propose the basis for an implementation of lws. The solid-lws should work with Solid. > **[GitHub - jeswr/CommunitySolidServer at feat/lws](https://github.com/jeswr/CommunitySolidServer/tree/feat/lws)** > > feat/lws An experimental CSS mashlib recipe with solid-lws can be tested locally [GitHub - SolidOS/css-mashlib at feat/lws · GitHub](https://github.com/SolidOS/css-mashlib/tree/feat/lws). There are 2 config available for `solid-lws` LWS is not finalised.