Prior Art Collection

[jeswr]

These are areas where we need prior research to collect:

• Existing work done on the topic in the context of Solid
• Related work done on the topic outside of Solid

The process for research is:

• Propose topics for research in this issue
• Self-nominate to lead research on a particular topic
• Write up research on the topic in the wiki for this repository

The current areas for research include (not exchaustive or in any particular order):

• Authorization - what has been attempted (including WAC, ACP, SAI), what industry solutions are there (e.g. what does AWS, GDrive) use for their permissioning system. - @termontwouter
• Authentication
• Discovery - Currently assigned to @jaxoncreed
• Consent mechanisms (including access grants, inbox based mechanisms, other).
• Read/write operations
• Notifications (unstable topic - may not be included in current version of LWS)
• Inbox (unstable topic - may not be included in current version of LWS)
• Profile negotiation (unstable topic - may not be included in current version of LWS)

This is to better inform, and speed up the process of writing each section as we get to it.

[uvdsl]

As pointed out in the meeting on 2025-06-09, I think there are many knowledgeable members of the community e.g. in the Solid CG or at the research organizations working on Semantic Web Technologies who could easily help to fill in the blanks.

In particular, I would like to highlight that the WG charter already provides a list of input documents and dependencies. Moreover, the charter provides clear guidance on which communities should be considered in such efforts.

[elf-pavlik]

One of the topics could be a dedicated authorization app/agent. Both SAI and MANDAT work by @uvdsl and team explored that approach:

• https://www.researchgate.net/publication/381463975_AuthApp_-_Portable_Reusable_Solid_App_for_GDPR-Compliant_Access_Granting (I couldn't find the full text online)
• https://solid.github.io/data-interoperability-panel/specification/#authorization-agent implemented in https://sai.js.og and https://activitypods.org/ (work in progress)

I plan to add variants to existing use cases, where the end user requires to manage all the access from one dedicated application that they trust and are used to the UX provided by it. Another use case will be sharing a resource, for example an event, without disclosing full social graph to domain specific app (eg. calendar app) SAI have very simple redirect based mechanism that can satisfy those use cases, as well as building blocks for more sophisticated mechanism.

---

In this discussion

• Authorization Capabilities for Linked Data solid/authorization-panel#203 (comment)

There are 3 screenshots trying to illustrate that an access matrix can be collapsed on resources to get ACL (ACP, WAC) as well as on agents (SAI Data Grants). Collapsing it on agents seems to make more sense with the delegation approach taken in SAI. I know that proxy based delegation in MANDAT works with WAC.

---

I can also think of this paper based on UMA

https://solidlab.be/wp-content/uploads/2024/11/User-Managed-Access-Whitepaper.pdf

[uvdsl]

Thanks, @elf-pavlik for mentioning our work.

Andreas Both, Thorsten Kastner, Dustin Yeboah, Christoph Braun, Daniel Schraudner, Sebastian Schmid, Tobias Käfer, Andreas Harth: AuthApp - Portable, Reusable Solid App for GDPR-Compliant Access Granting. ICWE 2024
The postprint is available [1] now; finally the embargo has dropped.
[1] https://publikationen.bibliothek.kit.edu/1000172187

On the authorization topic, there is also a UC w3c/lws-ucs#27, where I also mention
Bailly et al: Prototyping an End-User User Interface for the Solid Application Interoperability Specification Under GDPR. ESWC 2023

[jaxoncreed]

I am interested in the "Discovery" research area, but happy to abdicate if anyone wants to to do it more.

[jeswr]

Thanks @jaxoncreed I've created https://github.com/w3c/lws-protocol/wiki/Discovery:-Research-Topic for you to add notes to - do you have sufficient permissions on the repo to modify the wiki?

[elf-pavlik]

Short note on discovery, in SAI for protected resources, which aren't public read + publicly indexed, AuthZ is required prior to discovery, given that order of events - discovery works based on access grants that were issued in AuthZ step. This prevents privacy leaks, so even the existence of certain type of data isn't disclosed unless requesting party / client are authorized to access that data. If there is a privacy respecting approach to discovery which doesn't require AuthZ first I would be very interested to hear about it. If there are none, I think reusing data artifacts from AuthZ for discovery can be a clean and pragmatic approach (based on my implementation experience with https://sai.js.org)

• reference: SAI Applictions Primer

EDIT

