Add Proxy section

[csarven]

Adds a section for Proxy.

Touched by the following use cases mentioned in https://solid.github.io/webid-profile/#use-cases :

• Communication and use of multiple profiles for different purposes.
• Anonymous, pseudonymous, and meronymous profiles.
• Compilation of preferences, choices, activities and interactions of an agent.

See also solid/vocab#94 for adding solid:proxy to Solid Terms.

---

Preview | Diff

[VirginiaBalseiro]

Looks good.

As a side note, HTML Diff appears to not be working properly. Checked and it's the same for other older PRs where we used it, so perhaps something has changed.

[elf-pavlik]

I think this is a reasonable starting point. As a separate issue I would like to discuss how to prevent a random users to use other user's proxies trying to obscure illegal activities. For example downloading copyrighted content, or accessing content related to abusing children etc.

[csarven]

I agree, that's an important and separate matter. My understanding is that the proxy resource ought to require authentication. I think if the proxy is hosted on a Solid server, that'd be relatively straight forward to protect. Irrespective to where the proxy is, the concern can be mentioned as a note. I can update this PR to reflect that but I think it has to do with a recommendation for servers offering the proxy feature.

[josephguillaume]

I would support mentioning security in some form to avoid normalising use of unsecured proxies.

If this is in the profile document, the implication is that the agent trusts the proxy, but the reality of convenience is that an agent and app may well use whatever is available to get around cors restrictions, without actually thinking about the consequences of a mitm attack.

Even if the agent trusts the proxy, the app may not trust it, and may therefore want to avoid using it in a higher risk context, e.g. the app being seen to be trying to access illegal information.

The agent also does not automatically trust every app wanting to use the proxy endpoint, as noted above.

I'm not a security expert, which increases my desire for a spec to draw my attention to possible risks I may have overlooked.

[elf-pavlik]

I assume the proxy would only access public read data and never pass credentials. If data requires authorization, it will be on the Solid pod and willn't need a proxy. A requirement for the proxy should be added - never to send any user credentials.

[csarven]

Even if the agent trusts the proxy, the app may not trust it, and may therefore want to avoid using it in a higher risk context, e.g. the app being seen to be trying to access illegal information.

In such scenario, it would be the proxy server that will be trying to access illegal information, and the server that is receiving the request from the proxy server is not aware of the application.

That aside, the same argument can be made for using an OIDC Issuer that is involved in illegal activities, so I've created solid/security-considerations#21

The agent also does not automatically trust every app wanting to use the proxy endpoint, as noted above.

In the same way agent not automatically trusting any information that makes it on to their screen through the application? How is that being measure or evaluated in other scenarios?

I assume the proxy would only access public read data and never pass credentials. If data requires authorization, it will be on the Solid pod and willn't need a proxy. A requirement for the proxy should be added - never to send any user credentials.

First of all, this specification is not concerned with how a proxy server should be configured, in the same way it is not suggesting that the Solid WebID Profile server shouldn't be sending user credentials to third parties. Nor do we say an Solid OIDC Issuer shouldn't be sending user credentials to third parties without user's consent.

Second of all, in all likelihood, a trustable / reliable proxy is going to require authentication, otherwise it'll be an open proxy. Irrespective to how a proxy is configured, what proxy an agent trusts, or what proxy an application defaults to (built-in) should be used, isn't something this specification can dictate.

---

I've added the following text based on the feedback ( 58d527f ):

An agent's preferred or trusted proxy may not align with their application's. The decision of whether and in what contexts to use any proxy is an evaluation and a balance between the needs of the agent and the application.

Is that adequate for now?

[josephguillaume]

Second of all, in all likelihood, a trustable / reliable proxy is going to require authentication, otherwise it'll be an open proxy. Irrespective to how a proxy is configured, what proxy an agent trusts, or what proxy an application defaults to (built-in) should be used, isn't something this specification can dictate.

I'm happy with the edit in that it hints that not all proxies are suitable.
Any recommendations on other specs/reading regarding appropriate proxies? The use of proxies with Solid to avoid cors restrictions seems rather different to many other use cases.

[elf-pavlik]

First of all, this specification is not concerned with how a proxy server should be configured

If this draft only focuses on service discovery, including the proxy, there should be a draft that puts some requirements on that proxy. I also suggested that in the PR to the vocab since vocabs don't include normative requirements.