This video shows power of this approach where as soon as a new peer in the network shares a new resource, application with broad enough authorization can automatically discover it in real time

[bjdmeest]

For Authorization, in our lab we have been doing quite some work, mostly looking into interaction with other OIDC-related specs, e.g. UMA, me or (maybe even better @termontwouter) could volunteer to pull the efforts (or if not pull, we'll contribute :) ).
Considering consent mechanisms, @besteves4 is aware of quite some related work and legal regulations, so she could lead that effort (and she's also ODRL knowledgeable), so same: Beatriz or I could pull, and if not pull, we'll contribute

[gibsonf1]

Short note on discovery,

Wouldn't a simple search/query on a server which only returns results that the requesting agent can access accomplish the same level of privacy?

[elf-pavlik]

Considering consent mechanisms, @besteves4 is aware of quite some related work and legal regulations, so she could lead that effort (and she's also ODRL knowledgeable), so same: Beatriz or I could pull, and if not pull, we'll contribute

I exchanges few messages with @woutslabbinck about TREE/LDES and he also mentioned participating in ODRL related work

[elf-pavlik]

Wouldn't a simple search/query on a server which only returns results that the requesting agent can access accomplish the same level of privacy?

I think search/query can be part of the solution, I know that @jaxoncreed also heavily explores that. Still, a client at least needs to discover which server(s) it needs to query. Also if I authorize my clients (apps) to access data across various storages where I'm the resource owner and dozens (hundreds) storages where other social agents are the resource owner, there is protected data in a lot of places all over the web. In SAI grants in application registration act as a dedicated client-centric entry point from where it can follow its nose to all that data it was authorized to access. I guess something similar could be achieved with a user-centric query service that indexes all the protected data on the web that the user was granted (and accepted) access to.

BTW I believe we should not dive into too many details in this issue, editors/moderators please feel free to hide this comment as off-topic.

[jeswr]

Renamed: Research Topics -> Prior Art at suggestion of @kaefer3000

[termontwouter]

Thanks for suggesting me, @bjdmeest. As you already indicate, we'd be happy to take the lead on certain topics, or else contribute to the research effort. I believe the research on authorization (W3C uses US English, I'm afraid, @jeswr 😉) would indeed suit me best, since it is what I am currently working on most of the time anyway, and I've been following and contributing to the Solid CG's AuthN, AuthZ, and Interoperability panels – as well as to WAC, ACP, WebID, and Solid-OIDC – for the past 5y.

Last year a lot of effort went into the research presented in our white paper on OAuth and User-Managed Access which should definitely prove relevant for LWS (thanks, @elf-pavlik, for already mentioning it). In that paper, we highlight some of the shortcomings of WAC and ACP – but also of OAuth 2.x and UMA – in achieving real digital trust. These include multiple issues with orthogonality (RS – AS ; policy language – decision algorithm ; data – applications); restricted domains of protection and applicability (i.e., single LDP-specific hierarchies, assuming read-write symmetry); limited expressivity in policy language and authentication methods; lack of usage control, dynamic negotiation and delegation of control; and unnecessary disclosure of identity information.

This year, we've published and iterated on the first drafts of Authorization for Data Spaces (A4DS), a profile on top of UMA that addresses some of those issues; and we're working on a first implementation of an authorization server based on that specification, including a module for the Solid Community Server (CSS). Another highlight of that specification and implementation is it's complete orthogonality with policy engines. This allows for easy interoperability with, for example, @woutslabbinck's implementation of a FORCE ODRL evaluator (thanks again, @elf-pavlik, for mentioning this already).

When it comes to related work outside of Solid – not taking the custom in-house IAM solutions of the big five into account – OAuth 2.x is by far the de facto industry standard on protocol-level, so building on that with UMA/A4DS is a good start. GNAP is very similar, and has already been taking into account while drafting A4DS. On the level of policy engines, there are OPA, Zanzibar, and a decent amount of derivatives. The policy language for such systems is often still XACML (🙈), or a plethora of custom (JSON) formats (though OPA uses Rega, and is quite popular). From the Digital Trust perspective of our lab, however, we believe strongly in the semantic power of ODRL. All that should not necessarily concern LWS, though, since decent orthogonality should ensure that authorization servers can run any engine with any language, as long as they stay compliant with the outside interfaces of the protocol. In other words: let's focus on what matters (because we don't have much time).