[TallTed]

If data requires authorization, it will be on the Solid pod and willn't need a proxy.

Mightn't the data be spread across multiple pods? I can't think of any reason why a user should be required to have all their apps and/or data hosted in/by a single pod. This leads me to think that some app and/or data requiring authorzation could be on a different pod and therefore need such a proxy.

[elf-pavlik]

I meant that the access-protected data would be across variuos solid storage servers, which would set the needed CORS headers since the solid protocol requires it https://solidproject.org/TR/protocol#cors-server

To my understanding, the use case concerns in-browser apps that use public-readable linked data and can't rely on the servers hosting that data (non-solid storage servers) setting correct CORS headers.

[josephguillaume]

To my understanding, the use case concerns in-browser apps that use public-readable linked data and can't rely on the servers hosting that data (non-solid storage servers) setting correct CORS headers.

In addition to CORS headers, we also have the case where an in browser app using https wants to access linked data via http and is prevented from doing so by browser security rules.

[TallTed]

Suggested change

	<p>It is strongly encouraged to use protected proxies due to potential risks, including data exposure, privacy loss, and response manipulation.</p>
	<p>Users are strongly encouraged to use protected proxies due to potential risks, including data exposure, privacy loss, and response manipulation.</p>

[uvdsl]

I would like to contribute additional use case for linking to a proxy from a WebID profile.
This use case arose in our MANDAT Project (presented at Solid World Feb 2025, results documented in an Open Access Journal Article [1]).

---

Use Case: An Employee Acting on Behalf of an Organization.
This use case has also been documented in the Linked Web Storage use cases.

Example: An employee (Tom) acts on behalf of his company (SME) to search for and request a loan at a bank. The bank only sees the request coming from the SME, not the individual employee.

Discovery of the Proxy: The company (SME) advertises in their WebID profile their preferred proxy, their Rights Delegation Proxy (RDP) [2]. When Tom logs into an app, and wants/needs to act on behalf of SME, the app discovers the RDP from SME's WebID profile.

Functionality of the Proxy: The SME's RDP proxies requests from SME employees like Tom. In this use case, the proxy is equipped with the Solid's access control mechanisms (Solid-OIDC and WAC) such that only employees may access the proxy at all. In addition, the RDP is able to internally check whether a particular employee has the necessary rights to execute a particular action. Only if this is the case, then the request is forwarded.
A generally optional but for our use case required functionality is that the identity of the employee Tom is obscured/hidden in the forwarded request. This is achieved by a token exchange -- the RDP receives the ID+DPoP token from the employee (which were authenticated) and exchanges them for an ID+DPoP token of the SME without mentioning the employee.

This is referred to as impersonation (by the delegate (employee) as the principal (organization)) by RFC8693. If the RDP references the employee such that the bank can see that Tom initiated the request, this is referred to as delegation.

The RDP is thus able to log any requests that employee try to execute on behalf of the organization, and the organization's tokens are never present in the app used by Tom.

A very research-grade proof of concept, not maintained and overdue to be refactored, is available here. This is just to show that there exists "working" code for the above concept. If you are interested in this functionality, let me know.

---

With that, I second the idea of discovering a proxy via the WebID profile.

The above description of the behavior of the proxy is merely an illustration of what a proxy may be used for.
The above use case is of course generalizable to a user's personal proxy, e.g. to limit what resources a specific application may request or access if the user's Storage lacks a certain feature the user desires.

On security, I would defer the definition of the behavior of a proxy to a separate specification. In such discussion, I would be happy to discuss the mechanism we used in our RDP, based on Solid's own access control, and its relation to RFC8693.

---

[1] Andreas Both, Thorsten Kastner, Dustin Yeboah, Christoph Braun, Daniel Schraudner, Sebastian Schmid, Tobias Käfer, Andreas Harth: Foundational Components for B2B Data Sharing Using the Solid Protocol. J. Web Eng. 24(4): 593-634 (2025)
[2] Sebastian Schmid, Daniel Schraudner, Andreas Harth: The Rights Delegation Proxy: An Approach for Delegations in the Solid Dataspace. SDS@ESWC 2024

[elf-pavlik]

It might be useful to consider consequences of something like https://github.com/elf-pavlik/mallory?tab=readme-ov-file#cuckoo injecting new or swapping existing proxy to a mallicious one.